During normal piconet operation, the channel-hopping sequence is used. For the channel-hopping sequence, the address input to the FSM for all devices in the piconet consists of the 28 least significant bits, BD_ADDR[0:27], of the master's Bluetooth device address. The channel-hopping sequence has a very long period, but the (23 or 79) hop frequencies are distributed equally over short periods of time to satisfy the regulatory requirements for the frequency-hopping sequence described earlier in this chapter.

During normal piconet operation, a new frequency from the channel-hopping sequence is selected every 625 μsec. This interval is the period for bit c ₁ of the Bluetooth clock shown in Figure 6.6; in this case, the LSB of the clock, c ₀, is not used. The time, 625 μsec, between two successive ticks of bit c₁ of the clock is referred to as a slot. For devices in the connected state, the slot boundaries coincide with the ticks of bit c₁ of the master's clock. Furthermore, all the devices in the piconet utilize the current value of the master's clock to drive their FSMs.

During the residence time at a frequency, a device may transmit a single packetized piece of information, referred to as a baseband packet data unit (BB_PDU)^[5] BB_PDUs are strictly constrained within the residence time at a frequency. However, the residence time at a frequency may occupy multiple slots, thus permitting multi-slot BB_PDU transmissions to occur as discussed below. Following a multi-slot transmission, the next frequency selected is the one that would have been used if single-slot transmissions had occurred instead. That is, the frequencies from the channel-hopping sequence are selected on a slot basis, although the frequency hops themselves occur on a BB_PDU basis.

One device "invites" another device to join its piconet through the use of a page. The device issuing the page is called a paging device, and the device listening (or scanning) for pages is called the paged device. A paging device selects a new frequency at which to transmit a page every 312.5 μsec, which is the period of bit c₀ of a Bluetooth clock. During page scans, when a device listens for transmitted pages, a new listening frequency is selected every 1.28 seconds, which is the period of bit c₁₂ of the clock. Note that a paging device changes frequencies at a much higher rate than a paged device. While the paged device uses its own clock to drive its FSM, the paging device uses its best estimate of the clock of the paged device to drive its own FSM. The paging device estimates the clock value of the paged device based upon the most recent communication between the devices. In the worst case, the paging device could use its own clock.

During the page operation, the page-hopping sequence is used. To generate this sequence, the paging and paged devices use the 28 least significant bits of the address of the paged device—that is, the LAP and part of the UAP of the address shown in Figure 6.5—as the address input to their respective FSMs. For each device, its page-hopping sequence is a well-defined, periodic sequence composed of 32 (resp.^[6] 16) frequencies uniformly distributed over the 79 (resp. 23) frequency channels permissible in the 2.4 GHz band in various countries. The period of the page-hopping sequence is 32 (resp. 16) hops.

Through inquiries a device "searches" for other devices in its vicinity. Just as in page operation, an inquiring device selects a new frequency at which to transmit an inquiry every 312.5 μsec. Inquired devices, executing inquiry scans, select a new listening frequency every 1.28 seconds. Note that an inquiring device changes frequencies at a much higher rate than an inquired device. Both the inquiring and inquired devices use their own clock to drive their FSMs.

During the inquiry operation, the inquiry-hopping sequence is used. To generate this sequence, the inquiring and inquired devices use the 28 least significant bits of the "inquiry address," referred to as the general inquiry access code (GIAC) LAP, as the address input to their respective FSMs. The inquiry address is a known, reserved 24-bit field equivalent to the 24-bit LAP of a Bluetooth address. The remaining four bits of the inquiry address (UAP[0:3]) are equal to hexadecimal '0x0'. The GIAC LAP is '0x9E8B33' and no Bluetooth device is allowed to have an address whose LAP coincides with the GIAC LAP. The inquiry-hopping sequence is a well-defined periodic sequence composed of 32 (resp. 16) frequencies uniformly distributed over the 79 (resp. 23) frequency channels permissible in the 2.4 GHz band in various countries. The period of the inquiry-hopping sequence is 32 (resp. 16) hops.

During normal piconet operation, each transmission on a given frequency of the channel-hopping sequence is preceded by the channel access code (CAC) generated using the LAP of the address of the piconet master. Only transmissions that contain the proper channel access code are received by a device.

