Mistake on this page?
Submit a change in GitHub or email us

6LoWPAN Mesh

This guide provides design guidelines for developing an application on top of the 6LoWPAN mesh solution. The APIs and technologies are not discussed in detail here.

Overview of the 6LoWPAN network

Node connected to server

Typically, the 6LoWPAN network consists of one border router on multiple low-powered nodes. The nodes are connected to a cloud service for feeding in the sensor or control data.

Different device types in a 6LoWPAN network

In a 6LoWPAN network, devices can have different roles. The colours in the illustrations represent different device types and are used in the examples throughout this tutorial.

Border router (6LBR)

Border router

A border router is the coordinator of the 6LoWPAN network. It handles the translations between the 6LoWPAN and IPv6 networks. Arm does not provide translation to IPv4 network due the limited address space. We recommend using IPv6 tunnels over IPv4 network when operating in such environment.

The border router also authenticates the nodes joining the network and keeps track of the routing topology.

6LoWPAN router (6LR)

6LoWPAN router

A 6LoWPAN router is a node that can route packets. This role is required to form a topological or mesh network. This configuration does not allow nodes to sleep because they route packets to their siblings.

6LoWPAN host (6LH)

6LoWPAN Host

A 6LoWPAN host is a type of node that does not route any packets. It has only one parent routing the packets.

6LoWPAN sleepy host

A 6LoWPAN sleepy host is a 6LoWPAN host that is periodically allowed to sleep and turn off its radio.

Different types of 6LoWPAN mesh networks

6LoWPAN-based mesh networks cannot be described as a uniform standardized network type, such as Wi-Fi. Depending on the business requirements and use cases the network may have different setups and requirements.

Star network

Start topology

Star topology is the simplest form of a mesh network. Actually, it is not mesh at all. Every node connects directly to the border router.

In a star network, nodes can be very low-power devices with least amount of RAM because they have no routing responsibilities. It also allows sleeping nodes.

Mesh/tree network

Tree type mesh

In a mesh/tree network, all nodes are configured as 6LoWPAN routers.

In a 6LoWPAN network, RPL protocol is used for forming the routing topology. Every node selects a primary parent for routing so the result looks like a tree.

This network type allows to cover large areas because each node extends the range of the network. However, the packet is retransmitted on every hop, which means that the transfer capacity of the network decreases as the size of the network increases.

Example networks

Example networks

In the further chapters, we provide recommendations for three different network sizes:

  • A sensor network for an apartment.
  • A sensor/actuator network for a building.
  • A sensor/actuator network for a city.

Introduction to Thread networking stack

Why to use Thread

Thread was designed with one goal in mind; to create the best way to connect and control products in home. The key features of Thread are:

  • Designed for home.
  • Built-in security.
  • Optimized for battery-operated devices.
  • Utilizes IPv6 protocols.
  • Robust mesh network.
  • Simple to set up and use.

The Thread stack is built on IPv6 over Low power Wireless Personal Area Networks (6LoWPAN), which itself builds on IEEE 802.15.4 to offer IP-based networking. Internet Protocol (IP) provides the core mechanism for relaying datagrams across IP networks, and its routing capabilities enable internetworking.

Thread_image

Read more at the Thread Group site.

Why Mbed OS with Thread stack

Mbed OS is an open source embedded operating system designed specifically to facilitate the creation and deployment of commercial, standards-based IoT solutions at scale. Mbed OS features full support for Thread to simplify development of secure IoT applications in home and to ease the Thread product certification. The Mbed OS Thread stack is a Thread Group certified component.

Mbed Thread is based on the Mbed OS key elements

The key elements of Mbed OS are:

  • Hardware platform agnostic layer that allows easy adaptation of new hardware components.
  • Modular approach, which allows including the necessary libraries based on the application needs.
  • Multilayer build (SW/HW) in security that helps you to protect your IoT solutions.
  • Mbed RTOS (Arm CMSIS-RTOS) providing the real time software execution.
  • Toolchain and IDE support.

Mbed Thread is implemented in the Nanostack library, which also supports the 6LoWPAN protocol. In Mbed OS, the Thread stack runs in its own RTOS thread using an internal event scheduler. Mbed OS provides the Mesh C++ API for building Thread applications.

Nanostack provides a set of C API headers with more functionalities. The nanostack repository has the following header files():

  • thread_management_if.h for initializing the stack and managing the network data.
  • thread_commissioning_api.h for implementing an on-mesh or a native Thread commissioner.
  • thread_border_router_api.h for implementing a Thread border router.
  • thread_diagcop_lib.h for building and parsing the Thread diagnostics protocol TLV messages.
  • thread_meshcop_lib.h for building and parsing the Thread mesh commissioning protocol TLV messages.
  • thread_net_config_api.h for making neighbour discovery (ND) data requests.

Thread devices you can build on Mbed OS

The Mbed OS Mesh API allows you to define 3 types of devices:

  • Router enabled device (REED), which can become an active router.
  • Sleepy end device (SED).
  • Minimal end device (MED).

In addition the Nanostack API allows you to define the Full end device (FED) device type.

