Building the IoT – Connectivity and Security

25 Jul

Short-range wireless networking, for instance, is another major IoT building block that needs work. It is used in local networks, such as:

and more.With the latest versions of Bluetooth and Zigbee, both protocols can now transport an IP packet, allowing, as IDC represents it, a uniquely identifiable endpoint. A gateway/hub/concentrator is still required to move from the short-range wireless domain to the internet domain. For example, with Bluetooth, a smartphone or tablet can be this gateway.

The main R&D efforts for local area networking are focused on radio hardware and power consumption so that we can avoid needing a power cable or batteries for wireless devices, network topologies and software stacks. 6LoWPAN and its latest evolution under Google’s direction, Thread, are pushing the limits in this area. Because consumers have become accustomed to regularly changing their technology, such as updating their computers and smartphones every few years, the consumer market is a good laboratory for this development.

There is also a need for long-range wireless networking in the IoT to mature. Connectivity for things relies on existing IP networks. For mobile IoT devices and difficult-to-reach areas, IP networking is mainly achieved via cellular systems. However, there are multiple locations where there is no cellular coverage. Further, although cellular is effective, it becomes too expensive as the number of end-devices starts reaching a large number. A user can pay for a single data plan (the use of cellular modems in cars to provide Wi-Fi, for example), but that cost rapidly becomes prohibitive when operating a large fleet.

For end-devices without a stable power supply—such as in farming applications or pipeline monitoring and control—the use of cellular is also not a good option. A cellular modem is fairly power-hungry.

Accordingly, we are beginning to see new contenders for IoT device traffic in long-range wireless connections. A new class of wireless, called low-power wide-area networks (LPWAN), has begun to emerge. Whereas previously you could choose low power with limited distance (802.15.4), or greater distance with high power, LPWAN provide a good compromise: battery-powered operation with distances up to 30KM.

There are a number of competing technologies for LPWAN, but two approaches are of particular significance are LoRa and SIGFOX.

LoRa provides an open specification for the protocol, and most importantly, an open business model. The latter means that anyone can build a LoRa network—from an individual or a private company to a network operator.

SIGFOX is an ultra-narrowband technology. It requires an inexpensive endpoint radio and a more sophisticated base station to manage the network. Telecommunication operators usually carry the largest amount of data; usually high frequencies (such as 5G), whereas SIGFOX intends to do the opposite by using the lower frequencies. SIGFOX advertises that its messages can travel up to 1,000 kilometers (620 miles), and each base station can handle up to 1 million objects, consuming 1/1000th the energy of a standard cellular system. SIGFOX communication tends to be better if it’s headed up from the endpoint to the base station, because the receive sensitivity on the endpoint is not as good as the expensive base station. It has bidirectional functionality, but its capacity going from the base station back to the endpoint is constrained, and you’ll have less link budget going down than going up.

SIGFOX and LoRa have been competitors in the LPWAN space for several years. Yet even with different business models and technologies, SIGFOX and LoRa have the same end-goal: to be adopted for IoT deployments over both city and nationwide LPWAN. For the IoT, LPWAN solves the connectivity problem for simple coverage of complete buildings, campuses or cities without the need for complex mesh or densely populated star networks.

The advantage of LPWAN is well-understood by the cellular operators; so well, in fact, that Nokia, Ericsson and Intel are collaborating on narrowband-LTE (NB-LTE). They argue it is the best path forward for using LTE to power IoT devices. NB-LTE represents an optimized variant of LTE. According to them, it is well-suited for the IoT market segment because it is cheap to deploy, easy to use and delivers strong power efficiency. The three partners face an array of competing interests supporting alternative technologies. Those include Huawei and other companies supporting the existing narrowband cellular IoT proposal.

These technologies are part of the solution to solve some of the cloud-centric network challenges. It is happening, but we can’t say this is mainstream technology today.

Internet concerns

