Suggested intervals and windows

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 t_event of all active central links. Therefore, 20 link timing-events can complete in ∑t_event-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 ∑t_event-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 ∑t_event-Cx + scanWindow + t_ScanReserved. 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.

When the SoftDevice is configured to do extended scanning, it is able to receive auxiliary packets outside of the configured scan window. Therefore, to ensure that the SoftDevice receives packets from an advertiser, the scan window should be configured to be long enough to receive three primary channel packets. For an advertiser configured with an advertising interval of 50 ms, on LE 1M PHY this corresponds to 52.5 ms, for LE Coded PHY this corresponds to 57.5 ms.

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 (LL) Data Channel PDUs are in use, it is recommended to increase the event length of a connection. For example, LL Data Channel PDUs are by default 27 bytes in size. With an event length of 7.5 ms, it is possible to send seven full-sized packet pairs in one connection event. Therefore, when increasing the Link Layer Data Channel PDU size to 251 bytes, the event length should be increased to 33.75 ms. To calculate how much time should be added (in ms), use the following formula: ((size - 27) * 8 * 2 * pairs) / 1000.

The same formula can be used for the Connected roles on LE 2M PHY and LE Coded PHY. On LE 2M PHY, it is possible to fit eleven 27 bytes packet pairs in one connection event of 7.5 ms. On LE Coded PHY, it is possible to fit one 27 bytes packet pair in one connection event of 7.5 ms.

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 ∑t_event-Cx + scanWindow + t_ScanReserved.

When the SoftDevice is configured to do extended scanning, it is able to receive auxiliary packets outside its configured scan window. The Scanner uses asynchronous timing-events to receive such auxiliary packets. Therefore, in this configuration, there may be role collisions, which will result in packets being dropped.

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 fewer colliding Peripherals is to set a short event length and enable the Connection Event Length Extension in the SoftDevice (see 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:

• Interval of all roles have a common factor which is greater than or equal to ∑t_event-Cx + (t_ScanReserved + ScanWindow) + t_{SlaveEventNominal} + t_AdvEventMax
  Note: t_{SlaveEventNominal} can be used in the above equation in most cases, but should be replaced by t_{SlaveEventMax} for cases where links as a Peripheral can have worst-case sleep clock accuracy and longer connection interval.
• Broadcaster and advertiser roles also follow the constraint that their intervals can be factored by the smallest connection interval.
  Note: Directed high-duty cycle advertiser is not considered here because it is not a periodic event.

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, there will be two Central connection collisions if all connections have the same bandwidth and both the initiator scan window and the t_event for the Broadcaster are approximately equal to the t_event of the Central connections. The following figure shows this case of collision.

Figure 1. Worst-case collision of Bluetooth Low Energy roles

These collisions will result in collision resolution through the priority mechanism. The worst-case collision will be reduced if any of the above roles are not running. For example, when only Central and Peripheral connections are running, in the worst case each role will get a timing event 50% of the time because they have the same priority. (Refer to Scheduling priorities). Three links running as a Central and one Peripheral 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.

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.

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. For example, in a case where only three central connections and one peripheral connection are running, in the worst case, each role will get a timing-event 50% of 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.