Bluetooth Core Specification

A block of 64 contiguous LAPs is reserved for inquiry operations; one LAP common to all devices is reserved for general inquiry, the remaining 63 LAPs are reserved for dedicated inquiry of specific classes of devices (see Assigned Numbers). The same LAP values are used regardless of the contents of UAP and NAP. Consequently, none of these LAPs can be part of a user BD_ADDR.

The reserved LAP addresses are 0x9E8B00 to 0x9E8B3F. The general inquiry LAP is 0x9E8B33. All addresses have the LSB at the rightmost position, hexadecimal notation. The default check initialization (DCI) is used as the UAP whenever one of the reserved LAP addresses is used. The DCI is defined to be 0x00 (hexadecimal).

The basic piconet physical channel is defined by the Central of the piconet. The Central controls the traffic on the piconet physical channel by a polling scheme (see Section 8.5).

By definition, the device that initiates a connection by paging is the Central. Once a piconet has been established, the Central and Peripheral may exchange roles. This is described in Section 8.6.5.

The basic piconet physical channel is characterized by a pseudo-random hopping through all 79 RF channels. The frequency hopping in the piconet physical channel is determined by the Bluetooth clock and BD_ADDR of the Central. When the piconet is established, the Central's clock is communicated to the Peripherals. Each Peripheral shall add an offset to its native clock to synchronize with the Central's clock. Since the clocks are independent, the offsets must be updated regularly. All devices participating in the piconet are time-synchronized and hop-synchronized to the channel.

The basic piconet physical channel uses the basic channel hopping sequence and is described in Section 2.6.

The basic piconet physical channel is divided into time slots, each 625 μs in length. The time slots are numbered according to the most significant 27 bits of the Bluetooth clock CLK_27-1 of the piconet Central. The slot numbering ranges from 0 to 2²⁷-1 and is cyclic with a cycle length of 2²⁷. The time slot number is denoted as k.

A TDD scheme is used where Central and Peripheral alternately transmit, see Figure 2.1. The packet start shall be aligned with the slot start. Packets may extend over up to five time slots.

Figure 2.1: Multi-slot packets

The term slot pairs is used to indicate two adjacent time slots starting with a Central-to-Peripheral transmission slot.

CLK is the clock of the Central of the piconet. It shall be used for all timing and scheduling activities in the piconet. All devices shall use the CLK to schedule their transmission and reception. The CLK shall be derived from the reference clock CLKR (see Section 1.1) by adding a time_base_offset and a peripheral_clock_offset, see Figure 2.2. The time_base_offset is a value that devices may use to store a locally generated offset to CLKN caused by alignment to an external time base. The peripheral_clock_offset shall be zero for the Central since CLK is identical to its own native clock CLKN. Each Peripheral shall add an appropriate peripheral_clock_offset to its CLKN such that the CLK corresponds to the CLKN of the Central. Although all CLKNs in the devices run at the same nominal rate, mutual drift causes inaccuracies in CLK. Therefore, the peripheral_clock_offset in the Peripherals must be regularly updated such that CLK is approximately CLKN of the Central.

Figure 2.2: Derivation of CLK in Central (a) and in Peripheral (b)

Changes in time_base_offset are only made by the Central of a piconet; a device acting only as a Peripheral has no need to distinguish CLKR and CLKN in normal operation. In a scatternet situation, a Controller may be changing both time_base_offset to align its CLKN with an external clock, either collocated or at the request of a Peripheral, and peripheral_clock_offset to maintain synchronization with a different piconet clock. In some cases, it is not possible to determine how much of an observed offset is caused by external frame timing alignment (time_base_offset) and how much is caused by the offset between Central and Peripheral (peripheral_clock_offset).

The Central transmission shall always start at even numbered time slots (CLK₁=0) and the Peripheral transmission shall always start at odd numbered time slots (CLK₁=1). Due to packet types that cover more than a single slot, Central transmission may continue in odd numbered slots and Peripheral transmission may continue in even numbered slots, see Figure 2.1.

All timing diagrams shown in Section 2 are based on the signals as present at the antenna. The term “exact” when used to describe timing refers to an ideal transmission or reception and neglects timing jitter and clock frequency imperfections.

The average timing of packet transmission shall not drift faster than 20 ppm relative to the ideal slot timing of 625 μs. The instantaneous timing shall not deviate more than 1 μs from the average timing. Thus, the absolute packet transmission timing t_k of slot boundary k shall fulfill the equation:

where T_N is the nominal slot length (625 μs), j_k denotes jitter ($\left|j_k\right|\le 1\text{ μs}$) at the start of slot k, and, d_k, denotes the drift ($\left|d_k\right|\le 20\text{ ppm}$) within slot k. The jitter and drift can vary arbitrarily within the given limits for every slot, while offset is an arbitrary but fixed constant. For Hold and Sniff modes the drift and jitter parameters specified in Link Manager Protocol [Vol 2] Part C, Section 4.3.1 apply.

2.2.5.1. Piconet physical channel timing

In the figures, only single-slot packets are shown as an example.

The Central TX/RX timing is shown in Figure 2.3. In Figure 2.3 and Figure 2.4 the channel hopping frequencies are indicated by f(k) where k is the time slot number. After transmission, a return packet is expected N × 625 μs after the start of the TX packet where N is an odd, integer larger than 0. N depends on the type of the transmitted packet.

To allow for some time slipping, an uncertainty window is defined around the exact receive timing. During normal operation, the window length shall be 20 μs, which allows the RX packet to arrive up to 10 μs too early or 10 μs too late. It is recommended that Peripherals implement variable sized windows or time tracking to accommodate a Central's absence of more than 250 ms.

During the beginning of the RX cycle, the access correlator shall search for the correct channel access code over the uncertainty window. If an event trigger does not occur the receiver may go to sleep until the next RX event. If in the course of the search, it becomes apparent that the correlation output will never exceed the final threshold, the receiver may go to sleep earlier. If a trigger event occurs, the receiver shall remain open to receive the rest of the packet unless the packet is for another device, a non-recoverable header error is detected, or a non-recoverable payload error is detected.

Figure 2.3: RX/TX cycle of Central transceiver in normal mode for single-slot packets

Each Central transmission shall be derived from bit 2 of the Central's native Bluetooth clock, thus the current transmission will be scheduled M × 1250 μs after the start of the previous Central TX burst where M depends on the transmitted and received packet type and is an even, integer larger than 0. The Central TX timing shall be derived from the Central's native Bluetooth clock, and thus it will not be affected by time drifts in the Peripheral(s).

Peripherals maintain an estimate of the Central’s native clock by adding a timing offset to the Peripheral’s native clock (see Section 2.2.4). This offset shall be updated each time a packet is received from the Central. By comparing the exact RX timing of the received packet with the estimated RX timing, Peripherals shall correct the offset for any timing misalignments. Since only the channel access code is required to synchronize the Peripheral, Peripheral RX timing can be corrected with any packet sent in the Central-to-Peripheral transmission slot.

The Peripheral's TX/RX timing is shown in Figure 2.4. The Peripheral’s transmission shall be scheduled N × 625 μs after the start of the Peripheral’s RX packet where N is an odd, positive integer larger than 0. If the Peripheral’s RX timing drifts, so will its TX timing. During periods when a Peripheral is in the Active mode (see Section 8.6) and is prevented from receiving valid channel access codes from the Central due to local RF interference, Peripheral activity in a different piconet, or any other reason, the Peripheral may increase its receive uncertainty window and/or use predicted timing drift to increase the probability of receiving the Central's bursts when reception resumes.

Figure 2.4: RX/TX cycle of Peripheral transceiver in normal mode for single-slot packets

2.2.5.2. Piconet physical channel re-synchronization

In the piconet physical channel, a Peripheral can lose synchronization if it does not receive a packet from the Central at least every 200 ms (or less if the low power clock is used). The Central may fail to transmit to the Peripheral due to the Central being busy with other tasks such as maintaining connections to other devices in Sniff or Hold modes, due to SCO, eSCO, or Connectionless Peripheral Broadcast activity, due to the Central being involved in a scatternet, or due to interference. When re-synchronizing to the piconet physical channel a Peripheral shall listen for the Central before it may send information (except for a Connectionless Peripheral Broadcast Receiver device which shall listen for the Transmitter but does not send information). In this case, the length of the synchronization search window in the Peripheral may be increased from 20 µs to a larger value X µs as illustrated in Figure 2.5. Only RX hop frequencies are used: the hop frequency used in the Central-to-Peripheral (RX) slot shall also be used in the uncertainty window, even when it is extended into the preceding time interval normally used for the Peripheral-to-Central (TX) slot.

If the length of search window, X, exceeds 1250 µs, consecutive windows shall avoid overlapping search windows. Consecutive windows should instead be centered at f(k), f(k+4),... f(k+4i) (where 'i' is an integer), which gives a maximum value X=2500 µs, or even at f(k), f(k+6),...f(k+6i) which gives a maximum value X=3750 µs. The RX hop frequencies used shall correspond to the Central-to-Peripheral transmission slots.

It is recommended that single slot packets are transmitted by the Central during Peripheral re-synchronization.

Figure 2.5: RX timing of Peripheral returning from Hold mode

Each physical link on the adapted piconet physical channel shall use at least N_min RF channels (where N_min is 20).

The adapted piconet physical channel uses the adapted channel hopping sequence described in Section 2.6.

Adapted piconet physical channels can be used for connected devices that have adaptive frequency hopping (AFH) enabled. There are two distinctions between basic and adapted piconet physical channels. The first is the same channel mechanism that makes the Peripheral frequency the same as the preceding Central transmission. The second aspect is that the adapted piconet physical channel may be based on less than the full 79 frequencies of the basic piconet physical channel. Each physical link on an adapted piconet physical channel may use a different set of frequencies.

A paging device uses an estimate of the native clock of the page scanning device, CLKE; i.e. an offset shall be added to the CLKN of the pager to approximate the CLKN of the recipient, see Figure 2.6. CLKE shall be derived from the native CLKN by adding an offset. By using the CLKN of the recipient, the pager might be able to speed up the connection establishment.

Note: CLKR is never used for deriving CLKE or for any other control of the hopping kernel.

Figure 2.6: Derivation of CLKE

The page scan physical channel follows a slower hopping pattern than the basic piconet physical channel and is a short pseudo-random hopping sequence through the RF channels. The timing of the page scan channel shall be determined by the native Bluetooth clock of the scanning device. The frequency hopping sequence is determined by the Bluetooth address of the scanning device.

The page scan physical channel uses the page, Central page response, Peripheral page response, and page scan hopping sequences specified in Section 2.6.

During the paging procedure, the Central shall transmit paging messages (see Table 8.3) corresponding to the Peripheral to be connected. Since the paging message is a very short packet, the hop rate is 3200 hops per second. In a single TX slot interval, the paging device shall transmit on two different hop frequencies. In Figure 2.7 to Figure 2.11, f(k) is used for the frequencies of the page hopping sequence and f'(k) denotes the corresponding page response sequence frequencies. The first transmission starts where CLK₀ = 0 and the second transmission starts where CLK₀ = 1.

In a single RX slot interval, the paging device shall listen for the Peripheral page response message on two different hop frequencies. Similar to transmission, the nominal reception starts where CLK₀ = 0 and the second reception nominally starts where CLK₀ = 1; see Figure 2.7. During the TX slot, the paging device shall send the paging message at the TX hop frequencies f(k) and f(k+1). In the RX slot, it shall listen for a response on the corresponding RX hop frequencies f’(k) and f’(k+1). The listening periods shall be exactly timed 625 μs after the corresponding paging packets, and shall include a ±10 μs uncertainty window.

Figure 2.7: RX/TX cycle of transceiver in Page mode

At connection setup a Central page response packet is transmitted from the Central to the Peripheral (see Table 8.3). This packet establishes the timing and frequency synchronization. After the Peripheral has received the page message, it shall return a response message that consists of the Peripheral page response packet and shall follow 625 μs after the receipt of the page message. The Central shall send the Central page response packet in the TX slot following the RX slot in which it received the Peripheral’s response, according to the RX/TX timing of the Central. The time difference between the Peripheral page response and Central page response message will depend on the timing of the page message the Peripheral received. In Figure 2.8, the Peripheral receives the paging message sent first in the Central-to-Peripheral slot. It then responds with a first Peripheral page response packet in the first half of the Peripheral-to-Central slot. The timing of the Central page response packet is based on the timing of the page message sent first in the preceding Central-to-Peripheral slot: there is an exact 1250 μs delay between the first page message and the Central page response packet. The packet is sent at the hop frequency f(k+1) which is the hop frequency following the hop frequency f(k) the page message was received in.

Figure 2.8: Timing of page response packets on successful page in first half slot

In Figure 2.9, the Peripheral receives the paging message sent second in the Central-to-Peripheral slot. It then responds with a Peripheral page response packet in the second half of the Peripheral-to-Central slot exactly 625 μs after the receipt of the page message. The timing of the Central page response packet is still based on the timing of the page message sent first in the preceding Central-to-Peripheral slot: there is an exact 1250 μs delay between the first page message and the Central page response packet. The packet is sent at the hop frequency f(k+2) which is the hop frequency following the hop frequency f(k+1) the page message was received in.

Figure 2.9: Timing of page response packets on successful page in second half slot

The Peripheral shall adjust its RX/TX timing according to the reception of the Central page response packet (and not according to the reception of the page message). That is, the second Peripheral page response message that acknowledges the reception of the Central page response packet shall be transmitted 625 μs after the start of the Central page response packet.

The clock used for inquiry and inquiry scan shall be the device's native clock.

