Patent Description:
The "Internet of Things" (IoT) refers to devices (for example, digital machines, computing devices and mechanical devices) enabled for communication network connectivity, so that these devices may be remotely managed, and data collected or required by the devices may be exchanged between individual devices and between devices and application servers. Such devices, examples of which may include sensors and actuators, are often, although not necessarily, subject to severe limitations on processing power, storage capacity, energy supply, device complexity and/or network connectivity, imposed by their operating environment or situation, and may consequently be referred to as constrained devices.

The constrained nature of loT devices has prompted the design and implementation of new protocols and mechanisms. The Constrained Application Protocol (CoAP), as defined in RFC <NUM>, is one example of a protocol designed for loT applications in constrained nodes and constrained networks. CoAP provides a request for information-response based RESTful communication architecture between constrained nodes or between constrained nodes and nodes on the Internet. CoAP can easily be integrated to the web and web services by translating CoAP messages to HTTP.

CoAP follows a client/server model and employs a two-layer structure, where these two layers are the Message Layer, and the Request/Response layer. The Message Layer supports four types of messages: CON (confirmable), NON (non-confirmable), ACK (acknowledgement), and RST (reset), as defined in RFC <NUM>. The Request /Response layer supports methods such as GET, PUT, POST and DELETE (as defined in RFC <NUM>), allowing for the access, modification, or deletion of resources.

Various protocol extensions for CoAP exist, providing additional features. One example is the Observe mechanism, as defined in RFC <NUM>, which enables CoAP clients to "observe" resources, indicating that the CoAP client wishes to receive a notification of the current representation of a resource whenever the CoAP server updates the state of that resource. In this manner, the CoAP client may avoid the need to continuously pole the CoAP server for the current state of the resource, reducing power consumption and network traffic. A CoAP client may register its interest in a resource by sending an extended GET request. The extended GET request includes an Observe option, a value of which may be set to <NUM> (Observe registration) or <NUM> (Observe deregistration). If the value of the Observe option included in the request is set to <NUM>, the CoAP server will add the CoAP client to a list of observers of the resource. If the value of the Observe option included in the Request is set to <NUM>, the CoAP server will remove the CoAP client from the list of observers of the resource.

Whenever the state of a resource changes, the CoAP server responsible for that resource will notify the state change to each CoAP client in its list of observers of the current state of the resource. Each notification is an additional CoAP response message sent by the CoAP server in reply to an original Observe registration, and includes a complete, updated representation of the new resource state. This CoAP response also comprises an Observe option, and in these notification responses, the value of the Observe option comprises a sequence number for correctly ordering the notifications and enabling reordering detection. All notifications carry the token specified by the CoAP client in the original Observe registration, enabling the CoAP client to correctly correlate notifications to the original request.

<FIG> is a message flow diagram illustrating example exchanges between a CoAP client <NUM> and a CoAP server <NUM> according to the Observe procedure. In step <NUM>, the CoAP client <NUM> registers its interest in a resource by sending a request to the CoAP server <NUM> (Observe registration). As discussed above, the Observe registration includes an Observe option with value <NUM>. In this illustrated example, the CoAP client registers its interest in a temperature resource. This temperature resource may relate to, for example, a temperate sensor associated with the CoAP server <NUM>. The Observe registration further comprises a token that has been specified by the CoAP client <NUM>. In this illustrated example, the value of the token is 0x4a.

Responsive to receiving the Observe registration communicated by the CoAP client <NUM> in step <NUM>, the CoAP server <NUM> adds the CoAP client <NUM> to the list of observers of the resource and, in step <NUM>, sends a notification to the CoAP client <NUM> comprising a representation of the current state of the target resource. The initial notification sent by the CoAP server <NUM> in step <NUM> comprises the representation of the current state of the temperature resource: <NUM> degrees Celsius, an Observe option with a value of <NUM> (a sequence number for ordering notifications), and the token value form the Observe registration of 0x4a.

In step <NUM>, the CoAP server <NUM> then sends the CoAP client <NUM> a subsequent notification comprising an updated representation of the target resource in response to a change in the state of that resource. The subsequent notification sent by the CoAP server <NUM> in step <NUM> comprises the Observe option with a value of <NUM>, the current state of the temperature resource: <NUM> degrees Celsius, and the token value 0x4a.

In step <NUM>, the CoAP server <NUM> then sends the CoAP client <NUM> another notification comprising a further updated representation of the target resource in response to another change in the state of that resource. The notification sent by the CoAP server <NUM> in step <NUM> comprises the Observe option with a value of <NUM>, the current state of the temperature resource: <NUM> degrees Celsius, and the token 0x4a.

As stated above, the value of the Observe option in the notifications communicated in steps <NUM>, <NUM>, and <NUM> acts as a sequence number to allow the CoAP client <NUM> to correctly order notifications sent by the CoAP server <NUM>. Furthermore, the value of the token in the notifications communicated in steps <NUM>, <NUM>, and <NUM>, enables the CoAP client <NUM> to correlate these received notifications to the Observe registration request that was communicated to the CoAP server <NUM> in step <NUM>.

Thus, the Observe mechanism allows a CoAP client to be notified with an updated representation of a target resource whenever the state of that resource changes.

A situation may be envisaged in which a CoAP client that is no longer interested in receiving notifications, having for example gone offline, fails to deregister for the notifications. In such a situation, the CoAP client would remain on the list of observers for resources for which it has registered indefinitely. In order to avoid such a situation, the Observe mechanism requires that at least every <NUM> hours, a CoAP server should send a notification comprising an updated representation of a target resource in a confirmable message to all CoAP clients that have registered for updates about that resource. If a CoAP client does not respond to this confirmable message, the CoAP server should remove the CoAP client from the list of observers of the corresponding resource.

Although the CoAP Observe mechanism addresses a particular need that was not fulfilled by the original CoAP protocol, continuing evolution of loT devices and deployments has resulting in additional needs for information management with respect to representations of CoAP resources. For example, some CoAP clients may sleep for periods longer than <NUM> hours, resulting in such clients being undesirable deregistered from resources. In addition, CoAP currently only allows for the provision of real-time current information about resources, which information may not be sufficient to fulfil the requirements of all CoAP clients.

Internet Engineering Task Force, IETF; Standard Working Draft, Conditional observe in CoAP, dated <NUM>-<NUM>-<NUM> mentions that through an Observe option, CoAP clients can observe changes in the state of resources and obtain current representation of the last resource state.

Internet Engineering Task Force, IETF; Standard Working Draft, Constrainted Objects Language, dated <NUM>-<NUM>-<NUM> discloses CoAP endpoints cache responses in order to reuse the cached responses to satisfy a current request.

<NPL>, discloses a management function set adapted to constrained devices and constrained networks.

<NPL> discloses two options for CoAP Observe so that a CoAP client can specify timing conditions when observing a resource on a CoAP server.

Publication <CIT> relates to detecting an anomaly in a network, wherein an analyzer, acting as client, requests state information regarding output of an anomaly detection model applied by a distributed learning agent, DLA, acting as server. The request sent by the analyzer includes a parameter defining a time period for the requested information.

It is an aim of the present disclosure to provide a CoAP server, CoAP client, and corresponding methods according to the independent claims.

For a better understanding of the present disclosure, and to show more clearly how it may be carried into effect, reference will now be made, by way of example, to the following drawings in which:.

