Bluetooth Core Specification

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

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

The first addition operation only adds a constant to the phase and applies a mod 32 operation. For the page hopping sequence, the first addition is redundant since it only changes the phase within the segment. However, when different segments are concatenated (as in the basic channel hopping sequence), the first addition operation will have an impact on the resulting sequence.

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

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.

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 addition operation selects the hop frequencies to be used by the current segment and also switches between Central-to-Peripheral and Peripheral-to-Central. It adds the output of the current permutation (which selects a channel within the segment), a constant, the clock bit selecting Central or Peripheral slots, and a value used to switch each segment to a new set of channels in Connection state. The addition is applied mod 79.

The output of the adder addresses a bank of 79 registers. The registers are loaded with the synthesizer code words corresponding to the hop frequencies 0 to 78.

The upper half of the bank contains the even hop frequencies, whereas the lower half of the bank contains the odd hop frequencies.

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:

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).

For the transmitted access code and in the receiver correlator, the appropriate GIAC or DIAC shall be used. The application decides which inquiry access code to use depending on the purpose of the inquiry.

When the sequence selection input is set to page, the paging device shall start using the A-train, i.e., $\left(f\left(k-8\right),\dots ,f\left(k\right),\dots ,f\left(k+7\right)\right)$ , where f(k) is the source’s estimate of the current receiver frequency in the paged device. The index k is a function of all the inputs in Figure 2.16. There are 32 possible paging frequencies within each 1.28 second interval. Half of these frequencies belong to the A-train, the rest (i.e., $\left(f\left(k+8\right),\dots ,f\left(k+15\right),f\left(k-16\right),\dots ,f\left(k-9\right)\right)$ ) belong to the B-train. In order to achieve the -8 offset of the A-train, a constant of 24 shall be added to the clock bits (which is equivalent to -8 due to the mod 32 operation). The B-train is obtained by setting the offset to 8. In the case where slots to receive the first Peripheral response are periodically not available, an additional offset (k_nudge) is added to the clock bits in order to shift the train by an integer multiple of 1.25 ms duration. A cyclic shift of the order within the trains is also necessary in order to avoid a possible repetitive mismatch between the paging and scanning devices. Thus,

where

Alternatively, each switch between the A- and B-trains may be accomplished by adding 16 to the current value of k_offset (originally initialized with 24).

When the sequence selection input is set to Peripheral page response, in order to eliminate the possibility of losing the link due to discrepancies of the native clock CLKN and the Central’s clock estimate CLKE, the five bits CLKN_16-12 shall be frozen at their current value. The value shall be frozen at the content it has in the slot where the recipient’s access code is detected. The native clock shall not be stopped; it is merely the values of the bits used for creating the X-input that are kept fixed for a while. A frozen value is denoted by an asterisk (*) in the discussion below.

For each response slot the paged device shall use an X-input value one larger (mod 32) than in the preceding response slot. However, the first response shall be made with the X-input kept at the same value as it was when the access code was recognized. Let N be a counter starting at zero. Then, the X-input in the (N + 1) -th response slot (the first response slot being the one immediately following the page slot now responding to) of the Peripheral Page Response substate is:

The counter N shall be set to zero in the slot where the Peripheral acknowledges the page (see Figure 8.3 and Figure 8.4). Then, the value of N shall be increased by one each time CLKN₁ is set to zero, which corresponds to the start of a Central TX slot. The X-input shall be constructed this way until the first FHS packet is received and the immediately following response packet has been transmitted. After this the Peripheral shall enter the Connection state using the parameters received in the FHS packet.

When the sequence selection input is set to Central page response, the Central shall freeze its estimate of the Peripheral's clock to the value that triggered a response from the paged device. It is equivalent to using the values of the clock estimate when receiving the Peripheral’s response (since only CLKE₁ will differ from the corresponding page transmission). Thus, the values are frozen when the Peripheral’s ID packet is received. In addition to the clock bits used, the current values of k_offset and k_nudge shall also be frozen. The Central shall adjust its X-input in the same way the paged device does, i.e., by incrementing this value by one for each time CLKE₁ is set to zero. The first increment shall be done before sending the FHS packet to the paged device. Let N be a counter starting at one. The rule for forming the X-input is:

The value of N shall be increased each time CLKE₁ is set to zero, which corresponds to the start of a Central TX slot.

