Tech Landscape Evaluation

From Web of Things Interest Group
Jump to: navigation, search

In the following, we analyze the identified discovery technologies acoording to a set of evaluation criteria.

Evaluation Criteria

1. Interaction Pattern

This criterion specifies whether a discovery technology complies with the identified interaction pattern in that discovery category.

2. Support of higher layer discovery

This criterion specifies whether a discovery technology provides means to submit search queries based on terms used in the underlying data model, so the thing description. This includes searches such as e.g.: 'search all things with name X' or 'search all things with property XYZ'.

3. Bootstrapping

This criterion specifies whether means are provided to start/interact with things after discovery.

4. Lifetime / sleepy nodes

This criterion specifies whether sleeping times of constrained devices are directly considered by the discovery technology.

5. Range

This criterion specifies the spatial extent within which a discovery technology is functioning. This is important for the category “finding things around me”.

6. Support for (physically) local/remote discovery of things

7. Richness of query

This criterion specifies to what extent contextual query parameters can be passed in a search query to discover things. E.g., this may include spatial parameters ('search all things in NYC') and temporal parameters ('search all things active yesterday'). In comparison to the criterion 'Support of higher layer discovery', this criterion looks at richer search query mechanisms that go beyond a basic search for terms of the thing description model.

8. Ranking of results

This criterion specifies how/if the discovery mechanism is capable of ranking search results.

Evaluation

Category: 1) Finding things around me
Technology Follows Identified Interaction Pattern Higher Layer Discovery Bootstrapping Sleeping Time Support Range Local / Remote Discovery Richness of Query Ranking of Results
Optical Markers No (marker cannot send messages) No Pointing to thing endpoint n/a vicinity of client Local (vicinity of client) n/a n/a
NFC No (NFC initiator [client]starts interaction with target [thing]) No Pointing to thing endpoint n/a < 10 cm Local n/a n/a
Markerless Recognition No (things are not part of interactions) Yes (could be supported by filtering out things on an AR layer) Pointing to thing endpoint n/a vicinity of client Local n/a n/a
UriBeacon Yes No Advertise message points to thing endpoint There is support for sleep state in BLE and depends on which power mode is being used in the thing. For lowest power mode, the radio is switched off completely and the thing will not periodically announce its URI. There are power mode configurations where the thing powers on once every so many seconds, broadcasts, listens, then goes back to sleep. < 100 m (link) Local (around the client) n/a (since this discovery is not initiated by manual search) n/a
iBeacon Yes No Advertise message points to thing endpoint Same as above (need to confirm) < 100 m (link) Local (around the client) n/a n/a
Category: 2) Finding things on my network
Technology Follows Identified Interaction Pattern Higher Layer Discovery Bootstrapping Sleeping Time Support Range Local / Remote Discovery Richness of Query Ranking of Results
mDNS Yes No (but can be implemented on application layer) Client receives an IP address of the thing for direct interaction No n/a Local (network point of view) N/A since there is no manual entry of keywords No
Multicast CoAP yes yes, if resource directory is used address, port, and resource descriptions No n/a Local (network point of view) N/A since there is no manual entry of keywords No
SSDP Yes No (only basic filtering for devices or services with a specific type) Client receives the endpoint of the UPnP device description No n/a Local (network point of view) N/A querying using keywords is not possible No
WS-Discovery Yes Only basic filtering is possible. They use the term 'scope' for this. Discovery happens in two steps: (1) find services and (2) locate a target service, i.e., to retrieve its transport address(es) No n/a Local (network point of view) basic querying using service types and scopes No
XMPP Service Discovery No Yes (Two kinds of information can be discovered: (1) the identity and capabilities of an entity, including the protocols and features it supports; and (2) the items associated with an entity, such as the list of rooms hosted at a multi-user chat service) Provides information on identity and capabilities of an entity. No n/a Local discovery basic querying which discovers entity, features etc No
Category: 3) Searching in Directories
Technology Follows Identified Interaction Pattern Higher Layer Discovery Bootstrapping Sleeping Time Support Range Local / Remote Discovery (DOES THIS MAKE SENSE HERE??) Richness of Query Ranking of Results
CoRE Resource Directory Yes Yes, key-value-pair search based on tagged resources (e.g., "resource type", "interface type" etc.) is supported IP address & port of thing and list of resources matching the query No n/a Local and remote No. Not beyond tag concatenation. No
XMPP IoT Discovery Yes Yes Provides various metadata for discovered thing. Yes n/a Local and remote Basic (the spec is not finalized) No
HyperCat Yes Yes, flexible key-value-pair search based on tagged resources is supported Provides reference to thing. No n/a Local and remote No. Not beyond key-value-pairs. No
Push API Yes (???) Yes, through notifications Yes, Service Worker runs in the background n/a Yes (???) (???)
Sensor Instance Registry Yes Yes (bound to SensorML as thing description) Provides rich metadata description (SensorML) of discovered device No n/a Local and remote Yes. Spatial and Temporal queries. No
SPARQL Endpoint Yes Yes (flexible search interface - independent of underlying thing description) Provides description of discovered thing. No n/a Local and remote Yes, high flexibility in query formulation. Yes (with 'order by')
Category: 4) Searching across Peers
Technology Follows Identified Interaction Pattern Higher Layer Discovery Bootstrapping Sleeping Time Support Range Local / Remote Discovery Richness of Query Ranking of Results
CoAP RELOAD No pattern has been investigated See CoAP RD See CoAP RD No n/a Local and remote See CoAP RD No
Category: 5) Accessing thing metadata
Technology Follows Identified Interaction Pattern Higher Layer Discovery Bootstrapping Sleeping Time Support Range Local / Remote Discovery Richness of Query Ranking of Results
CoRE Link Format Yes No Yes, this format can be used for bootstrapping. No n/a Local and remote Low. Just direct access to metadata. Can be used by application layer to rank results
HATEOAS No (typically, not one metadata document, but information distributed and advertised via links) No Bootstrapping information can be gathered by following links. No n/a Local and remote Low. No
Sensor Observation Service Yes No Yes, it returns SensorML when metadata is queried. No n/a Local and remote Medium. Temporal queries are supported. No


--Arne Bröring (talk) 08:16, 8 October 2015 (UTC)