During page operation, each paging transmission on a given frequency of the page-hopping sequence and each response to it are preceded by the device access code(DAC) generated using the LAP of the paged device's address.

During inquiry operation, each inquiry transmission on a given frequency of the inquiry-hopping sequence and each response to it are preceded by an inquiry access code(IAC). There are 64 IACs, including the GIAC, associated with 64 reserved LAPs. Excluding the GIAC, the remaining 63 IACs are referred to as dedicated IACs (DIACs). The IAC LAPs belong to the set {'0x9E8B00', …, '0x9E8B3F'}. No device can have an address whose LAP matches any of these reserved LAPs. Note that no matter which IAC is used, the inquiry-hopping sequence over which this IAC is transmitted is generated using the GIAC. This is done to allow devices with multiple receiver correlators, as highlighted in Figure 6.8, to follow a single inquiry-hopping sequence but still be able to listen to multiple classes of inquiries simultaneously.

While the specification does not define how IACs are to be used, they are intended to be used primarily as a filtering mechanism for identifying well-defined subsets of the devices that may receive inquiries. While all devices that execute inquiry scans use the GIAC to generate the inquiry-hopping frequency, only those devices whose receiver correlators are tuned to a particular IAC will receive and respond to inquiries that contain that particular IAC.

Table 6.3 summarizes the various parameters related to the fundamental processes for each of the three operational states of a Bluetooth device.

As discussed earlier, the Bluetooth clock and the BD_ADDR of the master of a piconet fully identify the frequency-hopping sequence and phase of the channel used in the piconet. Since communication between a slave and a master can occur only within a piconet, it follows that each slave in a piconet must know the master's clock and BD_ADDR. Alternatively, for a potential master to efficiently invite a potential slave, it needs to know the slave's clock and address. The exchange of address and clock information between devices occurs during inquiries, when the master collects operational information about the prospective slaves, and during pages, when the master communicates to a slave its own operational information. The operational information of a device, which includes its BD_ADDR and clock value, is sent in a frequency-hopping sequence (FHS) BB_PDU described in detail later in this chapter.

Assuming that the fundamental elements (address and clock) of the devices involved are known, the connected state is highlighted first in the next section. The inquiry and page states are presented afterward.

Figure 6.9 depicts the general format of a BB_PDU transmitted on a piconet. No frequency hops occur during a BB_PDU transmission and at most one BB_PDU is transmitted during the residence time at a frequency. Over-the-air transmissions start with the LSB and proceed to the MSB (little-endian transmission ordering). Every BB_PDU transmitted starts with the access code that, for the discussion here, serves as the piconet identifier, thus filtering out transmissions that might be received from other piconets (see Figure 6.8). The access code typically is 72 bits long, which includes a 4-bit trailer field. If the BB_PDU does not contain a header (and hence a payload), the trailer is not used and the BB_PDU consists of the 68-bit access code only. The 68-bit BB_PDUs are used exclusively for transmitting inquiries or pages as described in the corresponding sections later in this chapter.

The header of the BB_PDU contains link control data to aid medium access control. The header contains a mere 18 bits of information for low overhead, but it is encoded with a forward error-correcting(FEC) code with rate 1/3 for high transmission reliability. In particular, every bit of the header is transmitted three times in sequence. Table 6.4 summarizes the fields of BB_PDU header.

During the paging process, the master assigns a 3-bit active member address (AM_ADDR) to the new slave. AM_ADDR takes on the values 1 through 7 and it is unique for each active slave in a piconet. The reserved value of AM_ADDR = 'b000' is used to signify broadcast transmissions from the master to all the slaves in a piconet.^[8] The AM_ADDR is included in the same FHS BB_PDU sent by the master to the slave that also contains the master's address and clock information.

The various BB_PDU types are distinguished by their roles: purely signaling or payload-carrying packets; their link designation: asynchronous connectionless (ACL) data or synchronous connection-oriented (SCO) data; their size: 1, 3 or 5 slots; and their FEC encoding: no FEC, 2/3 rate FEC encoding, and 1/3 rate FEC encoding. The 2/3 rate FEC is a (15,10) shortened Hamming code generated by the generator polynomial G _FEC(x) = x ⁵ + x ⁴ + x ² + 1.

