Summary
CoAP is a Representational State Transfer style (RESTful) protocol developed for constrained devices that allows interactions between clients and servers over the Internet. For simplicity, CoAP uses UDP as the transport protocol by default. Since UDP does not implement end-to-end reliability but this may be required by the application, CoAP introduces optional application layer end-to-end acknowledgements (ACKs). By setting the confirmable (CON) flag in an outgoing CoAP message, an end-to-end ACK is requested from the destination node. If no ACK is received within the retransmission timeout (RTO) interval, a retransmission is initiated for the outstanding transaction.
Contiki OS is an open source operating system designed for constrained devices and the Internet of Things and is the choice of many sensor motes. Fig. 1 shows the IETF protocols over IEEE 802.15.4 and how they are implemented in Contiki OS, along with other Contiki specific layers. It implements the uIPv6 stack that provides the functionality for IPv6 networking. uIPv6 includes Contiki-RPL, an implementation of the routing protocol for low-power lossy IPv6 networks, and SICSlowpan, an implementation of the 6LoWPAN adaptation layer. Contiki also comes with the Erbium CoAP implementation.
Fig. 1 : A comparison between the IETF communication protocol stack (left) and its implementation in Contiki (right).
RPL, as part of the uIPv6 Stack, is responsible for the network formation, packet routing and the maintenance of the network topology. In RPL, one or more root nodes generate a network topology that trickles down to the leaf nodes, resulting in Directed Acyclic Graphs (DAGs). The RPL objective function (OF) determines which links in the network are chosen to be part of RPL DAG.
The simulated network topologies used for CoAP performance evaluation include two types of nodes that differ in their resource requirements: CoAP nodes and RPL border routers. According to the RPL specifications, when a node is missing a routing table entry for the destination node, it forwards the packet to the next node in direction of the RPL-root (border router). Only one border router exists in every simulation. In the case that none of the nodes on the way to the RPL-root has valid routing information stored, the RPL-root eventually receives the packet. The RPL-root then looks up the entry with the destination address for the packet from the routing table and forwards it to the next hop in direction of the destination node. To achieve that, the RPL border router needs to be able to store routing table entries for all possible destinations in the network, which is why the RAM requirement of this node is relatively high.
Fig. 2: The three network topologies used for performance analysis (grid, dumbbell, and chain). The width of a square corresponds to 10 m. Nodes with a blue circle are sink nodes for CoAP messages. Green nodes are RPL border routers.
In each of the network topologies, there is always a single RPL root, while the rest are CoAP nodes, out of which one or two are set as the destination (sink) nodes. Figure 2 depicts snapshots of the Cooja simulator GUI showing the two-dimensional positioning of the nodes for the three different topologies. The transmission range is set to 10 meters, whereas the interference range is set to be twice of the transmission range, i.e., 20 meters. The distance between nodes in the chain topology is chosen in such a way that only direct neighbors are in transmission range. Since the interference range is twice the transmission range, a packet transmission may interfere the radio of nodes up to two hops away. Each node may therefore have up to two neighbors. The same distance rule applies for the grid topology, where each node may have up to 4 direct neighbors. In the dumbbell topology, the nodes on the half circles are exactly 10 meters away from the node that is part of the dumbbell’s axis.
For the simulations carried out in this paper, the neighbor tables are able to store information about all direct neighbors. The RPL border route has a routing table large enough to store entries for all nodes of the network. Due to the strict RAM limitations of CoAP nodes, their routing tables need to be smaller. Adjusted to the introduced topologies, the storable amount of RPL neighbor and routing table entries is set to the values shown in Table 2.
| Tables | Chain Topology | Dumbbell Topology | Grid Topology |
|---|---|---|---|
| Neighbour Table (all nodes) | 2 | 10 | 4 |
| Routing Table (CoAP node) | 10 | 10 | 20 |
| Routing Table (RPL bord. router) | 20 | 20 | 48 |
The RPL border router should be located in a central position of the network to make it equally accessible from all nodes in the network. In the chain topology, the RPL border router is located in the middle of the chain. In the grid it is located at the center of the topology, where the 4th line of nodes crosses with the 4th column. In the dumbbell topology the RPL border router is the center node that connects the two laterals of the dumbbell formation. In all the topologies, CoAP messages are created by the CoAP nodes and directed to one or two sink nodes. Except for the dumbbell topology, each network has a single sink, marked with a circle in the topology overviews. In the dumbbell topology there are two sink nodes.