When the sequence selection input is set to inquiry, the X-input is similar to that used in the page hopping sequence. Since no particular device is addressed, the native clock CLKN of the inquirer shall be used. Moreover, which of the two train offsets to start with is of no real concern in this state. Consequently,

where k_offset and k_nudge are defined by (EQ 3) and (EQ 4).

The initial choice of k_offset is arbitrary.

The inquiry response hopping sequence is similar to the Peripheral page response hopping sequence with respect to the X-input. The clock input shall not be frozen, thus the following equation applies:

Furthermore, the counter N is increased not on CLKE₁ basis, but rather after each FHS packet has been transmitted in response to the inquiry. There is no restriction on the initial value of N as it is independent of the corresponding value in the inquiring unit.

The X_ir value used for the extended inquiry response packet shall be the same X_ir value as calculated for the immediately preceding FHS packet.

In the basic and adapted channel hopping sequences, the clock bits to use in the basic or adapted hopping sequence generation shall always be derived from the Central's clock, CLK.

The synchronization train and synchronization scan use RF channels from the set of three fixed RF channels with indices 0, 24, and 78.

In the case of asynchronous data only the TX ACL buffer in Figure 4.1 has to be considered. In this case, only packet types DM or DH are used, and these can have different lengths. The length is indicated in the payload header. The selection of DM or DH packets should depend on the quality of the link. See [Vol 2] Part C, Section 4.1.7.

The default packet type in pure data traffic is NULL (see Section 6.5.1.2). This means that, if there is no data to be sent (the data traffic is asynchronous, and therefore pauses occur in which no data is available) or no Peripherals need to be polled, NULL packets are sent instead – in order to send link control information to the other device (e.g. ACK/STOP information for received data). When no link control information is available (either no need to acknowledge and/or no need to stop the RX flow) no packet is sent at all.

The TX routine works as follows. The Baseband Resource Manager loads new data information in the register to which the switch S1a points. Next, it gives a command to the Link Controller, which forces the switch S1 to change (both S1a and S1b switch synchronously). When the payload needs to be sent, the packet composer reads the current register and, depending on the packet type, builds a payload which is appended to the channel access code and the header and is subsequently transmitted. In the response packet (which arrives in the following RX slot if it concerned a Central transmission, or may be postponed until some later RX slot if it concerned a Peripheral transmission), the result of the transmission is reported back. In case of an ACK, the switch S1 changes position; if a NAK (explicit or implicit) is received instead, the switch S1 will not change position. In that case, the same payload is retransmitted at the next TX occasion.

As long as the Baseband Resource Manager keeps loading the registers with new information, the Link Controller will automatically transmit the payload; in addition, retransmissions are performed automatically in case of errors. The Link Controller will send NULL or nothing when no new data is loaded. If no new data has been loaded in the next register, during the last transmission, the packet composer will be pointing to an empty register after the last transmission has been acknowledged and the next register becomes the current register. If new data is loaded in the next register, a Flush command is required to switch the S1 switch to the proper register. As long as the Baseband Resource Manager keeps loading the data and type registers before each TX slot, the data is automatically processed by the Link Controller since the S1 switch is controlled by the ACK information received in response. However, if the traffic from the Baseband Resource Manager is interrupted once and a default packet is sent instead, a Flush command is necessary to continue the flow in the Link Controller.

The Flush command may also be used in case of time-bounded (isochronous) data. In case of a bad link, many retransmissions are necessary. In certain applications, the data is time-bounded: if a payload is retransmitted all the time because of link errors, it may become outdated, and the system might decide to continue with more recent data instead and skip the payload that does not come through. This is accomplished by the Flush command as well. With the flush, the switch S1 is forced to change and the Link Controller is forced to consider the next data payload and overrules the ACK control. Any ACL type of packet can be used to send data or link control information to any other ACL Peripheral.

On the SCO logical transport only HV and DV packet types are used, See Section 6.5.2. The synchronous port may continuously load the next register in the synchronous buffer. The S2 switches are changed according to the T_sco interval. This T_sco interval is negotiated between the Central and the Peripheral at the time the SCO logical transport is established.

