1 Introduction

The Internet of Things (IoT) [1] consists of wireless sensors and smart meters that are typically dealing with a large number of interconnected nodes in the order from thousands up to millions of nodes [2]. There is no way that IPv4 can have the capabilities to accommodate such a large number of interconnected devices. Wireless connections become the predominant edge for IoT networks [3]. Wired LAN switches are disappearing and already 70–80% of networks are becoming wireless. IPv6 can provide an address space of up to 2128 distinct addresses. It is necessary to have IPv6 devices in IoT networks to avoid the scalability bottleneck of the IPv4 subnet [4].

1.1 Heterogeneous Technologies Used in IoT

Among the biggest problems in IoT networks is the heterogeneity of the sensors and devices [5]. IoT networks are heterogeneous and may involve different connectivity technologies. Wireless technologies such as 2G/3G/4G/LTE/5G [6], Bluetooth technology referred to in the IEEE 802.15.1 standard, Wi-Fi technology referred to in the IEEE 802.11 standard, ZigBee technology referred to in the IEEE 802.15.4 standard, as well as, Radio-Frequency Identification (RFID) [7] are all among typical technologies mainly used in IoT network. A summary of connection edge technologies used in IoT, together with advantages, disadvantages, and uses are shown in Table 1.

Table 1 Connectivity edge technologies used in IoT
Full size table

These different types of access methods result in incompatibility issues and devices cannot efficiently communicate with each other [8]. Solving this heterogeneous nature of IoT devices [9] is the biggest challenge researchers are trying to solve. IPv6 has the capability of solving the heterogeneous nature of IoT devices and access methods as shown in Fig. 1, where these devices can communicate using IPv6.

Fig. 1
figure 1

Heterogeneous nature of devices and access methods used in IoT

Full size image

IPv6 can help unit the heterogeneous nature of IoT networks. Sensor networks can be connected by a variety of data links. The advantages of using IPv6 in heterogeneous IoT networks are its visibility into the packets, manageability through common protocols, and security capabilities.

1.2 Lack of a Standard Architecture for IoT Networks

There is no single global defined architecture that all IoT networks follow [10]. There are a lot of different standards organizations which published their architectures with recommendations about IoT structures that depend on the industry used. However, there's a set of requirements [11] that will help the preferred architecture.

1.3 Constrains of IoT Networks

The requirements of a typical IoT network emerge from the fact that IoT network devices are considered to be constrained devices [12]. These devices have a very low-power CPU and a small amount of memory. Moreover, the networks that IoT devices connect to are also constrained. A network that supports a hundred thousand devices can become very congested. The bandwidth available for each device is fairly low. We typically look at IoT networks as lossy and low-power type networks [13]. As a result of this, IoT devices and networks are both constrained and the scalability is very high. IoT networks also, in some cases, have deterministic requirements such as sub-millisecond response time [14]. These are typical types of requirements that require deterministic or time-sensitive networking capabilities.

1.4 Security of IoT Networks

Security requirements are much higher than normal in IoT networks [15, 16]. As some IoT devices are publicly accessible, like a smart meter on a house, once the hacker is into the meter, if it's IP connected, he can get into the whole network, thus can bring the whole network down. Security has to be at a different level. If two nations go to war, the easiest thing to do is to bring down their critical infrastructure, take down a utility or mess with transportation systems. It is possible to almost cripple a country through cyber security violations. Infections in the IoT world are more than just bringing down a system, they actually can create physical damage and cause the destruction of property. So security is one of the top requirements in any IoT deployment. All the above-mentioned issues are the problems we are trying to solve in our research using IPv6 for IoT networks.

1.5 The Contributions of this Research

The contribution of our research is the application of standard IPv6 as the main protocol for communication between IoT network devices with a proposed adaptation through IPv6 header compression and possible frame fragmentation for throughput improvement and better suitability for IoT networks. We propose an implementation technique, not a new protocol, that makes IPv6 fully compatible with the hob fragmentation and reassembly of the original IPv6 protocol.

2 IoT World Forum (IoTWF) Reference Model

One of the common architectures for IoT networks is the one published by the IoT World Forum and the published reference model [17]. In this model, the IoT network is divided into seven layers. It tends to be quite a data management-focused, as shown in Fig. 2.

Fig. 2
figure 2

IoT World Forum (IoTWF) Reference Model

Full size image

2.1 Physical Devices and Controllers Layer

At the bottom layer, we have sensors and actuators, there are the “things” that actually populate the IoT network. These are the actual physical devices and controllers that get IPv6 addresses.

2.2 Connectivity Layer

The second layer is the Connectivity layer. IoT devices typically connect through different types of access methods. Wireless networks such as narrowband IoT, low-power wireless access, or Wi-Fi could be used to connect devices up to an aggregation point.

