Bluetooth SIG.

Confidential

Page 1 of 8

Bluetooth SIG

Using eSCO in Profiles: A Whitepaper

This document is for discussion only Version number 1 12 September 2003 Prime Contact: Joel Linsky Tel: +1 858 597 5909 Email: jlinsky@siliconwave.com

Bluetooth SIG Confidential

Page 2 of 8

The information presented is intended to be a proposal for review by the Radio 1.0 improvements group within the Bluetooth Special Interest Group (SIG). Bluetooth Special Interest Group (SIG) The following Promoter Companies are representatives in the Bluetooth Special Interest Group: Ericsson Mobile Communications AB * IBM Corporation * Intel Corporation * Nokia Mobile Phones * Toshiba Corporation * 3Com Corporation * Agere Systems * Microsoft Corporation * Motorola Inc * Primary Contributors to this document Joel Linsky (Document Owner) Terry Bourk Martin van der Zee Henrik Hedlund Silicon Wave, Inc. Silicon Wave, Inc. Ericsson Technology Licensing AB Ericsson Technology Licensing AB

Revision History Revision 1 Date 12 Sept 2003 Comments First draft for discussion.

Disclaimer and copyright notice THIS DRAFT DOCUMENT IS PROVIDED "AS IS" WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE. All liability, including liability for infringement of any proprietary rights, relating to use of information in this document is disclaimed. No license, express or implied, by estoppel or otherwise, to any intellectual property rights are granted herein. This document is an intermediate draft for comment only and is subject to change without notice. Readers should not design products based on this document. Copyright Bluetooth SIG Inc. 2003. Third-party brands and names are the property of their respective owners

Using eSCO in Profiles Whitepaper.doc 12 September 2003 2 Copyright Bluetooth SIG 2003

Bluetooth SIG Confidential

Page 3 of 8

Table of Contents
Section ............................................................................................................................... Page

Table of Contents ........................................................................................... 3 1 2 Introduction ......................................................................................... 4 What Profiles Need to Know about eSCO ......................................... 5 2.1 Bandwidth Negotiation ................................................................ 5 2.2 Maximum Latency ....................................................................... 5 2.3 Air Mode Negotiation................................................................... 6 2.4 Retransmission Effort.................................................................. 6 2.5 Packet Types .............................................................................. 7 Conclusions and Recommendations ................................................ 8

Deleted: 5

Using eSCO in Profiles Whitepaper.doc 12 September 2003 3 Copyright Bluetooth SIG 2003

Bluetooth SIG Confidential

Page 4 of 8

Introduction

Extended SCO (eSCO) is a new feature in the Bluetooth 1.2 Core Specification. This feature allows for synchronous logical transports to be created over the air. These logical transports can support a wide variety of bandwidths and the bandwidths for uplink and downlink need not be the same. The maximum tolerable latency can be set by the Host. In addition, eSCO gives a CRC to the synchronous data packets and allows for retransmissions. These features of eSCO make it a very powerful new feature and are also more complex than SCO. With eSCO there are approximately 55 different configurations that achieve symmetric 64kbps and many more combinations when all possible bandwidths are taken into account. By comparison the Bluetooth 1.1 synchronous logical transport, SCO, only supports one bandwidth (64kbps), has no CRC, does not allow retransmissions and only has three combinations (HV1, HV2 and HV3). SCO is very limited in its capabilities, but it is also relatively simple from the negotiation point of view. If we, the Bluetooth developers community, try to start making eSCO work without thinking of the context we probably wont end up with an interoperable feature and people will start thinking of eSCO in the same way they think of Park today. So how do we fix this problem? This document presents an overview of how eSCO interacts over HCI and attempts to educate the reader, who many not are familiar with the detailed aspects of eSCO, to be able to update profiles that want to use eSCO. In many cases this document presents the reader with questions as helpful hints on design decisions. Note that this document does not answer the question of how a profile will choose to use SCO or eSCO. Depending on the scenarios and configurations that prevent the use of retransmissions, the added complexity of eSCO may not be justified. Nor does the document address the issue of how or when a profile may decide to change the configuration of the synchronous link. These issues are beyond the scope of this document simply because this document doesnt attempt to address the content of the synchronous link.

Using eSCO in Profiles Whitepaper.doc 12 September 2003 4 Copyright Bluetooth SIG 2003

Bluetooth SIG Confidential

Page 5 of 8

What Profiles Need to Know about eSCO