Beyond the issue of wireless connectivity to the internet lie questions about the internet itself. There is no doubt that IoT devices use the Internet Protocol (IP). The IPSO Alliance was founded in 2008 to promote IP adoption. Last year, the Alliance publicly declared that the use of IP in IoT devices was now well understood by all industries. The question now is, “How to best use IP?”

For example, is the current IP networking topology and hierarchy the right one to meet IoT requirements? When we start thinking of using gateways/hubs/concentrators in a network, it also raises the question of network equipment usage and data processing locations. Does it make sense to take the data from the end-points and send it all the way to a back-end system (cloud), or would some local processing offer a better system design?

Global-industry thinking right now is that distributed processing is a better solution, but the internet was not built that way. The predicted sheer breadth and scale of IoT systems requires collaboration at a number of levels, including hardware, software across edge and cloud, plus the protocols and data model standards that enable all of the “things” to communicate and interoperate. The world networking experts know that the current infrastructure made up of constrained devices and networks simply can’t keep up with the volume of data traffic created by IoT devices, nor can it meet the low-latency response times demanded by some systems. Given the predicted IoT growth, this problem will only get worse.

In his article, The IoT Needs Fog Computing, Angelo Corsaro, chief technology officer ofPrismtech, makes many good points about why the internet as we know it today is not adequate. He states that it must change from cloud to fog to support the new IoT networking, data storage and data processing requirements.

The main challenges of the existing cloud-centric network for broad IoT application are:

  • Connectivity (one connection for each device)
  • Bandwidth (high number of devices will exceed number of humans communicating)
  • Latency (the reaction time must be compatible with the dynamics of the physical entity or process with which the application interacts)
  • Cost (for an system owner, the cost of each connection multiplied by the number of devices can sour the ROI on a system)

These issues led to the creation of the OpenFog Consortium (OFC). OFC was created to define a composability architecture and approach to fog/edge/distributed computing, including creating a reference design that delivers interoperability close to the end-devices. OFC’s efforts will define an architecture of distributed computing, network, storage, control, and resources that will support intelligence at the edge of IoT, including autonomous and self-aware machines, things, devices, and smart objects. OFC is one more example that an important building block to achieve a scalable IoT is under development. This supports Gartner’s belief that the IoT will take five to 10 years to achieve mainstream adoption.

Yet the majority of media coverage about the IoT is still very cloud-centric, sharing the IT viewpoint. In my opinion, IT-driven cloud initiatives make one significant mistake. For many of the IoT building blocks, IT is trying to push its technologies to the other end of the spectrum—the devices. Applying IT know-how to embedded devices requires more hardware and software, which currently inflates the cost of IoT devices. For the IoT to become a reality, the edge device unit cost needs to be a lot lower than what we can achieve today. If we try to apply IT technologies and processes to OT devices, we are missing the point.

IT assumes large processors with lots of storage and memory. The programming languages and other software technologies of IT rely on the availability of these resources. Applying the IT cost infrastructure to OT devices is not the right approach. More development is required not only in hardware, but in system management. Managing a network of thousands or millions of computing devices is a significant challenge.

Securing the IoT

The existing internet architecture compounds another impediment to IoT growth: security. Not a single day goes by that I don’t read an article about IoT security requirements. The industry is still analyzing what it means. We understand IT security, but IT is just a part of the IoT. The IoT brings new challenges, especially in terms of networking architecture and device variety.

For example, recent studies are demonstrating that device-to-device interaction complexity doesn’t scale when we include security. With a highly diverse vendor community, it is clear the IoT requires interoperability. We also understand that device trust, which includes device authentication and attestation, is essential to securing the IoT. But device manufacturer-issued attestation keys compromise user privacy. Proprietary solutions may exist for third-party attestation, but again, they do not scale. Security in an IoT system must start with the end-device. The device must have an immutable identity.

Unfortunately, today this situation does not have an answer. Some chip vendors do have solutions for it. However, they are proprietary solutions, which means the software running on the device must be customized for each silicon vendor.

