- Open Access
Facilitating the creation of IoT applications through conditional observations in CoAP
© Teklemariam et al.; licensee Springer. 2013
- Received: 21 February 2013
- Accepted: 7 June 2013
- Published: 24 June 2013
With the advent of IPv6, the world is getting ready to incorporate smart objects to the current Internet to realize the idea of Internet of Things. The biggest challenge faced is the resource constraint of the smart objects to directly utilize the existing standard protocols and applications. A number of initiatives are currently witnessed to resolve this situation. One of such initiatives is the introduction of Constrained Application Protocol. This protocol is developed to fit in the resource-constrained smart object with the ability to easily translate to the prominent representational state transfer implementation, hypertext transfer protocol (and vice versa). The protocol has several optional extensions, one of them being, resource observation. With resource observation, a client may ask a server to be notified every state change of the resource. However, in many applications, all state changes are not significant enough for the clients. Therefore, the client will have to decide whether to use a value sent by a server or not. This results in wastage of the already constrained resources (bandwidth, processing power,…). In this paper, we introduced an alternative to the normal resource observation function, named Conditional Observation, where clients tell the servers the criteria for notification. We evaluated the power consumption and number of packets transmitted between clients and servers by using different network sizes and number of servers. In all cases, we found out that the existing observe option results in excessive number of packets (most of them unimportant for the client) and higher power consumption. We also made an extensive theoretical evaluation of the two approaches which give consistent result with the results we got from experimentation.
- Conditional observation
- Resource observation
Remarkable advances in microelectromechanical systems (MEMS) have led to the creation of tiny but crucial embedded devices such as sensors and actuators. The wireless communication capability of these devices turns them into smart objects that can interact with the virtual world. Coupled with the explosive expansion of wireless and mobile technologies, there are very good reasons to consider these objects as corner stones of the future internet rather than mere add-ons to the current communication networks. The resulting Internet is now commonly referred to as the internet of things (IoT). However, the severe limitations of these smart objects in terms of memory, processing capacity, power, and bandwidth pose great challenges in realizing this. A typical smart object may have a few kilobytes of memory (random access memory (RAM) and read-only memory (ROM)), slow microcontrollers, and limited bandwidth (around 250 kbps). On top of this, most of the smart objects are battery operated and have limited lifetime. The protocols and applications that are widely used in the current internet are too heavy for such constrained devices to be applied directly. Several initiatives exist to alleviate these prevailing problems by proposing new lightweight protocols suitable for constrained devices and networks. The internet engineering task force (IETF) is the pioneer in producing standards and protocols that fit the strict requirements of such constrained environments by establishing working groups that address different aspects of the requirements of the constrained objects and networks.
The IPv6 for low power and lossy wireless personal area network (6LoWPAN) working group of IETF has produced standards that enable IPv6 to be used in the most constrained devices . Montenegro et al.  introduce the 6LoWPAN adaptation layer which resides between the network and link layer and provides three basic services: IPv6 header compression, fragmentation, and mesh under routing support. These basic services ensure that constrained devices can talk to unmodified IPv6 hosts in the internet, and the other way around, while the 6LoWPAN adaption layer overcomes the differences in protocol design between these two worlds, necessitated by the constraints of the low power and lossy networks (LLNs). Further, current routing protocols and algorithms are not suitable for constrained environments for several reasons: high resource (memory, processing, and bandwidth) requirement, absence of uniform metric in LLNs and unreliability of intermediate routing nodes. The routing in low power and lossy networks (ROLL) working group is tasked with proposing routing solutions suitable for constrained networks and devices. The routing protocol for low-power and lossy networks (RPL) is a proposed standard by this working group .
Both IETF groups have realized the interconnectivity between tiny objects and the current internet in a standardized way. However, this connectivity is merely an enabler required to unlock all potential of the IoT in the form of novel applications and services. Web service technology made the success of the current internet. Now, it is expected that an embedded counterpart of web service technology is needed in order to exploit all great opportunities offered by the internet of things, since existing application layer protocols, such as hypertext transfer protocol (HTTP), SOAP, and XML are even heavier than the protocols defined in layers below. Therefore, the constrained RESTful environments (CoRE) working group was established to specifically work on the standardization of a framework for resource-oriented applications, allowing the realization of RESTful embedded web services in a similar way as traditional web services . Their work resulted in the Constrained Application Protocol (CoAP), a specialized RESTful web transfer protocol for use with constrained networks and nodes. It uses the same RESTful principles as HTTP, but it is much lighter so that it can be run on constrained devices . In addition, the group designed observe functionality in order to allow a device to publish a value or event to another device that has subscribed to be notified of changes in the resource representation .
CoAP, together with its observe functionality, provides the basis for the integration of constrained devices with the internet at the service level and the realization of embedded web services. However, in order to really facilitate IoT application design, additional CoAP-related functionalities are expected to appear. For instance, many applications can benefit from a lightweight solution for subscribing for very specific events. Ideally, this is built into the CoAP protocol as an extension, avoiding the need to implement such functionality on a per resource basis. This facilitates the realization of many sensor–actuator interactions which typically have the following pattern: if ‘condition fulfilled’ then ‘take action’. The contribution of this paper is that we present an extension of the CoAP observe functionality that exactly facilitates realizing this behavior by including notification criteria to be specified along with observation request. This way, the server will not just send notifications whenever the state of a resource changes. It will first check if the change is significant enough for the client by comparing the new value with the notification criteria sent by the client. Only then, a notification will be sent. The design is compact, lightweight, and can be easily shared across all resources. Further, we are the first to implement such an extension to CoAP on constrained devices and to evaluate in detail the potential reduction in power consumption and number of packets transmitted that can be achieved, which is of great importance to constrained networks.
Section 2 of the paper first introduces the CoAP protocol, followed by the existing CoAP Observe option, its limitations, and possible approach to tackle these limitations. Related work will be discussed in section 3. In section 4, an alternative method, called conditional observation, is presented, and the approach is explained in great details. The next section discusses our implementation on constrained devices, followed by section 6 presenting a detailed experimental and mathematical evaluation. In section 7, we further illustrate some potential IoT applications that can benefit from our proposal. Finally, the paper draws conclusions and suggests future work.
Representational state transfer (REST) uses mechanisms that are less memory and processing power intensive . As a result, many systems are now becoming RESTful . In this approach, data or resources that must be exchanged between client and server are encoded as representations of the resource. In addition, all states required to complete a request must be provided along with the request. The desired communication result is achieved by transferring the representations and the states between the client and the server using HTTP operations such as GET, PUT, POST, and DELETE . However, today's web service technology is a poor match for the vast majority of constrained networks, machine-to-machine (M2M) applications and embedded devices because of their overhead and complexity. For applications that involve smart objects, such as industry automation, transport logistics, and building automation, an embedded alternative would be ideal since it is in line with current web services, facilitating the integration of objects into the Internet.
As such, when Observe is used, the CoAP client will get a notification response whenever the state of the observed resource changes or its MAX-AGE expires. For frequently changing resources or resource with a low MAX-AGE value, this results in frequent notifications, which is not ideal in constrained networks. Also, it is unclear how non-cacheable (MAX-AGE equal to 0) resources should be handled. In many cases, an observer will typically be interested in state changes that satisfy a specific condition, instead of receiving all state changes or notifications that only update the freshness.
However, the current observe draft stresses on providing the clients with up-to-date information about the state of a resource. Applications that are interested in values that exceed some thresholds will simply drop the transmitted packets upon reception if they do not meet their criteria (client side filtering). This unnecessary data transmission can be costly to the already constrained objects. The increased number of packet transmissions in highly dynamic environment will also increase the network congestion and for larger networks the impact can be significant. In addition, the power consumption (processing, transmission, and listening) can be higher for the overall network.
Therefore, in several cases, one could benefit from a solution for subscribing to very specific events only, i.e., conditional observations. Since we are dealing with constrained devices, such a solution should satisfy several requirements. The functionality should have a sufficiently small footprint, allowing the implementation on very constrained devices. It should be usable by all resources on a constrained device without additional programming complexity. Further, it should offer sufficient expressiveness in order to be able to express conditions that are encountered frequently across resources and across IoT use cases. Finally, if needed, extensions should be possible in order to cope with future requirements. Based on these requirements, we have chosen to realize this conditional observe functionality by embedding it in the CoAP protocol as a new CoAP option. Before presenting our solution, we will first discuss related work that aims to achieve similar functionality, and position it against our approach.
There are a number of research activities under way on resource observation in WSNs. Different groups are using different approaches to come up with outstanding solutions and technologies. Publish/subscribe systems are widely used in the Internet already for a while. The basic concept of such systems is similar to normal observation where subscribers register at publishers (notifiers) and get responses depending on the original request made by the subscribers . Different authors have proposed similar solutions to be used in wireless sensor networks. MQTT-S is a protocol proposed to handle publish/subscribe issues in WSNs. The protocol is based on the MQTT protocol, an established protocol for lightweight publish/subscribe reliable messaging transport, optimized to connect physical world devices/messages and events with enterprise servers and other consumers. The protocol introduces MQTT-S gateways and forwarders to communicate publish/subscribe information between clients and the MQTT broker, which ultimately responds with the required information . With this approach, a 3rd party is required to realize the desired functionality, whereas we want to allow direct end-to-end interactions with the constrained devices. There are also middleware-based pub/sub solutions such as Mires and PSWare. Most of these solutions introduce a new protocol specifically addressing this issue while our approach, however, is an extension of an existing protocol that is being developed in an open standardization organization. This way, our approach significantly reduces the additional memory and processing requirement for realizing this new functionality, since it builds upon functionality already present in any CoAP implementation.
The European telecommunications standards institute (ETSI) has also proposed a standard to address observation relationships in Machine-to-Machine (M2M) communications. The ETSI Machine-To-Machine (M2M) Communications functional architecture  states how RESTful web services can be used in M2M communications. Subscription management is one of the areas the document addresses. In the document, a client may subscribe for a specific resource or an attribute of a resource by specifying filtering criteria, if required. The ETSI standard follows its own functional architecture that is totally different from the IETF approach. Our solution is based on the work of the IETF CoRE working group.
Another related work is  where conditional observation requests are represented by URI queries. An important problem with this approach is its complexity. The queries that are generated may have limited readability and could be difficult to represent. Furthermore, URI queries are very resource specific complicating automatic processing of conditional observations or code reuse over several resources. Using a CoAP option for conditional observations makes this functionality independent of any specific resource implementation, whereas URI queries can be used for resource-specific functionalities. Further, the link with the Observe option is lost by spreading this functionality over both URI queries and options and the multitude of URI queries that can occur makes it more complex for intermediaries to process this information.
Finally, the Open Geospacial Consortium (OGC), Inc. has been developing different standards in the area of geospatial data. One of the standards developed by the OGC is the sensor observation service (SOS) that deals with the specifications of data observation from different sensors in different, possibly geographically scattered, sensor networks . The standard specifies that a GetObservation request may have several mandatory and optional parameters. One of the optional parameters is featureOfInterest, which is similar to our observation type. However, this approach is more focused for geographical observations and is a subset of a bigger framework, which significantly differs from the IETF recommendation.
The Condition option has to be used in combination with the Observe option and can be used both in request and response messages. In a GET request message, the Condition option represents the condition the client wants to apply to the observation relationship. It is used to describe the resource states the client is interested in. In response to the initial GET request message, the Condition option, together with the Observe option, indicates that the client has been added to the list of observers and that notifications will be sent only when the resource state meets the condition specified in the Condition option. In all further notifications, the Condition option identifies the condition to which the notification applies. In the following subsections we will further describe the semantics and usage of the Condition option, illustrating the capabilities of this extension.
4.1 The Condition option format
4.2 Condition types
Li et al.  identified nine condition types, some of which are time-based while others are value-based. Minimum Response Time, Maximum Response Time, and Periodic option types are time-based conditions, whereas AllValues<, AllValues>, Value=, Value<>, and Step use the sensor reading values as notification criteria. The Time Series condition type is neither related to time nor to sensor readings.
4.2.1 Normal observe
According to the CoAP draft document , a server sends notifications to observers in three cases: first, a notification is sent to clients when the observation relationship is established for the first time to indicate that the client is added to the observers list; second, whenever the resource state changes the server sends notifications; finally, a notification is also sent when the data previously sent to the client is not fresh as indicated by the CoAP MAX-AGE option which by default is set to 60. In such cases, the server sends the notification, if the previous notification is older than the MAX-AGE value (even if the resource state stays the same).
Accordingly, given the values in Figure 7, the server sends notifications at the establishment of the observation relationship (at time 0) every time the value changes (at times 10, 15, 20, 25, 30, and 120 s), and the MAX-AGE expires (at time 90 s) as shown in the top row of Figure 8.
4.2.2 Condition type 1: time series
With Time Series condition type, every change of resource state triggers notification. The notification criteria are similar to normal observation. The only difference is that Time Series option ignores the CoAP MAX-AGE option while normal Observe sends a notification when the MAX-AGE timer expires.
The T-Series row of Figure 8 shows the packet transmission for conditional observation type Time Series. According to the sensor readings of Figure 7, the client is notified at time 0 (during establishment of the relationship) and at times 10, 15, 20, 25, 30, 120 s (when the resource state changes).
4.2.3 Condition type 2: minimum response time (MinRT)
When the condition type Minimum Response Time (MinRT) is used in observation relationships, the server sends notification by leaving a fixed minimum amount of time between successive notifications. This condition type is highly valuable for systems where the value changes up and down very frequently and the observer is not interested in every change. Consequently, the server does not always send notifications every time the resource state changes.
The MinRT (10) row of Figure 8 shows a relationship where the client requests the server to be notified about state changes, but leaving at least 10 s between notifications. In this case, the client sends notifications at time 0 (during establishment of relationship), at times 10, 20, 30, and 120 s. If we closely look at the values at times 15 and 25 s, the values are changed after previous notifications, but since the difference between the current time and the last notification time is less than 10 seconds, there will be no notification sent to the clients at those times. Also note that, the MAX-AGE option has no impact here.
4.2.4 Condition type 3: maximum response time (MaxRT)
For this condition, the value specified in the condition value field gives the maximum time in seconds the server is allowed to leave between subsequent notifications. What this means is that the server has to send notifications in three cases: first, just like all other condition types and normal observation, at the beginning of the observation relationship; second, whenever there is a resource state change; and third, when there is no state change but the maximum response time is reached.
The MaxRT row of Figure 8 shows the notification pattern for a client requesting notification by setting Maximum Response Time to 60 s. Accordingly, the server notifies the client at time 0 (initial notification), at times 10, 15, 20, 25, 30, and 120 s (notification due to value changes), and at time 90 s (notification due to maximum response time). This condition type, in a way, is similar to normal observe with MAX-AGE set to 60.
4.2.5 Condition type 4: step
Depending on the environment where the server node is deployed, the state of a resource might change so frequently that excessive packets are generated. However, the changes may not be significant enough for the client to trigger any action. In such cases, the client may inform the server to send notifications only when the change is more than a specific value by using the Step condition type.
In the Step (1) row of Figure 8, the client informs the server to send notifications only when the change in value is greater than or equal to 1. As a result, notifications are only sent at time 0, 15, 25, and 30 s. Since the other changes are not significant enough, the server does not send notifications.
4.2.6 Condition type 5: all values<
In many cases, clients are not interested in state changes which result in values above a specific threshold. For example, to turn on a heater, the temperature should be below a specific threshold. In such cases, the sensor node responsible to regulate the behavior of the heater is not interested in values which are above the threshold. Hence, they may indicate this preference by using the AllValues< (All values less).
In the AllValues< row of Figure 8, we can see that the client is interested to get notified only when the resource state changes result in value below 23. Thus, notifications are sent at times 0, 10, 30, and 120 s.
4.2.7 Condition type 6: all values>
This condition type is similar to condition 5 above. The only difference is that the notification is sent only when the new value exceeds a threshold set by the client. As Figure 8 illustrates, the client is interested to receive notifications only when the resource state is changed and the resulting value is above 23. Consequently, the server sends notifications at times 0, 20, and 25 s only.
4.2.8 Condition type 7: value=
This condition indicates that a client is only interested in receiving notifications whenever the state of the resource changes and the new value is equal to the value specified in the condition value field. In our example of Figure 8, the client is interested in values equal to 23. This means that the server has to send notifications only when the value changes, and the new value is 23. Therefore, the notifications are sent at times 0 and 15 s only.
4.2.9 Condition type 8: value<>
Some applications might require the values they are monitoring to be constant. In health care system, machines at intensive care units (ICUs) the machines that monitor a patient's vital signs could be a good example. In such cases, there are vital signs including body temperature, heartbeat, and blood pressure that must be constant, showing that the patient is in a good condition. However, if the values differ from the specified value, it might indicate the patient needs attention. The Value<> (value different from) condition type indicates that the client should be notified when the value changes and is below or above the specified threshold. Once the notification has been sent, no new notifications are sent for subsequent state changes where the value remains higher or lower. As such, a single notification is sent whenever a threshold is passed in either direction.
The Value<>(23) row in Figure 8 shows that the client needs to be notified only when resource state changes result in values other than 23. As a result, notifications are sent at times 0, 20, and 30 s: notification at time 0 is the initial transmission; notification at time 20 s is sent because that was the first change that deviates from 23 (and it was below 23); and notification at time 30 s was sent because it was the first time the value goes below 23. The value changes at 10 s was not sent because it is still below the threshold, and value at 25 was not notified because it is still above the threshold (which was notified at time 20).
4.2.10 Condition type 9: periodic
Many environment monitoring applications may require receiving notifications periodically despite the resource state change. Such applications may use the Periodic condition type along with the period of notification. The Periodic(30) row of Figure 8 shows notification trends where a client requires to be notified every 30 s. In this example, notifications are sent at times 0, 30, 60, 90, and 120 s.
One can see clearly that, depending on the condition of interest, a different number of notifications will be transmitted over the constrained network. The exact number will depend on the condition type and, if present, the value in the condition option.
Our implementation of conditional observation is based on Erbium (Er) - a low-power REST engine for Contiki developed by Matthias Kovatsch together with the Swedish Institute of Computer Science. The Erbium REST engine includes a CoAP implementation that supports CoAP drafts 03, 07, 12, and 13. It also supports block-wise transfers and resource observation . To support normal observation, Erbium employs two different mechanisms at the server side. The first mechanism uses timers that are used to periodically check states of resources and notify observers whenever there is a state change. The other mechanism is event-based. Whenever an event (e.g., change in temperature) occurs, an event handler will be called, which, in turn, calls a function that notifies registered observers. In the remainder of this paper, we have used timer based, periodic checks for resource changes.
Memory requirements of Normal Observe and Conditional Observe
It can be seen from the table that the Text segment (ROM) requirement for Conditional Observe is slightly larger than Normal Observe. Similarly, the size of the BSS segment, which stores uninitialized variables, is larger in case of conditional observe just by a few bytes. As our findings in the following sections illustrate, 720 bytes overhead is affordable for the advantage that can be gained through the use of conditional observation, either from a performance viewpoint or from an application developer viewpoint.
6.1 Scenario 1: basic evaluation
We used different scenarios to illustrate the relevance of Conditional Observe as an extension to the Normal Observe functionality of CoAP. In the first set of experiments, we used Zolertia Z1 motes to be used as client and server nodes in Cooja. To capture the impact of network size on performance, we used between 0 and 6 intermediate Z1 nodes, which merely exist to act as routers between the client and server nodes. We selected the AllValues> (value-based) and Periodic (Time-based) condition types to compare the performance against Normal Observe. For every hop, and every condition value, we run the test 10 times to average the results. For sensor values, we generated 288 pseudo-random numbers between 17 and 26 (representing temperature values). The average of the values is 20. For AllValues> condition type, we tested three condition values: the minimum (17), the average (20), and the maximum (26). Every 5 s, the server is made to retrieve a value from an array of 288 numbers sequentially as a new sensor reading. As CoAP supports both confirmable and non-confirmable requests, we repeated the same experiment twice to see the impact of reliable communication on network performance.
We may learn two basic lessons from Figures 11, 12, and 13: first, this simple scenario shows that the solution we proposed works and is implementable in constrained devices such as Z1 motes; second, for such a simple scenario, using Normal Observe as mechanism to collect all resource state change in combination with client side filtering generates a larger amount of packets as compared to all other conditional observation methods. This leads to higher power consumption and, hence, low battery life. From these findings we can conclude that, even though the exact impact is heavily dependent on specific use cases, conditional observation can be considered a useful extension to normal observation.
6.2 Scenario 2: non constrained client - gateway – multiple servers
The tests above show that the new implementation can be run in constrained devices such as Zolertia Z1 motes which have 8-KB RAM and 92-KB ROM. The slight increase in memory requirement, especially to filter packets on the server, is an affordable trade-off to gain substantial energy saving and avoid congestion of the constrained networks.
6.3 Mathematical evaluation
The previous tests show that conditional observation can achieve a significant gain in terms of the reduction of the number of transmitted packet and subsequently of the reduction in power consumption of constrained devices. Of course, the exact gain depends largely, amongst others, of the frequency of resource states and the specific conditions interested in. In this subsection, we will show this potential gain of conditional observation through a mathematical evaluation.
The power consumption values are all known from the datasheets of the chips of the constrained devices, the time values for the radio can be derived from the MAC protocol and the number of packet transmissions and receptions and the time values for the CPU can be derived from experimental results. To compare the power consumption difference between Normal and Conditional Observe and to keep the mathematical model sufficiently simple, we make the following assumptions:
We use value-based condition types.
The resource state changes every S seconds.
The device uses a duty-cycled low power listening protocol. The length of the duty cycle is L, and the duty cycling value is d (only d% of the time the radio is active, listening for incoming packets in order to save energy). When the device needs to transmit a packet, it has to turn on the radio for the entire period L.
The probability that the condition is not fulfilled is p.
The value of MAX-AGE is equal to 60 s.
The transmission of a notification requires only a single packet.
The notifications are non-confirmable messages, so the server generating the notifications is not receiving any packets.
For Normal Observe, every S seconds the device will do some processing and transmit a notification. In case S becomes larger than Max-Age, a notification is also sent every time MAX-AGE expires. This brings the total number of notifications sent, N, equal to CEIL (S/Max-Age).
Taken from the data sheets of the Z1 mote.
Power = Current × Voltage
Based on ContikiMAC LPL
Approximation based on extensive experiments.
Average percentage of time the CPU is active, based on extensive experiments.
We see that for increasing values of the probability p, i.e., the probability that the condition is not fulfilled, the reduction in energy consumption also increases. For a fixed time S between resource changes, and thus a fixed amount of potential notifications, an increasing probability p implies that less notifications have to be sent compared to normal observe, leading to a reduction of the energy spent on transmitting these notifications and thus of the overall energy consumption. This is in line with our experimental evaluation. Further, we notice that, for a fixed value of p, smaller values of S, the time between resource changes, leads to major reductions in energy consumption. On the other hand, for larger values of S, the potential energy reduction gradually decreases as can be seen from the zoomed-in area of the chart. For values larger than 30 s the average reduction varies between approximately 2% and 6%. The fact that the curves periodically rise and fall is due to the impact of the MAX-AGE value, which causes the number of notifications to be sent by Normal Observe to be a step function expressed by CEIL(S/MAX-AGE).
Further, in case one of the resources has a smaller MAX-AGE value than the default value of 60 s, the reduction also becomes bigger: between 2% and 6% for S values between 30 and 300 s and MAX-AGE equal to 60 s; between 4% and 10% for S values between 30 and 300 s and MAX-AGE equal to 30 s; and between 20% and 30% for S values between 30 and 300 s and MAX-AGE equal to 10 s. Last but not least, there is also the effect of larger-scale, multi-hop networks with multiple servers. In this case, every single notification will result in multiple packet transmission through the network, increasing the TX energy consumption in all intermediate nodes and thus contributing to the overall reduction of the network lifetime.
A last aspect that has not been discussed so far is the impact of multiple conditional observation relationships on a single resource (i.e., by different clients). For normal observe and in the presence of an intermediary, the intermediary can aggregate multiple observe relationship into a single one. This means that the intermediary establishes an observe relationship itself on behalf of multiple clients and delivers the resulting notifications to all clients. This way, notifications have to travel through the network only once. When using conditional observations in the presence of an intermediary, the possibility to aggregate different conditional observations into a single conditional observation relationship strongly depends on the condition type and associated values. In this case, it is possible that no optimal aggregation can be found, reducing somewhat the overall performance.
From the previous discussion, it has become clear that the actual advantage in terms of performance gain (energy reduction) of conditional observations is heavily dependent on specific-use cases. Apart from that, there is the additional advantage that it offers easy-to-use primitives to collect sensor data of interest, which have a small footprint and which are reusable by all CoAP resources hosted on a device. To concretize the advantage of having conditional observation as an extension to CoAP, we will now discuss in more detail three real-life IoT-use cases.
7.1 Heating and cooling systems
Smart buildings, heavy machineries, and greenhouses use temperature sensors to regulate their environment. Input from sensors will be used by heating and cooling systems, i.e., the actuators, to take the necessary actions to maintain the temperature at a specified level. If the temperature exceeds beyond a certain level, cooling systems at particular locations need to be activated to lower the temperature. Similarly, if it is below a certain threshold, a heating system has to increase the temperature.
When using wireless embedded systems to monitor and control the environment, conditional observation may play a significant role in such systems. Consider a building equipped with such a system. If the temperature in the building has to be maintained between 19°C and 22°C, the sensors have to inform either the heater or the cooler if the temperature is out of this range. To realize this, the heating or cooling system that is linked to a sensor may send two conditional observation requests. The first condition type should be AllValues < 19 and the second should be AllValues > 22. When the server receives these requests, on separate port numbers, it stores them as two different requests and sends notifications to the client when one of the two conditions is fulfilled.
7.2 Smart environment monitoring
There is a growing concern of pollution everywhere in the world. Pollution, be it air pollution, water pollution, or land pollution, is the introduction of harmful substances to clean sources (air, water, etc.). Air quality index (AQI) is widely used to measure the level of pollution of air by different pollutants such as ground-level ozone, particulates, sulfur dioxide, carbon dioxide, carbon monoxide, and nitrogen monoxide. The AQI values fluctuate substantially depending on various situations. Most countries divide the AQI values in different categories and take different actions depending on the level of AQI.
Using conditional observation, much more flexibility is introduced and system efficiency can be. The client (e.g., the gateway or an application in the cloud) may establish conditional observation with the servers (sensor nodes) stating its interest to be notified periodically. Here, the periodic condition type can be used for the subscription. Once this observation relationship is established, the servers will generate notifications periodically. It is also possible to further refine notifications based on prevailing circumstances. For example, in normal situations, where the concentration of pollutants is very low, there is no need to send notifications to the gateway very frequently. So, the notification interval can be set, for instance, to 1 h. However, as soon as the pollution level increases, which can be detected by establishing another conditional observation, the client may opt for more frequent updates (say every 5 min) by sending an updated conditional observation request which eventually removes the old observation relationship and establishes a new one with a higher frequency.
7.3 Sleepy nodes
Sleepy nodes are devices which occasionally go to a low-power mode by cutting power to unnecessary components to save energy. Some devices cut power only to the radio system while the other components run as usual. At any time, the device could be at a sleeping state or awake. But, in most cases the sleeping time is much larger.
A client request arrives at the proxy. The server is sleeping (SleepState = 0). The proxy buffers the request and sends a response to the client telling it to be patient for the actual response. Next the proxy starts to continuously check the server to see if it is awake.
As soon as the proxy detects the server is awake (meanwhile retrieving the value requested by the client and delivering the response to the client), it sends a conditional observe request indicating its need to be notified when the server wakes up (SleepState = 1). This can be achieved by using the VALUE = condition type. The server adds the proxy to the observers list.
After some time, the server may go to sleep for a long time (SleepState = 0). While the server is sleeping, clients may send GET requests to the proxy. Since the proxy now knows the server is sleeping, it buffers all requests and sends back patience responses.
When the server wakes up, it sends a notification to the proxy indicating its sleep state has changed, back to Awake.
When the proxy gets the notification, it sends all buffered requests to the server.
Finally, the server sends the responses directly to the clients. As an optimization, the proxy may aggregate similar requests into a single request. Communication with the sleepy node will be even more efficient if the clients themselves register as observers requesting the server to notify them when a particular criterion is met. In this case, once the server is awake and knows clients' requirement through the proxy, all subsequent notifications will be made directly to the clients whenever the criterion is met. This is done without the involvement of the proxy.
In this paper, we presented the concept of conditional observations as an extension to the CoAP protocol in general and the Observe option in particular. We presented comparative results of using normal observation and conditional observation by implementing this functionality on a constrained device. We also presented theoretical evaluations of normal and conditional observation. From both the experimental and theoretical results, it is evident that the conditional observations are very useful extensions to the basic observe behavior, both from an application point of view and from a network efficiency point of view. It enables clients to receive notifications that contain only state changes they are interested in. This has a twofold advantage: an application has the expressiveness to selectively collect data and the data of no interest does not have to travel over the network. The latter advantage will become even more important in larger constrained networks where notifications have to travel over multiple hops. As such, conditional observations can greatly contribute to the reduction of battery consumption and increase of network lifetime. In addition, many scenarios can be thought of that can benefit from this functionality. Finally, our implementation shows the feasibility of implementing this functionality on very constrained devices.
The research leading to these results has received funding from the European Union's Seventh Framework Programme (FP7/2007-2013) under grant agreement no. 258885 (SPITFIRE project). We would also like to acknowledge our co-authors of the IETF CoRE conditional observe draft.
- Shelby Z: Embedded web services. IEEE Wireless Communications 2010, 17: 52-57.View ArticleGoogle Scholar
- Montenegro G, Kushalnagar N, Culler D: RFC4944 - Transmission of IPv6 packets over IEEE 802.15.4 networks, IETF Trust. : ; 2007.Google Scholar
- Hui J, Kelsey R, Levis P, Pister K, Struik R, Vasseur JP, Alexander R: RFC6550 - RPL: routing protocol for low power and lossy networks, IETF Trust. : ; 2012.Google Scholar
- Shelby Z, Hartke K, Bormann C: Constrained application protocol (CoAP): draft-ietf-core-coap-13, IETF Trust. : ; 2012.Google Scholar
- Shelby Z, Hartke K, Bormann C: observing resources in CoAP - draft-ietf-core-observe-07, IETF Trust. : ; 2012.Google Scholar
- Vasseur JP, Dunkels A: Connecting Smart Objects with IP: The Next Internet. San Francisco: Morgan Kaufmann; 2010.Google Scholar
- Shelby Z: RFC6690 - Constrained restful environment (CoRE) Link Format, IETF Trust. : ; 2012.Google Scholar
- Roach AB: RFC3265 - Session initiation protocol (SIP): specific event notification. IETF Trust. : ; 2002.Google Scholar
- Stanford-Clark A, Truong HL: MQTT for Sensor Networks (MQTT-S) Protocol Specification Version 1.1. : IBM Corporation, Armonk; 2008.Google Scholar
- Souto E, Guimarães G, Vasconcelos G, Vieira M, Rosa N, Ferraz C, Kelner J: Mires: A Publish/Subscribe Middleware For Sensor Networks. London: Springer; 2005.Google Scholar
- Lai S, Cao J, Zheng Y, Ware PS: A Publish/Subscribe Middleware Supporting Composite Event In Wireless Sensor Network. Washington: IEEE Computer Society; 2009.View ArticleGoogle Scholar
- European Telecommunications Standards Institute (ETSI): Machine-to-Machine communications (M2M). ETSI TS 102 690 V1.1.1. France: ETSI; 2011:10.Google Scholar
- Shelby Z, Vial M: CoRE Interfaces: draft-shelby-core-interfaces-3, IETF Trust. : ; 2013.Google Scholar
- Na A, Priest M (Eds): Sensor Observation Service. Wayland: Open Geospatial Consortium Inc; 2007.Google Scholar
- Li ST, Hoebeke J, Jara AJ: Conditional Observe in CoAP: draft-li-core-conditional-observe-03, IETF Trust. : ; 2012.Google Scholar
- Kovatsch M, Valencia SD: A low-power CoAP for Contiki. In Proceedings of the 8th IEEE International Conference on Mobile Ad-hoc and Sensor Systems (MASS 2011). Amsterdam: IEEE; 2011:855-860.View ArticleGoogle Scholar
- Ishaq I, Hoebeke J, Rossey J, De Poorter E, Moerman I, Demeester P: Facilitating sensor deployment, discovery and resource access using embedded web services. Palermo, 4–6 July. In International Workshop on Extending Seamlessly to the Internet of Things (esIoT). Amsterdam: IEEE; 2012.Google Scholar
This article is published under license to BioMed Central Ltd. This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.