Networking Considerations in the Internet of Things
Introduction
The Internet of Things (IoT) refers to the humongous number of devices that are connected to the internet and sharing data. The applications of the IoT is enormous. IoT devices are in smart homes, factories, retail, health care, logistics, government, and more. In retail, users can use data from their stores to monitor customer’s behavior patterns and preferences. In manufacturing, IoT devices monitor machines and other hardware. With the combination of data analytics, users can ”prevent defects and downtime, maximize equipment performance, cut warranty costs, boost production yield, and enhance the customer experience.”[SAS]
With the growing number of IoT devices in the world, new considerations must be made to traditional networking to account for new levels of traffic, varying types of traffic, and how traffic moves throughout a network [BZB17]. This paper aims to address the current hurdles IoT networking must overcome, as well as present the various device-to-device communication methods currently used by the internet of things.
Challenges Faced by IoT Devices
TCP/IP Challenges
Devices attach to the internet using TCP/IP architecture in most applications. In the TCP/IP architecture, data sent between devices breaks down into five layers. These are the physical, data-link, network, transport, and application layers. Framing and control data are inserted as data progresses between layers. This additional data incurs a substantial cost in the form of devices needing more processing power and memory capacity. IoT devices typically do not have enough processing and memory power to meet these requirements [BZB17].
Because of this, it is clear that traditional TCP/IP is not a good fit for IoT devices. TCP/IP protocols were not intended to maintain the high level of traffic and mobility created in an IoT system. As such, TCP/IP is limited in its ability to fulfill the demands of networking for the internet of things [Let].
Packet Fragmentation, Acknowledgement, & Retransmission
In TCP/IP, packets are broken down into smaller chunks whenever their size exceeds the Maximum Transmission Unit (MTU) [Pos80]. Such packets are then put back together by the receiver. Each packet still has forwarding data, as well as other TCP/IP data attached. This data causes significant overhead and is detrimental to IoT device performance [Leg14].
In addition to packet fragmentation, TCP/IP protocols require devices to acknowledge packets they receive, as well as retransmit packets that were not acknowledged [Pic+10]. Packet acknowledgments and retransmissions cause additional overhead, which isn’t feasible with the small embedded systems that typically make up the IoT.
Bandwidth, Memory, Energy, & Processing Capacity Restrictions
Many IoT devices are unable to transmit much data at once, with some devices only transmitting 20–250 kbps. Many devices use simple sensors that cannot quickly transmit data. Transmission size limitations further complicate the use of TCP/IP, as using a heavyweight protocol limits how fast a device can send messages [Pic+10].
Amongst the previous restrictions, small IoT devices typically have limited Random Access Memory (RAM) — sometimes as low as a few kilobytes [BEK14]. This RAM quickly fills up if the device is holding onto messages that are waiting to be acknowledged or retransmitted. Data is lost if the device does not have enough RAM available.
Maintaining connections is energy-intensive. Some IoT devices rely solely on a battery, and for convenience’s sake, that battery should last a few years mini- mum. Processing large packets, as well as maintaining listening connections, is power-intensive, and thus not practical for many IoT applications [BZB17].
Finally, limited processing power further complicates traditional networking for IoT devices. IoT devices are small and lightweight, and therefore have small processors — think about the tiny computer used in a smart home’s smoke detector versus the processor in your laptop. Processing large TCP/IP protocol packets requires significant processing power when compared to the processing power contained in an IoT device’s small, inexpensive microchip.
Network Layer Challenges
The network layer allows devices to connect. This layer covers communication topics such as routing, security, and addressing. The explosion of internet- enabled devices that make up the internet of things forces us to rethink traditional TCP/IP routing to ensure IoT enabled networks function as device numbers grow.
Addressing
Users need to device new ways of addressing to account for the growing number and types of devices entering networks. Devices have to connect to networks and be identifiable seamlessly. Some devices might only connect to a network temporarily, and then leave the network after sending data. Therefore, networks must be able to efficiently allocate an address and later recycle that address when it is no longer in use.
As the number of devices entering the internet of things grows, the demand for device address self-configuration grows too. Some devices might exist in areas where they are not easily retrievable in the case of network errors. Therefore, address resolution protocols must allow IoT devices to configure their address easily. Device’s configuring their address reduces the length of time users spend setting up devices [YT08]. Fundamentally, devices should be able to enter networks quickly and communicate.
Finally, address duplication needs to be detectable with minimal effort [BZ14]. Devices should be able to discern whether two or more of their interfaces share a duplicate address. Assigning various types of addresses (such as for broadcast or multicast) without causing collisions of devices with multiple interfaces is essential [BZB17].
Routing
Devices can avoid using the core network by taking advantage of device-to-device communication. Therefore, we must devise new ways for devices to communicate, and thus avoid clogging up networks as they grow with new devices. The IoT consists of many different types of devices which are transmitting differ- ent types of data, which makes this task challenging [OAH12]. As it currently stands, the IoT is over-reliant on the internet backbone. Devising new ways for IoT devices to communicate by using each other as nodes would allow for scalable network growth as more and more devices enter networks [OAH12]. Additionally, these networks consist of devices that are constrained by process- ing, memory, and storage limitations. Networks need to be aware of these nodes and know how to route traffic amongst them.
Quality of Service
IoT devices make up critical applications such as real-time patient health monitoring in hospitals. A failure in device-to-device (D2D) communication in a healthcare scenario could lead to patient death and inevitable hospital lawsuits. Thus device-to-device communication must be able to guarantee a certain quality of service.
QoS guarantees should account for conglomerated data coming from multiple inputs. A patient having a seizure might generate data from the patient’s heart monitor, brainwave-reading wearable stroke sensor, and a camera in the patient’s room. As big data and machine learning enter more-and-more hospital applications, hospital software systems will inevitably use multiple inputs to monitor patients. A heart-rate sensor alone won’t be enough to detect a person falling — but are easily identifiable when combined with an accelerometer and floor pressure sensor. Therefore, quality-of-services guarantees for multiple IoT devices sending data simultaneously in real-time are necessary [LRZ14].
Security Challenges
Resolution of security concerns is needed to ensure the safety of future IoT frameworks. High-end security algorithms require processing power and energy that resource-constrained IoT devices do not possess. Additionally, traditional TCP/IP architecture does not have an all-inclusive security mechanism. Systems implement security over the TCP/IP layers — which further bloats packets and requires additional processing power to create and handle. Therefore, re- searchers and practitioners must devise lightweight security algorithms for use in IoT networks [JLG13].
Generally speaking, IoT security goals match those of traditional computing, such as confidentiality, integrity, and availability [Mah+15]. To secure IoT devices on a network, it is necessary to:
- ensure that only authorized software is allowed to run on an IoT device.
- ensure that before an IoT device sends or receives packets on a network, it first authenticates itself on said network.
- ensure that network firewalls protect IoT devices that are unable to secure themselves.
- ensure that IoT devices can be patched and upgraded.
Additionally, two of the same devices might belong to two separate heterogeneous networks, and therefore interact with different devices with whom they share the network. Users must devise lightweight security protocols to secure devices both in existing networks and foreseeable future ones. Following the above helps ensure the confidentiality, integrity, and availability of IoT network devices and transmissions.
Device-to-Device Communication in the IoT
This section aims to provide an overview of some of the most popular short-range and wide area network protocols being used in the internet of things today. It is in no way exhaustive, but the various device-to-device communication protocols listed uniquely address some of the challenges facing IoT networking. As it stands, there is no one-size-fits-all solution for IoT networking. Sometimes users must make trade-offs, such as sacrificing battery life for higher processing power or long-range data transmissions [Mak].
Short Range Networks
Short-range wireless communication is communication that typically ranges from a few centimeters to several meters. These technologies require various levels of power and have data rates that can differ exponentially [BG14].
6LoWPAN
IPv6 over low-power wireless personal area networks (6LoWPAN) is a variation of the IPv6 standard. It allows for the transmission of IPv6 packets but modifies the TCP/IP stack by introducing a new layer between the network and link layers. The goal is the reduce header sizes and therefore reduce the overhead of processing transmitted and received packets. Additionally, this new layer allows for layer two (data link) packet forwarding. Layer two packet forwarding enables packets to travel over multiple hops. Neighbor discovery and multicast functions operate inside this new layer [BZB17].
6LoWPAN is the most commonly used IoT network protocol because it easily interfaces with existing networks. Because it is an IP-based standard, there is no need for intermediary entities such as proxies to allow a 6LoWPAN network to communicate directly with another IP network. 6LoWPAN provides for low power consumption at the cost of low bandwidth [AlS+17]. 6LoWPAN is leveraged by other D2D technologies such as BLE and DECT ULE to enable them to interoperate [BZB17].
DECT ULE
Digital enhanced cordless telecommunications ultra-low energy (DECT ULE) is a low-bandwidth and low-power communication standard used in many smart home applications. This standard originated from the DECT and NG-DECT protocols. DECT ULE typically uses a star network topology in which one device acts as the base, connecting other devices that makeup nodes [ETS17]. These nodes might be IoT devices typically found in your home - like remote controls, lights, baby monitors, or smoke detectors.
Even though DECT ULE is considered a short-range networking protocol, it still maintains a greater range than most other protocols in its class. In an outdoor environment, DECT ULE can reach up to 300 meters, which is much farther than ZigBee or Z-wave technologies [Sec]. DECT-ULE operates in the 1800MHz - 1900MHz band. Additionally, DECT-ULE uses dynamic channel selection and allocation to ensure communications happen over a channel with little interference [Sec].
DECT-ULE allows for a bandwidth of up to 1 Mbps. This bandwidth en- ables DECT-ULE to support voice transmission, in addition to typical sensor data. On the security side, DECT-ULE uses 128 bit AES encryption - a secure encryption standard, especially when compared to the 64 bit encryption of DECT [ETS17].
IEEE 1901.2 standard
The IEEE 1901.2 standard specifies a new way for devices to communicate over alternating and direct current electric power-lines. The standard allows for communications for low-frequency narrowband power-line devices. It supports both rural and urban communication for power lines whose voltage ranges from less than 1000 V to 72kV. Depending on network conditions, data rates can reach 500 kb/s [IEE13]. Specifically, IEEE 1901.2 addresses devices that connect to the power grid, such as utility meters and electric vehicles at their charging stations. IEEE 1901.2’s enables cities to implement intelligent street lighting and AI-assisted road transport communication using existing power-lines.
RFID
Radio-frequency identification (RFID) uses radio signals to identify and track tags attached to objects. RFID chips are already in many industries — such as pharmaceuticals, health care, transportation, retail, defense, and logistics. Additionally, RFID is replacing barcodes in many applications [AI17].
RFID works in two parts — a reading device called a reader, and another radio frequency transponder called an RF tag. When an RFID reader scans an RF tag, that RF tag releases a radio frequency which uniquely identifies that tag. The two main types of RFID systems are active and passive reader tag systems. Active tags are battery-powered, while passive tags do not have an internal power source [AlS+17]. RF tags cannot compute and only release the same static information; therefore, their application outside of identifying and tracking items is limited.
BLE
Bluetooth Low Energy (BLE) is a popular low-power wireless communication technology developed by the Bluetooth Special Interests Group. Researchers developed BLE for use in control and monitoring applications that require low energy usage. Research has found that a BLE enabled device running on a coin cell battery can run up to 14.1 years with potentially over 5000 slave de- vices per master. BLE allows for single-hop networking, as opposed to other protocols such as ZigBee, 6LoWPAN, and Z-Wave, which provide for multi-hop networking [GOP12]. Additionally, BLE supports a star network topology with an unlimited number of nodes [SBH16]. One important fact to note is that BLE is incompatible with traditional Bluetooth. Devices that wish to communicate via both traditional Bluetooth and BLE must implement each protocol separately [SBH16].
Due to the above considerations, BLE is useful for applications that wish to use a low amount of energy, and broadcast a small amount of data over a short range. Usages might include allowing car keys to unlock a car door when nearby, or to send a body thermometers readings to a user’s smartphone [BZB17].
ZigBee
Similar to BLE, ZigBee (sometimes written as Zigbee) is a low cost, low power, low data rate, wireless networking protocol. ZigBee is a proprietary protocol which is owned by the ZigBee Alliance. The Zigbee protocol formed when the ZigBee Alliance teamed up with the IEEE 802.15.4 committee to create a low data rate standard in 2004 [Erg04]. The goal of ZigBee is to provide an IoT solution for devices that need a few months of battery life but do not require the data rates facilitated by Bluetooth.
Typical ZigBee devices can transmit data between 10 and 75 meters, de- pending on radio frequency interference and device power consumption. Zigbee operates at the 2.4 GHz global band, 915 MHz Americas band, and the 868 MHz European band. Utilizing these bands allows for data rates of 250 kbps, 40 kbps, and 20 kbps, respectively [Erg04].
The ZigBee protocol specifies a standard by which devices can interoperate with ZigBee devices built by other manufacturers. ZigBee IP D2D communication allows devices to join networks, communicate, and pair with other devices using the same protocol. ZigBee devices can be ZigBee Routers, ZigBee Coordinators, or ZigBee End Devices. ZigBee coordinators manage the network, ZigBee Routers relay traffic and extend the network, and ZigBee End Devices are any other ZigBee devices within the network. The applications of IoT devices running on the ZigBee protocol include smart home devices, energy monitors, industrial remote controls, and healthcare devices [BZB17].
Z-Wave
The Z-Wave protocol is a proprietary protocol created by Zensys in 1999 that supports up to 232 Z-Wave devices in a network. Z-Wave enabled devices operate as a mesh network that transmits messages in the 800–900 MHz range [Wora]. The mesh network allows two Z-Wave devices that might be out of range to communicate with each other through intermediary Z-Wave enabled IoT devices [Wora]. In this sense, each Z-Wave enabled device acts similarly to a WiFi repeater.
From a networking perspective, Z-Wave is a half-duplex low-bandwidth protocol used to send short messages between Z-Wave nodes [Worb]. As such, it is used for non-critical data because it cannot support higher levels of QoS necessary for critical applications. The Z-Wave protocol has the following layers [IoT]:
- Physical (PHY): Tasks care of modulation and radio frequency channel assignment.
- MAC: Handles HomeID and NodeID. Uses collision avoidance and backoff algorithms to enable reliable node-to-node communication.
- Transport: Handles reliable transmission and reception of frames. The transport layer also handles acknowledgments, checksums, and retransmissions.
- Network: Handles routing table updates and frame routing.
- Application: Handles command execution in a Z-Wave network, along with decoding.
Z-Wave networks consist of one primary controller, zero or more secondary controllers, and one or more slaves. Primary controllers issue commands to the slave nodes. Slave nodes forward commands to other slave nodes in the net- work if necessary. Z-Wave uses a Home ID field in packet headers to specify the Z-Wave network to which the packet belongs. Each Z-Wave device has a unique 8-bit Node ID that is used in packet headers to determine the device that receives or has sent a request. The primary controller assigns node IDs [IoT].
Z-Wave is great for home automation IoT applications, including alarm monitoring, smart power management, and cooling/heating systems [Bad+17]. Typically, Z-Wave supports up to 30-meter point-to-point communication with data rates of up to 100 kbps [AlS+17].
Low Power Wide Area Networks (LPWAN)
LPWAN technologies are popular long-range communication protocols for IoT devices. They allow for optimized battery life, long-range, and low-cost IoT applications. LPWAN technologies can transmit data up to 10 km in urban areas, and up to 50 km in rural zones. Additionally, LPWAN enabled devices can run up to 10 years on a single battery charge. LPWAN is most effective in applications that require low energy consumption, extended transmission range, and where small data transmissions are acceptable [Cen+16].
SigFox and LoRaWAN are two of the best technologies for cost, battery life, and maximizing network capacity. NB-IoT is best in terms of QoS and latency guarantees [Mek+18]. This section aims to explore each of these technologies in greater detail.
SigFox
SigFox (sometimes written as Sigfox) is a low power, long-range, low bandwidth technology for wireless communication. It supports the transport of data packets ranging from 1 to 12 bytes over a distance up to 40 km [AlS+17]. SigFox uses a technology called Ultra NarrowBand (UNB). UNB is a system in which channels use a very narrow bandwidth to communicate. SigFox uses the unlicensed sub- GHz ISM (Industrial, Scientific, and Medical) frequency band. End devices connect directly to base stations using a star topology. SigFox is very efficient, has low noise levels, and thus low battery usage. SigFox’s efficiency allows for SigFox-enabled IoT devices to have low-cost antennas with high receiver sensitivity. SigFox does not acknowledge messages. Therefore, devices send the same message three times through different frequencies to try and ensure message delivery [Mek+18].
LoRaWAN
LoRaWAN is a LoRa based communication protocol standardized by the LoRa- Alliance. Similar to SigFox, LoRaWAN uses the unlicensed sub-GHz band [Sfo]. LoRa allows for low noise, bidirectional communication that is resilient to interference. It is also difficult to detect or jam [RMP16].
LoRaWAN allows for a data rate between 300 bps and 50 kbps, and a maximum data payload of 243 bytes. LoRaWAN is reliable because messages are received at all base receiving stations — making reception of messages redundant.
NB-IoT
Narrowband-IoT (NB-IoT) is an LPWAN technology that coexists with LTE and GSM networks. NB-IoT uses a bandwidth of 200 kHz, which is equal to one resource block in GSM and LTE [Mek+18]. NB-IoT is a stripped-down ver- sion of LTE that minimizes power-expensive functionalities. NB-IoT is therefore an LTE-like protocol for resource-constrained IoT devices. A single NB-IoT net- work can support more than 100k devices. NB-IoT uses QPSK modulation and FDMA in uplink and OFDMA in downlink communication[Wan+17]. Payload size is limited to 1600 bytes per message. Similar to other LPWAN technologies, NB-IoT enabled devices can survive up to ten years on a single battery charge, all while transmitting an average of 200 bytes daily [ALW16] [Mek+18].
NB-IoT enjoys a higher quality of service than LoRaWAN and SigFox be- cause it licenses a radio frequency spectrum. Licensing a radio frequency band comes at a high cost — LTE frequency bands can easily cost half a billion dollars [SWH17]. When compared to other LPWAN options, NB-IoT offers the most IoT connected devices per station and largest transmission size — all at the cost of battery power [Mek+18].
Conclusion
The internet of things is growing rapidly. IoT applications are in practically every industry. Integrating new devices into existing networks reliably and securely is a growing concern. Smoothly integrating IoT devices using device-to-device protocols that do not rely on the internet backbone assists in IoT device implementation and acceptance. Different devices have different requirements, and thus will use different networking protocols to operate.
Traditional TCP/IP is too heavyweight for many IoT applications. Each layer of TCP/IP adds headers to transmitted packets. TCP/IP also provides a certain level of quality-of-service because it uses checksums, acknowledgments, and retransmissions. Resource-constrained IoT devices are limited in their ability to use the TCP/IP protocol because of all the overhead.
Because of challenges related to IoT devices implementing TCP/IP, it is necessary to create new lightweight protocols that allow for varying levels of QoS guarantees. Protocols must also allow for data transmission and device networking to flow seamlessly. Additionally, IoT protocols need to be secure to ensure confidentiality, integrity, and availability of IoT network devices and transmissions.
Finally, this paper covered some of the most popular short-range and long-range IoT transmission protocols. Short-range protocols are common in indoor environments where the quality of service and higher data rates are essential. Outdoor IoT applications are more likely to utilize low power wide area net- works. LPWAN is best suited for applications where devices need long battery life, long-range, and can tolerate small data transmissions.
References
For references, please see my original posting of this paper on Academia.edu.