Security in a closed proprietary system is achievable, especially as the attack surface is smaller. As soon as we open the systems to public networking technologies, however, and are looking at the exponential gain of data correlation from multiple sources, security becomes a combinatory problem that will not soon be solved. With semantic interoperability and application layer protocol interoperability required to exchange data between systems, translation gateways introduce trusted third parties and new/different data model/serialization formats that further complicate the combined systems’ complexity.

The IT realm has had the benefit of running on Intel or similar architectures, and having Windows or Linux as the main operating system. In the embedded realm there is no such thing as a common architecture (other than the core—which, most of the time, is ARM—but the peripherals are all different, even within the same silicon vendor product portfolio). There are also a number of real-time operating systems (RTOS) for the microcontrollers and microprocessors used in embedded systems, from open-source ones to commercial RTOS. To lower embedded systems cost and achieve economies of scale, the industry will need to standardize the hardware and software used. Otherwise, development and production costs of the “things” will remain high, and jeopardize reaching the predicted billions of devices.

Fortunately, the technology community has identified several IoT design patterns. A design pattern is a general reusable solution to a commonly occurring problem. While not a finished design that can be transformed directly into hardware or code, a design pattern is a description or template for how to solve a problem that can be used in many different situations.

These IoT design patterns are described in IETF RFC 7452 and in a recent Internet Society IoT white paper. In general, we recognize five classes of patterns:

  • Device-to-Device
  • Device-to-Cloud
  • Gateway
  • Back-end Data Portability
  • IP-based Device-to-Device

Security solutions for each of these design patterns are under development. But considerable work remains.

Finally, all of this work leads to data privacy, which, unfortunately, is not only a technical question, but also a legal one. Who owns the data, and what can the owner do with it? Can it be sold? Can it be made public?

As you can see, there are years of work ahead of us before we can provide solutions to these security questions. But the questions are being asked and, according to the saying, asking the question is already 50% of the answer!

Conclusion

My goal here is not to discourage anyone from developing and deploying an IoT system—quite the contrary, in fact. The building blocks to develop IoT systems exist. These blocks may be too expensive, too bulky, may not achieve an acceptable performance level, and may not be secured, but they exist.

Our position today is similar to that at the beginning of the automobile era. The first cars did not move that fast, and had myriad security issues! A century later, we are contemplating the advent of the self-driving car. For IoT, it will not take a century. As noted before, Gartner believes IoT will take five to ten years to reach mainstream adoption. I agree, and I am personally contributing and putting in the effort to develop some of the parts required to achieve this goal.

Many questions remain. About 10 years ago, the industry was asking if the IP was the right networking technology to use. Today it is clear. IP is a must. The question now is, “How do we use it”? Another question we begin to hear frequently is, “What is the RoI (return on investment) of the IoT”? What are the costs and revenue (or cost savings) that such technology can bring? Such questions will need solid answers before the IoT can really take off.

Challenges also abound. When designing your system, you may find limitations in the sensors/actuators, processors, networking technologies, storage, data processing, and analytics that your design needs. The IoT is not possible without software, and where there is software, there are bug fixes and feature enhancements. To achieve software upgradability, the systems need to be designed to allow for this functionality. The system hardware and operation costs may be higher to attain planned system life.

All that said, it is possible to develop and deploy an IoT system today. And as new technologies are introduced, more and more system concepts can have a positive RoI. Good examples of such systems include fleet management and many consumer initiatives. The IoT is composed of many moving parts, many of which have current major R&D programs. In the coming years, we will see great improvements in many sectors.

The real challenge for the IoT to materialize, then, is not technologies. They exist. The challenge is for their combined costs and performance to reach the level needed to enable the deployment of the forecasted billions of IoT devices.

Source: http://www.edn.com/electronics-blogs/eye-on-iot-/4442411/Building-the-IoT—Connectivity-and-Security

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: