WO2013071949A1

WO2013071949A1 - Machine-to-machine communication

Info

Publication number: WO2013071949A1
Application number: PCT/EP2011/070064
Authority: WO
Inventors: Jouni MÄENPÄÄ; Jaime JIMÉNEZ
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2011-11-14
Filing date: 2011-11-14
Publication date: 2013-05-23

Abstract

According to a first aspect of the present invention there is provided method of operating a machine-to-machine network comprising a plurality of nodes, one or more of the plurality of nodes hosting one or more resources. The method comprises implementing a peer-to-peer signalling protocol in order to provide distributed caching for data produced by the resources and to provide resource discovery for the cached resource data.

Description

MACHINE-TO-MACHINE COMMUNICATION

Technical Field The present invention relates to methods and apparatus for Machine-to-Machine communication. More particularly, the invention relates to methods and apparatus for implementing distributed data caching and resource discovery in a Machine-to- Machine network. Background

The rapid growth in the number of IP-enabled embedded devices is giving rise to the wide adoption of Machine-to-Machine (M2M) technologies. The basic concept behind M2M is the use of a device to capture an event, which is relayed through a network to an application or one or more other devices. The event can trigger an action that is carried out by the device itself, often in coordination with other devices in the network, without the need for human intervention.

M2M networks consist of constrained devices such as wireless sensors and actuators. The devices are referred to as constrained because they typically have limited resources such as battery power, processing capacity, and memory. For example, IETF draft-schoenw-netconf-light-00 classifies constrained devices based on the memory they have available. Similarly, IETF draft-ietf-core-coap-07 notes that constrained nodes often have 8-bit microcontrollers with small amounts of ROM and RAM. In particular, constrained devices are typically designed to operate during extended periods of time (months or even years) powered only by batteries. To enable long battery life, the devices need to have low power consumption and are typically configured to have longer periods of inactivity (sleep mode) than traditional devices.

The constrained nature of the devices and the need to preserve battery power is in contradiction with the requirements of most M2M applications that typically need immediate access to the information (e.g. sensor readings) produced by M2M devices. In particular, due to the need to optimize battery life, most constrained devices may only wake up periodically, which may therefore mean that an application may not be able to obtain data from such a device as and when it is required (due to the sensor being in sleep mode).

Caching at least partially mitigates against the problem of retrieving data from sleeping devices by providing that, instead of sending a query to a sleeping device/node, a cache is accessed to get the most recent data provided by/obtained from the device. In this regard, the Constrained Application Protocol (CoAP), defined in I ETF draft-ietf-core-coap-07, provides a simple caching mechanism in which the latest response sent by a device can be stored by another node (e.g. a CoAP proxy) in the network. If new requests arrive, the cached response is returned without the need to contact the device itself. CoAP is a specialized web transfer protocol for use with constrained networks and nodes for M2M applications, which realizes the Representational State Transfer (REST) architecture for the most constrained nodes, such as sensors and actuators, and networks. CoAP can be used not only between nodes on the same constrained network but also between constrained nodes and nodes on the I nternet. The latter is possible since CoAP can be translated to Hypertext Transfer Protocol (HTTP) for integration with the web.

However, the simple caching mechanism provided by the CoAP protocol has a number of limitations. For example, these limitations include:

- The mechanism stores the entire CoAP response, as opposed to only storing the data included in the response. This is sub-optimal as it would be more efficient to cache/store only the data itself.

- The mechanism can only cache the most recent data received from a device. A superior caching mechanism would also be able to store at least a few previously received items of data, and possibly even a large or unlimited amount of time series data.

- Given that the caching is implemented using the CoAP protocol, the cache(s) need to be located along the path taken by the CoAP signalling sent to and/or from the device. A more advanced caching mechanism would be able to store data anywhere in the network, such as in a distributed database.

- Given that the caching is implemented using the CoAP protocol, the simple act of fetching the most recent data from the cache involves resolving CoAP URI s to transport addresses (i . e. rendezvous), constructing the CoAP application messages, routing the messages towards the device (or its CoAP proxy), and so forth. A more efficient caching mechanism would be able to return cached data without the need to rely on CoAP signalling and without the need for the caches to understand CoAP. Furthermore, existing caching solutions for M2M networks are limited to storing data in central locations (such as a proxy). However, the use of central caches is not an attractive option for all M2M systems/applications. This is especially true for autonomous, distributed M2M networks that try to minimize the need for investment in centralized application servers, proxies, and data centres.

Summary

According to a first aspect of the present invention there is provided method of operating a machine-to-machine network comprising a plurality of nodes, one or more of the plurality of nodes hosting one or more resources. The method comprises implementing a peer-to-peer signalling protocol in order to provide distributed caching for data produced by the resources and to provide resource discovery for the cached resource data. The present invention provides an advanced, efficient mechanism for distributed caching of data produced by the resources of a machine-to-machine network, whilst also providing a decentralised means of achieving resource discovery/rendezvous.

The peer-to-peer signalling protocol may be the Resource Location And Discovery (RELOAD) Base Protocol.

The plurality of nodes can include both constrained devices and non-constrained devices. Each constrained device may then host one or more resources. Each of the non-constrained devices can be configured to act as a peer of a peer-to-peer overlay network, the peers of the peer-to-peer overlay network providing a distributed cache for resource data. One or more of the constrained devices may then be configured to act as a client of the peer-to-peer overlay network.

Each of the constrained devices may be configured to be active periodically, such that the resources hosted by each device will periodically produce and send data for caching in the peer-to-peer overlay network.