In most cases, the REED, MED and SED configurations are enough to build a network. In a SED device, the radio is switched off during the sleep times. To take the full advantage of the SED configuration, the application developer must implement the sleep procedures in the device.

For an end device or a router example, see mesh minimal example.

End devices

Mbed OS offers separate configurations for different Thread end device types. Usually, the end devices are the most constrained devices in the Thread network. They serve as last hop in the mesh topology. Devices such as plain sensors, controls and switches can be implemented as end devices only. For the most constrained hardware, the minimal end device (MED) or the sleepy end device (SED) is an optimal selection as the implementation requires the smallest amount of flash and RAM memory due to the limited functionality. Note that a sleepy end device also requires more resources on the parent device. End devices communicate through a parent and can switch to another parent if the current connection is broken.

A Thread network does not work with end devices only. There must be router devices, that can route the traffic between nodes and to the back-end network through the border router.

Minimal end device (MED):

  • Registers its address to a single parent.
  • Relies all routing and address queries on the parent.
  • Must start a new scan if the parent is lost; longer disconnect from network.

Sleepy end device (SED) is like MED, but:

  • Does not keep the radio on all the time.
  • Uses a polling mechanism to receive packets from the parent (polling time configurable).
  • Requires the parent to store packets when in sleep.
  • Can be temporarily switched to MED to transfer large amounts of data.

Full End Device (FED):

  • Does not register addresses to the parent.
  • Makes address queries.
  • Listens to multicast messages from other devices (others than parent).
  • Reduces the parent device's load and memory requirements compared to MED and SED.

Routers

In Thread networks, devices operate in several specific roles separated by the services they provide. All router devices provide mesh routing and they can switch the state between an active router and a REED device without any user interaction. The first router on a network becomes a leader, that manages:

  • Router ID assignment.
  • Thread network data registration.
  • Network data distribution.
  • Commissioner petition.

Additionally, a router can act as a border router (must be configured in build time), that provides services for devices within the Thread mesh network and the backbone network.

Mbed OS offers a separate build for a Thread border router. The border router routes IPv6 traffic to the external IPv6 networks. Currently, our border router uses an Ethernet connection to the backbone IP network, but also other means of connectivity are available (cellular or WiFi).

See an example of a Thread border router.

Commissioning

Commissioning takes place when new devices need to be added to the Thread network. All Mbed OS Thread devices (end nodes and routers) can join to any certified Thread network. In Thread, there can be one commissioner, that allows new devices to join the network. There are three types of commissioners:

  • A native commissioner uses the 802.15.4 radio interface, but does not belong to the Thread network.
  • An on-mesh commissioner is a Thread device already joined in the Thread network.
  • An external commissioner connects to the Thread network through the border router, that is connected to the backbone.

Example use case for external commissioning

An external commissioner uses mDNS-SD service discovery to find a list of available Thread networks. When you select the network to connect to, the application asks for the network passphrase. The passphrase is usually placed on a label on the border router box (like in WiFi).

The commissioner application generates PSKc from:

  • The network passphrase.
  • The Thread network name.
  • The extended PAN ID.

The Thread network name and the extended PAN ID are received in the scanning phase. The commissioner application can now start a DTLS session using the generated PSKc.

After the authentication phase, the commissioner requests the Thread network leader to petition the commissioner to become an authorized commissioner. Here, the border router works as an arbitrator in the middle.

Now, the Thread network is ready to accept new joiner devices.

  1. The commissioner application scans the QR code, which is PSKd (Pre-Shared Key for device) + EUI64, from the device's label and informs the Thread network that this device is accepted to the network.
  2. The joiner device detects in the scanning response that it can now join the network and starts a DTLS session using PSKd.
  3. The session is created through the Thread network (via the joiner router and the border router) to the commissioner application.
  4. The commissioner authenticates the device and accepts it to the network.
  5. The device receives the Thread configuration, which allows it to join.

Note: Thread uses hashing and elliptic curve algorithms for the secure communication. PSKd(s) and EUI64(s) are never transmitted in plain text over the peer to peer connection.

How to start on Mbed OS

The Mbed OS Thread stack supports all three types of commissioners. You can create an external commissioner application by using the Thread MeshCoP protocol or use the Mbed OS APIs (thread_commissioning_api.h) to implement a native or an on-mesh commissioner. Currently, there is no reference implementation for native or on-mesh commissioners. External commissioning is supported through the Nanostack border router. An external Commissioning application (Android) is already available. Also an IOS version will be available soon.

See Thread commissioning guide how to commission a Thread device to the network in practice.

The maturity of the Mbed OS Thread implementation

Mbed OS provides a certified Thread 1.1 stack implementation.

In addition to the Thread Group certification, where the focus is to ensure interoperability with different implementations, the Arm Mbed team is focused on delivering a high quality implementation of the software components required in the Thread implementation. We have invested in the automated test environment, where we can verify all the change requests as well as the regular releases.

To ensure high quality the Mbed OS Thread stack is tested daily including:

  • The non-functional test sets (stability, reliability, performance, stress, recovery).
  • The functional test cases using Valgrind memory analysis tool.
  • The code coverage measurement using LCov.
  • Automated certification test cases to ensure the certification validation all the time.
  • The RAM/ROM and performance measurements with trend charts.

