Understanding the IoT cloud and how it will change things

When first proposed, a “thing” on the newly named internet of things (IoT) was imagined as something that could be counted and these existed in relatively simple applications, now IoT is expanding into machine-to-machine (M2M) communication and applications such as manufacturing and power utilities, writes Martha Zemede of Keysight Technologies.

While automation is already important in manufacturing, IoT and the so-called Industrial Internet are enabling greater automation while also increasing flexibility and efficiency in manufacturing processes. Examples include new tools that support remote and predictive maintenance, thereby reducing costs and otherwise enhancing competitiveness.

These trends are influencing mammoth projections about the scale of IoT implementations: estimates range from 15 billion to 50 billion connected things by 2020, spanning all sectors. Further predictions about new, disruptive IoT-related services suggest potential revenues many times greater than those derived from IoT hardware and network provision.

Current visions for the IoT space have taken on a broader perspective, with more emphasis on post-processing of accumulated data. This has led to the need to connect individual applications to cloud storage and enable remote control via the internet. The scale of the required network is potentially mind-boggling—and making this scenario a reality depends on absolutely reliable connectivity, designed in from the start and well tested all along the product lifecycle.

Defining the nature of “things”

Today, a thing can be any natural or man-made object, fixed or mobile, that can be given the ability to transfer data over a network. Examples include an intruder alarm in a cellular base station and smart collars that make life easier for livestock farmers or pet owners.

The latest areas of focus include personal health and fitness, with the emergence of wearable technology that works in conjunction with a smartphone app. A common healthcare example is remote monitoring of a patient’s condition as they go about their daily routine, away from a clinic or hospital. Another is mitigation of injuries suffered during a traffic accident: an involved vehicle not only summons emergency assistance but also reports its location, the number of occupants and the severity of their injuries.

While some devices will use wired connections—USB, Ethernet, fiber—a majority of IoT things will rely on some kind of wireless technology. This will range from near-field communication (NFC) for mobile payments, to geosynchronous satellites for unattended remote weather stations, and everything in between: Bluetooth, wireless LAN (WLAN), cellular, ZigBee, point-to-point radio, and more.

The network will need to cope with all kinds of unique devices with different communication requirements. At one end will be simple wireless devices such as battery-powered sensors and actuators that will transmit very little data while operating unattended for several years. At the other end of the spectrum—figuratively and figuratively—will be high-bandwidth, mission-critical services and devices such as autonomous cars that require constant, reliable and super-secure connections.

Accessing gateways to the cloud

Figure 1 illustrates many of the possible paths that can be used to connect a device to the cloud. In most cases there’s no direct connection between the thing, the cloud or the remote application. One example might be an apartment complex equipped with a network of ZigBee-based fire-detection and entry sensors: data is compiled and stored in a local ADSL intelligent gateway that periodically reports to a security company. The gateway would be programmed to immediately raise an alarm when the system detects an abnormal sensor response.

In general, a gateway is responsible for protocol and interoperation of individual devices, the app and the cloud. Ultra low-power wireless technologies such as Bluetooth and ZigBee have proven instrumental in driving sensor and node implementations. These may use Wi-Fi or cellular connectivity as a backbone for transferring collected data to the cloud.

While cellular and Wi-Fi are quite common, some commercial and industrial applications use other wireless access networks. Emerging low-power wide-area networks (LPWAN) such as SIGFOX, LoRa and Telensa are relatively new standards optimized for IoT/M2M communication.

Unlike currently deployed cellular networks, LPWAN is optimized for very low data rates, long battery life, low duty cycle, and the ability to coexist in shared spectrum using unlicensed ISM bands. As an example use case, cities installing connected street lamps can use this type of approach because lighting systems have an expected service life measured in decades—far longer than the lifetime of typical cellular standards.

