When the internet became accessible to the public more than 20 years ago, it made possible a whole range of new businesses and ways of working. In doing so it disrupted traditional “bricks and mortar” business models. The internet of things (IoT) is set to go even further by bringing physical assets online. Even bricks and mortar themselves could be affected as sensors are embedded into buildings to monitor their condition.
By using distributed computational intelligence around the physical world, the IoT makes it possible to look again at traditional business models. Businesses can ask: what do consumers really need and what can we do to support that? We have already seen this transformation in action in the jet engines made for aircraft. The major suppliers were early adopters of the IoT model, using communications networks not just to support the servicing of their products but the way in which airlines buy them.
The model aligns the incentives of the airline and jet-engine maker by focusing on the most important parts of running air transportation profitably – reducing downtime on the ground to allow their aircraft to serve the maximum number of routes. Sensors in the engines provide real-time updates that are combined with more detailed data about condition obtained when the aircraft is on the ground at the airport gate. The resulting information provides the engine maker with up-to-date visibility to the condition of the engine, allowing them to schedule off-wing maintenance when it makes most sense according to the flight plans.
The jet-engine business model itself is designed to incentivize the engine maker to keep aircraft in the air as much as possible and so, rather than buying an engine, the airline is in effect leasing the ability to keep its fleet airborne. Sensors and worldwide communications provide the engine maker with the ability to deliver on the promises of its business model.
The same principles can be extended to numerous other markets. For example, carmakers can shift from their traditional product vendor role to one of being a provider of reliable transportation. Other suppliers to the automotive value chain can play a part. Instead of selling tires to drivers at irregular intervals, the manufacturers can use a leasing model that is enhanced through the use of sensors – some of which are already installed in tires.
By linking the tire pressure monitoring system to the IoT along with driving data, applications in the cloud can inform the driver of good times and locations to stop at a service station to top up the pressure and, if the driving data indicates intense usage, check on the tread depth and condition of the tires. When the wear approaches the point where the tires need changing, the driver can check in at a tire-changing location when it is convenient instead of waiting for an annual service. This approach provides the consumer with greater value and the tire manufacturer with greater predictability on revenue streams.
In the field of insurance, the transformation can be more dramatic. Instead of insurers using actuarial information to simply estimate risks when putting together policies, the providers can take a more active role in reducing risks and their overall costs – providing themselves and consumers with more value. For example, one of the biggest costs in home insurance is cleaning up and replacing items after the property has been flooded because of a burst pipe. The longer it takes to deal with the burst pipe, the greater the cost. So, unoccupied properties can lead to high cleanup costs.
If sensors in the home detect water in a way that indicates the beginnings of a flood, an automated valve can shut the water off at the mains and greatly reduce the potential for damage. Sensors can detect other problems so that the insurer can provide services to deal with them before they become costly. In this way, the role of the insurer changes to one of assurance.
There are a number of enabling technologies that make it possible for businesses to extract maximum leverage from the IoT. As shown in the examples above, sensors and communication are two critical technologies. But it is important to take into account the infrastructure that makes the overall system possible.
In most existing IoT-like applications, the role of the communications infrastructure is more akin to that of an intranet. The sensors have been deployed by the manufacturer and the network is often managed by them as well, although they may rent capacity on an existing communications infrastructure, such as cellular. The IoT will deliver maximum value by making it possible to use data and networks from multiple providers to create a single application.
For example, the water sensors may be installed by the owner; the automated valve by the water company. The key to coordinating their actions lies in the software developed by the insurer, which may run in a variety of locations. The core algorithms that work out whether water reading indicates a flood will often run in servers in the cloud. These servers may be owned by the server directly or leased from a provider such as Amazon Web Services or Microsoft’s Azure service.
To guarantee real-time response, some of the application may run in an IoT gateway that is much closer to the sensors and actuators. This gateway represents one of the biggest changes to computing architecture that needs to be made to extract the most value from the IoT.
At one level, an IoT gateway performs the same functions as the router in a home, office or industrial cell. It collects data from multiple sensor nodes, relays commands to actuators and feeds information to the cloud. The connections between the gateway and the various IoT nodes form part of the ‘fog’ layer, distinguishing them from the connections over the wider internet into the cloud.
One of the likely directions in gateway designs is to make them hosts for IoT applications. A virtualized architecture based around a hypervisor makes it possible to separate the core routing and network management functions from downloadable applications that may come from a variety of service providers and equipment vendors. The Prpl group has demonstrated the architecture and has developed a hypervisor that can support it, providing it in open-source form. This will make it easy for manufacturers to implement the core functions of an IoT gateway and for applications writers to create software that will run on them.
For the fog network, integrators and developers are faced with a number of choices that vary dramatically in terms of range, data rate and other capabilities. The wide-ranging nature of the IoT means there is no one-size-fits-all solution.
Consider the variety even within the nascent field of smart agriculture. Some will take place on relatively small brownfield sites, where the crops are grown in greenhouses. Although the greenhouse environment makes it relatively easy to control the irrigation of plants, the enclosed nature of this form of agriculture tends to lead to the rapid spread of disease.
Traditional field-based agriculture has a different set of challenges. Disease and pest infestations are problems but the key to efficient crop growth without wasting water is to monitor the effects of irrigation at the soil level. By monitoring moisture levels in the soil itself, sensors can feed applications that control highly directed irrigation. Only when the moisture level drops too far in a particular part of the field is irrigation activated. Other parts of the field are not watered in order to avoid over-irrigation. Such techniques are already being applied in dry areas, such as California, which has been afflicted with drought conditions in recent years.
In the greenhouse environment, soil data may be important. But, because it’s possible to recycle water, conservation is not as important. Instead, hydroponic growth media may be used, with a different type of sensor being used to monitor flow rates to maintain good nutrient distribution. To monitor diseases, unmanned aerial vehicles (UAVs) can be used to inspect the crops and identify those that need urgent treatment or removal to avoid infecting the rest of the crop.
The communications demands between the two forms of agriculture can be quite different. High-bandwidth communication is more important in the greenhouse environment to allow better recognition of disease symptoms by cloud- or gateway-based applications. However, the localized environment allows for the use of short-range, higher-bandwidth protocols such as Bluetooth or Wi-Fi. The open-air environment of the traditional farmer is less suitable for the range-limited fog networks but there are other options that can be deployed, such as LoRaWan or cellular.
Although it was developed primarily as a personal-area network for devices that communicate with mobile phones, the application space for Bluetooth has expanded dramatically through a series of protocol enhancements and is continuing to do so. One change being developed by the Bluetooth Special Interest Group (SIG) will extend the normal transmit range of 100 meters by as much as four times. The range extension reduces the bitrate but the protocol is adaptive so that closer nodes can use higher transmit speeds. Closely spaced devices will see an increased data rate to 2 Mbit/s as the result of the change.
Another change that brings Bluetooth into line with other IoT-oriented networks such as 6LowPAN and Zigbee is the addition of support for mesh networking. The IEEE 802.15.4 specification for wireless communication on which 6LowPAN and Zigbee are based was designed to support mesh networking, which can be used to extend the effective range and resilience of such fog network protocols.
A mesh network makes it possible for packets to travel a large distance using short-range communication. This is achieved by making it possible for a packet to use short hops between nodes that lie between the source and destination. The mesh technique improves resilience because, if one node fails, there is often another that can be used to relay data. The mesh technique makes it possible to place sensors in locations that are difficult to access – such as in the roof of the greenhouse – even though they are out of direct range of the IoT gateway node.
Revisions to Bluetooth also take into account the heterogeneous nature of the IoT by making it possible for sensor nodes that support the protocol to interact with 6LowPAN devices. Although introduced more recently than Zigbee, 6LowPAN is likely to become more prevalent in IoT installations thanks to its adoption by the Thread protocol group. Thread adds features such as authentication and encryption to 6LowPAN to improve overall security.
Protocols such as 6LowPAN operate not just in the 2.4 GHz band that Bluetooth and Wi-Fi employ but also in the license-exempt sub-gigahertz bands such as 868 MHz. This lower frequency range supports comparatively low bitrates because of the use of narrowband transmissions. However, range tends to increase with little impact on power consumption. As a result, operating in the sub-gigahertz suits the deployment of wireless sensor nodes in situations where mesh networking is less suitable but longer-distance transmission is required. An example is of sensors deployed along stretches of road, with gateways spaced at regular intervals to convey messages to and from the cloud.
By moving to a protocol such as LoRaWan or SIGFOX, it is possible for a single gateway to stay in touch with a large number of sensors that can be scattered across the countryside at a range of a kilometer or more.
Figure 2: Semtech SX1272/73 – 860 MHz to 1020 MHz low-power long range transceiver – block diagram.
The LoRaWan protocol was developed by Semtech, which together with Microchip Technology and STMicroelectronics, supplies compatible transceivers. The ready availability of silicon provides a choice for IoT application developers and integrators over the nature of the fog network. They can deploy their own gateway hardware or use public networks – both public and private. Not only are commercial LoRaWan networks now being deployed, but volunteers are deploying their own free offerings. One example is the city of Amsterdam in The Netherlands, which is covered almost entirely by just eleven gateways deployed by members of The Things Network organization.
Most transceivers developed for 868 MHz communication and similar bands can use the SIGFOX protocol. This is intended primarily for unidirectional, low-data rate communication to gateway nodes installed by the company that developed the protocol.
Another option for longer-distance communication is to use 3G and 4G cellular. The 3GPP standardization group has already developed a version of the 4G LTE protocol for IoT applications and is working on another – Narrowband-IoT – that will reduce complexity and power consumption.
As a result of the developments in communications infrastructure, IoT devices will find multiple ways to connect to the fog and onto the cloud. The key will be to link these disparate systems together and this is where standards for software and data will be key.
Protocols such as the Constrained Applications Protocol (CoAP) make it possible to extend the benefit of internet standards such as the HyperText Transfer Protocol (HTTP) to sensor nodes though the fog network. CoAP provides access to HTTP in a form that fits well on microcontrollers with restricted memory and processing resources. CoAP supports the same REpresentational State Transfer (REST) programming model that has become standard for developing web-based applications. However, it employs a binary rather than textual format that is more compact than traditional HTTP, suiting it to low-data rate connections.
Figure 3: MQTT quality of service (QoS) capability (Source MQTT – A practical protocol for the Internet of Things : IBM MessageSight Solutions)
Other protocols, such as MQ Telemetry Transport (MQTT), support an alternative application architecture. MQTT supports a publish-subscribe model in contrast to CoAP’s client-server architecture. The publish-subscribe architecture is one that suits the IoT because it provides data from individual sensor nodes from different applications without demanding direct access to the nodes themselves for each one. This reduces demand on the fog network and allows scalability. CoAP and MQTT are not mutually exclusive. Gateways may collect data using CoAP and then provide access to other applications using MQTT or other protocols that may emerge.
The key is that the architecture already being deployed will support interoperability and, thanks to this, will deliver on one of the key promises of the IoT – that innovative, profitable applications can be developed quickly without demanding infrastructural investment each time.
For example, having deployed UAVs and other sensors to monitor crops, farmers could adjust harvesting decisions based on market data or to the transport situation. A cloud-based application that tracks demand for a given foodstuff may lead to the farming systems speeding up harvesting to cope with the increased need. Another application may operate a just-in-time harvesting system to ensure maximum freshness. Only when a truck is in range of the farm does harvesting for that day begin – with the crop guaranteed ready when it arrives thanks to the use of predictive software that uses data from the UAVs to determine how much of the crop is ready for picking.
There is no need to add sensors to the trucks to determine their position and likely arrival times – they are already in place. The only requirement is that the data is available to the application, which can be arranged through protocols such as CoAP and MQTT.
The IoT encompasses communications, sensor technology, cloud-based intelligence and open software protocols. The IoT promises to deliver a new world of capabilities driven by business models that would be unthinkable without the combination of those technologies.