## 5 Final Remarks
### Addressing Space and Scalability  
In this section we are interested in answering the following questions: (i) How can we be sure that the definition of the Service ID, together with the fields in Table 1, will allow to address all the existing services? (ii) When considering new objects (and hence services) that may be created in the future, how will this solution incorporate them and adapt to any other future scenario? Since an exact _a priori_ estimation of the number of service types that will characterize the future IoT is infeasible, we designed our service characterization model so to make its encoding mechanism flexible and capable of enabling future extensions. What we propose is a progressive migration to a IANA numeration scheme that allows the inclusion of new services thanks to the following model attributes:  
Figure 9: Energy Consumption percentage distribution among the reception (RX), transmission (TX), processing (CPU), low-power-mode (LPM) components for different CoAP exchanges (ContikiMAC case). * the _Version_ field that identifies the version of the IANA numeration in use
* the _Description_ optional field, thought as an identifier of those services not yet included in the IANA numeration. For example, in the case of a new actuator (not yet included in the IANA numeration), the Description field may be used to store an object-related identifying information such as _Universal Product Code_ (UPC) or _European Article Number_ (EAN)  
To show the benefits of defining a compact and fixed service type encoding mechanism, the estimation of a Service ID-field size that could fit a worst case analysis is required. As regards the capacity of a 5B-long code to address the future _Service ID_-space expansion, a first indication comes from the Moore's and the Metcalfe's Laws. In fact, when considered together, they mean that continued network expansion is inevitable. However, they predict an increase in the number of _nodes_ not in the number of _node types_. Past experiences in Telecommunications tell us that the latter number is usually much smaller and it also increases much more slowly. In conclusion, a 5B-long Service ID sounds as a comfortable estimation, since it allows the usage of an address space of 24 elements. It has to be noticed, that this estimation considers _the number of service types_ statistically correlated to the _number of device types_. This sounds reasonable because, even if more than one service can be advertised by a certain device, the same service may belong to different devices. Giving details on the specific IANA numeration is out of the scope of the present work. Thus, hereafter, we describe the reasoning that brought to the envisioned numeration to allow the reader to achieve a conceptual comprehension of the same. We started by considering the kind of objects that belong to the IoT, and grouping them into three families: sensors, actuators, and identifiers (_i.e._, RFID tags). Consequently, we looked for any existing classification of the number of device classes for each family, trying to foresee their possible future expansion. For the sensor's family, we found a starting approximation for the number of elements in [23] where a list of existing sensors can be found. We saw that 1 byte was enough to address all the sensors types listed there. Anyway, as shown in Figure 10, we added 1 extra byte. In the tags' family we could just start distinguishing into active, passive, and semi-passive tags. At this beginning level, we classified the actuators into simple (just _on_ or _off_ state are allowed) and complex one (all the others). Figure 10: Rough Service ID classification. The described reasoning is intended to give an idea of the kind of numeration envisaged: a binary globally-valid encoding purified from the overhead due to human-readable information (which is not needed for its functioning). By extending the length size up to 5 bytes, a more accurate characterization (especially for the actuators' family) is possible.