# A Power Planning Algorithm Based on RPL for AMI Wireless Sensor Networks
## 4 DODAG-Oriented Power Planning Algorithm
### Remarks on the Centralized Operation of the Algorithm  
This section describes how the proposed algorithm could operate together with a centralized control application. The goal of the control application is to collect the necessary information for the algorithm execution and apply the produced transmission power setting. The principles described here are based on experiments conducted with the implementation of the 6 LoWPAN-RPL stack that exists in the Contiki operating system [23]. The specification of 6 LoWPAN [19] was produced by a working group of the IETF, aimed to optimize the use of IPv6 within low-speed wireless networks based on the IEEE 802.15.4 standard. Its main feature is a header compression mechanism to increase the amount of information (payload) that can be transmitted in a frame having a maximum transfer unit of 127 bytes. This is done by removing a number of fields in IPv6 and user datagram protocol (UDP) headers, either because they have known values, or because the values can be inferred from fields in the IEEE802.15.4 header. The 6 LoWPAN border router (6 LBR) supports the translation between regular IP and 6 LoWPAN packets, and implements the functions of the DODAG root. The control application uses the constrained application protocol (CoAP) to format the data and to ensure the delivery of control messages. CoAP is an application protocol designed specifically for the low power and lossy networks, providing an alternative to XML and HTTP [24]. CoAP uses a formatting style called representational state transfer (REST), which uses the same verbs of HTTP, such as GET, POST, PUT, and DELETE. The REST style uses uniform resource identifiers to interact with external objects, providing access through the verbs listed before. Figure 3 illustrates the principles of the centralized operation. One can observe an instance of 6 LBR, provided with the Contiki platform. The control application runs outside the RPL-6 LoWPAN network and communicates with 6 LBR and with the AMI network nodes. Communication with 6 LBR is necessary because it allows the control application to know what nodes are running at a given moment. The example shows an AMI network with six nodes, each one including the metering and communication functions. The communication function supports the exchange of messages between the metering devices and the utility, as well as communication between the nodes and the control application. The first is not shown in Figure 3, but the last is performed through CoAP messages. One can observe a CoAP client running with the control application and a CoAP server running inside the nodes. The planning algorithm assumes to know the location of each node. Because the AMI network is a structured wireless network, location information is pre-configured in each node before field deployment and collected by the control application during network operation. The algorithm computes an estimated initial value for ETX, which is configured in each node before starting network operation. In addition, the initial power configuration is computed offline and it is stored in the nodes before the deployment. When the nodes begin to operate, RPL messages are exchanged, and the 6 LBR becomes aware of active nodes. When 6 LBR identifies a node, it reports to the control application, which then uses GET messages to read its location, neighbors and ETX. The GET messages include a registration to observe the resources (neighbors and ETX). In the CoAP terminology, the client retrievesa representation of the resources and requests the server to update this representation. When a node starts unicast communication, the MAC layer of Contiki updates the current neighbors and the quality of the links (ETX). The CoAP server notifies these resources periodically to the CoAP client, which, in turn, informs the control application.