2.3 Edge (Fog) Computing Layer

The third layer is the Fog Computing layer. Data elements analysis and transformation are often called the fog computing layer. As data comes through this point of the network, it is examined and analytics can be performed on it and the response is directly sent back to the physical layer. As we move up the stack. we see that the top four layers here are about managing data. From a networking perspective, it's less about the network it's more about data.

2.4 Data Accumulation Layer

Looking at layers four and above, it's the separation between the operational technology piece and IoT and this is also the division between IPv6 and IPv4. For example, a company that has a large IoT network deals with a very large volume of sensors. It is preferred that this network will be IPv6 for a lot of good reasons. However, the organization is typically an IPv4. So this division point is the boundary not just between IT nodes but now between IPv6 and IPv4 as a lot of companies are not yet ready to do full IPv6 on the enterprise.

2.5 Data Abstraction Layer

In this layer, some sense is made out of data. Similar data from IoT sensors are collected together.

2.6 Application Layer

This layer contains the data plane where monitoring and statistical analysis are performed.

2.7 Collaboration and Processes Layer

This is the topmost layer. At this layer, data analysis takes place on data received from the Application layer. This layer is about human interaction where application processing is presented to users.

3 Challenges with Running IPv6 in IoT Networks

IPv6 is a very feature-rich protocol but it's also quite a big protocol. IPv6 doesn't suit itself well as a default to IoT networks. A lot of work has to be done to adapt IPv6 and especially the IPv6 headers to be better suited to IoT networks [18].

3.1 IPv6 Packet Size

We would like to adopt IPv6 to be utilized in a specific wireless mesh technology called IEEE 802.15.4 in the ZigBee family [19]. It inherits some of the capabilities of ZigBee but 802.15.4 networks were the first to be used on large scale for smart meter networks and they're mesh-type networks.

We can have a thousand nodes that form a mesh and connect up to an aggregation point. When the specification was published, the MAC layer frame was defined as 127 bytes. Looking at the IPv6 MTU, it's 1280 bytes. This is a big packet that we want to fit into 127 bytes. We can do fragmentation and reassembly in IPv6, but it's not going to be efficient to split an IPv6 packet into 10 IoT frames.

3.2 Reliability Requirements

IoT devices are not going to be sending a lot of data, however, they do send important data that reports important events. Wireless connections typically used in IoT are fairly unreliable and error-prone [20]. We can achieve better efficiency with smaller frames than we can with big ones. That is why we recommend adopting smaller frame sizes.

3.3 Narrow Bandwidth

A very popular class of devices widely used in IoT networks is narrowband IoT [21]. Those are typically battery-powered and are very sensitive to how much data you send and those have even a smaller footprint [22]. It is very essential to reduce complexity, power consumption and only transmit data at very low rates.

3.4 Support for IPv4 and Legacy Devices

One of the interesting challenges with IoT is that we can't replace all devices and go IPv6 as there are a lot of already existing legacy devices [23]. If we look at utilities, for example, they are so many devices up on the utility poles. It is required to have these devices connected to the mesh and have management of it but without having to replace them. One of the key requirements here is to be able to support legacy devices through a gateway device. There are various types of gateway devices we could have, but these devices will typically connect through a serial connection or an IPv4-type connection.

4 Related Work

IEEE 802.15.4/ZigBee standards have become the predominant technology for IoT, following this many types of research in this field have emerged. In many research articles, the performance of IEEE 802.15.4 was evaluated and compared with existing networking protocols. The research article authored by Srinidhi et al. [24] detailed the need for network optimizations in the Internet of Things. This article focused on open network optimization issues and challenges in IoT such as the need for efficient routing and the need to select the best energy-efficient routing algorithm for battery-powered devices.

The research article authored by Rady et al. [25] presented a detailed survey studying routing protocols utilized in Mobile Wireless Sensor Networks (MWSN) and mainly emphasized the basics of operation and system architecture of the most intelligent-based and advanced routing protocols. The two research articles authored by Rady et al. proposed a protocol that promotes energy efficiency for an only mobile sink node [26] and then considered both a mobile sink node and a mobile sensor node at the same time [27] in the network.

On the other hand, standards committees are trying to address the incompatibility issue in IoT by creating services called Machine-To-Machine (M2M) that take the back-end application system of all of these sensor networks and open up APIs to enable communication as proposed in the research articles [28, 29], and [30]. The research article authored by Mishra et al. [31] detailed the use of MQ Telemetry Transport (MQTT) as a lightweight open messaging protocol in M2M and IoT systems. Despite the diversity of the range of proposed routing protocols detailed that can be utilized by application layers to communicate, however, the efficiencies and the scale that can be obtained from directly communicating devices are so much more if they can communicate directly.

The research article authored by Liu Xiongfei et al. [32] proposed modifying the MAC frame size to allow 2000 byte frames, however, larger frame size is not preferred. It is preferred to have small MAC frame sizes as IoT networks are extremely lossy networks. The reason for this is that IoT networks are typically using an unlicensed spectrum. Interference exists from different sources as IoT networks use Frequency Hopping Spread Spectrum (FHSS). This results in losing a lot of frames. If we send big frames, and if that frame is lost and doesn't get acknowledgment, that big frame has to be resent. A lost big frame with a lot of data in it, makes the efficiency go way down. From the above-mentioned literature review, we can conclude that it is necessary to adapt IPv6 for IoT networks with adaptation to better cater to the inherent constraints in IoT networks detailed earlier.

5 Use of IPv6 Adaptation

The problem with using IPv6 in Low-Rate Wireless Personal Area Networks widely used in IoT is that wireless links are required to only support an MTU maximum transmission unit of 1208 bytes. Because of this limitation, it is impossible to transmit IPv6 packets over 802.5.4 technology as it is without adaptation. Therefore, header compression and potentially link fragmentation and reassembly operations are required. The main goal of the compression mechanism is to take the original IPv6 headers of 40 bytes and add a few bits which indicate how the original IPv6 header is compressed. These additional bits form what is called the compressed header or IPv6 header compression. The objective of this operation is that the receiver of the compressed packet, by adding these fields of the compressed header, can at the end decompress and obtain the original IPv6 packet. The compression principle can be summaries as following, any field that can be guessed by the destination endpoint is not sent. So, some of the header fields can be removed, which mean that, they will not be transmitted for different reasons as will be detailed in the following sections.

5.1 IPv6 Header Format

In this section, we will provide a detailed description of standard fields used in the IPv6 header [33]. Figure 3 shows a diagram of the standard IPv6 header format.

Fig. 3
figure 3

Standard IPv6 header format

Full size image

The first field of the IPv6 header represents the Version. This consists of four bits and represents the IP version number. For IP version 6, the sequence of bits is defined to be 0110. The next field is the Traffic Class that consists of 8 bits. The bits in this field represent two items of information, the sixth most significant bits hold what is called Differentiated Services (DS) field. The DS is used by the network for traffic management and classification and for providing quality of service. The default value of this field is 000000 which corresponds to the classic service known as the Best Effort. The last two bits of the field are used for Explicit Congestion Notification (ECN). This ECN field allows for notification of network congestion from the end-to-end. The next field is the Flow Label field which is a 20 bits field. This field is used as an identifier by a source node to label the IPv6 packet that belongs to the same flow, for example, Voice Over IP application or a TCP session to request special treatment by the intermediate IPv6 routers or nodes. A Flow Label of value 0 indicates the fact that this packet is not belonging to any special flow. The next field is the Payload Length which consists of 16 bits. This field indicates the size of the payload in Bytes. The next field is the Next Header field. This 8 bits field indicates the next protocol header following the IPv6 header or in other words the transport layer protocol. Then we have an 8-bit Hop Limit field. This field provides an upper limit on the number of hops, indicating the how many routers the IPv6 packet can pass through. The next field is the Source Address which consists of 128 bits and it is the field of the source of the IPv6 datagram. Finally, we have 128 bits address field of the Destination Address of the IPv6 datagram. Table 2 shows a summary of IPv6 header fields and their interpretations.

Table 2 IP address types
Full size table

5.2 IPv6 Addressing

An IPv6 address consists of two parts; the Prefix bits and the Interface ID bits. The Prefix bits of an IPv6 address can be considered like the subnet mask used in IPv4 address, so the Prefix identifies the network in which the nodes or the routers are located. The Interface ID bits then identify the interface of a node in that specific network that the prefix was previously identified. Figure 4 shows a typical IPv6 address split into the prefix and interface ID parts. The /62 shows the prefix length, that is the first 62 bits, are the prefix part of the IPv6 address. The remaining bits then represent the Interface ID part [34].

Fig. 4
figure 4

An IPv6 address showing the Prefix and the Interface ID

Full size image

There are different kinds of IPv6 addresses. The prefix and IPv6 address can be in one of the following cases: it can be a Loopback, Unicast Link-Local, Global Unicast, Multicast, Anycast, etc. IPv6 address can be one of the cases shown in Table 2.

5.3 MAC Frame Format

According to IEEE 802.15.4, the maximum physical packet size is 127 bytes. 40 bytes are needed for the uncompressed IPv6 header and 8 bytes for the uncompressed UDP header. Figure 5 shows the format of the IEEE 802.15.4 MAC frame [19].

Fig. 5
figure 5

