## 5 Final Remarks
### Real World Scenario  
Let us now focus on a real world sample environment. In the reference scenario (Figure 11(b)), devices are classified according to their capabilities into different level (Level 1, 2, and 3). During the network startup, they get to know each other (through their IP addresses, device level, and service IDs). Let us suppose that the one shown in Figure 11 is the object domain of a domotic environment for the two models under analysis. A query from the Internet reaches a leaf node (_i.e._, sensor or any kind of house facility) of the object network for accessing one of its services passing through the root and an intermediate node.  
For the CoAP model nodes (described in [24]) 6 LoWPAN Node (6 LN), 6 LoWPAN Router (6 LR), and 6 LoWPAN Border Router (6 LBR) are defined. All of them implement the CoAP layer and, therefore, they exchange packets (in this case a GET exchange occurs) containing application-level information (Figure 11(a)) with a representation of the accessed resource (as illustrated previously).  
For the proposed model case, CoAP communication is kept among devices of Level 2 and Level 3 (Figure 11(b)), but CoAP packets have two extra options that contains the information of the _Version_ and _Service ID_ fields of Table 1. Once the requesting CoAP packet with the GET request reaches the Level 2 node, it switches the communication up to the _Network Level_ by using the proposed SM-packet exchange illustrated in Section 3. In particular, the _request_ SM-packet will be of _Confirmable_ type, with  
Figure 11: Communication models: (**a**) CoAP model; (**b**) proposed model.  
the _AccessCode_ in the _Code_ field. The _sq_ flag will be set up for indicating a simple query and the _Service ID_ will identify the queried service. The response packet (_i.e._, the one the Level 1 node sends back to Level 2) will be of _Acknowledgement plus data_ type and it will contain the payload. Once the response is received, the Level 2 node will convert it back into a GET response for the Level 3 node.  
The SM packet exchange is independent from the link layer technology; hence, it is _extensible to any network supporting a 6 LoWPAN exchange_. Moreover, Service ID-based encoding helps to implement a uniform resource naming in the IoT since, by using the CoAP model, two objects that deliver the same services will potentially advertise them differently. This means that programmers who want to write back-end applications or middleware solutions for the IoT, by using our solution, will not need to first discover the particular resource representation of the underlying object domain, but they could just refer to any IoT service by referring to its Service ID.  
It has to be noticed that, the _(IP address, Service ID)_ couple uniquely identifies a certain service on a device. Basically, it gives the same information provided by the _(IP address, transport port)_ couple in a standard TCP/IP network. Moreover, _Message ID_ and _Type_ fields of the SM packet are means to handle issues like packet losses, retransmissions and, duplication of packets whose discussion, however, is out of the scope of the present paper.  
As regards the application-level information care, this is up to application-level nodes. Constrained nodes will simply return information related to their services as foreseen for the kind of services they deal with. In other words, for each kind of service (Service ID), a specific response format will have to be expected. Once the reply is obtained from constrained nodes, it will be shaped into the requested format by the first application level entity in the path.