Of course, the cellular standards bodies are not standing still. 3GPP has been working towards support for IoT and machine-type communication (MTC). Release 12 of the standard (March 2015) added an MTC extension to LTE-Advanced, defining a new device category called Category-0 or Cat-0. Significant optimization of Cat-0 MTC is planned for Release 13 (March 2016), targeting lower-cost, lower-complexity devices with reduced transmission power, ultra-long battery life and extended-coverage operation. Looking for even better link budget, cost and power consumption than available with LTE-MTC (Cat-0), the GSM EDGE Radio Access Network (GERAN) groups are proposing two strands for what it’s calling cellular IoT (CIoT). One is based on an evolution of GSM and the other uses clean-slate radio access technologies aimed at low-end IoT applications.

Mapping technologies versus operating range

Figure 1 shows a partial list of the technologies being proposed for IoT, grouped by operating range. There is no firm definition of the boundaries of WPAN, WLAN, WNAN and WWAN.

keysight 2

Figure 1. Expected operating range has a direct relation to the available choices of connection technologies.

Many formats are available for short-range connections between devices and gateways. To facilitate future development, standards are quickly forming and evolving as new devices become connected. Currently, there are more than 60 legacy and new RF formats in use for M2M and IoT-related applications. Some, such as Bluetooth, 802.11ac WLAN and cellular, are already widely used. Others, such as ZigBee and Thread, are less well known but have carved out specific niches in the market.

To accelerate their products to market, some companies developed proprietary solutions that were relatively easy to create because they had low data rates, low-power transmissions and minimal interoperability requirements. This approach is likely to fall out of favor because the globalization of markets is driving device communication away from proprietary designs and towards standardized solutions.

Accelerating the creation of new things

As-yet unknown applications that require customized gateway capabilities are likely to arise from the expansion of IoT into areas not currently addressed by connected devices.

While the required gateways will increasingly use standardized interfaces to devices and the cloud, their required level of intelligence will depend on specific application needs. Designers and manufacturers of custom gateway hardware must be prepared to fulfill the needs of both niche and mainstream service providers addressing these new business opportunities.

One key to rapid deployment of custom gateways is the availability of solutions for design and test that are flexible enough to meet the needs of engineers across R&D, manufacturing and deployment. One key factor is shared “measurement science” that runs through design tools, standalone test equipment, modular measurement hardware, and handheld instruments. This enables a common understanding of the crucial measurements that define and verify device performance, and this creates a feedback path that spans the entire product lifecycle.

It works as follows. Early in development, a new product can be simulated in a design environment that includes virtual measurement tools: these can be attached to nodes in the simulation, providing realistic views of expected performance. As the design moves from simulation to reality, physical device modules can be substituted into the simulation: real measurements replace their virtual simulations, allowing developers to close the feedback loop by easily comparing actual and simulated performance.

When prototypes are available, continuity comes from lab-grade test equipment and built-in measurement applications that provide one-button, standards-based measurements. For custom gateway products, pre-qualification testing for each supported format provides greater assurance that the product will meet the relevant specifications.

MarthaThis may not be the only requirement for certification. Similar to mobile carriers that maintain strict compliance requirements, many industry alliances insist on broad interoperability testing before awarding their certification mark. Standards-based measurement solutions give designers greater confidence that their custom gateway will pass the required tests quickly and efficiently.

Looking ahead

There are many visions of a near future populated by billions of connected things. Most visionaries paint a picture that promises amazing benefits to consumers, businesses and governments.

For designers and developers, making these scenarios a reality depends on the ability to create absolutely reliable connections between devices, gateways and the cloud. One way to get there faster is to adopt a design-and-test methodology that includes its own reliable connection—based on shared measurement science—that spans the entire product lifecycle. The ultimate result is greater confidence in the performance and compliance of new devices and gateways that will enable the future benefits of IoT, M2M, and other visionary scenarios.

Martha Zemede works for Keysight Technologies.


Leave a Reply

Your email address will not be published. Required fields are marked *

*