Within the peer-to-peer overlay network, the nodes can each be identified by a node identifier and the resource data produced by a resource and cached in the peer-to- peer overlay network can be identified by a resource identifier. The resource data produced by a resource can be stored in the peer-to-peer overlay network as a resource record, and a resource identifier may then be used to store and retrieve resource data in the resource record. The resource record of a resource may then include one or more or a list of the peers of the peer-to-peer overlay network through which the resource can be reached, a value for the most recent data produced by the resource, a validity period for the most recent data, an indication as to when the most recent data was produced, an indication as to when the most recent data was cached, and an indication of the current status of the resource. A resource record may also include a resource identifier identifying a time series record of data previously produced by the resource, the time series record also being stored in the peer-to-peer overlay network. A resource record may also include the node identities of one or more nodes that are to be contacted by the resource when the node hosting the resource is next active.

A node record identifying the resources hosted by a node may also be stored in the peer-to-peer overlay network, and the node identifier of the node can be used to store and retrieve the node record. A node record of a node may further comprises one of more of an indication of the duration of inactivity of the node, an indication of the remaining power of the node, and, for each resource hosted at the node, an indication of the type of resource.

A machine-to-machine-suitable signalling protocol may be used for signalling between one or more of the constrained devices, and between one or more of the constrained devices and the non-constrained devices. The machine-to-machine- suitable signalling protocol could be the Constrained Application Protocol (CoAP).

The nodes in the machine-to-machine network, the resources hosted by the nodes, and the resource data cached in the machine-to-machine network may be addressed using CoAP Uniform Resource Identifiers (URIs). The peers of the peer-to-peer overlay network may then be configured to map a CoAP U RI to one of a node identifier and a resource identifier within the peer-to-peer overlay network.

According to a second aspect of the present invention there is provided a method of operating a co nstra i ned d evi ce with i n a m ach i n e-to-machine network, the constrained device hosting one or more resources and being configured to be active periodically. The method comprises, when the constrained device is active, each of the one or more resources hosted by the constrained device producing resource data and sending the resource data to a non-constrained device in the machine-to- machine network for caching.

The constrained device may be configured to act as a Constrained Application Protocol (CoAP) end point and to use a CoAP message to send resource data for caching in the network. Alternatively, the constrained device could be configured to act as a client of a peer-to-peer overlay network, the non-constrained device acting as a peer of the peer-to-peer overlay network, and resource data would then be sent to the non-constrained device for caching in the peer-to-peer overlay network. In this case, the constrained device could be configured to act as a client of a Resource Location And Discovery (RELOAD) Base Protocol overlay network and to use a RELOAD message to send the resource data for caching in a RELOAD overlay network.

According to a third aspect of the present invention there is provided a method of operating a non-constrained device within a machine-to-machine network, the machine-to-machine network including constrained devices each hosting one or more resources. The method comprises configuring the non-constrained device to act as a peer of a peer-to-peer overlay network, the peers of the peer-to-peer overlay network providing a distributed cache for resource data produced by the resources. The non-constrained device could be configured to act as a peer of a Resource Location And Discovery (RELOAD) Base Protocol overlay network. The method may then further comprise receiving a RELOAD message from a constrained device, the received RELOAD message including resource data for caching, and sending a RELOAD message to cache the resource data in the RELOAD overlay network. The method may also further comprise configuring the non-constrained device to act as a Constrained Application Protocol (CoAP) end point, receiving a CoAP message from a constrained device, the CoAP message including resource data for caching, and sending a RELOAD message to cache the resource data in the RELOAD overlay network.

The method may further comprise receiving a message from a node that is external to the machine-to-machine network, the message requesting data from an identified resource, and sending a RELOAD message to retrieve resource data produced by the identified resource that is cached in the RELOAD overlay network. The message from the external node may identify the resource using a CoAP Uniform Resource Identifier (URI) and the non-constrained device may be configured to map the CoAP URI to a resource identifier.

According to a fourth aspect of the present invention there is provided a constrained device configured to operate within a machine-to-machine network. The constrained device comprises one or more resources hosted by the constrained device, each of the one or more resources being configured to produce resource data, and a transmitter for sending the resource data to a non-constrained device in the machine- to-machine network for caching.

The constrained device may be configured to act as a Constrained Application Protocol (CoAP) end point and may further comprise a processor configured to generate a CoAP message that includes resource data for caching in the network. The constrained device may be configured to act as a client of a peer-to-peer overlay network, the non-constrained device acting as a peer of the peer-to-peer overlay network, and the transmitter may be configured to send the resource data to the non- constrained device for caching in the peer-to-peer overlay network. In this case, the constrained device may be configured to act as a client of a Resource Location And Discovery (RELOAD) Base Protocol overlay network and may further comprise a processor configured to generate a RELOAD message that includes resource data for caching in a RELOAD overlay network.

According to a fifth aspect of the present invention there is provided a non- constrained device configured to operate within a machine-to-machine network, the machine-to-machine network including constrained devices each hosting one or more resources, wherein the non-constrained device is configured to act as a peer of a peer-to-peer overlay network, the peers of the peer-to-peer overlay network providing a distributed cache for resource data produced by the resources.

The non-constrained device may be configured to act as a peer of a Resource Location And Discovery (RELOAD) Base Protocol overlay network. The non- constrained device may then further comprise a receiver for receiving a RELOAD message from a constrained device, the received RELOAD message including resource data for caching, and a transmitter for sending a RELOAD message to cache the resource data in the RELOAD overlay network.

The non-constrained device may also be configured to act as a Constrained Application Protocol (CoAP) end point, and may further comprise a receiver for receiving a CoAP message from a constrained device, the CoAP message including resource data for caching, a processor configured to generate a RELOAD message in order to cache the resource data in the RELOAD overlay network, and a transmitter for sending a RELOAD message to cache the resource data in the RELOAD overlay network.

The non-constrained device may further comprise a receiver for receiving a message from a node that is external to the machine-to-machine network, the message requesting data from an identified resource, and a transmitter for sending a RELOAD message to retrieve resource data produced by the identified resource that is cached in the RELOAD overlay network. The non-constrained device may then also further comprise a receiver for receiving a RELOAD response message, the RELOAD response message including the resource data produced by the identified resource and that has been cached in the RELOAD overlay network; and a transmitter for sending a response message to the external node, the response message including the resource data retrieved from the RELOAD overlay network

