## 6 Implementation and Evaluation
### Performance Evaluation
#### 6.3.1 Experiment Setup  
In our test we used a star topology with the gateway (node ID 0) in the middle of the five-leg star (Figure 16) and the nodes along the legs at 50 m distances. The transmission range (55 m) is enough to make the signal travel from one node to the other node on the same leg, but does not allow the signal to be heard between nodes on different legs. The interference range is 105 m, so that it covers the distance between three nodes on the same leg. The reason for selecting this topology is that it allows minimizing the impact of the underlying routing protocol on our measurements, as each node has only one deterministic route to the gateway. The gateway is running the example rpl-border-router provided by Contiki and therefor it is the RPL DODAG root, delegates the global IPv6 prefix and routes traffic to and from the constrained network. All other nodes run the Erbium server extended with resource profiles and multicast support as discussed in Section 6.1. Table 1 summarizes the parameters of the simulations in Cooja. Since evaluating the performance of MAC and routing protocols is beyond the scope of this work, we had to take special care during the experiments to make sure that what we are observing is not a result of routing or MAC errors. For example, when introducing link errors in the simulations, routes can get lost or can be changed which has a considerable impact on the delivery rate of packets in the LLN. One solution would have been to use static routes. This is however not practical, since each node needs to be programmed with its own routes each time we change anything to the topology. To avoid such manual reconfiguration and since a stable version of RPL is available within Contiki, we used RPL as a routing protocol in all of the experiments. However, in order to minimize route changes from impacting our results we have taken the following two measures in all experiments:  
1. Before sending any CoAP messages in the LLN, we wait for some time to allow RPL to establish routes to all nodes. In our chosen topologies, waiting for 2 min was in most cases sufficient to achieve this goal. In a few cases (with a high percentage of packet loss) we had to wait more than an hour, since the time between RPL neighbor updates is exponential up to a certain value. 2. The Contiki implementation of RPL relies on Contiki to maintain the neighbor table. Contiki in turn removes a neighbor if it does not hear its heartbeat a consecutive number of times (three by default). In very lossy networks (such as in our experiments with high packet loss) this behavior might lead to neighbors being removed and thus all routes via that neighbor as well. However in all of our experiments the nodes are static and never disappear from the network. As such they should not be removed from the neighbor table. To achieve this goal we have changed the Contiki configuration parameter UIP_CONF_ND6_MAX_UNICAST_SOLICIT from its default value of 3 to 100. This allowed all experiments to be completed without routes to the nodes being lost. With these two measures in place it was possible to get stable routes during the experiments. The other factor that may heavily impact the measurements is the used MAC protocol. In order to save energy, MAC protocols for LLNs use Radio Duty Cycles (RDC) to shut down their radios when not in use. Contiki has its own MAC protocol, called ContikiMAC, with a good RDC schema. However ContikiMAC requires more resources than other MAC protocols. In our experiments we also need, next to CoAP and multicast, debug information in order to be able to collect measurement statistics. As such, it was impossible to fit CoAP, multicast, RPL, debug info and ContikiMAC on the used Z1 motes. Instead of ContikiMAC we therefore used null-rdc, which is Carrier Sense multiple Access (CSMA) MAC protocol without RDC (radio always on). While using null-rdc is not realistic for battery-powered devices, it still helps avoiding delays in the collection of measurement statistics as imposed by the RDC protocols.