# ndInIoT-FC: IoT Devices as First-Class Traffic in Name Data Networks
## 3 ICN Architecture for IoT Environments
### ndnlIoT-FC Pub-Sub Architecture
#### 3.4.1 Hybrid Naming Strategy  
Under a Smart City context, sensory measurements are exposed by microservices hosted in the DCUs which can be managed by some remote host.  
Whatever the configuration at the collection point, the subscription will be for a service that will periodically send a set of readings to the subscriber node, this is, the subscriber is not required to sign up for every single content available in each sensor or to a specific measurement. Moreover, the subscriber nodes possess brief knowledge of which services and DCUs exist in the network, which grants them the ability to construct an Interest packet appropriately named that can be used to retrieve the intended data. Accordingly, we adopted a hybrid naming strategy to ease the process of subscription of data available to the ICN subscriber nodes: Hosts, DCUs and services must have a static unique identification which can be combined in the following sequence: **host_ID / DCU_ID / service_ID**, to form a specific  
Figure 3: ndnlIoT-FC pub-sub packet changes.  
naming format which can handily be identified by intermediate nodes NDN tables and forwarded correspondingly. This naming format must be used between all the communications under the scope of the Publish-Subscriber mechanism, both by subscribers and publishers, unifying all content requests under the same naming format. As the use of a single subscription request allows for several data to be transmitted towards the subscriber for one specific service, the identification of the content itself coming from the sensors is at the discretion of the applications, without impacting the naming of the request. Additionally, it is important to notice that a single host may request content from services which can be spread across different DCUs. Figure 2 shows four groups of sensors exposed by four groups of services (yellow, blue, pink, and green). Although some services are available in different _localization_, i.e., are available by different Faces in terms of ICN architectures, it can also be induced that requests arrive at an intermediate node through the same incoming Face. In this way, we adopt the aggregation of names in the data structure (PIT) of the backbone nodes of our proposed architecture.  
By using naming aggregation, we reduce PIT sizes as several entries for different contents can all be agglomerated, depending on which host originated the requests. The Interests arriving from the same subscriber node are registered in the PIT as a single entry, using the content name as a baseline, under the format **host_ID** to establish the PIT entry name. This strategy adequately meets the scalability requirements of the IoT environment, where a large amount of microservices are needed to handle multiple sensors, as data must be forwarded towards the interested subscriber despite which sensor originated the content and intermediate nodes are only concerned in forwarding packets according to known paths. Thus, the allocation of resources towards PIT entry analysis in intermediate nodes is not linked to the number of services under subscription by the subscriber node. This format for naming aggregation is illustrated in the following section where we show an example of how the subscriber and intermediaries PITs are filled.