The HEC is implemented through an 8-bit linear feedback shift register (LFSR) circuit whose initial value is UAP[0:7] of the master of the piconet. Hence, even in the case where transmissions from multiple masters with overlapping LAPs (thus generating the identical access code as shown in Figure 6.8) were accepted, the corresponding BB_PDU would be rejected because the BB_PDU header would fail its header error check. In other words, both the LAP and the UAP of the master of a piconet are needed to fully identify and accept a BB_PDU transmission on the piconet.

The link control packets include:

The ACL packets are designated as D(M∣H)(1∣3∣5), where "DM" stands for medium speed data that use a 2/3 FEC encoding for the payload; "DH" stands for high speed data where no FEC is used for the payload. The size qualifier 1, 3 or 5 refers to the number of slots occupied by the packet. For multi-slot packets, the frequency does not change until the packet finishes its transmission. The next frequency to be used is the one that would have been used if single-slot transmissions were used in the meantime instead. Note that the size of an ACL packet is odd because a master's transmission must always start at even-numbered slots while slave transmissions must start at odd-numbered slots. Using five-slot packets in one direction and one-slot packets in the opposing direction, the maximum achievable rate for ACL traffic is 723.2 Kbps in the first direction and 57.6 Kbps in the opposite direction.

Knowledge of the type of a BB_PDU and hence its size facilitates power conservation in a slave. In particular, as a slave in a piconet inspects an incoming transmission and finds that the transmission is not intended for that slave (that is, its AM_ADDR does not match the address in the BB_PDU header), the slave could go to "sleep" for a duration of time dictated by the packet type field.

The SCO packets are one slot long and are designated as HV(1∣2∣3). All three variants can support 64 Kbps in each direction over periodically reserved slots using different encoding for the payload data. In particular, HV stands for high-quality voice, and the encoding qualifier 1, 2 or 3 refers to the encoding used for the payload data:

In addition to the above packet types there is a DV packet that combines both ACL, with 2/3 FEC, and SCO, with no FEC, data in a single-slot packet. A device could transmit a DV packet every 2 slots.

Figure 6.10 depicts the low-level baseband operations that occur during the transmission and reception of baseband packets. Note that different operations take place for the packet header versus the payload; the operations for the header and the payload occur serially rather than in parallel as the figure might imply. In the figure, whitening refers to the process of scrambling the transmitted data to randomize them and to reduce the DC bias in the transmitted data. The data are whitened through the use of the whitening word generated by the polynomial G _WHITE (x) = x ⁷ + x ⁴+1. Security features in Bluetooth piconets, including device authentication and link encryption, are discussed in the following LMP section. The CRC operation pertains only to ACL packets, detailed immediately below.

Figure 6.10. Low-level baseband operations during transmission and reception of baseband packets.

As mentioned earlier, the Bluetooth baseband supports two types of links over a piconet. ACL links are used for carrying asynchronous data. The master schedules asynchronous transmissions in slots not already reserved for synchronous (SCO) transmissions. In other words, SCO traffic is of high priority and cannot be preempted for asynchronous transmissions. For each and every slave in its piconet, a master establishes exactly one ACL link that represents a physical pipe between the master-slave pair over which ACL data are exchanged. Point-to-point ACL BB_PDU exchanges are all acknowledged and retransmitted as appropriate. Broadcast (AM_ADDR = 'b000') ACL transmissions from a master to its slaves are not acknowledged but may be repeated several, N _BC, times for increased reliability. Note that, since it is impossible for multiple slaves to acknowledge a transmission simultaneously, it is also impossible to acknowledge a broadcast transmission. In particular, there exists no simple and reliable method to dynamically designate a single slave to acknowledge on behalf of all slaves in the piconet that the broadcast transmission has been successfully received by all slaves.

