## 3 The Proposed Approach
### Packet Size Evaluation and Comparisons  
To implement our solution, we introduce a _Service Management_ (SM) packet which encodes three kinds of information: (i) type of operation; (ii) service identification information; (iii) service delivery method. Table 1 shows the size of all fields. Each of them corresponds to a parameter of the service characterization in Section 3.1, but the following:  
* _Type:_ identifies the type of message (_Confirmable_, _Non Confirmable_, _Acknowledgement_, _Acknowledgement plus data_);
* _Code:_ specifies the kind of method to query a service (_i.e.,_ to access it, to modify the subscription, to unsubscribe). In case of response, it contains a response code;
* _Message ID:_ detects duplicates and matches confirmable or reset messages with their acknowledgement;
* _Length:_ length of the packet. The SM packet is implemented as an ICMPv6-like packet. Both description and performance analysis of packet retransmission, loss handing, duplicate detection are out of the scope of this paper even if _Message Identifier_ and _Type_ fields have been thought to support future mechanisms addressing those problems. In the remainder of this section we compare our proposal, which has a _service_-oriented nature, to the two CoAP solutions proposed in the IETF CORE WG and described in Section 2. Since these solutions are resource-oriented, an extra attention will be paid while comparing. A CoAP message consists of a header followed by options in _Type-Length-Value_ (TLV) format and a payload [18]. Only the header size is fixed at 4 bytes, the other two fields are optional and of a variable length. In official IETF documents, the authors suggest developers to be frugal in the packet size choice for their applications since it may cause a very important fragmentation phenomenon, especially at the adaptation level (6 LoWPAN messages are limited to 127 bytes including various \begin{table}
\begin{tabular}{|c|c|l|c|} \hline
**Name** & **Mandatory/Optional** & **Description** & **Length** \\ \hline Type & M & Message Type & 2 bit \\ Code & M & Kind of operation or response code & 1B \\ Message ID & M & Message Identifier & 2B \\ Length & M & Message Length & 1B \\ Version & M & Version of the Service ID numeration & 3 bit \\ Service ID & M & Identification code for the service type & 5B \\ Description & O & Further service type identification & 20B \\ Obs & M & Flag for the _observe_ delivery method & 1 bit \\ Pn & M & Flag for the _periodic notification_ delivery method & 1 bit \\ Sq & M & Flag for the _simple query_ delivery method & 1 bit \\ X & O & Numeric variable to set the periodicity & 2B \\ Y & O & Numeric variable to set the periodicity & 2B \\ Z & O & Numeric variable to set the periodicity & 2B \\ \hline \end{tabular}
\end{table} 
Table 1: Packet fields length. overheads). For this reason, the CoAP authors claim that \"_a CoAP message, appropriately encapsulated, should fit within a single IP packet_\" (intending IPv6 datagram which has an MTU of 1,280 bytes); thus defining a kind of generic upper layer. Figure 3 shows the potential maximum values of the CoAP packet size. It is obtained by considering the information given in [18], related to the information (options, payload) contained in each packet according to the used method (GET, PUT, POST, DELETE) associated to a _resource_. For each interaction, a distinction is made between the CoAP packet sizes of a request and of a response. We assumed the maximum length for the options and 1,024 bytes for the payload size (this value is not fixed since it depends on the resource representation length). The \(n\) parameter in the labels refers to the fact that some options may appear _one or more_ times in the same packet. In order to keep CoAP packet size near to the suggested maximum size, \(n\) in this case has to assume very low values (_n_ = 1, 2).