Group Actions
Engagement
  • Author Author: Gough Lui
  • Date Created: Date Created
  • Views 718 views
  • Likes 3 likes
  • Comments 2 comments
Related
Recommended

IDT SDAWIR03 RoadTest-in-Depth: Ch1 - Why 6LoWPAN?

Gough Lui

Realising practical Internet of Things (IoT) projects requires careful balance of several potentially conflicting variables, which may include cost, convenience, power consumption, bandwidth, processing power and security just to name a few. Even when just considering the communications needs of IoT devices, there is rarely a one-size-fits-all solution as it depends on the individual project needs.

 

Looking for a Networking Technology

The requirements of IoT devices contrast dramatically with general purpose networks, with the majority of IoT devices expected to send very small volumes of data but over longer distances with much more stringent power budgets resulting in short active periods. The majority of IoT devices are generally low-cost and have limited computational capabilities, but also may require security defences and mesh network capabilities to meet requirements. Regardless of the technology chosen, the data will have to be carried over conventional networks/internet for processing and data warehousing, possibly in the cloud.

 

To meet these various needs, there is a plethora of wireless networking technologies which may be applicable to IoT scenarios, which can be quite confusing to navigate. A number of common technologies operate at different layers using the same physical layer technology and thus vary in abilities and complexity. A summary of most of the technologies is given in the table below:

image

Note: All information supplied in the table is sourced from publicly available sources on the internet and is provided in good faith. No guarantees are provided, as some claims and specifications may vary from vendor to vendor. Please do your own research as I will not be held responsible for any damage or loss incurred from errors, omissions, your use of or inability to use the information provided.

 

When looking at the table, it may be difficult to identify the correct technology for your needs as it doesn’t summarise all the characteristics of each technology, as many details are implementation-specific and dependent on operating condition. For example, at a glance, for home-based IoT technologies, Wi-Fi might appear to be a great choice as it is a standards-governed private-operator technology with high bandwidth and decent range. In truth, it often is, although the power consumption is its Achilles heel and its range may not be sufficient especially as it generally operates point-to-point.

 

As a result, it may be tempting to use Bluetooth, especially the low-energy variant, as the data rate is still sufficient and the power budget is greatly reduced. However, traditional Bluetooth is a point-to-point system which can create coverage challenges especially as the 2.4GHz band is often crowded and thus has an elevated noise-floor reducing range in practice. Newer mesh-type Bluetooth technologies are only just emerging on the market. Integration can be more difficult, as low-energy devices tend to use an attribute/value system that is not directly translated to IP requiring a complex “gateway” device.

 

At the “home” scale, a mesh network in bands other than 2.4GHz may be desirable as it avoids interference, prevents causing interference to 2.4GHz wireless-LANs and extends coverage. Technologies in this umbrella include IEEE 802.15.4-based systems including ZigBee, SNAP, 6LoWPAN, Thread, Xbee; Z-Wave and Insteon. While there are some similarities, 6LoWPAN has advantages in being IPv6-based thus the mesh network of devices can be simply “gatewayed” into a regular IP network without requiring a complex gateway. This also simplifies programming for communication to end nodes, while also providing standards-based security (IKEv2). A particular advantage is the IEEE standardisation which leads to increased competition and interoperability and private ownership model which can reduce costs. Thread is built atop of 6LoWPAN for this reason, whereas the other IEEE 802.15.4-based technologies operate their own device profiles and communication protocols. Some competitors like to claim that being IP-based opens the systems to potential IP-based attacks and the private ownership model is old-fashioned, but I think this is a trade-off that designers will have to consider.

 

At the wide-area scale, cellular networks can have a role to play, but their radios are power-hungry and costly. Newer LTE-M/NB-IoT standards provides an option for network providers to provide a lower-rate, simplified network for IoT communication often with a software upgrade to their eNodeB’s. These standards are still in their infancy and use of these services are likely to incur some level of cost as they would be operated by telecommunications providers.

 

Knowing this, a number of other IoT-specific wide-area radio technologies have tried to fill the gap, providing low-rate data services in the sub-Ghz bands with a mixture of models. This includes LoRa, Sigfox, NB-Fi, RPMA, D7AP, Nwave, Telensa and Weightless-P. Most of these are point-to-point based with a gateway device sitting in the middle, with many of these being proprietary operator-based systems, thus incurring similar issues with cost as with the LTE-based service. Others such as NB-Fi, D7AP and Weightless-P are (or claim to be) open which makes them more attractive, but do not seem to be too popular at this stage.

 

As a result, it seems that 6LoWPAN is a sensible choice for those looking for a sub-GHz networking technology that is standardised without ongoing operator costs, with a mesh-networking topology for increased range and “transparent” IPv6 communication capability with inbuilt security that does not require complex gateway devices.

 

On the Hunt for 868/915MHz 6LoWPAN Modules