The non-constrained device may further comprise a processor for mapping a CoAP Uniform Resource Identifier, URI, included in the message from the external node that identifies the resource to a resource identifier. According to the present invention there is provided a machine-to-machine network comprising a plurality of nodes, one or more of the nodes hosting one or more resources. The plurality of nodes can include both constrained devices and non- constrained devices. The non-constrained devices are configured to act as peers of a peer-to-peer overlay network. The non-constrained devices may therefore be configured to implement a peer-to-peer protocol, such as RELOAD. The constrained devices may be configured to communicate using a machine-to-machine suitable signalling protocol . The constrained devices may therefore be configured to implement a machine-to-machine suitable signalling protocol, such as CoAP. In this case, the non-constrained devices will also be configured to implement the machine- to-machine suitable signalling protocol in order to communicate with the constrained devices. Alternatively, one or more of the constrained devices may be configured to act as clients of a peer-to-peer overlay network. In this case, the one or more constrained devices may be configured to implement a peer-to-peer protocol, such as RELOAD.

Brief Description of the Drawings

Figure 1 illustrates schematically an example of a M2M network architecture suitable for implementing the methods described herein;

Figure 2 illustrates an example of signalling involved when accessing resource data stored in a peer-to-peer overlay network;

Figure 3 is a flow diagram illustrating the process implemented when accessing resource data stored in a peer-to-peer overlay network;

Figure 4 illustrates an example of signalling involved when a storing resource data in a peer-to-peer overlay network;

Figure 5 illustrates schematically an example of a constrained device suitable for implementing the methods described herein; and

Figure 6 illustrates schematically an example of a non-constrained device suitable for implementing the methods described herein.

Detailed Description

In order to overcome, or at least mitigate, the problems associated with the existing caching solutions for M2M networks, it is proposed here to make use of a new architecture for M2M networks that is based on the combination of the Constrained Application Protocol (CoAP) and the REsource Location And Discovery (RELOAD) Base Protocol. RELOAD is a generic Peer-to-Peer (P2P) signalling protocol that is currently being standardized in the Peer-to-Peer Session Initiation Protocol (P2PSIP) working group of the I ETF, and has been most recently defined in I ETF draft-ietf- p2psip-base-18. RELOAD uses the Chord Distributed Hash Table (DHT) algorithm as the default algorithm to organize participating nodes in a P2P overlay network. RELOAD therefore provides a generic, self-organizing P2P overlay network service, and nodes can use the overlay to route messages to other nodes and to store and retrieve data.

By using the P2P overlay network provided by the RELOAD protocol as a distributed peer-to-peer cache for data provided by M2M devices/nodes, this solution removes the need for centralised caches. In addition, in current CoAP-based M2M systems the resource discovery/rendezvous process (i.e. the locating and retrieving of data/information) requires that a CoAP server register its resources with a central server, known as a resource directory. A CoAP client must then query/poll the resource directory to locate/discover a resource hosted by a CoAP server. CoAP- based M2M systems therefore also suffer from the drawback that such a centralised service for resource discovery/rendezvous needs to be configured and incurs costs associated with its maintenance. However, the use of the P2P overlay network provided by the RELOAD protocol also removes the need for such a centralised mechanism for resource discovery/rendezvous. There will now be described methods and apparatus for implementing a RELOAD overlay network to provide a resource discovery/rendezvous service and a distributed cache for data produced by nodes in a M2M network. In this regard, the nodes in the M2M network are assumed to be heterogeneous; in so far as the network nodes include both constrained devices and non-constrained devices. I n this context, a non-constrained device can be considered as referring to devices having Internet connectivity and a reasonable amount of processing power, memory, and battery capacity. In this example, the non-constrained devices are configured to act as peers of a peer-to-peer overlay network, thereby providing/forming the peer-to-peer overlay network that provides the resource discovery/rendezvous service and the caching of data produced by the nodes within the network. Figure 1 illustrates schematically an example of a M2M network architecture suitable for implementing the methods described herein. According to this example, the M2M network can include several different types of nodes, including Proxy Nodes, Wide- area Nodes, Local Nodes, Gateway nodes and Monitoring and Control Nodes. The Proxy Nodes, Wide-area Nodes and Gateway nodes are non-constrained devices. In contrast, the Local Nodes are constrained devices (e.g. M2M devices hosting resources such as sensors, actuators etc). In this example, Proxy Nodes (PNs) are devices having dual interfaces; both a cellular radio interface and a short-range Wireless Sensor Network (WSN) radio interface. Wide-area Nodes (WNs) have only a cellular radio interface. Both WNs and PNs have Internet connectivity through the cellular radio access network, and are configured to act as peers in a RELOAD overlay network. PNs and WNs are deployed in the wide area, such that distances between them are typically in the order of kilometres.

Each Local Node (LN) is part of a Wireless Sensor Network (WSN) that is only capable of operating within a restricted geographical area. Examples of such WSNs include ZigBee networks and 6LowPAN networks. LNs have only a short-range WSN radio interface and therefore rely on PNs for wide area connectivity, that is, for connecting to nodes outside of their WSN. This also means that all the traffic to and from the LNs goes through a PN . Since LNs are constrained devices, they have limited resources and typically spend extended periods of time in sleep mode, waking up only periodically to send and receive data. Whilst it is generally the LNs that will host one or more resources (e.g. sensors and/or actuators), the PNs and WNs may also host one or more resources.

