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)