Internet of Things ( IoT ) Networking
For consistent connectivity locally among IoT things and to remote cloud or on-premise IoT platforms requires having the right type of network infrastructure that suits the characteristics for IoT devices. Many business need to research and take a lot of factors into consideration. Bandwidth on cellular networks is expensive and we are seeing the deployment of both short-range Low Power and long-range Low Power networks in the IoT world. IPv6 and 6LoWPAN compression and fragmentation techniques enable IP on even the smallest of devices offering direct IP addressing and an NAT-free world.
Depending on device requirements and characteristics, the design might consist of a number of “type” centric design approaches. For example, we can have a thing-centric, gateway-centric, smartphone-centric, and cloud-centric designs that are selected based on IoT device requirement. Some processing may need to be performed locally if there are slow and expensive satellite links resulting in a thing-centric design. Other device types require local gateway support while others communicate directly to the IoT platform.
IoT device driven design
The design of IoT networks are device type driven and it really depends on the memory and processing power of the things. They drive a new network paradigm, a paradigm no longer well defined with boundaries. It is dynamic and extended to the edge where IoT devices are located. It is no longer static as some of these devices and sensors move and sleep as required.
There are many factors to consider when selecting the wireless infrastructure. You need to take into consideration 1) range, 2) power consumption and battery life, 3) data requirements, 4) security, 5) endpoint and operational costs of IoT devices. These characteristics will dictate the type of network and may even result in a combination of technologies. Similarly to how applications drive the network design in a non-IoT network, the IoT device and the application it serves drives the network design in the IoT atmosphere.
Cellular connectivity is the most widely deployed network but for IoT, it’s expensive per node and has poor battery life. As there is going to be way more IoT endpoints than cellular phones new types of networks are needed. Cellular networks are not agile enough and provisioning take ages. Smart IoT devices require more signaling than what traditional cellular networks are used to carrying. Devices require bi-directional signaling between each other or to remote servers and this needs to be reliable. Reach is also a challenge to connect up far-flung IoT devices.
Two types of networks are commonly deployed in the IoT world – short-range Low Power and long-range Low Power networks.
Short-range low power
New types of devices, data types, and traffic profiles result in new types of access networks for the “last 100 meters of connectivity”. As a result, we see the introduction of many different types of technologies at this layer – Z-Wave, ZigBee, Bluetooth, IEEE 802.15.4 , 6LoWPAN, RFID, Edge, and Near Field Communication ( NFC ).
Devices that live on short range networks have very specific characteristics 1) low cost, 2) low power consumption, energy is potentially harvested from another power source, and 3) short range with the potential for the extension with a router or repeater. These networks usually offer a range of around 10 – 100 meters, 5 – 10 years of battery life, low bandwidth requirements, and low endpoints costs. Potentially consist of 100 – 150 adjacent devices and usually deployed in the smart home / office space.
The topologies include point-to-point, star, and mesh. A gateway device is usually included acting as a bridge or interface linking the outside network to the internal short range network. A gateway could be as simple as a smartphone / mobile device. For example, in an access control systems, a smartphone could be used as the temporary gateway when it approaches the sensor / device. More than likely an architecture with a gateway between the WAN and the short-range network is needed for short-range Low Power networks.
Short-range low power technologies
Bluetooth Low Energy ( BLE ) or Bluetooth Smart
Bluetooth Smart has the largest ecosystem with widespread smartphone integration. It fits nicely into many sectors including home and building, health and fitness, security, and remote control. It has the potential for less power consumption than IEEE 802.15.4 and looks strong as a leader in the last 100 meters. Now, recently with Bluetooth 4.2, BLE devices can directly access the Internet with 6LoWPAN. It has a similar range to that of Classic Bluetooth and comes with additional functionality designed to reduce power consumption. BLE is reliable with its support for Adaptive Frequency Hopping ( AFH ).
The data rate and range depict if you can use BLE or not. If your application sends small chunks of data then you’re fine but if you want to send large file transfer you should look for an alternative technology. The range is suited for 50 – 150 meters with a max data rate of 1 Mbps.
IEEE 802.15.4 wireless
IEEE 802.15.4 will be the niche wireless technology of the future. It already has an established base in the home and building automation space. The IEEE 802.15.4 market is targeting small battery powered devices that wake up for a period of time and go back to sleep again. IEEE 802.15.4 consist of a low bit, low power, and low costs endpoints. The main emphasis is on low-cost communication between nearby devices.
It is only the physical and MAC layer and doesn’t provide anything on top of that. This is where for example ZigBee and 6LoWPAN come to play. Specifications, such as 6LoWPAN and ZigBee are built on the IEEE 802.15.4 standard and add additional functionality to the upper layers.
15.4 has simple addressing with no routing. It has a star and peer-to-peer topologies. Mesh topologies are supported but you need to add additional layers that are not defined by default in IEEE.
ZigBee is suited for applications with infrequent data transfers of around 250 kbps with a low range between 10 – 100m. It’s a very low-cost network and a lot simpler than Bluetooth and Wifi. It is a proprietary solution and there is no ZigBee support for the Linux kernel resulting in a significant performance hit for userspace interaction. This is one of the reasons why 6LoWPAN would be a better option, that also runs on top of IEEE 802.15.4.
NFC ( Near Field Communication ) has low power but very short range enabling a simple 2-way interaction. An example would be a contactless payment transaction. WLAN ( wifi ) has large ecosystem but high power consumption.
Low-power wide-area network (LPWAN) or Low-power network (LPN)
BLE, ZigBee, and Wifi are not designed for long range performance and traditional Cellular networks are costly and consume a lot of power. Low Power networks are a class of wireless network consisting of constrained devices in terms of processing power, memory, and battery life. The length of device battery is dependent on the power consumption and low power consumption enables devices to last up to 10 years on a battery.
When a device transmits a signal, it needs energy for the receiving side to detect it. As always a certain amount of power is lost during transmission. One of the reasons for LPWAN long reach is for a high receiver sensitivity. Receiver sensitivities in LPWAN operate at -130 dBm, normally in other wireless technologies this would be 90 – 110 dBm. Receiver sensitivity operating at -130 can detect signals 10,000 times quicker than at -90.
It offers long range communication at a very low bit rate. LPWAN have a much longer range than Wifi and more cost effective cellular networks. Each node can be up to 10 km from the gateway. Data rates are low, usually only between 20 – 256 bytes per message are sent per day. These types of network are optimized for specific types of data transfers consisting of small, intermittent blocks of data. Not all IoT application transmit large amounts of data. For example, a parking garage sensor only transmits when a parking space in either occupied or empty. Devices within these networks are generally cheap at £5 per module and optimized for low throughput.
IPv6 and IoT
All the emerging IoT standards are moving towards IPv6 and 6LoWPAN. There is a big adoption of IPv6 in the last mile of connectivity. Deploying IPv6 brings many benefits. It overcomes any problems with NAT providing true end-to-end connectivity and direct addressing of end hosts. It has mobility support and stateless address autoconfiguration.
The fundamental problem with NAT is performance. When everything is NAT’d for an IoT device to be contacted from the outside performance gets very painful. NAT also breaks flexibility in networking as an IoT device can only be accessed if it first contacts. Not only does this break true end-to-end connectivity it makes it difficult to share IoT infrastructure among different IoT providers. What we really need is an NAT-free scalable network that IPv4 cannot offer, a solution that does not require gateways or translation devices that only add to network complexity.
It’s far better to use IPv6 and 6LowPAN than proprietary protocols. It’s proven to work and we have a lot of operational experience. With the use of 6LoWPAN, IPv6 can be compressed into a couple of bytes of data which is useful for small and power constrained devices.
6LoWPAN on IEEE 802.15.4 networks
6LoWPAN is all about transmitting IP over IEEE 802.15.4 networks. As the name suggests, its IPv6 over LoWPAN ( IEEE 802.15.4 ) enabling IP to the smallest of devices. Rather than using an IoT application protocol like Bluetooth and ZigBee, 6LoWPAN is a network layer protocol that has frequency band and physical layer freedom. It’s suitable for small nodes ( 10 kilobyte of RAM ) and sensor networks for machine-to-machine communication.
15.4 has 4 types of frames 1) Beacon, 2) MAC command, 3) ACK, 4) Data – this is where the IPv6 packets must be carried.
6LoWPAN is an adaption layer between the data link and network layer ( RFC 4944 ). It actually becomes part of the network layer. So, instead of using IPv6 natively on the MAC layer they have a shim layer that adapts between the data and network layer. As it’s a network layer protocol it doesn’t provide any functionality above layer 3. As a result, it is often used in conjunction with Constrained Application Protocol ( CoAP ), MQTT ( machine-to-machine (M2M)/”Internet of Things ) protocols.
6LoWPAN header compression and fragmentation
IPv6 allows maximum packet size of 1280 bytes. However, the maximum transfer size for 802.15.4 is a 127 byte MTU which means a full IPv6 packet does not fit in a 15.4 frame. By default, a 127 byte 15.4 frame only leave 33 bytes for the actual payload. This small frame size support is one of the reasons why deploying a full IP stack would be challenging. A couple of things must be done to make this work and compliant with IPv6 standards. In order to use IPv6, we need to make some adjustments to header overhead and adaptations for MTU size.
The first thing we have to do is to bring back fragmentation to IPv6. In order to allow such packets, we define a fragmentation scheme. The 11-bit fragmentation header allows for 2048 byte packet size with fragmentation. A lot of tables in the IPv6 header are static and you might not need them. The version will always be 0, so will the traffic class and flow label.
Finally, the full TCP/IP stack is not one size fits all and on small devices would certainly reach hardware limitations. It’s better to use UDP ( DTLS ) instead of TCP. Packets loss on the lossy network may invoke additional latencies while TCP carries out retransmissions. You can still use TCP but it won’t be optimized and the headers will not be compressed.