To ensure the production ready delivery we also check:

  • Security vulnerabilities using Defensics automated testing tool.
  • Static code analysis using the Coverity tool.
  • Interoperability against other vendors using the official Thread certification harness.

Configuring the hardware

Selecting your radio

6LoWPAN network uses IEEE 802.15.4 radios and therefore, operates on one of the following unlicensed frequency bands:

  • 868.0–868.6 MHz: Europe, allows one communication channel (2003, 2006, 2011[4])
  • 902–928 MHz: North America, up to ten channels (2003), extended to thirty (2006)
  • 2400–2483.5 MHz: worldwide use, up to sixteen channels (2003, 2006)

The data rate varies from 20 kbit/s to 250 kbit/s. The data rate available per node should be considered when designing the application. Basically, the data rate is divided between all nodes in the network. Roughly half of the channel capacity should be allocated for signalling purposes, and each hop requires retransmisson of the packet.

Datarate

Rule of thumb: The bandwidth per node is divided by the number of nodes in the network and the number of hops.

Notes on different hardware

As the stack runs on multiple different Mbed OS development boards there might be combinations of board and RF shields that may, or may not, work together due to pin collision or other reasons.

This page aims to collect information regarding different hardware combinations.

Please see Notes on different hardware on Mesh example application for up to date copy of this list.

RF shields

Following RF shield have been used with Mbed OS mesh examples.

Tested development boards

The following table shows which development boards have been tested. It does not present our current testing infrastructure, so we cannot guarantee all combinations but we do our best to ensure it is up to date.

board / RF shield Atmel MCR20A X-NUCLEO-IDS01A4
FRDM-K64F Yes Yes
NUCLEO_F429ZI (1) Yes Yes Modified, (3)
NUCLEO_F401RE Yes
ublox EVK-ODIN-W2 Yes No. (2)
Onsemi NCS36510 (internal RF)
NXP KW24D (internal RF) Yes (4)

Notes:

  1. If the Ethernet driver is enabled, requires HW modifications if RF shield uses SPI1. See Driver notes and nanostack-borderrouter-private Issue #17.
  2. Pin collision, see mesh-minimal Issue 55.
  3. X-NUCLEO-IDS01A4 expansion board required modifications to be used in Mbed OS. See Driver readme.
  4. KW24D has MCR20A chip integrated. Use the same driver.

Build time configuration of the stack

To minimize the size of the produced stack, we have defined a set of build options.

The suitable build option depends on whether you are building it for Mbed OS or for bare metal.

Build options

Option Name Features supported Current binary size in Mbed OS 5.5
FEATURE_ETHERNET_HOST Only Ethernet host support, no mesh networking. 108 kB
FEATURE_LOWPAN_BORDER_ROUTER 6LoWPAN-ND border router support. 219 kB
FEATURE_LOWPAN_HOST 6LoWPAN-ND non routing host mode. 122 kB
FEATURE_LOWPAN_ROUTER 6LoWPAN-ND routing host mode. 169 kB
FEATURE_NANOSTACK_FULL Everything. This is only for testing purposes. 355 kB
FEATURE_THREAD_BORDER_ROUTER Thread router device with border router capability. 211.927 kB
FEATURE_THREAD_END_DEVICE Thread host without routing capability 165.548 kB
FEATURE_THREAD_ROUTER Thread host with routing capability 198.618 kB

Note: The binary sizes have been estimated using GNU Arm Embedded Toolchain version 4.9. They will differ based on the toolchains or the status of the repository. The final size can only be estimated when linking the final application. The indicated size only gives you a guideline of what kind of changes to expect between different options.

Using configuration option on Mbed OS

If you want to optimize the flash usage, you need to select a proper configuration for Nanostack. The configuration depends mostly on the preferred use case.

See 6LoWPAN overview for the definition of star and mesh networks. These same principles apply also to Thread protocol.

Select the protocol the network is based on:

  • 6LoWPAN-ND.
  • Thread.

Select the device role:

  • Mesh network. A router. (default)
  • Star network. A non-routing device. Also known as a host, or sleepy host.

Modify your mbed_app.json file to tell which Nanostack build to choose and which configrations to use on Mbed Mesh API.

An example of the mbed_app.json file:

...
    "target_overrides": {
        "*": {
            "target.features_add": ["NANOSTACK", "LOWPAN_ROUTER", "COMMON_PAL"],
            "mbed-mesh-api.6lowpan-nd-device-type": "NET_6LOWPAN_ROUTER",
            "mbed-mesh-api.thread-device-type": "MESH_DEVICE_TYPE_THREAD_ROUTER",
        }
    }

In the application, you need to choose from two supported interface classes:

  • For 6LoWPAN-ND based network, use LoWPANNDInterface.
  • For Thread based network, use ThreadInterface.

Then you may optionally choose to select the non-routing mode for those networks. The following tables show the values you should use in the mbed_app.json file for your devices in different networks.

6LoWPAN-ND

mesh-type: MESH_LOWPAN