A Gateway (GW) node acts as a peer in a RELOAD overlay network, and provides web applications (i.e. HTTP clients) with access to the WSNs that are interconnected by the RELOAD overlay network. The HTTP client can be, for instance, a Monitoring and Control Node (MCN) that is interested in accessing the data from the sensors hosted by the LNs, PNs, and WNs. The M2M network architecture illustrated in Figure 1 uses CoAP as the M2M application protocol for providing and accessing data from the resources of the M2M network. In this example, all the above-mentioned nodes, including PNs, WNs, LNs, GWs, and MCNs support CoAP, whilst only the non-constrained devices support the RELOAD protocol. In this regard, the PNs, WNs, GWs, and MCNs are configured to act as peers in a RELOAD overlay network, and it is this RELOAD overlay network that is used to provide a rendezvous/resource discovery mechanism for the CoAP endpoints. Furthermore, the RELOAD overlay network is also used to provide a distributed cache for resource data/information as will be described below In this example, the constrained LNs are assumed not to be capable of supporting RELOAD due to their limited resources, and are configured as CoAP endpoints. The LNs therefore use CoAP to communicate with other nodes in the network, and the PNs are configured to map between CoAP and the RELOAD protocol. However, as an alternative, it may be possible for at least some of the constrained devices to be configured to act as clients of the RELOAD overlay network, such that they are able to store data in and retrieve data from the overlay network using the RELOAD protocol, but do not themselves participate in routing or data storage for the overlay network. I n the combined CoAP and RELOAD architecture, all nodes and resources are addressed using CoAP URIs. An example of a CoAP URI is as follows:

coap : / / sensorl . example . com/ temperature

This URI points to resource temperature in sensorl located in the domain example.com.

The RELOAD overlay supports rendezvous by mapping between CoAP URIs and both Node-IDs and Resource-IDs. In doing so, the non-constrained devices (i.e. the peers in the RELOAD overlay network) and the constrained devices can be identified using the Node-IDs, and the resources and resource data can be identified using Resource-IDs. As an example, for a resource that is identified by the CoAP URI given above, a record containing the data generated by that resource would be stored in the RELOAD overlay network under a key (a.k.a. , Resource-ID) that is calculated by taking a SHA-1 hash over the URI:

hash ( " coap : / / sensorl . example . com/ temperature" ) In order to implement caching, whenever a LN hosting one or more resources wakes up, the LN sends the most recent resource data from its resources to its PN, which then stores the data in the RELOAD overlay network in a resource record that is identified by the Resource-ID. For example, the resource record can store that data using the SensorRecord structure defined below:

struct {

Nodeld destination list[];

CachedValue most recent value;

integer validity time;

/* extensions

} SensorRecord;

In this data structure definition, the type of the data field is defined on the left-hand side and the name of the field on the right-hand side. Square brackets after the name of the field indicate that the field contains an array of values. This data structure could be implemented using the StoredData structure defined by the RELOAD protocol. However, the RELOAD protocol could also be extended in order to standardise the format of the SensorRecord data structure.

For example, if a LN that is located in a wireless sensor network wsn.net, and that is served by a proxy node PN, wishes to make a resource called temperature addressable in the RELOAD overlay network, the PN stores the following resource record (i.e., <key, value> pair) in the overlay:

key = hash ( "coap : //In . wsn . net/temperature" )

value = SensorRecord

Among other things, the SensorRecord can be used by other nodes in the RELOAD overlay network to determine how to reach the resource/sensor, as it contains the contact information of the resource for rendezvous/resource discovery purposes. As indicated above, the SensorRecord structure contains three fields: destinationjist, most_recent_value, and validity_time. Further, the structure can be extended with additional fields, as indicated by the / * extensions * / comment within the structure. The destinationjist field is an array of Node-IDs and contains the list of Node-IDs through which the resource/sensor can be reached in the overlay (i.e. that can be used to route messages to the LN hosting the resource). For example, the first entry in the destination list could be the Node-ID of the PN that provides wide area connectivity for the LN hosting the resource. The second entry would then be the Node-I D of the LN. Together the two entries would indicate to a node wishing to send a message to the LN that, in order to reach the LN, the node first needs to route the message to the PN, which will then take care of routing the message to the LN. The validity_time field indicates how long (e.g. in seconds) the most recent data from the resource/sensor will be valid. The most_recent_value field stores the most recent data generated by resource (i.e. it is used for caching this value). By storing the most recent resource data in the SensorRecord, this data will be available to other nodes and applications even if the resource itself is asleep. Furthermore, if a node is only accessing the SensorRecord in order to obtain data from the resource, then the data cached in the SensorRecord could be sufficient, such that there is no need to actually contact the resource or it's PN.

In the SensorRecord, the most_recent_value is defined as being of type CachedValue, which is defined as follows:

struct {

integer timestamp;

opaque value [ ] ;

} CachedValue;

Inside the CachedValue structure, the timestamp field contains an integer value indicating the time at which the resource data was generated. The value field contains the actual resource data, and is an opaque sequence of bytes. In order to access the SensorRecord within the RELOAD overlay network a node makes use of the key for the SensorRecord, which is the Resource-ID of the resource (i.e., a hash calculated over the CoAP URI of the resource as described above). The RELOAD overlay network can also be used for storing time series data provided by/obtained from the resources. One way to achieve this is to store the time series data directly within the SensorRecord structure. However, as this would increase the size of the structure, and given that not all applications may be interested in the time series data, a better way to implement the caching of time series data is to store, within the SensorRecord, a pointer to (i.e. Resource-ID) another record that contains the time series data. This other record containing the time series data is referred to herein as the TimeSeriesRecord structure. In order to implement the pointer with the SensorRecord, the SensorRecord structure can be extended by adding one extra field within the / * extensions * / part of the structure. This field can take the form:

Resource ld time series data ;

In this field, the time_series_data field contains the Resource-ID of the TimeSeriesRecord structure that contains the time series data from the resource/sensor. This record is typically stored by an overlay node (i.e. non- constrained device) different to the one that is storing the SensorRecord.

In the TimeSeriesRecord structure, the time series data is stored using the dictionary data model defined in the RELOAD protocol, wherein a dictionary is a set of opaque values indexed by an opaque key with one value for each key. In other words, the data is stored as an array of <key, value> pairs. In the TimeSeriesRecord, the key of each record is the timestamp and the values are CachedValue structures (defined above).

I n addition, a single constrained device (i.e. LN) may have multiple resources attached to it. Therefore, rather than storing device-level/node-level data (i.e. data that relates to the device/node) inside the SensorRecord of each resource, it is more efficient to store this device-level/node-level data in its own record device/node record, referred to here as a DeviceRecord. The DeviceRecord structure contains, as a minimum, a list of the resources that the node is hosting, and can therefore have following structure:

struct {

Sensor sensors [ ] ;

/ * extensions * / } DeviceRecord;

The DeviceRecord contains a field called sensors which is an array of Sensor data types. The Sensor data type contains the following information:

struct {

integer sensor type;

Resourceld sensor id;

/* extensions */

} Sensor;