The inquiry scan channel follows a slower hopping pattern than the piconet physical channel and is a short pseudo-random hopping sequence through the RF channels. The timing of the inquiry scan channel is determined by the native Bluetooth clock of the scanning device while the frequency hopping sequence is determined by the general inquiry access code.

The inquiry scan physical channel uses the inquiry, inquiry response, and inquiry scan hopping sequences described in Section 2.6.

During the inquiry procedure, the Central shall transmit inquiry messages with the general or dedicated inquiry access code. The timing for inquiry is the same as for paging (see Section 2.4.3).

An inquiry response packet is transmitted from the Peripheral to the Central after the Peripheral has received an inquiry message (see Table 8.5). This packet contains information necessary for the inquiring Central to page the Peripheral (see definition of the FHS packet in Section 6.5.1.4) and follows 625 μs after the receipt of the inquiry message. If the Peripheral transmits an extended inquiry response packet, it shall be transmitted 1250 μs after the start of the inquiry response packet.

In Figure 2.10 and Figure 2.11, f(k) is used for the frequencies of the inquiry hopping sequence and f'(k) denotes the corresponding inquiry response sequence frequency. The inquiry response packet and the extended inquiry response packet are received by the Central at the hop frequency f'(k) when the inquiry message received by the Peripheral was first in the Central-to-Peripheral slot.

Figure 2.10: Timing of inquiry response packets on successful inquiry in first half slot

When the inquiry message received by the Peripheral was the second in the Central-to-Peripheral slot the inquiry response packet and the extended inquiry response packet are received by the Central at the hop frequency f'(k+1).

Figure 2.11: Timing of inquiry response packets on successful inquiry in second half slot

The selection scheme consists of two parts:

The general block diagram of the hop selection scheme is shown in Figure 2.12. The mapping from the input to a particular RF channel index is performed in the selection box.

The inputs to the selection box are the selected clock, frozen clock, N, k_offset, interlace_offset, address, sequence selection and AFH_channel_map. The source of the clock input depends on the hopping sequence selected. Additionally, each hopping sequence uses different bits of the clock (see Table 2.2). N, interlace_offset, and k_offset are defined in Section 2.6.4.

The sequence selection input can be set to the following values:

The address input consists of 28 bits as specified in Table 2.3 (see Section 2.6.4). The hopping sequence is selected by the sequence selection input to the selection box.

When the adapted channel hopping sequence is selected, the AFH_channel_map is an additional input to the selection box. The AFH_channel_map indicates which channels shall be used and which shall be unused. These terms are defined in Section 2.6.3.

Figure 2.12: General block diagram of hop selection scheme

The output, RF channel index, constitutes a pseudo-random sequence. The RF channel index is mapped to RF channel frequencies using the equation in [Vol 2] Part A, Table 2.1.

The selection scheme chooses a segment of 32 hop frequencies spanning about 64 MHz and visits these hops in a pseudo-random order. Next, a different 32-hop segment is chosen, etc. In the page, Central page response, Peripheral page response, page scan, inquiry, inquiry response and inquiry scan hopping sequences, the same 32-hop segment is used all the time (the segment is selected by the address; different devices will have different paging segments). When the basic channel hopping sequence is selected, the output constitutes a pseudo-random sequence that slides through the 79 hops. The principle is depicted in Figure 2.13.

Figure 2.13: Hop selection scheme in Connection state

The RF frequency shall remain fixed for the duration of the packet. The RF frequency for the packet shall be derived from the Bluetooth clock value in the first slot of the packet. The RF frequency in the first slot after a multi-slot packet shall use the frequency as determined by the Bluetooth clock value for that slot. Figure 2.14 illustrates the hop definition on single- and multi-slot packets.

Figure 2.14: Single- and multi-slot packets

When the adapted channel hopping sequence is used, the pseudo-random sequence contains only frequencies that are in the RF channel set defined by the AFH_channel_map input. The adapted sequence has similar statistical properties to the non-adapted hop sequence. In addition, the Peripheral responds with its packet on the same RF channel that was used by the Central to address that Peripheral (or would have been in the case of a synchronous reserved slot without a validly received Central-to-Peripheral transmission). This is called the same channel mechanism of AFH. Thus, the RF channel used for the Central to Peripheral packet is also used for the immediately following Peripheral to Central packet. An example of the same channel mechanism is illustrated in Figure 2.15. The same channel mechanism shall be used whenever the adapted channel hopping sequence is selected.

Figure 2.15: Example of the same channel mechanism

The basic hop selection kernel shall be as shown in Figure 2.16 and is used for the page, page response, inquiry, inquiry response and basic channel hopping selection kernels. In these substates the AFH_channel_map input is unused. The adapted channel hopping selection kernel is described in Section 2.6.3. The X input determines the phase in the 32-hop segment, whereas Y1 and Y2 selects between Central-to-Peripheral and Peripheral-to-Central. The inputs A to D determine the ordering within the segment, the inputs E and F determine the mapping onto the hop frequencies. The kernel addresses a register containing the RF channel indices. This list is ordered so that first all even RF channel indices are listed and then all odd hop frequencies. In this way, a 32-hop segment spans about 64 MHz.

Figure 2.16: Block diagram of the basic hop selection kernel for the hop system

The selection procedure consists of an addition, an XOR operation, a permutation operation, an addition, and finally a register selection. In Section 2.6.2 and Table 2.2, the notation A_i is used for bit i of the BD_ADDR.

2.6.2.2. XOR operation

In the XOR operation, the four LSBs of the output of the first addition (designated Z′ here) are XORed with the address bits A_22-19, while the Z′₄ bit is left unaltered. The operation is illustrated in Figure 2.17.

Figure 2.17: XOR operation for the hop system

2.6.2.3. Permutation operation

The permutation operation involves the switching from 5 inputs to 5 outputs for the hop system, controlled by the control word. The permutation or switching box shall be as shown in Figure 2.18. It consists of 7 stages of butterfly operations. The control of the butterflies by the control signals P is shown in Table 2.1. P_0-8 corresponds to D_0-8, and, P_i+9 corresponds to ${\mathrm{C}}_i\oplus \mathrm{Y}1$ for $i=0\dots 4$ in Figure 2.16.

Control signal	Butterfly		Control signal	Butterfly
P0	{Z0,Z1}		P7	{Z3,Z4}
P1	{Z2,Z3}		P8	{Z1,Z4}
P2	{Z1,Z2}		P9	{Z0,Z3}
P3	{Z3,Z4}		P10	{Z2,Z4}
P4	{Z0,Z4}		P11	{Z1,Z3}
P5	{Z1,Z3}		P12	{Z0,Z3}
P6	{Z0,Z2}		P13	{Z1,Z2}

Table 2.1: Control of the butterflies for the hop system

The Z input is the output of the XOR operation as described in the previous section. The butterfly operation can be implemented with multiplexers as depicted in Figure 2.19.

Figure 2.18: Permutation operation for the hop system

Figure 2.19: Butterfly implementation

The adapted hop selection kernel is based on the basic hop selection kernel defined in the preceding sections.

The inputs to the adapted hop selection kernel are the same as for the basic hop system kernel except that the input AFH_channel_map (defined in Link Manager Protocol [Vol 2] Part C, Section 5.2) is used. The AFH_channel_map indicates which RF channels shall be used and which shall be unused. When hop sequence adaptation is enabled, the number of used RF channels may be reduced from 79 to some smaller value N. All devices shall be capable of operating on an adapted hop sequence (AHS) with N_min ≤ N ≤ 79, with any combination of used RF channels within the AFH_channel_map that meets this constraint. N_min is defined in Section 2.3.1.

Adaptation of the hopping sequence is achieved through two additions to the basic channel hopping sequence according to Figure 2.16:

2.6.3.1. Channel re-mapping function

When the adapted hop selection kernel is selected, the basic hop selection kernel according to Figure 2.16 is initially used to determine an RF channel. If this RF channel is unused according to the AFH_channel_map, the unused RF channel is re-mapped by the re-mapping function to one of the used RF channels. If the RF channel determined by the basic hop selection kernel is already in the set of used RF channels, no adjustment is made. The hop sequence of the (non-adapted) basic hop equals the sequence of the adapted selection kernel on all locations where used RF channels are generated by the basic hop. This property facilitates all Peripherals remaining synchronized even if they are not all using the same hopping sequence.

A block diagram of the re-mapping mechanism is shown in Figure 2.20. The re-mapping function is a post-processing step to the selection kernel from Figure 2.16, denoted as ‘Hop selection of the basic hop’. The output f_k of the basic hop selection kernel is an RF channel number that ranges between 0 and 78. This RF channel will either be in the set of used RF channels or in the set of unused RF channels.

Figure 2.20: Block diagram of adaptive hop selection mechanism

When an unused RF channel is generated by the basic hop selection mechanism, it is re-mapped to the set of used RF channels as follows. A new index k’ ∈ {0, 1,..., N-1} is calculated using some of the parameters from the basic hop selection kernel:

k’ = (PERM5_out + E + F’ + Y2) mod N

where F’ is defined in Table 2.2. The index k’ is then used to select the re-mapped channel from a mapping table that contains all of the even used RF channels in ascending order followed by all the odd used RF channels in ascending order (i.e., the mapping table of Figure 2.16 with all the unused RF channels removed).

The control word of the kernel is controlled by the overall control signals X, Y1, Y2, A to F, and F’ as illustrated in Figure 2.16 and Figure 2.20. During paging and inquiry, the inputs A to E use the address values as given in the corresponding columns of Table 2.2. In addition, the inputs X, Y1 and Y2 are used. The F and F’ inputs are unused. The clock bits CLK_6-2 (i.e., input X) specify the phase within the length 32 sequence. CLK₁ (i.e., inputs Y1 and Y2) is used to select between TX and RX. The address inputs determine the sequence order within segments. The final mapping onto the hop frequencies is determined by the register contents.

During the Connection state (see Section 8.5), the inputs A, C and D shall be derived from the address bits being bit-wise XORed with the clock bits as shown in the “Connection state” column of Table 2.2 (the two most significant bits, MSBs, are XORed together, the two second MSBs are XORed together, etc.).

The five X input bits vary depending on the current state of the device. In the Page Scan and Inquiry Scan substates, the native clock (CLKN) shall be used. In Connection state the Central's clock (CLK) shall be used as input. The situation is somewhat more complicated for the other states.

The address bits A₀ to A₂₇ depend on the sequence selection input as specified in Table 2.3.

When a device enters the Synchronization Scan substate, it shall scan the synchronization train RF channels using the timing defined in Section 2.7.3. Each individual scan window shall use a different RF channel than the previous two scan windows.

The synchronization scan physical channel shall use all of the synchronization train RF channels defined in Section 2.6.4.8.

The Central shall use the synchronization train procedure only when Connectionless Peripheral Broadcast mode is enabled or during the Coarse Clock Adjustment Recovery Mode ( Section 8.6.10.2); these can happen concurrently. During the synchronization train procedure, the Central shall attempt to transmit synchronization train packets on all of the RF channels specified in Section 2.6.4.8. The transmission of synchronization train packets on each RF channel is independent of the transmission on other RF channels. For each RF channel, the Central shall:

Figure 2.21 shows the timing relationship of consecutive synchronization train packets on a single RF channel.

Figure 2.21: Synchronization train packet timing on a single channel

During the Synchronization Scan procedure, a device performs synchronization scans on the synchronization train RF channels. During each scan window, the device listens for the duration of T_{Sync_Scan_Window}. The RF channel for each scan window shall be selected as specified in Section 2.7.1. Each scan window should be continuous and not interrupted by other activities. The interval between the start of consecutive scan windows shall be equal to T_{Sync_Scan_Interval}. The values for T_{Sync_Scan_Window} and T_{Sync_Scan_Interval} shall be chosen as follows:

This timing relationship is shown in Figure 2.22.

Figure 2.22: Synchronization scan timing

The TX routine is carried out separately for each asynchronous and synchronous logical transport. Figure 4.1 shows the asynchronous and synchronous buffers as used in the TX routine. In this figure, only a single TX asynchronous buffer and a single TX synchronous buffer are shown. In the Central, there is a separate TX asynchronous buffer for each Peripheral. In addition there can be one or more TX synchronous buffers for each synchronous Peripheral (different SCO or eSCO logical transports could either reuse the same TX synchronous buffer, or each have their own TX synchronous buffer). Each TX buffer consists of two FIFO registers: one current register which can be accessed and read by the Link Controller in order to compose the packets, and one next register that can be accessed by the Baseband Resource Manager to load new information. The positions of the switches S1 and S2 determine which register is current and which register is next; the switches are controlled by the Link Controller. The switches at the input and the output of the FIFO registers can never be connected to the same register simultaneously.

Figure 4.1: Functional diagram of TX buffering

Of the packets common to the ACL and SCO logical transports (NULL, POLL and DM1), only the DM1 packet carries a payload that is exchanged between the Link Controller and the Link Manager; this packet makes use of the asynchronous buffer. All ACL packets make use of the asynchronous buffer. All SCO and eSCO packets make use of the synchronous buffer except for the DV packet where the synchronous data part is handled by the synchronous buffer and the data part is handled by the asynchronous buffer. In the next sections, the operation for ACL traffic, SCO traffic, eSCO traffic, and combined data-voice traffic on the SCO logical transport are described.

The RX routine is carried out separately for the ACL logical transport and the synchronous logical transports. However, in contrast to the Central TX asynchronous buffer, a single RX buffer is shared among all Peripherals. For the synchronous buffer, how the different synchronous logical transports are distinguished depends on whether extra synchronous buffers are required or not. Figure 4.2 shows the asynchronous and synchronous buffers as used in the RX routine. The RX asynchronous buffer consists of two FIFO registers: one register that can be accessed and loaded by the Link Controller with the payload of the latest RX packet, and one register that can be accessed by the Baseband Resource Manager to read the previous payload. The RX synchronous buffer also consists of two FIFO registers: one register which is filled with newly arrived voice information, and one register which can be read by the voice processing unit.

Figure 4.2: Functional diagram of RX buffering

Since the TYPE indication in the header (see Section 6.4.2) of the received packet indicates whether the payload contains data and/or voice, the packet de-composer can automatically direct the traffic to the proper buffers. The switch S1 changes every time the Baseband Resource Manager reads the old register. If the next payload arrives before the RX register is emptied, a STOP indication is included in the packet header of the next TX packet that is returned. The STOP indication is removed again as soon as the RX register is emptied. The SEQN field is checked before a new ACL payload is stored into the asynchronous register (flush indication in LLID and broadcast messages influence the interpretation of the SEQN field see Section 7.6).

The S2 switch is changed every T_SCO or T_eSCO for SCO and eSCO respectively. If, due to errors in the header, no new synchronous payload arrives, the switch still changes. The synchronous data processing unit then processes the synchronous data to account for the missing parts.

Since the RX ACL buffer can be full while a new payload arrives, flow control is required. The header field FLOW in the return TX packet may use STOP or GO in order to control the transmission of new data.

When paused by the LM, the Link Controller transmits the current packet with ACL-U information, if any, until an ACK is received. While the ACL-U logical link is paused, the Link Controller shall not transmit any (more) packets with ACL-U logical link information.

When the ACL-U logical link is resumed by the LM, the Link Controller may resume transmitting packets with ACL-U information.

The general packet format of Basic Rate packets is shown in Figure 6.1. Each packet consists of 3 entities: the access code, the header, and the payload. In the figure, the number of bits per entity is indicated.

Figure 6.1: General Basic Rate packet format

The access code is 72 or 68 bits and the header is 54 bits. The payload ranges from zero to a maximum of 2790 bits. Different packet types have been defined. A packet may consist of:

The general format of Enhanced Data Rate packets is shown in Figure 6.2. The access code and packet header are identical in format and modulation to Basic Rate packets. Enhanced Data Rate packets have a guard time and synchronization sequence following the packet header. Following the payload are two trailer symbols. The guard time, synchronization sequence and trailer are defined in Section 6.6.

Figure 6.2: General Enhanced Data Rate packet format

The different access code types use different Lower Address Parts (LAPs) to construct the sync word. The LAP field of the BD_ADDR is explained in Section 1.2. A summary of the different access code types is in Table 6.1.

The CAC consists of a preamble, sync word, and trailer and its total length is 72 bits. When used as self-contained messages without a header, the DAC and IAC do not include the trailer bits and are of length 68 bits.

The preamble is a fixed zero-one pattern of 4 symbols used to facilitate DC compensation. The sequence is either ‘1010’ or ‘0101’ (in transmission order), depending on whether the LSB of the following sync word is 1 or 0, respectively. The preamble is shown in Figure 6.4.

Figure 6.4: Preamble

The sync word is a 64-bit code word derived from a 24 bit address (LAP); for the CAC the Central’s LAP is used; for the GIAC and the DIAC, reserved, dedicated LAPs are used; for the DAC, the Peripheral LAP is used. The construction results in a large Hamming distance between sync words based on different LAPs. In addition, the good auto correlation properties of the sync word improve timing acquisition.

6.3.3.1. Synchronization word definition

The sync words are based on a (64,30) expurgated block code with an overlay (bit-wise XOR) of a 64 bit full length pseudo-random noise (PN) sequence. The expurgated code results in a large Hamming distance (d_min = 14) between sync words based on different addresses. The PN sequence improves the auto correlation properties of the access code. The following steps describe how the sync word shall be generated:

1. Generate information sequence;

2. XOR this with the “information covering” part of the PN overlay sequence;

3. Generate the codeword;

4. XOR the codeword with all 64 bits of the PN overlay sequence;

The information sequence is generated by appending 6 bits to the 24 bit LAP (step 1). The appended bits are '001101' (in transmission order) if the MSB of the LAP equals 0. If the MSB of the LAP is 1 the appended bits are '110010'. The LAP MSB together with the appended bits constitute a length-seven Barker sequence. The purpose of including a Barker sequence is to further improve the auto correlation properties. In step 2 the information is pre-scrambled by XORing it with the bits $p_{34\dots }{p}_{63}$ of the PN sequence (defined in Section 6.3.3.2). After generating the codeword (step 3), the complete PN sequence is XORed to the codeword (step 4). This step de-scrambles the information part of the codeword. At the same time the parity bits of the codeword are scrambled. Consequently, the original LAP and Barker sequence are ensured a role as a part of the access code sync word, and the cyclic properties of the underlying code is removed. The principle is depicted in Figure 6.5.

