It is flow control using a credit based scheme for L2CAP data.
A credit based scheme is a scheme where the credit count determines the number of packets a device can receive.
In LE Credit Based Flow Control Mode the SDU can be split into LE-frames. The credit count determines the number of LE-frames a device can receive.
In your SoftDevice each LE-frame can have a payload of 27 octets. So when the SDU is bigger than this it is fragmented into LE-frames and sent to the peer device. But before the LE-frame is sent, it needs to know if the peer device can receive it. So the flow of LE-frames needs to be controlled.
Upon connection it tells the peer device that is has a credit count of x. Every time the peer device sends a packet it decreases the credit count by 1. If the count reaches 0 it shouldn't send any more packets. When y number of LE-frames can be reassembled into an SDU, and sent to a higher layer, it tells the peer device to increase the credit count with y.
If you want more detail I suggest you examine Vol. 3, Part A Section 3.4, 4.22, 4.23, 4.24 and 10.1 in the Bluetooth Core Specification 4.2.
In my set up I have a Raspberry Pi and nrf42840 communicating over IPSP. The nrf sends data to the Raspberry. How to make sure the Raspberry gives sufficient credits to the nrf in order to achieve high throughputs?
In my set up I have a Raspberry Pi and nrf42840 communicating over IPSP. The nrf sends data to the Raspberry. How to make sure the Raspberry gives sufficient credits to the nrf in order to achieve high throughputs?
