Why Bluetooth 1.1?

What Changed?

Many changes took place throughout the Bluetooth specification. This section looks in detail at each of the changes and gives some background on why the changes were required.

Radio

When the Bluetooth specification began, Spain, France, and Japan used restricted portions of the ISM band. Spain and Japan have now opened up the full band, and France has a change scheduled to take place in 2003. This all means that the original frequency allocation table is no longer valid. The Bluetooth SIG is lobbying to get the whole world to adopt the complete ISM band, so, rather than continuing to show France in the table, Erratum 1044 moved it to a footnote to emphasize that limited-frequency bands are the exception not the rule. (By removing Spain from the list of exceptions, this erratum coincidentally removed an error in the table: The guard band for Spain had been too large.)

Baseband

Interoperability testing during unplugfests showed that the description of a master-slave switch was ambiguous. Erratum 1067 completely rewrote Section 10.9.3 of the baseband specification to make the description of master-slave switch clearer.

The Bluetooth security procedures begin with units generating an initialization key that is derived from a PIN code and a Bluetooth device address. This key is used to secure data used to generate link keys. The link keys, in turn, are used to generate encryption keys for encrypting data on the link. In version 1.0b, the initialization keys were authenticated. The initialization keys are discarded as soon as the link keys have been generated, and the link keys are authenticated before the encryption keys are generated. There is really no need to authenticate both link keys and initialization keys, so Erratum 1071 changed the text to make authentication happen after link key exchange. Sometimes authentication is used to verify the identity of a unit, but the units don't go on to encrypt traffic, so the same errata marked generation of an encryption key as optional.

Version 1.0b of the specification was unclear on the order of bits from the CVSD encoder, which caused some interoperability problems. Erratum 1077 clarified that CVSD bits should be sent over the air in the same order that they are generated by the CVSD encoder.

In version 1.0b of the specification, ARQN numbers, which are used to acknowledge data transfer, were frozen throughout hold and sniff modes. Data can be transferred during sniff mode, and freezing the ARQN numbers made the sniff-mode data transfer unreliable. In hold mode, no data can be transferred, so there's no point in specifying that ARQN numbers don't change. Erratum 1079 removed the text that stopped ARQN numbers from changing during hold and sniff modes, thus giving sniff mode the capability to transfer data reliably.

The baseband and Link Manager sections described the parameters used in sniff mode inconsistently. Erratum 1081 fixed this by bringing the baseband in line with the Link Manager.

Link Manager

With 25 critical errata, the Link Manager attracted more changes than any other section of the 1.0b Bluetooth specification. Because there were so many changes to the Link Manager, this section is split up into the different areas of Link Management behavior that were affected.

Security

In version 1.0b, there was no clearly defined way for the slave to stop encryption. Erratum 1092 specified that any unit wanting to stop encryption could send an LMP_encryption_mode_req with the encryption-mode parameter set to no encryption (zero). If the other device responds with LMP_accepted, the master sends an LMP_stop_encryption_req message. The same erratum specified that encryption had to be stopped before an encryption key could be changed.

Erratum 1095 corresponded with Erratum 1071 from the baseband: It removed the redundant authentication on link keys and specified that mutual authentication should happen every time link keys are changed.

Version 1.0b allowed link keys to be changed at any time. For the semipermanent keys used on point-to-point links, this makes sense, but temporary keys are in use only for one session, so they don't need to be changed. Errata 1098 and 1099 changed the specification so that temporary link keys could not be changed. Erratum 1098 also removed some text that specified that the semipermanent link keys should be stored in nonvolatile memory; in version 1.1, it just says that they should be stored—where they go is up to the implementer. Errata 1098 and 1099 also specified that after changing link keys, mutual authentication had to take place. Previously, this was required by the baseband part of the specification, but it had been forgotten in the Link Manager specification.

When link keys are changed, encryption is stopped and restarted, but in version 1.0b, the Link Manager specification did not say how it should be restarted. Some implementers thought that it automatically restarted without signaling, while others thought that LMP messages were needed to restart encryption. By adding a reference to the procedures used to restart encryption, Erratum 1100 got rid of the ambiguity and made it clear that LMP_encryption_mode_req should be used to restart encryption.

