## 2 Research Problem Statement  
Let us focus on the case where a user tries to access a node service by implementing the CoAP method and the server has to send the client back a _large_ resource representation. In the considered protocol stack (see Figure 1), IEEE 802.15.4 covers the physical and MAC layers. Immediately above, the 6 LoWPAN adaptation layer makes constrained nodes able to support IPv6 and it is responsible for handling IPv6 header compression, fragmentation, and reassembly. The transport protocol is UDP. By considering that IEEE 802.15.4 MAC layer leaves just 81B frame space to the upper layers, from the viewpoint of a constrained node, two events may occur:  
* fragmentation;
* message rejection because of too small a buffer. In the _first_ case, the client-server exchange takes place and the packet at IPv6 level is encapsulated into one (or just a few) IPv6 datagrams. Notwithstanding, the 6 LoWPAN adaptation layer processes the information and fragments it into a number \(p\) of frames. Thus, the number of bytes the constrained node exchanges during the CoAP packet transmission, proportionally depends on \(p\). This means that handling a large packet correspond to overload the 6 LoWPAN nodes, which have to process a larger amount of bytes with respect to IPv6 nodes. Moreover, until the node has not processed all fragments, it cannot serve any other request. In the _second_ case, the node is not even able to receive the CoAP packet, since the buffer it can allocate is not large enough to contain it all. To deal with this critical issue, CoAP authors simply introduce the 4.13 response code (_Request Entity Too Large_) which should be sent by the server to tell the client that the packet has been truncated. In order to solve the above mentioned problems, the \"_Blockwise transfer_\" mode has been introduced in the literature [15]. This is a new kind of data transfer for CoAP which implements a sort of application-level fragmentation that splits a single REST operation into multiple CoAP message exchanges. In conclusion, the amount of data that in the previous case was sent by means of a single  
Figure 1: Object Protocol Stack. CoAP packet, it is now sent through several CoAP packets. Despite this method solves the packet rejection problem, the added overhead further degrades the performance. In conclusion, in both cases constrained nodes have to deal with an increase in the overhead in terms of bytes sent. In the remaining part of the paper we will show how this corresponds to an increase in the energy consumption, which obviously reduces the battery lifetime. Even though in the next future constrained nodes will be less constrained thanks to extra memory and more powerful processors, the question we should reflect on is: _is this the wisest way to exploit the nodes and the network resources?_ The analyses in this paper aim at providing more elements to answer this question. Another open issue is related to the definition of the resource representation used in CoAP to identify the services of the constrained nodes. Being this left to manufacturers, two objects that deliver the same services will potentially advertise them differently. Thus, programmers who want to write applications for the IoT will need to first discover the resource representation format and semantic [16]. This also means that the same application will not work for objects of different manufactures as, otherwise, an intermediate entity should solve the semantics \"mismatches\" in between. Our proposed solution is based on the introduction of a global unique identifier for the service type. If on the one hand this would let constrained nodes to save their energy and computational resources (as it will be shown in the next sections), on the other hand this helps the IoT to evolve in a more \"_unifying_\" _fashion_. Furthermore, the solution is intended to be fully _compatible_ with the existing CoAP standard because the service identifier can _easily be incorporated into the CoAP resource representation format_ within one packet option.