This section contains information on what profiles need to know about eSCO. This lets the developers of profiles make intelligent decisions on what needs to be in a profile and what doesnt. The main interface between a profile and a Controller are two HCI commands: HCI_Setup_Synchronous_Connection HCI_Accept_Synchronous_Connection.

Both of these commands have the following parameters: Transmit_Bandwidth Receive_Bandwidth Max_Latency Voice_Setting Retransmission_Effort Packet_Type

These parameters give constraints on what LMP can do during the eSCO negotiation. The details of these parameters are given in the following sections.

2.1 Bandwidth Negotiation

Transmit and receive bandwidth are not negotiated in eSCO at the LMP level. This means that either the eSCO link is established with exactly the requested bandwidth, or the eSCO link is rejected. It is the Host / Profile that determines the requested bandwidth. The reason for this is that it is not possible for LMP to make intelligent decisions as LMP doesnt know the data content. Therefore, transmit and receive bandwidth need to be negotiated prior to initiating eSCO via HCI. The headset and hands free profiles only support 64kbps audio it is clear that when the profiles are started that there is one, and only one, bandwidth that can be supported. In the future, when the AV profiles use eSCO they may support a variety of bandwidths and therefore the profile would need to negotiate the bandwidth prior to initiating the eSCO link. If the profile has needs to adjust the data rate during the connection (for example, based on a change in radio link conditions), this will need to be discussed with Radio1. At the host or profile level if the two devices do not agree on the transmit and receive bandwidth parameters the eSCO link setup will fail at the LMP layer with an LMP_not_accepted_ext PDU. Both Hosts have to specify exactly the same transmit and receive bandwidth in the HCI_Setup_Synchronous_Connection and HCI_Accept_Synchronous_Connection command, otherwise the eSCO link will be rejected.

2.2 Maximum Latency

The maximum latency parameter sets an upper bound on the latency of the eSCO data and sets bounds on the maximum number of retransmissions and eSCO interval. Given the max_latency and bandwidth requirement, this can imply limitations on the possible Packet Types and Packet Lengths the Link Manager can select. The max_latency parameter is part of the LMP eSCO negotiation in an indirect manner; it simply sets an upper limit on some combinations of parameters used by LMP. When using CVSD, A-law or u-law the max_latency parameter is probably not something that the profile would make recommendations on since this has more to do with the maximum latency acceptable in the implementation. If the Latency parameter is set to something else than 'don't care', it is recommended to use the same value at both sides, to reduce the negotiation of all possible parameter combinations between the Link Managers during eSCO setup.

Using eSCO in Profiles Whitepaper.doc 12 September 2003 5 Copyright Bluetooth SIG 2003

Bluetooth SIG Confidential

Page 6 of 8

2.3 Air Mode Negotiation

The air mode is part of the voice_settings parameter. The air mode is not negotiated in eSCO at the LMP level. The reason for this is the same as for bandwidth negotiation; it is not possible for LMP to make intelligent decisions, as LMP doesnt know the data content. Therefore, the air mode needs to be negotiated prior to initiating eSCO via HCI. In BT1.1 SCO the air mode is negotiated by LMP. This was possible because SCO only supported 64kbps audio and all three of the possible air coding formats (CVSD, A-law and u-law) achieved a similar result. The negotiation in BT1.1 is simply that the initiating side chooses an air mode and the other side uses it. Since A-law and u-law are generally not used with SCO (they do not handle bit errors well and degrade rapidly with any interference or at longer ranges) negotiating air modes with SCO has been largely ignored. In addition to the three air modes supported by SCO, eSCO added transparent data. While it might be possible to let LMP decide whether to switch between CVSD, A-law and u-law, it is not possible to make a choice between transparent data and any of the other three coding formats. For this reason, air mode is not negotiable by LMP and must be negotiated by the profile prior to initiating the eSCO link via HCI. If the two devices do not agree on air mode the eSCO link setup will fail at the LMP layer with an LMP_not_accepted_ext PDU. Profiles that have the possibility of supporting multiple air modes need to consider how to handle changing the air mode during the connection. When A-law or u-law are being used in order to gain the better audio quality from PCM coding and the radio channel degrades, it would probably be best to change to CVSD. This aspect of eSCO would require some type of protocol at the profile layer to make the switch on both sides.

2.4 Retransmission Effort