SCO links carry telephony-grade voice audio through a priori periodically reserved pairs of slots. In a piconet, following a request from a slave or the master, a master may establish up to three SCO links in total between it and all of its slaves. Each SCO link represents a physical pipe between the master and one of its slaves over which SCO data are exchanged. To maintain the high quality of service expected for SCO traffic, the length of the baseband slot, 625 µsec, is selected to minimize the packetization delay for audio traffic and the effects of noise interference. For example, an HV1 BB_PDU carries the equivalent of 10 bytes of audio information, which at 8,000 samples per second and 8 bits per sample takes 1.25 msec (=2*625 µsec) to accumulate. This is the same as the period of transmissions of HV1 BB_PDUs from a device. Unlike ACL transmissions, SCO BB_PDUs are not acknowledged. Note that prior to establishing an SCO link, an ACL link must already exist to carry, at a minimum, the SCO connection control information.

Bluetooth links between devices can be authenticated, encrypted, operated in low-power mode, and in general, qualified based upon application or user requirements. The operation of the baseband in these cases is highlighted in the following link manager protocol section since it is link manager involvement that initiates these sorts of changes in link behavior.

For communication in a piconet to occur, a slave needs to know its master's clock and address. The following sections discuss the inquiry and page mechanisms by which this information is acquired. As Figure 6.4 shows, this two-step process can be trimmed to one step when connecting to known devices.

Authentication of Bluetooth devices is based on a challenge-response transaction. In this transaction, a verifier challenges a claimant by sending to the latter a 16-byte random number in an LMP_au_rand PDU. The claimant operates on the random number and returns the result of the operation to the verifier in an LMP_sres PDU. If the result is the one expected by the verifier, the verifier considers the claimant an authenticated device. Optionally, the two devices may then exchange their roles as verifier and claimant and perform authentication in the opposite direction.

The above procedure occurs when the two devices have a common link key, which is used to operate on the random number. A device may maintain identical or separate link keys for every other device that it wants to authenticate. If a link key does not exist for a device, when an LMP_au_rand PDU is sent, the claimant will respond with an LMP_not_accepted PDU, giving the reason that the key is missing.

When a link key is missing, the devices need to be paired first. With the pairing process, an initialization key is generated and used to authenticate the devices and eventually to create a permanent link key for them. The initialization key is generated by entering a common personal identification number (PIN) in both of the pairing devices, which generates a temporary key. Note that neither keys nor the PINs that generate them are ever sent in clear form over the air. Using the temporary key generated by the PIN, the two devices may proceed with the authentication process as if they had a link key. The only difference is that pairing is initiated using an LMP_in_rand PDU instead of the LMP_au_rand PDU. Certain devices without a user interface may have a fixed, non-changeable PIN. In this case, the PIN entered in a device with a user interface must match this fixed PIN; otherwise authentication is not possible.

Authentication of Bluetooth devices depends upon a shared secret. Commonly used public key and certificate schemes are not appropriate for ad hoc networks of personal devices. These other schemes require the support of trusted authentication agencies and other third-party means of communication that cannot be assumed to be available in ad hoc networks. Authentication keys are 128 bits long and are constructed using the PIN (only for the initial authentication), a 128-bit random number, and a device's BD_ADDR.

Bluetooth devices may store link keys for future authentication without the need to enter a PIN each time. The two primary types of link keys are the unit keys and the combination keys. The former are derived from input parameters available in only one device, while the latter are derived by combining input parameters available in each of the two devices. The use of combination keys is preferred, as it provides for a stronger "bonding" between pairs of devices; a device must store a separate combination key for each other device it wants to authenticate using a stored link key. However, devices of limited storage capacity may store and use just a single link key for authentication of other devices.

To protect the privacy of the data flowing over a Bluetooth link, the link can be encrypted. Encryption in Bluetooth wireless technology is based on a 1-bit stream cipher, whose implementation is included in the specification. The size of the encryption key, which changes with each BB_PDU transmission, is negotiable to match application requirements.

The encryption key is derived from the link key used to authenticate the communicating devices. This implies that prior to using encryption two devices must have authenticated themselves at least once. The maximum key size is 128 bits, but regulatory authorities in various countries may limit the permissible maximum key size. Encryption applies only to the payload of BB_PDUs and it is symmetric, in that both directions of communication are encrypted. Encryption is a link property in that both SCO and ACL packets over this link are encrypted.

