Initiator timing

This section introduces the different situations that happen with the Initiator when establishing a connection.

The examples in this section demonstrate an Initiator that is configured to listen on one PHY, resulting in one Initiator timing-event. Correspondingly, listening on two PHYs would result in two initiator timing-events as shown in Initiator - first connection initiating on two PHYs.

When establishing a connection with no other connections active, the Initiator will establish the connection in the minimum time and allocate the first central link connection event transmitWindowDelay after the connect request was sent, as shown in the following figure.

Figure 1. Initiator - first connection
Initiator - first connection
Figure 2. Initiator - first connection initiating on two PHYs
Initiator - first connection initiating on two PHYs

When establishing a new connection with other connections already made as a Central, the Initiator will start asynchronously to the connected link timing-events and schedule the new central connection’s first timing-event in any free time between existing central timing-events or after the existing central timing-events. Central link timing-events will be scheduled close to each other (without any free time between them). The minimum time between the start of two central role timing-events is the event length of the central role to which the first timing-event belongs. This minimum time is referred to as tevent. The following figure illustrates the case of establishing a new central connection with one central connection already running.

Figure 3. Initiator - one central connection running
Initiator - one central connection running
Note: The Initiator is scheduled asynchronously to any other role (and any other timing-activity) and assigned higher priority to ensure faster connection setup.

When a central link disconnects, the timings of other central link timing-events remain unchanged. The following figure illustrates the case when central link C1 is disconnected, which results in free time between C0 and C2.

Figure 4. Initiator - free time due to disconnection
Initiator - free time due to disconnection

When establishing a new connection in cases where free time is available between already running central link timing-events, best-fit algorithm is used to find which free time space should be used. Initiator - one or more connections as a Central illustrates the case when all existing central connections have the same connection interval and the initiator timing-event starts around the same time as the 1st central connection (C0) timing-event in the schedule. There is available time between C1–C2 and between C2–C3. A timing-event for new a connection, Cn, is scheduled in the available time between C2–C3 because that is the best fit for Cn.

Figure 5. Initiator - one or more connections as a Central
Initiator - one or more connections as a Central

Initiator - free time not enough illustrates the case when any free time between existing central link timing-events is not long enough to fit the new connection. The new central link timing-event is placed after all running central link timing-events in this case.

Figure 6. Initiator - free time not enough
Initiator - free time not enough

When establishing connections to newly discovered devices, the Scanner may be used for discovery followed by the Initiator. In Initiator - fast connection, the Initiator is started directly after discovering a new device to connect as fast as possible to that device. The Initiator will always start asynchronously to the connected link events. The result is some link timing-events being dropped while the initiator timing-event runs. Link timing-events scheduled in the transmit window offset will not be dropped (C1). In this case, time between C0–C1 is available and is allocated for the new connection (Cn).

Figure 7. Initiator - fast connection
Initiator - fast connection