Format of IEEE 802.15.4 MAC Frame

Full size image

The IEEE standard 802.15.4 comes with a very small Maximum Transmission Unit (MTU) of 127 bytes. Considering that an IPv6 header consists of 40 bytes by default and a UDP header of 8 bytes [35]. While the IEEE 802.15.4 MAC header can be up to 25 bytes if there is no security employed or 46 bytes if the security field is used. As a result, there are either 54 bytes left for the payload when security is not considered or 33 bytes when security is considered.

5.4 IPv6 Adaptation for IoT Networks

The compression of IPv6 and UDP headers are thus very essential. The first thing to do is to create compression. Taking the very big IPv6 header, which is up to 60 bytes of the header with extension headers, and compress it. Secondly, create fragments, which is typical fragmentation and reassembly but limited in the access network of the IoT system. The scheme of a MAC frame without header compression is shown in Fig. 6.

Fig. 6
figure 6

IPv6 header without compression

Full size image

The entire 802.15.4 MAC frame without compression is 127 bytes. If it is put in the IPv6 header, that is 40 bytes without an extension header, this will only leave us with 33 bytes of payload. The efficiency of transition through the IoT network is going to be extremely low because of not sending a lot of data. These frames are small and there is a need to get the actual data through them as efficiently as possible. Adding IPv6 header compression allows to compress the header down to approximately 2 bytes. It will be possible then to greatly increase the payload up to 108 bytes. As a result of this, the efficiency of transmission across 802.15.4 goes up dramatically. We determine the common header values contained in common data flows. For internal communication within the 802.15.4 network, we have a common network prefix. Only the host portion of the address can be used to address all devices. First, we have the version, so actually, the version field can be removed in all cases, since only IPv6 is employed. Therefore, we don't need to send this information because the receiver expects that the packet that it will receive comes with IPv6 version. Second, we have the payload length. Indeed, this field can be removed as well, since it can be inferred from the lower layers, for example, from the IEEE 802.15.4 MAC from layer 2. As a result, these two fields are not necessary to be sent to the destination. The source address is assumed to be the transmitter’s MAC address in a single-hop communication.

5.5 IPv6 Header Compression Encoding

The IPv6 header compression encoding consists of two bytes (16 bits) that may be extended by another byte to support additional context encoding. The target is to have compressed header fields that match the fields in the original header. Figure 7 shows the header compression encoding format.

Fig. 7
figure 7

IPv6 header compression encoding format

Full size image

First, we have the 3 bits which is the dispatch value. This value indicates the nature of the frame and, in this case, 011 represents that we have a compressed IPv6. Next, we have the TF field that handles the compression of the Traffic Class and Flow Label fields of the original IPv6 header shown in Fig. 3. The TF field is two bits, which means that there are four combinations of these two bits. If they are 00, then all information will be carried in line. If they are 01, then we will have ECM plus the Flow Label. If they are 10 then we have only the ECM and the Differentiated Service and finally, if they are 11 it means that we have nothing to transmit. The next field is the Next Header field which refers to the next header of the original IPv6 and it indicates whether the next header field is compressed or not. For example, if we have a UDP protocol, it indicates whether the UDP header is compressed or not.

Then we have the HLIM, which stands for Hop Limit and it represents the hop limit of the original IPv6. There are four well-known values, we have 255, 64, 1, or 0. The 00 represents that the value of the Hop Limit is something not among the 1, 64, or 255 so it must be carried in line and the transmitter must transmit this information. If we have the bits equal to 01, then it means that the receiver will understand that the hope limit is equal to 1. If we have 10, the receiver will decode and will be understood that the value of the hop limit equals 64, and respectively we have the final value which is equal to 255. We can have compression efficiency if and only if the transmitter is using either 1, 64, or 255 hops. If not, then we have 00 and this information must be carried in line.

Next, we have what is called the CID field which stands for Context Identifier extension. It adds a context to allow 16 source and destination prefixes by default. If the CID Context Identifier extension is equal to 1, then it means that we do have a context, so basically, it means that the transmitter and the receiver have agreed on a specific context on a specific prefix and there will be additional 8 bits after the dumb so as you can see my pointer here after that we do have eight bits additionally but we then identify which uh which is the prefix of the source in the destination so that's why we have eight because we need four bits for the source of to represent the prefix and four bits of the destination of the prefix of the destination so that's why we have 8 bits in total. 24 we have 16 different contexts.

Next, we have what is called the SAC and the sum so suck and this suck represents resource address compression and it indicates whether we have a stateless or context-based address. If it is 0, it means that we do not use context. If it is 1, it means that we do have a context space. Similarly, for the DAC so this is for destination address compression and it represents the same whether or not we are using the context or if we have a stateless approach stateless approach. Next, we have SAM and DAM fields that represent the source and destination address mode depending on the combination. We might have different byte sizes, so it highly depends on whether the addresses are linked local or global. Finally, there is the field M which stands for multicast compression. It indicates whether the destination address is a multicast address or not. Table 3 shows a summary of IPv6 header compression encoding values and interpretations.