The sensor type is an integer identifying the type of the resource. Table 1 below gives some examples of possible values for the sensorjtype field. The sensorjd contains the Resource-ID of the resource's SensorRecord in the overlay. It allows a node fetching the DeviceRecord to also fetch the SensorRecords of the device's resources. The key under which the DeviceRecord is stored in the RELOAD overlay network is the device's Node-ID. The benefit of using the Node-I D is that, as the Node-ID is also stored in the SensorRecord structures, any node fetching a SensorRecord can use the Node-ID to fetch the DeviceRecord of the node/device, and thereby learn which other resources the node/device identified by that Node-ID is hosting.

For some applications, it may also be useful to be able to learn the wake-up schedule of a node/device hosting one or more resources. The application can then use this information to determine when new data will be available from the resources of the device. For instance, the application could then schedule a new data lookup to occur immediately after the next time the resource is due to wake up. To enable this kind of behaviour, the DeviceRecord structure can be extended with one additional field placed in the / * extensions * / part of the structure, in which this field can take the form:

integer duration of inactivity;

The duration_of_inactivity field can then indicate the duration of the resource's sleeping period (e.g. in seconds). Based on the timestamp of the most_recent_value (which therefore indicates when the device most recently woke up), the contents of the validity field, and the duration_of_inactivity field, an application fetching the DeviceRecord can determine whether it can still use the most recent data from the device's resources. As an example, the application could use this information to determine that the data is recent enough. As a further example, the application could also use this information to determine that it would be appropriate to schedule a new lookup if new data will be available shortly.

Furthermore, in some cases it may be useful for a node/device hosting one or more resources, or for a node maintaining the SensorRecord on behalf of another node/device, to know who has been accessing the record while the node/device was sleeping. To enable this, the SensorRecord can be extended by adding a new field in the / * extensions * / part of the record, in which this field can take the form:

ContactRequest nodes to contact [] ;

The nodes_to_contact field contains an array of ContactRequest structures that could be defined to take the form:

Struct {

Nodeld node to contact;

integer type of action;

/* extensions */

} ContactRequest;

The node_to_contact field could then contain the Node-ID of a node that wants to get information about the resource to which the SensorRecord is related. The type_of_action field specifies the type of action that should be performed when the resource wakes up. Table 2 below gives some examples of possible values for the type_of_action field.

As an example, a node that wishes to get information from a resource may learn, based on the resource's SensorRecord, that the resource is currently sleeping and that the value cached in the SensorRecord is no longer valid. Thus, the node can store a new ContactRecord entry containing its own Node-ID in the nodes_to_contact array of the SensorRecord. When the resource wakes up and the SensorRecord is updated, the node storing the SensorRecord checks the list of ContactRecord entries inside the SensorRecord. It will then send a notification to all the nodes who have stored ContactRecord entries within the SensorRecord, indicating to them that new data is available (or performs any other action specified in the type_of_action field).