Device role target.features_add value mbed-mesh-api.6lowpan-nd-device-type
Mesh router (default) LOWPAN_ROUTER NET_6LOWPAN_ROUTER
Non-routing device LOWPAN_HOST NET_6LOWPAN_HOST
Thread

mesh-type: MESH_THREAD

Device role target.features_add value mbed-mesh-api.thread-device-type
Mesh router (default) THREAD_ROUTER MESH_DEVICE_TYPE_THREAD_ROUTER
Non-routing device THREAD_END_DEVICE MESH_DEVICE_TYPE_THREAD_SLEEPY_END_DEVICE

How to commission a Thread device in practice

Building the node application

By default, the Mbed Thread applications/examples use the static network link configuration defined in the mesh-api configuration file. If you want to use the Thread commissioning, add the following lines to your .json file. You can use the mesh-minimal application as an example.

  • "mbed-mesh-api.thread-use-static-link-config": false
  • "macros": ["MBEDTLS_USER_CONFIG_FILE=\"mbedtls_config.h\""]

Setting thread-use-static-link-config to false prevents the usage of the predefined link configuration values and allows the device to start network scanning.

QR code generation

You can use a free online tool to generate a QR code.

In the tool, fill in the URL field: v=1&eui=000b57fffe07a8be&cc=PV7TUCB0. These are just example values. Fill in the correct values for your device and make sure v=1 is always there.

  • cc is the PSKd, which is configured in the .json file (see the mesh-api configuration).
  • eui is equal to the RF MAC address by default.

There are four additional query parameters you can put into this field:

  • vn Vendor name
  • vm Vendor model
  • vv Product/Vendor version
  • vs Product/Vendor serial number

To print the MAC address, you need to connect the node to the Thread network with static configuration enabled, unless you have your own configuration for the MAC address. For example, in the mesh-minimal application, place this printf("MAC address = %s\n", mesh.get_mac_address()); after printf("connected. IP = %s\n", mesh.get_ip_address());

Using the Thread commissioning application

You can use the Thread Android application for commissioning:

  1. Set up a connection to the Wi-Fi access point to which the Thread border router is connected. When connected, the application lists your Thread border routers(s).
  2. Select a border router from the list.
  3. Enter the passphrase asked by the application. It is Thread Network (when using the default mesh-api Thread configuration). After successful connection, the application is ready to scan the QR code.
  4. Power on your Thread device if it is not already on.
  5. Scan the QR code. The Thread device should join the network. If you are using the mesh-minimal application you should see the IP address printed: connected. IP = ....

Thread mesh questions and answers

How are devices joined to the networks and what are the options for commissioning modes?

There are no different commissioning modes for devices joining to the network, there are only different kinds of commissioners (on-mesh, native, external). Thread devices either have the configuration or not. If they don’t have the configuration, they try to find a Thread network that accepts them. Then they do the commissioning using DTLS to authenticate themselves and if successful, they will receive the network credentials and become a part of the network.

Where are the default configurations of the Nanostack set?

  • Thread devices do not have a default configuration. They should always be commissioned to the network and receive the configuration on site. A commissioner can modify the configurations to the entire network and all Thread devices in the network will automatically pick the new configuration and save it to NVM.
  • The border router may have a default configuration set, that provides a starting point for setting up the network.

Are the Thread configurations easily exposed to the application and are they runtime configurable?

  • The Thread management API can be used to read/store/delete the Thread link configuration and to define the device configuration (thread_management_if.h).
  • The Thread commissioner can change the network configuration of the entire Thread network. By using the thread_commissioning_api.h and thread_management_if.h, you can build an on-mesh or native commissioner that can update the network configuration.
  • For example, the border router can be set up with the default configuration. The commissioner can then update the whole Thread network configuration (including border router).

Who selects the channel and PAN ID? Will different manufacturers pick different channels and PAN IDs?

Channel and PAN ID are part of the Thread configuration that is received when a device is commissioned to the Thread network. The commissioner can modify the configuration at any time. The manufacturer does not decide the Thread link configuration.

How can ad-hoc mesh networks be easily formed with different manufacturers?

Ad-hoc networks with devices from different manufacturers can be easily created by commissioning.

Does the border router listen on all channels or just one?

  • The border router is a Thread router device and uses the same configuration as other devices in the Thread network. So it uses a single channel.
  • Devices that have not yet joined the Thread network scan all channels and PAN IDs to find a Thread network that they want to be part of.

How to commission with a mobile device? Is there an example app?

An example application is downloadable from the Android store.

Are there any application examples? What are the Thread features supported/not supported by them?

How to debug and visualize the network?

  • You can download a Wireshark version that supports the Thread protocol from the Wireshark web page.
  • A commissioner can do network diagnostics and topology images using Thread-specific diagnostics commands. Our software supports this but there is no C/C++ API support.

Link quality and errors are easiest to debug using Wireshark.

How to send/receive with UDP and TCP sockets. How to use multicast groups?

The mesh minimal uses socket communication and multicasting. See more details in the mesh minimal example.

What if my ISP does not provide IPv6 service? Why do I need IPv6 internet service? Can I use a tunneling service?

