View source for Discovery Categories and Tech Landscape

This list of discovery categories below outlines a technology landscape for WoT discovery mechanisms.

The aim of this exercise is to collect candidate technologies here and to subsequently derive generic discovery interaction patterns. 
Update: a first draft of discovery interaction patterns for the identified categories can be viewed [https://github.com/w3c/wot/blob/master/TF-DI/Interactions.md here].

Further, we have evaluated the identified technologies [[Tech_Landscape_Evaluation|here]].

Also, we are analyzing which discovery technologies are used by related IoT consortia, [[Discovery_Solutions_Iot_Consortia|here]].


===1. Finding things ''around me''===
This category of discovery includes technologies that allow to discover things ''around me'' (in a spatial sense).

* Optical markers 
** this includes e.g. barcodes and QR codes which can be visually read and decoded by a program (e.g. by an app)
** max range: vicinity of client
** Interaction style: ''pull'' (client initiates interaction)

* NFC
** Near field communication (NFC) employs electromagnetic induction between two loop antennae when NFC devices (e.g. 'smart phone' and 'smart object') interact.  NFC operates on globally unlicensed radio frequency ISM band of 13.56 MHz.
** builds up on RFID by allowing two-way communication between endpoints
** e.g. NFC can be utilized to bootstrap more powerful communication connections (e.g. Bluetooth or WiFi) between two devices
** max range: ~10 cm

* Markerless recognition
** augmented reality technique using sensors such as accelerometer, camera, compass, GPS to determine client's location and field of view. Based on derived position, surrounding things are discovered.
** implemented e.g. by AR browser LAYAR or AURASMA
** max range: vicinity of client
** Interaction style: ''pull'' (client initiates interaction)

* UriBeacon (Google's Physical Web)
** Base technology: Bluetooth Low Energy
** BLE-enabled device periodically transmits an advertising packet containing a '''URI'''.
** UriBeacon approach does not require an app. Since URI is identifying a beacon, standard Web mechanisms (DNS) can be used for resolving
** UriBeacon is now part of the [https://github.com/google/eddystone Eddystone] open source project which allows to send other beacon formats in addition to URLs. Eddystone supports broadcasting URLs via its [https://github.com/google/eddystone/tree/master/eddystone-url Eddystone-URL] frame type.
** max range: 100 meters (see: http://www.bluetooth.com/Pages/low-energy-tech-info.aspx)
** Interaction style: ''push'' (beacons broadcast information)
** https://github.com/google/uribeacon/tree/master/specification

* iBeacon (Apple)
** Base technology: Bluetooth Low Energy
** BLE-enabled device periodically transmits an advertising packet containing a '''UUID'''.
** iBeacon requires an app that is enabled to read whitelisted objects. UUID resolution requires an additional server.
** max range: 100 meters (see: http://www.bluetooth.com/Pages/low-energy-tech-info.aspx)
** Interaction style: ''push'' (beacons broadcast information)
** https://developer.apple.com/ibeacon


===2. Finding things on my network===
This category includes technologies that allow discovery of endpoints of things on the network.

* mDNS (+ DNS-SD)
** Base technology: IP + UDP
** multicast DNS (mDNS) resolves host names to IP addresses within small networks. When an mDNS client needs to resolve a host name, it sends an ''IP multicast'' query message that asks the host having that name to identify itself. That target machine then multicasts a message that includes its IP address. All machines in that subnet can then use that information to update their mDNS caches.
** often used in conjunction with ''DNS-SD'' that allows clients to conduct simple service discovery using standard DNS queries.
** part of 'zeroconf' technology suite
** implemented e.g. by Apple Bonjour
** Interaction style: ''pull'' (client initiates communication)
** https://tools.ietf.org/html/rfc6762 (+ https://tools.ietf.org/html/rfc6763)

* Multicast CoAP
** Base technology: IP + UDP + CoAP
** CoAP supports making requests to an ''IP multicast'' group.
** Clients can use multicast CoAP and the "All CoAP Nodes" multicast address to find CoAP servers. CoAP servers listen on the "All CoAP Nodes" address and the default CoAP port to reply to clients.
** in combination with ''CoRE Link Format'': a GET request to the appropriate multicast address is made for '/.well-known/core' (https://tools.ietf.org/html/rfc6690)
** Interaction style: ''pull'' (client initiates communication)
** https://tools.ietf.org/html/rfc7252

* SSDP
** Base technology: IP + UDP + HTTP''U'' + SOAP
** used by ''UPnP'' for discovery
** 'Simple Service Discovery Protocol' (SSDP) 
** In order to discover SSDP services, an SSDP client multicasts a HTTP UDP discovery request to the SSDP multicast channel/Port. SSDP services listen to the SSDP multicast channel/Port. If a SSDP service hears a HTTP UDP discovery request that matches the service it offers then it will respond using a unicast HTTP UDP response.
** Interaction style: ''pull'' (client initiates communication); however, some UPnP devices also ''push'' info periodically
** https://tools.ietf.org/html/draft-cai-ssdp-v1-03

* WS-Discovery
** Base technology: IP + TCP/UDP + SOAP et al.
** specifies multicast discovery via web service based communication; avoids the need for centralized registries in smaller networks.
** used by OASIS' Device Profile for Web Services (''DPWS'')
** implemented e.g. by Microsoft Web Services on Devices API
** Interaction style: ''pull'' (client initiates communication)
** http://docs.oasis-open.org/ws-dd/discovery/1.1/os/wsdd-discovery-1.1-spec-os.html

* XMPP Service Discovery
** Base technology: IP + TCP + XMPP
** discovering information about other XMPP entities (e.g. user). Two kinds of information can be discovered: (1) the identity and capabilities of an entity and (2) the items associated with an entity, such as the list of rooms hosted at a multi-user chat service.
** Interaction style: ''pull'' (client initiates communication)
** http://xmpp.org/extensions/xep-0030.html
** update: http://xmpp.org/extensions/xep-0115.html#discover

* µPnP
** Base technology: IP + UDP + CoAP + IPSO
** CoAP support makes use of CoAP's Resource Directory. Modified 802.15.4 link layer for support of uPnP. Resources formatted using IPSO Objects. 
** http://www.micropnp.com/ipso/index.html

===3. Searching in Directories===
In contrast to the above technologies, here, a central directory can be used for discovery of things and resources. '''Queries''' can be submitted to the directory to search for things and/or resources.

* CoRE Resource Directory
** Base technology: IP + UDP + CoAP
** Resource Directory (RD) hosts descriptions of resources held on other servers, allowing lookups to be performed for those resources
** Also defines lookup interface that allows simple queries (e.g.: ''GET /rd-lookup/res?rt=temperature'' )
** https://tools.ietf.org/html/draft-ietf-core-resource-directory-04

* XMPP IoT Discovery
** Base technology: IP + TCP
** Thing Registry can be searched for public Things and their metadata (various tags, e.g., location or serial number). A search is performed by providing one or more comparison operators in a search request to the registry.
** http://xmpp.org/extensions/xep-0347.html#search

* HyperCat
** Base technology: IP + TCP + HTTP
** HyperCat is an open, lightweight JSON-based hypermedia catalogue format for exposing collections of URIs. HyperCat catalogue may expose any number of URIs, each with any number of resource description framework-like (RDF-like) triple statements about it.
** http://www.hypercat.io/standard.html

* Push API
** Base technology: HTTP + web push protocol
** The Push API enables sending of a push message to a previously registered Service Worker of a web application via a push service, e.g. allowing the web application to resume on this device. The Push API makes it possible to discover, awaken and connect user devices.
** https://w3c.github.io/push-api/
** https://tools.ietf.org/html/draft-ietf-webpush-protocol-02

* SIR
** Base technology: IP + TCP + HTTP + XML
** Discussion paper at the Open Geospatial Consortium (OGC) and part of the Sensor Web Enablement (SWE) framework.
** Sensor Instance Registry (SIR) is a web service interface for managing the metadata and status information of sensors. Furthermore it is capable of automatically harvesting sensor metadata, and transforming the collected metadata sets into a homogeneous data model.
** https://portal.opengeospatial.org/files/?artifact_id=40609

* SPARQL Endpoints
** Base technology: IP + TCP + HTTP + RDF
** a SPARQL endpoint of a central triplestore accepts advanced queries (generally consisting of SELECT/WHERE statements) for RDF data.
** http://www.w3.org/TR/2013/REC-sparql11-overview-20130321/

* ''Research article'': "Mobile digcovery: A global service discovery for the IoT"
** A centralized infrastructure that allows registration of sensors. Employs 'digrectory' to handle different resources. Each directory is attached to a particular communication technology, such as NFC, IPv6 etc. A mobile app enables users to discover and access sensors. Discovery mechanism takes advantage of geolocation and context awareness.
** http://dx.doi.org/10.1109/WAINA.2013.261

* ''Research article'': "A discovery service for smart objects over an agent-based middleware"
** Indexes all smart objects connected to the registry. Indexing is done based on domains. Discovery process is based on searching the indices.
** http://dx.doi.org/10.1007/978-3-642-41428-2_23

* ''Research article'': "A Semantic Enhanced Service Proxy Framework for Internet of Things"
** A semantic based framework which uses the concept of service advertisement of a smart object. Authors argue that such a mechanism makes the service registration easier which in turn facilitates discovery. The advertisement contains a service metadata including name, id, endpoint, location and semantic annotation link.
** http://dx.doi.org/10.1109/GreenCom-CPSCom.2010.116

===4. Searching across Peers===
In peer to peer discovery, the directory is essentially distributed across the peers. This is often based upon distributed hash tables which maps the search space into a numeric range and then allocates servers to parts of that range. The technique works well for scale free networks. It requires Peers in the P2P overlay to host parts of the RD and to have full connectivity and certain computing power in order to forward overlay messages, keep a consistent DHT and routing tables in the node. P2P Overlays tolerate certain amounts of churn but it would be impractical for constrained devices to participate as full peers on the DHT.

* "RFC7650": CoAP usage for RELOAD
** Base technology: IP + UDP/TCP + CoAP
** CoAP Usage for [https://tools.ietf.org/html/rfc6940 RELOAD] allows CoAP nodes to store resources in a RELOAD peer-to-peer overlay, provides a lookup service, and enables the use of RELOAD overlay as a cache for sensor data. RELOAD is a DHT-based (Chord) P2P protocol of IETF.
** https://datatracker.ietf.org/doc/rfc7650/

* "IETF Draft": Distributed RD
** Base technology: IP + UDP/TCP + CoAP
** This document defines a Distributed Resource Directory (DRD) for Constrained Application Protocol (CoAP). This case uses raw DHT with no RELOAD dependencies.
** http://tools.ietf.org/html/draft-jimenez-distributed-resource-directory-00.html

* ''Research article'': "A Scalable and self-configurable architecture for service discovery in  the IoT"
** IoT gateways are backbones of the architecture. Gateways enable registration and un-registration of smart objects. A list of registered objects are maintained in a CoAP server. Service discovery is based on sending a GET request to ./well-known/core. In the distributed architecture several gateways are interlinked through two P2P overlays namely distributed local service (DLS) and distributed geographic table (DGT) to facilitate global service discovery.
** http://dx.doi.org/10.1109/JIOT.2014.2358296

===5. Accessing thing metadata===
Once a "service" has been discovered with the approaches above, next "resources" and/or general metadata access at thing level needs to be performed.

* CoRE Link Format
** Base technology: IP + UDP + CoAP
** lists URIs (links) for the resources hosted by the server, complemented by attributes about those resources and possible further link relations. A well-known relative URI "/.well-known/core" is defined as a default entry point for requesting the list of links about resources hosted by a server. 
** https://tools.ietf.org/html/rfc6690

* HATEOAS
** Base technology: IP + TCP + HTTP (typically)
** abbrv. for 'Hypermedia as the Engine of Application State'
** principle of REST architectures (not a standard)
** hypertext should be used to find your way through the API => client interacts with an application through hypermedia provided dynamically by application servers - no prior knowledge on how to interact, since ''links'' to resources are provided
** http://restcookbook.com/Basics/hateoas/

* SOS
** Base technology: IP + TCP + HTTP + SOAP etc.
** Standard by the Open Geospatial Consortium (OGC) and part of the Sensor Web Enablement (SWE) framework.
** Sensor Observation Service (SOS) is a Web service interface which allows querying sensor measurements as well as sensor metadata. Advanced spatial, temporal and thematic filtering is possible to query measurements.
** http://www.opengeospatial.org/standards/sos

===6. Semantic Based Discovery===
Several research articles using semantics for discovery can be found below.

* A web service discovery computational method for IOT system
** Zhou and Ma presents an ontology concept for vehicular sensors. The algorithm calculates semantic similarity, relativity and combines them to work out the maximum value of the required concepts of the web services. Then a matching degree is computed to find out the relevant web services. @[http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6664533]

* Semantic Enhanced Service Proxy Framework for Internet of Things
** The authors of @[http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=5724875] have introduced a semantic based framework which uses the concept of service advertisement of a smart object. They mention that such mechanism makes the service registration easier which in turn facilitates discovery. The advertisement contains a service metadata including name, id, endpoint, location and semantic annotation link.

* An evaluation of semantic service discovery of a U-city middleware
** Another semantic based service discovery is presented in @[http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=5440391]. It proposes a middleware which performs SD using semantic web technologies on the contextual information inferred from sensor data.