Table 3 Header compression encoding values and interpretations
Full size table

5.6 UDP Header Format

Figure 8 shows a typical UDP header format. We have the source port, the destination port, the length, and the checksum fields [36].

Fig. 8
figure 8

Typical UDP header format

Full size image

The source port is the field that identifies the port of the transmitter. The destination port is the field that identifies the port of the receiver. The third field is the length which specifies the length in bytes of the UDP header and data. Finally, we have the checksum field for error checking of the UDP header and data. Table 4 shows a summary of the UDF field names, sizes, and descriptions.

Table 4 Summary of UDP field names, sizes, and descriptions
Full size table

5.7 UPD Header Compression

In Low Power Wireless Area Networks, only a specific range of UDP port numbers is defined. This allows for the source and destination ports to be compressed from 16 bits down to 4 bits. So instead of having 16 bits for the source address and 16 bits for the destination port only 4 bits can be used. The idea is that, the UDP ports are only within the range of ports 61,616 to 61,632. Then these ports can be compressed up to 4 bits to represent the range from 16 to 32. Next, regarding the UDP length field, it can be as well removed, similar to IPv6 payload length, since it can be inferred from the lower layers. Finally, we have the checksum field which will be either carried in line, if we are using it, or can be removed if we are not using it. A compressor in the source transport endpoint may remove the UDP checksum if it is authorized by the upper layer. Figure 9 illustrates the UDP header encoding format which consists of 8 bits.

Fig. 9
figure 9

UDP Header Encoding

Full size image

We have the first 5 bits which is the dispatch value. We have 11,110 and it indicates that we have UDP header compression. With this dispatch value, we know that there is a compressed UDP header. The next field is the C which represents the checksum. When it is 0, this field is not compressed, and when it is equal to 1 it is removed. Finally, we have the final 2 bits field which represents the ports, where 00 indicates that there is no compression, and all the information must be carried in line, 01 indicates that only the first 8 bits of the destination port are removed, the 10 indicates that the first 8 bits from the source port are removed. The most efficient combination is the 11 which indicates that the first 12 bits from both source and destination ports are removed and thus only the remaining 4 bits are sent.

5.8 IPv6 and UDP Compression with Fragmentation

Figure 10 illustrates the whole process of applying fragmentation and compression to an IPv6 datagram.

Fig. 10
figure 10

The whole process of compression with fragmentation

Full size image

We have an IPv6 datagram that has a large packet. The source node tends to send this packet to the destination. However, because we have the problem of 127 bytes MTU at layer 2, the source node should compress the IPv6 header. The dispatch type 011 represents that we have IPv6 compressed header fields. If there are IPv6 header fields that cannot be compressed, then these fields will be carried in line. Similarly, we have the same process for the Next Header compression and more specifically for the UDP header. As can be seen in Fig. 10, at the beginning we have FRAG 1 which represents that we have fragmentation of the IPv6 datagram and this is the first fragment because it starts with 11,000. We have another dispatch type that represents the Next Header compression. Then we have the first part of the payload. Similarly, for the second part and finally the last part of the IPv6 datagram is carried through the third fragment.

5.9 Fragment Forwarding

The concept of Fragment Forwarding is when the intermediate node forwards a fragment of a packet without the reassembly of that fragmented packet. The decision to route this packet is made on the first fragment of the IPv6 packet which has the IPv6 header and thus the IPv6 destination address of the first fragment is forwarded immediately. Some state is then kept in the intermediate nodes to enable forwarding the subsequent fragments along the same path toward the destination node. When receiving the first fragment of an IPv6 packet, an intermediate node decompresses the IPv6 compressed header to determine the next hop. Once all the fragments have successfully arrived at the destination node only then the IPv6 packet is reassembled.

A Virtual Reassembly Buffer (VRB) technique can be implemented similarly to a switching table. Each intermediate node maintains a VRB table in which the entries correspond to IPv6 packets in the process of being forwarded. Each VRB entry is a record with four elements, the link-layer address of the previous hop, the locally unique datagram tag of the incoming fragment, the link-layer address of the next hop, and the locally unique datagram tag for the outgoing fragment.