An overview of CoAP server and CoAP client behaviour according to different examples of the present disclosure is provided below, together with discussion of details which may be incorporated in different implementations of these examples. There then follows a discussion of example methods according to the present disclosure, which methods may be implemented by processing circuitry in a CoAP server and CoAP client according to the present disclosure. Some example message sequences are then discussed illustrating operation of a CoAP server and CoAP client according to examples of the present disclosure. A CoAP server according to examples of the present disclosure is operable to provide information, such as representations, for one or more resources. A resource may for example be a data object or information, a service or application, a sensor etc..

Aspects of the present disclosure relate to enabling a CoAP client to request historical information about a resource from a CoAP server.

As currently specified, the CoAP Observe mechanism does not allow representations of a past state of a resource, that is a state in which the resource was prior to the receipt of an Observe registration, to be provided to a CoAP client. Thus, in other words it is not currently possible to obtain historical information relating to a resource. It is proposed that a new CoAP option may be provided to address this challenge. The option may be included in a request for information (such as an extended GET request or Observe registration, for example), and comprise a first time period value. The first time period value indicates a period of time prior to the sending of the request for information during which period of time information about a resource is requested. This option is referred to herein as the time period option.

<FIG> is a flow chart illustrating a method <NUM> that may be conducted at a CoAP client, according to examples of the present disclosure.

Referring to <FIG>, in a first step <NUM>, a CoAP client sends to a CoAP server a request for information about a resource. The request for information comprises a time period option, wherein the time period option comprises a first time period value that indicates a period of time prior to the sending of the request for information, over which information about the resource is requested.

In some examples, the first time period value may indicate the beginning of the period of time prior to the sending of the request for information, over which information about the resource is requested. In some examples, the first time period value may comprise an integer value indicating the beginning of the period of time. The first time period value may for example comprise a value indicating a time in seconds prior to the sending of the request for information. For example, the time period value may be <NUM>, indicating that the period of time begins <NUM> seconds (<NUM> hours) prior to the sending of the request for information by the CoAP client. In other words, in this example, the CoAP client would be requesting information about a resource over the period of time that begins <NUM> seconds (<NUM> hours) prior to the sending of the request for information by the CoAP client, and ends at the time at which the request for information is sent by the CoAP client. Therefore, in some examples, the period of time ends at the time at which the request for information is sent. It will be appreciated that the first time period value may correspond to any suitable unit of time (for example, minutes, hours, days, etc.).

In another example, the first time period value may comprise a value indicating a date in seconds that exists prior to the sending of the request for information. In some examples, the date may be provided in Unix Epoch time. For example, the first time period value may be <NUM>, indicating that the period of time prior to the sending of the request for information begins at the Unix Epoch time <NUM> (GMT May <NUM>, <NUM><NUM>:<NUM>:<NUM> PM). In other words, in this example, the CoAP client would be requesting information about a resource over the period of time that begins at the Unix Epoch time <NUM>, and ends at the time at which the request for information is sent by the CoAP client. Therefore, in some examples, the period of time ends at the time at which the request for information is sent. It will be appreciated that the first time period value may represent a date in any suitable form.

In some examples, the first time period value may indicate the length of the period of time prior to the sending of the request for information over which information about a resource is requested. In some examples, the first time period value may be an integer value indicating the length of the period of time.

In some examples, the time period option may further comprise a second time period value that indicates the length of the period of time. The first period time value may indicate the beginning of the period of time according to any of the examples discussed above. Similarly, the second period time value may indicate the length of the period of time according to any of the examples discussed above.

For example, the first period time value may comprise a value indicating a date in seconds that exists prior to the sending of the request for information, as discussed above. The second time period value may be a value indicating a length of a time period in seconds, as discussed above. The first time period value and the second time period value may be separated by a token "+", although it will be appreciated that any suitable token may be used to separate the first and second time period values. For example, the first time period value may be <NUM> in Unix Epoch time (GMT May <NUM>, <NUM><NUM>:<NUM>:<NUM> PM), and the second time period value may be <NUM> seconds (<NUM> hours). In other words, in this example, the CoAP client would be requesting information about a resource over the period of time that begins at <NUM> in Unix Epoch time, and ends <NUM> seconds (<NUM> hours) after <NUM> Unix Epoch time (GMT May <NUM>, <NUM><NUM>:<NUM>:<NUM> PM).

In some examples, the information about the resource that is requested may comprise at least one representation of the resource over the period of time. The resource may for example be a data object or information, a service or application, a sensor, a sensor reading etc., and the representation may be any appropriate representation able to convey a state of the resource.

In some examples, the request for information may further comprise a timestamp option, wherein the timestamp option comprises a first timestamp value. The first timestamp value may indicate that at least one timestamp corresponding to each of the at least one representations of the resource is requested. In other words, the timestamp option indicates whether timestamps should be provided for each representation of the resource that is requested.

In some examples, the information about the resource comprises at least one representation of the resource corresponding to a change of state of the resource within the period of time. For example, where the resource comprises a temperature value, if the temperature value changes from <NUM> degrees Celsius to <NUM> degrees Celsius during the period of time, the information about the resource will comprise the value <NUM> degrees Celsius.

In some examples, the information about the resource comprises at least one representation of the resource corresponding to the resource fulfilling at least one predetermined criterion within the period of time. For example, where the resource comprises a temperature value, and the predetermined criterion comprises a temperature value that is below <NUM> degrees Celsius, if the temperature value changes from <NUM> degrees Celsius to <NUM> degrees Celsius during the period of time, the information about the resource may comprise the value <NUM> degrees Celsius. It will be appreciated that a change of state of the resource may comprise the resource fulfilling at least one predetermined criterion. In other examples, resource may comprise a qualitative indication of temperature, and the criterion may be associated with a label, such that, for example, a temperature below <NUM> degrees Celsius is labelled as "low". In such examples, if the temperature value changes from <NUM> degrees Celsius to <NUM> degrees Celsius during the period of time, the information about the resource may comprise the label "low".

In step <NUM>, the CoAP client receives a response to the request for information. The response to the request for information may comprise some, all or none of the additional features discussed below with reference to <FIG> and later in the detailed description.

<FIG> shows a flow chart illustrating process steps in a further example of a method <NUM> by a CoAP client. The steps of the method <NUM> illustrate example ways in which the steps of the method <NUM> may be implemented and supplemented in order to achieve the above discussed and additional functionality.

In a first step <NUM>, a CoAP client sends to a CoAP server a request for information about a resource, the request for information comprising a time period option, wherein the time period option comprises a first time period value that indicates a period of time prior to the sending of the request for information over which information about the resource is requested. According to different examples of the method <NUM>, the information about the resource, the time period option, and the first time period value, may comprise some, all or none of the additional features discussed above with reference to <FIG> and earlier in the detailed description.

