Tech Landscape Evaluation
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)