IoT Device Architecture

Because there are so many ways to build a cellular-connected IoT device, it is hard to give specific recommendations that are valid for every device and application design requirement.

GSMA TS.34, therefore, generalizes the device architecture to the following:

• IoT Device Host – The application specific environment containing the IoT Device e.g. vehicle, utility meter, security alarm etc.
• IoT Device – The combination of both the IoT Device Application and the Communication Module.
• IoT Device Application – The application software component of the IoT Device that controls the Communications Module and interacts with an IoT Service Platform via the communications module.
• IoT Communication Module – The communications component which provides wide area (2G, 3G, 4G) radio connectivity. Comprising of IoT Communications Module Firmware, Radio Baseband Chipset and UICC.
• IoT Communications Module Firmware – The functionality within the IoT Communications Module that provides an API to the IoT Device Application and controls the Radio Baseband Chipset.
• Radio Baseband Chipset – The functionality within the communications module that provides connectivity to the mobile network.UICC – The smart card used by a mobile network to authenticate devices for connection to the mobile network and access to network services.

In addition to this generalized device architecture, devices are also often distinguished by:

• Operating System (OS)-driven devices, where the IoT Communications Module is typically controlled by dedicated management software running in parallel with the IoT Device Application inside the operating system
• Microcontroller-driven devices, where the IoT Communications Module is typically controlled directly by the IoT Device Application (either using the microcontroller’s own IP stack or an IP stack that is integrated in the cellular module)
• Embedded devices, where the IoT Device Application runs on a separate application processor inside the IoT Communications Module (sometimes called SoC or System-on-Chip)

No matter the variant, the IoT Communications Module handles the 3GPP-standardized baseband stack required for connecting to cellular networks, and all such modules have passed multiple certification steps during their development cycle, which will usually guarantee network-friendly operation.

However, as IoT Device Applications control these modules, the application may cause the module to behave in a way that causes serious harm to a cellular network. Therefore, it is critical that the application is designed appropriately.

While some scenarios that can cause harm to a cellular network are derived from cyber security attacks, most are from devices that just want to maintain connectivity and transfer data as fast and easily as possible.

The most common scenarios from these problematic devices are:

• The IoT Device Application turns the IoT Communications Module on and off excessively to achieve power savings or attempt to restore a cellular network connection more quickly.
• Performing the same action across a large number of IoT Devices simultaneously, such as restarting devices or updating device firmware at the same time, results in a kind of “denial of service” attack from a cellular network point of view due to a sudden surge in network connections or data transfer.