This section provides recommendations for choosing intervals and windows for connection and scanning on LE 1M PHY unless specified otherwise.
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.
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 + scanWindow. The Initiator is scheduled asynchronously to any other role (and any other timing-activity), hence the initiator timing-event might collide with other timing-events even if the 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.
To summarize, a recommended configuration for operation without dropped packets for cases
of only central roles running is that all central role intervals (i.e. connection
interval, scanner/observer/initiator intervals) should have a common factor. This common
factor should be greater than or equal to ∑tevent-Cx
+
scanWindow.
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 greater than or equal to
∑tevent-Cx+ScanWindow
If only Bluetooth® Low Energy role events are running and the above conditions are met, the worst-case collision scenario will be 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, there will be two Central connection collisions if all connections have the same bandwidth and both the initiator scan window is approximately equal to the tevent of the Central connections. The following figure shows this case of collision.
These collisions will result in collision resolution through the priority mechanism (refer to Scheduling priorities).
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 a connection with a connection interval of 50 ms. In this case, the connection that schedules events often compared to the scanner will raise its priority and may cause the scanner to receive less radio time than expected.
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.
Dropped packets are possible 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.