## 3 DiRPL: RPL-Based Resource and Service Discovery for Constrained IoT Devices
### RPL-Based Resource Discovery  
As previously anticipated, in this work a novel approach to RD and SD, denoted as DiRPL and based on the RPL handshake and composed of three main phases (initialization, node discovery, and resource identification), is proposed. While the RPL-based handshake helps in organizing a constrained network in a DODAG, facilitating the management and the data collection of the network itself, it does not provide an RD mechanism that matches well with most of the adopted IoT-oriented protocols, such as CoAP, thus forcing the LEN to self-advertise. This task, however, is carried out by a powerful device--namely the BR--and this is one of the reasons that motivates the approach proposed in this work. The initialization phase acts as follows: after the BR module on the TelosB mode boots up, the RPi which the TelosB mote is attached to: (i) loads the CoAP server (as highlighted in Section 3.1) hosting the local resource directory; (ii) loads a CoAP client in charge of observing the CoAP resource /network/last_entered_node; and (iii) powers on the local caching processes. Finally, the CoAP client on the RPi starts observing the CoAP resource itself exposed by the TelosB. Once the initialization phase has completed, the 6 LoWPAN-oriented network is operational and can discover every new appearing IoT node (i.e., a LEN). As previously mentioned, the node discovery procedure exploits the RPL handshake for network registration. More precisely, the message exchange, shown in Figure 1, can be detailed as follows (numbers in Figure 1 refer to the step numbers below). 1. When a joining node (LEN) appears in the coverage area of the 6 LoWPAN network, it starts the ND procedure and sends a DIS message to the node that has been elected as its default parent. 2. The parent node receives the DIS packet and replies with a DIO message. In this way, the LEN gathers knowledge about the existence of the BR in the 6 LoWPAN network, and the DOGAG governing the network itself. 3. The LEN generates a DAO packet that will be forwarded up to the BR through the DODAG. 4. The reception of the DAO packet by the BR invokes the creation of a corresponding routing entry in the routing table of the BR itself and, since the BR is hosted on the TelosB mote, this routing insertion triggers an update of the CoAP observable resource /network/last_entered_node. 5. Recalling the fact that, during the network boot up phase, the CoAP client (internal to the RPi) has started an observing relation on the CoAP resource /network/last_entered_node exposed by the TelosB mote, the updates of this CoAP resource are received and propagated by the BR to its upper layers, for further processing tasks. Once the previously detailed steps have been taken, thus completing the node discovery phase, the following RD/SD procedure, shown in Figure 2, is ready to be executed (with numbers in Figure 2 referring to the step numbers below). Figure 1: Node discovery procedure embedded in the RPL discovery handshake. The numbers in the figure refer to the node discovery phases. The CoAP client running on the RPi, triggered by the CoAP Observe notification, sends a CoAP GET request to the CoAP resource /.well-known/core of the LEN. 7. Since the LEN runs an internal CoAP server, it thus can handle the incoming CoAP GET request on its /.well-known/core resource. It replies (in CoRE Link format) to the CoAP client on-board of the RPi with the list of its maintained CoAP resources and services. 8. Upon reception of the list of CoAP resources hosted by the LEN, the CoAP client running on the RPi requests the CoAP server, hosted on the same platform, to create several CoAP resources equal to received resource list's size.