IoT connectivity solutions: Media access control layer and network topology

161-Datalink-MAC

Media access control layer and network topology

For IoT applications, the main characteristics of the media access layer control (MAC) that need to be considered are multiple access, synchronization, and network topology.

Multiple Access. Looking back at decades of successful cellular system deployment, one can safely conclude that TDMA is a good fit for the IoT. TDMA is suited for low-power operation with a decent number of devices, as it allows for optimal scheduling of inactive periods. Hence, TDMA is selected for multiple access in the MAC layer.

Synchronization. In IoT applications, there are potentially a very large number of power-sensitive devices with moderate throughput requirements. In such a configuration, it is essential to maintain a reasonably consistent time base across the entire network and potentially across different networks. Given that throughput is not the most critical requirement, it is suitable to follow a beacon-enabled approach, with a flexible beacon period to accommodate different types of services.

Network topology. Mobile networks using a cellular topology have efficiently been servicing a large number of devices with a high level of security and reliability, e.g., 5,000+ per base station for LTE in urban areas. This typology is based on a star topology in each cell, while the cells are connected in a hierarchical tree in the network backhaul. This approach is regarded suitable for the IoT and is therefore selected.

The network layer and interface to applications

The network layer (NWK) and the interface to applications are less fundamental as far as power-efficiency and reliability is concerned. In addition, there is more variation in the field of IoT applications. Nevertheless, it is widely acknowledged that IoT applications need to support the Internet Protocol (IP), whether it is IPv4 or IPv6. In addition, the User Datagram Protocol (UDP) and Constrained Application Protocol (CoAP) could provide the relevant trade-off between flexibility and implementation-complexity on resource-constrained devices.

Furthermore, the IoT will represent an immense security challenge, and it is likely that state-of-the-art security features will become necessary. As of today, we can assume 128 bits Advanced Encryption Standard (AES) for encryption and Diffie-Hellman (DH), or the Elliptic Curve Diffie-Hellman (ECDH) variants, can become the baseline for securing communication.

Internet of Things Wireless Connectivity Option Analysis: Pros and Cons of Bluetooth Classic, Bluetooth Low Energy, and CSRmesh

Nordic-Semiconductor-launches-the-Blue-nRF8002-a-low-cost-ultra-low-power-uniquely-easy-to-design-in-single-chip-solution-for-Bluetooth-Smart-tags-and-accessories

Analysis of the major Bluetooth technologies, including Bluetooth Classic, Bluetooth Low Energy, and CSRmesh as solution for the last 100m of IoT connectivity.

Bluetooth Classic

Bluetooth Classic, also standardized as IEEE 802.15.1 in 2002 and revised in 2005 (although this standard is not maintained anymore), was invented in 1994 as a replacement for RS-232. Bluetooth Classic operates in the 2.4 GHz band and is limited to a small number of eight devices. Because of the following reasons, Bluetooth Classic is not a suitable protocol for IoT applications:

  • Bluetooth Classic was designed to provide low-latency wireless peripherals and has evolved to provide high data rates. This is achieved at the expense of power consumption.
  • The physical layer (PHY) of Bluetooth Classic only supports long packets (up to 2745 bits of payload) with mandatory channel encoding. This enables higher throughput, however, this is not suitable for resource-constrained devices.
  • The protocol stack of Bluetooth Classic has grown in complexity and can typically be 128 kB of code size, which is not satisfactory for IoT embedded devices.
  • Bluetooth Classic’s loose specification on the modulation index range does not make it easy to improve the receiver performance in the future. Consequently, Bluetooth Classic has poor coverage, typically less than 10 m.
  • With a 3-bit address for piconet space, Bluetooth Classic is limited to having a maximum size of 8 connected devices, which is obviously insufficient for IoT applications.

Bluetooth Low Energy (BLE)