The resource and node/device records stored in the distributed cache provided by the RELOAD overlay network can also be extended to include any other items of data or information that may be of use. For example, the DeviceRecord structure could be extended by adding an additional field to the /* extensions * / part of the structure, in which this field can take the form:

Integer remaining battery life;

This field could then be used to store information about the remaining battery capacity of the node/device. Depending on the application, this may contain the percentage of battery capacity left, the remaining energy, or an estimate of the length of time (e.g. in seconds) for which node/device can operate with the remaining battery capacity. As an example, a monitoring application (e.g. a MCN) could use this information to issue alarms so that the operator of the network can send personnel to replace the battery of the device if the remaining battery capacity is low.

By way of further example, the SensorRecord structure could be extended by adding an additional field to the /* extensions * / part of the structure, in which this field can take the form:

Opaque status;

This field could then be used to store information indicating the current status of the resource. For example, in the case of a sensor, the possible status value could include malfunction, permanently_offline, everything_ok, awake, asleep etc. In the case of an actuator, this field could alternatively be used to store information such as valve_open or valvejclosed. As an example, the status information could then be used by an application to monitor the current status of a resource in order detect any malfunction or erroneous behaviour.

I n a d d i ti o n to p rov i d i n g d i st ri b u te d m e c h a n i s m s fo r i m p l e m e n t i n g rendezvous/resource discovery and caching for an M2M network, the RELOAD protocol could be further extended to provide that processed data can be requested from the nodes of the RELOAD overlay network, and that the nodes of the RELOAD overlay network can respond to such requests with data that has been processed accordingly. By way of example, a given TimeSeriesRecord may contain a large number of CachedData entries, and it may not always be desirable and/or feasible for a node/application that is interested in the data to fetch the entire record from the RELOAD overlay network. For example, a node may only be interested in getting the average of the values within the TimeSeriesRecord. In this case, rather than fetching the entire TimeSeriesRecord, which may contain perhaps tens of thousands of entries, and calculating the average locally, it is more efficient if the node can simply ask the node storing the TimeSeriesRecord to calculate the average and return the calculated average in a RELOAD response. To allow a node to perform statistical operations (e.g., getting the average, standard deviation, or median) on a TimeSeriesRecord, the RELOAD Fetch (i.e. , lookup) request, defined in I ETF draft- ietf-p2psip-base-18, can be extended with a new field statistical_operation. Table 1 below gives some examples of possible values for the statistical_operation field.

Consequently, if a node wishes to learn the average of the values within a given TimeSeriesRecord, i t can send a RELOAD Fetch request addressed to the Resource-ID of the record. In this example, the node would be required to add a statistical_operation field to the Fetch request and set the field of the value to 1. Then, when the node storing the TimeSeriesRecord receives the Fetch request, it would be required to detect the statistical_operation field, and thereby trigger the node to calculate the average from the stored data, and return the calculated average in a Fetch response. In doing so, the response will only contain the average and not the entire TimeSeriesRecord.

In some cases it may also be beneficial to limit the size of a single TimeSeriesRecord structure, for instance, to optimise the distribution of the cached data among the nodes in the RELOAD overlay network or to limit the size of Fetch responses. In this case, the time series data from a given resource can be split into multiple TimeSeriesRecord structures that are linked to each other. This can be achieved by providing that a node that wants to add a new entry (i.e. CachedValue) into the TimeSeriesRecord of a given resource, checks the size of the record, and compares the size of the record against a predefined threshold/size limit. In order to check the size of the record, a node could make use of the statistical_operation field defined above in order to request this information from overlay network. If the record exceeds the predefined threshold/size limit, then the node would be configured to create a new TimeSeriesRecord structure and place the new entry within it (as the first entry). The node would then store the Resource-ID of the new (second) TimeSeriesRecord structure inside the pre-existing (first) TimeSeriesRecord structure. This effectively forms a linked list of TimeSeriesRecord structures stored in the overlay network. Another node wishing to fetch the entire time series data would then fetch the first TimeSeriesRecord by using the Resource-ID stored in the SensorRecord of the sensor of interest. The node could then fetch the second TimeSeriesRecord by following the (linked list) pointer contained within the first TimeSeriesRecord. If further records have also been generated for the resource, then a third record could be fetched using a pointer contained in the second record, and so on.

Figure 2 illustrates an example of signalling involved when a Monitoring and Control Node (MCN) wishes to access resource information from a Local Node (LN) that is not itself a direct part of the RELOAD overlay network. In this example, the MCN is a Hyper Text Transfer Protocol (HTTP) client located in the web. A proxy node (PN1) is responsible for connecting the LN to the RELOAD overlay network. A Gateway Node (GW) is also part of the RELOAD overlay network and acts as a HTTP/CoAP proxy mapping from HTTP to CoAP. The GW acts as a first point of contact in the RELOAD overlay network for external nodes (such as the MCN) wishing to retrieve data from the overlay network. The GW uses the RELOAD overlay network for rendezvous/resource discovery. The rest of the peers in the overlay are PNs that might be serving different LNs. The node responsible for the contact record of the LN is PN3.

In step A1 of Figure 2, the MCN sends a HTTP GET request to the GW. The purpose of the HTTP GET is to retrieve the latest temperature reading from a sensor (sensorl) hosted by the LN. The HTTP GET is addressed to the CoAP URI of the sensor, "coap //sensor1.ln.wsn.net/temperature" . Upon receiving the HTTP GET, the GW hashes the CoAP URI to get the Resource-ID of the SensorRecord of sensorl. Next, the GW creates and sends a RELOAD Fetch request into the RELOAD overlay network. This RELOAD Fetch request is routed, according to the RELOAD protocol, towards the node responsible for the Resource-ID, which in this example is PN3. In step A2, the Fetch is routed to PN3 via PN2 using normal overlay routing. In step A3, the Fetch reaches PN3.

Once PN3 receives the Fetch request, PN3 replies with a RELOAD Fetch 200 OK response, which contains the SensorRecord of the LN. In step A4, the response is routed back along the same path as the request, via PN2. Once the GW receives the Fetch 200 OK response, it can investigate the timestamp and validity_time fields included in the SensorRecord. If these fields indicate that the most_recent_value is still valid, the lookup is determined to be complete/successful and the GW returns a HTTP 200 OK answer with the sensor data immediately to the MCN. Note that in this case there is no need to contact neither the LN nor the PN1 since the data that was being searched for was already found from the SensorRecord during the rendezvous/resource discovery procedure. Alternatively, if the most_recent_value is no longer valid, the GW has multiple options to choose from. Firstly, it can use the ContactRequest extension defined above to store a ContactRequest within the LN's SensorRecord. In doing so, the GW will be informed when the LN hosting the resource has new data available. Secondly, the GW can use the extension duration_of_inactivity defined above to determine when the LN hosting the resource is next due to wake and thereby schedule a new Fetch to occur at that time or shortly after. Thirdly, the GW can use the destination list in the LN's SensorRecord to establish a regular CoAP association with PN 1 , and poll or observe for new data on the LN using CoAP signalling. In this context, a CoAP association refers here to a direct UDP connection carrying CoAP signalling between the GW and PN 1 . To establish a direct CoAP connection, the GW would send a RELOAD Attach request across the overlay to PN 1 . The purpose of an Attach request is to set up a direct UDP connection between the nodes. Once the direct connection has been set up, CoAP messages can be sent on the connection. This third alternative is the least efficient option, especially if the GW is only interested in fetching a single value from the LN. However, this option may be preferable if the MCN wants to establish a long-term relationship with the LN.

Figure 3 is a flow diagram illustrating the process of an MCN getting information from a sensor in accordance with the methods detailed above. Figure 4 illustrates an example of signalling involved when a Local Node (LN) stores data at the node that is responsible for the contact record of the LN, which in this example is PN3. Every time the resource hosted at the LN awakes from sleep mode, the LN will inform PN1 , which is the PN that provides the LN with wide area connectivity, using CoAP signalling, as shown in step B1 of Figure 4. This will trigger PN1 to send a RELOAD Store request to the peer responsible for the LN's SensorRecord (i.e. PN3), as shown in step B2 of Figure 3. Alternatively, if the LN has enough resources to run the RELOAD client protocol, then the LN could use the RELOAD protocol to communicate with PN1 instead of CoAP.

Figure 5 illustrates schematically an example of a constrained device 1 suitable for implementing the methods outlined above. The constrained device 1 can be implemented as a combination of computer hardware and software, and is part of a machine-to-machine network in which a non-constrained device provides the constrained device 1 with wide area access. The constrained device 1 comprises one or more resources 2, a processor 3, a memory 4, a transmitter 5 and a receiver 6. For example, each of the one or more resources 2 can be a sensor or actuator. The memory 4 stores the various programs/executable files that are implemented by the processor 3, and also provides a storage unit for any required data. However, as a constrained device, the processing capacity and memory of the device will be limited. The programs/executable files stored in the memory 4, and implemented by the processor 3, include a CoAP or RELOAD protocol unit 7. For example, the CoAP/RELOAD protocol unit 7 is responsible for generating messages including the data produced by the one or more resources 2 for caching in the network. The constrained device 1 will be configured to act as a CoAP end-point if it is provided with a CoAP protocol unit, or will be configured to act as a RELOAD client if it is provided with a RELOAD protocol unit. The transmitter 5 is configured to send the CoAP/RELOAD messages generated by the CoAP/RELOAD protocol unit 7 to a non- constrained device that provides wide area access to the constrained device 1.

Figure 6 illustrates schematically an example of a non-constrained device 8 suitable for implementing the methods outlined above. The non-constrained device 8 can be implemented as a combination of computer hardware and software, and is part of a machine-to-machine network in which the non-constrained device 8 provides the wide area access to one or more constrained devices, each of the constrained devices hosting one or more resources of the machine-to-machine network. The non-constrained device 8 comprises a processor 9, a memory 10, a receiver 1 1 and a transmitter 12. The memory 10 stores the various programs/executable files that are implemented by the processor 9, and also provides storage for any required data. For example, the memory can include a resource data storage unit 13 for storing resource data that has been cached in the network. The programs/executable files stored in the memory 10, and implemented by the processor 9, include a CoAP protocol unit 14 and a RELOAD protocol unit 15. For example, the CoAP protocol unit 14 is responsible for processing CoAP messages received from a non- constrained device that includes resource data that is to be cached in the network. Similarly, RELOAD protocol unit 15 is responsible for processing RELOAD messages received from non-constrained devices, and possibly constrained devices, that include resource data that is to be cached in the network. The RELOAD protocol unit 15 is also responsible for generating RELOAD messages for storing and retrieving resource data in a RELOAD overlay network formed within the machine-to-machine network. The non-constrained device 8 can therefore be configured to act as a CoAP end-point, and/or can be configured to act as a RELOAD peer. The receiver 1 1 is configured to receive CoAP/RELOAD messages sent to the non-constrained device 8 by other non-constrained devices in the network (i.e. other peers of the RELOAD overlay network, including peers acting as gateway to nodes that are external to the machine-to-machine network), and to receive CoAP/RELOAD messages sent to the non-constrained device 8 by constrained devices i n the network. The transmitter 12 is configured to send the CoAP/RELOAD messages generated by the CoAP protocol unit 14 and the RELOAD protocol unit 15.

The methods and apparatus described above provide a distributed rendezvous service and an advanced distributed cache for CoAP endpoints and applications. No such mechanisms currently exist for CoAP or other M2M systems. In doing so, these methods and apparatus make it possible to use the CoAP protocol without the need to rely on centralized services like DNS-SD for rendezvous. In addition, given that the architecture enabled by these methods and apparatus is completely decentralized, it provides that autonomous M2M systems can be deployed with minimal need for central servers and/or data centres. This solution is therefore inherently scalable and meets the requirements of systems with a large number of interconnected devices, such as the Internet of Things and M2M networks. The methods and apparatus described above enable rapid retrieval of the most recent data value from a resource, as the most recent data is stored as part of the sensor's rendezvous information within the overlay network, and provides that it is possible to retrieve data even if the resource is asleep. Further, these methods and apparatus make it possible to store time series information from resources in a scalable manner within the overlay network.

It will be appreciated by the person of skill in the art that various modifications may be made to the above-described embodiments without departing from the scope of the present invention. For example, whilst the embodiments described above use RELOAD as an example of a P2P protocol , the present invention is equal ly applicable to any other P2P signalling protocol or P2P algorithms. In this regard, whilst the RELOAD protocol uses the Chord DHT algorithm to implement the P2P overlay network, other algorithms such as Kademlia, Pastry, CAN, and Tapestry could also be used. Furthermore, whilst the embodiments described above use CoAP as an example of a M2M signalling protocol, the present invention is equally applicable to other M2M signalling protocols.

Table 1 - Examples of sensor_type values

Table 2 - Examples of values for the type_of_action field

Table 3 - Examples of values for the statistical joperation field

Value Meaning

0 No statistical processing required. Instead, the Fetch response should contain all the values of the record (i.e., the Fetch is processed in the normal way).

1 Return the average of the values within the record in the

Fetch response.

2 Return the standard deviation of the values within the record.

3 Return the median of the values within the record.

4 Return the Λ/th percentile of the values within the record.

The value of N is specified in a further extension field of the Fetch request called percentile_n.

5 Return the number of entries (i.e., CachedValue structures) within the TimeSeriesRecord.

6 Return the size of the TimeSeriesRecord in bytes.

Other values are

possible although

not listed here

Claims

1. A method of operating a machine-to-machine network comprising a plurality of nodes, one or more of the plurality of nodes hosting one or more resources, the method comprising:

implementing a peer-to-peer signalling protocol in order to provide distributed caching for data produced by the resources and to provide resource discovery for the cached resource data.

2. A method as claimed in claim 1 , wherein the plurality of nodes includes constrained devices and non-constrained devices.

3. A method as claimed in claim 2, wherein each constrained device hosts one or more resources.

4. A method as claimed in any of claims 2 or 3, and further comprising:

configuring each of the non-constrained devices to act as a peer of a peer-to- peer overlay network, the peers of the peer-to-peer overlay network providing a distributed cache for resource data.

5. A method as claimed in claim 4, and further comprising:

configuring one or more of the constrained devices to act as a client of the peer-to-peer overlay network.

6. A method as claimed in any of claims 4 or 5, wherein the resource data produced by a resource is stored in the peer-to-peer overlay network as a resource record, and a resource identifier is used to store and retrieve resource data in the resource record.

7. A method as claimed in claim 6, wherein the resource record of a resource includes one or more or:

a list of the peers of the peer-to-peer overlay network through which the resource can be reached;

a value for the most recent data produced by the resource; a validity period for the most recent data;

an indication as to when the most recent data was produced;

an indication as to when the most recent data was cached; and

an indication of the current status of the resource.

8. A method as claimed in any of claims 6 or 7, wherein the resource record includes a resource identifier identifying a time series record of data previously produced by the resource, the time series record also being stored in the peer-to- peer overlay network.

9. A method as claimed in any of claims 6 to 8, wherein the resource record includes the node identities of one or more nodes that are to be contacted by the resource when the node hosting the resource is next active.

10. A method as claims in any of the preceding claims, wherein the peer-to-peer signalling protocol is the Resource Location And Discovery, RELOAD, Base Protocol.

1 1. A method as claimed in any of claims 2 to 10, wherein a machine-to-machine- suitable signalling protocol is used for signalling between one or more of the constrained devices, and between one or more of the constrained devices and the non-constrained devices.

12. A method as claimed in claim 1 1 , wherein the machine-to-machine-suitable signalling protocol is the Constrained Application Protocol, CoAP.

13. A method of operating a constrained device within a machine-to-machine network, the constrained device hosting one or more resources and being configured to be active periodically, the method comprising:

when the constrained device is active, each of the one or more resources hosted by the constrained device producing resource data and sending the resource data to a non-constrained device in the machine-to-machine network for caching.

14. A method as claimed in claim 13, and further comprising:

configuring the constrained device to act as a Constrained Application Protocol, CoAP, end point and using a CoAP message to send resource data for caching in the network.

15. A method as claimed in claim 13, and further comprising:

configuring the constrained device to act as a client of a peer-to-peer overlay network, the non-constrained device acting as a peer of the peer-to-peer overlay network, and sending the resource data to the non-constrained device for caching in the peer-to-peer overlay network.

16. A method as claimed i n clai m 15, wherein the constrained device is configured to act as a client of a Resource Location And Discovery, RELOAD, Base Protocol overlay network and a RELOAD message is used to send the resource data for caching in a RELOAD overlay network.

17. A method of operating a non-constrained device within a machine-to-machine network, the machine-to-machine network including constrained devices each hosting one or more resources, the method comprising:

configuring the non-constrained device to act as a peer of a peer-to-peer overlay network, the peers of the peer-to-peer overlay network providing a distributed cache for resource data produced by the resources.

18. A method as claimed in claim 17, wherein the non-constrained device is configured to act as a peer of a Resource Location And Discovery, RELOAD, Base Protocol overlay network.

19. A method as claimed in claim 18, and further comprising:

receiving a RELOAD message from a constrained device, the received RELOAD message including resource data for caching; and

sending a RELOAD message to cache the resource data in the RELOAD overlay network.

20. A method as claimed in claim 18, and further comprising:

configuring the non-constrained device to act as a Constrained Application Protocol, CoAP, end point; receiving a CoAP message from a constrained device, the CoAP message including resource data for caching; and

21. A method as claimed in any of claims 18 to 20, and further comprising:

receiving a message from a node that is external to the machine-to-machine network, the message requesting data from an identified resource;

sending a RELOAD message to retrieve resource data produced by the identified resource that is cached in the RELOAD overlay network.

22. A constrained device configured to operate within a machine-to-machine network, the constrained device comprising:

one or more resources hosted by the constrained device, each of the one or more resources being configured to produce resource data; and

a transmitter for sending the resource data to a non-constrained device in the machine-to-machine network for caching.

23. A constrained device as claimed in claim 22, wherein the constrained device is configured to act as a Constrained Application Protocol, CoAP, end point and further comprises a processor configured to generate a CoAP message that includes resource data for caching in the network.

24. A constrained device as claimed in claim 22, wherein the constrained device is configured to act as a client of a peer-to-peer overlay network, the non-constrained device acting as a peer of the peer-to-peer overlay network, and the transmitter is configured to send the resource data to the non-constrained device for caching in the peer-to-peer overlay network.

25. A constrained device as claimed in claim 24, wherein the constrained device is configured to act as a client of a Resource Location And Discovery, RELOAD, Base Protocol overlay network and further comprises a processor configured to generate a RELOAD message that includes resource data for caching in a RELOAD overlay network.

26. A non-constrained device configured to operate within a machine-to-machine network, the machine-to-machine network including constrained devices each hosting one or more resources, wherein the non-constrained device is configured to act as a peer of a peer-to-peer overlay network, the peers of the peer-to-peer overlay network providing a distributed cache for resource data produced by the resources.

27. A n o n-constrained device as claimed in claim 26, wherein the non- constrained device is configured to act as a peer of a Resource Location And Discovery, RELOAD, Base Protocol overlay network.

28. A n o n-constrained device as claimed in claim 27, wherein the non- constrained device is also configured to act as a Constrained Application Protocol, CoAP, end point, and further comprises a receiver for receiving a CoAP message from a constrained device, the CoAP message including resource data for caching, a processor configured to generate a RELOAD message in order to cache the resource data in the RELOAD overlay network, and a transmitter for sending a RELOAD message to cache the resource data in the RELOAD overlay network.

29. A non-constrained device as claimed in any of claims 27 or 28, and further comprising:

a receiver for receiving a message from a node that is external to the machine-to-machine network, the message requesting data from an identified resource; and

a transmitter for sending a RELOAD message to retrieve resource data produced by the identified resource that is cached in the RELOAD overlay network.