Thread is based on the IPv6 protocol. If the communication must go over IPV4 network, there are two solutions available:

  • NAT64.
  • IPv6 tunneling.

What happens if a packet cannot reach its destination (for example, no internet connection to border router)? What is the responce back to the device?

There are no special Thread codes available, you will have the normal internet error codes. An application must handle the temporary network connection problems with proper retry logic.

How are network errors sent back to the device? Is there a description of what went wrong or simply no response?

There are no special error codes in Thread. The application can receive ICMPv6 error codes.

How to message all nodes in the mesh? Can I use a multicast address?

IPv6 multicast messages are supported. link-local and realm-local (mesh-local) multicast scopes work within the Thread network, as well the site-local multicast messages.

  • Usually, global addresses are used to communicate with the remote services. When a device has the destination address, the network stack selects the proper source address and route to that destination.
  • An application developer may implement a protocol (using multicast) for querying the link-local or mesh-local addresses from other devices in the Thread network. Link-local addresses work only over one radio hop. Mesh-local addresses work over multiple hops in the Thread network.
  • The mbed OS mesh API provides functions to query the device's own addresses (link-local or global).

What are the configurable parameters in the Thread devices? What do they mean and where are they documented?

  • The Thread configurable parameters are the Active Operational Dataset parameters. The parameter explanations can be found in the Mbed Mesh API. More information can be found in the Thread specification.
  • The Thread device configuration includes PSKd and EUI64 (usually the MAC address of the radio chip), that are used to commission the device.

What are PSKc and PSKd? Where can find these?

  • PSKc is the authentication key for the native or external commissioner. This value is generated from the passphrase of the network combined with the network name and XPANID that are received when scanning the networks. The commissioner application asks for this passphrase after scanning and selecting an available Thread network, exactly the same way as in WiFi.
  • PSKd is the authentication key used to authenticate a device to the Thread network in combination with EUI64.
  • These values are printed to a sticker on the device or the device packaging in the form of a QR code that is then scanned by the commissioner application. This will allow the device to be commissioned to the Thread network. After the authentication, the Thread configuration is given to the new device.

Nanostack

This chapter introduces the 6LoWPAN stack architecture. It contains the following sections:

Architecture

IPv6 Low power Wireless Personal Area Network (6LoWPAN) is an adaptation layer that enables the use of IPv6 over low power wireless and supports IPv6 and User Datagram Protocol (UDP) header compression. The Internet Protocol (IP) header compression allows 6LoWPAN packets to be compact, making it robust and, ideal for low power and lossy networks. It also handles fragmentation and reassembly of packets in scenarios where payloads larger than the Maximum Transmission Unit (MTU) of the supported interface are transferred (a maximum of 1280 bytes).

The industry leading Arm 6LoWPAN stack is both highly scalable and reliable, but also provides an unrivaled feature set to include a compact source code base and optimal memory usage. Additionally, the 6LoWPAN stack can be supplied with optional software modules for security and embedded web services (Mbed Device Server). The modular structure of the design makes it possible for Arm to accommodate most requirements.

The combination of 6LoWPAN stack and 6LoWPAN border router Access Point (AP) software enables developers to use the extremely flexible and multi-purpose mesh communication solution for most applications (see Figure 1-1).

Figure 1-1 6LoWPAN network architecture

nw-arc

6LoWPAN stack

The 6LoWPAN stack is modular in design and uses an extremely lightweight event environment that allows the developer to run the stack completely in standalone mode without a need for a third-party Operating System (OS). Additional benefits of the model are lower hardware requirements in the terms of flash and RAM usage. This approach significantly reduces integration effort and, thus, reduces your time-to-market. The stack can also be used in a configuration so that the developer can run it as a task or thread, for example, within a full Real-time Operating System (RTOS). However, this will inevitably increase the system resource requirement because additional resources are required by the RTOS.

The stack architecture can be divided into four high-level components:

These components are illustrated in Figure 1-2.

Figure 1-2 The components that comprise the 6LoWPAN stack architecture

stack-arc

Note: For simplicity, the event core is shown to be part of the same component, alongside the protocol modules.

Event core

The event core is responsible for the low level events, scheduling and system timer functions. The core module provides all the basic functionality that the rest of the modules need (with the exception of the application modules) and is undertaken with a low resource requirement. The design objective has been to reserve and use minimal resources of the hardware platform and, instead, leave all unnecessary timers, for example, unused so that the developer has full control over these resources from the application layer.

The event system provides the application with the tools and functionality that it needs, for example, to post timed events to itself and create events with specific callback functions.

The event system relies on Platform API to provide portable set of functions that it needs. These platform drivers are then ported for each operating system or embedded platform you want to run the 6LoWPAN stack.

Protocol modules

The 6LoWPAN stack implements a wide range of protocols as individual modules, which is illustrated in Figure 1-2. These modules are designed to use an internal data structure that is used to exchange packets. The stack uses a no-copy design wherever possible because in some modules a packet may be copied to provide a re-transmission functionality, as mandated by related standards.

