IoT Networking

Introduction

When we use the term Internet of Things (IoT) we refer to the connection of everything to the network, that is to a close IP network or to an IP network that is connected to the Internet. These things are various types of sensors, connected to controllers, collecting information and controlling various types of devices.

The term “Internet of Things” was first set by Kevin Ashton of Procter & Gamble in 1999, to mark the connection of the company’s supply chain to the Internet and said in the context of the IoT that “in the twentieth century, computers are brainless, they do what we tell them “In the twenty-first century computers will feel things for themselves.”

It is important to note that the connection of electronic components to the network began long before the IoT. When the air-conditioner in our house connects to the home Wi-Fi network and we log in remotely to monitor or turn it on it is not IoT, it is a standard internet connection with access to the air-conditioner app. Same thing when we watch the security cameras at home or when the fridge sends us messages that the milk is running out. These are standard applications that use standard networks to transmit data to us and receive commands to the electrical device. IoT is much more than that – IoT is a network architecture, protocols and applications that come to give a standard language that all components can talk to each other, easily and quickly, and for that new protocols have been defined, most of which are still evolving and many more will develop and change in the coming years. In this article we will talk about the technology, the protocols and the various implementations.

What are the requirements from an IoT network?

Before we get into technology and protocols, let’s try to understand what an IoT network is, and what we need from that network. Like we said, the IoT network is not the connection of the air conditioner in the house. The IoT network is a connection of hundreds, thousands and even millions of different sensors, for example tens to hundreds of sensors in our vehicle, which send and receive information from vehicles close to us, millions of vehicles worldwide that send a manufacturer warning about vehicle malfunctions, farm vehicles that work independently and talk to external servers, port management systems that receive information from sensors that are on every crane and every container, sensors on our body that monitor the human organs in the body, sensors in industrial plants that operate and monitor the machines and the work between them and more. Since the various applications have been talked about a lot, in this article we will go into the technical part, i.e. how it all works.

Because of this, let’s first look at the requirements set for IoT networks, each of which is a huge challenge in itself (and these are just the main issues, before going into the technical details):

1. Millions of components connected to the network in limited areas, billions of components in the country and more worldwide, with some of the components fixed in place but a large part of them portable.
2. Lossy networks, low bandwidth, batteries that should last for many years and therefore should be used for short periods of time.
3. Millions of sensors that produce large amounts of information that reach central servers in a short period of time and requires fast responses.
4. Non-IP components, i.e., non-IP components that are connected to the network by gateways that sent and receive information to these components.
5. Requirement for fast responses (Realtime), i.e., commands that will be passed to sensors and indicators that will be received from them at extremely fast times.
6. Extremely long battery lives – sensors are supposed to work for many years without replacing the battery (or replacing the sensor itself).
7. After all we have said, with all the limitations we have listed, strong information security mechanisms are required, as the sensors are of extremely critical systems whose damage can result in damage to human life and severe economic damage.

How do you deal with all this? The solutions exist but so do the challenges. For example, for large number of components we will use IPv6, for low latency networks 5G networks improved latency by improving the air-interface to provide milli-seconds delays and standardized the technology for massive machine-type communications and many other protocols came along. New concepts of information security based on artificial intelligence (AI) decodes information passing through the network and identify suspicious traffic patterns (you can read more about this here). There are also new and faster protocols – 6LoWPAN, 802.15.4, LoRA and others that came into the market for these specific requirements.

In this article we will talk about these protocols, but before this, let’s talk about IoT network architecture.

IoT Network Architecture

Number of network architectures for IoT came out over the years. Practically, the most common topology is what we see in the following figure.

To the left of the figure, we see the network of sensors and actuators. Sensors that send information from the controlled devices and actuators that send commands to the controlled devices. We also see the gateways that connect the sensors to the corporate network. The cooperate network, usually the “OT” or Operational Technology part of it, which is responsible to the operational aspects of the organization, is connected to the datacenter, whether on-prem or cloud based.

As with any communication network, to transfer information from end to end we need a physical link from the end components to the component that will connect them to the network (levels 1-2 in OSI model), addresses, end to end routing, linking between applications (levels 3-4 in OSI model) and applications that transmit information from sensors to servers (Levels 5-6-7 in the OSI model).

To implement the requirements, the main options accepted for IoT networks are:

1. Cellular networks (4G / 5G)
2. Wireless networks (WiFi)
3. LoRa / LoRaWAN
4. Bluetooth Low Energy (BLE)

Let us start with Cellular networks.

4G/5G Cellular Networks