eSCO was designed so that the profile (or application) could make intelligent tradeoffs between performance and current consumption. The retransmission_effort parameter may be set to one of four values by the Host: 0x00: no retransmissions 0x01: at least one retransmission (optimize for power) 0x02: at least one retransmission (optimize for quality) 0xFF: dont care Both the initiating and non-initiating hosts have the same four options. The Profile is recommended to set the Re-transmission effort according to the required quality and make the trade-off between power consumption and quality. Only when the Profile does not have any specific requirements on the eSCO quality, the Re-transmission effort 'don't care' is recommended. When one side selects a Re-transmission effort of at least one re-transmission (0x01 or 0x02) then the other side shall not select zero re-transmissions (0x00). These parameter settings are incompatible, and will result in a failure of the underlying eSCO link setup. When both sides decide to use a 'don't care', then the resulting eSCO link quality will be dependent on the choice made by the LM implementation. It should be pointed out that when a Re-transmission effort of at least one re-transmission is selected (0x01 or 0x02), the eSCO link setup may fail, as there many not be sufficient resources available to guarantee at least one re-transmission opportunity. The Profiles are recommended to consider scenarios were an asymmetric Re-transmission effort is selected. For example, a cell phone might always set retransmission_effort to at least one retransmission (optimize for quality) and the headset might always select no retransmissions. The asymmetry of quality may not be acceptable to the customer. Using eSCO in Profiles Whitepaper.doc 12 September 2003 6 Copyright Bluetooth SIG 2003

Bluetooth SIG Confidential

Page 7 of 8

If, however, the profile is using transparent data, it should be more explicit about the retransmission_effort setting as this may greatly affect the quality of the synchronous data.

2.5 Packet Types

All Controllers that support eSCO have to support the EV3 packet type. This ensures that the Controllers will have at least one packet type in common. However, it is possible for a Host to set the packet_type mask such that the mandatory packet type is not selected. When this happens there is a possibility that the Link Manager cannot negotiate an eSCO connection. Therefore, a profile should ensure that there is at least one common eSCO packet type. The benefits of using longer packet types (EV4 or EV5) is twofold. First, longer packet types can free up more slots in between the eSCO reserved slots. Second, long packet types can reduce the current consumption required for the eSCO connection. In both cases, the benefit is that more bandwidth is freed up for other uses (either simultaneous ACL connections or additional eSCO logical transports). The downside is that longer packet types will have a longer latency. Depending on the system this may be problematic. Profiles that will be used in a multi-profile scenario should be encouraged to use the longer packet types with longer latencies, so that the performance of the other profiles could be improved due to the better scheduling flexibility with longer packets.

Using eSCO in Profiles Whitepaper.doc 12 September 2003 7 Copyright Bluetooth SIG 2003

Bluetooth SIG Confidential

Page 8 of 8

Conclusions and Recommendations

eSCO is a powerful new feature in the Bluetooth 1.2 Core Specification. It is also a feature that, unless constrained, can create long LMP negotiation sequences and possibly interoperability problems. For the most part, these interoperability problems can be mitigated by some simple recommendations in the profiles. If the profile working groups (and profile enhancement groups) do not include recommendations when updating profiles for eSCO there will be a significant delay in getting interoperable products to market and the advantages of eSCO will be tainted. Given the timeframe for updating profiles, it is recommended that profile groups wishing to update their profile to eSCO use a two-phased approach. The first phase adds in a very limited/restricted usage of eSCO. The second phase allows for a more complex approach. For the purposes of describing these phases, the hands free and headset profiles are used: Phase 1: Require that the HCI parameters are set as follows: Transmit_bandwidth = 8000 (64kbps) Receive_bandwidth = 8000 (64kbps) Max_latency >= 7ms Air mode (in voice_settings) = CVSD Retransmission_effort = 0x01 (At least one retransmission, optimize for power consumption) Packet_types = at least EV3 It is important to remember that with these basic parameter settings the profiles will not be benefiting from the full capabilities of eSCO. For example, restricting the air mode to CVSD will reduce the audio quality when compared with either A-law or u-law, under most cases. If Max_latency is set small then retransmissions will be limited. By using small Max_latency and not allowing 3 slot packets, the capacity available for simultaneous data connections in the same piconet will be limited. Phase 2: In this phase, add protocol support on the profile level to exchange capabilities and to negotiate the following parameters: Transmit_bandwidth, Receive_bandwidth, Air mode, Retransmission_effort and Packet_types. Max latency can probably be handled the same way as phase I.

Using eSCO in Profiles Whitepaper.doc 12 September 2003 8 Copyright Bluetooth SIG 2003