For each new SCO slot, the packet composer reads the current register after which the S2 switch is changed. If the SCO slot has to be used to send control information with high priority concerning a control packet between the Central and the SCO Peripheral, or a control packet between the Central and any other Peripheral, the packet composer will discard the SCO information and use the control information instead. This control information shall be sent in a DM1 packet. Data or link control information may also be exchanged between the Central and the SCO Peripheral by using the DV or DM1 packets.

In Section 6.5.2, a DV packet has been defined that can support both data and voice simultaneously on a single SCO logical transport. When the TYPE is DV, the Link Controller reads the data register to fill the data field and the voice register to fill the voice field. Thereafter, the switch S2 is changed. However, the position of S1 depends on the result of the transmission as on the ACL logical transport: only if an ACK has been received will the S1 switch change its position. In each DV packet, the voice information is new, but the data information might be retransmitted if the previous transmission failed. If there is no data to be sent, the SCO logical transport will automatically change from DV packet type to the current HV packet type used before the mixed data/voice transmission.

A Flush command is necessary when the data stream has been interrupted and new data has arrived.

Combined data-voice transmission can also be accomplished by using a separate ACL logical transport in addition to the SCO logical transport(s) if channel capacity permits this.

On the eSCO logical transport only EV, POLL and NULL packet types are used, see Section 6.5.3. The synchronous port may continuously load the next register in the synchronous buffer. The S2 switches are changed according to the T_eSCO interval. This T_eSCO interval is negotiated between the Central and the Peripheral at the time the eSCO logical transport is established.

For each new eSCO slot, the packet composer reads the current register after which the S2 switch is changed. If the eSCO slot has to be used to send control information with high priority concerning a control packet between the Central and the eSCO Peripheral, or an ACL packet between the Central and any other Peripheral, the packet composer will discard the eSCO information and use the control information instead. Control information to the eSCO Peripheral is sent in a DM1 packet on the primary LT_ADDR.

On the ACL links, the default type is always NULL both for the Central and the Peripheral. This means that if no user information needs to be sent, either a NULL packet is sent if there is ACK or STOP information, or no packet is sent at all. The NULL packet can be used by the Central to allocate the next Peripheral-to-Central slot to a certain Peripheral (namely the one addressed). However, the Peripheral is not forced to respond to the NULL packet from the Central. If the Central requires a response, it sends a POLL packet.

The SCO and eSCO packet types are negotiated at the LM level when the SCO or eSCO logical transport is established. The agreed packet type is also the default packet type for the reserved SCO or eSCO slots.

As long as data cannot be received, a STOP indication shall be transmitted which is automatically inserted by the Link Controller into the header of the return packet. STOP shall be returned as long as the RX ACL buffer is not emptied by the Baseband Resource Manager. When new data can be accepted again, the GO indication shall be returned. GO shall be the default value. All packet types not including data can still be received. Voice communication for example is not affected by the flow control. Although a device can-not receive new information, it may still continue to transmit information: the flow control shall be separate for each direction.

On the reception of a STOP signal, the Link Controller shall automatically switch to the default packet type. The ACL packet transmitted just before the reception of the STOP indication shall be kept until a GO signal is received. It may be retransmitted as soon as a GO indication is received. Only default packets shall be sent as long as the STOP indication is received. When no packet is received, GO shall be assumed implicitly. The default packets contain link control information (in the header) for the receive direction (which may still be open) and may contain synchronous data (HV or EV packets). When a GO indication is received, the Link Controller may resume transmitting the data that is present in the TX ACL buffers.

In a multi-Peripheral configuration, only the transmission to the Peripheral that issued the STOP signal shall be stalled. This means that the Central shall only stop transmission from the TX ACL buffer corresponding to the Peripheral that momentarily cannot accept data.

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:

The information sequence is generated by appending 6 bits to the 24 bit LAP (step 1). The appended bits are $001101$ 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 157464165547 (octal notation) of a primitive binary (63,30) BCH code. Thus, in octal notation g(D) is

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

respectively. Furthermore,

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

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 (hexadecimal notation) 83848D96BBCC54FC. 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:

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 identity or ID packet consists of the device access code (DAC) or inquiry access code (IAC). It has a fixed length of 68 bits. It is a very robust packet since the receiver uses a bit correlator to match the received packet to the known bit sequence of the ID packet.

The ID packet shall only be used where explicitly stated in paging (see Section 8.3), inquiry (see Section 8.4), and role switch (see Section 8.6.5). It shall not be used where any other packet type is permitted.

