CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a 35 U.S.C. § 371 national stage application of PCT International Application No. PCT/EP2018/058870 filed on Apr. 6, 2018, the disclosure and content of which is incorporated by reference herein in its entirety.

TECHNICAL FIELD

The inventive concepts described herein relate to Internet of Things (IoT) devices, and in particular to registration of available resources in an IoT environment using a Resource Directory.

BACKGROUND

An Internet of Things (IoT) device may include one or more sensors that can be used to provide measurements of one or more quantities, such as environmental variables (e.g., temperature, humidity, ambient light, carbon monoxide levels, etc.), network variables (e.g., memory utilization, energy consumption, processor utilization etc.), or other measurable quantities, and transmit the measurements as data over a network to a network node that requests the data. As used herein, a “network node” or “node”, refers to any endpoint or device that has an address on a communication network, including, for example, a server, a client device, an IoT device, a sensor, an actuator, etc.

Referring toFIG. 1, an IoT environment100is illustrated. The IoT environment100generally includes one or more IoT devices20that may each include one or more sensors, such as temperature sensors, humidity sensors, light sensors, water sensors, etc. The IoT devices20are connected to a data communication network25, which may include one or more of a wireless data communication network, a wired network, a local area network (LAN), a wide area network (WAN), and/or any other data communication network. Thus, an “IoT environment” refers to any network environment including IoT devices that communicate with one another. The IoT environment may be further defined or limited based on a common protocol by which the devices communicate, a security layer or protocol utilized by devices on the network, and/or other factors, such as a defined geographical area or functionality, or any other characteristic.

A client device15that needs to obtain data, e.g., temperature data, that can be provided by an IoT device20may send a request through the network25to one of the IoT devices20asking for the IoT device20to take a measurement of the requested data and provide the measured data to the client device15. However, this assumes that the client device15knows the network address of an IoT device20that is suitably configured to measure the desired data and that is currently available to take the measurement and report the data to the client device15.

One problem faced by the client device15is that an IoT environment100may be highly variable, as IoT devices20may come online or go offline from time to time, such as when they transition into or out of sleep mode. To determine what IoT devices are currently available to provide a desired service, a client device15may conduct a process to discover which resources are currently available on the IoT network.

IoT devices are often considered “constrained” devices (or constrained nodes), as they may have limited resources in terms of processing power, memory, battery lifetime, bandwidth, etc. The Internet Engineering Task Force (IETF), which is a standard setting organization, has defined a new communication protocol suitable for constrained nodes (e.g., 8-bit microcontrollers with limited memory) called Constrained Application (CoAP) protocol and described in IETF RFC 7252, a new constrained wireless personal area network called IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) and described in IETF RFC 4919, and a new link format called CoRE Link Format described in IETF RFC 6690, among others.

The discovery of resources hosted by a constrained node is important in machine-to-machine applications where static interfaces may result in fragility. The discovery of resources hosted by a constrained node, their attributes, and other resource relations, is standardized in the IETF document draft-ietf-core-resource-directory and is referred to as “Resource Discovery.”

The main function of the Resource Discovery mechanism is to provide Universal Resource Identifiers (URIs, called links) for the resources hosted by the node, 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 an IoT device and thus performing Resource Discovery.

In many IoT environments, however, direct discovery of resources from constrained nodes, such as by directly querying known IoT devices using the relative URI “/.well-known/core”, may not be practical due to sleeping nodes or when a network does not support multicast traffic. This problem can be addressed by employing an entity called a Resource Directory10on the network25. Each IoT device20on the network25may register its presence and capabilities in the Resource Directory10. A client device can discover whether a particular type of IoT resource is available on the network25by querying the Resource Directory10. However, for the Resource Directory10to be useful as a resource discovery tool, it is important that the Resource Directory10maintain accurate and up-to-date information about what IoT devices20are available on the network25and what resources are available on those devices.