Data transmission must be stopped when encryption mode changes; otherwise, data could be sent when the encryption mode is indeterminate, which would lead to data being corrupted or lost. To avoid this, data transmission is stopped before any encryption change. Version 1.0b of the specification said that data traffic had to be temporarily stopped, but there was some disagreement among implementers as to when to stop it: Should it stop immediately, at the end of an ACL packet, or at the end of an L2CAP packet? Erratum 1114 clarified that data transmission should stop at the end of the current ACL packet with L2CAP data.

As a side effect of a successful authentication procedure, a parameter called the Authenticated Ciphering Offset (ACO) is calculated and then used to generate the ciphering keys, which are then used to encrypt data. If a master and a slave initiated authentication together, they could end up with two different ACOs, so they would not be capable of decrypting one another's encrypted data. To keep this from happening, Erratum 1203 introduced a new rule that link managers must reply to any outstanding LMP_au_rand authentication request signals with LMP_sres secure response signals before sending their own LMP_au_rand authentication request signals. It is still possible for LMP_au_rand messages to cross, however. If this happens and the master receives an LMP_au_rand before it has received a response to its own LMP_au_rand, it is allowed to respond with LMP_not_accepted with the error code "LMP Error Transaction Collision." In this way, Link Managers should be capable of ensuring that only one authentication is in progress at any time, thus also avoiding mismatching ACOs.

Allowed and Disallowed Messages

During unplugfests and other interoperability testing, it was found that many implementations had problems with LMP messages sent before the LMP_host_connection_req. Erratum 1093 clarified exactly which LMP messages could be sent in the interval between paging and the LMP_host_connection_req. The list allowed for version 1.1 is: clock offset request, LMP version, supported features, name request and detach.

Erratum 1109 clarified how the Link Manager should handle PDUs that are disallowed on a link. Some Link Managers had been taking drastic action and disconnecting if they saw a disallowed PDU. This seemed like an overreaction to others, who simply ignored the PDUs. Even ignoring them caused problems because some Link Managers hung waiting for a response that never came, and then they timed out. To solve all these problems, version 1.1 now says that if the disallowed PDU is one that expects a response, then an LMP_not_accepted with a reason code "PDU not allowed" should be sent as a response; otherwise, the PDU should be ignored.

Transactions

During unplugfests and other interoperability testing, a lot of confusion arose about transaction IDs—in particular, the IDs to be sent on the LMP_setup_complete messages. Several implementers gave up checking the transaction IDs altogether as the only way to achieve interoperability! Erratum 1097 clarified the situation by simply stating, "The transaction ID shall be 0 if LMP_setup_complete is sent from the master, and 1 if it is sent from the slave."

LMP uses transaction IDs to identify whether a transaction was started by the master or the slave, but in version 1.0b it was unclear exactly what a transaction was. Erratum 1185 made it clear that a transaction could extend across several LMP exchanges. For instance, it said that all the security sequences in Section 3.3, including mutual authentication after link key creation, form a single transaction. Therefore, all use the transaction ID from the first LMP_in_rand. The erratum added several more examples to make it clear exactly what was defined as a single transaction.

Master-Slave Switch

The description of a master-slave switch in version 1.0b was ambiguous, which led to many interoperability problems. Version 1.1 greatly improved the descriptions of how it should work. Erratum 1094 was part of this improvement: In version 1.0b, there was no description of how to do a master-slave switch during connection setup, and no specification of exactly when the switch messages should be sent. Erratum 1094 clarified when LMP_setup_complete should be sent and when non-LMP traffic can start.

