Suggested intervals and windows

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

Therefore eight link timing-events can complete in maximum ∑t_EEO-Cx,which is around 17.5 ms for LOW bandwidth configuration Refer 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 ∑t_EEO-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 17.5 ms , for 3 connections with MID bandwidth it is 12.5 ms. In case of of using 17.5 ms as the common factor, all connections would have an interval of 17.5 ms or a multiple of 17.5 ms like 35 ms, 53.5 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 ∑t_EEO-Cx plus the scanWindow plus t_ScanReserved. Note that the inititator 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 45 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:

• All central role intervals (i.e. connection interval, scanner/observer/initiator intervals) should have a common factor. This common factor should be ≥ ∑t_EEO-Cx + scanWindow + t_ScanReserved.

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:

• Interval of all roles have a common factor which is ≥ ∑t_EEO-Cx + (t_ScanReserved + ScanWindow) + t_{SlaveEventNominal} + t_AdvEventMax

  Important: t_{SlaveEventNominal} can be used in above equation in most cases, but should be replaced by t_{SlaveEventMax} for cases where links as a peripheral can have worst sleep clock accuracy and longer connection interval.

• Broadcaster and Advertiser roles also follow the constraint of interval which can be factored by the smallest connection interval.

  Important: Directed advertiser is not considered here because that is not a periodic event.

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 t_event for the broadcaster are approximately equal to t_EEO. Figure 1 shows this case of collision.

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.

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.