Packet loss during ISO transmission when advertising

Hi,

Bug:

With a connected ISO connection between two devices X and Y:

  • X acts as a peripheral. It's the ISO server and it is transmiting iso data to Y.
  • Y is multirole. It connects to X and establish an ISO connection to receive ISO data.

As long as Y only receives data, the communication is stable (no packet loss). As soon as Y advertises (bt_le_adv_start), Y does not receive all packets.

  • Increasing advertising interval, decrease packet loss.
  • Decreasing advertising interval, increase packet loss.

Environment:

  • OS: Linux
  • Toolchain zephyr-sdk-0.16.8
  • NRF5340DK
  • NCS 2.7 (sdk-nrf v2.7.0 and zephyr v3.6.99-ncs2)

How can solve this issue, which causes too many packet loss ?

Thank you

  • Hi,

    The numbers you are seeing make sense. The reason is that a legacy advertising event takes about 4.5 ms in our implementation (including time for a potential scan request and scan response). And an ISO event with 128 byte takes about 1 ms as you write, but including overhead it is 1.5 ms. So in this case, with an ISO packet every 10 ms, there likelyhood of a collision is above 50%, as you are seeing. In other words, what you are seeing is expected.

    You may want to consider increasing the retransmission coun and transport latency to better handle the packet loss.

  • Hi,

    I tried the following configuration:

    • retransmission: 1, latency: 30ms or 100ms: No change
    • retransmissions: 3, latency: 10ms: No change
    • retransmissions: 3, latency: 30ms: Reduce packet loss by factor 2.5 (so packet loss when advertising is ~25% instead of 65%)

    So, increasing retransmission and latency improve the situation however with my configuration I don't understand why we don't have 0 packet lost. If advertising takes 4.5ms, with retransmission set to 2 and latency set to 20ms, it should be enough to cover all collision with advertising. Isn't it ?


    Moreover I found few interesting thing in the Soft Device scheduling documentation (docs.nordicsemi.com/.../scheduling.html):

    In "BIS timing" (docs.nordicsemi.com/.../scheduling.html, there are few parameters that seems to transpose to CIS:

    • BT_CTLR_SDC_BIG_RESERVED_TIME_US: Equivalent of BT_CTLR_SDC_CIG_RESERVED_TIME_US for CIS
    • BT_CTLR_SDC_PERIODIC_ADV_EVENT_LEN_DEFAULT: Is it used by CIS ?

    In this section it is stated that "For optimal scheduling, the periodic advertising interval and ISO interval should have a common factor, and the sum of the periodic and extended advertising timing-event lengths should be less than the BIG reserved time".

    So, do you think we could reduce the impact of advertising by configuring these ?

    "CONFIG_BT_CTLR_SDC_PERIODIC_ADV_EVENT_LEN_DEFAULT: The time set aside for periodic advertising each periodic advertising interval in microseconds. The event length is the primary parameter for how much data can be transmitted by the periodic advertiser without scheduling conflicts occurring.".
    My understanding is that we can reduce scheduling conflict (advertising) using this parameter. If so, which value should we use ? If not, I'm not sure to understand what this value does, could you provide me with more insight ?


    Thanks

  • Hi,

    thomas_hexploy said:
    increasing retransmission and latency improve the situation however with my configuration

    That is good.

    thomas_hexploy said:
    If advertising takes 4.5ms, with retransmission set to 2 and latency set to 20ms, it should be enough to cover all collision with advertising. Isn't it ?

    In principle, yes. However, legacy advertising packets have a random offset of 0-10 ms per the Bluetooth sepcification, so you cannot schedule it exactly where it would fit in between the ISO packets.

    thomas_hexploy said:

    In this section it is stated that "For optimal scheduling, the periodic advertising interval and ISO interval should have a common factor, and the sum of the periodic and extended advertising timing-event lengths should be less than the BIG reserved time".

    So, do you think we could reduce the impact of advertising by configuring these ?

    This applies to periodic avertising only, but as that was not mentioned before I assumed you are using only legacy (normal) advertising. If that is the case(?), this is not relevant.

  • Hello,

    Thank you for your response. However, there are two points I'd like to clarify:

    I don't quite understand why these 10ms would cause a collision. From my perspective, this is only a delay and should not interfere with transmission or reception. If we consider the minimum advertising interval allowed by the specification, which is 20ms, this would imply that up to 33% (10ms random delay divided by 30ms, which is the total advertising duration, 20ms + random delay) of the bandwidth might be unavailable. Therefore, in my understanding, this delay should not cause collision with any reception or transmission.(I used the information provided in "Legacy advertising" section of https://www.bluetooth.com/blog/periodic-advertising-sync-transfer/)

    How is this implemented in the SoftDevice ? Can you confirm that the ~10ms delay is blocking any transmission/reception ?

    Even if we treat the 10ms delay as part of the advertising, it would suggest that advertising takes 14.5ms, which is still under 20ms (the time between 3 retransmissions). So, I don’t understand how a packet could be lost with 3 retransmissions and a 40ms latency (as I tested). The following diagram illustrates my perspective (I simplified it, focusing on lost packet):


    Could you please point out where I might be mistaken?

    Thank you.

  • thomas_hexploy said:
    How is this implemented in the SoftDevice ? Can you confirm that the ~10ms delay is blocking any transmission/reception ?

    No, it is not. Advertising blocks for about 4.5ms per advertising event. But due to the random offset this is not consistent so you cannot schedule the advertising events to always be between other activity. And the ISO transmissions happen at a fixed interval. So as you have one fixed interval (ISO) and one gliding and varying interval (advertising) whese will collide from time to time in a non-deterministic way.

Related