As illustrated in step 310b, the request for information may further comprise a time interval option, wherein the time interval option comprises a first time interval value that indicates a minimum period of time that is to separate successive representations of the resource to be provided in response to the request for information. In some circumstances, it may be that information relating to a resource changes very frequently during the period of time. In such circumstances, the CoAP client may seek to limit in some manner the amount of information provided by the CoAP server in response to the request for information. This may be appropriate owing to storage limitations in the CoAP server, or to reduce the length of a message that will be required to be communicated by the CoAP server to the CoAP client. In some examples, this limitation may be achieved by including another new option in the request for information. This further new option is referred to herein as a time interval option. The time interval option comprises a first time interval value that indicates a minimum period of time that is to separate successive representations of the resource to be provided in response to the request for information. In other words, in this example, the CoAP client defines a minimum interval that is to exist between successive representations of the resource to be provided by the CoAP server. In this manner, even if there are many representations of the resource that have been obtained by the CoAP server in the period of time (for example, due to the resource changing state frequently, or due to the resource meeting a predetermined criteria on multiple occasions, etc.), the CoAP client will only receive a subset of these representations each representation being separated in time from its preceding and subsequent representation by at least the minimum interval defined in the time interval option. In one example, if a minimum time interval of <NUM> hours is specified, and the subject resource changed state within the time period at times of <NUM>:<NUM>, <NUM>:<NUM>, <NUM>:<NUM>, <NUM>:<NUM>, <NUM>:<NUM> and <NUM>:<NUM>, only the representations corresponding to the times <NUM>:<NUM> and <NUM>:<NUM> would be provided by the CoAP server in the response to the request for information. This option may be beneficial in situations where the CoAP client does not require every representation of a resource over an extended period of time. This may also be beneficial in reducing the size of the message that is communicated to the CoAP client by the CoAP server.

In some examples, the first time interval value indicate a minimum period of time in seconds that is to separate successive representations of a resource to be provided in response to a request for information. For example, the first time interval value may comprise the value <NUM>, which in this example indicates that successive representations of the resource to be provided in response to the request for information should be separated by at least <NUM> seconds. It will be appreciated that the first time interval value may comprise any value, and that the time interval values correspond to any suitable unit of time.

As illustrated in step 310a, the request for information may comprise an Observe registration comprising an Observe option. The Observe registration may be as described above in relation to <FIG>. The inclusion of a request for information with an Observe registration may allow a CoAP client to indicate that it wishes to receive the current state of the resource, and notifications of how that resource will change in the future, as well as simultaneously requesting information relating to that resource in a past or historical time period, that is a time period prior to the sending of the Observe registration. This may allow for a reduction in the number of messages to be communicated by the CoAP client, and may reduce the power consumed by the CoAP client.

As illustrated in step 310c, the time interval option may comprise a second time interval value, wherein the second time interval value indicates a minimum period of time to elapse between notifications to be provided by the CoAP server in response to the Observe registration. In other words, in this example, in addition to specifying a temporal separation between representations of the resource in the historical data to be provided to the CoAP client, the CoAP client also defines a minimum period of time that is to exist between successive notifications to be provided by the CoAP server. In this manner, even if there are many more representations of the resource that have been obtained by the CoAP server in this minimum period of time (for example, due to the resource changing state, due to the resource meeting a predetermined criteria on multiple occasions, etc.), the CoAP client will only receive a subset of these representations, so reducing the load on the CoAP server and message traffic in what may be a constrained network. In one example, the CoAP client may specify a minimum interval of <NUM> seconds between representations in requested historical data, and specify that future notifications should be separated by a minimum of <NUM> seconds. According to such an example, even if the response changes state every <NUM> seconds, notifications will be sent at intervals of at least <NUM> seconds, and intervening representations will not be notified to the CoAP client.

In other words, the second time interval value may control the time separation of subsequent Observe notifications. For example, a CoAP server may wake up following a period of sleep, and may request representations of a resource from the last <NUM> hours that are separated by <NUM> hour intervals, and may also request that every hour from now onwards it receives a notification comprising the current representation of the resource.

Thus, in this example, the first time period value will represent <NUM> hours, the first time interval value will represent <NUM> hours, and the second time interval value will represent <NUM> hour.

In step <NUM>, the CoAP client receives a response to the request for information from the CoAP server. According to different examples of the method <NUM>, the response to the request for information may comprise some, all or none of the additional features discussed below with reference to <FIG> and later in the detailed description. In some examples, the response to the request for information may be included in a response to an Observe registration at step <NUM>, such that steps <NUM> and <NUM> are achieved by receiving a single message.

In step <NUM>, the CoAP client receives a response to the Observe registration, wherein the response to the Observe registration comprises a message sent by the CoAP server comprising a current representation of the resource. The response may be as described above in relation to <FIG>. In some examples, as discussed above, the response to the request for information at step <NUM>, containing the historical information about the resource, and the response to the Observe registration at step <NUM>, may be included in a single message received by the CoAP client.

In step <NUM>, the CoAP client receives a subsequent response to the Observe registration, wherein the subsequent response to the Observe registration comprises a message sent by the CoAP server comprising an updated representation of the resource. In some examples, in which a minimum time period for separating notifications was included in the Observe registration as discussed above, the notification containing the updated representation of the resource may be separated from the response sent at step <NUM> by the minimum period of time as discussed above. The subsequent response may be as described above in relation to <FIG>. For example, if the minimum period of time is <NUM> seconds, the subsequent response to the Observe registration may not be communicated by the CoAP server until at least <NUM> seconds after the earlier response to the Observe registration has been communicated.

The steps of the methods <NUM> and <NUM> may be complimented by a method <NUM> performed by a CoAP server, as illustrated in <FIG>.

In a first step <NUM>, the CoAP server receives from a CoAP client a request for information about a resource, the request for information comprising a time period option that comprises a time period value. According to different examples of the method <NUM>, the information about the resource, the time period option, and the time period value may comprise some, all or none of the additional features discussed above with reference to <FIG> and earlier in the detailed description.

In step <NUM>, the CoAP server responds to the request for information. In some examples, the CoAP server is configured to respond to the request for information by sending a message to the CoAP client comprising information about the resource over the period of time. In some examples, the message may comprise at least one representation of the resource over the period of time, as discussed above. In some examples, the information about the resource over the period of time may further comprise a timestamp corresponding to each of the representations of the resource comprised within the message.

For example, the message may comprise at least one representation of the resource corresponding to a change of state of the resource within the period of time, as discussed above. In another example, the message may comprise at least one representation of the resource corresponding to the resource fulfilling at least one predetermined criterion within the period of time, as discussed above.

<FIG> and <FIG> show flow charts illustrating process steps in a further example of a method <NUM> performed by a CoAP server. The steps of the method <NUM> illustrate example ways in which the steps of the methods <NUM> may be implemented and supplemented in order to achieve the above discussed and additional functionality.

As illustrated in step 510a, the request for information may comprise an Observe registration. According to different examples of the method <NUM>, the Observe registration may comprise some, all or none of the additional features discussed above with reference to <FIG> and earlier in the detailed description.

At step <NUM>, the CoAP server determines whether it is able to respond to the received request for information. If it is determined that the CoAP server cannot respond to the request for information, the process moves to step <NUM>. If it is determined that the CoAP server can respond to the request for information, the process moves to step <NUM>. The different steps that may be carried out to respond to the request for information are illustrated in <FIG>.

Referring now to <FIG>, at step <NUM>, the CoAP server determines whether a minimum period of time to separate successive representations of the resource in the response to the request for information has been received. If it is determined that a minimum period of time has been received, the process moves to step <NUM>. At step <NUM>, the CoAP server sends a message to the CoAP client wherein the information about the resource over the period of time comprises representations of the resource that are separated by the minimum period of time.