Another part of the master-slave switch ambiguity in version 1.0b was that how to calculate the slot offset between master and slave clocks was not clearly defined. Erratum 1194 clarified this. The message contains a BD_ADDR and a slot offset. The BD_ADDR is the slave that will become master in a switch. To calculate the slot offset, you work out the value in microseconds of the start of a TX slot as if the slave were master of a piconet. Then you subtract the value in microseconds of the start of the current master's transmit slot. You then do a modulo 1250 operation to get a value between 0 and 1249. So, if the time that a transmit slot starts on the current piconet is TXstart _{slave's clock} and the time that a transmit slot would start if the slave were master is TXstart _{master's clock}, then the offset is given by this equation:

offset = (TXstart _{slave's clock} - TXstart _{master's clock}) mod 250

A third problem with the master-slave switch was that the instant to make the switch was not defined. Erratum 1190 added a switch instant parameter to the LMP_switch_req to indicate when the switch should happen. Procedures such as stopping traffic before the switch and determining the exact sequence of messages were also defined in this erratum. Some implementations had trouble reacting fast enough to a master-slave switch request, so this erratum also said that the switch instant should be set at least 2*T_poll or 32 slots (whichever is greater) after the LMP_switch_req.

Low-Power Modes

Erratum 1101 covered the LMP_unpark_PM_ADDR message. This message contains an AM_ADDR. In version 1.0b, 4 bits were allocated for the AM_ADDR, but only 3 are needed. This confused implementers, who did not know whether they should use the high bits or low bits. Version 1.1 specifies just 3 bits for the AM_ADDR, so there can be no confusion on where to store it.

In version 1.0b, the sniff parameters sniff attempt and sniff timeout were counted in slots. Some implementers counted transmit and receive slots, and some just counted receive slots. This obviously caused interoperability problems because some implementers made the sniff attempt and sniff timeout twice as long as the others did. Erratum 1102 added the description "number of receive slots" to these two parameters to ensure that everybody interprets them in the same way.

Erratum 1106 removed a section that allowed a master to force sniff mode. This proved to be an impractical feature because the master could not tell whether the slave could support the sniff settings that it supported. Masters can still request slaves to enter sniff mode, so removing the capability to force sniff mode does not make any great change in functionality.

Because the link control level packet delivery is unreliable, there were potential problems with hold mode. For example, a master could ask a slave to hold, and the slave would send a response that then got lost. The master would then continue trying to hold the slave, while the slave was inactive. If the link supervision timeout didn't elapse, the master would still be trying to hold the slave when it came back out of hold mode, so the slave would exit hold mode only to go straight back in again. Obviously, this sort of thing can waste a lot of bandwidth, so the LMP_hold message was changed by Erratum 1188 to add a hold instant parameter specifying exactly when the hold should happen. That way, if the Link Controller did keep trying to send a stale LMP_hold message, the device that received it could tell that the message was out-of-date because the hold instant would be in the past. To give the message a chance to work its way through from one Link Manager to the other, the hold instant must be set to at least 6*T_poll slots in the future.

Erratum 1189 attempted to clear up a problem with entering park mode. It had been possible for a master to park a slave: The slave replied with LMP_accepted and parked, but the master didn't see the LMP_accepted and thus didn't know the slave was parked. As a result, the master kept trying to park the slave. Alternatively, the master might assume that it had missed an LMP_accepted and believe a slave to be parked when, in fact, the LMP_park message had been lost. This could lead to the master reusing the AM_ADDR for a slave that was still active. To mitigate this problem, some timers were introduced into version 1.1. The slave must now try to send the LMP_accepted message until it gets a baseband acknowledgement or until 6*T_poll slots have passed, whichever is sooner. The master is not allowed to reuse the parked slave's AM_ADDR until 6*T_poll slots after it has received LMP_accepted. If it doesn't receive LMP_accepted, then a link supervision timeout happens and the slave is detached. These procedures aren't perfect, but it seems that there is no perfect way to guarantee that a slave has been parked using messages across an unreliable radio link. These procedures are at least a lot more reliable than the 1.0b procedures for parking.

Erratum 1189 also removed the forced park mode because there was no way to guarantee that the slave could handle the beacon parameters that were being forced upon it.

Multislot Packets

In version 1.0b, the master could control whether the slave used multislot packets, but the slave had no such control over the master. This was a problem for slaves with limited capabilities, for example, because they were trying to meet tight time constraints in scatternets. Erratum 1096 made the default for any new connection single-slot packets. This included connections formed by slaves returning from park mode or formed by a master-slave switch. In version 1.1, multislot packets cannot be used until they have been negotiated with LMP_max_slot and LMP_max_slot_req.

Detach

When a slave has been detached (disconnected), the master can reuse the AM_ADDR that it used to identify the slave. This is the procedure that Erratum 1187 defined: First the LM initiating detach finishes sending the current ACL packet with L2CAP information and stops sending L2CAP data. Obviously, it makes no sense to detach from a device and still try to send it data! Next an LMP_detach message is queued for transmission, and the Link Manager starts a timer of 6*T_poll slots (where T_poll is the poll interval for the connection). If this timer expires before a baseband acknowledgement is received, then the link is dropped and a link supervision timer is started. When that timer has elapsed, the AM_ADDR for the dropped link can be reused. If a baseband-level acknowledgement for the LMP_detach is received before the 6*T_poll timer expires, the detached link's AM_ADDR can be reused after 3*T_poll slots. On the receiving side, a timer is also used. A master starts a timer of 6*T_poll slots when it receives an LMP_detach, and a slave uses a timer of 3*T_poll. When this timer expires, the link can be dropped and the AM_ADDR can be reused. If the LMP_detach message is lost due to interference, then a link supervision timeout will occur and the link will be detached eventually anyway. These procedures might seem complicated, but they avoid using the same address for two devices at the same time.

Timing

Erratum 1191 added an explanation of interaction between the Link Manager and the Link Controller. The erratum explains that the Link Controller guarantees to communicate only once every T_poll slots. So, for instance, if a Link Manager issues a detach or park, it can't immediately reuse the AM_ADDR because it has not yet received a Link Controller–level acknowledgement indicating that the old connection is inactive. The erratum also points out that Link Managers must be aware of Link Controller–level timings during a master-slave switch and when starting hold mode because Link Managers must read the baseband clock to synchronize these actions.

Erratum 1193 also dealt with timings, but this time it was Link Management–level timing. LMP defines a 30-second timeout between an LMP PDU and its response. Erratum 1193 said that this timeout should also apply between a Link Control–level connection being established and a LMP_host_connection_req being sent. It also said that the LMP_setup_completed should be sent before the LMP response timeout from the preceding transaction had timed out. This change was made because some implementations were hanging up during connection setup, and there was no real mechanism to allow a Link Manager to escape from that situation—it was just stuck waiting with no reason to go on and no reason to disconnect.

Flow Control Lag

When a baseband receives a packet with its flow bit set to 0, it should stop transmitting L2CAP data. However, delays in processing the flow bit can mean that there is a lag between receiving the 0 flow bit and acting on it. This lag can result in data being received for a while after the flow off bit has been set. For maximum efficiency, it is useful to know what the likely lag at the other end of a link is. That way, a flow bit can be set to 0 when there are still enough buffers left to accommodate data sent during the flow lag period. To allow for this information to be passed, Erratum 1305 added a 3-bit field into the features parameter to give the total amount of L2CAP data that can be sent following the receipt of a valid payload header with the payload header flow bit set to 0. The unit for flow lag is 256 bytes (so, for example, 0b010 gives a flow lag of 512 bytes).

Host Controller Interface

There were no critical errata raised against the Host Controller Interface for version 1.0b, but a change in functionality was made as a result of Erratum 1142 (this was not listed as critical). In version 1.0b, an HCI reset command left a Bluetooth device in standby mode and caused it to lose its current operational state. Because the device lost all state after the reset was performed, it had no way to tell if it had been reset or just powered up; the command complete was returned before the reset was performed instead of afterward.

In Erratum 1142, the reset caused a device to lose operational state below HCI, so in version 1.1, connections are dropped and parameters that are not stored (such as inquiry window) return to default values. The HCI interface itself did not reset: This means that USB devices do not need to re-enumerate, saving a good deal of time for them. Because the HCI interface does not reset, it is possible to tell the difference between a reset and a power-on, so in version 1.1, the Command Complete event for a reset is sent after the reset is executed. Some implementers have criticized the new reset because it prevents implementers from resetting on-chip processors. Not being able to do a complete chip reset also means that problems such as memory leaks may persist through an HCI reset. However, the new reset scheme is better for the higher layers because they now know when a reset has completed and can rely on HCI transport to function seamlessly across a reset (although the upper layers aren't allowed to send commands during the reset itself).

Logical Link Control

L2CAP has a response timer, RTX, that is used to keep track of the time it takes to get a response to a signaling message. Version 1.0b stated that when the timer expired, the channel should be disconnected, but it wasn't clear exactly how this should happen. The normal procedure for disconnecting an L2CAP channel is to send an L2CAP_DisconnectReq, but if the RTX timer has expired, that implies that the peer L2CAP isn't listening to signaling requests. It seems rather pointless to send another signaling request! Erratum 1000 clarified that when the RTX timer expires, the channel goes straight to the closed state, with no extra signaling messages required.

L2CAP uses channel IDs to identify which channel a particular request affects. Usually, if an invalid channel ID is received in an L2CAP signal, a command reject is sent back. For configuration requests, however, the 1.0b specification required a configuration response to be sent. This made it impossible to reject configuration on an invalid channel ID. Erratum 1002 corrected this by allowing a command reject to be sent in response to a configuration request when an error condition made a reject appropriate.

RFCOMM

RFCOMM is based on GSM TS07.10, so unless RFCOMM specifically overrides the GSM standards, the rules of GSM TS07.10 are used. This means that RFCOMM could send several multiplexor control messages in one frame. RFCOMM is used in the headset profile, which is likely to be implemented in devices with very little memory or processing power, so keeping it simple is a good idea. In the interests of simplifying this protocol layer, Erratum 1047 limited RFCOMM to sending only one multiplexor control message per frame.

The Modem Status Command (MSC) was the flow-control mechanism for individual channels in version 1.0b. Erratum 1050 clarified which bits were used for flow control. The draft version of 1.1 also introduced credit-based flow control to RFCOMM. With credit-based flow control, units grant credits to one another. Then each time a packet is sent, one credit is used up. Before the introduction of credit-based flow control, RFCOMM channels used FCON and FCOFF messages for flow control on individual channels. Because Bluetooth channels are unreliable, these messages could require several retransmissions to switch off the flow of packets. This could lead to RFCOMM layer buffers overflowing and data being lost,

RFCOMM uses a new frame type for credit-based flow control with the CL1–CL4 field redefined. In GSM TS07.10, this field gives the convergence layer to use. In RFCOMM versions up to 1.0B, this field was forced to 0. In version 1.1, this field is used to indicate whether the frame carries credit-based flow-control messages.

RFCOMM uses a Parameter Negotiation (PN) command to negotiate various parameters, including frame size and flow-control method. Use of the PN command was optional in the draft version of 1.1, but it was made mandatory in the final version because, otherwise, the responding device could miss the chance of ever negotiating the parameters on its channel. Because credit-based flow control must be negotiated without mandatory parameter negotiation, units could not rely on being able to use credit-based flow control. The k1-k3 field is used to indicate the initial number of credits issued to a peer; there are 3 bits, so the initial credit value can range from 0 to 7. If credit-based flow control is not used, the k1–k3 bits stay as 0.

Erratum 1048 said that units must support the default RFCOMM frame length because they couldn't rely on negotiating parameters. In the final 1.1 specification, however, parameter negotiation on connection setup was made mandatory, so this no longer held true. The same erratum also pointed out that units did not have to accept any changes in parameters once an RFCOMM channel was set up.

SDP

Erratum 1159 corrected a simple typo. The value given for the base UUID in the SDP part of the specification was invalid. The correct value was already given in the Bluetooth Assigned Numbers document: 00000000-0000-1000-8000-00805F9B34FB.

Similarly, Erratum 1160 corrected the value given to PublicBrowseRoot to 00001002-0000-1000-8000-00805F9B34FB (UUID16: 0x1002). Again, the correct value came from the Bluetooth Assigned Numbers document.

Erratum 1163 clarified the meaning of MaximumAttributeByteCount. Some implementers had thought that it specified the maximum number of attributes that could be returned in all responses to a request. In fact, it specified the maximum number of attributes that could be returned in a single response packet, but the response could be split over several packets.

Cordless Telephony Profile

Version 1.0b of the Cordless Telephony Profile has a service record with service class Generic Telephony followed by service class Cordless Telephony. The rules for service class UUIDs in profiles state that the most specific class comes first, with more generic classes coming later. Erratum 1195 reversed the order of the service classes to make Cordless Telephony come before generic Telephony.

Erratum 1306 made park mode optional for the Cordless Telephony Profile. This was done because the Cordless Telephony Profile was the only profile that had park mode as mandatory, and LMP changes had made 1.0b park mode incompatible with version 1.1. By making park optional, the profile allowed devices implementing the Cordless Telephony Profile to be backward compatible with version 1.0b.

Intercom Profile

Erratum 1220 was similar to Erratum 1195 from the Cordless Telephony Profile: The service classes Intercom and Generic Telephony had been wrong in the service records, so they were reversed to put Intercom (the most specific class) first.

Erratum 1238 corrected an error in Figure 10.1, which had an SCO link being established by the outgoing side rather than the incoming side.

Headset Profile

Erratum 1204 simply corrected a typing error: The ServiceClass0 which had been Headset" was corrected to read "HeadsetAudioGateway."

Erratum 1211 changed the type of the headset gain value from an unsigned octet to a decimal numeric constant. This change was made because, if an unsigned octet was used, some possible values could match the codes used for command termination and response formatting.

Erratum 1215 made the RING signal before connecting a headset call optional. This was done because the Headset Profile might be used for data calls, and, in this case, no RING signal is needed. The same erratum also clarified that in-band (audio) ring tones could be sent instead of the RING signal.

Erratum 1217 finished a correction that was made between versions 1.0a and 1.0b, when pairing was made optional for the Headset Profile. The change had been made to pairing, but bonding was left as mandatory, which made no sense, so both were made optional.

Dialup Networking Profile

Erratum 1198 was also similar to Erratum 1195 from the Cordless Telephony Profile: The service classes Dialup Networking and Generic Networking had been wrong in the service records, so they were reversed to put Dialup Networking (the most specific class) first.

Erratum 1282 was a minor change bringing the Dialup Networking Profile in line with the Generic Access Profile. Version 1.0b had required devices supporting limited discoverable mode to also support general discoverable mode. This was changed to allow a device to support just limited discoverable mode (because a device in limited discoverable mode will respond to general inquiries anyway).

Fax Profile

Erratum 1206 made nondiscoverable and nonpairable modes optional. Previously they had been mandatory, but this requirement was removed because it did not contribute to interoperability, which, after all, is the goal of the profile's requirements.

Erratum 1207 was also similar to Erratum 1195 from the Cordless Telephony Profile: The service classes Fax and Generic Telephony had been wrong in the service records, so they were reversed to put Fax (the most specific class) first.

LAN Access Profile

Erratum 1055 changed the default PIN for a LAN access point. It had been set to a zero-length PIN, but the rules of the HCI interface did not allow a zero-length PIN to be set. Instead, the default was set to a single byte with all bits set to 0.

Assigned Numbers

Erratum 1113 wasn't really an erratum; it just created a new version number in the assigned numbers so that the LMP_version_req and LMP_version_res messages have a value assigned for version 1.1. This erratum was originally raised on the Link Management part of the specification because the Link Management protocol needed the parameter, but the change was made in the Bluetooth assigned numbers.

In version 1.1, the assigned numbers were split off from the rest of the core specification. This was done because the assigned numbers are likely to change often—for instance, as new profiles are released or as new manufacturers are assigned company IDs. Separating the assigned numbers avoids having to keep re-releasing the whole core specification every time a new number is added.