BLE also known as Bluetooth v4.0 or Bluetooth Smart originated from Nokia’s WiBree. Contrary to belief, BLE is actually not compatible with Bluetooth Classic since the physical layer (PHY) has been re-designed. BLE is using a fixed data rate of 1 Mbps and GMSK modulation. BLE uses short packets, and is suitable for low-latency proximity communication. Unfortunately, BLE has the following issues that make it less suitable for IoT applications:

  • BLE is operating in the crowded 2.4 GHz frequency band, along with Bluetooth Classic, Wi-Fi, ZigBee, and IEEE 802.15.4. This spectrum crowding will pose a severe reliability challenge to all 2.4 GHz devices, and the problem will only get worse when the number of connected object increases.
  • BLE is optimized for low-latency sporadic transmissions and therefore its efficiency degrades dramatically for larger data transfers. With its maximum of 20 bytes application payload size per packet, the gross 1 Mbps data rate of BLE translates into a theoretical maximum transfer rate of 250 kbps, and in practice the actual transfer rates drops below 100 kbps. This opposed to Bluetooth Classic v1.2 that achieves 700 kbps, and v2.1 + EDR reaches 2 Mbps actual transfer rate. An actual transfer rate of only 1/10 of the gross data rate is rather lackluster and translates into poor power-efficiency for such type of data traffic. Although many IoT applications may have a limited data amount to transfer, e.g., for switching off or changing the color of a light bulb, others would still require slightly larger transfers. As a result, BLE is not suitable for IoT applications that require higher data transfers.
  • BLE has limited range and extending the network therefore requires a hybrid topology where some client nodes act as server nodes for other star networks. In Bluetooth-specific terminology, this is called scatternet, which yields high network complexity in real deployments. For instance, BLE is essentially asynchronous, such that this hybrid topology (mix of star and mesh) causes increased interference and increased power consumption, even inside a single network.
  • Finally, BLE suffers from interference from USB 3.0, and poses a challenge when operating with collocated LTE or WIMAX networks. This is reflected in Bluetooth SIG filtering recommendations. However, workarounds are developed as well.

CSRmesh

In February 2014, CSR plc, formerly Cambridge Silicon Radio, announced the availability of their proprietary CSRmesh software. CSRmesh operates over Bluetooth Low Energy (BLE) with the aim to enable mesh topology over the restrictive BLE scatternet topology and to provide direct communication between BLE devices. However, we want to note the following:

  • The main advantage of CSRmesh is to allow smartphone connectivity. It is still questionable whether this connectivity should be achieved via direct connection to any device or more simply via a gateway or routers, e.g., Wi-Fi or BLE-enabled routers, or even through cellular if a device is out of range.
  • Turning BLE into a mesh-able protocol is not that straightforward. Even if BLE in itself is power-efficient for low duty cycle and small data packets, enabling the mesh functionality would require each device to simultaneously be an observer and broadcaster. This implies that each device would continuously listen for advertising packets, and would then switch to advertising the received data for some period.
  • The inefficient use of the radio resources inherent to continuous receive would make it difficult to achieve ultra-low-power consumption in resource-constrained devices. As reported on CSR Forums, there happened to be a current consumption in idle state of around 3mA, which is 100x more than people would expect for a battery powered IoT device. In short, the asynchronous nature of BLE, optimized for low duty cycle / sporadic transmission, seems to offer a challenge for the implementation of a power efficient mesh topology on top of the exiting BLE protocol stack.
  • Allowing direct smartphone connection to every device may not provide additional functions. On the contrary, as discussed above it will drain the battery of the device. In addition, it is a potential security threat because there is no gateway with sufficient computing power to filter access and enable strong authentication security.

questions / comments? fire away!

Internet of Things Wireless Connectivity Option: Wi-Fi Pros and Cons

Wifi-Hotspots
Today one of the most common connectivity technologies for consumer products is Wi-Fi, whose 802.11b/g flavors are using the license-free 2.4 GHz frequency band. A Wi-Fi access point (or hotspot) has a range of about 20 meters (66 feet) indoors and a slightly greater range outdoors. Wi-Fi has the benefit of a large spectrum allowing high data rates, 54 Mbps and still increasing with 802.11n and 802.11ac, in a license-free frequency band that is almost harmonized worldwide1 [17]. Wi-Fi has been widely adopted and it is a great way to provide wireless broadband internet access. However, Wi-Fi is designed for high data rates needed for multimedia contents, as opposed to many IoT applications. There has been some effort to promote low-power Wi-Fi; however, it remains an order of magnitude hungrier than what battery-powered devices in IoT application can afford such as battery powered sensors. In short, Wi-Fi is not a suitable candidate for many IoT applications. It is overkill on the data rate for most applications and an absolute power guzzler.  Wi-Fi is likely to remain the major smartphone and Internet connectivity medium. One can envision that the IoT network gateway would be embedded in the Wi-Fi hub already present in most homes, commercial spaces, factories, and offices.