The modular design of the 6LoWPAN stack allows some modules to be omitted from the build, for example, excluding the Transmission Control Protocol (TCP) module would disable the TCP transport mechanism.

At the upper-edge of the 6LoWPAN stack, the Socket Application Programming Interface (API) is exposed (see Figure 1-2). This API is designed to provide a Berkeley Software Distribution (BSD) socket-like interface for the application to receive and transmit packets using standard IPv6 address and port number definitions. The function names also roughly follow the BSD socket definitions with some minor modifications due to the nature of the event environment. The intention is to clearly indicate to the developer that minute differences exist between the embedded socket interface and a full BSD socket interface.

Optional security components

The 6LoWPAN stack can be delivered with optional security components. These components provide strong security mechanisms that offer data authentication, device authentication and authorization, and data encryption. The stack supports the following standards:

  • PANA (requires EAP, TLS and SHA-256)
  • EAP (requires TLS and SHA-256)
  • TLS1.2 (requires SHA-256)
  • SHA-256
  • ECC (ECDSA and ECDHE) (requires X509.3)
  • X509.3 (requires ECC)

The Elliptic Curve Cryptography (ECC) component supports the EEC curve NIST-P256 as defined in the Smart Grid standards collection of the National Institute of Standards and Technology (NIST); see NIST. The stack also provides full x509.3 certificate support along with certificate chaining.

The stack essentially allows the end device to be a part of a full Public Key Infrastructure (PKI) security scheme.

Note: The 6LoWPAN stack is dependent of the Advanced Encryption Standard (AES)-Counter Mode Cipher* (CCM*) component that is part of the core stack.

Application modules

The 6LoWPAN stack runs on a lightweight event-based system that allows low power consumption and minimal latency. Application logic is implemented in a specific event handler called tasklet. The 6LoWPAN stack allows the developer to define multiple tasklets to ease the task of application design. Each of these tasklets can then have full access to the network stack and its features. The system relies on events and does not attempt to provide real multi-thread services, so the developer does not need to be concerned about multiple access to resources.

One of the most important aspects of an application tasklet design is for the developer to understand how the event environment impacts it. The system does not support the capability for a multi-thread environment.

The application tasklet must be designed so that it cannot block the execution for an extended period of time. A simple design rule is that a tasklet needs to be implemented in a state machine fashion. The tasklet receives an event that it processes, performs an action, such as reading a sensor value, builds a packet and transmits it, sets up a new timed event, and eventually returns. When the tasklet returns, the event core system schedules the networking stack to take care of the actual transmission of the packet. The delay between the actual transmission of the packet and the socket_sendto( ) function at the application layer depends on the overall loading of the device at that time. In an otherwise idle situation, the delay is subject to the performance of the processor, but is typically negligible.

Figure 1-3 shows the various protocol modules that make up the 6LoWPAN stack, which are placed alongside the Open Systems Interconnect (OSI) model.

Figure 1-3 The 6LoWPAN stack placed alongside the OSI model

osi

The related standards supported by the stack are:

  • 6LoWPAN:
    • RFC4944.
    • RFC6282.
    • RFC6775.
  • IPv6:
    • RFC2460.
    • RFC2464.
    • RFC3168 (parts).
    • RFC4291 (parts).
    • RFC6040.
    • RFC6437.
    • RFC6946.
  • UDP:
    • RFC768.
  • TCP:
    • RFC793 (parts).
  • RPL:
    • RFC6550.
    • RFC6552.
    • RFC6553.
    • RFC6554.
    • RFC6719.
    • RFC2473 (parts).
  • ICMPv6:
    • RFC4443 (parts).
    • RFC4861 (parts).
    • RFC4862 (parts).
  • MLE:
    • IETF draft-kelsey-intarea-mesh-link-establishment-06.
    • IEEE802.15.4.
    • IEEE802.15.4-2006 (certified).
    • IEEE802.15.4g (parts).
  • MPL:
    • IETF draft-ietf-roll-trickle-mcast-12 (parts).
  • AES:
    • FIPS 197.
    • SP 800-38C.
  • PANA:
    • RFC5191.
    • RFC6345.
    • RFC6786.
  • EAP:
    • RFC3748.
    • RFC5216.
  • TLS:
    • RFC4279.
    • RFC5216.
    • RFC5246.
    • RFC6655.
    • IETF draft-mcgrew-tls-aes-ccm-ecc-05.
  • ECC:
    • RFC4492.
    • RFC5289.
    • IETF draft-mcgrew-tls-aes-ccm-ecc-05.

Interfaces

The 6LoWPAN stack offers application developers programming interfaces for configuring the 6LoWPAN network, defining security levels and sending and receiving packets. The 6LoWPAN stack requires the developers to provide functions for platform specific tasks and network drivers for physical layer. For more information on programming interfaces, see Mbed Mesh API.

Operation modes

In 6LoWPAN network, the following roles are described in RFCs:

6LoWPAN Node (6LN)
A 6LoWPAN Node is any host or router participating in a network. This term is used when referring to situations in which either a host or router can play the role described.
6LoWPAN Router (6LR)
A node that can route packets. This role is required to form a topological or mesh network.
6LoWPAN Border Router (6LBR)
A border router located in between a 6LoWPAN network and IPv6 network. A 6LBR is the responsible authority for IPv6 Prefix propagation for the 6LoWPAN network it is serving.

