Mistake on this page?
Report an issue in GitHub or email us


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

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 colors in the illustrations represent different device types and are used in the examples throughout this section.

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 to the limited address space. We recommend using IPv6 tunnels over an IPv4 network when operating in such an 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 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 can 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.

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. Consider the data rate available per node when designing the application. Basically, the data rate is divided between all nodes in the network. Allocate roughly half of the channel capacity for signalling purposes. Each hop requires retransmisson of the packet.


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

File system

Thread network stack can write network configuration settings to the file system and read them in the following startup. The size of the Thread configuration settings is a few thousand bytes. You can store network configuration settings to the file system when:

  1. You enable the file system as instructed in the Mbed OS storage documentation.
  2. You set the file system root path to the Thread network stack by calling the function ns_file_system_set_root_path(root-path). Do this before starting the Thread stack to read possible configuration settings in the first power up.

Depending on the selected file system, the application may need to format the file system before you can use it.


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


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 Pelion Device Management. 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


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


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


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.


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.


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



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).


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.


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


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


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


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


Figure 1-10 High level view of a mesh topology


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


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


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.