In the following discussion, binary sequences will be denoted by their corresponding D-transform (in which Dⁱ represents a delay of i time units). Let $p\text{'}\left(D\right)=p{\text{'}}_0+p{\text{'}}_{1}D+\dots +p{\text{'}}_{62}{D}^{62}$ be the 63 bit PN sequence, where $p{\text{'}}_0$ is the first bit (LSB) leaving the PRNG (see Figure 6.6), and, $p{\text{'}}_{62}$ is the last bit (MSB). To obtain 64 bits, an extra zero is appended at the end of this sequence (thus, $p\text{'}\left(D\right)$ is unchanged). For notational convenience, the reciprocal of this extended polynomial, $p\left(D\right)=D^{63}p\text{'}\left(1/D\right)$, will be used in the following discussion. This is the sequence $p\text{'}\left(D\right)$ in reverse order. We denote the 24 bit lower address part (LAP) of the Bluetooth Device Address by $a\left(D\right)=a_0+a_{1}D+\dots +a_{23}{D}^{23}$ ($a_0$ is the LSB of the Bluetooth Device Address).

Figure 6.5: Construction of the sync word

The (64,30) block code generator polynomial is denoted $g\left(D\right)=\left(1+D\right)g\text{'}\left(D\right)$, where $g\text{'}\left(D\right)$ is the generator polynomial 0x37CD0EB67 of a primitive binary (63,30) BCH code. Thus, g(D) is

Equation 9. 

$g\left(D\right)=0\mathrm{x}585713\mathrm{DA}9,$

where the left-most bit corresponds to the high-order (g₃₄) coefficient. The DC-free four bit sequences '0101' and '1010' (in transmission order) can be written

Equation 10. 

$\left\{\begin{array}{l}{F}_0\left(D\right)=D+D^3,\\ F_1\left(D\right)=1+D^2,\end{array}\right.$

respectively. Furthermore,

Equation 11. 

$\left\{\begin{array}{l}{B}_0\left(D\right)=D^2+D^3+D^5,\\ B_1\left(D\right)=1+D+D^4,\end{array}\right.$

which are used to create the length seven Barker sequences. Then, the access code shall be generated by the following procedure:

1. Format the 30 information bits to encode:

   Equation 0. 

   $x\left(D\right)=a\left(D\right)+D^{24}{B}_{a_{23}}\left(D\right).$
   
   
   

2. Add the information covering part of the PN overlay sequence:

   Equation 0. 

   $\tilde{x}\left(D\right)=x\left(D\right)+p_{34}+p_{35}D+\dots +p_{63}{D}^{29}.$
   
   
   

3. Generate parity bits of the (64,30) expurgated block code:¹

   Equation 0. 

   $\tilde{c}\left(D\right)=D^{34}\tilde{x}\left(D\right)\mathit{\text{ mod }}g\left(D\right).$
   
   
   

4. Create the codeword:

   Equation 0. 

   $\tilde{s}\left(D\right)=D^{34}\tilde{x}\left(D\right)+\tilde{c}\left(D\right).$
   
   
   

5. Add the PN sequence:

   Equation 0. 

   $s\left(D\right)=\tilde{s}\left(D\right)+p\left(D\right).$
   
   
   

6. Append the (DC-free) preamble and trailer:

   Equation 0. 

   $y\left(D\right)=F_{c_0}\left(D\right)+D^{4}s\left(D\right)+D^{68}{F}_{a_{23}}\left(D\right).$
   
   
   

6.3.3.2. Pseudo-random noise sequence generation

To generate the PN sequence the primitive polynomial h(D) = 1 + D + D³ + D⁴ + D⁶ shall be used. The LFSR and its starting state are shown in Figure 6.6. The PN sequence generated (including the extra terminating zero) becomes 0x83848D96BBCC54FC. The LFSR output starts with the left-most bit of this PN sequence. This corresponds to $p\text{'}\left(D\right)$ of the previous section. Thus, using the reciprocal $p\text{'}\left(D\right)$ as overlay gives the 64 bit sequence:

Equation 12. 

$\begin{array}{rcc}p& \mathrm{=}& \text{'}3F2A33DD69B121C1\text{'}\end{array}$

(in transmission order) where the left-most bit is p₀ = 0 (there are two initial zeros in the binary representation of the hexadecimal digit 3), and p₆₃ = 1 is the right-most bit.

Figure 6.6: LFSR and the starting state to generate $p\text{'}\left(D\right)$

The trailer is appended to the sync word as soon as the packet header follows the access code. This is typically the case with the CAC, but the trailer is also used in the DAC and IAC when these codes are used in FHS packets exchanged during page response and inquiry response.

The trailer is a fixed zero-one pattern of four symbols. The trailer together with the three MSBs of the syncword form a 7-bit pattern of alternating ones and zeroes which can be used for extended DC compensation. The trailer sequence is either ‘1010’ or ‘0101’ (in transmission order) depending on whether the MSB of the sync word is 0 or 1, respectively. The choice of trailer is illustrated in Figure 6.7.

Figure 6.7: Trailer in CAC when MSB of sync word is 0 (a), and when MSB of sync word is 1 (b)

The 3-bit LT_ADDR field contains the logical transport address for the packet (see Section 4.2). This field indicates the destination Peripheral (or Peripherals in the case of a broadcast) for a packet in a Central-to-Peripheral transmission slot and indicates the source Peripheral for a Peripheral-to-Central transmission slot.

Sixteen different types of packets can be distinguished. The 4-bit TYPE code specifies which packet type is used. The interpretation of the TYPE code depends on the logical transport address in the packet. First, it shall be determined whether the packet is sent on a SCO logical transport, an eSCO logical transport, an ACL logical transport, or a CPB logical transport. Second, it shall be determined whether Enhanced Data Rate has been enabled for the logical transport (ACL or eSCO) indicated by LT_ADDR. It can then be determined which type of SCO packet, eSCO packet, or ACL packet has been received. The TYPE code determines how many slots the current packet will occupy (see the slot occupancy column in Table 6.2). This allows the non-addressed receivers to refrain from listening to the channel for the duration of the remaining slots. In Section 6.5, each packet type is described in more detail.

The FLOW bit is used for flow control of packets over the ACL logical transport. When the RX buffer for the ACL logical transport in the recipient is full, a STOP indication (FLOW=0) shall be returned to stop the other device from transmitting data temporarily. The STOP signal only affects ACL packets. Packets including only link control information (POLL and NULL packets), SCO packets or eSCO packets can still be received. When the RX buffer can accept data, a GO indication (FLOW=1) shall be returned. When no packet is received, or the received header is in error, a GO shall be assumed implicitly. In this case, the Peripheral can receive a new packet with CRC although its RX buffer is still not emptied. The Peripheral shall then return a NAK in response to this packet even if the packet passed the CRC check.

The FLOW bit is not used on the eSCO logical transport and shall be set to one on transmission and ignored upon receipt. The FLOW bit is reserved for future use on the CPB logical transport.

The 1-bit acknowledgment indication ARQN is used to inform the source of a successful transfer of payload data with CRC, and can be positive acknowledge ACK or negative acknowledge NAK. See Section 7.6 for initialization and usage of this bit.

The ARQN bit is reserved for future use on the CPB logical transport.

The SEQN bit provides a sequential numbering scheme to order the data packet stream. See Section 7.6.2 for initialization and usage of the SEQN bit. For Active Peripheral Broadcast packets, a modified sequencing method is used, see Section 7.6.5.

The SEQN bit is reserved for future use on the CPB logical transport.

Each header has a header-error-check to check the header integrity. The HEC is an 8-bit word (generation of the HEC is specified in Section 7.1.1). Before generating the HEC, the HEC generator is initialized with an 8-bit value. For FHS packets sent in Central Page Response substate, the Peripheral upper address part (UAP) shall be used. For FHS packets and extended inquiry response packets sent in Inquiry Response substate, the default check initialization (DCI, see Section 1.2.1) shall be used. In all other cases, the UAP of the Central shall be used.

After the initialization, a HEC shall be calculated for the 10 header bits. Before checking the HEC, the receiver shall initialize the HEC check circuitry with the proper 8-bit UAP (or DCI). If the HEC does not check, the entire packet shall be discarded. More information can be found in Section 7.1.

There are five common kinds of packets. In addition to the types listed in segment 1 of Table 6.2, the ID packet is also a common packet type but is not listed in segment 1 because it does not have a packet header.

6.5.1.4. FHS packet

The FHS packet is a special control packet containing, among other things, the Bluetooth Device Address and the clock of the sender. The payload contains 144 information bits plus a 16-bit CRC code. The payload is coded with a rate 2/3 FEC with a gross payload length of 240 bits.

Figure 6.9 illustrates the format and contents of the FHS payload. The FHS packet is used in Central page response, inquiry response and in role switch.

The FHS packet is not encrypted. No payload header or MIC is present.

The FHS packet contains real-time clock information. This clock information shall be updated before each retransmission. The retransmission of the FHS payload is different than retransmissions of ordinary data payloads where the same payload is used for each retransmission. The FHS packet is used for frequency hop synchronization before the piconet channel has been established, or when an existing piconet changes to a new piconet. However, the FHS packet is not used by Connectionless Peripheral Broadcast Receivers for frequency hop synchronization with Connectionless Peripheral Broadcast Transmitters.

Figure 6.9: Format of the FHS payload

Each field is described in more detail below:

Parity bits	This 34-bit field contains the parity bits that form the first part of the sync word of the access code of the device that sends the FHS packet. These bits are derived from the LAP as described in Section 1.2.
LAP	This 24-bit field shall contain the lower address part of the device that sends the FHS packet.
EIR	This bit shall indicate that an extended inquiry response packet may follow. See Section 8.4.3.
Reserved	This 1-bit field is reserved for future use.
SR	This 2-bit field is the page scan repetition mode field and indicates the interval between two consecutive page scan windows, see also Table 6.4 and Table 8.1
SP	This 2-bit field shall be set to 0b10.
UAP	This 8-bit field shall contain the upper address part of the device that sends the FHS packet.
NAP	This 16-bit field shall contain the non-significant address part of the device that sends the FHS packet (see also Section 1.2 for LAP, UAP, and NAP).
Class of Device	This 24-bit field shall contain the Class of Device of the device that sends the FHS packet. The field is defined in Assigned Numbers.
LT_ADDR	This 3-bit field shall contain the logical transport address the recipient shall use if the FHS packet is used at connection setup or role switch. A Peripheral responding to a Central or a device responding to an inquiry request message shall include an all-zero LT_ADDR field if it sends the FHS packet.
CLK27-2	This 26-bit field shall contain the value of the native clock of the device that sends the FHS packet, sampled at the beginning of the transmission of the access code of this FHS packet. This clock value has a resolution of 1.25 ms (two-slot interval). For each new transmission, this field is updated so that it accurately reflects the real-time clock value.

Table 6.3: Description of the FHS payload

The device sending the FHS shall set the SR bits according to Table 6.4.

SR bit format b1b0	SR (page scan repetition) mode
00	R0
01	R1
10	R2
11	Reserved for future use

Table 6.4: Contents of SR field

The LAP, UAP, and NAP together form the 48-bit Bluetooth Device Address of the device that sends the FHS packet. Using the parity bits and the LAP, the recipient can directly construct the channel access code of the sender of the FHS packet.

When initializing the HEC and CRC for the FHS packet of inquiry response, the UAP shall be the DCI.

HV and DV packets are used on the synchronous SCO logical transport. The HV packets do not include a MIC or CRC and shall not be retransmitted. DV packets include a CRC on the data section, but not on the synchronous data section. DV packets do not include a MIC. The data section of DV packets shall be retransmitted. SCO packets may be routed to the synchronous I/O port. Four packets are allowed on the SCO logical transport: HV1, HV2, HV3 and DV. These packets are typically used for 64 kb/s speech transmission but may be used for transparent synchronous data.

SCO packets shall only be encrypted with E0 when E0 is enabled. SCO packets shall not be sent when AES-CCM Encryption is enabled.

6.5.2.4. DV packet

The DV packet is a combined data - voice packet. The DV packet shall only be used in place of an HV1 packet. The payload is divided into a voice field of 80 bits and a data field containing up to 150 bits, see Figure 6.10. The voice field is not protected by FEC. The data field has between 1 and 10 information bytes (including the 1-byte payload header) plus a 16-bit CRC code. No MIC is present. The data field (including the CRC) is encoded with a rate 2/3 FEC. Since the DV packet has to be sent at regular intervals due to its synchronous contents, it is listed under the SCO packet types. The voice and data fields shall be treated separately. The voice field shall be handled in the same way as normal SCO data and shall never be retransmitted; that is, the voice field is always new. The data field is checked for errors and shall be retransmitted if necessary. When the asynchronous data field in the DV packet has not been acknowledged before the SCO logical transport is terminated, the asynchronous data field shall be retransmitted in a DM1 packet.

Figure 6.10: DV packet format

EV packets are used on the synchronous eSCO logical transport. The packets include a CRC and retransmission may be applied if no acknowledgment of proper reception is received within the retransmission window. No MIC is present. eSCO packets may be routed to the synchronous I/O port. Three eSCO packet types (EV3, EV4, EV5) are defined for Basic Rate operation and four additional eSCO packet types (2-EV3, 3-EV3, 2-EV5, 3-EV5) for Enhanced Data Rate operation. The eSCO packets may be used for 64 kb/s speech transmission as well as transparent data at 64 kb/s and other rates.

ACL packets are used on the asynchronous logical transport and the CPB logical transport. The information carried may be user data for either logical transport or control data for the asynchronous logical transport.

Six packet types are defined for Basic Rate operation: DM1, DH1, DM3, DH3, DM5, and DH5. Six additional packets are defined for Enhanced Data Rate operation: 2-DH1, 3-DH1, 2-DH3, 3-DH3, 2-DH5 and 3-DH5. The AUX1 packet is also defined for test purposes.

The length indicator in the payload header specifies the number of user bytes (excluding payload header, MIC and the CRC code).

In SCO, which is only supported in Basic Rate mode, the synchronous data field has a fixed length and consists only of the synchronous data body portion. No payload header is present.

In Basic Rate eSCO, the synchronous data field consists of two segments: a synchronous data body and a CRC code. No payload header is present.

In Enhanced Data Rate eSCO, the synchronous data field consists of five segments: a guard time, a synchronization sequence, a synchronous data body, a CRC code and a trailer. No payload header is present.

Basic rate ACL packets have an asynchronous data field consisting of two, three or four segments: a payload header, a payload body, possibly a MIC, and possibly a CRC code.

Enhanced Data Rate ACL packets have an asynchronous data field consisting of six or seven segments: a guard time, a synchronization sequence, a payload header, a payload body, possibly a MIC, a CRC and a trailer.

The HEC generating LFSR is depicted in Figure 7.3. The generator polynomial is g(D) = (D + 1)(D⁷ + D⁴ + D³ + D² + 1) = D⁸ + D⁷ + D⁵ + D² + D + 1. Initially this circuit shall be pre-loaded with the 8-bit UAP such that the LSB of the UAP (denoted UAP₀) goes to the left-most shift register element, and, UAP₇ goes to the right-most element. The initial state of the HEC LFSR is depicted in Figure 7.4. Then the data shall be shifted in with the switch S set in position 1. When the last data bit has been clocked into the LFSR, the switch S shall be set in position 2, and, the HEC can be read out from the register. The LFSR bits shall be read out from right to left (i.e., the bit in position 7 is the first to be transmitted, followed by the bit in position 6, etc.).

Figure 7.3: LFSR circuit generating the HEC

Figure 7.4: Initial state of the HEC generating circuit

Figure 7.5: HEC generation and checking

The 16 bit LFSR for the CRC is constructed similarly to the HEC using the CRC-CCITT generator polynomial g(D) = D¹⁶ + D¹² + D⁵ + 1 (i.e., 0x11021) (see Figure 7.6). For this case, the 8 left-most bits shall be initially loaded with the 8-bit UAP (UAP₀ to the left and UAP₇ to the right) while the 8 right-most bits shall be reset to zero. The initial state of the 16 bit LFSR is specified in Figure 7.7. The switch S shall be set in position 1 while the data is shifted in. After the last bit has entered the LFSR, the switch shall be set in position 2, and, the register’s contents shall be transmitted, from right to left (i.e., starting with position 15, then position 14, etc.).

Figure 7.6: The LFSR circuit generating the CRC

Figure 7.7: Initial state of the CRC generating circuit

Figure 7.8: CRC generation and checking

Bluetooth uses a fast, unnumbered acknowledgment scheme. An ACK (ARQN=1) or a NAK (ARQN=0) is returned in response to the receipt of a previously received packet. The Peripheral shall respond in the Peripheral-to-Central slot directly following the Central-to-Peripheral slot unless the Peripheral has scatternet commitments in that timeslot; the Central shall respond at the next event addressing the same Peripheral (the Central may have addressed other Peripherals between the last received packet from the considered Peripheral and the Central’s response to this packet). A packet reception is successful if the HEC passes and, when present, the MIC and CRC pass.

In the first POLL packet at the start of a new connection (as a result of a page, page scan, or role switch) the Central shall initialize the ARQN bit to NAK. The response packet sent by the Peripheral shall also have the ARQN bit set to NAK. The subsequent packets shall use the following rules. The initial value of the Central’s eSCO ARQN at link set-up shall be NAK.

The ARQN bit shall only be affected by data packets containing CRC and empty slots. As shown in Figure 7.12, Figure 7.13, and Figure 7.14, upon successful reception of a CRC packet, the ARQN bit shall be set to ACK. If, in any receive slot in the Peripheral, or, in a receive slot in the Central following transmission of a packet, one of these events applies:

then the ARQN bit shall be set to NAK except in the conditions below:

Packets that have correct HEC but that are addressed to other Peripherals, or packets other than DH, DM, DV or EV packets, shall not affect the ARQN bit, except as noted in Section 7.6.2.2. In these cases the ARQN bit shall be left as it was prior to reception of the packet. For eSCO packets, the SEQN shall not be used when determining the ARQN. If an eSCO packet has been received successfully within the eSCO window subsequent receptions within the eSCO window shall be ignored. At the end of the eSCO window, the Central’s ARQN shall be retained for the first Central-to-Peripheral transmission in the next eSCO window.

The ARQN bit in the FHS packet is not meaningful. Contents of the ARQN bit in the FHS packet shall not be checked.

The ARQN bit in the extended inquiry response packet is reserved for future use.

Broadcast packets shall be checked on errors using the CRC, but no ARQ scheme shall be applied. Broadcast packets shall never be acknowledged.

In Figure 7.12, TX refers to the next transmission that the device makes, which might not be in the next slot. NO TX indicates that the device is not allowed to transmit in the next slot.

In Figure 7.14, "Packet OK" means that the packet has an allowed TYPE for the connection and the CRC is valid.

Figure 7.12: Stage 1 of the receive protocol for determining the ARQN bit

Figure 7.13: Stage 2 (ACL) of the receive protocol for determining the ARQN bit

Figure 7.14: Stage 2 (eSCO) of the receive protocol for determining the ARQN bit

The data payload shall be transmitted until a positive acknowledgment is received or a timeout is exceeded. A retransmission shall be carried out either because the packet transmission itself failed, or because the acknowledgment transmitted in the return packet failed (which has a lower failure probability since the header is more heavily coded). In the latter case, the destination keeps receiving the same payload over and over again. In order to filter out the retransmissions in the destination, the SEQN bit is present in the header. Normally, this bit is alternated for every new CRC data payload transmission. In case of a retransmission, this bit shall not be changed so the destination can compare the SEQN bit with the previous SEQN value. If different, a new data payload has arrived; otherwise it is the same data payload and may be ignored. Only new data payloads shall be transferred to the Baseband Resource Manager.

7.6.2.2. ACL and SCO retransmit filtering

The SEQN bit shall only be affected by the CRC data packets as shown in Figure 7.15. It shall be inverted every time a new CRC data packet is sent. The CRC data packet shall be retransmitted with the same SEQN number until an ACK is received or the packet is flushed. When an ACK is received, a new payload may be sent and on that transmission the SEQN bit shall be inverted. If a device decides to flush (see Section 7.6.3), and it has not received an acknowledgment for the current packet, it shall replace the current packet with an ACL-U continuation packet with the same sequence number as the current packet and length zero. If it replaces the current packet in this way it shall not move on to transmit the next packet until it has received an ACK.

If the Peripheral receives a packet other than DH, DM, DV or EV with the SEQN bit inverted from that in the last header successfully received on the same LT_ADDR, it shall set the ARQN bit to NAK until a DH, DM, DV or EV packet is successfully received.

Figure 7.15: Transmit filtering for packets with CRC

On ACL logical transports, the ARQ scheme can cause variable delay in the traffic flow since retransmissions are inserted to assure error-free data transfer. For certain communication links, only a limited amount of delay is allowed: retransmissions are allowed up to a certain limit at which the current payload shall be ignored. This data transfer is indicated as isochronous traffic. This means that the retransmit process must be overruled in order to continue with the next data payload. Aborting the retransmit scheme is accomplished by flushing the old data and forcing the Link Controller to take the next data instead.

Flushing results in loss of remaining portions of an L2CAP message. Therefore, the packet following the flush shall have a start packet indication of LLID = 10 in the payload header for the next L2CAP message. This informs the destination of the flush (see Section 6.6). Flushing will not necessarily result in a change in the SEQN bit value, see the previous section.

The Flush Timeout defines a maximum period after which all segments of the ACL-U packet with a Packet_Boundary_Flag value of 10 are flushed from the Controller buffer. The Flush Timeout shall start when the First segment of the ACL-U packet is stored in the Controller buffer. If the First segment of an ACL-U packet has a Packet_Boundary_Flag value of 00, it is non-automatically-flushable and shall not cause the Flush Timeout to start. After the Flush timeout has expired the Link Controller may continue transmissions according to the procedure described in Section 7.6.2.2, however the Baseband Resource Manager shall not continue the transmission of the ACL-U packet to the Link Controller. If the Baseband Resource Manager has further segments of the packet queued for transmission to the Link Controller it shall delete the remaining segments of the ACL-U packet from the queue. In case the complete ACL-U packet was not stored in the Controller buffer yet, any Continuation segments, received for the ACL logical transport, shall be flushed, until a First segment is received. When the complete ACL-U packet has been flushed, the Link Manager shall continue transmission of the next ACL-U packet for the ACL logical transport. The default Flush Timeout shall be infinite, i.e. re-transmissions are carried out until physical link loss occurs. This is also referred to as a 'reliable channel.' All devices shall support the default Flush Timeout. Reliable data shall be sent over a channel with a finite flush timeout by marking reliable packets as non-automatically-flushable.

On eSCO logical transports, packets shall be automatically flushed at the end of the eSCO window.

Connectionless Peripheral Broadcast packets are transmitted at each scheduled Connectionless Peripheral Broadcast Instant. If no new data is available, the Connectionless Peripheral Broadcast Transmitter shall transmit a packet with the last available data in the payload.

In a piconet with multiple logical transports, the Central shall carry out the ARQ protocol independently on each logical transport.

APB broadcast packets are packets transmitted by the Central to all the Peripherals simultaneously (see Section 8.6.4) If multiple hop sequences are being used each transmission may only be received by some of the Peripherals. In this case the Central shall repeat the transmission on each hop sequence. An APB broadcast packet shall be indicated by the all-zero LT_ADDR.

Broadcast packets shall not be acknowledged (at least not at the LC level), hence each broadcast packet is transmitted at least a fixed number of times. An APB broadcast packet should be transmitted N_BC times before the next broadcast packet of the same broadcast message is transmitted, see Figure 7.16. Optionally, an APB broadcast packet may be transmitted N_BC + 1 times, so N_BC=1 means that each broadcast packet should be sent only once but may be sent twice. However, time-critical broadcast information may abort the ongoing broadcast train. In addition, an LMP packet sent on the APB-C logical link is always a complete message for these purposes and is always sent exactly once; the LMP specification may provide requirements for whether and when to send another message with the same or related contents.

If multiple hop sequences are being used then the Central may transmit on the different hop sequences in any order, providing that transmission of a new broadcast packet shall not be started until all transmissions of any previous broadcast packet have completed on all hop sequences. The transmission of a single broadcast packet may be interleaved among the hop sequences to minimize the total time to broadcast a packet. The Central has the option of transmitting only N_BC times on channels common to all hop sequences.

APB broadcast packets with a CRC shall have their own sequence number. The SEQN of the first broadcast packet with a CRC shall be set to SEQN = 1 by the Central and shall be inverted for each new broadcast packet with CRC thereafter. APB broadcast packets without a CRC have no influence on the sequence number. The Peripheral shall accept the SEQN of the first broadcast packet it receives in a connection and shall check for change in SEQN for subsequent broadcast packets. Since there is no acknowledgment of broadcast messages and there is no end packet indication, it is important to receive the start packets correctly. To ensure this, repetitions of the broadcast packets that are L2CAP start packets and LMP packets shall not be filtered out. These packets shall be indicated by LLID=1X in the payload header as explained in Table 6.5. Only repetitions of the L2CAP continuation packets shall be filtered out.

Figure 7.16: Broadcast repetition scheme

In the Page Scan substate, a device may be configured to use either the standard or generalized interlaced scanning procedure. During a standard scan, a device listens for the duration of the scan window T_{w_page_scan} (11.25 ms default, see HCI [Vol 4] Part E, Section 7.3.20), while the generalized interlaced scan is performed as two back to back scans of T_{w_page_scan}. If the scan interval is not at least twice the scan window, then generalized interlaced scan shall not be used. During each scan window, the device shall listen at a single hop frequency, its correlator matched to its device access code (DAC). The scan window shall be long enough to completely scan 16 page frequencies.

When a device enters the Page Scan substate, it shall select the scan frequency according to the page hopping sequence determined by the device's Bluetooth Device Address, see Section 2.6.4.1. The phase in the sequence shall be determined by CLKN_16-12 of the device’s native clock; that is, every 1.28 s a different frequency is selected.

In the case of a standard scan, if the correlator exceeds the trigger threshold during the page scan, the device shall enter the Peripheral Page Response substate described in Section 8.3.3.1. The scanning device may also use generalized interlaced scan. In this case, if the correlator does not exceed the trigger threshold during the first scan it shall scan a second time using the phase in the sequence determined by [CLKN_16-12 + interlace_offset] mod 32. If on this second scan the correlator exceeds the trigger threshold the device shall enter the Peripheral Page Response substate using [CLKN_16-12 + interlace_offset] mod 32 as the frozen CLKN* in the calculation for Xprp (see Section 2.6.4.3 for details). If the correlator does not exceed the trigger threshold during a scan in normal mode or during the second scan in interlaced scan mode it shall return to either the Standby or Connection state.

The interlace_offset value ranges from 0 to 31. The value 16 should be used unless the pattern of slots that are not available for scanning implies a different value should be used.

The Page Scan substate can be entered from the Standby state or the Connection state. In the Standby state, no connection has been established and the device can use all the capacity to carry out the page scan. Before entering the Page Scan substate from the Connection state, the device should reserve as much capacity as possible for scanning. If desired, the device may place ACL connections in Hold mode (see Section 8.8) or Sniff mode (see Section 8.7). Synchronous connections should not be interrupted by the page scan, although eSCO retransmissions should be paused during the scan. The page scan may be interrupted by the reserved synchronous slots which should have higher priority than the page scan. SCO packets should be used requiring the least amount of capacity (HV3 packets). The scan window shall be increased to minimize the setup delay. If one SCO logical transport is present using HV3 packets and T_SCO=6 slots or one eSCO logical transport is present using EV3 packets and T_eSCO=6 slots, a total scan window T_{w_page_scan} of at least 36 slots (22.5 ms) is recommended; if two SCO links are present using HV3 packets and T_SCO=6 slots or two eSCO links are present using EV3 packets and T_eSCO=6 slots, a total scan window of at least 54 slots (33.75 ms) is recommended.

The scan interval T_{page_scan} is defined as the interval between the beginnings of two consecutive page scans. A distinction is made between the case where the scan interval is equal to the scan window T_{w_page_scan} (continuous scan), the scan interval is maximal 1.28 s, or the scan interval is maximal 2.56 s. These three cases shall determine the behavior of the paging device; that is, whether the paging device shall use R0, R1 or R2, see also Section 8.3.2. Table 8.1 illustrates the relationship between T_{page_scan} and modes R0, R1 and R2. Although scanning in the R0 mode is continuous, the scanning may be interrupted for example by reserved synchronous slots. The scan interval information (also known as the page scan repetition mode) is included in the SR field in the FHS packet.

The Page substate is used by the Central (source) to activate and connect to a Peripheral (destination) in the Page Scan substate. The Central tries to coincide with the Peripheral's scan activity by repeatedly transmitting the paging message consisting of the Peripheral’s device access code (DAC) in different hop channels. Since the Bluetooth clocks of the Central and the Peripheral are not synchronized, the Central does not know exactly when the Peripheral wakes up and on which hop frequency. Therefore, it transmits a train of identical page messages at different hop frequencies and listens in between the transmit intervals until it receives a response from the Peripheral.

The page procedure in the Central consists of a number of steps. First, the Host communicates the BD_ADDR of the Peripheral to the Controller. This BD_ADDR shall be used by the Central to determine the page hopping sequence; see Section 2.6.4.2. If the BD_ADDR of the Peripheral is identical to the BD_ADDR of the Central, then the Central's Controller shall reject the page procedure. For the phase in the sequence, the Central shall use an estimate of the Peripheral’s clock. For example, this estimate can be derived from timing information that was exchanged during the last encounter with this particular device (which could have acted as a Central at that time), or from an inquiry procedure. With this estimate CLKE of the Peripheral’s Bluetooth clock, the Central can predict on which hop channel the Peripheral starts page scanning.

The estimate of the Bluetooth clock in the Peripheral can be completely wrong. Although the Central and the Peripheral use the same hopping sequence, they use different phases in the sequence and might never select the same frequency. To compensate for the clock drifts, the Central shall send its page message during a short time interval on a number of wake-up frequencies. It shall transmit also on hop frequencies just before and after the current, predicted hop frequency. During each TX slot, the Central shall sequentially transmit on two different hop frequencies. In the following RX slot, the receiver shall listen sequentially to two corresponding RX hops for an ID packet. The RX hops shall be selected according to the page response hopping sequence. The page response hopping sequence is strictly related to the page hopping sequence: for each page hop there is a corresponding page response hop. The RX/TX timing in the Page substate is described in Section 2.2.5, see also Figure 2.7. In the next TX slot, the Central shall transmit on two hop frequencies different from the former ones.

With the increased hopping rate as described above, the transmitter can cover 16 different hop frequencies in 16 slots or 10 ms. The page hopping sequence is divided over two paging trains A and B of 16 frequencies. Train A includes the 16 hop frequencies surrounding the current, predicted hop frequency f(k), where k is determined by the clock estimate CLKE_16-12. The first train consists of hops

f(k-8), f(k-7),...,f(k),...,f(k+7)

When the difference between the Bluetooth clocks of the Central and the Peripheral is between -8x1.28 s and +7x1.28 s, one of the frequencies used by the Central will be the hop frequency the Peripheral will listen to. Since the Central does not know when the Peripheral will enter the Page Scan substate, the Central has to repeat this train A N_page times or until a response is obtained, whichever is shorter. If the Peripheral scan interval corresponds to R1, the repetition number is at least 128; if the Peripheral scan interval corresponds to R2 or if the Central has not previously read the Peripheral's SR (page scan repetition) mode, the repetition number is at least 256. If the Central has not previously read the Peripheral's SR mode it shall use N_page >= 256.

When the difference between the Bluetooth clocks of the Central and the Peripheral is less than -8x1.28 s or larger than +7x1.28 s, the remaining 16 hops are used to form the new 10 ms train B. The second train consists of hops

f(k-16), f(k-15),...,f(k-9),f(k+8)...,f(k+15)

Train B shall be repeated for N_page times. If no response is obtained, k_nudge may be updated in the case where slots to receive are periodically not available and train A shall be tried again N_page times. Alternate use of train A and train B and updates of k_nudge shall be continued until a response is received or the timeout pageTO + extended_pageTO is exceeded. If a response is returned by the Peripheral, the Central enters the Central Page Response substate.

The Page substate may be entered from the Standby state or the Connection state. In the Standby state, no connection has been established and the device can use all the capacity to carry out the page. Before entering the Page substate from the Connection state, the device should free as much capacity as possible for paging. To ensure this, it is recommended that the ACL connections are put on hold. However, the synchronous connections shall not be disturbed by the page. This means that the page will be interrupted by the reserved SCO and eSCO slots which have higher priority than the page. In order to obtain as much capacity for paging, it is recommended to use the SCO packets which use the least amount of capacity (HV3 packets). If SCO or eSCO links are present, the repetition number N_page of a single train shall be increased, see Table 8.2. Here it has been assumed that the HV3 packet are used with an interval T_SCO=6 slots or EV3 packets are used with an interval of T_eSCO=6 slots, which would correspond to a 64 kb/s synchronous link.

The construction of the page train shall be independent of the presence of synchronous links; that is, synchronous packets are sent on the reserved slots but shall not affect the hop frequencies used in the unreserved slots, see Figure 8.2.

Figure 8.2: Conventional page (a), page while one synchronous link present (b), page while two synchronous links present (c)

When a page message is successfully received by the Peripheral, there is a coarse frequency hopping synchronization between the Central and the Peripheral. Both the Central and the Peripheral enter a response substate to exchange vital information to continue the connection setup. It is important for the piconet connection that both devices shall use the same channel access code, use the same channel hopping sequence, and their clocks are synchronized. These parameters shall be derived from the Central. The device that initializes the connection (starts paging) is defined as the Central (which is thus only valid during the time the piconet exists). The channel access code and channel hopping sequence shall be derived from the Bluetooth Device Address (BD_ADDR) of the Central. The timing shall be determined by the Central's clock. An offset shall be added to the Peripheral’s native clock to temporarily synchronize the Peripheral's clock to the Central's clock. At start-up, the Central's parameters are transmitted from the Central to the Peripheral. The messaging between the Central and the Peripheral at start-up is specified in this section.

If Central and Peripheral are already connected (irrespective of roles) then the Peripheral shall either ignore the page or shall immediately close the existing connection without sending any further packets relating to that connection and then continue with the page response procedure.

If the BD_ADDR of the Central is identical to the BD_ADDR of the Peripheral, then the Peripheral's Controller shall ignore the page and end the page response procedure.

The initial messaging between Central and Peripheral is shown in Table 8.3 and in Figure 8.3 and Figure 8.4. In those two figures frequencies f (k), f(k+1), etc. are the frequencies of the page hopping sequence determined by the Peripheral’s BD_ADDR. The frequencies f’(k), f’(k+1), etc. are the corresponding page_response frequencies (Peripheral-to-Central). The frequencies g(m) belong to the basic channel hopping sequence.

In step 1 (see Table 8.3), the Central is in Page substate and the Peripheral in the Page Scan substate. Assume in this step that the page message sent by the Central reaches the Peripheral. On receiving the page message, the Peripheral enters the Peripheral Page Response substate in step 2. The Central waits for a reply from the Peripheral and when this arrives in step 2, it shall enter the Central Page Response substate in step 3.

Figure 8.3: Messaging at initial connection when Peripheral responds to first page message

Figure 8.4: Messaging at initial connection when Peripheral responds to second page message

In the case of the truncated page procedure, the messaging stops after step 2 in the sequence shown in Table 8.3. This procedure is illustrated in Figure 8.5 and Figure 8.6.

Figure 8.5: First half slot truncated page

Figure 8.6: Second half slot truncated page

The Inquiry Scan substate is very similar to the Page Scan substate. However, instead of scanning for the device's device access code, the receiver shall scan for the inquiry access code long enough to completely scan for 16 inquiry frequencies. Two types of scans are defined: standard and generalized interlaced. In the case of a standard scan the length of this scan period is denoted T_{w_inquiry_scan} (11.25 ms default, see HCI [Vol 4] Part E, Section 7.3.22). The standard scan is performed at a single hop frequency as defined by Xir_4-0 (see Section 2.6.4.6). The generalized interlaced scan is performed as two back to back scans of T_{w_inquiry_scan} where the first scan is on the normal hop frequency and the second scan is defined by [Xir_4-0 + interlace_offset] mod 32. If the scan interval is not at least twice the scan window then generalized interlaced scan shall not be used. The inquiry procedure uses 32 dedicated inquiry hop frequencies according to the inquiry hopping sequence. These frequencies are determined by the general inquiry address. The phase is determined by the native clock of the device carrying out the inquiry scan; the phase changes every 1.28 s.

The interlace_offset value ranges from 0 to 31. The value 16 should be used unless the pattern of slots that are not available for scanning implies a different value should be used.

Instead of, or in addition to, the general inquiry access code, the device may scan for one or more dedicated inquiry access codes. However, the scanning shall follow the inquiry scan hopping sequence determined by the general inquiry address. If an inquiry message is received during an inquiry wake-up period, the device shall enter the Inquiry Response substate.

The Inquiry Scan substate can be entered from the Standby state or the Connection state. In the Standby state, no connection has been established and the device can use all the capacity to carry out the inquiry scan. Before entering the Inquiry Scan substate from the Connection state, the device should reserve as much capacity as possible for scanning. If desired, the device may place ACL logical transports in Sniff mode or Hold mode. Synchronous logical transports are preferably not interrupted by the inquiry scan, although eSCO retransmissions should be paused during the scan. In this case, the inquiry scan may be interrupted by the reserved synchronous slots. SCO packets should be used requiring the least amount of capacity (HV3 packets). The scan window, T_{w inquiry scan}, shall be increased to increase the probability to respond to an inquiry message. If one SCO logical transport is present using HV3 packets and T_SCO=6 slots or one eSCO logical transport is present using EV3 packets and T_eSCO=6 slots, a total scan window of at least 36 slots (22.5 ms) is recommended; if two SCO links are present using HV3 packets and T_SCO=6 slots or two eSCO links are present using EV3 packets and T_eSCO=6 slots, a total scan window of at least 54 slots (33.75 ms) is recommended.

The scan interval T_{inquiry scan} is defined as the interval between two consecutive inquiry scans. The inquiry scan interval shall be less than or equal to 2.56 s.

The Inquiry substate is used to discover new devices. This substate is very similar to the Page substate; the TX/RX timing shall be the same as in paging, see Section 2.4.4 and Figure 2.7. The TX and RX frequencies shall follow the inquiry hopping sequence and the inquiry response hopping sequence, and are determined by the general inquiry access code and the native clock of the discovering device. In between inquiry transmissions, the receiver shall scan for inquiry response messages. When a response is received, the entire packet (an FHS packet) shall be read. If the EIR bit in the FHS packet is set to one, the device should try to receive the extended inquiry response packet 1250 μs after the start of the FHS packet. After this, the device shall continue with inquiry transmissions. The device in an Inquiry substate shall not acknowledge the inquiry response messages. If enabled by the Host (see HCI [Vol 4] Part E, Section 7.3.50), the RSSI value of the inquiry response message shall be measured. It shall keep probing at different hop channels and in between listening for response packets. As in the Page substate, two 10 ms trains A and B are defined, splitting the 32 frequencies of the inquiry hopping sequence into two 16-hop parts. A single train shall be repeated for at least N_inquiry=256 times before a new train is used. In order to collect all responses in an error-free environment, at least three train switches must have taken place. As a result, the Inquiry substate may have to last for 10.24 s unless the inquirer collects enough responses and aborts the Inquiry substate earlier. If desired, the inquirer may also prolong the Inquiry substate to increase the probability of receiving all responses in an error-prone environment. When some receive slots are periodically not available, it may require up to 31 train switches to collect all responses in an error-free environment, depending on the pattern of the available receive slots. Before each switch to train A, k_nudge may be updated. As a result, the Inquiry substate may have to last for 40.96 s. If an inquiry procedure is automatically initiated periodically (say a 10 s period every minute), then the interval between two inquiry instances shall be determined randomly. This is done to avoid two devices synchronizing their inquiry procedures.

The Inquiry substate is continued until stopped by the Baseband Resource Manager (when it decides that it has sufficient number of responses), when a timeout has been reached (Inquiry_Length + Extended_Inquiry_Length), or by a command from the Host to cancel the inquiry procedure.

The Inquiry substate can be entered from the Standby state or the Connection state. In the Standby state, no connection has been established and the device can use all the capacity to carry out the inquiry. Before entering the Inquiry substate from the Connection state, the device should free as much capacity as possible for inquiry. To ensure this, it is recommended that the ACL logical transports are placed in Sniff mode or Hold mode. However, the reserved slots of synchronous logical transports shall not be disturbed by the inquiry. This means that the inquiry will be interrupted by the reserved SCO and eSCO slots which have higher priority than the inquiry. In order to obtain as much capacity as possible for inquiry, it is recommended to use the SCO packets which use the least amount of capacity (HV3 packets). If SCO or eSCO links are present, the repetition number N_inquiry shall be increased, see Table 8.4.

Here it has been assumed that HV3 packets are used with an interval T_SCO=6 slots or EV3 packets are used with an interval of T_eSCO=6 slots, which would correspond to a 64 kb/s synchronous link.

If an extended inquiry response packet could not be received because of higher priority traffic, the reception failed due to HEC or CRC failure, or because the packet type is not supported by the device, the inquiry response shall be reported to higher layers as an extended inquiry response with all-zero data.

The response substate for inquiries differs completely from the Peripheral Page Response substate applied for pages. When the inquiry message is received in the Inquiry Scan substate, the recipient shall return an inquiry response (FHS) packet containing the recipient's device address (BD_ADDR) and other parameters. If the recipient has non-zero extended inquiry response data to send it shall return an extended inquiry response packet after the FHS packet.

The following protocol in the Peripheral's inquiry response shall be used. On the first inquiry message received in the Inquiry Scan substate the Peripheral shall enter the Inquiry Response substate. If the Peripheral has non-zero extended inquiry response data to send it shall return an FHS packet with the EIR bit set to one to the Central 625 μs after the inquiry message was received. It shall then return an extended inquiry response packet 1250 μs after the start of the FHS packet. If the Peripheral's extended inquiry response data is all zeroes the Peripheral shall only return an FHS packet with the EIR bit set to zero. A contention problem could arise when several devices are in close proximity to the inquiring device and all respond to an inquiry message at the same time. However, because every device has a free running clock it is highly unlikely that they all use the same phase of the inquiry hopping sequence. In order to avoid repeated collisions between devices that wake up in the same inquiry hop channel simultaneously, a device shall back-off for a random period of time. Thus, if the device receives an inquiry message and returns an FHS packet, it shall generate a random number, RAND, between 0 and MAX_RAND. For scanning intervals ≥ 1.28 s MAX_RAND shall be 1023, however, for scanning intervals < 1.28 s MAX_RAND may be as small as 127. A profile that uses a special DIAC may choose to use a smaller MAX_RAND than 1023 even when the scanning interval is ≥ 1.28 s. The Peripheral shall return to the Connection or Standby state for the duration of at least RAND time slots. Before returning to the Connection and Standby state, the device may go through the Page Scan substate. After at least RAND slots, the device shall add an offset of 1 to the phase in the inquiry hop sequence (the phase has a 1.28 s resolution) and return to the Inquiry Scan substate again. If the Peripheral is triggered again, it shall repeat the procedure using a new RAND. The offset to the clock accumulates each time an FHS packet is returned. During a probing window, a Peripheral may respond multiple times, but on different frequencies and at different times. Reserved synchronous slots should have priority over response packets; that is, if a response packet overlaps with a reserved synchronous slot, it shall not be sent but the next inquiry message is awaited. If a device has extended inquiry response data to send but the extended inquiry response packet overlaps with a reserved synchronous slot the FHS packet may be sent with the EIR bit set to zero.

The messaging during the inquiry routines is summarized in Table 8.5. In step 1, the Central transmits an inquiry message using the inquiry access code and its own clock. The Peripheral responds with the FHS packet containing the Peripheral’s Bluetooth Device Address, native clock and other Peripheral information. This FHS packet is returned at times that tend to be random. The FHS packet is not acknowledged in the inquiry routine, but it is retransmitted at other times and frequencies as long as the Central is probing with inquiry messages. If the Peripheral has non-zero extended inquiry response data it sends an extended inquiry response packet to the Central in step 3.

The extended inquiry response packet is an ACL packet with type DM1, DM3, DM5, DH1, DH3 or DH5. To minimize interference it is recommended to use the shortest packet that fits the data. The packet shall be sent on the same frequency as the FHS packet, 1250 µs after the start of the FHS packet. In the packet header, LT_ADDR shall be set to zero. TYPE shall be one of DM1, DM3, DM5, DH1, DH3 or DH5. FLOW, ARQN and SEQN shall all be set to zero and ignored during receipt. The HEC LFSR shall be initialized with the same DCI (default check initialization) as for the FHS packet. In the payload header, LLID shall contain the value 10 (start of an L2CAP message or no fragmentation). FLOW shall be set to zero and ignored upon receipt. The length of the payload body (LENGTH) shall be smaller than or equal to 240 bytes. The CRC LFSR shall be initialized with the same DCI as for the FHS packet. The data whitening LFSR shall be initialized with the same value as for the FHS packet.

The payload data has two parts, a significant part followed by a non-significant part. The significant part contains a sequence of data structures as defined in [Vol 3] Part C, Section 8. The non-significant part contains all-zero octets.

The Baseband shall not change any octets in the significant part. When transmitting data, the non-significant part octets may be omitted from the payload.

A device shall store a single extended inquiry response packet. This packet shall be used with all IACs.

The Central always has full control over the piconet. Due to the TDD scheme, Peripherals can only communicate with the Central and not other Peripherals. In order to avoid collisions on the ACL logical transport, a Peripheral is only allowed to transmit in the Peripheral-to-Central slot when addressed by the LT_ADDR in the packet header in the preceding Central-to-Peripheral slot. If the LT_ADDR in the preceding slot does not match, or a valid packet header was not received, the Peripheral shall not transmit.

The Central normally attempts to poll a Peripheral's ACL logical transport no less often than once every T_poll slots. T_poll is set by the Link Manager (see [Vol 2] Part C, Section 4.1.8).

The Peripheral's ACL logical transport may be polled with any packet type except for FHS and ID. For example, polling during SCO may use HV packets, since the Peripheral may respond to an HV packet with a DM1 packet (see Section 8.6.2).

The SCO logical transport shall be established by the Central sending a SCO setup message via the LM protocol. This message contains timing parameters including the SCO interval T_SCO and the offset D_SCO to specify the reserved slots.

In order to prevent clock wrap-around problems, an initialization flag in the SCO setup message indicates whether initialization procedure 1 or 2 is being used. The Peripheral shall apply the initialization method as indicated by the initialization flag. The Central shall use initialization 1 when the MSB of the Central's current clock (CLK₂₇) is 0; it shall use initialization 2 when the MSB of the Central's current clock (CLK₂₇) is 1. The Central-to-Peripheral SCO slots reserved by the Central and the Peripheral shall be initialized on the slots for which the clock satisfies the applicable equation:

The Peripheral-to-Central SCO slots shall directly follow the reserved Central-to-Peripheral SCO slots. After initialization, the clock value CLK(k+1) for the next Central-to-Peripheral SCO slot shall be derived by adding the fixed interval T_SCO to the clock value of the current Central-to-Peripheral SCO slot:

The Central will send SCO packets to the Peripheral at regular intervals (the SCO interval T_SCO counted in slots) in the reserved Central-to-Peripheral slots. An HV1 packet can carry 1.25 ms of speech at a 64 kb/s rate. An HV1 packet shall therefore be sent every two time slots (T_SCO=2). An HV2 packet can carry 2.5 ms of speech at a 64 kb/s rate. An HV2 packet shall therefore be sent every four time slots (T_SCO=4). An HV3 packet can carry 3.75 ms of speech at a 64 kb/s rate. An HV3 packet shall therefore be sent every six time slots (T_SCO=6).

The Peripheral is allowed to transmit in the slot reserved for its SCO logical transport unless a packet with the correct access code was received in the preceding slot and the LT_ADDR did not address this Peripheral (irrespective of whether or not the HEC was correct). If the correct LT_ADDR was received in the preceding slot but the HEC was incorrect, the Peripheral should not transmit in the reserved SCO slot.

Since the DM1 packet is recognized on the SCO logical transport, it may be sent during the SCO reserved slots if a valid packet header with the primary LT_ADDR is received in the preceding slot. DM1 packets sent during SCO reserved slots shall only be used to send ACL-C data.

The Peripheral shall not transmit anything other than an HV packet in a reserved SCO slot unless it decodes its own Peripheral address in the packet header of the packet in the preceding Central-to-Peripheral transmission slot.

The eSCO logical transport is established by sending an eSCO setup message via the LM protocol. This message contains timing parameters including the eSCO interval T_eSCO and the offset D_eSCO to specify the reserved slots.

To enter eSCO, the Central or Peripheral shall send an eSCO setup message via the LM protocol. This message shall contain the eSCO interval T_eSCO and an offset D_eSCO. In order to prevent clock wrap-around problems, an initialization flag in the eSCO setup message indicates whether initialization procedure 1 or 2 shall be used. The device sending the eSCO setup message shall use initialization 1 when the MSB of the Central's current clock (CLK₂₇) is 0; it shall use initialization 2 when the MSB of the Central's current clock (CLK₂₇) is 1. The device that receives the eSCO setup message shall apply the initialization method as indicated by the initialization flag. The Central-to-Peripheral eSCO slots reserved by the Central and the Peripheral shall be initialized on the slots for which the clock satisfies the applicable equation:

The Peripheral-to-Central eSCO slots shall directly follow the reserved Central-to-Peripheral eSCO slots. After initialization, the clock value CLK(k+1) for the next Central-to-Peripheral eSCO slot shall be found by adding the fixed interval T_eSCO to the clock value of the current Central-to-Peripheral eSCO slot:

When an eSCO logical transport is established, the Central shall assign an additional LT_ADDR to the Peripheral. This provides the eSCO logical transport with an ARQ scheme that is separate from that of the ACL logical transport. All traffic on a particular eSCO logical transport, and only that eSCO traffic, is carried on the eSCO LT_ADDR. The eSCO ARQ scheme uses the ARQN bit in the packet header, and operates similarly to the ARQ scheme on ACL links.

The Central may send a packet in the reserved Central-to-Peripheral slot. The Peripheral may transmit on the eSCO LT_ADDR in the following slot either if it received a packet on the eSCO LT_ADDR in the previous slot, or if it did not receive a valid packet header in the previous slot. When the Central-to-Peripheral packet type is a three-slot packet, the Peripheral’s transmit slot is the fourth slot of the eSCO reserved slots.

A Central shall transmit in an eSCO retransmission window on a given eSCO LT_ADDR only if it addressed that eSCO LT_ADDR or did not transmit any packet in the immediately preceding eSCO reserved slots. A Peripheral shall transmit in an eSCO retransmission window on a given eSCO LT_ADDR only if it received a valid packet header and that LT_ADDR on the eSCO channel in the previous Central-to-Peripheral transmission slot. The Central may transmit on any non-eSCO LT_ADDR in any Central-to-Peripheral transmission slot inside the eSCO retransmission window; if it addresses a Peripheral, that Peripheral may respond on the ACL channel as usual.

The Central shall only transmit on an eSCO LT_ADDR in the retransmission window if there are enough slots left for both the Central and Peripheral packets to complete in the retransmission window. If the Central is transmitting a NULL packet (with ARQN=ACK), then this requires one slot, otherwise it requires enough slots for the Central’s negotiated eSCO packet type plus:

The Central may refrain from transmitting in any slot during the eSCO retransmission window. When there is no data to transmit from Central to Peripheral, either due to the traffic being unidirectional or due to the Central-to-Peripheral packet having been ACK’ed, the Central shall use the POLL packet. When the Central-to-Peripheral packet has been ACK’ed, and the Peripheral-to-Central packet has been correctly received, the Central shall not address the Peripheral on the eSCO LT_ADDR until the next eSCO reserved slot, with the exception that the Central may transmit a NULL packet with ARQN=ACK on the eSCO LT_ADDR. If the Central is transmitting on the eSCO LT_ADDR during a retransmission slot and there is no data to transmit from Peripheral to Central, either due to the traffic being unidirectional or due to the Peripheral-to-Central packet having been ACK'ed, the Peripheral shall use NULL packets. eSCO traffic should be given priority over ACL traffic in the retransmission window.

Figure 8.9 shows the eSCO window when single slot packets are used.

Figure 8.9: eSCO window details for single-slot packets

When multi-slot packets are used in either direction of the eSCO logical transport, the first transmission continues into the following slots. The retransmission window in this case starts the slot after the end of the Peripheral-to-Central packet, i.e. two, four or six slots immediately following the eSCO instant are reserved and should not be used for other traffic. Figure 8.10 shows the eSCO window when multi-slot packets are used in one direction and single-slot packets are used in the other direction.

Figure 8.10: eSCO window details for asymmetric traffic

eSCO windows may overlap on the Central, but shall not overlap on an individual Peripheral.

In the reserved slots both Central and Peripheral shall only listen and transmit at their allocated slots at the first transmission time of each eSCO window. Intermittent lapses due to, for instance, time-critical signaling during connection establishment are allowed. Both Central and Peripheral may refrain from sending data and may use instead POLL and NULL packets respectively. When the Central transmits a POLL packet instead of an eSCO 3-slot packet, or the Peripheral does not receive anything in the reserved Central-to-Peripheral transmission slot, it shall start any transmission in the same slot as if the Central had transmitted the negotiated packet type. For example, if the Central had negotiated an EV5 packet the Peripheral would transmit three slots later. If the Central does not receive a Peripheral transmission in response to an eSCO packet it causes an implicit NAK of the packet in question. The listening requirements for the Peripheral during the retransmission window are the same as for an active ACL logical transport.

The Central of the piconet can broadcast messages to all Peripherals on the APB logical transport. An APB broadcast packet shall have an LT_ADDR set to all zero. If a new broadcast message carries APB-U data, it may be fragmented in the same way as ACL packets. Therefore it shall start with a packet carrying the start of L2CAP message indication (LLID=0b10) and may be followed by packets carrying the continuation of L2CAP message indication (LLID=0b01). If a new broadcast message carries APB-C data, it shall not be fragmented and shall consist of a single packet carrying the LMP message indication (LLID=0b11). In either case, the Central may carry out a number of retransmissions of each of these packets to increase the probability for error-free delivery; see also Section 7.6.5.

A broadcast packet shall never be acknowledged by the Baseband.

The Broadcast LT_ADDR shall use a ptt=0.

There are several occasions when a role switch is used:

Prior to the role switch, encryption if present, shall be paused or disabled in the old piconet. A role switch shall not be performed if the physical link is in Sniff or Hold mode, or has any synchronous logical transports.

For the Central and Peripheral involved in the role switch, the switch results in a reversal of their TX and RX timing: a TDD switch. Additionally, since the piconet parameters are derived from the Bluetooth Device Address and clock of the Central, a role switch inherently involves a redefinition of the piconet as well: a piconet switch. The new piconet's parameters shall be derived from the former Peripheral's device address and clock.

Assume device A is to become Central; device B was the former Central. Then there are two alternatives: either the Peripheral initiates the role switch or the Central initiates the role switch. These alternatives are described in Link Manager Protocol, [Vol 2] Part C, Section 4.4.2. The Baseband procedure is the same regardless of which alternative is used.

To begin the role switch, A and B shall perform a TDD switch using the former hopping scheme (still using the Bluetooth Device Address and clock of device B), so there is no piconet switch yet. The slot offset information sent by A shall not be used yet; it is used when both devices have switched to the new piconet and device B is positioning its correlation window. Device A now becomes the Central, device B the Peripheral.

At the moment of the TDD switch, both devices A and B shall start a timer with a time out of newconnectionTO. The timer shall be stopped in B as soon as it receives an FHS packet from A on the TDD-switched channel. The timer shall be stopped in A as soon as it receives an ID packet from B. If the newconnectionTO expires, A and B shall return to the old piconet timing and AFH state, taking their old roles of Peripheral and Central respectively. The FHS packet shall be sent by A using the "old" piconet parameters. The LT_ADDR in the FHS packet header shall be the former LT_ADDR used by device A. The LT_ADDR carried in the FHS payload shall be the new LT_ADDR intended for device B when operating on the new piconet. After the FHS acknowledgment, which is the ID packet and shall be sent by B on the old hopping sequence, both A and B shall use the new channel parameters of the new piconet as indicated by the FHS with the sequence selection set to basic channel hopping sequence. If the new Central A has physical links that are AFH enabled, following the piconet switch the new Central is responsible for controlling the AFH operational mode of its new Peripheral B.

Since the old and new Centrals' clocks are synchronized, the clock information sent in the FHS payload shall indicate the new Central's clock at the beginning of the FHS packet transmission. Furthermore, the 1.25 ms resolution of the clock information given in the FHS packet is not sufficient for aligning the slot boundaries of the two piconets. The slot-offset information in the LMP message previously sent by device A shall be used to provide more accurate timing information. The slot offset indicates the delay between the start of the Central-to-Peripheral slots of the old and new piconet channels. This timing information ranges from 0 to 1249 μs with a resolution of 1 μs. It shall be used together with the clock information in the FHS packet to accurately position the correlation window when switching to the new Central's timing after acknowledgment of the FHS packet.

After reception of the FHS packet acknowledgment, the new Central A shall switch to its own timing with the sequence selection set to the basic channel hopping sequence and shall send a POLL packet to verify the switch. Both A and B shall start a new timer with a time out of newconnectionTO on FHS packet acknowledgment. The start of this timer shall be aligned with the beginning of the first Central TX slot boundary of the new piconet, following the FHS packet acknowledgment. B shall stop the timer when the POLL packet is received; A shall stop the timer when the POLL packet is acknowledged. The Peripheral B shall respond with a NULL, DM1, or DH1 packet to acknowledge the POLL. Any pending AFH_Instant shall be cancelled once the POLL packet has been received by the Peripheral. If no response is received, A shall re-send the POLL packet until newconnectionTO is reached. If this timer expires, both A and B shall return to the old piconet timing with the old roles: B as Central and A as Peripheral. Expiry of the timer shall also restore the state associated with AFH (including any pending AFH_Instant), Channel Quality Driven Data Rate (CQDDR, Link Manager Protocol [Vol 2] Part C, Section 4.1.7) and power control (Link Manager Protocol [Vol 2] Part C, Section 4.1.3). The role switch procedure may then restart from the TDD switch. Aligning the timer with TX boundaries of the new piconet ensures that no device returns to the old piconet timing in the middle of a Central RX slot.

The messaging during a successful role switch is summarized in Table 8.6.

After the role switch the ACL logical transport is reinitialized as if it were a new connection. For example, the SEQN of the first data packet containing a CRC on the new piconet channel shall be set according to the rules in Section 7.6.2.

Multiple piconets can cover the same area. Since each piconet has a different Central, the piconets hop independently, each with their own hopping sequence and phase as determined by the respective Central. In addition, the packets carried on the channels are preceded by different channel access codes as determined by the Centrals’ device addresses. As more piconets are added, the probability of collisions increases; a graceful degradation of performance results as is common in frequency-hopping spread spectrum systems.

If multiple piconets cover the same area, a device can participate in two or more overlaying piconets by applying time multiplexing. To participate on the proper channel, it shall use the associated Central’s device address and proper clock offset to obtain the correct phase. A device can act as a Peripheral in several piconets, but only as a Central in a single piconet: since two piconets with the same Central are synchronized and use the same hopping sequence, they are one and the same piconet. A group of piconets in which connections exist between different piconets is called a scatternet.

A Central or Peripheral can become a Peripheral in another piconet by being paged by the Central of this other piconet. On the other hand, a device participating in one piconet can page the Central or Peripheral of another piconet. Since the paging device always starts out as Central, a role switch is required if a Peripheral role is desired. This is described in Section 8.6.5.

Hop sequence adaptation is controlled by the Central and can be set to either enabled or disabled. Once enabled, hop sequence adaptation shall apply to all logical transports on a physical link. Once enabled, the Central may periodically update the set of used and unused channels as well as disable hop sequence adaptation on a physical link. When a Central has multiple physical links the state of each link is independent of all other physical links.

When hop sequence adaptation is enabled, the sequence selection hop selection kernel input is set to adapted channel hopping sequence and the AFH_channel_map input is set to the appropriate set of used and unused channels. Additionally, the same channel mechanism shall be used. When hop sequence adaptation is enabled with all channels used this is known as AHS(79).

When hop sequence adaptation is disabled, the sequence selection input of the hop selection kernel is set to basic channel hopping sequence (the AFH_channel_map input is unused in this case) and the same channel mechanism shall not be used.

The hop sequence adaptation state shall be changed when the Central sends the LMP_SET_AFH PDU and a Baseband acknowledgment is received. When the Baseband acknowledgment is received prior to the hop sequence switch instant, AFH_Instant, (See Link Manager Protocol [Vol 2] Part C, Section 4.1.4) the hop sequence proceeds as shown in Figure 8.11.

Figure 8.11: Successful hop sequence switching

When the Baseband acknowledgment is not received prior to the AFH_Instant the Central shall use a recovery hop sequence for the Peripheral(s) that did not respond with an acknowledgment (this may be because the Peripheral did not hear the Central’s transmission or the Central did not hear the Peripheral’s transmission). When hop sequence adaptation is being enabled or disabled the recovery sequence shall be the AFH_channel_map specified in the LMP_SET_AFH PDU. When the AFH_channel_map is being updated the Central shall choose a recovery sequence that includes all of the RF channels marked as used in either the old or new AFH_channel_map, e.g. AHS(79). Once the Baseband acknowledgment is received the Central shall use the AFH_channel_map in the LMP_SET_AFH PDU starting with the next transmission to the Peripheral. See Figure 8.12.

Figure 8.12: Recovery hop sequences

When the AFH_Instant occurs during a multi-slot packet transmitted by the Central, the Peripheral shall use the same hopping sequence parameters as the Central used at the start of the multi-slot packet. An example of this is shown in Figure 8.13. In this figure the basic channel hopping sequence is designated f. The first adapted channel hopping sequence is designated with f', and the second adapted channel hopping sequence is designated f''.

Figure 8.13: AFH_Instant changes during multi-slot packets transmitted by the Central

RF channels are classified as being unknown, bad or good. These classifications are determined individually by the Central and Peripherals based on local information (e.g. active or passive channel assessment methods or from the Host via HCI). Information received from other devices via LMP (for example, an AFH_channel_map from a Central or a channel classification report from a Peripheral) shall not be included in a device’s channel classification.

The three possible channel classifications shall be as defined in Table 8.7.

A Central with AFH enabled physical links shall determine an AFH_channel_map for each such link (two or more links may use the same map) based on any combination of the following information:

The algorithm used by the Central to combine these information sources and generate the AFH_channel_map is not defined in the specification and will be implementation specific. At no time shall the number of channels used be less than N_min, defined in Section 2.3.1.

If a Central determines that all channels should be used, it may keep AFH operation enabled using an AFH_channel_map of 79 used channels, i.e., AHS(79).

For all devices that support the Synchronization Train substate (see Section 8.11.2), the RF channel indices used for the Synchronization Train (see Section 2.6.4.8) shall be marked as unused in the AFH_channel_map for all logical links.

Features are provided to allow low-power operation. These features are both at the microscopic level when handling the packets, and at the macroscopic level when using certain operation modes.

A Central may adjust the piconet clock during the existence of a piconet using two mechanisms: Coarse Clock Adjustment and Clock Dragging. Both mechanisms may be used within the same piconet.

8.6.10.1. Coarse clock adjustment

The Central carries out a coarse clock adjustment by selecting an adjustment instant (clk_adj_instant), which shall be a Central-to-Peripheral slot, and the amount of the adjustment, and then broadcasting these parameters to all Peripherals by sending LMP_CLK_ADJ (see [Vol 2] Part C, Section 4.1.14.1). The amount of the adjustment is specified as two values: clk_adj_slots, which is the change in the value of CLK[27:1] at the clk_adj_instant, and clk_adj_us, which is the number of microseconds between the start of a Central slot in the old clock (CLK_old) and in the new clock (CLK_new) domains.

The Central shall provide the opportunity for each Peripheral to acknowledge the adjustment with LMP_CLK_ADJ_ACK (see [Vol 2] Part C, Section 4.1.14.1). If the Central receives any other packet than LMP_CLK_ADJ_ACK with the current clk_adj_id, it should poll the Peripheral more times until the expected acknowledgment is received or the Peripheral responds with a NULL packet. If any Peripheral does not acknowledge the adjustment, the Central shall start the Coarse Clock Adjustment Recovery Mode (see Section 8.6.10.2).

When the clk_adj_instant occurs, the Central will add (clk_adj_slots × 625 + clk_adj_us) µs to time_base_offset and the Peripheral(s) will add the same amount to peripheral_clock_offset. If the clk_adj_instant occurs during a multi-slot packet the adjustment is delayed until the start of the following Central-to-Peripheral slot. If a role switch is successful prior to the clk_adj_instant, the pending coarse clock adjustment shall be discarded. The effect of the adjustment is that devices will use the new clock domain starting at clk_adj_instant.

Figure 8.14 shows an example of a positive clock adjustment. In this example the clk_adj_instant is set to slot 12 (which is in the old clock domain), clk_adj_slots is set to 6 and clk_adj_us is set to 400. Time is moved forward clk_adj_slots × 625 + clk_adj_us = 6 × 625 + 400 = 4150 µs. The initial slot in the new clock domain is at CLK_new[27:1] = clk_adj_instant + clk_adj_slots = 12 + 6 = 18. This is an even value so the first slot is a Central-to-Peripheral slot. A positive clk_adj_us means that the first slot is assumed to have started clk_adj_us before the clk_adj_instant, and hence only 625 – clk_adj_us = 225 µs remains after the instant. Since transmissions cannot be started part way through a slot, this partial slot is unusable. The first complete slot after the clk_adj_instant is a Peripheral-to-Central slot which can be used, for example, for eSCO. If clk_adj_slots had been an odd number, the first complete slot would have been a Central-to-Peripheral slot. The first complete Central-to-Peripheral slot in this example happens at CLK_new[27:1] = 20.

Figure 8.14: Positive coarse clock adjustment

Figure 8.15 shows an example of a negative clock adjustment. In this example the clk_adj_instant is again set to slot 12, clk_adj_slots is set to 0 and clk_adj_us is set to –400. Time is moved by clk_adj_slots × 625 + clk_adj_us = 0 × 625 + (–400) = –400 µs, which is 400 µs backwards. The initial slot in the CLK_new domain is at CLK_new[27:1] = clk_adj_instant + clk_adj_slots = 12 + 0 = 12. This is an even value so the first slot is a Central-to-Peripheral slot. A negative clk_adj_us means that the first slot in the CLK_new domain starts clk_adj_us after clk_adj_instant. The time between the first slot in the CLK_new domain and clk_adj_instant (in this case 400 µs) is effectively a continuation of the previous slot, even if its number changes, and hence is unusable. (This is the case whenever clk_adj_us is negative, even when clk_adj_slots is non-zero.)

Figure 8.15: Negative coarse clock adjustment

If clk_adj_us is zero then the adjustment alters the slot numbering but not the actual times at which slots start. Therefore all slots remain available for use, though if clk_adj_slots is odd then there will be two consecutive Peripheral-to-Central slots.

Slot Availability Mask (SAM) allows two Bluetooth devices to indicate to each other the availability of their time slots for transmission and reception. From the Baseband point of view, SAM provides a map - the SAM slot map - which marks the availability of Bluetooth slots. The availability arises from either external conditions (e.g., MWS coexistence) or internal conditions (e.g., topology management for scatternets). The SAM slot map marks each slot using one of four type codes defined in [Vol 2] Part C, Section 5.2 and repeated for convenience in Table 8.8.

Figure 8.16 shows an example of a SAM slot map. The Central-to-Peripheral slots are labeled with the letter 'C' and Peripheral-to-Central slots with the letter 'P'.

Figure 8.16: An example of a SAM slot map

A SAM slot map has a finite length and is repeated indefinitely until changed by the associated LMP procedures. SAM anchor points are spaced regularly with an interval of T_SAM, in units of slots. Between adjacent SAM anchor points, the slot map indicates when the device is able to transmit and receive. The SAM slot map is effectively repeated every T_SAM until it is changed.

The SAM interval T_SAM is further divided into N_{SAM_SM} sub-intervals of equal length, T_{SAM_SM}, such that T_SAM = T_{SAM_SM} × N_{SAM_SM}. T_{SAM_SM} shall be an even integer so as to contain TX/RX slot pairs.

The words "SAM submap" (or simply "submap" when there is no ambiguity from the context) will be used to denote a sub-interval of T_{SAM_SM} slots. Each submap is assigned one of the four usage types defined in [Vol 2] Part C, Section 5.2 and repeated for convenience in Table 8.9.

The SAM facilities specify each SAM slot map at the submap granularity. Figure 8.17 shows an example of a SAM slot map in terms of submaps in the local device. Each box represents a sub-interval of T_{SAM_SM} slots, with the label on the box indicating the type of the submap.

At the submap level of granularity, transmit and receive are handled identically; the difference will only appear inside submaps with type 0.

Figure 8.17: Example of a SAM slot map in terms of submaps in the local device

In addition to the SAM slot maps, the Controller also maintains a single "SAM type 0 submap" that is used to specify the availability of individual slots for those submaps shown as having type 0. The Controller then combines the SAM slot map at submap granularity with the first T_{SAM_SM} entries of the type 0 submap to generate the effective maps. Figure 8.18 shows a SAM slot map and a SAM type 0 submap together with the resulting effective map.

Figure 8.18: Example of a SAM slot map and SAM type 0 submap being combined

Figure 8.19 shows an example of a SAM type 0 submap for a collocated MWS.

Figure 8.19: Examples of SAM type 0 submap at a Bluetooth device with a collocated MWS

The assumption in the example is that, in order to prevent mutual interference between Bluetooth and MWS radios, Bluetooth transmissions are not available during MWS downlink durations and Bluetooth reception is not available during MWS uplink durations. The MWS frame is 10 ms long and the SAM type 0 submap needs to have the same length, so T_{SAM_SM} is 16.

Figure 8.20 shows another example of a collocated Bluetooth device with a low traffic load in the MWS Uplink. In this case, the implementation chooses to mark the MWS Uplink portion available for both TX and RX, because there is a good chance that it can receive Central packets and respond to them without interference from MWS.

Figure 8.20: Examples of SAM type 0 submap at a Bluetooth device with a collocated MWS with low uplink traffic load

SAM allows each device to send its local slot availability to the other, in which case the availability of slots depends on the combined slot maps. The scheduling recommendations for such a SAM slot map are described in Section 8.6.11.2.

A device that supports the SAM feature shall be capable of storing three distinct SAM slot maps from each connected remote device. A remote device can only define one type 0 submap, which can be referenced by any of its defined SAM slot maps. The remote device may redefine its type 0 submap at any time.

8.6.11.1. SAM anchor point

SAM slot maps are periodic, defined by an interval T_SAM and an offset D_SAM. Figure 8.21 shows an example of SAM slot maps designed to correspond to periodic MWS active and inactivity cycles.

Figure 8.21: An example of SAM slot maps for a periodic MWS active and inactive cycles

SAM anchor points are the start points of the first slot in the SAM slot maps. SAM anchor points are computed from T_SAM and D_SAM using the Central's current clock, which is known to both devices. The first SAM anchor point is indicated by SAM_Instant. In order to prevent problems caused by the clock wrap-around, the LMP message carries an additional timing control flag, which indicates whether initialization procedure 1 or 2 shall be used. The initiating device shall use initialization 1 when the MSB of the Central's current clock (CLK₂₇) is 0; it shall use initialization 2 when the MSB of the Central's current clock (CLK₂₇) is 1. The responding device shall apply the initialization method indicated by the initialization flag. The SAM anchor points shall be initialized on the slots for which the clock satisfies the applicable equations:

Equation 0. 

$\begin{array}{lcc}{\mathrm{CLK}}_{27-1}{\mathit{\text{ mod T}}}_{\mathrm{SAM}}\text{= }{\mathit{\text{\hspace{0.05em}D}}}_{\mathrm{SAM}}& & \text{for initialization 1}\\ \left({\overline{\mathrm{CLK}}}_{27},{\mathrm{CLK}}_{26-1}\right){\mathit{\text{ mod T}}}_{\mathit{SAM}}\text{= }{\mathit{\text{\hspace{0.05em}D}}}_{SAM}& & \text{for initialization 2}\end{array}$

After initialization, the clock value CLK(k+1) for the next SAM anchor point can be found by adding the fixed interval T_SAM to the clock value of the current anchor point:

Equation 0. 

${\mathrm{CLK}}_{27-1} \left(\mathrm{k}+1\right)={\mathrm{CLK}}_{27-1} \left(\mathrm{k}\right)+T_{\mathrm{SAM}}$

The SAM anchor point shall be a Central-to-Peripheral slot. As a corollary, the first slot of every SAM submap is also a Central-to-Peripheral slot.

8.6.11.2. SAM scheduling

SAM enables each device to send its local slot availability to the other. The scheduler in the Bluetooth Controller should consider the SAM slot maps from both local and remote devices for packet scheduling. The only effect of using the SAM information is to restrict a device's transmission and reception opportunities.

For all ACL packets and for eSCO packets in the retransmission window:

1. The Central should only transmit a packet if the required Central-to-Peripheral slots are marked as available for transmission in the Central's SAM slot map and available for reception in the Peripheral's SAM slot map.

2. The Peripheral should only transmit a packet if the required slots are marked as available for reception in the Central's SAM slot map and available for transmission in the Peripheral's SAM slot map.

3. The Peripheral may choose not to listen to the Central in Central-to-Peripheral slots that are marked either unavailable for transmission in the Central’s SAM slot map or unavailable for reception in the Peripheral’s SAM slot map.

For all ACL packets, the Central should only transmit a packet if the slot immediately following the Central's packet is marked as available for transmission in the Peripheral's SAM slot map and available for reception in the Central's SAM slot map.

For eSCO packets in the retransmission window, the Central should only transmit a packet if either:

1. the slot immediately following the Central's packet is marked as available for transmission in the Peripheral's SAM slot map and available for reception in the Central's SAM slot map;

2. this is the last opportunity for the Central to transmit this packet in this retransmission window; or

3. for all subsequent Central-to-Peripheral slots in the same retransmission window that provide sufficient remaining slots for the Central to transmit the same packet, the rules in this section state that the Central should not transmit the packet.

In SCO and eSCO reserved slots, either the Central or the Peripheral may choose not to transmit a SCO or eSCO packet unless the required slots are marked both as available for transmission in the local SAM slot map and available for reception in the remote SAM slot map.

Figure 8.22 below illustrates possible scheduling results with combined SAM slot maps from Central and Peripheral.

Figure 8.22: Example of possible scheduling results with combined SAM slot maps from Central and Peripheral

Sniff Transition mode is a special mode which is used during the transition between Sniff mode and Active mode. It is required because during this transition it is unclear which mode (Sniff or Active) the Peripheral is in and it is necessary to ensure that the Peripheral is polled correctly regardless of which mode it is in.

In Sniff Transition mode the Central shall maintain the Active mode poll interval in case the Peripheral is in Active mode. In addition the Central shall poll the Peripheral at least once in the sniff attempt transmit slots starting at each sniff anchor point. This transmission counts for the Active mode polling as well. The Central shall use its high power accurate clock when in Sniff Transition mode.

The precise circumstances under which the Central enters Sniff Transition mode are defined in [Vol 2] Part C, Section 4.5.3.1.

When sniff subrating is enabled by the Link Manager a device alternates between Sniff mode and Sniff Subrating mode. Sniff Subrating mode allows a device to use a reduced number of sniff anchor points. A device shall transition from Sniff mode to Sniff Subrating mode based on the Sniff mode timeout value (see Section 8.7.2.1). A device shall transition from Sniff Subrating mode to Sniff mode whenever ACL-U, APB-U, ACL-C, or APB-C data is received from the remote device.

Figure 8.24: Sniff subrating

A Peripheral in Sniff Subrating mode shall also temporarily enter Sniff mode after transmitting a packet requiring acknowledgment until the Baseband acknowledgment is received.

Once sniff subrating is enabled the Central and Peripheral may be in Sniff mode or Sniff Subrating mode at different times. The rules defined in Section 8.7.2.2 describe how the two devices maintain synchronization and can reliably exchange data.