A device running a 6LoWPAN stack can be configured in runtime to be in one of the following three modes:

  • Router:
    • Is effectively a 6LoWPAN Router (6LR).
    • Routes packets to and from other devices in the network.
    • Typically always-on, that is, radio always on.
    • Stack automatically reduces power consumption by placing the processor into sleep when in idle, so that no packets are routed or processed.
  • Host:
    • Is a 6LoWPAN node (6LN) with no routing capability.
    • Does not route packets to and from other devices in the network.
    • Typically RF always on.
    • Can sleep, but parent router does not cache packets destined to this device.
  • Sleepy host:
    • Is a 6LoWPAN node (6LN) with no routing capability and utilizes prolonged sleep periods.
    • Does not route packets to and from other devices in the network.
    • Typically in sleep for prolonged time periods.
    • Duty cycle often less than 1%.
    • Wakes up due to timer trigger or external interrupt, performs some action, polls for data from parent router and goes back to sleep.
    • An MLE protocol or alternative is required.
    • May shut down the radio when sleeping.

Networking

This chapter discusses the networking topology and the protocols used.

Networking topology

The 6LoWPAN stack uses two types of networking topology, namely the star and tree topologies, as shown in Figure 1-5.

Figure 1-5 Networking topologies supported by the 6LoWPAN stack ecosystem

nw-topologies

MAC

The Media Access Control (MAC) implementation is based on the IEEE802.15.4-2006 standard (see [MAC]) and is used for MAC layer communication between nodes such as beacon scans and responses, and data requests and indications. The MAC implementation has already been certified on multiple platforms.

The MAC implements the non-beacon enabled modes of the standard. It does not implement Guaranteed Time Slot (GTS).

UDP

The 6LoWPAN stack supports the UDP transport protocol. Applications can use the Socket API to send and receive data using UDP sockets. UDP is typically used by applications to deliver short messages over IP. It is an unreliable, connectionless protocol, but can be used for broadcast and multicast messages. The advantage of UDP is that it does not require any kind of connection formation or handshake process to take place prior to communication. UDP is the classic fire-and-forget transport mechanism that combines inherent low reliability, requiring minimal overhead.

A disadvantage of UDP can easily be mitigated by using a simple application layer, end-to-end acknowledgment scheme. As an efficient and scalable example of such a solution, see the Constrained Application Protocol(CoAP) Acknowledgement (ACK) mechanism as defined in CoAP.

TCP

The 6LoWPAN stack supports the Transmission Control Protocol (TCP) and applications can use the socket interface APIs of the stack to send and receive data using TCP sockets. Applications requiring a reliable, ordered transport for a stream of bytes can typically use TCP. However, TCP is not suitable for every application because it only supports unicast communication and reacts badly to packet loss. TCP is not suitable for very short transactions because the ratio of overhead to application data typically increases fairly quickly. Additionally, the use of TCP can have very adverse effects on the power consumption of a device because of the duration of the TCP handshake process.

RPL routing

Routing Protocol for Low power and Lossy networks (RPL) is a distance vector IPv6 routing protocol defined in the Internet Engineering Task Force (IETF) for low power and lossy networks that specifies how to build a Destination Oriented Directed Acyclic Graph (DODAG) using an objective function and a set of metrics and constraints. RPL is optimized for a many-to-one topology. Neighbors keep route records of the edge router as a final destination. The reverse route, or source route, is kept by the edge router and is used for sending data to any node in the network it has a route for. When a node sends a packet to another node, the packet travels up to a common ancestor in the DAG, at which point it is forwarded in the down direction to the destination.

Network join process

The developer has full control as to when the 6LoWPAN stack attempts to join a network. The developer has the possibility to configure a channel, Personal Area Network Identifier (PANID) and 128-bit Network Identifier (NWKID) masks to filter out both unwanted channels or networks. With a few simple function calls the developer can inform the stack to initiate either a passive energy scan or a beacon scan to select channels. Network PANIDs and NWKIDs will be filtered and non-matching networks will be silently discarded. The stack will then proceed to perform the network level bootstrapping according to 6LOWPAN-ND. When the stack joins a network or no network is found, the developer is notified using a standard system event. If the stack has not joined a network, the developer has the option to 1) select alternative parameters; 2) cease further attempts to join a network or 3) continue to retry the joining process. The stack will make no attempt to join a network when it informs the application layer of an unsuccessful attempt. However, the stack may choose to retry using the initial parameters.

Figure 1-6 High level view of the network bootstrap process when using network authentication

high-level

Join a 6LoWPAN network

The initial process of joining a network involves a MAC level association where the node will perform a MAC beacon scan using the channels in its channel list. The resulting beacon will ignore responses from neighboring nodes using the beacon protocol ID filter where the node will associate with the best parent router in the network, typically the highest Link Quality Indicator (LQI) that has a matching PANID. The node will then perform a Mesh Link Establishment (MLE) request to the parent router, as well as other routers that have responded to the initial beacon scan. If the chosen router did not respond to the MLE request, the node will select a new router from the beacon scan results.

