Suggested intervals and windows

The time required to fit one timing-event of all active central links is equal to the sum of tEEO of all active central links.

Therefore, eight link timing-events can complete in maximum ∑tEEO-Cx, which is around 15 ms for 27 byte maximum packet payload and LOW bandwidth configuration. Refer to Table 1 and Table 2 for timing ranges in central role.

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 eight). 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 or equal to ∑tEEO-Cx. Note that this sum depends on number of connections and their respective bandwidth. In the case of eight connections with LOW bandwidth it is 15 ms, for three connections with MID bandwidth it is 11.25 ms (assuming maximum packet payload of 27 bytes). In case of using 15 ms as the common factor, all connections would have an interval of 15 ms or a multiple of 15 ms like 30 ms, 45 ms, etc.

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 ∑tEEO-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.

As an example, setting the connection interval to 43.75 ms will allow three connection events with MID bandwidth 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.

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. 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 BLE role events are running and the above conditions are met, the worst case collision scenario will be Broadcaster, connection as a Peripheral, Initiator and one or more connection 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 tEEO. Figure 1 shows this case of collision.

Figure 1. Worst case collision of BLE 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.

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 BLE 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 it is 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 3 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.

Documentation feedback | Developer Zone | Subscribe | Updated 2016-12-09