A request for encryption starts with the LMP_encryption_mode_req PDU with an encryption mode parameter that distinguishes encryption of a link between two devices (point-to-point encryption), or encryption of broadcast packets as well. In the latter case, a master key is created that is to be used for encryption by multiple devices in the piconet. If the request for encryption is accepted, the devices then negotiate the size of the encryption key exchanging LMP_encryption_key_size_req PDUs. If the negotiation succeeds, the devices can initiate encryption by sending an LMP_start_encryption PDU. Encryption starts by: (a) the master becoming ready to receive encrypted data; (b) a slave becoming ready to transmit and receive encrypted data; and (c) the master becoming ready to transmit encrypted data.

Typically a slave must listen at the beginning of each even-numbered slot to see whether the master will transmit to the device. In the sniff mode, a slave may relax this requirement for its ACL link. The master will transmit to the slave at a reduced duty cycle by starting its transmissions every T _sniff slave listening opportunities (master transmit slots). In particular every, say, T _sniff[j] listening opportunities, slave j will listen for N _sniffAttempt [j] slots for a transmission to it. If data is received, the slave will continue listening until the transmissions stop. The slave will continue listening for an additional N _sniffTimeout [j] listening opportunities for additional transmissions to it. While a slave is in the sniff mode, any ongoing SCO transmissions will still occur as scheduled.

A master may force a slave into sniff mode with an LMP_sniff PDU. Alternatively, a master or a slave may request that the slave enter into sniff mode with an LMP_sniff_req PDU. Both of these LMP_PDUs carry the timing parameters defining the slave operation in sniff mode. These LMP_PDUs also carry an offset parameter D _sniff that determines the time of the first sniff instance. Subsequent sniff instances are separated by the period T _sniff. In the case of a request to enter the sniff mode, the master and the slave may negotiate the timing parameters for this mode.

While sniff mode communications are periodic, in hold mode ACL communications with a slave are suspended in single installments for a time interval referred to as the hold time. While a slave is in hold mode, any ongoing SCO transmissions will still occur as scheduled.

A master may force a slave into hold mode with an LMP_hold PDU. Alternatively, a master or a slave may request that the slave enter into hold mode with an LMP_hold_req PDU. Both of these LMP_PDUs carry the initial value of the hold time. In the case of a request to enter the hold mode, the master and the slave may negotiate the timing parameters for this mode.

In the sniff and hold modes, a slave is still considered a fully qualified active member of the piconet and as such it maintains its AM_ADDR that was assigned to it when it joined the piconet. Note that while in these two modes, SCO transmissions with the slave are not interrupted.

To further reduce power consumption during periods of no activity, a slave may enter the park mode during which it disassociates itself from the piconet, while still maintaining timing synchronization with the piconet. By doing so, it can rejoin the piconet relatively quickly without having to perform inquiry and paging procedures.

A slave that enters the park mode gives up its AM_ADDR. On the other hand, to manage its fast and orderly readmission to the piconet, the master assigns to the slave two temporary 8-bit addresses, the parked member address (PM_ADDR) and the access request address (AR_ADDR). PM_ADDR is used to distinguish up to 255 parked devices (actually, slaves); the address '0x00' is a reserved PM_ADDR. Parked devices could be recalled using their 48-bit BD_ADDR if needed, but the use of the much shorter PM_ADDR allows for increased efficiency in recalling multiple parked devices.^[11] AR_ADDR is used in scheduling the order of readmission of parked devices in a way that minimizes the possibility of collisions.

To maintain synchronization with the piconet and to facilitate the readmission of parked devices in the piconet, the master defines a low-bandwidth beacon channel, which consists of the periodic transmission of broadcast packets. Prior to entering park mode, slaves are notified of the timing parameters of the beacon transmissions, and thus they know when they can wake to receive possible transmissions from the master. Beacon transmissions destined to the parked stations are broadcast transmissions (BB_PDUs with AM_ADDR = 'b000'), for the simple reason that parked devices don't have an AM_ADDR and thus they cannot be addressed explicitly.

The timing parameters for beacon intervals are numerous. They include an offset parameter denoting the time of the first beacon transmission and the period of the beacon instances. They also include the broadcast repetition parameter, the interval following a beacon instant before the master gives the opportunity to parked devices to request to rejoin the piconet, the length of time that the master will continue giving this opportunity, and so on.

