apache / apache/mynewt-nimble

controller: timing error and processing time consideration in `ble_ll_conn_can_send_next_pdu()`

Open
#1,808 4 comments 0 reactions 0 assignees View on GitHub
Dominant language
C
Stars
893
Forks
512
Avg merge
13d 31m
Merged PRs (30d)
7

Description

Hi ~
The function `ble_ll_conn_can_send_next_pdu()` in `ble_ll_conn.c` is used by the Central to decide wether to reply the Peripheral so that the Peripheral can send more data packets.
Since the Central does not know how many data needs to be transmitted, it always assume the Peripheral to send a maximum length data.
I am using a older version of NimBLE and the time of the maximum length is `connsm->eff_max_rx_time` is 2120 us.
Since we do not use the MIC field, we modified it to 2088 us to fully utilize the connection event.
It seems that `connsm->ota_max_rx_time` in the lastest version already remove the MIC field.

However, because of the timing error and the processing time, the Central may miss the reply packet from the Peripheral.
Specifically, if the end transmission time of the Peripheral reply is very close to the start time of the connection event, the reply packet will not be processed even it has been received.
For example, in our experiment, the `ticks` in `ble_ll_conn.c` Line 1698 is `150` (i.e., 4577 us).
`usec` is 2468 us, including an empty PDU, a full PDU without MIC (2088us), IFS, and MSS.
The `added_usec` is 2106 us.
Therefore, **the next event start is only 3 us after the reply packet transmission**.
Because of the timing error and the processing time, the reply can not be fully processed before the start of the next event.
The Peripheral has to retransmit the reply in the next connection event.

The most straigeforward way is adding a redundancy time considering the timing error and processing time.
If we still set the `connsm->eff_max_rx_time` to 2120 us, the Centeral choose not to transmit an extra empty packet since the Peripheral does not uses the MIC field, it acutall brings 32 us redundancy time.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start in ble_ll_conn.c at ble_ll_conn_can_send_next_pdu(), especially the timing calculation around line 1698. Compare ticks, usec, and added_usec with the reported connection-event boundary, then verify that timing error and processing time leave enough margin so a received reply is processed without requiring retransmission.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
embedded-iot
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.