We start with 3GPP, the standard organization of cellular networks. If in the third generation networks the emphasis was on high bandwidth and in the fourth generation on critical applications (Mission Critical), for example PTT applications for high quality voice and video calls (3GPP R.13 / R.14), in the fifth generation (version R.14 which is considered a preliminary version for the generation Fifth and in R.15 and later versions that define the fifth generation) the main innovations are for IoT work. For example, version R.15 defined services for Massive MTC (Machine Type Communications), standardization for V2X (Vehicle to Everything), Network Slicing for the division of the network into subnets at different service levels and more. Version R.16 of the standard set standards for industrial IoT networks and better battery efficiency, and many further improvements were defined in version R.17, with version R.18 in progress.

In the next drawing we see the structure of a 4G network – the cell itself (eNode-B), connection to pGW / sGW routers that transmit the information (the User / Data Plane), MME and HSS. The added component is the PCRF. When connecting an IoT component to a network, it sends a request for authentication via the MME to the HSS. If there is a confirmation of the connection, a notification is sent to the routers that transmit the information.

In terms of working principles, no one has reinvented physics. Battery savings are achieved by turning on the radio (reception transmission) only for short periods, low prices are achieved by using a single antenna (without MIMO), low bandwidth and Half Duplex and not Full Duplex, load control (Congestion control) by providing Priorities and limitation of bandwidth and so on.

In the 5^th Generation, the network is more service-oriented. As we see in the next figure, we see how it’s done. The UPF router in connected to the SMF controller, that is connected to the PCF that can enforce traffic policies. On the right we have the AF which acts as an interface to external applications and top-left we have the NSSF that allows us to chose a slice of the network (termed ”network slicing” in 5G terminology) that suits our application, in this case IoT applications.

When we get to some more details, the two main technologies developed for IoT already in version R.13 are LTE-M and NB-IoT. Both protocols came out in 2017, with NB-IoT designed for lower bandwidths and LTE-M designed for work with higher bandwidths. As we can see from the table there are sub-categories for both LTE-M and NB-IoT. When choosing a technology, there are many other parameters that need to be decided on, such as the manufacturer’s support, the cellular provider’s network support and others. We will go into depth on these topics in the IoT Networking course.

The type of technology is of course chosen as needed – for applications such as inventory management sensors, agriculture and animals, street lighting, etc. we will need low bandwidths at the level of tens of Kbps. For applications like smart homes, car fleets etc. we will join higher bandwidths at the level of hundreds of Kbps and for applications for vehicles, surveillance cameras etc. we will need Mbps bandwidths. According to these requirements we will define the required technology.

Wireless Networks (Wi-Fi)

In wireless networks, in the IEEE 802.11 standard, we have of course the more familiar standards and the devices that supports them – 802.11ac (Wifi 5) and the newest device 801.11ad (WiFi 6). These standards are for enterprise networks and you can read more about them here.

These technologies can be used for supported IoT components; however, these technologies are designed for laptops and mobile devices and have not been given attention throughout battery life. For IoT, Wi-Fi standards organizations developed the 802.1ah standard or Wi-Fi Ha-Low, designed for IoT environments. This standard is for work at 900MHz frequencies that requires licensing but allows work for longer ranges, with lower energy consumption.

LoRa and LoRAWAN

The LoRa (Long Range) Alliance is a manufacturers’ forum that developed the technology and protocols for LoRa and LoRaWAN (Wide Area Network). This technology competes with cellular networks for IoT implementations in a way that can cover large areas by a single gateway, and deploy large networks over large areas, with LoRa defining the physical level and LoRaWAN defining the network architecture and protocols.

LoRaWAN networks are based on sensors, gateways, and application servers (as outlined at the beginning of the article), where each sensor can forward the messages to several gateways, which will transmit the messages to the system servers located on-prem or in the cloud. The advantage of this method is also that in mobile sensors there is no need to set roaming because wherever the sensor is located it can send and receive messages through any Gateway it sees.

At the physical level LoRa is configured to operate at 915MHz (US), 868MHz (Europe) or 433MHz (Asia). Due ot these low frequencies we have less frequencies to use, but we are more tolerant to noise and interference and have higher distances.

Three types of components are defined at the Datalink level of LoRaWAN:

1. The most economical Class A in terms of battery consumption. This mode of operation is the re-choice and must be supported by each component. In components of this type of the communication will always be at the initiative of the end sensor.
2. Class B at a medium level of economy, where in this way Beacons will be sent to the network every regular period, and “time channels” will be opened for listening every regular period.
3. Class C which always leaves the receiver open, so its response times will be the fastest, but the battery consumption will be the highest.

