Building the Internet of Things


Architectural considerations



Download 258.06 Kb.
Page4/13
Date10.06.2017
Size258.06 Kb.
#20222
1   2   3   4   5   6   7   8   9   ...   13

Architectural considerations


Designing any system reveals concerns that transcend the individual components of the system. In this section, we discuss various considerations and architectural approaches that we have encountered while helping our customers design solutions in the realm of predictive maintenance.


Figure . An overview of network layers and mapped logical protocols
Connectivity

A key technical enabler of the Internet of Things (IoT) is ubiquitous connectivity. Let’s first look at the Open Systems Interconnection (OSI) model.25 Even though the Internet model uses a simplified abstraction, the models in the previous figure and the associated well-known logical protocols are comparable.

Application-layer protocols are not concerned with the lower-level layers in the stack other than being aware of the key attributes of those layers, such as IP addresses and ports. The right side of the figure shows the logical protocol breakdown transposed over the OSI model and the TCP/IP model.

Interaction patterns


Special-purpose devices differ not only in the depth of their relationship with back-end services, but in the interaction patterns of these services when compared to information-centric devices because of their role as peripherals. They are not the origin of command-and-control gestures; instead, they typically contribute information to decisions, and receive commands as a result of decisions. The decision-maker does not interface with them locally, and the device acts as an immediate proxy; the decision-maker is remotely connected and might be a machine. We usually classify interaction patterns for special-purpose devices into the four categories indicated in the following figure.





Figure . Device communication patterns

Telemetry is information flowing in one direction that a device volunteers to a collecting service, either on a schedule or based on circumstances. That information represents the current or temporally aggregated state of the device or the state of its environment, such as readings from sensors that are associated with it.

Notifications are one-way, service-initiated messages that inform a device or a group of devices about some environmental state that they would otherwise not be aware of. For example, wind parks can be fed weather forecast information, and cities can broadcast information about air pollution, suggesting that fossil-fueled systems either throttle CO2 output or vehicles may want to show weather or news alerts or text messages to drivers.

Inquiries occur when a device solicits information about the state of the world beyond its own reach based on its current needs; an inquiry can be a singular request, but it might also ask a service to supply ongoing updates about a particular information scope. For example, a vehicle might supply a set of geo-coordinates for a route, and then ask for continuous traffic alert updates about a particular route until it arrives at the destination.

Commands are service-initiated instructions sent to either a single device or a group of devices. Commands can tell a device to provide information about its state, or to change the state of the device, including activities with effects on the physical world. That includes, for instance, sending a command from a smartphone app to unlock the doors of your vehicle, whereby the command first flows to an intermediating service and then from there is routed to the vehicle's onboard control system.

Telemetry and inquiries are device-initiated, and their counterparts, commands and notifications, are service-initiated. This means that there must be a network path for messages to flow from the service to the device, which bubbles up a set of important technical questions. How do you:

Address a device on a network when it is roaming or if it is power-constrained and duty cycling the radio to conserve energy?26, 27

Send commands or notifications with acceptable latency for a given scenario?

Ensure that the device only accepts legitimate commands and trustworthy notifications?

Ensure that the device is not easily susceptible to denial-of-service (DoS) attacks that render it inoperable?

Perform this with millions of devices attached to a telemetry-and-control system?

Connectivity pathways


Figure . Communication styles

In the architectures that we have worked on, there are four common connectivity pathways:

Peer-to-peer: A method of communication between devices of a system without the use of a centralized administrative system. The peers in the network can exchange information and communicate only the necessary information back to the system. Besides providing the ability to create specific case and self-organizing networks of devices, this method of communication enhances the capabilities of the system—nodes can work together to become smarter. The disadvantages for smart systems in this type of inter-device communication is the lack of centralized control, and the impact it has on the security of the system. It also requires a higher level of logic (“intelligence”) for some or all peers to use peer-to-peer communication.

Device-to-service: A device that communicates to a supporting back-end in the system, often called the service.

Service-to-device: A service that communicates to a device; the opposite of the previous connectivity pathway.

Service-to-service. Communication between two separate systems, exchanging data to augment knowledge in the system.

From the work that the authors have done, we have learned that for predictive maintenance implementations, a bi-directional communication pattern is key to a manageable solution. The reason for this bi-directional communication ability is to ensure that the system can tell devices to change the way that they capture telemetry, for example, the rate at which it is captured or the fidelity of the readings. We have not come across a case where the requirements were simply to capture data from devices in a one-way communication flow. Because most systems will need a method of telling devices to capture data at differing frequency or with increased fidelity, we consider a one-way communication flow a subset of the more common pattern.


Connectivity network types


The connectivity type demonstrates how a device and service communicate. The type of connectivity chosen for a system has broad implications to its architecture. We commonly see three types of connectivity with different implementations and implications:



Figure . The increasing geographical reach of varying network types

Wide area network (WAN). A good example of a WAN is a cellular network. This network type is a wireless network that is distributed over land areas called cells, each served by at least one fixed-location transceiver, known as a cell site or base station. In a cellular network, each cell uses a different set of frequencies from neighboring cells, to avoid interference and provide guaranteed bandwidth within each cell. When joined together, these cells provide radio coverage over a wide geographic area. This enables a large number of portable transceivers (for example, mobile phones, pagers, and so on.) to communicate with each other and with fixed transceivers and telephones anywhere in the network, via base stations, even if some of the transceivers are moving through more than one cell during transmission.28 The most common cellular network is the type that cellphones use. Cellphones and many integrated components for devices support network technologies, such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS) and as an evolution technology, Long Term Evolution (LTE), as well as others. As with many technologies in the ecosystem of IoT, there is still a large opportunity for optimization of resource usage and cost for these technologies.29

Local area network/wireless local area network (LAN/WLAN). A LAN uses networking technology to connect computers and devices in a limited area, such as a home, school, computer laboratory, or office building. Unlike WANs, LANs cover a limited geographic area, and do not include leased telecommunication lines. Ethernet over twisted-pair cables and Wi-Fi are the two most common technologies used in LANs today. Though Ethernet 10/100Base-T structured cabling is the basis for many commercial LANs, fiber-optic cabling is increasingly used in commercial applications. Cabling is often inconvenient or impossible to use. With the increasing capability of WLAN devices that use radio waves based on the Wi-Fi industry standard, WLAN is now the standard for wireless connectivity. Wi-Fi has a maximum range of about 250 meters outdoors.30 The connection between different LANs, often times owned by a single entity and extending its range inside a metropolitan area, is referred to as a Metropolitan Area Network (MAN).

Personal area network (PAN). One of the most interesting developments in networking is the use of a PAN to transmit data among devices, such as computers, telephones, and personal digital assistants. PANs can be used to communicate among the devices themselves (intrapersonal communication), or to connect to the Internet. Until recently, PAN devices could not communicate over IP, so they needed a bridge to translate between their proprietary protocol and IP. With the introduction and adoption of IPv6 over low-power wireless personal area networks (6LoWPAN), these devices, which use developing standards, such as Bluetooth LE,31 will communicate via IP directly and take a more active role in IoT.

A wireless personal area network (WPAN) is a PAN carried over wireless network technologies such as the following:



Bluetooth and Bluetooth Low Energy (LE): A wireless technology standard for exchanging data over short distances (using short-wavelength UHF radio waves in the ISM band from 2.4 to 2.485 GHz from fixed and mobile devices, and building personal area networks (PANs). Invented by telecom Ericsson in 1994, it was originally conceived as a wireless alternative to RS-232 data cables. It can connect several devices, overcoming problems of synchronization. Bluetooth LE32 uses 5 to 10 times less power than older Bluetooth,33 making it a good fit for certain IoT applications.

Z-Wave: A wireless communications protocol designed for home automation to remotely control applications in residential and light commercial environments. Z-Wave is licensed through the Z-Wave alliance.34

ZigBee(-IP): Built on IEEE 802.15.4, the physical layer for low-rate WPANs, ZigBee35 is often used to transmit low-powered periodic or intermittent data or a single signal from a sensor or input device, wireless light switch, electrical meter with in-home-display, traffic management system, or other consumer and industrial equipment that requires short-range wireless data transfer at relatively low rates. The new ZigBee IP,36 based on 6LoWPAN, lets ZigBee devices communicate without a bridge.

For an interesting comparison of power consumption between ZigBee and Bluetooth LE, see “Power Consumption Analysis of Bluetooth Low Energy, ZigBee and ANT Sensor Nodes in a Cyclic Sleep Scenario”.37 Here are some of our observations from this study:

BLE would appear to have an intrinsic disadvantage in a cyclic sleep scenario because the frequency hopping scheme it uses inherently takes longer to connect compare to the fixed RF channel used in ZigBee and ANT.

BLE took longer for one connection (1.15 s), than ANT (0.93 s) and ZigBee (0.25 s). This is because the BLE node was able to sleep for longer between individual RF packets, improving its duty cycle significantly.



We found that BLE achieved the lowest power consumption, followed by ZigBee and ANT. The parameters that dominated power consumption were not the active or sleep currents but rather the time required to reconnect after a sleep cycle and to what extent the RF module slept between individual RF packets.


Download 258.06 Kb.

Share with your friends:
1   2   3   4   5   6   7   8   9   ...   13



The database is protected by copyright ©ininet.org 2024
send message
    Main page
information contained
current view
issues discussed as
authors would like
express written permission