If it is determined that a minimum period of time has not been received, the process moves to step <NUM>. At step <NUM>, the CoAP server determines whether a predetermined separation period exists. If it is determined that a predetermined separation period exists, the process moves to step <NUM>. At step <NUM>, the CoAP server sends a message to the CoAP client wherein the information about the resource over the period of time comprises representations of the resource that are separated by a predetermined separation period. In other words, the CoAP server may provide a subset of the representations of the resource over the period of time, where this subset is based on the predetermined separation period. The predetermined separation period may not have been received in a request for information from a CoAP client, and may be a parameter that is stored by the CoAP server.

Therefore, in some embodiments, the CoAP server may provide a subset of the information about the resource over the period of time that is requested by the CoAP client. This subset may be based on internal policies of the CoAP server. In some examples, this may prevent the size of the CoAP response message from becoming excessively large, and additionally or alternatively, may prevent the CoAP client from being provided with unnecessary information about the resource (for example, if the resource has changed very frequently over the predetermined period of time). In this example, the response sent by the CoAP server may further comprise a <NUM> content filter code. This code indicates that the CoAP server can send part of the information requested by the CoAP client.

Alternatively, the response sent by the CoAP server may further comprise a <NUM> content incomplete code. This code indicates that the CoAP server cannot provide all the information requested by the CoAP client. This may occur if the CoAP server is a constrained device with limited capabilities to store information relating to a resource for extended period of time, and has not stored information about the resource over the complete time period requested by the CoAP client.

Alternatively, if it is determined by the CoAP server that a predetermined separation period does not exist at step <NUM>, the process moves to step <NUM>. At step <NUM>, the CoAP server sends a message to the CoAP client comprising information about the resource over the period of time. According to different examples of the method <NUM>, the information about the resource may comprise some, all or none of the additional features discussed above with reference to <FIG> and the relevant earlier description.

Thus, in some embodiments, the CoAP server may provide all of the information about the resource over the period of time that has been requested by the CoAP client. In this example, the response sent by the CoAP server may further comprise a <NUM> content response code, or alternatively, may comprise a <NUM> (valid) response code. These codes indicate that the CoAP server can provide all of the information about the resource over the period of time that has been requested by the CoAP client.

Referring again to <FIG>, if the CoAP server is unable to respond to the request then, at step <NUM>, the CoAP server sends a message to the CoAP client indicating that the CoAP server is unable to send notification messages to the CoAP client comprising information about the resource over the period of time. For example, in some embodiments, the CoAP server may send a message to the CoAP client comprising a <NUM> not found code. Alternatively, if the CoAP server is not able to implement the time period option as described in the document, the CoAP server may communicate this to the CoAP client by sending a message to the CoAP client comprising a <NUM> method not allowed code.

At step <NUM>, following sending of the messages at step <NUM> or <NUM>, the CoAP server determines whether an Observe registration has been received. For example, the request for information may have been included in an Observe registration. If it is determined that an Observe registration has not been received, the process ends. If it is determined that an Observe registration has been received, the process moves to step <NUM>. At step <NUM>, the CoAP server sends a message to the CoAP client comprising the current representation of the resource. The process then moves to step <NUM>. At step <NUM>, the CoAP server determines if a condition for sending an updated representation of the resource has been fulfilled, and if a minimum period of time to elapse between sending by the CoAP server of successive notifications about the resource has elapsed. In some embodiments, the condition may have been received in the Observe registration from the CoAP client, or may be based on the internal policies of the CoAP server. In some embodiments, the minimum period of time may have been received in the Observe registration, for example, as the second time interval value, as described above. Additionally or alternatively, in some embodiments, the minimum period of time to elapse may have been received in the Observe registration from the CoAP client, or may be based on the internal policies of the CoAP server. If it is determined that either the condition for sending an updated representation of the resource has not been fulfilled, or that the minimum period of time has not elapsed, then the process shall return to step <NUM>. If it is determined that both the condition for sending an updated representation of the resource has been fulfilled and that the minimum period of time has elapsed, the process moves to step <NUM>.

At step <NUM>, the CoAP server sends a subsequent Observe message to the CoAP client comprising an updated representation of the resource.

Thus, the methods <NUM> to <NUM> discussed above illustrate different ways in which a CoAP server and client may operate in order to communicate regarding historical information relating to a resource.

Further aspects of the present disclosure relate to enabling a CoAP client to pause the sending of notifications by a CoAP server relating to a resource that the CoAP client is observing.

As discussed above, the Observe mechanism requires that a CoAP server sends a notification comprising an updated representation of a target resource to a CoAP client in a confirmable message at least every <NUM> hours. If the CoAP client does not respond to this confirmable message, the CoAP server will remove the CoAP client from the list of observers of the corresponding resource. As noted above, many CoAP devices may implement sleeping patterns in order to conserve energy, owing to their constrained capabilities, and these sleeping patterns may comprise sleeping periods that exceed <NUM> hours. Furthermore, a CoAP client will not be made aware that it has been removed by the CoAP server from the list of observers of the corresponding resource, and may therefore not be aware that it is missing future CoAP notifications of the state of a resource. In addition, a CoAP client may be registered to multiple CoAP observations at the same CoAP server. It may therefore be cumbersome to deregister for each resource at the CoAP server each time the CoAP client goes to sleep, and to re-register for each resource on waking.

It is proposed that new Option values in an Observe registration may be considered to address this challenge. As discussed above, when the value of the Observe option is set to <NUM> in an Observe registration, the CoAP server adds the CoAP client to the list of observers of the resource. When the value of the Observe option is set to <NUM> in an Observe registration, the CoAP server removes the CoAP client from the list of observers of the resource. It is proposed that new values of the Observe option may be used to pause and resume notifications relating to a resource.

In a first step <NUM>, a CoAP client sends to a CoAP server an Observe registration relating to one or more resources, the Observe registration comprising an option, the option comprising a first value that indicates that the CoAP server should pause notifications for one or more registrations corresponding to one or more resources. In some examples, the option may be the Observe option and the first value may comprise the value <NUM> (as described in <FIG>). When the CoAP server receives the option comprising the first value that indicates that the CoAP server should pause notifications for one or more registrations corresponding to one or more resources, the CoAP server will cease sending the CoAP client notifications for those one or more resources. However, the CoAP server will retain the CoAP client in the relevant lists of observers for those one or more resources. The relevant entry in the list may be identified by matching an endpoint or a token stored in the list with an endpoint or token received in a request for information from the CoAP client.

In some examples, the CoAP client is further configured to send to the CoAP server a subsequent Observe registration relating to one or more resources, the subsequent Observe registration comprising an option, the option comprising a second value that indicates that the CoAP server should resume paused notifications for one or more registrations. In some embodiments, the option may be the Observe option and the second value may comprise the value <NUM> (as described in <FIG>). When the CoAP server receives the option comprising the second value that indicates that the CoAP server should resume paused notifications for one or more registrations, the CoAP server will resume sending the CoAP client notifications for those one or more registrations.

In some examples, where the Observe registration comprises an option comprising either the first value or the second value, the Observe registration may not further comprise a token option. In these cases, the Observe registration will either relate to pausing all notifications for the registrations that are registered at the CoAP server for that CoAP client (in the case that the option comprises the first value), or will relate to resuming paused notifications for all the registrations that are registered at the CoAP server for that CoAP client (in the case that the option comprises the second value). Additionally or alternatively, this may be indicated by an "/all" URL comprised within the Observe registration.

In some examples, where the Observe registration comprises an option comprising either the first value or the second value, the Observe registration may comprise a token. In these cases, the Observe registration will either relate to pausing or resuming notifications for the registration that corresponds to the token that is included in the Observe registration.

In other words, including (or not including) the token option in the Observe registration may provide the CoAP client with greater control over which notifications (that it is registered to receive from a CoAP server) it requests be paused or resumed.

Therefore, the CoAP client may use the above discussed method to prevent its registrations (each registration corresponding to a resource that the CoAP client is observing) from being cancelled at the relevant CoAP server. This may be useful when the CoAP client will be entering a sleeping period that exceeds <NUM> hours. Alternatively or additionally, if the CoAP client is able to pause the notifications relating to a registration at a time when the notifications are not required by the CoAP client, this may also reduce unnecessary traffic in a network. In other words, the above discussed method may contribute to the optimization of the throughput of a network, as loT networks may be constrained, and thus the sending of unnecessary messages may negatively impact the throughput. Alternatively or additionally, if the CoAP client is able to pause the notifications relating to a registration at a time where the network is known to be unreliable, and the notifications being communicated by the CoAP server are at risk of not being received by the CoAP client, this may reduce uncertainty as to the validity of notifications received.

In some examples, the CoAP client may be further configured to send an Observe registration comprising an option that comprises either the first value or the second value as part of a multicasting message to the network. This allows the CoAP client to either pause, or to resume, one or more notifications at all the CoAP servers in the network. This may prevent the CoAP client from having to send an individual Observe registration (to either pause or resume notifications) to each of the CoAP servers in the network, and therefore may reduce traffic in the network.

In some examples, the CoAP client may also be configured to send to the CoAP server a request for information about a resource corresponding to at least one of the resumed registrations, wherein the request for information comprises a time period option, as discussed above. Additionally, the CoAP client may further be configured to receive a response to the request for information. In other words, the step of requesting that paused notifications for one or more registrations be resumed may be combined with the method of requesting historical information relating to the one or more registrations, as described above. This may be beneficial in a situation in which a CoAP client wishes to obtain information relating to a resource over the period of time during which the CoAP client requested that notification corresponding to that resource be paused (for example, over a period of time in which the CoAP client was sleeping, or at a time when the CoAP client requested notifications be paused due to network unreliability).

<FIG> shows a flow chart illustrating process steps in a further example of a method <NUM> performed by a CoAP client. The steps of the method <NUM> illustrate example ways in which the steps of the method <NUM> may be implemented and supplemented in order to achieve the above discussed and additional functionality.

In a first step <NUM>, the CoAP client sends to a CoAP server an Observe registration relating to one or more resources, the Observe registration comprising an option, the option comprising a first value that indicates that the CoAP server should pause notifications for one or more registrations corresponding to one or more resources. According to different examples of the method <NUM>, the Observe registration may comprise some, all or none of the additional features discussed above with reference to <FIG> and earlier in the detailed description. The Observe registration may thus comprise an Observe option with a value of <NUM> (as described in <FIG>).

At step <NUM>, the CoAP client sends a subsequent Observe registration relating to one or more resources, the subsequent Observe registration comprising an option, the option comprising a second value that indicates that the CoAP server should resume paused notifications for one or more registrations. According to different examples of the method <NUM>, the subsequent Observe registration may comprise some, all or none of the additional features discussed above with reference to <FIG> and earlier in the detailed description. The Observe registration may thus comprise an Observe option with a value of <NUM> (as described in <FIG>).

At step <NUM>, the CoAP client receives a response to the subsequent Observe registration from the CoAP server. According to different examples of the method <NUM>, the response may comprise some, all or none of the additional features discussed above with reference to <FIG> and earlier in the detailed description.

At step <NUM>, the CoAP client sends a request for information about a resource corresponding to at least one of the resumed registrations, the request for information comprising a time period option. According to different examples of the method <NUM>, the request for information may comprise some, all or none of the additional features discussed above with reference to <FIG> and earlier in the detailed description.

At step <NUM>, the CoAP client receives a response to the request for information from the CoAP server. According to different examples of the method <NUM>, the request for information may comprise some, all or none of the additional features discussed above with reference to <FIG> and earlier in the detailed description. In some examples, the request for information sent at step <NUM> may be included in the subsequent Observe registration sent at step <NUM>, for example be including the time period option on the subsequent Observe registration sent at step <NUM>.

Referring now to <FIG>, in a first step <NUM>, the CoAP server receives from a CoAP client an Observe registration relating to one or more resources, the Observe registration comprising a CoAP Option, the option comprising a first value that indicates that the CoAP server should pause notifications for one or more registrations corresponding to the one or more resources. According to different examples of the method <NUM>, the Observe registration may comprise some, all or none of the additional features discussed above with reference to <FIG> and earlier in the detailed description.

At step <NUM>, the CoAP server pauses the one or more registrations.

<FIG> show a flow chart illustrating process steps in a further example of a method <NUM> performed by a CoAP server. The steps of the method <NUM> illustrate example ways in which the steps of the method <NUM> may be implemented and supplemented in order to achieve the above discussed and additional functionality.

Referring to <FIG>, in a first step <NUM>, the CoAP server receives from a CoAP client an Observe registration relating to one or more resources, the Observe registration comprising an option, the option comprising a first value that indicates that the CoAP server should pause notifications for one or more registrations corresponding to the one or more resources. According to different examples of the method <NUM>, the Observe registration may comprise some, all or none of the additional features discussed above with reference to <FIG> and earlier in the detailed description.

At step <NUM>, the CoAP server stores one or more representations of the one or more resources corresponding to the one or more registrations for which notifications have been paused. It will be appreciated that although retaining the representations of the one or more resources may not be possible for some CoAP servers due to their constrained capabilities, some CoAP servers may be able to retain the requested representations, or alternatively, can implement internal policies to limit the number of representations stored. Aspects of the present disclosure may, for example, be implemented on Class <NUM> devices (as per RFC <NUM>, ~ <NUM> KB of RAM and ~ <NUM> KB of ROM) or may be implemented in constrained devices with capabilities significantly beyond Class <NUM>. In some examples, the CoAP server may store a notification state of a CoAP client for one or more registrations corresponding to the CoAP client. In other words, the CoAP server may store whether notifications have been paused, or not, for each registration at the CoAP server.

At steps <NUM> and <NUM>, the CoAP server determines whether a subsequent Observe registration has been received prior to the expiry of a predetermined period of time. In some examples, the predetermined period of time begins at the receipt of the Observe registration indicating that the CoAP server should pause notifications for one or more registrations corresponding to the one or more resources. If it is determined that no subsequent observe registration has been received, the process moves to step <NUM>. At step <NUM>, the CoAP server deregisters the one or more registrations for which notifications have been paused. This may, for example, prevent a malicious third party from attacking a CoAP server by pausing the notifications at the CoAP server for a particular observation by a particular CoAP client. In these circumstances, the attacker would not resume the paused notifications, thus wasting the storage capabilities of the CoAP server. However, allowing the pausing of the notifications to timeout may prevent this from occurring. For example, the predetermined period of time to timeout may be <NUM> days, or any other suitable length of time.

If it is determined that a subsequent Observe registration relating to one or more resources has been received from the CoAP client, the CoAP server may restart a timer for the timeout of at least the paused notifications included in the subsequent Observe registration and the process moves to step <NUM>. At step <NUM>, the CoAP server resumes the one or more paused registrations indicated in the subsequent Observe registration.

