 |
nRF51 IoT SDK
|
|
nRF51 IoT SDK
|
See Figure 1 below for a description on the interaction between each of the layers for any IPv6 stack.
RX Path
The IoT SoftDevice is provided with receive buffers when accepting the L2CAP channel connection request in the IPSP module. A single contiguous memory buffer of size (Receive_MTU * N) is provided. N = [1, MAX]. N is determined by application needs for the use case. N is set to 3 by default because the IPv6 neighbor discovery starts right after the connection is established, during which the router sends three packets in quick succession.
When a complete SDU is received on the L2CAP channel, the IPSP is notified of the received packet. The receive buffer is available as long it is not resubmitted to the IoT SoftDevice. However, be aware that holding on to this buffer for a very long time might lead to a situation where the L2CAP packets are dropped because the IoT SoftDevice is running out of buffers.
TX Path
The IoT SoftDevice does not make a copy of the L2CAP packet that is transmitted to the peer. Therefore, the transmit buffer provided to the IoT SoftDevice should not be reused or freed, unless it notifies BLE_IPSP_EVT_CHANNEL_DATA_TX_COMPLETE with the appropriate pointer to the transmit buffer.
RX Path
IPSP does not make a copy of the SDU sent to the application, instead it just notifies the BLE 6LoWPAN layer of BLE_IPSP_EVT_CHANNEL_DATA_RX along with the received packet and its length. As soon as the BLE 6LoWPAN notification callback returns, the receive buffer is resubmitted back to the IoT SoftDevice. Therefore, it is the BLE 6LoWPAN layer that needs to make a copy of the received packet that is forwarded upstream.
TX Path
IPSP does not make a copy of the packet requested to be transmitted by the BLE 6LoWPAN layer, and will simply forward the request to the IoT SoftDevice. Once a BLE_EVT_TX_COMPLETE is notified by the IoT SoftDevice, the BLE 6LoWPAN layer is notified of BLE_IPSP_EVT_CHANNEL_DATA_TX_COMPLETE.
RX Path
A copy of the received packet is made and necessary decompression is applied to create an IPv6 packet. The copy is made on a buffer allocation request from the Memory Manager module. The memory allocated for the received packet is available to the consumer of the packet. The consumer of the IPv6 packet could be the application, the IPv6 stack, or the IPv6 stack driver, based on the packet and memory management within the embedded IPv6 stack.
TX Path
No copy of the IPv6 packet is made. Instead, the buffer is reused by overwriting it with the compressed packet. Once the IPSP module notifies the 6LoWPAN module of the BLE_IPSP_EVT_CHANNEL_DATA_TX_COMPLETE event that the packet transfer is complete, the memory buffer is freed for the Memory Manager.
The BLE 6LoWPAN module maintains a queue of the packets that is to be transferred to the peer, as it is not necessary that the packets are transferred immediately.
RX Path
The IPv6 stack driver is the module that is expected to have the knowledge of the memory management of both the IPv6 stack and the BLE 6LoWPAN layer. Therefore, in the receive path, a copy of the packet is made in case the IPv6 stack implements a memory management of its own and cannot be configured to use the Memory Manager provided for nRF51.
If a copy of the packet is made, the driver shall free the buffer provided by the BLE 6LoWPAN module.
TX Path
Because the driver module has no knowledge of whether the IPv6 stack uses the nRF51 Memory Manager or not, it is expected to allocate a buffer with the Memory Manager and make a copy of the IPv6 packet before sending it to the BLE 6LoWPAN module.
If a copy of the IPv6 packet is made, the driver shall free or resubmit the IPv6 stack buffer.
RX & TX Path
If the IPv6 stack is configured to use the nRF51 Memory Manager, and the stack memory management functions are mapped to the nRF51 Memory Manager API, freeing of the received buffer will result in the buffer being returned to the pool. This is the ideal configuration as it involves no copy of data from the BLE 6LoWPAN layer to the IPv6 stack.
However, in case the stack is not or cannot be configured to use the nRF51 Memory Manager, memory management of the received and transmitted packets is completely detached. Then the IPv6 stack driver will need to take the necessary actions to ensure smooth data flow upstream and downstream between the IPv6 stack and the BLE 6LoWPAN layer.
1.8.3.1 