On the other hand, the world wide web consortium (W3C) standardization fora defines a meta-data format called a “Thing Description” (TD) that describes interactions provided by the IoT device. Thing Description files can be serialized in different formats such as the extensible markup language (XML) format. Each IoT device may have a unique Thing Description file that describes the interface that can be used by other devices to access the information of such IoT device. The Thing Description file associated with an IoT device may be shared by the IoT device with other devices upon request to facilitate interaction with the IoT device or can be stored in a third party server.

SUMMARY

A method according to some embodiments includes providing a Thing Description file for an Internet of Things, IoT, device, the Thing Description file including information describing a resource provided by the IoT device, mapping the Thing Description file to a Resource Directory registration command, and transmitting the Resource Directory registration command to a Resource Directory to register the resource in the Resource Directory.

Mapping the Thing Description file to the Resource Directory registration command may include constructing a POST request including a request command string and a payload, parsing the Thing Description file to obtain a resource name of a resource described by the Thing Description file, and providing the resource name as an end point, ep, parameter in the request command string of the POST request.

The method may further include obtaining a uniform resource identifier, URI, associated with the resource from a base field in the Thing Description file, and providing the URI as a context, con, parameter in the request command string of the POST request.

Mapping the Thing Description file to the Resource Directory registration command may further include parsing the Thing Description file to obtain a name of an interaction associated with the resource, a hyperlink associated with the interaction, and a media type associated with the hyperlink, and providing the name of the interaction, the hyperlink and the media type in the payload of the POST request.

Providing the name of the interaction, the hyperlink and the media type in the payload of the POST request may include parsing the hyperlink to obtain a pathname and a target, and converting the media type to a media type number.

The payload of the POST request may include the target obtained from the hyperlink, a content type, ct, field including the media type number, a resource type, rt, field including the name of the interaction, and an anchor field including the pathname obtained from the hyperlink.

Mapping the Thing Description file to the Resource Directory registration command may further include parsing the Thing Description file to obtain a plurality of resources.

Providing the names of the interactions, the hyperlinks and the media types in the payload of the POST request may include parsing the hyperlinks to provide respective pathnames and targets, and converting the media types to respective media type numbers.

The payload of the POST request may include for each of the plurality of interactions an opening tag including the target obtained from the hyperlink of the respective interaction, a content type, ct, field including the media type number of the respective interaction, a resource type, rt, field including the name of the respective interaction, and an anchor field including the pathname obtained from the hyperlink of the respective interaction.

The Thing Description file may be serialized in a JavaScript object notation (JSON) format, and the payload of the operations of the Resource Directory may be serialized in a CoRE Link Format.

Some further embodiments provide an Internet of Things, IoT, device adapted to provide a Thing Description file for the IoT device, the Thing Description file including a formatted record describing a resource provided by the IoT device, map the Thing Description file to a Resource Directory registration command, and send the Resource Directory registration command to a Resource Directory to register the resource in the Resource Directory.

Some further embodiments provide a computing device adapted to provide a Thing Description file for an IoT device, the Thing Description file including a formatted record describing a resource provided by the IoT device, map the Thing Description file to a Resource Directory registration command, and send the Resource Directory registration command to a Resource Directory to register the resource or resources in the Resource Directory.

Still further embodiments provide a computer program product including a non-transitory computer readable storage medium having computer readable program code embodied in the medium, the computer readable program code comprising computer readable program code configured to provide a Thing Description file for an IoT device, the Thing Description file including a formatted record describing a resource provided by the IoT device, map the Thing Description file to a Resource Directory registration command, and send the Resource Directory registration command to a Resource Directory to register the resource or resources in the Resource Directory.

Other systems, methods, and/or computer program products according to embodiments of the invention will be or become apparent to one with skill in the art upon review of the following drawings and detailed description. It is intended that all such additional systems, methods, and/or computer program products be included within this description, be within the scope of the present invention, and be protected by the accompanying claims.