Referring now to <FIG>, at step <NUM>, the CoAP server receives a request for information about a resource corresponding to at least one of the resumed registrations, the request for information comprising a time period option, wherein the time period option comprises a time period value. According to different examples of the method <NUM>, the information about the resource, the time period option, and the first time period value, may comprise some, all or none of the additional features discussed above with reference to <FIG> and earlier in the detailed description. As illustrated in step 940a, in some examples, the request for information may further comprise an Observe registration. According to different examples of the method <NUM>, the Observe registration may comprise some, all or none of the additional features discussed above with reference to <FIG> and earlier in the detailed description.

Referring now to <FIG>, at step <NUM>, the CoAP server determines whether a minimum period of time to separate successive representations of the resource in the response to the request for information has been received. If it is determined that a minimum period of time has been received, the process moves to step <NUM>. At step <NUM>, the CoAP server may send a message to the CoAP client wherein the information about the resource over the period of time comprises representations of the resource that are separated by the minimum period of time.

If it is determined that a minimum period of time has not been received, the process moves to step <NUM>. At step <NUM>, the CoAP server determines whether a predetermined separation period exists. If it is determined that a predetermined separation period exists, the process moves to step <NUM>. At step <NUM>, the CoAP server may send a message to the CoAP client wherein the information about the resource over the period of time comprises representations of the resource that are separated by a predetermined separation period. In other words, the CoAP server may provide a subset of the representations of the resource over the period of time, where this subset is based on the predetermined separation period. The predetermined separation period may not have been received in a request for information from a CoAP client, and may be a parameter that is stored by the CoAP server.

Alternatively, the response sent by the CoAP server may further comprise a <NUM> content incomplete code. This code indicates that the CoAP server cannot provide all the information requested by the CoAP client. This may occur if the CoAP server is a constrained device with limited capabilities to store information relating to a resource for extended period of time, and has been unable to store representations of the resource for the full time period specified.

If it is determined that a predetermined separation period does not exist, the process moves to step <NUM>. At step <NUM>, the CoAP server sends a message to the CoAP client comprising information about the resource over the period of time. According to different examples of the method <NUM>, the information about the resource may comprise some, all or none of the additional features discussed above with reference to <FIG>.

Thus, in some embodiments, the CoAP server may provide all of the information about the resource over the period of time that is requested by the CoAP client. In this example, the response sent by the CoAP server may further comprise a <NUM> content response code, or alternatively, may comprise a <NUM> (valid) response code. These codes indicate that the CoAP server can provide all of the information about the resource over the period of time that is requested by the CoAP client.

Referring again to <FIG>, at step <NUM>, if the CoAP server is unable to respond to the request, the CoAP server sends a message to the CoAP client indicating that the CoAP server is unable to send a message to the CoAP client comprising information about the resource over the period of time. For example, in some examples, the CoAP server may send a message to the CoAP client comprising a <NUM> not found code. Alternatively, if the CoAP server is not able to implement the time period option as described in the document, the CoAP server may communicate this to the CoAP client by sending a message to the CoAP client comprising a <NUM> method not allowed code.

The methods <NUM> and <NUM>, and <NUM> and <NUM> discussed above illustrate different ways in which a CoAP server and client may operate in order to enable a CoAP client to request historical information from a CoAP server.

The methods <NUM> and <NUM>, and <NUM> and <NUM> discussed above illustrate different ways in which a CoAP server and client may operate in order to enable a CoAP client to pause the sending of notifications by a CoAP server relating to a resource that the CoAP client is observing.

<FIG>, <FIG>, <FIG> and <FIG> are message flow diagrams illustrating example exchanges between a CoAP client and server according to different examples of the methods discussed above.

In the example message exchange of <FIG> between a CoAP client <NUM> and a CoAP server <NUM>, in step <NUM>, the CoAP client <NUM> sends a request for information about a resource, the request for information comprising a time period option, wherein the time period option comprises a first time period value that indicates a period of time prior to the sending of the request for information over which information about the resource is requested. In this illustrated example, the request for information comprises a CoAP GET request, and the resource comprises a temperature resource. The request further comprises a token that has been specified by the CoAP client <NUM>, wherein the value of the token is 0x4a. The first time period value comprises <NUM>, which in this example indicates that the period of time prior to the sending of the request for information begins <NUM> seconds (<NUM> hours) prior to the sending of the request for information by the CoAP client <NUM>. It will be appreciated that the request for information sent by the CoAP client <NUM> at step <NUM> may be considered a historical information request.

At step <NUM>, the CoAP server <NUM> responds to the request for information. In this example, the CoAP server <NUM> sends a message to the CoAP client <NUM> comprising information about the resource over the period of time, wherein the message comprises at least one representation of the resource over the period of time. In this example, the message comprises the values <NUM>, <NUM> and <NUM> in the payload, corresponding to three distinct representations of the temperature resource of <NUM> degrees Celsius, <NUM> degrees Celsius and <NUM> degrees Celsius. As, in this example, all the values are in Celsius, the CoAP server <NUM> only indicates the Celsius value as part of the last representation to simplify the message. In this example, although the different representations of the resource are separated by semicolons, it will be appreciated that any other appropriate symbols, or any other appropriate method of separating values in the payload may be used. For example, different representations of the resource may be separated by a carriage return ("\r"). It will be appreciated that the representations of the resource within the payload may be in chronological order.

In this example, the message further comprises a <NUM> content code. It will be appreciated that the request for information sent by the CoAP sever <NUM> at step <NUM> may be considered a historical information response.

In the example message exchange of <FIG> between a CoAP client <NUM> and a CoAP server <NUM>, in step <NUM>, the CoAP client <NUM> sends a request for information about a resource, the request for information comprising a time period option, wherein the time period option comprises a first time period value that indicates a period of time prior to the sending of the request for information over which information about the resource is requested. In this illustrated example, the request for information comprises a CoAP GET request, and the resource comprises a temperature resource. The request further comprises a token that has been specified by the CoAP client <NUM>, wherein the value of the token is 0x4a. The first time period value comprises <NUM>, which in this example indicates that the period of time prior to the sending of the request for information begins <NUM> seconds (<NUM> hours) prior to the sending of the request for information by the CoAP client <NUM>. In this illustrated example, the request for information further comprises a timestamp option, wherein the timestamp option comprises a first timestamp value, wherein the first timestamp value indicates that at least one timestamp corresponding to each of the at least one representation of the resource is requested. It will be appreciated that the request for information sent by the CoAP client <NUM> at step <NUM> may be considered a historical information request.