Connectivity Options for the Internet of Things (IoT)

First, it was M2M – Machine to Machine communication a technology that was suppose to revolutionize our world, but never really took off in a big way due to the cost of embedding cellular connectivity in the end devices. Now M2M has been replaced with IoT – Internet of Things, a better sounding term and hopefully with smarter and cheaper options to connect random things to the Internet. Everyone has their own idea of what the Internet of Things (IoT) is, but one thing is certain that it will increasingly become important in our lives given the ever decreasing cost of wearable devices, sensors, and other monitoring equipment.

It is important to separate over optimistic ignorant hype from actual reality of the technologies. Any software / hardware engineer who ever developed anything useful will tell you that it is easy to define a use case, but a lot harder to actually build a system.

Our aim is describe technology enablers for IoT, especially communication technologies and protocols that will be used for building IoT applications.

Applications for IoT Abound

Despite a lot of vague use cases cited in popular press (and many seem out of science fiction books rather than based on understanding of technology), IoT can be applied to three broad areas:

– Consumer Homes and Personal Networks

– Consumer in his/her Automotive Vehicle

– Industrial and Office Applications

Homes are easy frontiers to deal with for IoT. A typical American home contains home appliances, entertainments systems, temperature and humidly controls units. It is easy to see how a user will like to be able to manage some or all of these devices using his wearable or handheld devices. Most use cases are easy to enumerate by using a general paradigm of control X using Unit Y.

Automotive sector is already integrating all kind of sensors in the car and creating various enablers like Advanced Driver Assistance Systems (ADAS). ADAS can warn drivers from low tire pressure to dangers ahead using a combination of communication and data processing technologies.

Industrial applications for IoT are still in infancy. Most existing M2M applications will be moved to the IoT categories be it the data collection in the supply truck or the manufacturing floor. The amount and type of such applications is only limited by human imagination and the ability of engineers to create them.

Today, these mentioned segments use wireless technologies and Internet interaction, but typically they each focus on what is common within their industry. The chosen wireless solution needs to adequately address the industries’ concerns regarding connectivity options, robust operation, and security features.

Communication Options

The Internet of Things (IoT) is built on an underlying multi-protocol communications framework that can easily move data between embedded “things” and systems located at higher levels of the IoT hierarchy. For designers and application developers, a diverse set of wireless and wired connectivity options provides the glue that holds IoT together.

All IoT sensors require some means of relaying data to the outside world. There’s a plethora of short-range, or local area, wireless technologies available, including: RFID, NFC, Wi-Fi, Bluetooth (including Bluetooth Low Energy), XBee, ZigBee, Z-Wave and Wireless M-Bus. There’s no shortage of wired links either, including Ethernet, HomePlug, HomePNA, HomeGrid/G.hn and LonWorks.

Selecting the best network option for an IoT device, however, requires a careful look at various factors for each situation.

  • The Scale and Size of the IoT Network
  • Data Throughput or Transfer Requirements,
  • The eventual physical location of the embedded devices, the battery size and physical size etc.

Micro-controllers that provide the heart of most embedded or wearable devices already have certain input output integrated. Today, there is a big choice of good, inexpensive, programmer-friendly devices with nice peripherals, low power consumption, and good cross-platform support. You can get cheap Arduino or Raspberry boards just for under 10 dollars.

Just like Micro-controllers, designers do not lack options for wireless connectivity and ICs able to support them. While ANT, Bluetooth®, WiFi and ZigBee may number among the more familiar alternatives, viable wireless connectivity solutions have coalesced around standards including 6LoWPAN, DASH6, EnOcean, Insteon and Z-Wave, among many others. At the same time, smart designers can use proprietary RF approaches. However, for remote and highly mobile applications cellular broadband with LTE or other Wireless connectivity is the only option.

For Wired Devices, Ethernet Rules Supreme

The Internet of Things (IoT) implies connectivity, and developers have lots of wired and wireless options at their disposal to make it happen. Ethernet tends to dominate the wired realm. IoT frameworks map higher-level protocols on this type of connectivity, but the devices don’t work until they have a method of communication with the network.