Now assuming 64-bit link-layer addresses and 16-bit datagram tags, one VRB entry requires 20 bytes of memory. When the first fragment of an IPv6 packet is received by an intermediate node from a neighbor with a datagram tag not registered for that neighbor in the VRB table, first it will create an entry in the VRB table and then will record the link layer address of this previous hope and the datagram tag of the incoming fragment. Next it will determine the link layer address of the next hop based on the IPv6 address contained in that fragment, then it will pick a new diagram tag for the outgoing fragment that is unique for the next hop node. Moreover, it will set a timer that allows discarding the state after some time out. All subsequent fragments of the same IPv6 packet will go through the same process and will be forwarded to the next hope by employing this newly created VRB entry. More specifically, the intermediate node for each subsequent fragment will search its source link layer address and in the incoming columns of the VRB table and forward fragments based on the outgoing columns. Finally, after the last fragment is forwarded, the node clears the VRB entry from its table. As a result, the VRB technique allows intermediate nodes to directly forward the received fragments without the need to reassemble the IPv6 packet. Figure 11 shows a detailed diagram of the Virtual Reassembly Buffer.

Fig. 11
figure 11

Virtual Reassembly Buffer

Full size image

6 Simulation and Results

For implementing and testing our proposed methods, we utilise Contiki network operating system for IoT devices with Cooja network simulator.

6.1 Contiki Network Operating System with Cooja Network Simulator

One of the most popularly used open source operating system for Internet of Things (IoT) networks is the Contiki OS [37]. With Contiki, you can connect small microcontrollers to the Internet at a low cost and with minimal power consumption. Contiki is a powerful tool for building wireless systems, with a high level of complexly, that is mainly designed for memory constraint systems and IoT devices. Contiki provides multitasking using prototypes method and has a built in TCP/IP protocol suite. Contiki OS needs only about 10 KB of Random Access Memory (RAM) and 30 KB of Read Only Memory (ROM).

The Contiki systems included network simulator called Cooja [38]. Cooja simulates networks on Contiki supported nodes to run natively on a small memory system. The quantity programming model is based on prototypes. Proto-thread is a memory efficient programming that feature of multi-threading to attaining low memory overhead. Figure 12 shows the simulation of 41 sky motes that support IPv6 forming a mesh network. A mote is a wireless transceiver that also acts as a remote sensor.

Fig. 12
figure 12

Cooja simulator for 41 sky motes forming a mesh network

Full size image

6.2 Compression of an IPv6 Link-Local Multicast Address

We are going now to analyze all fields in the original IPv6 header of an IPv6 Link-Local Multicast Address shown in Fig. 13 to check which field can be removed or compressed and which must be carried in line.

Fig. 13
figure 13

The original IPv6 header of a Link-Local Multicast Address

Full size image

First, we have the version field. It consists of four bits and it represents the internet protocol version number. The version field can be removed in all cases since only IPv6 is employed and therefore the value of this field is always 6 or 0110. The next field is the Traffic Class which consists of 8 bits. The bits of this field represent two values; the 6 most significant bits hold the Differentiated Services (DS) field. This service is used by the network for traffic management and classification and for providing quality service. The last two bits of the field are used for Explicit Congestion Notification (ECN). Next, we have the 20 bits Flow Label field which is used as an identifier by the source node to label the IPv6 packets that belong to the same flow, for instance, in Voice over IP applications. The special flow label 0 means the packet does not belong to any flow.

The following 16-bit field is the payload Length. It indicates the Length of the IPv6 payload. In other words, the size of the rest of the packet following this IPv6 header. Then there is the Next Header field which identifies the next protocol header following the IPv6 header such as ICMP, UPD, or TCP. The 3A in hexadecimal represents the ICMPv6 protocol as identified by the IANA. The next field is the Hop Limit which consists of 8 bits. This field represents the maximum number of routers the IPv6 packet can pass through. The next two fields are the source and the destination addresses of the IPv6 diagram where each consists of 128 bits and the remaining part represents the payload. Now we move to analyze the resultant compressed header shown in Fig. 14. First, the dispatch placed for a compressed IPv6 diagram the binary sequence is 011 which replaces the header of the original IPv6.

Fig. 14
figure 14

The resultant compressed header

Full size image

Then we have the 2-bit Traffic Class and Flow Label (TF) field which handles the compression of the Traffic Class and Flow Label fields of the original IPv6 header. In this case, TF is encoded with 10. Therefore, only the Flow Label is removed and the rest is carried in line, so the value E0 is appended in the IPv6 Header fields. Next, the payload length field can be removed since it can be inferred from lower layers either from the fragmentation header or from the layer 2 IEEE 802 15.4 headers. Then we have one bit of a Next Header field in this example it is 0 since the Next Header field is not compressed and thus all eight bits for the next header are carried in line, so the 3A indicates the ICMPv6 protocol. Next, the value of the Hop Limit is FF which is 255 in decimal, therefore this field can be compressed to 11.