At step <NUM>, the CoAP server <NUM> responds to the request for information. In this example, the CoAP server <NUM> sends a message to the CoAP client <NUM> comprising information about the resource over the period of time, wherein the message comprises at least one representation of the resource over the period of time. In this example, the message comprises a first entry - the value <NUM> and the timestamp <NUM>, a second entry - the value <NUM> and the timestamp <NUM>, and a third entry - the value <NUM> and the timestamp <NUM>, in the payload. For each of the three entries, the value of the resource and the timestamp are separated by a comma, and each of the entries are separated from one another by semicolons. However, it will be appreciated that any other appropriate symbols, or any other appropriate method of separating entries in the payload, and of separating parameters within entries, may be used. As, in this example, all the values of the resource are in Celsius, the CoAP server <NUM> only indicates the Celsius value as part of the last representation to simplify the message. In this example, each timestamp represents the time in seconds from each previous state change of the resource. Thus, in this example, the value of the resource was <NUM> degrees Celsius at the beginning of the period of time (at <NUM> seconds), the value of the resource was then <NUM> degrees Celsius <NUM> seconds after the time corresponding to the first value of the resource (<NUM> seconds into the period of time), and the value of the resource was then <NUM> degrees Celsius <NUM> seconds after the time corresponding to the second value of the resource (<NUM> seconds into the period of time). In this example, the message further comprises a <NUM> content filter response code, which indicates that the CoAP server <NUM> has sent only part of the information requested by the CoAP client <NUM>. For example, the CoAP server <NUM> may have filtered the information requested by the CoAP client <NUM> in one of the manners as discussed above. It will be appreciated that the request for information sent by the CoAP sever <NUM> at step <NUM> may be considered a historical information response.

In the example message exchange of <FIG> between a CoAP client <NUM> and a CoAP server <NUM>, in step <NUM>, the CoAP client registers its interest in a resource by sending an Observe registration to the CoAP server. As stated above, the Observe registration includes an Observe option with a value set to <NUM>. In this illustrated example, the CoAP client <NUM> registers its interest in a temperature resource. This temperature resource may relate to, for example, a temperate sensor associated with the CoAP server. In this illustrated example, the request further comprises a token that has been specified by the CoAP client <NUM>. In this illustrated example, the value of the token is 0x4a.

Responsive to receiving the request for information communicated by the CoAP client <NUM> in step <NUM>, the CoAP server <NUM> adds the CoAP client <NUM> to the list of observers of the resource and, in step <NUM>, sends a notification to the CoAP client <NUM> comprising a representation of the target resource. As stated above, each notification sent by the CoAP server <NUM> is an additional CoAP response in reply to the single Observation registration, including an Observe option. In this illustrated example, the notification sent by the CoAP server <NUM> in step <NUM> comprises an Observe option with a value of <NUM>, the value of the temperature resource of <NUM> degrees Celsius, and the value of the token of 0x4a.

At step <NUM>, the CoAP client <NUM> sends to the CoAP server <NUM> an Observe registration relating to one or more resources, the Observe registration comprising an option, the option comprising a first value that indicates that the CoAP server should pause notifications for one or more registrations corresponding to one or more resources. In this example, the option is the Observe option and the first value comprises the value <NUM>. The Observe registration further comprises an "/all" URL indicating that the Observe registration relates to all the resources at the CoAP server <NUM> that the CoAP client <NUM> has registered interest in.

At step <NUM>, the CoAP client <NUM> sends to the CoAP server <NUM> a subsequent Observe registration relating to one or more resources, the subsequent Observe registration comprising an option, the option comprising a second value that indicates that the CoAP server should resume paused notifications for one or more registrations. In this example, the option comprises the Observe option and the first value comprises the value <NUM>. The Observe registration further comprises an "fall" URL indicating that the Observe registration relates to all the resources at the CoAP server <NUM> that the CoAP client <NUM> has registered interest in.

In the example message exchange of <FIG> between a CoAP client <NUM> and a CoAP server <NUM>, in step <NUM>, the CoAP client registers its interest in a resource by sending an Observe registration to the CoAP server. As stated above, the Observe registration includes an Observe option with a value of <NUM>. In this illustrated example, the CoAP client registers its interest in a temperature resource. This temperature resource may relate to, for example, a temperate sensor associated with the CoAP server. In this illustrated example, the Observe registration further comprises a token that has been specified by the CoAP client <NUM>. In this illustrated example, the value of the token is 0x4a.

Responsive to receiving the Observe registration communicated by the CoAP client <NUM> in step <NUM>, the CoAP server <NUM> adds the CoAP client <NUM> to the list of observers of the resource and, in step <NUM>, the CoAP server <NUM> sends a notification to the CoAP client <NUM> comprising a representation of the target resource. As stated above, each notification sent by the CoAP server <NUM> is an additional CoAP response in reply to the single Observe registration. In this illustrated example, the notification sent by the CoAP server <NUM> in step <NUM> comprises an Observe option with a value of <NUM>, the value of the temperature resource of <NUM> degrees Celsius, and the value of the token of 0x4a.

At step <NUM>, the CoAP client <NUM> sends to the CoAP server <NUM> an Observe registration relating to one or more resources, the Observe registration comprising an option, the option comprising a first value that indicates that the CoAP server should pause notifications for one or more registrations corresponding to one or more resources. In this example, the option comprises the Observe option and the first value comprises the value <NUM>. The Observe registration further comprises an "fall" URL indicating that the Observe registration relates to all the resources at the CoAP server <NUM> that the CoAP client <NUM> has registered interest in. The CoAP server therefore pauses notifications on all Observe registrations for the CoAP client.

At step <NUM>, the CoAP client <NUM> sends to the CoAP server <NUM> a subsequent Observe registration relating to one or more resources, the subsequent Observe registration comprising an option, the option comprising a second value that indicates that the CoAP server should resume paused notifications for one or more registrations. In this example, the option comprises the Observe option and the first value comprises the value <NUM>. The Observe registration further comprises a "/temperature" URL indicating that the Observe registration relates to only the temperature resource at the CoAP server <NUM>. In this example, the subsequent Observe registration further comprises a request for information about a resource corresponding to at least one of the resumed registrations, the request for information comprising a time period option. In this example, the first time period value comprises <NUM>, which in this example indicates that the period of time prior to the sending of the request for information begins <NUM> seconds (<NUM> hours) prior to the sending of the request for information by the CoAP client <NUM>. Furthermore, in this example, the value of the token is 0x4a as in the message sent in step <NUM>.

At step <NUM>, the CoAP server <NUM> responds to the request for information. In this example, the CoAP server <NUM> sends a message to the CoAP client comprising information about the resource over the period of time, wherein the message comprises at least one representation of the resource over the period of time. In this example, the message comprises the values <NUM>, <NUM> and <NUM> in the payload, corresponding to three distinct representations of the temperature resource of <NUM> degrees Celsius, <NUM> degrees Celsius and <NUM> degrees Celsius. As, in this example, all the values are in Celsius, the CoAP server only indicates the Celsius value as part of the last representation to simplify the message. In this example, although the different representations of the resource are separated by semicolons, it will be appreciated that any other appropriate symbols, or any other appropriate method of separating values in the payload may be used. In this example, the message further comprises a <NUM> content code. In this illustrated example, the notification sent by the CoAP server <NUM> in step <NUM> comprises an Observe option set to the value of <NUM> and the value of the token of 0x4a. The value of the token in the notification communicated in steps <NUM> and <NUM> enables the client to correlate these received notifications to the requests communicated to the CoAP client <NUM> communicated in step <NUM> and <NUM> respectively.