Subsequently, a node in a 6LoWPAN mesh network initiates the 6LoWPAN Neighbor Discovery (6LoWPAN-ND) process. The neighbor discovery protocol handles address assignment including Duplicate Address Detection (DAD) and registration with the edge router. The edge router keeps a whiteboard of all nodes that have joined the 6LoWPAN network. In a 6LoWPAN mesh, the registration process is repeated over multiple hops for routers or host devices that are not adjacent to the edge router. The RPL is only for the router.

The last step, excluding anything above the RPL modules, is the RPL topology formation. The RPL DODAG formation is a multiphase process where the joining node actively attempts to find the best available parent to use for registration to the 6LoWPAN border router (6LBR).

Figure 1-7 shows the 6LoWPAN Node (6LN) join process to a 6LBR using a 6LoWPAN Router (6LR) in a mesh topology configuration. In the illustration, the vertical axis represents time. The 6LN will typically receive multiple Router Advertisement (RA) messages.

Figure 1-7 The join process for a mesh topology

join-mesh

Figure 1-8 High level state machine description for network bootstrap

state-machine

Figure 1-9 shows the RPL layer registration and topology formation process message flow for a scenario where the joining node may use multiple hops from the 6LBR.

Note: The joining device can receive multiple DIO messages.

Figure 1-9 RPL routing layer message flow for multiple hops

rpl-multiple

Figure 1-10 High level view of a mesh topology

rpl-high-level

Join a star network

The joining process for a node in a 6LoWPAN star network uses the same process as mentioned in Join a 6LoWPAN network. However, a star network differs insofar as the registration process is only undertaken as a one-hop sequence with the edge router.

Figure 1-11 shows the Wireless Personal Area Network (WPAN) node (6LN) join process to a 6LBR in a star topology configuration. In the illustration, the vertical axis represents time.

Note: Typically the 6LN will receive multiple RA messages.

Figure 1-11 6LoWPAN join process to a border router

join-star

Figure 1-12_ shows the RPL layer registration and topology formation process message sequence for a scenario where the joining node is a single hop from the 6LBR.

Note: The joining device can receive multiple DIO messages.

Figure 1-12 The RPL layer registration formation process

rpl-single

Network rejoin process

If a device with the 6LoWPAN stack is forced into sleep mode for an extended period of time so that its registration with the 6LBR has expired, the stack will automatically detect this and update its registration. The stack is then ready for communication without any further action from the application when the device wakes up.

The exact time that it takes for the stack to refresh the registration depends on whether a full mesh network topology or a star topology is used. Additionally, in the mesh network scenario the exact location of the device (depth from the 6LBR to be specific) in the mesh has a small impact on the time when full networking capabilities are restored.

Automatic network healing process

It is fairly common for the RF channel to change even if the physical location of the actual mesh network has not. The network must then adapt to the new channel immediately and with ease.

The standards that the 6LoWPAN stack uses provide feedback from multiple protocol layers, such as the MAC, network and routing layers. This multiple layer approach provides the stack with numerous sources of information that can be used to make automatic decisions as to when network reconfiguration can be initiated. It can also be delivered to other devices in the IP network using standard Internet Control Message Protocol (ICMP)v6 messages. More specifically, these messages can either be ICMPv6 Destination Unreachable or No Route To Host types.

MAC layer

When repeated notifications of layer two (L2) ACKs are not passed up to the higher layers, a possible lost connection has occurred. If the ACK messages are lost from a parent device in the routing topology, this results in one of the following actions: 1) switch to a secondary parent, that is, an alternative parent that has been stored for backup; or 2) the stack should initiate a local network reconfiguration.

If the L2 ACKs are missing from a child node, the routing node typically transmits an ICMPv6 error message to the originator of the packet. If an application on the device itself is the originator, the application is notified of the error using a system event.

Network layer

If the MAC layer informs layer three (L3) of a connectivity issue toward the parent network, it becomes the responsibility of L3 to reconfigure the network. This is achieved simply by transmitting multicast Router Solicitation (RS) messages using the configured channel in an attempt to find an alternative parent. Since 6LR and 6LBR devices that have already joined the RPL DODAG reply to RS messages with RA messages, the scanning device can be certain that all replies come from devices that are capable of routing packets. This step essentially ensures that the device can join a new network if the 6LBR, of the previously used network, has become unusable. It is important to understand that the 6LoWPAN-ND process is not used to form the network topology, but merely to establish the IPv6 prefix context information and the identities of the available (direct or multihop) 6LBR devices.

Routing layer

If the device has made the decision to perform local reconfiguration and has updated the 6LoWPAN network information using the 6LoWPAN-ND process, the next step is to (re-)join the RPL DODAG. To achieve this, the device will follow the standard RPL network join process as described in Join a 6LoWPAN network.

Important Information for this Arm website

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies. If you are not happy with the use of these cookies, please review our Cookie Policy to learn how they can be disabled. By disabling cookies, some features of the site will not work.