The NULL packet has no payload and consists of the channel access code and packet header only. Its total (fixed) length is 126 bits. The NULL packet may be used to return link information to the source regarding the success of the previous transmission (ARQN), or the status of the RX buffer (FLOW). The NULL packet does not require acknowledgment.

The POLL packet is very similar to the NULL packet. It does not have a payload. In contrast to the NULL packet, it requires a confirmation from the recipient. It is not a part of the ARQ scheme. The POLL packet does not affect the ARQN and SEQN fields. Upon reception of a POLL packet the Peripheral shall respond with a packet even when the Peripheral does not have any information to send unless the Peripheral has scatternet commitments in that timeslot. This return packet is an implicit acknowledgment of the POLL packet. This packet can be used by the Central in a piconet to poll the Peripherals. Peripherals shall not transmit the POLL packet. POLL packets shall not be sent on a Connectionless Peripheral Broadcast logical transport.

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:

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

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.

DM1 is part of segment 1 in order to support control messages in any logical transport that allows the DM1 packet (see Table 6.2). However, it may also carry regular user data. Since the DM1 packet can be regarded as an ACL packet, it will be discussed in Section 6.5.4.

The HV1 packet has 10 information bytes. The bytes are protected with a rate 1/3 FEC. No MIC is present. No CRC is present. The payload length is fixed at 240 bits. There is no payload header present.

The HV2 packet has 20 information bytes. The bytes are protected with a rate 2/3 FEC. No MIC is present. No CRC is present. The payload length is fixed at 240 bits. There is no payload header present.

The HV3 packet has 30 information bytes. The bytes are not protected by FEC. No MIC is present. No CRC is present. The payload length is fixed at 240 bits. There is no payload header present.

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

The EV3 packet has between 1 and 30 information bytes plus a 16-bit CRC code. No MIC is present. The bytes are not protected by FEC. The EV3 packet may cover up to a single time slot. There is no payload header present. The payload length is set during the LMP eSCO setup and remains fixed until the link is removed or re-negotiated.

The EV4 packet has between 1 and 120 information bytes plus a 16-bit CRC code. No MIC is present. The EV4 packet may cover to up three time slots. The information plus CRC bits are coded with a rate 2/3 FEC. There is no payload header present. The payload length is set during the LMP eSCO setup and remains fixed until the link is removed or re-negotiated.

The EV5 packet has between 1 and 180 information bytes plus a 16-bit CRC code. No MIC is present. The bytes are not protected by FEC. The EV5 packet may cover up to three time slots. There is no payload header present. The payload length is set during the LMP eSCO setup and remains fixed until the link is removed or re-negotiated.

The 2-EV3 packet is similar to the EV3 packet except that the payload is modulated using π/4-DQPSK. It has between 1 and 60 information bytes plus a 16-bit CRC code. No MIC is present. The bytes are not protected by FEC. The 2-EV3 packet covers a single time slot. There is no payload header present. The payload length is set during the LMP eSCO setup and remains fixed until the link is removed or re-negotiated.

The 2-EV5 packet is similar to the EV5 packet except that the payload is modulated using π/4-DQPSK. It has between 1 and 360 information bytes plus a 16-bit CRC code. No MIC is present. The bytes are not protected by FEC. The 2-EV5 packet may cover up to three time slots. There is no payload header present. The payload length is set during the LMP eSCO setup and remains fixed until the link is removed or re-negotiated.

The 3-EV3 packet is similar to the EV3 packet except that the payload is modulated using 8DPSK. It has between 1 and 90 information bytes plus a 16-bit CRC code. No MIC is present. The bytes are not protected by FEC. The 3-EV3 packet covers a single time slot. There is no payload header present. The payload length is set during the LMP eSCO setup and remains fixed until the link is removed or re-negotiated.

The 3-EV5 packet is similar to the EV5 packet except that the payload is modulated using 8DPSK. It has between 1 and 540 information bytes plus a 16-bit CRC code. No MIC is present. The bytes are not protected by FEC. The 3-EV5 packet may cover up to three time slots. There is no payload header present. The payload length is set during the LMP eSCO setup and remains fixed until the link is removed or re-negotiated.