<FIG> is a block diagram illustrating an example CoAP server <NUM> which may implement the method <NUM> and/or <NUM> and/or <NUM> and/or <NUM> according to examples of the present disclosure, for example on receipt of suitable instructions from a computer program <NUM>. Referring to <FIG>, the CoAP server <NUM> comprises a processor or processing circuitry <NUM>, and may comprise a memory <NUM> and interfaces <NUM>. The processing circuitry <NUM> is operable to perform some or all of the steps of the method <NUM> and/or <NUM> and/or <NUM> and/or <NUM> as discussed above with reference to <FIG>, <FIG>, <FIG> and <FIG>. The memory <NUM> may contain instructions executable by the processing circuitry <NUM> such that the CoAP server <NUM> is operable to perform some or all of the steps of the method <NUM> and/or <NUM> and/or <NUM> and/or <NUM>. The instructions may also include instructions for executing one or more telecommunications and/or data communications protocols. The instructions may be stored in the form of the computer program <NUM>. In some examples, the processor or processing circuitry <NUM> may include one or more microprocessors or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, etc. The processor or processing circuitry <NUM> may be implemented by any type of integrated circuit, such as an Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA) etc. The memory <NUM> may include one or several types of memory suitable for the processor, such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, solid state disk, hard disk drive etc..

<FIG> illustrates functional units in another example of CoAP server <NUM> which may execute examples of the method <NUM> and/or <NUM> of the present disclosure, for example according to computer readable instructions received from a computer program. It will be understood that the units illustrated in <FIG> are functional units, and may be realised in any appropriate combination of hardware and/or software. The units may comprise one or more processors and may be integrated to any degree.

Referring to <FIG>, the CoAP server <NUM> comprises a receiving module <NUM> for receiving from a CoAP client a request for information about a resource, the request for information comprising a time period option that comprises a time period value, and a transmitting module <NUM> for responding to the request. The CoAP server <NUM> may also comprise interfaces <NUM>.

Referring to <FIG>, the CoAP server <NUM> comprises a receiving module <NUM> for receiving from a CoAP client a CoAP Observe registration relating to one or more resources, the CoAP Observe registration comprising an option, the option comprising a first value that indicates that the CoAP server should pause notifications for one or more registrations, and a pausing module <NUM> for pausing the one or more registrations. The CoAP server <NUM> may also comprise interfaces <NUM>.

<FIG> is a block diagram illustrating an example CoAP client <NUM> which may implement the method <NUM> and/or <NUM> and/or <NUM> and/or <NUM> according to examples of the present disclosure, for example on receipt of suitable instructions from a computer program <NUM>. Referring to <FIG>, the CoAP client <NUM> comprises a processor or processing circuitry <NUM>, and may comprise a memory <NUM> and interfaces <NUM>. The processing circuitry <NUM> is operable to perform some or all of the steps of the method <NUM> and/or <NUM> and/or <NUM> and/or <NUM> as discussed above with reference to <FIG>, <FIG>, <FIG> and <FIG>. The memory <NUM> may contain instructions executable by the processing circuitry <NUM> such that the CoAP client <NUM> is operable to perform some or all of the steps of the method <NUM> and/or <NUM> and/or <NUM> and/or <NUM>. The instructions may also include instructions for executing one or more telecommunications and/or data communications protocols. The instructions may be stored in the form of the computer program <NUM>. In some examples, the processor or processing circuitry <NUM> may include one or more microprocessors or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, etc. The processor or processing circuitry <NUM> may be implemented by any type of integrated circuit, such as an Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA) etc. The memory <NUM> may include one or several types of memory suitable for the processor, such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, solid state disk, hard disk drive etc..

<FIG> illustrates functional units in another example of CoAP client <NUM> which may execute examples of the method <NUM> and/or <NUM> of the present disclosure, for example according to computer readable instructions received from a computer program. It will be understood that the units illustrated in <FIG> are functional units, and may be realised in any appropriate combination of hardware and/or software. The units may comprise one or more processors and may be integrated to any degree.

Referring to <FIG>, the CoAP client <NUM> comprises a transmitting module <NUM> for sending to a CoAP server a request for information about a resource, the request comprising a time period option, wherein the time period option comprises a first time period value that indicates a period of time prior to the sending of the request over which information about the resource is requested, and a receiving module <NUM> for receiving a response to the request for information. The CoAP client may also comprise interfaces <NUM>.

<FIG> illustrates functional units in another example of CoAP client <NUM> which may execute examples of the methods <NUM> and/or <NUM> of the present disclosure, for example according to computer readable instructions received from a computer program. It will be understood that the units illustrated in <FIG> are functional units, and may be realised in any appropriate combination of hardware and/or software. The units may comprise one or more processors and may be integrated to any degree.

Referring to <FIG>, the CoAP client <NUM> comprises a transmitting module <NUM> for sending to a CoAP server an Observe registration relating to one or more resources, the Observe registration comprising an option, the option comprising a first value that indicates that the CoAP server should pause notifications for one or more registrations corresponding to one or more resources. The CoAP client may also comprise interfaces <NUM>.

Examples of the present disclosure thus provide a CoAP server and client, and methods performed in a CoAP server and client, that expand on the existing CoAP Observe mechanism. The Observe mechanism as currently specified does not allow representations of a resource from periods of time in the past, prior to the receipt of a request for information (in other words, historical information relating to the resource) to be provided to a CoAP client. In addition to this, the Observe mechanism requires that the CoAP server sends a notification comprising an updated representation of the target resource to the CoAP client in a confirmable message at least every <NUM> hours. If the CoAP client does not respond to this confirmable message, the CoAP server will remove the CoAP client from the list of observers of the corresponding resource.

Examples of the present disclosure provide mechanisms for obtaining historical information relating to a resource, and for pausing and resuming notifications relating to a resource. The aspects may be combined to allow a CoAP client to pause notifications before entering an extended sleeping period, and, upon waking, resume notifications and obtain information about the state of the resource during the period in which the CoAP client was sleeping. This avoids a CoAP client being deregistered form resources, and also avoids cumbersome intentional deregistering and re-registering. In addition, the CoAP client may "catch up" on data that was missed while the CoAP client was sleeping though the requesting of historical data for the period in which it was sleeping. A CoAP client may also pause notifications for other reasons, such as when temporarily not useful, during times of network congestion etc. A CoAP client may pause all or only some registrations, such that notifications on the most important resources continue to be delivered while others are paused. Examples of the present disclosure may thus address existing challenges relating to the Observe mechanism, as well as offering savings relating to device energy and network throughput.

It will be appreciated that examples of the present disclosure may be virtualised, such that the methods and processes described herein may be run in a cloud environment.

The methods of the present disclosure may be implemented in hardware, or as software modules running on one or more processors. The methods may also be carried out according to the instructions of a computer program, and the present disclosure also provides a computer readable medium having stored thereon a program for carrying out any of the methods described herein. A computer program embodying the disclosure may be stored on a computer readable medium, or it could, for example, be in the form of a signal such as a downloadable data signal provided from an Internet website, or it could be in any other form.

It should be noted that the above-mentioned examples illustrate rather than limit the disclosure, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The scope of protection is defined by these claims.

Claim 1:
A Constrained Application Protocol, CoAP, client (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) comprising processing circuitry configured to:
send (<NUM>) to a CoAP server (<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) a request for information about a resource, the request for information comprising:
a CoAP Observe registration comprising an Observe option;
a time period option, wherein the time period option comprises a first time period value that indicates a period of time prior to the sending of the request for information over which information about the resource is requested, wherein the information about the resource comprises at least one representation of the resource over the period of time; and
a time interval option, wherein the time interval option comprises a first time interval value that indicates a minimum period of time that is to separate successive representations of the resource to be provided in response to the request for information, and a second time interval value, wherein the second time interval value indicates a minimum period of time to elapse between successive Observe notifications to be provided by the CoAP server in response to the Observe registration;
receive (<NUM>) a response to the request for information