In terms of the information structure in LoRaWAN, as we see in the drawing, the information between the sensor and the Gateway is modulated directly above the physical level, and when it reaches the Gateway it is transmitted to the IP and continues over the IP to the application servers.

The goal is of course to save the amount of information transmitted to and from the sensor, since reaching the sensor in Frame Level 2 and above it TCP / UDP and IP adds to the amount of information transmitted and requires more battery time for transmission and reception.

802.15.4 and ZigBee

Another common standard for the lower layers is IEEE 802.15.4, where 802.15.4g defines work at the physical layer and 802.15.4e defines work at the Data Link layer. This standard defines work in the field of unlicensed 2.4GHz frequencies and therefore does not require licensing. The device defines work in the form of Sleep-Wake meaning that the device only works when it is transmitting or receiving information, when 99.9% of the time it is inactive, and only occasionally wakes up for a few milliseconds to check if it has any transmissions. The device allows working at ranges of up to one hundred meters, and at a working speed of up to 250Kbps.

BLE (Bluetooth Low Energy) which is part of the Bluetooth 4.0 facility also works in the 2.4GHz frequency band (like the older Bluetooth) and is supported on most standard operating systems. The device supports network connections as MESH with up to 32K components.

Two other higher layers protocols are IPv6 and 6LoWPAN. IPv6 importance is in the large number of addresses, and in other capabilities such as built-in encryption (with IPsec) and more. The problem with IPv6 working over 802.15.4 is that the last frame size is up to 127Bytes, and the maximum packet size in IPv6 is 64Kbytes and IPv6 does not allow fragmentation of the packet, standard developer (IPv6 over Low Power Wireless Personal Area Networks) 6LoWPAN for adjusting IPv6 to 802.15.4, with what the device allows is the transfer of IPv6 over 802.15.4 frames. The device is set to RFC8066. A parallel standard, RFC7668, defines IPv6 transfer over BLE frames. Parallel protocols is 6TiSCH and 6Lo.

Management and control protocols

What we have seen so far are protocols and network architectures that aim to transmit network servers and sensors, and now we will talk about the passing information, i.e. the commands and messages passing between them.

A simple read/write protocol that is used a lot is of course HTTP, but for IoT implementations it is too “heavy” protocol. Both work over TCP which is a wasteful protocol in terms of network resources (connection establishment, connection closure, retransmissions and more), and a large and complex header make HTTP irrelevant to IoT applications. Due to this, additional protocols were developed. Constrained Application Protocol (CoAP) for example that works over UDP with a short set of commands (GET, POST, PUT, DELETE) versus HTTP, option for working with certificates like in HTTP (which get OK after executing a command), or without certificates (Confirmed/Unconfirmed).

Another management protocol is MQTT (Message Queue Telemetry Transport) which is also a messaging protocol. MQTT works over TCP and is based on the “Publisher” model which is for example the sensor and the “Subscriber” which is for example the application. You can also subscribe to certain topics (Topics) and then get only the information you want.

Technologies comparison

Comparing LoRaWAN with other technologies we the following parameters.

Operational Technology (OT) and Information Technology (IT)

Another important issue that came to mind with the development of IoT is the connection between IT (Information Technology) and OT (Operational Technology). The IT systems are the business enterprise systems that are also connected to the Internet, and the OT systems are the production systems themselves, for example the production lines in factories, the transportation systems in ports, and so on. Traditionally, for decades the IT and OT systems have been interconnected to one degree or another, with no clear policy of unifying or separating the networks, but in recent years there has been a growing debate over whether to connect or separate the networks.

Another factor that encourages the connection between the networks is that the networks are gradually moving to uniform technologies. If 30-40 years ago the industrial and operational networks were in completely different network technologies from IT technologies, with the development of IoT all systems and networks switch to standard protocols, however when IT networks are also connected to the Internet of course the fear of connecting the operational networks is justified.

In Israel, when it comes to critical national infrastructure (ports, electricity company, sources, airports, fuel manufacturers, etc.), the cyber authority requires separation between IT / OT networks as safely as possible.

In the following articles I will go into design and technology selection considerations, various applications including industrial applications, transportation applications, energy applications, applications for buildings and smart campuses, security applications and of course how to secure IoT networks. We will also talk about products, economic-business aspects of the various technologies and of course the important issue of linking the IT and OT networks. Anyone interested in delving deeper into these topics is welcome to sign up for the IoT Networking course here.

Summary

We have gone through the major technologies used for IoT networking. Keep watching technologies and developments – many thinks are going to happen here in the next years, even in the next months.