The IDT SDAWIR03 demonstration kit contains the ZWIR4512 module for 6LoWPAN connectivity. In order to see how it compares to the rest of the market, I decided to go looking for sub-GHz band 6LoWPAN-compatible radios, modules and microcontrollers. To my surprise, this was a little more difficult than I had anticipated.

 

Looking for modules on the market, there really are not many choices at all –

 

However, it can be seen that the modules have a common theme – namely marrying an IEEE 802.15.4-compliant radio with an ARM microcontroller running the 6LoWPAN stack. Potentially compatible radios (I haven’t tried) include:

 

Unfortunately, going this route for 6LoWPAN connectivity requires additional integration work with third party stacks such as uIP/Contiki or Nanostack and is not as straightforward as using a module. This also throws up another issue – namely that IEEE 802.15.4-compliant radios may not all be using the same modulations, as the standard allows for a number of different bands and modulations. As a result, while there are multiple 6LoWPAN products, interoperability is still a potential issue. Despite this, it seems IDT are a leader in a rather clear “niche” category of being able to offer not just one but two 6LoWPAN sub-GHz modules.

 

Conclusion

There are a plethora of IoT-applicable networking technologies, some of which are built upon others. Bandwidth, power consumption, range, operating band, cost of module, cost of operation, openness of standard and operating model are all factors which decide whether a given technology is suitable for a given application.

 

Of the technologies on offer, 6LoWPAN is a sensible choice for those looking for a sub-GHz networking technology that is standardised without ongoing operator costs, with a mesh-networking topology and “transparent” IPv6 communication capability with inbuilt security that does not require complex gateway devices.

 

In the market of sub-GHz 6LoWPAN modules, there are not many choices, with only the IDT ZWIR4512 and ZWIR4532, Microchip (formerly Atmel) ATSAMR30M18 and EBVElektronik Janus being the units identified. It is possible, however, to create a 6LoWPAN radio system by integrating a sub-GHz transciever with a microcontroller running the 6LoWPAN stack software (e.g. uIP/Contiki, Nanostack, etc) although this requires additional integration effort. As a result, it appears that IDT is a leader in the niche area of 6LoWPAN sub-GHz modules, although their modules are more expensive than the Microchip module.

 

---

This blog is part of the IDT SDAWIR Wireless Flow Rate, Humidity and Temperature Sensing Evaluation Kit RoadTest

  • in reply to mp2100

    That's what happens when you step back and try to look at the market objectively - it's not easy to find a perfect balance of features, especially for low-power, long-range, moderate data-rate, open standard with private ownership model. In fact, it could be argued to be a double-edged sword as closed standards generally are single-vendor but will "always work". Open standards should encourage more uptake but then potentially run into interoperability issues without additional care.

     

    The limited number of modules is an unfortunate situation, however, considering the Janus is just a ST Spirit transciever with a microcontroller tacked on, perhaps going to a radio module + microcontroller may be a worthwhile development effort as it may make it easier to integrate other features into the one package. It does mean that you might have to spin some PCBs with impedance matched traces and do some fine soldering which may be a bit difficult for a prototype.

     

    I think that the market may come to warm to 6LoWPAN as Thread runs atop of it, with the backing of a number of large companies including Nest/Google. It will all depend on how many devices are sold and installed, plus whether there is a real market need to see whether it will pick up. As a result, a "Thread" device really relies on 6LoWPAN as the networking protocol which in turn relies on IEEE 802.15.4 for the physical layer, which in turn, is usually designed for smaller-than-WAN scale.

     

    The biggest question I have regarding 6LoWPAN which I have no clear answer on is of interoperability. Already, the IEEE 802.15.4 standard defines a number of data rates, channel widths and regionalised channel plans for different "alternate" PHYs, there is the issue of physical layer compatibility. Assuming all your radios use the same frequency, modulation and data-rate (e.g. 906MHz, BPSK, 100kBit/s in the case of this kit), then the problem falls to the 6LoWPAN side. As it stands, 6LoWPAN appears to be standardised in a plethora of separate RFC documents, of which due to limited computational resources, many "6LoWPAN" modules and stacks may only implement a subset of. To learn the caveats of the ZWIR451x series, there are three pages of supported RFCs and limitations (Page 33 to 35 in the ZWIR451x Programming Guide). If two 6LoWPAN modules from different vendors implement a different subset of the RFCs, it could be conceivable that communication between modules could be impeded or be impossible.

     

    Add to this the line that says "Mesh functionality specified in the RFC is not implemented. Instead, a proprietary link-layer mesh implementation is provided." This, I think, further signals the big challenge that 6LoWPAN may face in terms of interoperability. Unlike Wi-FI Alliance where interoperability testing is part of the standards, anyone can really claim to make a 6LoWPAN module or stack but implement just a subset of the RFCs and patch the other things in their own non-standard way.

     

    - Gough

  • You had me talked into 6loWPAN, and then you talked me out of it due to the limited options. image

     

    Thanks for the background information though, it is a nice comparison of the options available.