Just as in the sniff and hold modes, the master may force a slave into park mode with an LMP_park PDU. Alternatively, a master or a slave may request that the slave enter into park mode with an LMP_park_req PDU. When a slave is to rejoin the piconet, the master broadcasts in the beacon slots an LMP_unpark_BD_ADDR_req or an LMP_unpark_PM_ADDR_req PDU, depending upon whether the parked device is addressed with its 48-bit BD_ADDR or its 8-bit PM_ADDR. Multiple parked devices can be invited with a single unpark LMP_PDU. In the unpark LMP_PDUs, the master also includes the new AM_ADDR to be assigned to the parked device when it rejoins the piconet as a slave. Note that a parked device cannot be invited to rejoin a piconet when there are already seven active slaves in the piconet. In the latter case, the master may have to park some active devices and free the corresponding AM_ADDRs prior to unparking a parked device.

A piconet supports up to three SCO links for telephony-quality (64 Kbps) voice communications. SCO packets transmitted on the SCO links are of high priority and can preempt any other activity that the device may be involved with, like pages and inquiries, holds, and so on. A device requests the establishment of an SCO link with an LMP_SCO_link_req PDU. This LMP_PDU contains the audio parameters like the period T SCO, the SCO BB_PDU type and the air-mode, which represents the voice codec type. Supported codec types are: 64 Kbps μ-law or A-law PCM format, or 64 Kbps CVSD (continuous variable slope delta) modulation format. With such a high resolution of voice traffic, cellular phone conversations carried to, say, a headset that is connected with a cellular phone over a Bluetooth SCO link should not degrade in quality.

When the master responds positively to a slave's LMP_SCO_link_req PDU or sends its own LMP_SCO_link_req PDU, it supplies the offset D_SCO that identifies the time of the first transmission for the new SCO link, and an SCO link unique identifier, or handle. Either the master or the slave can subsequently request to change the parameters of the SCO link, using the LMP_SCO_link_req PDU again, or to remove the link altogether, using an LMP_remove_SCO_link_req PDU. The latter transactions make use of the SCO link handle to identify the particular SCO link whose parameters or status is to be changed.

To control the minimum bandwidth assignment for ACL traffic between two devices, or equivalently the maximum access delay of ACL BB_PDUs, the maximum polling interval ^[12] for a slave can be adjusted as needed. A master can enforce a new maximum polling interval using an LMP_quality_of_service PDU. In this case, the slave cannot reject the adjustment of the polling interval determined by the master. On the other hand, a master or a slave may request a change in the polling interval with an LMP_quality_of_service_req PDU. In this case, the request can be either accepted or rejected by the other party.

Both of these LMP_PDUs also carry the number of times, N _BC, that each broadcast packet is to be repeated. Since this parameter relates to the operation of the entire piconet, and not just to the ACL link between a slave and the master, N _BC is meaningful only when it is sent from the master. When this parameter is included in a request LMP_PDU from a slave, it is ignored.

When two devices have already communicated with each other, they may subsequently reconnect with each other more rapidly, since they can bypass the inquiry process. However, during an inquiry response, a slave provides paging information to the master in an FHS packet. When bypassing the inquiry process, this FHS packet is also bypassed. Thus, if a device has modified its paging parameters, perhaps to switch to an optional paging scheme or to change its T _pageScan interval, the master will not become aware of the change.

With the paging scheme LMP_PDU transaction, devices can announce or even negotiate the paging scheme to be used the next time these devices page each other. With an LMP_page_mode_req PDU, the requesting link manager suggests to the other link manager the paging scheme to be used when the requesting device pages the other. Likewise, with an LMP_page_scan_mode_req PDU, the requesting link manager suggests to the other link manager the paging scheme to be used when the other device pages the requesting device. Rejecting any of these request LMP_PDUs implies that the current paging scheme is not to be changed. However, a request to change to the mandatory paging scheme cannot be rejected. Support for this transaction is optional.

A paging device becomes the default master of the resulting piconet, although circumstances may necessitate that the roles of the master and the slave be exchanged. For example, such an exchange is needed to implement the LAN access profile using PPP (described in Chapter 15). To initiate the process of master-slave role switch, a device sends an LMP_switch_req PDU, which upon acceptance will initialize the role switch. The switch basically comprises the process of migrating from the master/slave transmit timing sequence in the piconet of the old master (the new slave) to the master/slave transmit timing sequence in the piconet of the new master (the old slave). Support for a master-slave role switch is optional.

