|
|
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.
For more details : Download the AVRCP Profile from the Bluetooth.org
website.
Image reprinted from Bluetooth AVRCP Profile, Figure
2.1
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. AV control is the entity responsible for A/V
device control signalling; this signalling is AV/C command-based.
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.
-
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.
There are 4 scenarios that are covered
in this profile:
-
Remote Control from Separate Controller
-
Remote Control and Audio Stream Between Two Devices
-
Mutual Remote Control Within a Piconet
-
Remote Controller with LCD
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. of the AVRCP Profile (Remote Control
from Separate Controller)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.
-
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. A controller
may support several targets, and the detail of control such as target
selection is not defined in AVRCP.
-
Limited Latency: 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.
-
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.
-
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 preset time, within this profile.
The profile fundamentals, with which
all applications shall comply, are the followings.
-
Use of security features in link level such as
authorisation, authentication and encryption are optional. Support for
authentication and encryption is mandatory, such
that the device can take part in the corresponding procedures if
requested from a peer device.
-
A link shall be established before commands can be
initiated or received.
-
There are no fixed master/slave roles.
-
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.
If 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 all
optional and conditional capabilities for which support is indicated.
Section 3 of the AVRCP describes the feature
requirements on units complying with the Audio/Video Remote Control
Profile. Table 3.1 of the AVRCP Profile 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. Table 3.2 of the
AVRCP Profile below maps each feature to the procedures used for that
feature. All procedures are mandatory if the feature is supported.
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.
Connection for Control
-
An L2CAP connection establishment for AVCTP may be
initiated by the CT or by the TG. An internal event
or an event generated by a user, such as turning the power on,
initiates the connection establishment. Note: Only one L2CAP
connection shall be established between AVCTP entities. If the
connection already exists, the CT/TG shall not initiate the connection
request.
Release Connection for Control
-
Release of an L2CAP connection for AVCTP may be
initiated by the CT or by the TG. An internal event or an event
generated by a user, such as turning the power off, initiates the
connection release.
Procedure of AV/C Command
-
Upon an internal or an event generated by a user,
the CT shall initiate connection establishment if a connection has
not been established by then. Once the connection is established, it
is able to send a AV/C command.
Image reprinted from Bluetooth AVRCP Profile,
Figure 4.4
AV/C Command Operation
-
This section describes the operation procedure of
AV/C command exchange shown in the figure above.
-
The AV/C General Specification covers the AV/C
general command and response model, unit/subunit model, and standard
unit and subunit commands. An AV/C subunit is an instantiation of a
logical entity that is identified within an AV/C unit. An AV/C
subunit has a set of coherent functions that the electronic device
provides. Functions are defined for each category of devices in its
subunit specification. (Monitor, Audio, Tape recorder/player, Disc,
Tuner, etc.).
-
The AV/C command set consists of the AV/C General
Specification and each subunit command. In the AV/C General
Specification, the UNIT INFO command and SUBUNIT INFO command are
both mandatory. For subunit commands, the mandatory commands are
defined in each subunit specification, and it depends on the device
implementation which subunit to support.
-
The main feature of this profile is the remote
control performed by the PASS THROUGH command of the Panel subunit.
The Panel subunit provides a user-centric model for actuating the
controls on a device. The controller controls the Panel subunit
according to the user operation using certain controller-dependent
manners. The user manipulates the user interface on the display or
operates a button, and then the controller sends commands to the
panel subunit. In response to these commands, the Panel subunit
performs some action(s). Even though there may be several subunits
in a TG, the TG shall have only one panel subunit. Unlike many other
AV/C subunits, the panel subunit does not directly deal with media
streams itself. The main purpose for using a panel subunit is to
allow it to translate the incoming user action commands into
internal actions, which affect other subunits and/or the unit, and
dispatch them to an appropriate subunit or unit inside the TG using
the TG-dependent manner. The result of these actions may have an
effect on media streams. This profile uses the PASS THROUGH command,
which is one of the subunit commands defined in the Panel Subunit
Specification. A controller conveys a user operation to a TG by the
PASS THROUGH command.
-
On the CT side, it is
application-dependent how transaction labels are handled, and therefore
it is not defined in this specification. On the TG side, the transaction
label received in an AVCTP command frame shall be used as the
transaction label returned in the possible corresponding AVCTP response
frame. In case several response frames are sent as reaction to one AVCTP
command, all response frames shall use the same value of transaction
label in the received command frame.. See Section 4.2.2 & 4.2.3 in
the AVRCP Profile for more information on Message Fragmentation &
Profile Identifier of AVCTP Message Information respectively.
AV/C command and response frames are
encapsulated within the AVCTP Command/Response Message Information
field,
AV/C Transaction Rules
-
An AV/C transaction consists of one message
containing a command frame addressed to the TG and zero or more
messages containing a response frame returned to the CT by the TG.
The TG is required to generate a response frame as quickly as
possible, within a time period of T RCP (100)
counting from the moment a command frame is received.
-
For some transactions, the TG may not be able to
complete the request or determine whether it is possible to complete
the request within the T RCP (100)
allowed. In this case, the TG shall return an initial response code
in INTERIM with the expectation that the final response follow
later.
AV/C Command Frame
-
An AV/C command frame contains up to 512 bytes of
data, and it is contained in the AVCTP Command/Response Message
Information field. An AV/C command frame has the structure shown
below.
Image reprinted from Bluetooth AVRCP Profile,
Figure 4.5
AV/C Response Frame
-
An AV/C response frame is contained in the AVCTP
Command/Response Message Information field, and it has the structure
shown in the figure below.
AV/C Frame Fields
-
For the fields and code values for AV/C command and
response frames listed below, as well as the definition of reserved
field and reserved value, refer to the AV/C General Specification.
-
Command type codes (ctype)
-
Response codes (response)
-
AV/C address (subunit_type, subunit_ID)
-
Subunit_type and subunit_ID encoding
-
Operation (opcode)
-
Operands
The unit commands shown in the
following table are used in this profile. For unit commands, the AV/C
address field of AV/C command frame shall indicate the value for
unit. See Section 4.4 of the AVRCP Profile for more details.
Image reprinted from Bluetooth AVRCP Profile,
Table 4.3
The common unit and subunit commands
shown in the following table are used in this profile. For the common
unit and subunit command, the AV/C address field of the AV/C
command frame shall indicate the value for unit or Panel Subunit if the
command is one defined in this profile.
Image reprinted from Bluetooth AVRCP Profile,
Table 4.4
The VENDOR DEPENDENT command shall
not be used instead of commands specified in the AVRCP that have the
same functionality.
PASS THROUGH Command
-
The PASS THROUGH command of the Panel subunit is
used in this profile. The operation_id’s to be used in this
profile depend on which A/V function category the device supports.
For the PASS THROUGH command, the AV/C address field of the
AV/C command frame shall indicate the value for Panel Subunit. The
PASS THROUGH command is used to transfer user operation information
from a CT to Panel subunit on TG.
-
This profile ensures the
interoperability by classifying the A/V functions into four categories.
For each category, the mandatory commands for the TG are defined by the operation_ids
in the PASS THROUGH command. It is mandatory for the TG to support at
least one of the categories. The categories are:
See section 4.7 of the AVRCP Profile
for details on each category type
Support Level in TG & CT
-
No mandatory command for the CT is defined by the operation_ids
in the PASS THROUGH command. However, it is mandatory in CT to
support at least one of the operation_ids. The category for
CT indicates that the CT expects to control a TG supporting the
corresponding category. It is mandatory for CT to support at least
one of categories. The table 4.6 & 4.7 in the AVRCP Profile show
the operation_ids and their support level for each category
for the TG and CT respectively.
Table 5.1 & 5.2 in the AVRCP Profile define
the following service records for the CT and the TG
respectively.
In this profile, only connection-oriented channels
shall be used. This implies that broadcasts shall not be used in this
profile. In the PSM field of the Connection Request packet, the value
for AVCTP defined in the Bluetooth Assigned Numbers document shall be
used.
Only the CT may issue an L2CAP
Connection Request within the execution of this profile. Other than
that, AVRCP does not impose any additional restrictions or requirements
on L2CAP signalling.
This section describes the usage of
configuration options in this profile.
- Maximum Transmission Unit (MTU) : The minimum MTU that a
L2CAP implementation for this profile shall support is 48 bytes.
- Flush Timeout : The Application shall set the appropriate
value for responding time to the flush timeout. However, the Flush
timeout can be constrained by the ACL channels when the other
applications (such as audio/video streaming or file sharing) coexist
with AVRCP.
- Quality of Service : Negotiation of Quality of Service is
optional in this profile.
The procedure for SCO links is
excluded. Other than that, there is no change to the requirements as
stated in the Link Manager specification itself.
Table 8.1 in the AVRCP Profile lists
all features at LC level, and the extra requirements are added to the
one in the Baseband specification by this profile.
Section 9 in the AVRCP Profile defines the support
requirements for the capabilities as defined in the Generic Access
Profile.
This shows
- the support status for modes within this profile
- the support status for idle mode procedures within this profile.
There is no change to the Security Aspects
requirements as stated in the Generic Access Profile.
Note , the above text contains excerpts from the
Bluetooth SIG's Specification, as well as various interpretations of the
Specs. For complete details of the various sections, consult the actual
Bluetooth Specification.
|
