Protocol multiplexer
Max PDU payload
= 1 LE-frame
IPv6 over BLE
Continuing Section 10.8.2 — Connection Parameter Update
The previous file (PDF 2123) introduced the Connection Parameter Update Request — the four parameters a Slave sends to ask the Master for different connection timing. This file covers the Master’s response, the full update sequence in Figure 10.6, and then moves into the BLE 4.1 credit-based signaling commands and the credit-based flow control mechanism in Section 10.9.
10.8.2 — Connection Parameter Update Request (Parameters)
When the Slave sends a Connection Parameter Update Request over CID 0x0005, it includes four timing values that it would like the Master to adopt:
The minimum connection event interval the Slave is requesting. The Master must choose a value at least this large. If it cannot meet even this minimum, it will reject the request entirely. Expressed in 1.25 ms units — so a value of 80 means 100 ms.
The maximum connection event interval the Slave will accept. The Master picks any value between Interval Min and Interval Max. If it cannot fit within this range, it rejects the request.
The number of consecutive connection events the Slave would like to be allowed to skip. If Slave Latency is 4, the Slave only needs to wake up and listen every 4th connection event. If it is 0, the Slave must listen at every event. Higher latency saves battery on the Slave at the cost of higher data latency.
Used to calculate the supervision timeout using the formula: Connection Supervision Timeout = Timeout Multiplier × 10 ms. If no packet is received for this long, both devices declare the connection lost independently. A larger timeout is more tolerant of temporary signal loss.
Important direction rule: This command can only be sent from the LE Slave to the LE Master — never the other way around. If the Master wants to change connection parameters, it does not use this L2CAP command. Instead it uses the Link Layer procedure directly via HCI_LE_Connection_Update.
10.8.3 — Connection Parameter Update Response
When the Master receives the Connection Parameter Update Request from the Slave, it evaluates the proposed parameters against its own scheduling constraints (it may be managing other connections, or the proposed interval may not suit the application). It then sends a Connection Parameter Update Response (Code 0x13) back to the Slave on the L2CAP signaling channel.
The response contains a single Result field with two possible values:
0x0000 — Connection Parameters Accepted
The Master accepts the proposed parameters. It then sends HCI_LE_Connection_Update down to its controller so the link layer starts the update procedure.
0x0001 — Connection Parameters Rejected
The Master cannot accommodate the Slave’s requested range. The existing parameters remain in effect and the Slave must live with them or try again later.
When the Master accepts, it does not apply the new parameters immediately — doing so would desynchronise the two sides. Instead it sends the update down to the controller using HCI_LE_Connection_Update, which triggers the link layer LL_CONNECTION_UPDATE_REQ procedure. Both devices switch to the new parameters simultaneously at a future connection event defined by the Instant field in the link layer command.
/* Watching a connection parameter update with btmon */
/* sudo btmon | grep -A 10 "LE L2CAP Signaling" */
/* L2CAP Connection Parameter Update Request (Slave → Master) */
/* > HCI Event: LE L2CAP Signaling: Connection Parameter Update Request
/* Identifier: 0x01
/* Min interval: 80 (100ms)
/* Max interval: 160 (200ms)
/* Latency: 0
/* Timeout: 500 (5s)
/* Master accepts and sends HCI_LE_Connection_Update: */
/* < HCI Command: LE Connection Update (0x08|0x0013) */
/* Handle: 64
/* Min interval: 0x0050 (100ms)
/* Max interval: 0x0050 (100ms)
/* Latency: 0
/* Supervision timeout: 0x01F4 (5000ms) */10.8.4 — LE Credit-Based Connection Request (BLE 4.1)
Unlike the fixed channels (ATT on CID 0x0004, SMP on CID 0x0006) which exist automatically the moment a connection is established, a credit-based channel must be explicitly created. The LE Credit-Based Connection Request (Code 0x14) is sent by the device that wants to open the new channel.
This command was introduced in BLE 4.1 to support the Internet Protocol Support Profile (IPSP), which lets BLE devices communicate over IPv6 by creating a connection-oriented L2CAP channel between a BLE node and a border router gateway. Without this mechanism, BLE devices could not carry variable-length IPv6 packets.
The request carries five parameters:
LE Protocol Service Multiplexer (PSM)
Identifies the higher-layer protocol that this channel is being created for. Comparable to a port number in TCP/IP — it tells the receiving device which protocol should handle the incoming data on this channel. PSM values are either fixed by the Bluetooth SIG (e.g. IPSP has a fixed PSM) or dynamically assigned by GATT for application-specific use.
Source CID
The channel identifier chosen by the sender. Once the channel is established, the remote device must send all packets destined for this channel to this CID. The value is selected from the dynamically allocated range 0x0040–0x007F.
Maximum Transmission Unit (MTU)
The maximum SDU size this device can accept on the new channel. This is an upper-layer limit — one complete application-level SDU can be up to MTU bytes. If a larger SDU needs to be sent it must be fragmented across multiple PDUs, each up to MPS bytes.
Maximum PDU Size (MPS)
The maximum payload size of a single LE-frame PDU that this device can accept. While MTU is about the total SDU size, MPS is about the size of each individual PDU fragment that carries pieces of that SDU. The receiver must never receive a PDU with a payload larger than its stated MPS.
Initial Credits
The number of LE-frames the remote device is permitted to send to this device immediately after the channel opens. One credit = permission to send one LE-frame. The remote device counts down from this number as it sends frames and can only send more when this device grants additional credits using the LE Flow Control Credit command.
10.8.5 — LE Credit-Based Connection Response (BLE 4.1)
The device that received the Connection Request sends back an LE Credit-Based Connection Response (Code 0x15). If accepted, the response also allocates credits in the opposite direction — the requester now knows how many LE-frames it can send to the responding device.
Five fields in the response:
Destination CID
The CID chosen by the responding device for its own endpoint of the channel. The requester uses this CID when sending data to the responder. Also from the 0x0040–0x007F dynamic range.
Maximum Transmission Unit
The responder’s maximum SDU size — the largest complete application packet the responder can accept.
Maximum PDU Size
The responder’s maximum PDU payload — the largest single LE-frame the responder can handle.
Initial Credits
Credits granted to the original requester. How many LE-frames the requester can send to the responder immediately after the channel opens.
Result
0x0000 = Connection successful. Other values indicate failure reasons (e.g. PSM not supported, no resources, security requirements not met).
PSM + Source CID + MTU + MPS + 10 initial credits
Dest CID + MTU + MPS + 11 initial credits + Result=0x0000
10.8.6 — LE Flow Control Credit (BLE 4.1)
After the initial credits are established during channel setup, those credits get consumed as LE-frames are sent. When one side has processed enough frames and has buffer space available again, it sends an LE Flow Control Credit (Code 0x16) to tell the other side it can send more.
This command is intentionally minimal — it carries only two fields:
CID
The Source Channel ID — identifies which channel endpoint the additional credits apply to. Only the credits for this specific channel are increased; other channels are not affected.
Credits
How many additional LE-frames the sender of this command is now willing to accept. The receiver adds this number to its current available credit count for this CID and can immediately start sending that many more frames.
Example: Device A opens a credit-based channel and grants 10 initial credits to Device B. Device B sends 5 LE-frames (credits now at 5). Device A finishes processing those 5 frames and has buffer space again. Device A sends an LE Flow Control Credit with CID=its channel endpoint and Credits=5. Device B now has 10 credits again and can continue sending.
10.9 — Credit-Based Flow Control
BLE 4.1 introduced connection-oriented channels with credit-based flow control. This mechanism lets the receiver control how fast the transmitter sends data — the transmitter can only send when it has credits, and credits are issued only by the receiver when it is actually ready to accept more data.
The credit mechanism works as follows. These rules apply independently in each direction — each side has its own credit counter for sending:
A naive flow control approach would be: send one packet, wait for the receiver to acknowledge it, then send the next one. This is simple but wasteful — the transmitter is idle for the entire round-trip time waiting for the ACK.
Credit-based flow control is better because the transmitter does not need to wait. If the receiver provides 10 initial credits, the transmitter can immediately send 10 frames back-to-back without pausing. While those 10 frames are in flight (or being processed by the receiver), the transmitter may receive new credits and queue up the next batch. This keeps the radio utilisation high and minimises dead time.
A smartphone sending data to a memory-constrained sensor. The sensor issues only a few credits at a time, keeping the phone from flooding its small buffer. The phone sends at the rate the sensor can process — no data loss, no buffer overflow.
A host with plenty of RAM issues many credits upfront. The remote device sends a large burst of data quickly before the credits run out, then waits for a credit refill. This pattern is efficient for bulk transfers like firmware updates or log uploads.
IPSP usage: The LE connection-oriented channels with credit-based flow control are the foundation of the Internet Protocol Support Profile (IPSP). IPSP lets BLE devices connect to the internet through a border router gateway using IPv6. The IPv6 packets are carried as SDUs over credit-based L2CAP channels — the gateway issues credits to control how fast the BLE device pushes data. Chapter 15 will cover IPSP in full detail.
/* Credit-based L2CAP channel with BlueZ using L2CAP socket */
#include <bluetooth/bluetooth.h>
#include <bluetooth/l2cap.h>
/* Open a LE credit-based connection-oriented channel */
int sock = socket(PF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_L2CAP);
struct sockaddr_l2 addr = {
.l2_family = AF_BLUETOOTH,
.l2_cid = htobs(0x0040), /* dynamic CID */
.l2_psm = htobs(0x0023), /* IPSP PSM value */
.l2_bdaddr_type = BDADDR_LE_PUBLIC,
};
str2ba("AA:BB:CC:DD:EE:FF", &addr.l2_bdaddr);
/* Set MTU and MPS via socket options before connect */
struct bt_power pwr = { .force_active = 0 };
setsockopt(sock, SOL_BLUETOOTH, BT_POWER, &pwr, sizeof(pwr));
connect(sock, (struct sockaddr *)&addr, sizeof(addr));
/* L2CAP sends LE Credit-Based Connection Request with PSM */
/* After connect() returns, channel is established */Next — Practical Sniffer Examples & Chapter 10 Summary
PDF 2729 closes Chapter 10 with real sniffer captures showing L2CAP PDUs in action and the chapter summary.