The Context Identifier extension or CID field is labeled 0 which indicates that there is not a context that will help to compress the prefix and thus no additional CID field is employed. The Source Address Compression (SAC) field is also encoded with 0 to indicate that a stateless approach is employed for the compression of the source address which means that a link-local prefix is used. We can verify it by checking the beginning of the source address. Next, the Source Address Mode (SAM) field is equal to 1 1 which is the best-case scenario in terms of compression efficiency since it indicates that all 128 bits are related as the prefix the, first 64 bits of the ipv6 address, is link local and the Interface ID, the remaining 64 bits, is formed from the layer 2 Source Address.

The Multicast compression or M field is equal to 1 and it indicates that the destination address is a multicast address. This is because the destination address here starts with FF02 which is a typical multicast address. Then the Destination Address Compression (DAC) field is labeled with 0 since the stateless approach is employed for the compression of the Destination Address as a link-local prefix is used.

The Destination Address Mode (DAM) field is equal to 11 since the multicast address has the format of FF02::00xx. As we can see here we have a destination address that starts with FF02 and it ends with 0001. Therefore, eight bits are carried in line and 01 is appended in the IPv6 Header fields. As a result, the compression mechanism has achieved to compress the 40 bytes of the original IPv6 header to 5 bytes. More specifically we have 2 bytes for the compression header and three bytes for the non-compressed IPv6 header fields that are carried in line after the IPv6 compressed header.

6.3 Compression of an IPv6 Global Unicast Address

We are going now to analyze all fields in the original IPv6 header of an IPv6 Global Unicast Address shown in Fig. 15 to check which field can be removed or compressed and which must be carried in line.

Fig. 15
figure 15

The original IPv6 header of a Global Unicast Address

Full size image

First, the dispatch is placed as previously stated for a compressed IPv6 diagram as the binary sequence is 011. Once again the first field of the original IPv6 header is the version field. The version field can be removed in all cases since only IPv6 is employed. Then we have the TF field, in this case, TF is labeled 11 since all fields in Traffic Class and Flow Label are zeros and therefore are removed. Next, the payload Length field can be removed since it can be inferred from the lower layers. Then we have the 1-bit Next Header field. The NH field comes with the 06 value in decimal which is the 06 in hexadecimal and it represents the TCP protocol. In this case, the NH field is 0 since the Next Header field is not compressed as there is no compression mechanism for the TCP yet. Thus all eight bits for the Next Header will be carried in line. As we can see here the 06 value is carried in line. Next, the value of the Hop Limit field is 40 in hexadecimal which is 64 in decimal, and therefore this field can be compressed to 10.

The Context Identifier Extension (CID) field is labeled with 0 to indicate that no additional CID field is employed. In other words, the prefix is not given by the context. Regarding the SAC and SAM fields, the SAC is labeled 1 since the prefix does not start with FE80 and therefore there is no indication for a link-local prefix but rather for a global prefix. The SAM field is encoded with 00 since the prefix is not given by the context which indicates that the full IPv6 address must be carried in line. Thus, in this case, there is no gain from the compression operation. The multicast compression or M field is equal to 0 since there is no indication that the destination address is a multicast address as you can see here. Then the destination address compression DAC field is encoded with 1 since we have a global prefix. Finally, regarding the Destination Address Mode or DAM field, considering that we have a global prefix this field is encoded with 00 which means that the full IPv6 address must be carried in line, and thus, in this case, there is no gain from the compression operation.

Now considering that the SAM and DAM fields are equal to 00 since both source and destination IPv6 addresses must be carried in line. This represents the worst-case scenario in terms of compression efficiency. As a result, the compression mechanism has achieved to compress the 40 bytes of the original IPv6 header down to 35 bytes. More specifically, we have two bytes for the compressed header and 33 bytes for the non-compressed IPv6 header fields that are carried in line after the IPv6 compressed header. The resultant IPv6 compressed header is shown in Fig. 16.

Fig. 16
figure 16

The resultant IPv6 compressed header

Full size image

6.4 Comparison between IPv6 Addressing Modes

Figure 17 shows the comparison between compression efficiency for Link-Local Multicast Addresses and Global Unicast Addresses.

Fig. 17
figure 17

Comparison between Link-local multicast address and Global unicast address

Full size image

Compression is applied to several multicast addresses and unicast addresses and the resultant compressed packet sizes are compared the results of these comparisons are shown in Fig. 18.

Fig. 18
figure 18

Compressed packet sizes for various addressing modes

Full size image

6.5 Analysis of Fragment Forwarding

