Information Centric Networking based Internet of Things
Why ICN for loT?
To overcome the shortcomings of IP-based networking, ICN is considered to be a promising approach. Content naming is used by ICN to get rid of address- space scarcity, and the content is accessed by name-based routing. Contents are cached at intermediate nodes to provide reliable and efficient delivery of the data. Moreover, the contents are self-certifying which ensures better security. Thus, the benefits of ICN in terms of data delivery speed, efficiency, and improved reliability paves the way for the ICN based Internet of Things (loT).
Connecting all the devices with the Internet is the main aim of loT so that all the devices can be accessed at any time and from any place. loT paves the way for future technologies like smart washing machines, smart refrigerators, smart microwave ovens, smartphones, smart meters, and smart vehicles. Associating these smart objects with the Internet provides the pathway for remarkable innovations like smart home, smart building, smart transport, digital health, smart grid, and smart cities. And bonding billions of these devices to the Internet leads to the generation of an enormous amount of data which results in loT Big Data. However, systematized access and discovery of loT Big Data put more limitations on the underlying TCP/IP architecture while raising many critical issues.
From the loT perspective, one of the issues is the naming (and addressing) of every loT device. As the IPv4 addressing space has been exhausted, IPv6 address space may also exhaust in the future. And the long length of IPv6 addresses makes it less suitable for communication through constraint-oriented devices like wireless sensors [327, 69]. Hence, IP architecture does not provide efficient naming and addressing scheme for billions of devices. Moreover, different devices have divergent specifications and constraints in terms of processing power capability, size, memory and battery life which procreate complicated issues. And most of these devices are low power, tiny, low cost, limited memory, and constraint-oriented wireless sensors. And these devices frequently suffer from data unavailability problem. However, IP-based networking provides no solution to this data unavailability problem. But, ICN handles this problem quite smartly using its in-network caching facility. loT applications like smart home, smart town, smart health, etc., require more security and privacy whereas VANET and MANET require better mobility handling [330, 32].
From the data perspective, most of the users of loT applications are more interested in getting updated information rather than knowing the source or address of information. For instance, in the domain of wireless sensor networks (WSN), loT devices aim to harvest information on a large scale .
TCP/IP network architecture was designed to connect a limited number of computers to the network and for the sharing of limited network resources. Thus it was not designed for modern loT requirements. Moreover, the huge amount of data produced by loT devices put additional requirements like scalability and data dissemination on the underlying architecture. Thus, to fulfill these requirements, ICN can serve as a promising architecture. Its primary characteristics like in-network caching, content naming, better and easy mobility management, improved security and scalable information delivery make it suitable for loT applications. Additionally, ICN can mask over the TCP/IP network layer or MAC layer. Even though ICN has an edge over TCP/IP, it will take time to completely replace TCP/IP. Thus, shortly ICN will work as an overlay on the IP network. And in the long run, TCP/IP will be completely replaced by ICN architecture.
In-network caching in ICN can efficiently handle information delivery from an unavailable device (i.e., dead device due to the expiry of battery life) by caching contents at intermediate nodes. In-network caching also minimizes the content retrieval latency, provides scalable and easy information retrieval of a large amount of data produced by loT applications. And better hand-off for mobile devices like mobile phones and vehicles is provided by mobility handling features. Moreover, ICN's feature of self-certifying contents provides better security [41, 136].
IoT Architecture Requirements
Following are the requirements and challenges [53, 30, 69] posed by loT network architecture:
- 1. Scalability: The main vision of loT is to connect networks, corresponding devices and billions of low power devices to the Internet. And this poses bigger and newer challenges over underlying architecture because of scalability issues. loT architecture should support billions of devices efficiently. IPv6 provides a huge address space to accommodate loT devices. But addressing is not the only issue. A large amount of data that is being produced by loT devices needs to be managed efficiently while considering the scalability issues. Therefore, loT network architecture must be scalable for content access and at the same time it must maintain network efficiency.
- 2. Mobility: Mobile devices like smartphones, tablets have limited battery life. And some of the loT applications need connectivity anytime and anywhere. Furthermore, the number of mobile devices connected to the Internet exceeds the stationary nodes. Thus for data availability, reliability, and faster connectivity, the network architecture should provide seamless mobility and roaming.
- 3. Security and Privacy: In specific loT scenarios transmitted data is highly sensitive, for eg. smart health and smart hospital. Hacking of such data can lead to severe consequences. Thus, authorization, confidentiality, and integrity should be incorporated in the loT network. Data access policies and standards should be also clearly defined. For example, a smart home where the detail of a soup ordered by the house owner is required by a hotel for processing payment. But if this detail is shared with his insurance company then this can affect user policy. As the private data can be misused by the insurance company, hence, privacy must be ensured via some access policies.
- 4. Naming and Addressing: Billions of tiny low-power constraint-oriented devices are used in loT. These devices need unique naming and addressing to get recognition in the loT network. Because of the availability of large address space in IPv6, addressing and naming a large number of loT devices is no longer an issue. However, IPv6 uses long addresses. Hence, it would be complex to process these addresses for constraint oriented loT devices as it leads to wastage of resources. Moreover, loT contents are produced and processed very fast. And, for a single content, there are multiple versions. Thus, naming these contents increases complexity. Hence, efficient naming schemes to suit the loT environment is needed.
- 5. Heterogeneity and Interoperability: The primary components of loT are smart wireless sensors and RFID tags. Smart sensors are the major components of loT and it offers many applications. And since these devices vary in specifications like memory size, processing power, and battery life, thus they are heterogeneous. Moreover different technologies like cellular technology, Bluetooth, 4G, LTE, CRN, and opportunistic networks are used to communicate between these sensors. Hence the technologies used for communication are heterogeneous in nature. Thus the technology required for loT must support heterogeneity.
- 6. Data Availability: Whenever a node moves from one location to another in TCP/IP architecture, data may become unavailable. A similar case occurs when a battery completely drains out and is unable to forward data. Similarly, due to the Denial of Service (DoS) attack Internet users cannot receive data. Since TCP/IP architecture cannot look at or inspect data according to request during data transmission, consequently DoS attack is possible. And, the in-network caching technique can improve data availability.
- 7. Energy Efficiency: A huge amount of energy is needed by billions of devices to build loT applications. And most of the smart devices such as wireless sensors are low in battery life. Thus, to make universal connectivity possible in the form of loT, energy-efficient mechanisms are required.
Significance of ICN for IoT
loT users, as well as the internet users, are interested in data and not the data source. And ICN does the same for the users, as it provides the required data to the consumer without knowing about the producer of data. The receiver driven communication model in ICN works on the same principle. In ICN receiver requests for the content and need not bother about the source of content. Moreover, data access is only possible when the receiver explicitly requests it.
loT plays a crucial role when a vehicle faces a road accident and that vehicle wants to inform incoming vehicles about this accident. In this case, any specific node can act as both the producer and consumer. Hence it results in the flash crowd as only one vehicle is providing the data about the incident. The request for specific information by a large number of users in the network causes the flash crowd. Similar flash crowds are also produced in modern-day internet [24, 379]. Hence, flash crowd results in an increase in network traffic for a particular server , which results in quick drainage of the battery life of the sensors of producer vehicles. Thus data can become unavailable due to the end of the battery life of some of the sensors. This problem can be sorted out by the in-network caching facility provided by ICN as it minimizes the traffic load on the original data producing server while caching the data on intermediate routers. And these intermediate routers can provide the cached data on behalf of the original producer thus reducing the so-called flash crowd situation. Thus, the in-network caching facility serves as a boon for the low powered loT devices. And since the content is named independent from its source in ICN it can be stored anywhere globally. Moreover, ICN provides names to content; thus it is more suitable for loT as it can combine billions of devices and huge information contents. Moreover, for push type communication beacon messages are used . As the content name is location independent, opaque communication is provided by ICN between the sender and receiver making it more secure.
IoT Requirements Mapping to ICN Characteristics
Scalability requirements for loT applications that connect to billions of loT devices and produce a massive quantity of content can be fulfilled by ICN characteristics like content naming, in-network caching and content-based security. ICN naming and name resolution can be efficiently used to provide billions of addresses and names to loT devices and contents respectively.
Receiver-driven communication in ICN along with flexible naming and location independence makes hand-off easier for mobile devices in loT applications. Moreover, ICN in decoupled mode can perform easy re-registration after a hand- off of a mobile device with the nearest new router .
Security and privacy in loTs can be provided through the following features of ICN.
- 1. ICN content naming made it easy to inspect whether data is flowing according to query or not.
- 2. Content location independence hides the source of content.
- 3. Receiver-driven communication style confirms that content arrives because the receiver has requested for this content.
- 4. Self-certified contents ensure that the contents are the same as sent by the source.
Figure 3.3: loT prerequisites
Heterogeneity among loT devices can be easily handled when devices are named using ICN naming scheme. Different types of loT devices can operate with each other more efficiently when ICN strategy layer is induced in loT devices. Data availability in the loT network can be improved by the ICN in-network caching facility. Moreover, in-network caching decreases the frequency of fetching data from the producer and thus saving network life and making it more energy- efficient. Figure 3.3 shows the summary of loT requirements.
ICN IoT network architectures
ICN-loT architectures were proposed to fulfill the needs of loT infrastructure. On the same lines research efforts have been discussed in this section. And the significance of this research area and the efficient applicability of ICN for loT has been also discussed.
The research community is actively working on loT to suit the needs of ICN architecture. Thus NDN based ICN architecture was proposed for loT . In NDN-loT architecture there are three layers, namely, the application layer, the NDN layer, and the thing layer. To enable name-based networking, architecture consists of content chunks instead of IP addresses. Moreover, to support the transport and forwarding tasks strategy layer is introduced. NDN operates at the network layer and performs its task with the help of two planes, namely, control and management plane and data plane. Tasks like routing, configuration and service models are performed by control and management plane. While the data plane manages the Interest and Data messages and the caching strategy.
There are three different strategies in NDN to support push-type communication so that loT push operations can be supported . Primarily NDN is designed for pull-based communication but to provide support for loT push support has been introduced in loT. In the first scheme called Interest notification, the Interest message is modified by including small data that is to be transmitted. And this data is not cached. The second scheme called Unsolicited data transmits a small packet of uData. And in the third scheme called virtual interest polling (VIP), long live interests are transmitted by the receiver and whenever data is available producer replies and in case of failure consumers can re-transmit an Interest message. All these three techniques have their own set of advantages. In terms of network resource usage, VIP outperforms the other two and is suitable for a massive loT environment. But Interest notification and Unsolicited data techniques are suitable where battery life is important.
To showcase the scalability and security performance achieved by NDN this initial prototype has been developed. And to address the issue of heterogeneity in loT for both static and mobile devices a unified ICN-based loT platform has been proposed [221 ]. NDN and MobilityFirst(MF) (MF is also one of the ICN architectures) cater to the need of both static and mobile devices. Comparision has been done between NDN architecture and MF architecture by the implementation of building management and bus management system scenarios. In bus management system buses are mobile devices and different sensors and actuators are static devices. From the observation, it was concluded that NDN outperforms MF when static devices are involved and MF outperforms NDN when mobile objects are involved.
In network Computation in Edge Computing and Cloud Computing
In loT infrastructure, the data collected from constraint oriented sensors are initially processed and then the refined data is transmitted to the requested host. This mechanism is called in-network computation in loT. This helps to reduce the amount of data produced thus reducing the storage and high processing requirements. In-network computation also helps in simplifying the mobile node management, minimizing cached data, simplifying data routing and forwarding hence improving network life and battery life. And in-network computation paves the way for edge computing.
Figure 3.4: Requirements of loT infrastructure
As shown in figure 3.4, cloud computing is the main driving force involved in the life cycle of loT to process and manage loT contents. But cloud computing creates a separation between the producer and the consumer of information. This results in increased delay and bandwidth requirement during transmission and reception of information to the central servers for cloud computing. Since the central servers are responsible for the processing of data and management of information so the intervention of central sever is necessary. Moreover, it may pose many privacy concerns during the reception and transmission of content. Considering these disadvantages, fog computing has been introduced to shift storage and computing capabilities towards the end node or edge node of the network. And since end node or edge nodes are involved fog computing is also known as edge computing . Data needs to be cached before its processing in edge computing, and ICN-loT allows to cache data naturally. Thus loT devices can process the cached data in ICN-loT as it allows caching with edge computing.
In ICN-loT, it is encouraged to cache the data near the end consumers which increases the applicability of edge computing. Thus, in ICN-loT caching, edge computing in-network computation plays a pivotal role. In loT applications like virtual and augmented reality-based games which require real-time behavior with almost zero-delay can benefit from edge computing .
An alternative way to process and compute ICN-loT data is by employing cloud computing . The burden of processing can be shared by the cloud. Cloud also provides high storage and can also calculate analytics of any specific ICN-loT application. As an example, the usage of electricity can be calculated and seen in any specific locality of the town. Hence, cloud-assisted ICN-loT assists in designing systems that can perform complex calculations, provide huge storage capabilities and act as the backup in case of mobile devices.