nRF5 SDK v14.1.0
6LoWPAN over BLE

Table of Contents

This information applies to the following SoftDevice: S132

The BLE 6LoWPAN library implements the 6lo (IPv6) over BLE (Bluetooth low energy) adaptation layer functionality defined in the IETF RFC 7668. The location of the 6LoWPAN layer is shown in Figure 1 below. This layer contains IPSP, which communicate directly with the SoftDevice, and manages traffic on the transport layer (L2CAP Channel).

6lowpan_arch.png
Figure 1. BLE_6LOWPAN localization in the nRF5x layer structure.

The main responsibilities of the 6LoWPAN module are:

This module does not contain the following functionality:

Internally, the module can be visualized to be consisting of three sub-layers as shown in Figure 2:

6lowpan_arch_internal.png
Figure 1. BLE 6LoWPAN internal logical layer structure.

6LoWPAN interface

To distinguish the connections from different BLE devices (on Master), concept of interfaces is created (iot_interface_t). Each interface is of the Point-to-Point type and is a logical representation of the L2CAP CoC connection, which contains several parameters:

Each of the 6LoWPAN interfaces can be enumerated as a point-to-point network interface with the IP stack.

API functions

Initialization/setup procedure

Before the module can be used, an initialization via the ble_6lowpan_init function is mandatory. The function takes two parameters:

Send procedure

The ble_6lowpan_interface_send function allows the application to send IPv6 packets. The size of the packets should be at least 40 bytes to contain the IPv6 header. This API expects the packet to be an entire IPv6 packet without any compression performed on it. Compression is done by the module.

Sometimes the transport channel cannot send the packet immediately, and then the packet is queued to be transmitted later. In case of overflowing the transmit queue, the BLE_6LOWPAN_TX_FIFO_FULL return value is used.

This API expects that the buffer used to transmit the packet is an allocated one, and it frees the packet once the transmission is complete. This is done to ensure that there is no need to copy the data in each module.

Is it also possible to speed up the stateful compression procedure by setting the tx_contexts on the IoT interface. It stops any additional address compression for the 64-bit prefix.

Asynchronous Event Notification Callback

6LoWPAN notifies the application of the following asynchronous events by using the callback registered with it at the initialization:

Event Description
BLE_6LO_EVT_ERROR When an error occurs in the module.
BLE_6LO_EVT_INTERFACE_ADD When a new interface is available for IPv6 exchange.
BLE_6LO_EVT_INTERFACE_DELETE When an interface is no longer available for IPv6 exchange.
BLE_6LO_EVT_INTERFACE_DATA_RX When IP traffic is received on the interface.

The interface for which an event is notified is identified by using the interface identification in the callback. Each event is also accompanied with an event result to provide any additional status information. For example, an IP packet could not be successfully decompressed,and this is notified to the IP stack using the event result for BLE_6LO_EVT_INTERFACE_DATA_RX. Event parameters contain related parameters (if any).

In case stateful compression is used and no context table or context identifier is found, then BLE_6LO_EVT_INTERFACE_DATA_RX with the result BLE_6LOWPAN_CID_NOT_FOUND is generated. The stack is then responsible for taking a decision about the decompression source and the destination addresses. Used contexts are always attached to the event parameters.

It is a good idea to refer to the MSC to better understand 6LoWPAN events and the application interface with respect to the IPSP and the IPv6 stack.


Documentation feedback | Developer Zone | Subscribe | Updated