BLUETOOTH DOC
`
`Prepared
`Bluetooth Audio Video
`Working Group
`
`Date / Year-Month-Day
`2003-05-22
`e-mail address
`avv-feedback@bluetooth.org
`
`Approved
`Version
`
`Revision
`1.0
`
`Document No
`
`
`
`N.B.
`
`
`AUDIO/VIDEO REMOTE CONTROL PROFILE
`
`Version 1.0 Adopted
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Abstract
`
`This profile defines the requirements for Bluetooth™
`devices necessary for the support of the Audio/Video
`
`1
`
`APPLE 1034
`
`

`

`
`
`
`
`BLUETOOTH SPECIFICATION
`
`Audio Video Remote Control Profile
`
`Page 2 of 52
`
`
`
`Remote Control usage case. The requirements are
`expressed in terms of end-user services, and by defining
`the features and procedures that are required for
`interoperability between Bluetooth devices in the
`Audio/Video Remote Control usage case.
`
`Release Date: 22 May 2003
`
`
`
`2
`
`

`

`BLUETOOTH SPECIFICATION
`
`Audio/Video Remote Control Profile
`
`Page 3 of 52
`
`
`
`Revision History
`
`Revision
`
`Date
`
`Comments
`
`Release to Associates
`April 2001
`0.5
`Release to Associates
`June, 2001
`0.7
`Release to Associates and Early Adopters
`September, 2001
`0.9
`Release to Associates and Early Adopters
`October, 2001
`Voting Draft 0.95
`Voting Draft 0.95 a February 11, 2002 Release to Associates and Early Adopters, small clarifications
`based on IOP and feedback.
`Adopted 0.95
`Release for Voting Draft
`Release for Voting Draft
`Title and header changed
`
`March 2002
`0.95b
`May 2002
`Voting Draft 1.00
`Voting Draft 1.00 a February 2003
`Version 1.0
`May 2003
`
`Release Date: 5th of Feb 2003
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`3
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`BLUETOOTH SPECIFICATION
`
`Audio/Video Remote Control Profile
`
`Page 4 of 52
`
`
`
`Contributors
`
`Morgan Lindqvist
`
`Tsuyoshi Okada
`
`Jurgen Schnitzler
`
`Kalervo Kontola
`
`Vesa Lunden
`
`Shaun Barrett
`
`Christian Bouffioux
`
`Geert Knapen
`
`Emmanuel Mellery
`
`Masakazu Hattori
`
`Harumi Kawamura (Owner)
`
`Rudiger Mosig
`
`Yoshiyuki Nezu
`
`Hiroyasu Noguchi
`
`Tomoko Tanaka
`
`Junko Ami
`
`Yoshiaki Takabatake
`
`Ichiro Tomoda
`
`Ericsson
`
`Matsushita
`
`Nokia
`
`Nokia
`
`Nokia
`
`Philips
`
`Philips
`
`Philips
`
`Philips
`
`Sony
`
`Sony
`
`Sony
`
`Sony
`
`Sony
`
`Sony
`
`Toshiba
`
`Toshiba
`
`Toshiba
`
`Release Date: 22 May 2003
`
`
`
`4
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`BLUETOOTH SPECIFICATION
`
`Audio/Video Remote Control Profile
`
`Disclaimer and Copyright Notice
`
`Page 5 of 52
`
`
`
`The copyright in these specifications is owned by the Promoter Members of Bluetooth
`SIG, Inc. (“Bluetooth SIG”). Use of these specifications and any related intellectual
`property (collectively, the “Specification”), is governed by the Promoters Membership
`Agreement among the Promoter Members and Bluetooth SIG (the “Promoters
`Agreement”), certain membership agreements between Bluetooth SIG and its Adopter
`and Associate Members (the Membership Agreements”) and the Bluetooth
`Specification Early Adopters Agreements (“1.2 Early Adopters Agreements”) among
`Early Adopter members of the unincorporated Bluetooth special interest group and the
`Promoter Members (the “Early Adopters Agreement”). Certain rights and obligations of
`the Promoter Members under the Early Adopters Agreements have been assigned to
`Bluetooth SIG by the Promoter Members.
`
`Use of the Specification by anyone who is not a member of Bluetooth SIG or a party to an Early
`Adopters Agreement (each such person or party, a “Member”), is prohibited. The legal rights and
`obligations of each Member are governed by their applicable Membership Agreement, Early Adopters
`Agreement or Promoters Agreement. No license, express or implied, by estoppel or otherwise, to any
`intellectual property rights are granted herein.
`
`Any use of the Specification not in compliance with the terms of the applicable Membership Agreement,
`Early Adopters Agreement or Promoters Agreement is prohibited and any such prohibited use may result
`in termination of the applicable Membership Agreement or Early Adopters Agreement and other liability
`permitted by the applicable agreement or by applicable law to Bluetooth SIG or any of its members for
`patent, copyright and/or trademark infringement.
`
`THE SPECIFICATION IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING
`ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR
`PURPOSE, SATISFACTORY QUALITY, OR REASONABLE SKILL OR CARE, OR ANY WARRANTY
`ARISING OUT OF ANY COURSE OF DEALING, USAGE, TRADE PRACTICE, PROPOSAL,
`SPECIFICATION OR SAMPLE.
`
`technology
`the Bluetooth™
`that products equipped with
`Each Member hereby acknowledges
`(“Bluetooth™ Products”) may be subject to various regulatory controls under the laws and regulations of
`various governments worldwide. Such laws and regulatory controls may govern, among other things, the
`combi-nation, operation, use, implementation and distribution of Bluetooth™ Products. Examples of such
`laws and
`regulatory controls
`include, but are not
`limited
`to, airline
`regulatory controls,
`telecommunications regulations, technology transfer controls and health and safety regulations. Each
`Member is solely responsible for the compliance by their Bluetooth™ Products with any such laws and
`regulations and for obtaining any and all required authorizations, permits, or licenses for their
`Bluetooth™ Products related to such regulations within the applicable jurisdictions. Each Member
`acknowledges that nothing in the Specification provides any information or assistance in connection with
`securing such compliance, authorizations or licenses. NOTHING IN THE SPECIFICATION CREATES
`ANY WARRANTIES, EITHER EXPRESS OR
`IMPLIED, REGARDING SUCH LAWS OR
`REGULATIONS.
`
`ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY INTELLECTUAL PROPERTY
`RIGHTS OR FOR NONCOMPLIANCE WITH LAWS, RELATING TO USE OF THE SPECIFICATION IS
`EXPRESSLY DISCLAIMED. BY USE OF THE SPECIFICATION, EACH MEMBER EXPRESSLY
`WAIVES ANY CLAIM AGAINST BLUETOOTH SIG AND ITS PROMOTER MEMBERS RELATED TO
`USE OF THE SPECIFICATION.
`
`Bluetooth SIG reserves the right to adopt any changes or alterations to the Specification as it deems
`necessary or appropriate and to adopt a process for adding new Bluetooth™ profiles after the release of
`the Specification.
`
`Copyright © 2003, Bluetooth SIG Inc
`
`Release Date: 22 May 2003
`
`5
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`BLUETOOTH SPECIFICATION
`
`Audio/Video Remote Control Profile
`
`Document Terminology
`
`Page 6 of 52
`
`
`
`The Bluetooth SIG has adopted Section 13.1 of the IEEE Standards Style Manual,
`which dictates use of the words ``shall’’, ``should’’, ``may’’, and ``can’’ in the
`development of documentation, as follows:
`
` The word shall is used to indicate mandatory requirements strictly to be followed in
`order to conform to the standard and from which no deviation is permitted (shall
`equals is required to).
`
` The use of the word must is deprecated and shall not be used when stating
`mandatory requirements; must is used only to describe unavoidable situations.
`
` The use of the word will is deprecated and shall not be used when stating
`mandatory requirements; will is only used in statements of fact.
`
` The word should is used to indicate that among several possibilities one is
`recommended as particularly suitable, without mentioning or excluding others; or
`that a certain course of action is preferred but not necessarily required; or that (in
`the negative form) a certain course of action is deprecated but not prohibited
`(should equals is recommended that).
`
` The word may is used to indicate a course of action permissible within the limits of
`the standard (may equals is permitted).
`
` The word can is used for statements of possibility and capability, whether material,
`physical, or causal (can equals is able to).
`
`Release Date: 22 May 2003
`
`
`
`6
`
`

`

`BLUETOOTH SPECIFICATION
`
`Audio/Video Remote Control Profile
`
`Contents
`
`
`
`
`
`
`
`
`
`
`
`Page 7 of 52
`
`
`
`
`
`1
`
`2
`
`3
`
`4
`
`Introduction ........................................................................................ 10
`1.1 Scope ........................................................................................ 10
`1.2 Profile Dependencies ................................................................ 10
`1.3 Symbols and Conventions ......................................................... 11
`1.3.1 Requirement Status Symbols ....................................... 11
`
`1.3.2 Definition ....................................................................... 12
`
`1.3.3 Conventions .................................................................. 12
`
`1.3.4 Notation for Timers ....................................................... 14
`
`Profile Overview ................................................................................ 15
`2.1 Profile Stack .............................................................................. 15
`2.2 Configuration and Roles ............................................................ 15
`2.3 User Requirements .................................................................... 16
`2.3.1 Scenarios ...................................................................... 16
`
`2.3.2 User Expectations ......................................................... 18
`
`2.4 Profile Fundamentals ................................................................. 19
`2.5 Conformance ............................................................................. 20
`
`Application Layer ............................................................................... 21
`3.1 Feature Support ......................................................................... 21
`3.2 Feature Mapping ....................................................................... 21
`
`Control Interoperability Requirements ............................................ 22
`4.1 Procedure .................................................................................. 22
`4.1.1 Connection for Control .................................................. 22
`
`4.1.2 Release Connection for Control .................................... 23
`
`4.1.3 Procedure of AV/C Command ....................................... 23
`
`4.1.4 AV/C Command Operation ........................................... 24
`
`4.2 AVCTP Interoperability Requirements ....................................... 25
`4.2.1 Transaction Labels ....................................................... 25
`
`4.2.2 Message Fragmentation ............................................... 26
`
`4.2.3 Profile Identifier of AVCTP Message Information .......... 26
`
`4.3 AV/C Command and Response ................................................. 26
`4.3.1 AV/C Transaction Rules ................................................ 26
`
`4.3.2 AV/C Command Frame................................................. 27
`
`4.3.3 AV/C Response Frame ................................................. 27
`
`4.3.4 AV/C Frame Fields ........................................................ 28
`
`4.4 Supported Unit Commands ....................................................... 28
`4.4.1 UNIT INFO Command .................................................. 28
`
`4.4.2 SUBUNIT INFO Command ........................................... 29
`
`Release Date: 22 May 2003
`
`
`
`7
`
`

`

`
`
`BLUETOOTH SPECIFICATION
`
`Audio/Video Remote Control Profile
`
`Page 8 of 52
`
`4.5 Supported Common Unit and Subunit Commands .................... 29
`4.5.1 VENDOR DEPENDENT Command .............................. 29
`
`4.6 Supported Subunit Command ................................................... 29
`4.6.1 PASS THROUGH Command ........................................ 30
`
`4.7 Categories ........................................................................................ 30
`4.7.1 Category 1: Player/Recorder ......................................... 30
`
`4.7.2 Category 2: Monitor/Amplifier ........................................ 30
`
`4.7.3 Category 3: Tuner ......................................................... 30
`
`4.7.4 Category 4: Menu ......................................................... 30
`
`4.7.5 Support Level in TG ...................................................... 30
`
`4.7.6 Support Level in CT ...................................................... 32
`
`Service Discovery Interoperability Requirements ........................... 34
`
`L2CAP Interoperability Requirements ............................................. 36
`6.1 Channel Types .......................................................................... 36
`6.2 Signalling .......................................................................................... 36
`6.3 Configuration Options ................................................................ 36
`6.3.1 Maximum Transmission Unit ......................................... 36
`
`6.3.2 Flush Timeout ............................................................... 36
`
`6.3.3 Quality of Service .......................................................... 37
`
`Link Manager (LM) Interoperability Requirements .......................... 38
`
`Link Controller (LC) Interoperability Requirements ........................ 39
`8.1 Class of Device .......................................................................... 39
`
`Generic Access Profile Requirements. ............................................ 40
`9.1 Modes ....................................................................................... 40
`9.2 Security Aspects ........................................................................ 40
`9.3
`Idle Mode Procedures ............................................................... 40
`
`Timers and Counters. ........................................................................ 41
`
`Testing ....................................................................................................... 42
`
`References ......................................................................................... 43
`
`List of Figures .................................................................................... 44
`
`List of Tables...................................................................................... 45
`
`Appendix A (Informative): Example of Latency ............................... 46
`
`Appendix B (Informative): Example of A/V Devices ........................ 47
`
`Appendix C (Informative): Multiple applications use of AVCTP ..... 48
`
`Appendix D (Informative): Example of AV/C Commands and Responses
`............................................................................................................ 49
`18.1 UNIT INFO command ................................................................ 49
`18.2 SUBUNIT INFO command ......................................................... 50
`18.3 PASS THROUGH command ..................................................... 51
`
`5
`
`6
`
`7
`
`8
`
`9
`
`10
`
`11
`
`12
`
`13
`
`14
`
`15
`
`16
`
`17
`
`18
`
`Release Date: 22 May 2003
`
`
`
`8
`
`

`

`
`
`
`
`
`BLUETOOTH SPECIFICATION
`
`Audio/Video Remote Control Profile
`
`Page 9 of 52
`
`19
`
`Appendix E: Acronyms and Abbreviations ...................................... 52
`
`Release Date: 22 May 2003
`
`
`
`9
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`BLUETOOTH SPECIFICATION
`
`Audio/Video Remote Control Profile
`
`1
`
`Introduction
`
`1.1 Scope
`
`Page 10 of 52
`
`
`
`The Audio/Video Remote Control Profile (AVRCP) defines the features and procedures
`required in order to ensure interoperability between Bluetooth devices with audio/video
`control functions in the Audio/Video distribution scenarios. This profile specifies the
`scope of the AV/C Digital Interface Command Set (AV/C command set, defined by the
`1394 Trade Association) to be applied, and it realizes simple implementation and easy
`operability. This profile adopts the AV/C device model and command format for control
`messages, and those messages are transported by the Audio/Video Control Transport
`Protocol (AVCTP).
`
`In this profile, the controller translates the detected user action to the A/V control signal,
`and then transmits it to a remote Bluetooth device. The functions available for a
`conventional infrared remote controller can be realized in this profile. The remote
`control described in this profile is designed specific to A/V control. Other remote control
`solutions using Bluetooth wireless technology may be applied for general Bluetooth
`devices including A/V devices.
`
`Note that the Audio/Video Remote Control Profile does not handle the audio/video
`streaming. Devices that support this profile may support audio/video streaming by also
`implementing the Advanced Audio Distribution Profile and/or Video Distribution Profile.
`
`Editors’ Note: The A/V WG has requested additional QoS support in the next revision
`of the Bluetooth data link specification. When other profiles with stringent requirements
`are used in conjunction with this profile the performance may be degraded due to
`insufficient support of QoS in the current Bluetooth specification (v1.1), which all
`profiles use.
`
`1.2 Profile Dependencies
`
`In Figure 1.1, the structure and dependencies of the Audio/Video Remote Control
`Profile are depicted. A profile is dependent upon another profile if it re-uses parts of
`that profile, by implicitly or explicitly referencing it.
`
`As indicated in the figure, the Audio/Video Remote Control Profile is dependent upon
`the Generic Access Profile. The details regarding the profile are provided in Section 9,
`Generic Access Profile Requirements.
`
`Release Date: 22 May 2003
`
`
`
`10
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`BLUETOOTH SPECIFICATION
`
`Audio/Video Remote Control Profile
`
`Page 11 of 52
`
`
`
`Generic Access Profile
`
`Generic Audio/Video Distribution Profile
`
`Advanced Audio Distribution Profile
`
`Video Distribution Profile*
`
`Audio/Video Remote Control Profile
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`* Still under development when AVRCP version 1.0 is published.
`
`
`
`Figure 1.1: Audio/Video Remote Control Profile Dependency
`
`1.3 Symbols and Conventions
`
`1.3.1Requirement Status Symbols
`
`In this document, the following symbols are used:
`
`‘M’ for mandatory to support (used for capabilities that shall be used in the profile).
`
`‘O’ for optional to support (used for capabilities that may be used in the profile).
`
`‘X’ for excluded (used for capabilities that may be supported by the unit but that shall
`never be used in the profile).
`
`‘C’ for conditional to support (used for capabilities that shall be used in case a certain
`other capability is supported).
`
`‘N/A’ for not applicable (in the given context it is impossible to use this capability).
`
`Some excluded capabilities are the ones that, according to the relevant Bluetooth
`specification, are mandatory. These are features that may degrade the operation of
`devices following this profile. Even if such features exist, which can occur when the
`device supports different profiles, they should never be activated while the device is
`operating within this profile.
`
`Release Date: 22 May 2003
`
`
`
`11
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`BLUETOOTH SPECIFICATION
`
`Audio/Video Remote Control Profile
`
`1.3.2Definition
`
`1.3.2.1 RFA
`
`Page 12 of 52
`
`
`
`Reserved for Future Additions. Bits with this designation shall be set to zero. Receivers
`shall ignore these bits.
`
`1.3.2.2 RFD
`
`Reserved for Future Definition. These bit value combinations or bit values are not
`allowed in the current specification but may be used in future versions. The receiver
`shall check that unsupported bit value combination is not used.
`
`1.3.3Conventions
`
`In this profile, protocol signals are exchanged by initiating procedures in
`communicating devices and by exchanging messages. Signalling diagrams use the
`conventions of Figure 1.2: Signalling Conventions. Both A and B represent devices
`playing specific roles, as defined in Section 2.2, Configuration and Roles. Specific
`arrow styles are used in the diagrams to indicate the relevant procedures initiated by
`the participant devices and the exchanged messages.
`
`Release Date: 22 May 2003
`
`
`
`12
`
`

`

`
`
`
`
`
`
`
`
`
`BLUETOOTH SPECIFICATION
`
`Audio/Video Remote Control Profile
`
`Page 13 of 52
`
`
`
`A
`
`B
`
`Mandatory Signal Sent by A
`
`Optional Signal Sent by B
`
`Mandatory Procedure initiated by B
`
`Optional Procedure initiated by A
`
`Mandatory Procedure initiated by either A or B
`
`Optional Procedure initiated by either A or B
`
`Figure 1.2: Signalling Conventions
`
`
`
`Release Date: 22 May 2003
`
`
`
`13
`
`

`

`
`
`
`
`
`
`
`
`
`
`BLUETOOTH SPECIFICATION
`
`Audio/Video Remote Control Profile
`
`1.3.4 Notation for Timers
`
`Page 14 of 52
`
`
`
`Timer is introduced, specific to this profile. To distinguish them from timers used in the
`Bluetooth protocol specifications and other profiles, these timers are named in the
`following format:
`
`
`
`“TRCP(nnn)” for timers
`
`Release Date: 22 May 2003
`
`
`
`14
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`BLUETOOTH SPECIFICATION
`
`Audio/Video Remote Control Profile
`
`2 Profile Overview
`
`2.1 Profile Stack
`
`Page 15 of 52
`
`
`
`
`
`Application
`(Controller)
`
`AV Control
`
`AVCTP
`
`SDP
`
`LMP
`
`L2CAP
`
`Baseband
`
`Controller Side
`
`
`
`
`
`
`
`Application
`(Target)
`
`AV Control
`
`AVCTP
`
`SDP
`
`LMP
`
`L2CAP
`
`Baseband
`
`Target Side
`
`
`
`
`
`
`
`Figure 2.1: Protocol Model
`
`The Baseband, LMP, and L2CAP are the OSI layer 1 and 2 Bluetooth protocols.
`AVCTP defines the procedures and messages to be exchanged for controlling A/V
`devices. SDP is the Bluetooth Service Discovery Protocol[10]. AV control is the entity
`responsible for A/V device control signalling; this signalling is AV/C command-based.
`
`2.2 Configuration and Roles
`
`For the configuration examples for this profile, refer to the figures shown in Section 2.3.
`
`The following roles are defined for devices that comply with this profile:
`
` The controller (CT) is a device that initiates a transaction by sending a command
`frame to a target. Examples for CT are a personal computer, a PDA, a mobile
`phone, a remote controller or an AV device (such as headphone, player/recorder,
`timer, tuner, monitor etc.).
`
` The target (TG) is a device that receives a command frame and accordingly
`generates a response frame. Examples for TG are an audio player/recorder, a
`video player/recorder, a TV, a tuner, an amplifier or a headphone.
`
`Release Date: 22 May 2003
`
`
`
`15
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`BLUETOOTH SPECIFICATION
`
`Audio/Video Remote Control Profile
`
`Page 16 of 52
`
`
`
`command
`
`PC as a CT
`
`
`
`
`
`VCR as a TG
`
`Figure 2.2: Controller and target
`
`2.3 User Requirements
`
`2.3.1Scenarios
`
`User requirements and scenarios for the configuration examples are described in this
`section.
`
`The usage model of AVRCP is specific in a way that user action manipulates the
`control, but there is no limitation to perform the features in audio/video devices. AVRCP
`is capable to manipulate the menu function that is already commonly used for analogue
`devices for various features such as adjustment of TV brightness or hue, or VCR timer.
`With this menu function, AVRCP is designed so that any type features can be
`supported.
`
`A user can learn the status information of a device using display on the body such as
`LED or LCD, as well as OSD (On Screen Display) method. Although a controller can
`not directly gain the status information from a target through AVCTP transaction, the
`similar information can be given to a user in various ways as feedback.
`
`2.3.1.1 Remote Control from Separate Controller
`
`In the configuration shown in Figure 2.3 below, the remote controller is the CT of the
`transaction. Command frames from the remote controller are sent to the portable disc
`player as a TG. An audio stream is sent from the portable disc player to the
`headphone. The headphone simply receives the audio stream and is not involved in
`the transaction between the remote controller and the portable disc player. A trigger of
`the transaction is made by a user from the remote controller, when he/she wishes to
`control the portable disc player.
`
`Release Date: 22 May 2003
`
`
`
`16
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`BLUETOOTH SPECIFICATION
`
`Audio/Video Remote Control Profile
`
`Page 17 of 52
`
`
`
`Headphone
`
`audio
`stream*
`
`Portable Disc Player
`
`
`
`
`Remote Controller
`
`* The audio stream is not handled in this profile.
`
`Figure 2.3: Remote Control from Separate Controller
`
`2.3.1.2 Remote Control and Audio Stream Between Two Devices
`
`In the configuration shown in Figure 2.4 below, the CT is the headphone and the
`portable disc player is the TG.
`
`A trigger of the transaction is made by a user from the remote controller that
`accompanies the headphone, when he/she wishes to control the portable disc player.
`
`audio stream*
`
`command
`
`Portable Disc Player
`
`Headphone with
`Remote Controller
`
`* The audio stream is not handled in this profile.
`
`Figure 2.4: Remote Control and Audio Stream Between Two Devices
`
`2.3.1.3 Mutual Remote Control Within a Piconet
`
`In the configuration shown in Figure 2.5 below, both the headphone and the portable
`disc player are capable of working as remote controllers.
`
`For example, the portable disc player becomes a CT if it controls the volume of the
`headphone that becomes a TG. On the other hand, the headphone becomes a CT
`when it sends a command to start playback or stop playing to the portable disc as a
`TG.
`
`Release Date: 22 May 2003
`
`
`
`17
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`BLUETOOTH SPECIFICATION
`
`Audio/Video Remote Control Profile
`
`Page 18 of 52
`
`
`
`audio
`stream*
`
`
`command
`
`
`
`command
`
`Portable Disc Player
`
`Headphone
`
`* The audio stream is not handled in this profile.
`
`Figure 2.5: Mutual Remote Control Within a Piconet
`
`2.3.1.4 Remote Controller with LCD
`
`In the configuration shown in Figure 2.6 below, the remote controller is a CT. It
`receives audio and/or video data by sending commands to control the VCR as a TG.
`The remote controller can have an LCD or an audio speaker(s) to present received
`data to a user.
`
`command
`
`audio/video stream*
`
`Remote controller
`with LCD
`
`VCR
`
`* The audio/video stream is not handled in this profile.
`
`Figure 2.6: Remote Controller with LCD
`
`2.3.2 User Expectations
`
`In this section, user expectations and related restrictions of AVRCP are described.
`
`Although a device may implement only AVRCP as shown in 2.3.1.1, it is assumed that,
`in most cases, an A/V distribution profile co-exists in a device. Items described in this
`section shall be considered according to the condition; whether only AVRCP is
`implemented, or one or more AV distribution profiles co-exist in the device.
`
`2.3.2.1 Configuration
`
`AVRCP is based on the control over point to point connection within a piconet. For this
`profile, it is assumed that the use case is active between the two devices. Note that
`one or more CTs may exist within a piconet. (Refer 2.3.1.3)
`
`A controller may support several targets, and the detail of control such as target
`selection is not defined in AVRCP.
`
`Release Date: 22 May 2003
`
`18
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`BLUETOOTH SPECIFICATION
`
`Audio/Video Remote Control Profile
`
`2.3.2.2 Limited Latency
`
`Page 19 of 52
`
`
`
`The responsiveness of remote control operations is an important feature of AVRCP. It
`is expected that the system reacts in a timely manner in order to avoid uncontrollable
`situations like system overload by repeated commands.
`
`Latency figures depend on application. Additional information on the desired delay is
`provided in 15 Appendix A (Informative): Example of Latency.
`
`CT and TG interoperate through L2CAP channel connections. In case the TG is a
`master, it is required to poll the slaves on a regular basis in order to satisfy the
`application QoS requirements. It is recommended that the polling rate is approximately
`10 Hz.
`
`2.3.2.3 Power Management
`
`The discussions below are intended to be for application information only: there are no
`mandatory usages of the low power modes for AVRCP.
`
`It is assumed that battery powered devices are common in the usage model of AVRCP,
`in case that CT is a handheld device. The device is recommended to ensure
`comparable service grade to the existing infrared product range.
`
`Duplex radio systems suffer from higher power consumption compared to the simple
`infrared transmission controller. To compensate this fundamental drawback, dynamic
`use of low power modes is recommended especially when only AVRCP is implemented
`in a device.
`
`Regarding the details of the low power modes (PARK, SNIFF, HOLD), refer to the
`Specification of the Bluetooth System, Core, Baseband[7] and Link Manager
`Protocol[9]. Appropriate low power mode strategy partly depends on applications.
`
`2.3.2.4 User Action
`
`The user action is required in most cases in AVRCP. Applications shall be designed
`based on this characteristic. It is possible to design simple automatic operation without
`a user action; such as a timer function that sends a command to start recording at pre-
`set time, within this profile.
`
`2.4 Profile Fundamentals
`
`The profile fundamentals, with which all applications shall comply, are the followings.
`
`1. Use of security features in link level such as authorisation, authentication and
`encryption are optional. Support for authentication and encryption is mandatory,
`
`Release Date: 22 May 2003
`
`19
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`BLUETOOTH SPECIFICATION
`
`Audio/Video Remote Control Profile
`
`Page 20 of 52
`
`
`
`such that the device can take part in the corresponding procedures if requested
`from a peer device.
`
`2. A link shall be established before commands can be initiated or received.
`
`3. There are no fixed master/slave roles.
`
`4. In this profile, the A/V functions are classified into four categories defined in Section
`4.7. All devices that conform to this profile shall support at least one category, and
`may support several categories.
`
`2.5 Conformance
`
`When conformance to this profile is claimed, all capabilities indicated mandatory for
`this profile shall be supported in the specified manner (process mandatory). This also
`applies to optional and conditional capabilities, for which support is indicated, and
`subject to verification as part of the Bluetooth certification program.
`
`Release Date: 22 May 2003
`
`
`
`20
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`BLUETOOTH SPECIFICATION
`
`Audio/Video Remote Control Profile
`
`3 Application Layer
`
`Page 21 of 52
`
`
`
`
`
`This section describes the feature requirements on units complying with the
`Audio/Video Remote Control Profile.
`
`3.1 Feature Support
`
`The table below shows the features requirements for this profile. Note that a device
`may have both CT and TG capabilities. In that case, features for both CT and TG are
`required.
`
`
`
`Feature
`
`Support in
`CT
`
`Support in
`TG
`
`1.
`2.
`3.
`4.
`5.
`6.
`7.
`8.
`9.
`10.
`
`Connection establishment for control
`Release connection for control
`Sending UNIT INFO command
`Receiving UNIT INFO command
`Sending SUBUNIT INFO command
`Receiving SUBUNIT INFO command
`Sending VENDOR DEPENDENT command
`Receiving VENDOR DEPENDENT command
`Sending PASS THROUGH command
`Receiving PASS THROUGH command
`
`M
`M
`O
`X
`O
`X
`O
`X
`M
`X
`
`O
`M
`X
`M
`X
`M
`X
`O
`X
`M
`
`Table 3.1: Application Layer Features
`
`3.2 Feature Mapping
`
`The table below maps each feature to the procedures used for that feature. All
`procedures are mandatory if the feature is supported.
`
`
`
`Feature
`
`Procedure
`
`Connection for control
`Release connection for control
`Procedure of AV/C command
`Procedure of AV/C command
`Procedure of AV/C command
`Procedure of AV/C command
`Procedure of AV/C command
`
`Ref.
`
`4.1.1
`4.1.2
`4.1.3
`4.1.3
`4.1.3
`4.1.3
`4.1.3
`
`1.
`2.
`3.
`4.
`5.
`6.
`7.
`
`8.
`
`9.
`10.
`
`Connection establishment
`Connection release
`Sending UNIT INFO command
`Receiving UNIT INFO command
`Sending SUBUNIT INFO command
`Receiving SUBUNIT INFO command
`Sending VENDOR DEPENDENT
`command
`Receiving VENDOR DEPENDENT
`command
`Sending PASS THROUGH command
`Receiving PASS THROUGH command
`
`Procedure of AV/C command
`
`4.1.3
`
`Procedure of AV/C command
`Procedure of AV/C command
`
`4.1.3
`4.1.3
`
`Table 3.2: Application Layer Feature to Procedure Mapping
`
`Release Date: 22 May 2003
`
`
`
`21
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`BLUETOOTH SPECIFICATION
`
`Audio/Video Remote Control Profile
`
`4 Control Interoperability Requirements
`
`Page 22 of 52
`
`
`
`
`
`The interoperability requirements for an entity that is compatible with the AVRCP are
`completely contained in this chapter. The requirements directly relate to the application
`layer features.
`
`4.1 Procedure
`
`4.1.1 Connection for Control
`