By Imagination Technologies
What is the Internet of Things?
The Internet of Things (IoT) is an emerging market trend impacting semiconductor devices, system OEMs, cloud service providers, and internet infrastructure companies. The trade press, accompanied by the types of companies mentioned above, has spilled a lot of ink on the subject, but this is typical in an emerging market with evolving requirements. For the purpose of this white paper, an IoT device or related service applies to the following characteristics.
- The device is connected via LAN, WLAN or WPAN.
- The device communicates certain localized information or requests for service to a network hub or through the network hub to a cloud-based service.
- The cloud accumulates data from the networked device or provides a service or capability to the networked device.
An IoT device can cover a great deal of capabilities and be part of a wide range of vertical markets. To break down the market segments of the Internet of Things, one can look at the requirements of the device in terms of:
- Sustained transmit and receive data rate required for the IoT device
- Type of data the IoT device is handling; for example, the IoT device can be generating or receiving video, audio or other content/data
- The level of processing at the edge of the network; for example, an accelerometer can measure acceleration and velocity, but local sensor data processing may convert that data into distance or energy
- The type of transactions between the device and the cloud; for example, whether the device provides any type of proprietary or sensitive data such as medical information which needs to be protected by HIPAA (Health Insurance Portability and Accountability Act of 1996) laws in the United States
Most IoT applications will be supported by wireless LANs – Wi-Fi (802.11n or 802.11ac) by 802.15.4 (Zigbee) and by Bluetooth.
Classes of IoT devices
IoT devices can be classified based on the type of data handled. It is useful to view the requirements for IoT devices in this way as a way of determining the device requirements from a power, connectivity and security perspective. We can classify the devices as follows based on the types of data handled:
- Machine to machine data
- Audio
- Audio/video
Table 1 shows the requirements of the IoT device based on the type of data handled. This table is for illustrative purposes and specific IoT device requirements may vary.
Table 1: IoT device classification
| | IoT (M2M data) | IoT (Audio) | IoT (Video and imaging) |
| Device example | Personal health
Sensor hubs
Smart home
Energy management | Wireless audio | Chromecast
Connected camera
Video analytics
Ray tracing enabled imaging |
| CPU type/performance | M51xx/50 MIPS | M51xx/300 – 500 MIPS
I6400/500 – 800 MIPS | MIPS I6400/P5600
2000 – 5000 MIPS; GPU |
| OS requirement | RTOS or No OS | Linux/Android or RTOS | Linux/Android |
| Power requirements | 30 days on 700 mA-hr battery | 1 day at 1000 mA-hr | Line powered by USB or line |
| Connectivity | BTLE and low power Wi-Fi
802.11n/BT/BTLE
Later – 802.11ah | Low power 802.11n/BT/
BTLE | 802.11ac |
| Semicon process | 40 nm | 40 nm/28 nm | 28 nm/16 ff |
| Differentiators | Data security
Low power
Integrated connectivity
Cloud ready | Data security
Secure update
Digital Rights Management
Integrated connectivity
Cloud ready | Data security
Secure update
Digital Rights Management
Integrated connectivity
Cloud ready |
A continuum of capabilities
An IoT device connects a physical device to the cloud for services or further data processing. The device requires certain functional capabilities, and these capabilities will vary based on the application. There are a set of requirements that are needed by IoT devices, but the scope and the performance of those features will vary based on the application requirements. These feature set requirements are shown in Figure 1.
- Power requirements and power management
- Processing power – both CPU and GPU
- Connectivity requirements
- Security requirements
- Cloud interface
Figure 1: IoT continuum of capabilities
Power management
Power management is most important for mobile and other battery backed up devices. In a battery powered device, optimizing dynamic as well as static power is imperative. Power optimization is addressed in three different ways:
- Power management control
- IP implemented for low power
- Power aware software
Power management control should address the inclusion of voltage and frequency scaling. In order to integrate power management control into an IoT device, the system designer needs to identify the known power states for each of the major functional blocks within the device. Table 2 provides an example of power states that the blocks within an SoC that are valid.
Table 2: Valid power states
| Power state | Power applied | Clocks applied |
| On | VDD Nominal | FCLK = Full speed |
| Idle | VDD Reduced | FCLK = Reduced |
| Sleep | VDD MIN only for memory and F/F state retention | FCLK = Gated off |
| Off | VDD Off | FCLK = Gated off |
IP blocks for IoT should be designed to include power control wrappers for power and frequency scaling as shown in Figure 2. IP providers, such as Imagination Technologies, can provide power control wrappers that will enable a functional IP block to be set to a valid power state within the device.
To implement IP for low power, the system designer must fi rst identify the power management objectives. In the case of an IoT device, where the device is turned off for signifi cantly longer time periods than it is turned on, leakage power will dominate the power consumption of the device. In the example of leakage power domination process selection, ie., where choosing a process technology with low leakage is an imperative, leaking can be further reduced by implementing the chip with high Vt devices and using power gating where ever possible.
If the device is turned on for the majority of time, as in IoT devices such as sensor hubs, dynamic power will dominate. To reduce the dynamic power, voltage and frequency scaling should be implemented as a part of the power management function. In addition, choosing processes and memory IP that can operate over low voltages, such as operating in the 0.7 V to 0.8 V regime in a 40nm process is highly desirable. A useful scheme to reduce power for a CPU is to close timing based on reduced values of supply voltage. This is commonly referred to as voltage scaling. For example, by operating a MIPS M-Class processor such as the M5150 CPU through voltage scaling at 0.95 V as opposed to the minimum voltage of 1.08 V results in a power reduction of 23%.
However, a lot of the dynamic power savings would be lost if the wireless communications systems operate ineffi ciently. Bluetooth Smart (also known as Bluetooth Low Energy or BTLE) is positioned for very low power wireless communications, but the power reduction comes at the cost of reduced range point-to-point communications, and low data rates. For applications requiring higher data rates (see Figure 1), Wi-Fi would be a suitable solution. Imagination has developed a lowpower Wi-Fi offering including baseband called Ensigma ‘Whisper’. Low-power Wi-Fi is possible in Whisper by exploiting the low-power aspects within the 802.11 specifi cation. Whisper can operate 802.11n over a single 2.4GHz band radio.
Figure 2: Power management control for IoT
Security
A key requirement for IoT applications is security. IoT opens up networks to a variety of threats as more and more devices are connected to a network and eventually to the cloud. Figure 3 shows an example of an IoT device being used for home automation that is connected to a home network with possible threats to the network security.
At the edge of the network, as multiple IoT devices are added, the potential threats are greatly increased. The threats to networks with connected devices are documented and are newsworthy. The LifX brand of connected LED bulbs have been reported as being able to leak wireless security information.1
IoT devices must be capable of providing a robustly secure environment. Security is achieved in the following ways:
- Secure boot
- Secure code update
- Key protection
- Tamper resistance
- Access control of secure resources
- Secure DMA (Direct Memory Access) with data encryption for critical functions
- Session authentication
Figure 3: Threats to networked devices
Secure boot
When the IoT device is powered up and begins execution, the system must start execution with trusted code at boot time. In an IoT system, the trusted execution can be accomplished by having a secure CPU run trusted code on-chip. This trusted code must have its credentials secured from the time the credentials leave the secured credentialled vault to the time the code is implemented on the IoT device. The secure boot code must not be capable of being tampered. Imagination has developed and licenses IP that provides the secure boot feature required in IoT systems.
Secure code update
An IoT device can be hacked by corrupting the embedded software with malware. To protect against this type of attack requires the firmware to be properly credentialled and downloaded to the IoT device in a secure manner. The secure update, which is available as an intellectual property block from Imagination, is accomplished by means of including the hardware required on the IoT device to be encapsulated within a cryptographic boundary. The updated firmware is encrypted and downloaded to the IoT device where it is decrypted and the credentials are checked. This is an important use case in consumer devices where software updates are provided for bug fixes (including security improvements) as well as adding additional functional capabilities to the IoT device.
Key protection
Private keys consist of a set of addresses of OTP (One Time Programmable) memory which can be programmed with keys for encryption, authentication and device identifier. The memory needs to be configured on-chip so that:
- OTP is not accessible via external pins of the IoT SoC device
- OTP memory contents may be encrypted
- OTP memory contents are accessible only by ‘trusted processes’ running on the application processor
Tamper resistance
Simple Power Analysis (SPA), Differential Power Analysis2 (DPA), and High Order Differential Power Analysis are techniques whereby analysis of the power and other electrical emissions from a semiconductor device can provide information about the encryption techniques and codes used. These emitted signals are a point of attack that require countermeasures. These attacks are addressed to the CPU and associated hardware that runs encryption and decryption. MIPS M-Class CPUs are tamper resistant by implementing the following countermeasures including user-defined scrambling of the cache memory address and data and injection of random pipeline stalls.
Access control of secure resources
In an IoT system where a device is sending proprietary data or is engaged in commerce, the software processes running on the device are required to have secure access to peripherals and memory. This is needed to maintain security and to ensure malware cannot access the same information in memory or on peripherals as may be required by the secure processes. Consider the following example where a medical device may measure certain data on an individual, where such data is controlled by the HIPAA laws in the United States. Also this example assumes that a second process is running that is communicating with a medical insurance company to validate insurance. In this case there may be multiple processes running on the CPU, but there are two processes running that are required to be secure and isolated. In this type of situation, virtualization is required in order to isolate the hardware resources committed to each of the secured processes running on the CPU, as illustrated in Figure 4. MIPS processors support hardware virtualization.
Figure 4: Benefits of virtualization
Secure DMA
DMA transfers to memory in a secure IoT device must be encrypted. The DMA engine and associated peripherals and memory should be encapsulated with in an encryption boundary so that any transfers into or out of the memory boundary will be encrypted or decrypted respectively.
CPU processing performance requirements
Architectural considerations for the CPU performance for an IoT device will depend on the scope of what the CPU needs to do, as well as hardware security provisions contained within the hardware of the CPU. For example, for an embedded controller IoT sensor hub system, the following performance requirements would be required.
| Function | CPU performance required | Application |
| Embedded OS overhead | 10 MIPS | Eg., Real time kernel/scheduler |
| Security | 20 MIPS | Running AES 256 encryption/decryption stream/ CPU support of dedicated AES encryption engine |
| Sensor interpretation software | 50 MIPS | Eg., Sensor platforms context aware |
| Wireless communications management | 20 - 40 MIPS | Wi-Fi device AP mode – requires 40 MIPS |
| Internet messaging | 20 MIPS | |
| Total | 120 MIPS to 140 MIPS | |
Table 3: Performance budgeting for a sensor hub application
In Table 3, a MIPS M5150 CPU, which includes hardware virtualization, is capable and provides 70 DMIPS/MHz to run the sensor interpretation code, the Wi-Fi stack, and internet communications with a clock speed of about 100 MHz. Most IoT devices will be designed with additional CPU capability to support additional features to be added via software upgrades. As a result, the performance of the CPU will need to be scalable, and may also include special pipeline stages to include special purpose processing that is deemed necessary in order to be done locally. The CPU chosen for a specific IoT application must not only support the security features as explained earlier, but must also be implemented in a way so that it is scalable in performance to support higher clock frequencies. For certain applications, it is also beneficial for the CPU to support hardware multi-threading, as in CPUs such as the MIPS I-Class processors.
Wireless communication
Typical wireless IoT devices will be enabled by specific standards. The standards deployed will depend on (1) the security requirements needed, (2) the type of network topology to be supported (eg., IP, mesh), and (3) the data rates to be supported. The diagram below provides a classification of IoT network requirements based on sustained data rates. Since Wi-Fi is pervasively deployed today, most IoT applications will support Wi- Fi. Also, for LED lighting and applications that may span large geographic areas, ZigBee networks are used and may be present in IoT systems alongside Wi-Fi.
Aside from HD video streaming applications such as those used in home entertainment or security video monitoring, 802.11n and 1x1 would provide sufficient bandwidth. The 802.11 networks will use dual band 2.4 GHz and 5.5 GHz frequencies. For lower power and lower cost implementations, 802.11n can be supported by a single band 2.4 GHz radio. The lower frequency bands are more desirable since the RF transmission provides a greater range for a given power level output. By 2016, 802.11ah will become available for low data rate/low power IoT systems with Wi-Fi. This standard will be based on the 930 MHz frequency band.
Figure 5: IoT applications vs. data rate requirements
Cloud interface
In an IoT system, the provision of services by the cloud will depend on several conditions. Security is a concern for device-to-cloud data transactions. An IoT device will need to support data encryption to the cloud via TLS or HTTPS. The software stack in the IoT device will need to support these security components. In addition, cloud based communication can use more lightweight signalling such as COAP3 (RFC-7252) and MQTT4. Compared to HTTP, these lightweight signalling standards are desirable since they will (1) provide a reduced overhead for communicating to the cloud and (2) as the data communicated is reduced, data traffi c on the internet will be reduced compared to using HTTP.
In addition, the different standards bodies have emerged to support IoT are aiming to develop software stacks that can be used across platforms.
Thread
The Thread Group (
www.threadgroup.org) has emerged in the development of a software stack that focuses on networks that are using 802.15.4 wireless mesh networks. A key benefi t of a mesh network is that if any device on the network fails, the network can continue to connect and communicate to other devices on the network.