A device can request updated clock information from another device to optimize various link controller operations.

An LMP_clock_offset_req ^[13] PDU sent by a master results in a slave returning the most current offset between the native clocks of the slave and the master as registered by the slave. This information can be used to optimize the paging time when the master pages the slave again in the future. Support for this transaction is mandatory.

An LMP_slot_offset PDU carries with it the slot offset, in microseconds, between the start of the time of a transmit slot from the master and the corresponding transmit slot from the slave, if the slave were to be a master. This information is used to optimize a master-slave role switch. Support for this LMP_PDU is optional.

An LMP_timing_accuracy_req PDU results in returning the long-term jitter, in microseconds, and drift, in parts per million (ppm), of the receiving device's clock. This information is used to optimize the wake time for a device after a long period of inactivity while still being associated with a piconet, such as waking after hold mode, or waking prior to a master's transmission at a sniff slot or a beacon slot for a parked device. Support for this LMP_PDU is optional; when it is not supported the jitter and accuracy are assumed to be at their maximum value of 10 μsec and 250 ppm, respectively.

An LMP_supervision_timeout PDU sent by a master includes the link supervision timeout value used by a link controller to detect the loss of a Bluetooth link between the master and a slave. Support for this LMP_PDU is mandatory.

Link managers typically exchange information about each other to better coordinate their interaction. The LMP_version_req PDU contains the LMP version supported by the sender of this PDU. The receiver of this LMP_PDU returns the LMP_version_res PDU which contains its own supported LMP version. The version number is provided as a triplet [versionNo:companyID:subVersionNo]. The version number part of the triplet is a version of LMP as defined by the SIG. The subversion number is relative to a company that may have its own particular implementation of the protocol. Support for this LMP_PDU transaction is mandatory.

The LMP_features_req PDU contains the optional radio, baseband, and link manager features supported by the sender of this LMP_PDU. The receiver of this LMP_PDU returns the LMP_features_res PDU, which contains its own supported features. These features include the supported packet types, other than the mandatory FHS, NULL, POLL, DM1 and DH1; supported power control modes, voice codecs, encryption, role switch, optional paging schemes and so on. Support for this LMP_PDU transaction is mandatory.

With the LMP_name_req PDU, the requesting link manager requests the user-friendly name of the device that receives this LMP_PDU. The user-friendly name is the name that a user of a device assigns to it. Within a device a name is encoded in UTF-8 and it can be up to 248 bytes long. Since the name of a device can be longer than a single DM1 packet, when a device requests the user-friendly name of another device it also provides an offset parameter that the responding device can use to transmit the proper segment of its name, using the LMP_name_res PDU.

The UTF-8 encoding [IETF96] for device names has been selected for its support of international languages because the Bluetooth wireless technology is targeted for worldwide use. UTF-8 characters are encoded using sequences of 1 to 6 bytes. For compatibility with the widely used ASCII character set, ASCII characters are encoded using a one-byte UTF-8 character, which has the same value as the corresponding ASCII character. Hence, the user-friendly name of a Bluetooth device can be up to 248 ASCII characters long.

LMP is a transport protocol for control information between link managers in devices. LMP does not encapsulate PDUs of any higher communication layer. As such, LMP transactions may occur without involvement of any higher layer, such as L2CAP or the host itself. When a host application in a device wants to communicate with one in another device, the first device sends an LMP_host_connection_req PDU which the receiving device will either accept or not. If the connection request is accepted, the two link managers will negotiate the parameters of the link, like authentication and QoS. When link managers finish negotiating, each sends an LMP_setup_complete PDU. Only after both link managers have issued the LMP_setup_complete PDU can communication that does not involve LMP_PDUs commence between the devices.

When any device wants to terminate its link with another device, it issues an LMP_detach PDU with a reason parameter explaining why the link is to be terminated. The LMP_detach PDU cannot be contested and the link between the two devices will be terminated immediately.

Support for the LMP_PDUs in this section is mandatory.