At this point, Ethernet implementations range from 10 Mb/s up to 100 Gb/s. Of course, the high end generally targets the backbone of the Internet to link server farms in the cloud, while the low to mid-range runs on the rest of the devices. The median implementation these days is 1-Gb/s Ethernet. A new class of Ethernet speeds looms on the horizon. Essentially, 1-Gb/s Ethernet is bumping up to 2.5 Gb/s with a corresponding hop up for higher-speed Ethernet like 10 Gb/s moving to 25 Gb/s. This change essentially provides faster throughput using the same cabling.

Other less common networking possibilities exist on both the wired and wireless side, but are worth mentioning. For example, the HomePlug Alliance’s Powerline networking uses power connections to power the interface as well as a transmission medium. A host of interoperable products include devices such as wireless access points and bridges to Ethernet.

IoT Wireless Technology Selection

Here it really gets interesting. There are several proprietary wireless solutions used in every segment as well as standards including 6LoWPAN, ANT+, Bluetooth, Bluetooth low energy, DECT, EDGE, GPRS, IrDA, LTE, NFC, RFID, Weightless, WLAN (also commonly referred to as Wi-Fi), ZigBee, Z-Wave, and others. We can briefly examine the merits of each.

Wi-Fi When You Need Big Bandwidth

Wi-Fi, with its array of 802.11 variants, provides the highest throughput of wireless technologies at this point. New emerging 802.11ac uses the 2.5- and 5-GHz bands with a combined bandwidth of 5.3 Gb/s. Indoor range is on the order of 100 to 200 feet. The next evolution—802.11ax—is poised to succeed 802.11ac.

A key challenge for IoT developers surrounds power requirements. WiFi communication technology requires far more power than some other technologies. Hence, WiFi option may have to be limited only to devices such as mobile phone, tablets or where it may be possible to deliver wired power like home mounted temperature control sensors and security system components.

Wi-Fi for more power-limited budgets is possible but will have to add techniques to preserve battery lives. For example, a device can send a burst of data at pre-determined intervals and then get to sleep mode.

Bluetooth Classic and Bluetooth-Low Energy (LE)

Bluetooth is a short-range technology utilizing the 2.4- to 2.485-GHz ISM (industrial, scientific, and medical) band. The Bluetooth Special Interest Group manages the technology, with the latest standard being Bluetooth 4.2.

Until smart phones came with media players, Bluetooth was at the verge of almost dying but since then it has come to be embedded in numerous devices. Bluetooth has “classic” and Low Energy (LE) versions; the 4.x standard allows both or either to be implemented. BT- “classic” and BT-Smart/LE aren’t backward-compatible and very different technologies except for the name.

BT-LE is designed to allow for devices that run and communicate for months or years using low-power sources like button cell batteries or energy-harvesting devices. Classic and Smart Bluetooth maximum range is about 100 m (330 feet), while data rate is up to 3 Mbs/s and 1 Mb/s, respectively. However, actual application throughput, like most wireless technologies, is less—2.1 Mb/s for classic and 0.27 Mb/s for Smart.

A new feature in BT-LE is Bluetooth beacons that permit a transfer of information such as device availability, coupons etc at certain intervals. It can be very useful for IoT apps.

ZigBee – Sensor Networking with Scalable Mesh Routing

This is my favorite technology. You can get ZigBee modules cheaply for a few cents, and integrate in any device. It barely uses any battery, runs for a year on a simply battery, and is good for sending periodic sensor data. It can be used for everything from embedded sensors, medical profiling and, naturally home automation processes.

ZigBee is a wireless technology developed as an open global standard to address the unique needs of low-cost, low-power wireless M2M networks. The ZigBee standard operates on the IEEE 802.15.4 physical radio specification and operates in unlicensed bands including 2.4 GHz, 900 MHz and 868 MHz.

A key component of the ZigBee protocol is the ability to support mesh networking of up to 65,000 nodes. In a mesh network, nodes are interconnected with other nodes so that multiple pathways connect each node. Connections between nodes are dynamically updated and optimized through sophisticated, built-in mesh routing table.

Other Low Energy Wireless Options – Zwave, 6LowPan, MiWi, ANT etc.

Just like ZigBee, there are other options some proprietary, some developed by a group of vendors and some coming through other standardization bodies that sit on top of IEEE 802.15.4 physical radio specifications or have their own proprietary radio layers.