After applying Fragment Forwarding, we reached the following results regarding this technique. The advantages of employing the Virtual Reassembly Buffer (VRB) and the Fragment Forwarding scheme can be summarized as follows. First, latency is greatly reduced, since there is no need to reassemble and then fragment again the IPv6 packets before forwarding them to the next hop. The end-to-end network reliability is improved since the memory footprint of VRB is just the VRB table and not the actual size of each IPv6 packet, thus reducing fragment drop probability significantly. Furthermore, the datagram tag issue is solved by swapping the tags at each hope instead of having the same globally unique.

However, this method comes with some limitations. First, there is no fragment recovery built in to request the lost fragments. Moreover, it requires the whole IPv6 packet to be re-sent from the source node. Next, this method does not support per-fragment routing, since only the first fragment contains the IPv6 header and the IPv6 destination address. So all subsequent fragments must follow the same path toward the destination as the first fragment. Finally, even though each entry reserves a small footprint in the VRB, the size of the VRB table must necessarily remain finite, thus when the number of IPv6 packets concurrently traversing an intermediate node is large, then IPv6 packets maybe dropped.

6.6 Evaluation of Compression Gain

To evaluate the benefit of compression we calculate the number of bytes saved as a result of applying compression. In order provide a metric for compression gain we calculate the ratio between the size of the compressed packet to the original size of the packet. The compression gain can be defined as:

$$G = 1 - \frac{{{\text{Size}}_{c} }}{{{\text{Size}}_{u} }}$$

where Sizec is the compressed packet size and Sizeu is the original packet size without compression. Figure 19 shows the compression gain for various pay load sizes ranging from 10 to 50 Bytes.

Fig. 19
figure 19

Compression gain for various pay load sizes

Full size image

It can be seen from the diagram that compression gain is significant for smaller payload sizes. However, compression gain becomes less significant for bigger payload sizes. Pointing to the fact that typical payload sizes sent over IoT networks for data acquisition purposes is usually very small, we can conclude that our proposed header compression technique will always result in a high compression gain.

6.7 Evaluation of Packet Delivery Ratio

Packet Delivery Ratio (PDR) is an important metric in measuring network performance for wireless sensor networks due to the lossy nature of wireless links. PDR for a network can be calculated by dividing the number of packets sent from the source by the number of packets actually received at the destination.

$${\text{Packet}}\,{\text{ Delivery}}\,{\text{ Ration}} = \frac{{\sum {\text{Number }}\,{\text{of}}\, {\text{packets}}\,{\text{ received}}}}{{\sum {\text{Number}}\, {\text{of}}\, {\text{packets}} \,{\text{transmitted}}}} \times 100$$

Packet loss in wireless sensor networks may result from signal degradation and this causes a reduction in the Packet Delivery Ratio. Smaller packets resulting from our proposed header compression technique has a higher possibility of successfully arriving at the destination with less probability of suffering from packet loss. Figure 20 shows a comparison of Packet Delivery Ratio for compressed and uncompressed headers for IPv6 packet for a fixed payload size of 20 Bytes for a wireless sensor network that suffers from data loss due to fading.

Fig. 20
figure 20

Compression of packet delivery ratio networks of various number of modes

Full size image

It can be seen from Fig. 20 that out prosed header compression results in a higher Packet Delivery Ratio for almost all network sizes with a greater impact on networks of larger number of nodes.

7 Conclusions and Future Work

As a result of our research and analysis of IoT networks we can come to the following concussions. Internet of Things (IoT) networks have many challenges in terms of security, mobility because things in IoT networks are resource-constrained devices in terms of energy, memory, and processing power. Our proposal for using IPv6 for IoT networks has a large number of benefits. IPv6 is capable of giving sufficient IP addresses to all devices so that they can be directly accessed on the network. IPv6 has auto-configuration capabilities and provides far better security. IPv6 has highly efficient multicast communication features and provides multiple addresses to devices. IPv6 allows for the use of open IP standards including TCP, UDP, HTTP and mesh routing. The above mentioned benefits make the characteristics of our proposed technology ideal for the market.

Our proposal of using IPv6 compression with or without fragmentation serves toward adapting IPv6 packets to IoT networks. In the case of applying fragmentation, the technique of fragment forwarding greatly enhances the performance. Network traffic within the same network can be compressed to 2 bytes. On leaving the 802.15.4 network, the header increases to 12 bytes if the network prefix is known or to 20 bytes if the network prefix is unknown. Compression gain is more significant for smaller payload sizes, which is the norm for wireless sensor networks. Packet Delivery Ratio is using compressed IPv6 headers higher for almost all network sizes with a greater impact on networks of larger number of nodes.

For future work following the findings of our research, we propose the development of a specialized web transfer protocol, alternative to HTTP client server model, for use with constrained nodes and constrained networks in the Internet of Things. This protocol is necessary because traditional protocols are too heavy for memory constrained devices and in order to enable simple constrained things to communicate interactively via the Internet.