Suggested intervals and windows

The time required to fit one timing-event of all active central links is equal to the sum of tevent of all active central links. Therefore, 20 link timing-events can complete in ∑tevent-Cx, which is 50 ms for connections with a 2.5 ms event length.

Note that this does not leave sufficient time in the schedule for scanning or initiating new connections (when the number of connections already established is less than the maximum). Scanner, observer, and initiator events can therefore cause connection packets to be dropped.

It is recommended that all connections have intervals that have a common factor. This common factor should be greater than or equal to ∑tevent-Cx. For example, for eight connections with an event length of 2.5 ms, the lowest recommended connection interval is 20 ms. This means all connections would then have a connection interval of 20 ms or a multiple of 20 ms, such as 40 ms, 60 ms, and so on.

If short connection intervals are not essential to the application and there is a need to have a Scanner running at the same time as connections, then it is possible to avoid dropping packets on any connection as a Central by having a connection interval larger than ∑tevent-Cx plus the scanWindow plus tScanReserved. Note that the Initiator is scheduled asynchronously to any other role (and any other timing-activity), hence initiator timing-event might collide with other timing-events even if above recommendation is followed.

For example, setting the connection interval to 43.75 ms will allow three connection events with event length of 3.75 ms and a scan window of 31.0 ms, which is sufficient to ensure advertising packets from a 20 ms (nominal) advertiser hitting and being responded to within the window.

The event length should be used together with the connection interval to set the desired bandwidth of the connection. When both peripheral and central roles are running, it is recommended to use the event length to ensure a fair allocation of the available Radio time resources between the existing roles and then enable Connection Event Length Extension to improve the bandwidth if possible.

When long Link Layer Data Channel PDUs are in use, it is recommended to increase the event length of a connection. For example, Link Layer Data Channel PDUs are by default 27 bytes in size. With an event length of 3.75 ms, it is possible to send three full sized packet pairs on LE 1M PHY in one connection event. Therefore, when increasing the Link Layer Data Channel PDU size to 251 bytes, the event length should be increased to 15 ms. To calculate how much time should be added (in ms), use the following formula: ((size - 27) * 8 * 2 * pairs) / 1000.

To summarize, a recommended configuration for operation without dropped packets for cases of only central roles running is:

Peripheral roles use the same time space as all other roles (including any other peripheral and central roles). Hence, a collision-free schedule cannot be guaranteed if a peripheral role is running along with any other role. A recommended configuration for having less colliding Peripherals is to set a short event length and enable the Connection Event Length Extension in SoftDevice (refer to Connection timing with Connection Event Length Extension).

The probability of collision can be reduced (though not eliminated) if the central role link parameters are set as suggested in this section, and the following rules are applied for all roles:

If only Bluetooth® low energy role events are running and the above conditions are met, the worst-case collision scenario will be Broadcaster, one or more connections as Peripheral, Initiator, and one or more connections as Central colliding in time. The number of colliding connections as Central depends on the maximum timing-event length of other asynchronous timing-activities. For example, it will be two connections as Central if all connections have same bandwidth and both the initiator scan window and the tevent for the Broadcaster are approximately equal to tevent. Figure 1 shows this case of collision.

Figure 1. Worst-case collision of Bluetooth low energy roles

These collisions will result in collision resolution via priority mechanism. The worst-case collision will be reduced if any of the above roles are not running. For example, in the case of only connections as a Central and slave connection is running, in the worst case, each role will get a timing-event half the time because they both run with the same priority (Refer to Table 1). Figure 2 shows this case of collision.

Collision resolution may cause bad performance if suboptimal intervals are chosen. For example, a scanner that is configured with a scan interval of 2000 ms and a scan window of 1000 ms will collide with an advertiser with an advertising interval of 50 ms. In this case, the advertiser that schedules events often compared to the scanner will raise its priority and may cause the scanner to receive less radio time than expected.

Important: These are worst-case collision numbers, and an average case will most likely be better.
Figure 2. Three links running as a Central and one Peripheral

Timing-activities other than Bluetooth low energy role events, such as Flash access and Radio Timeslot API, also use the same time space as all other timing-activities. Hence, they will also add up to the worst-case collision scenario.

Packet drops might happen due to collision between different roles as explained above. Application should tolerate dropped packets by setting the supervision time-out for connections long enough to avoid loss of connection when packets are dropped. For example, in case when only three central connections and one peripheral connection are running, in the worst case, each role will get a timing-event half the time. To accommodate this packet drop, the application should set the supervision time-out to twice the size it would have set if only either central or peripheral role was running.