Professional Documents
Culture Documents
Confidential
Page 1 of 8
Bluetooth SIG
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
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
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
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
Page 5 of 8
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.
Using eSCO in Profiles Whitepaper.doc 12 September 2003 5 Copyright Bluetooth SIG 2003
Page 6 of 8
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.
Using eSCO in Profiles Whitepaper.doc 12 September 2003 7 Copyright Bluetooth SIG 2003
Page 8 of 8
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