Zwave, supported by the Z-Wave Alliance, is another competing technology to Zigbee for home automation projects. Like ZigBee it too supports mesh networking, but is protocol is proprietary. ZigBee chipsets are produced by several silicon vendors, while Z-Wave ones come only from one manufacturer, Sigma Designs.

Z-Wave uses the Part 15 unlicensed ISM band. It operates at 908.42 MHz in the U.S. and Canada but uses other frequencies in other countries depending on their regulations Performance characteristics are similar to 802.15.4, including 100-kb/s throughput and a 100-ft. (30.5 m) range.

In addition, a number of vendor-specific protocols are built on 802.15.4, such as Microchip’s MiWi, which are often lighter weight and have fewer licensing restrictions.

6LoWPAN is a low-power wireless mesh network where every node has its own IPv6 address, allowing it to connect directly to the Internet using open standards. Since, each node has its own IP address all other IP routing protocols can be used.

ANT is an open access multicast wireless sensor network technology designed and marketed by ANT Wireless, now part of Garmin, featuring a wireless communications protocol stack that enables semiconductor radios operating in the 2.4 GHz band (“ISM band”) to communicate. ANT is characterized by low computational overhead resulting in low power consumption by the radios supporting the protocol and enabling low power wireless embedded devices that can operate on a single coin-cell battery from months to years..

In short, 6LoWPAN, ZigBee, ZWAve, MiWi, ANT are all competing for the same space.

Cellular Network Options Are Still Available

Most cellular IoT devices aim to use Long Term Evolution (LTE) 4G and 5G standards. Cellular technology has the advantage of coverage and availability in the large areas. For some devices mounted in the moving trains, trucks, roadside emergency devices, or cars this may be the only viable option.

LTE and LTE-advanced both provide excellent bandwidth throughputs. LTE provides almost like 300 MBits/sec. 4G LTE-Advanced will provide 1 Gb/s, while 5G promises 10 Gb/s.

The major problem is the recurring cost of cellular connectivity since cellular operation requires plans from service providers.

Device Selection Criteria for IoT Designers

IoT is about creating a most efficient, application specific network of connected devices. Connected devices all share five key components:

  • The need for smarter power consumption, data storage, and network management;
  • The need for stronger safeguards for privacy and security;
  • The need high-performance micro-controllers (MCUs); sensors and actuators; and
  • The ability to communicate without losing information.

To narrow down the list of options, compare the technologies from the following IoT key needs:

  • Cost efficiency: Most IoT devices are of low cost, and need affordable radio solutions. So, performance and cost balance are very important.
  • Small size. IoT devices are typically of small size, the radio technology with all its Antenna, battery etc need to physically fit in the housing of the sensor device.
  • Secure Communication. Security of communication is needed. Authentication and data encryption must be supported by the chosen wireless technology. Also, it should be possible to build end to end secure applications.
  • Low power consumption. Since most IoT devices operate on batteries or energy harvesting technologies, the radio technology must have ultra-low power consumption.
  • Strong Available Ecosystem. For any device selection you will need to examine its ecosystems since interoperability with other devices will be important.
  • High Reliability under Noisy Conditions. IoT devices will operate in less than perfect conditions. Hence wireless technology must be able to deal with signal noise, interference and other environmental conditions.
  • Easy to Use. It is possible to leave configurations to experts in the industrial settings, but for consumers ease of plug and play is needed.
  • Radio Range extension capability. Though IoT operates in short distances, it is important that the chosen technology can offer enough range coverage or have some range extension capabilities.

Matching the Design to the Target Market

Despite the bewildering list of connectivity options, system designers find that the best option for a particular IoT device. A design is often constrained based on application needs, performance requirements and environmental limitations. The need for compatibility in established markets may also affect the best connectivity choice.

The good part is that if you are a hardware or embedded system designer, the choices of components is plentiful.

You can find a diverse set of relate hardware solutions including modules and ICs for ANT connectivity from vendors including Nordic Semiconductor, Panasonic and Texas Instruments; ZigBee solutions from Atmel, Freescale and Microchip; and Bluetooth/BLE solutions from CSR, RFM and STMicroelectronics, 6LowPAN devices from TI, STMicroElectronics, Sensinode, Atmel etc.

If you are designing IoT devices or wants to create iOT software and need individual consulting, feel free to connect with me.