The DM1 packet carries data information only. The payload has between 1 and 18 information bytes (including the 1-byte payload header) plus a 16-bit CRC code. A 32-bit MIC is present only when encryption with AES-CCM is enabled. The DM1 packet occupies a single time slot. The information bits, MIC bits (when present), plus CRC bits are coded with a rate 2/3 FEC. The payload header in the DM1 packet is 1 byte long, see Figure 6.12.

This packet is similar to the DM1 packet, except that the information in the payload is not FEC encoded. As a result, the DH1 packet has between 1 and 28 information bytes (including the 1-byte payload header) plus a 16-bit CRC code. A 32-bit MIC is present only when encryption with AES-CCM is enabled. The DH1 packet occupies a single time slot.

The DM3 packet may occupy up to three time slots. The payload has between 2 and 123 information bytes (including the 2-byte payload header) plus a 16-bit CRC code. A 32-bit MIC is present only when encryption with AES-CCM is enabled. The information bits, MIC bits (when present), plus CRC bits are coded with a rate 2/3 FEC. The payload header in the DM3 packet is 2 bytes long, see Figure 6.13.

This packet is similar to the DM3 packet, except that the information in the payload is not FEC encoded. As a result, the DH3 packet has between 2 and 185 information bytes (including the 2-byte payload header) plus a 16-bit CRC code. A 32-bit MIC is present only when encryption with AES-CCM is enabled. The DH3 packet may occupy up to three time slots.

The DM5 packet may occupy up to five time slots. The payload has between 2 and 226 information bytes (including the 2-byte payload header) plus a 16-bit CRC code. A 32-bit MIC is present only when encryption with AES-CCM is enabled. The payload header in the DM5 packet is 2 bytes long. The information bits, MIC bits (when present), plus CRC bits are coded with a rate 2/3 FEC.

This packet is similar to the DM5 packet, except that the information in the payload is not FEC encoded. As a result, the DH5 packet has between 2 and 341 information bytes (including the 2-byte payload header) plus a 16-bit CRC code. A 32-bit MIC is present only when encryption with AES-CCM is enabled. The DH5 packet may occupy up to five time slots.

This packet resembles a DH1 packet but has no MIC or CRC code. The AUX1 packet has between 1 and 30 information bytes (including the 1-byte payload header). The AUX1 packet occupies a single time slot. The AUX1 packet shall only be used in test mode (see [Vol 3] Part D). The Link Controller shall discard any AUX1 packet received in any other circumstances.

This packet is similar to the DH1 packet except that the payload is modulated using π/4-DQPSK. The 2-DH1 packet has between 2 and 56 information bytes (including the 2-byte payload header) plus a 16-bit CRC code. A 32-bit MIC is present only when encryption with AES-CCM is enabled.The 2-DH1 packet occupies a single time slot.

This packet is similar to the DH3 packet except that the payload is modulated using π/4-DQPSK. The 2-DH3 packet has between 2 and 369 information bytes (including the 2-byte payload header) plus a 16-bit CRC code. A 32-bit MIC is present only when encryption with AES-CCM is enabled. The 2-DH3 packet may occupy up to three time slots.

This packet is similar to the DH5 packet except that the payload is modulated using π/4-DQPSK. The 2-DH5 packet has between 2 and 681 information bytes (including the 2-byte payload header) plus a 16-bit CRC code. A 32-bit MIC is present only when encryption with AES-CCM is enabled. The 2-DH5 packet may occupy up to five time slots.

This packet is similar to the DH1 packet except that the payload is modulated using 8DPSK. The 3-DH1 packet has between 2 and 85 information bytes (including the 2-byte payload header) plus a 16-bit CRC code. A 32-bit MIC is present only when encryption with AES-CCM is enabled. The 3-DH1 packet occupies a single time slot.

This packet is similar to the DH3 packet except that the payload is modulated using 8DPSK. The 3-DH3 packet has between 2 and 554 information bytes (including the 2-byte payload header) plus a 16-bit CRC code. A 32-bit MIC is present only when encryption with AES-CCM is enabled. The 3-DH3 packet may occupy up to three time slots.

This packet is similar to the DH5 packet except that the payload is modulated using 8DPSK. The 3-DH5 packet has between 2 and 1023 information bytes (including the 2-byte payload header) plus a 16-bit CRC code. A 32-bit MIC is present only when encryption with AES-CCM is enabled. The 3-DH5 packet may occupy up to five time slots.