MTP Over BT Profile Specification

MTP over Bluetooth Profile
Specification
Abstract
This document specifies the manner in which the Media Transport Protocol (MTP) is
to be transported within the Bluetooth wireless networking environment. This
information enables a Bluetooth aware MTP Initiator and MTP Responder to carry on
a standard MTP conversation over Bluetooth similar to USB and TCP/IP.
This document is preliminary and will be updated prior to the final release of
Windows.
BLUETOOTH SPECIFICATION Page 2 of 40
MTP over Bluetooth
2008 Microsoft Corporation. All rights reserved.

By using or providing feedback on these materials, you agree to the attached
license agreement.
MTP over Bluetooth
Disclaimer: This is a preliminary document and may be changed substantially prior to final commercial release of the software
described herein.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the
date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment
on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR
STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of
this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means
(electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of
Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter
in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document
does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places
and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email
address, logo, person, place or event is intended or should be inferred.
Microsoft, Windows, Windows NT, Windows Server, and Windows Vista are either registered trademarks or trademarks of Microsoft
Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

license agreement.
MTP over Bluetooth
Revision History
Revision Date Comments
0.9 31 March 2008 Initial draft
0.91 27 May 2008 Updated for correct ordering of
PacketType and Sequence ID. Added
TransportID as well. Additional
clarifications around TransportError
handling including the addition of the
TransportReady packet.
0.92 22 October 2008 Added MTU information. Moved L2CAP
Basic Mode operation to its own section
and added more details on how it
operates.

license agreement.
MTP over Bluetooth
Contributors
Name Company
Darren Davis Microsoft Corporation
E-Zu Wu Microsoft Corporation
John Felkins Microsoft Corporation

license agreement.
MTP over Bluetooth
Table of Contents
1 Overview.............................................................................................................. 6
1.1 Scope............................................................................................................. 6
1.2 Key MTP Concepts.......................................................................................... 6
1.3 Conformance with MTP/USB and MTP/IP........................................................7
1.4 RFC 2119 Compliance.................................................................................... 8
2 MTP implementation over Bluetooth....................................................................9
2.1 L2CAP Transport............................................................................................. 9
2.2 Transport Model............................................................................................. 9
2.2.1 Maximum Transmission Unit (MTU) Requirements...................................9
2.2.2 SDP Records.......................................................................................... 10
2.2.3 Role Determination................................................................................ 10
2.2.4 Connections........................................................................................... 10
2.2.5 Security................................................................................................. 11
2.2.6 L2CAP Flow Control and Retransmission Support..................................11
2.3 MTP Bluetooth Service Definitions...............................................................11
2.3.1 MTP Initiator Service Definition Record..................................................12
2.3.2 MTP Responder Service Definition Record.............................................12
2.4 Transport Channel Management..................................................................13
2.4.1 Bluetooth Pairing................................................................................... 13
2.4.2 Initiator Driven Link Establishment........................................................13
2.4.3 Responder Driven Link Establishment...................................................14
2.4.4 Race Conditions in Link Establishment..................................................15
2.4.5 MTP Bluetooth Link Power Management................................................16
2.4.6 Shutdown of MTP Bluetooth Link...........................................................16
2.5 Transfer Packet Types................................................................................... 17
2.5.1 Packet Header and Identifiers................................................................17
2.5.2 Parameter Optimizations.......................................................................18
2.5.3 Link Fail Packet...................................................................................... 19

license agreement.
MTP over Bluetooth
2.6 Length.......................................................................................................... 19
2.7 4................................................................................................................... 19
2.8 UINT32......................................................................................................... 19
2.9 Total size of the packet, in bytes, including the header...............................19
2.9.1 Operation Request Packet......................................................................19
2.9.2 Operation Response Packet...................................................................20
2.9.3 Event Packet.......................................................................................... 21
2.9.4 Start Data Packet...................................................................................21
2.9.5 Cancel Packet........................................................................................ 22
2.9.6 Probe Request Packet............................................................................23
2.9.7 Probe Response Packet..........................................................................23
2.9.8 Init Command Request Packet...............................................................24
2.9.9 Init Event Request Packet......................................................................25
2.9.10 Init Link Acknowledgement Packet........................................................26
2.9.11 End Data Packet.................................................................................... 26
2.9.12 Transport Error Packet............................................................................27
2.9.13 Transport Ready Packet.........................................................................28
2.9.14 Request Link Destroy Packet..................................................................29
2.9.15 Data Packet........................................................................................... 30
2.10 L2CAP Basic Mode Support..........................................................................31
2.10.1 Error Handling........................................................................................ 31
2.10.2 Error Detection Fields............................................................................ 33

license agreement.
MTP over Bluetooth
1 Overview
1.1 Scope
This document assumes familiarity with the MTP specification and is targeted at
Bluetooth wireless device developers who would like to implement Media Transport
Protocol (MTP) - based data exchange. Since MTP is transport agnostic, this
document does not enhance or otherwise add new MTP functionality. It only serves
to formalize how the MTP specification is handled over Bluetooth transport. The
functional components of MTP referenced in this document are specified in the MTP
1.0 specification hosted by the USB Implementers Forum 1.
For optimum reliability, the MTP Profile for Bluetooth is dependent on the presence
of a Bluetooth 1.2 compatible Logical Link Control and Adaptation Protocol (L2CAP)
implementation. Allowance is made for support under Bluetooth 1.1 but the
reliability of such interactions may be limited by the underlying L2CAP limitations.
As such this document describes the issues concerning the reliability and
robustness of the Bluetooth link, the packetization of MTP data over Bluetooth, and
the role of MTP hosts (Initiators) and MTP clients (Responders).
1.2 Key MTP Concepts

While this specification does not replicate the details of the MTP protocol, there are
certain core concepts which are referred to throughout this document. For
convenience, these concepts are defined below:
Concept Definition
Initiator The controlling, or host, device in an MTP protocol
interaction. It is responsible for initiating operations
with the attached client. All behavior during an MTP
interaction is under the control of the Initiator. The role
of Responder //Initiator?// is determined at the point the
MTP protocol interaction is established and cannot
change without the current interaction being
disconnected or an additional interaction being
established.
Responder The answering, or client, device in an MTP protocol
interaction. It is responsible for responding to
operations and requests from the attached host. The
role of Responder is determined at the point the MTP
protocol interaction is established and cannot change
without the current interaction being disconnected or an
1
Media Transfer Protocol 1.0 - http://www.usb.org/developers/devclass_docs/MTP_1.0.zip
license agreement.
MTP over Bluetooth
additional interaction being established.

Command An MTP operation request issued from the Initiator to the
Responder.
Response An MTP operation response issued from the Responder
to the Initiator.
Data Phase An exchange of data between the Initiator and the
Responder. The direction of the data phase is
determined by the command being performed.
Event An MTP status notification issued from the Responder to
the Initiator. Events are by nature out-of-band and may
have no direct correlation with the current command
being performed.
Transaction All MTP operations occur as atomic MTP transactions. In
order of operation, each transaction consists of a
command phase, an optional data phase, and a
response phase. Each transaction must be completed
before the start of next transaction.
Transaction ID A value that increases monotonically starting from
0x00000001 that is associated with each MTP
Transaction. 0x00000000 is reserved and may only be
used with OpenSession or GetDeviceInfo operations.
0xFFFFFFFF is also reserved and must be used whenever
this parameter is not applicable for the packet.
Session The MTP session defines the lifetime of the MTP
interaction and may be used by either the Initiator or
the Responder to optimize interactions with the other
party (for example, the Initiator may perform caching on
behalf of the responder to improve performance). MTP
transactions typically occur within the confines of an
MTP session.
1.3 Conformance with MTP/USB and MTP/IP

MTP is a formalized object exchange protocol intended to be implemented on
multiple different transport layers. Today MTP has been defined to work over USB
and TCP/IP transports. As such, the MTP over Bluetooth specification is intended to
conform to MTP behaviors already defined for these two transports. Throughout this
specification, the term MTP applies to generic operations regardless of the
underlying transport.
MTP places a set of requirements on transport layers to guarantee correct behavior:
1. Disconnection Events: The Bluetooth baseband operation includes a keep-

alive behavior which enables the detection of devices which go out of range.
Unfortunately, the nature of this disconnection event is somewhat lazy. in
other words, the arrival of the disconnect notification may occur significantly
license agreement.
MTP over Bluetooth
later than the actual time the device went out of range. To accommodate a
more active connect/disconnect behavior, MTP Bluetooth implementations
are encouraged to take advantage of Initiator- or Responder-driven
disconnect operations (defined later in this document).
2. Reliable, Error Free Channel: Bluetooth 1.2 and above, optionally support
reliable, error-free channels at the L2CAP layer through optional L2CAP
extensions for flow control and packet retransmission. Additions have been
made at the MTP Bluetooth packet model level to account for the limitations
of pre-Bluetooth 1.2 environments or L2CAP Basic Mode environments
where the optional reliable, error-free channels are not supported. It should
be understood that these additions are intended to meet the spirit, if not the
letter of this MTP-compliance requirement and may not guarantee the best
MTP experience. Where a reliable, error-free channel is available, the MTP
Bluetooth specifies that it must be used.
3. Asynchronous Event Support: The definition of MTP over Bluetooth is a
two-channel model in order to provide asynchronous, out-of-band delivery of
MTP events.
4. Device Discovery and Enumeration: The definition of MTP over Bluetooth
defines standard Session Description Protocol (SDP)-based methods by which
the presence of both an MTP-compliant Bluetooth Initiator and MTP-compliant
Bluetooth Responder may be discovered.
5. Specific Transports: This document defines how MTP interactions are to
occur over Bluetooth wireless links.
1.4 RFC 2119 Compliance

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.

license agreement.
MTP over Bluetooth
2 MTP implementation over Bluetooth

2.1 L2CAP Transport
MTP over Bluetooth operates using the L2CAP Bluetooth transport 2. However,
L2CAP as specified prior to Bluetooth 1.2 does not guarantee reliable, error-free
delivery and therefore fails to meet requirement 2 of the MTP specification. In
addition, the presence of Bluetooth 1.2 or later hardware does not guarantee
support for L2CAP flow control and retransmission as they are optional features.
When enabled, L2CAP flow and error control does meet requirement 2 and
guarantees a reliable, error-free delivery of data. Given that L2CAP flow and error
control are optional, it is still desirable to define a method for MTP to be carried over
Bluetooth connections where this optional functionality is not available. Additions
have been made to the underlying transport operations to ensure detection as
minimum, if not correction, of error conditions within environments that do not
support Bluetooth 1.2 or better flow and error control support for L2CAP. Where
L2CAP flow control and retransmission are available, they MUST be enabled.
2.2 Transport Model

MTP requires two active L2CAP channels in order to meet the asynchronous event
requirement of the MTP transport 3. The first channel starts from the MTP Initiator
(host) to the MTP Responder (client) and is used to carry command and data. The
second channel runs from the MTP Responder (client) to the MTP Initiator (host) and
is used to carry events. Both channels may be used to issue transport errors to
support transmission on unreliable L2CAP connections.
2.2.1 Maximum Transmission Unit (MTU) Requirements
The minimum MTU value required is 48 bytes. However given the fact that MTP is
frequently used to transmit large binary objects initiators the default L2CAP MTU of
768 bytes tends to introduce significant performance penalties given the number of
2
The key protocols evaluated were L2CAP, RFCOMM, and MTP/IP carried over a Bluetooth
PAN connection. Given the channel requirements of MTP in combination with the drive for
greater simplicity and better future adaptation in the Bluetooth implementation, RFCOMM
was excluded. While carrying MTP/IP over the top of PAN was a reasonable approach, some
PII concerns arise that may have required an additional layer of security. The combination of
performance and the security requirement excluded PAN from selection.
3
The MTP Bluetooth model is similar to the MTP/IP specification in its use of channel
allocation and packet formats. Due to slightly different requirements and reliability issues
with L2CAP some changes have been introduced.
license agreement.
MTP over Bluetooth
packets required to send these objects. It has been found that packet sizes of
around 8 KB are the most efficient.
More powerful MTP Initiators (with more memory, higher CPU performance) are
encouraged to let the MTP Responder establish the packet sizes.
2.2.2 SDP Records

The Bluetooth protocol specifies that supported services on a Bluetooth-capable
device are discovered through the SDP protocol. The MTP Bluetooth model defines
two SDP servicesthe MTP Initiator Service and the MTP Responder Service. The
MTP Initiator Service record publishes the necessary information for an MTP
Responder device to connect to the MTP Initiator and establish an event channel.
The MTP Responder Service record publishes the necessary information for an MTP
Initiator device to connect to the MTP Responder and establish a command/data
channel.
In order for an Initiator to support incoming connections from a Responder, it MUST

publish an MTP Initiator Service record. If an Initiator only desires to initiate
connections and not allow a remote Responder to initiate connections it MUST NOT
publish an MTP Initiator Service record.
In order for a Responder to support incoming connections from an Initiator it MUST

publish an MTP Responder Service record. If a Responder only desires to initiate
connections and not allow a remote Initiator to initiate connections it MUST NOT
publish an MTP Responder Service record.
An MTP link may only be established when either the MTP Initiator or the MTP
Responder Service record is present on at least one device.
Devices which desire to serve as both an Initiator and a Responder may publish
both the MTP Initiator and MTP Responder Service records.
2.2.3 Role Determination

Unlike USB and IP transports for MTP, the type of services published by the device
determines the MTP role (initiator or responder) rather than by the host which
initiates the connection4. Devices publishing the MTP Initiator SDP record are
defined to be MTP Initiators. Devices publishing the MTP Responder SDP record are
defined to be MTP Responders.
There is no restriction on a device publishing both an MTP Initiator and MTP

Responder records. It means this device is capable of performing either role. In this
4
In USB transports the Initiator is always the USB host while the responder is always the USB
client. In TCP transports the host initiates both the command/data and event connections.
license agreement.
MTP over Bluetooth
case, the service selected by the remote endpoint determines the role of the device
with respect to that connection.
2.2.4 Connections
MTP Bluetooth requires two active connections between the MTP Initiator and the
MTP Responder. An MTP Bluetooth Link is not considered established until both of
these connections have been made. Both of these connections MUST be
maintained for the lifetime of the MTP Bluetooth link. If either of these connections
is lost for any reason, the entire link is considered broken and the standard MTP
unexpected disconnect behaviors MUST be employed.
2.2.4.1Command/Data Channel
The command/data channel is always created by the MTP Initiator to the MTP
Responder. This channel carries the core MTP command and data operations for
each transaction. The connection is made to a published SDP Responder endpoint
on the Responder device.
2.2.4.2Event Channel
The event channel is always created by the MTP Responder to the MTP Initiator.
This channel carries asynchronous event data from the Responder to the Initiator.
The connection is made to a published SDP Initiator endpoint on the Initiator device.
The amount of information on the Event Channel is expected to be low. Therefore
power or servicing optimizations MAY be made provided that the connection itself is
maintained.
2.2.5 Security
MTP is intended to be a generic object exchange protocol. As such it is reasonable
to expect that sensitive information including Personally Identifiable Information
(PII) will be exchanged over this link. For this purpose all MTP Bluetooth
connections MUST support authorization, authentication, and encryption:
Bluetooth 2.0 and earlier implementations MUST support Security mode 2

(service level enforced security) with authorization, authentication, and
encryption.
Bluetooth 2.1 and later implementations MUST support Security mode 4
(service level enforced security) with an authenticated link key requirement.
When establishing connections between two Bluetooth devices of differing

capabilities, the highest possible security MUST be used. For example, when a
Bluetooth 2.1 device connects to a Bluetooth 1.1 device, Security mode 2 must be
enforced as this is the highest level of security supported by the Bluetooth 1.1
device.

license agreement.
MTP over Bluetooth
2.2.6 L2CAP Flow Control and Retransmission Support

Multiple versions of L2CAP Flow Control and Retransmission Support have been (or
are being) defined. In order to meet the Reliable, Error Free Channel transport
requirement defined in the MTP specification, each Bluetooth endpoint MUST
attempt to negotiate for the highest level of L2CAP Flow Control and Retransmission
support that it supports. As this support is symmetric, both the Command/Data and
Event pipes MUST have the same L2CAP Flow Control and Retransmission support
enabled regardless of who initiates the MTP Link. Where a mutually acceptable
level of Flow Control and Retransmission support cannot be negotiated, L2CAP Basic
Mode MUST be employed and the MTP Bluetooth Transport Error Detection behavior
MUST be fully enabled.
2.3 MTP Bluetooth Service Definitions

Like all Bluetooth functionality, support for the MTP Bluetooth protocol is published
via the Service Discovery Protocol (SDP). MTP defines two service record types
which must be listed separately (i.e. assigned unique ServiceRecordHandle values)
within the SDP database.
2.3.1 MTP Initiator Service Definition Record

The MTP Initiator Service Definition Record provides details to a connecting
responder on how to establish the event channel. The record MUST contain:
Item Definition Type/Size Value AttributeI

D
ServiceClassIDList 0x0001
ServiceClass0 MTP UUID { 9518e5ca
Initiator -f6af-464b-
9907-
a97433641
968}5
ProtocolDescriptorList 0x0004
Protocol0 L2CAP UUID L2CAP
Protocol0SpecificParame PSM UInt16 0x1xxx6
ter0
Protocol1 MTP UUID {824ea7cf-
dae9-4d87-
a97e-
d3458416f3
b3}
5
UUIDs currently called out in the MTP Bluetooth profile specification are vendor generated
128-bit UUIDs. As the MTP Bluetooth Profile is further defined in the BT SIG either 16-bit or
32-bit UUIDs MAY be assigned.
6
MTP Bluetooth is expected to use a dynamic PSM assigned by the particular device
implementation. As appropriate, a standard PSM MAY be adopted during formalization
through the BT SIG.
license agreement.
MTP over Bluetooth
Protocol1SpecificParame Version UInt16 0x0100

ter1
BluetoothProfileDescript 0x0009
orList
Profile0 MTP Profile UUID { eb981b53
-a110-4f7c-
97b6-
af4843cfcf9
8}
Profile0SpecificParamete Version UInt16 0x0100
r0
Additional parameters such as Provider Name and Service Name are optional.
2.3.2 MTP Responder Service Definition Record

The MTP Responder Service Definition Record provides details to a connecting
Initiator on how to establish a command/data connection.
Item Definition Type/Size Value AttributeI

D
ServiceClassIDList 0x0001
ServiceClass0 MTP UUID { b1673f75
Responder -a798-
4ed8-a662-
b4f4d3286e
a9}
ProtocolDescriptorList 0x0004
Protocol0 L2CAP UUID L2CAP
Protocol0SpecificParame PSM UInt16 0x1xxx7
ter0
Protocol1 MTP UUID {824ea7cf-
dae9-4d87-
a97e-
d3458416f3
b3}
Protocol1SpecificParame Version UInt16 0x0100
ter1
BluetoothProfileDescript 0x0009
orList
Profile0 MTP Profile UUID { eb981b53
-a110-4f7c-
97b6-
7
MTP Bluetooth is expected to use a dynamic PSM assigned by the particular device
implementation. As appropriate, a standard PSM MAY be adopted during formalization
through the BT SIG.
license agreement.
MTP over Bluetooth
af4843cfcf9
8}
Profile0SpecificParamete Version UInt16 0x0100
r0
Additional parameters such as Provider Name and Service Name are optional.
2.4 Transport Channel Management

Unlike USB and IP transports, the transport channel management behavior in MTP
over Bluetooth is designed to be bidirectional. This means that either the Initiator
or Responder is capable of initiating an MTP link. The user experiences around how
and when links are established are beyond the scope of this document. At a
minimum it is assumed that some user initiated behavior will cause either the
Initiator or the Responder to request the MTP link.
2.4.1 Bluetooth Pairing

The process of pairing two MTP Bluetooth-enabled devices is beyond the scope of
this document. It is assumed that existing pairing behavior on the Initiator and/or
Responder is capable of establishing the basic Bluetooth link.
2.4.2 Initiator Driven Link Establishment

The process by which an Initiator requests the establishment of an MTP link is:
1. The Initiator begins by performing an SDP query to discover if the remote

device supports the MTP Responder Service. If the device does not support
the MTP Responder Service no link is possible and the link establishment
aborts.
2. The Initiator creates a local Command/Data L2CAP dynamic endpoint to send
and receive data from the Responder device.
3. The Initiator initiates a Command/Data L2CAP connection request to the PSM
specified in the MTP Responder Service record from the remote device
specifying the local L2CAP dynamic channel. The Initiator requests the
highest level of L2CAP Flow Control and Retransmission options that it is
capable of supporting.
4. As appropriate, Bluetooth security protocols are handled to guarantee the
required security level according to the Bluetooth version in use.
5. Upon acknowledgement that the link is available, the Initiator generates a
UUID LinkID to identify this particular link.
6. The Initiator sends an InitCommandRequest packet to the Responder over
the bound Command/Data L2CAP channel containing the newly generated
LinkID and the L2CAP PSM to which the Responder should connect to
establish the event link.

license agreement.
MTP over Bluetooth
7. Upon receiving the InitCommandRequest and associated LinkID and

remote PSM, the Responder creates a local L2CAP dynamic endpoint to use
for sending Events.
8. The Responder initiates an Event L2CAP connection request to the Initiator
using the PSM specified in the InitCommandRequest. The Responder
requests the highest level of L2CAP Flow Control and Retransmission options
that it is capable of supporting.
9. Upon acknowledgement that the link is available, the Responder sends an
InitEventRequest packet to the Initiator containing the LinkID from the
InitCommandRequest packet and an empty (0) PSM to indicate that this is
in response to an Initiator started link establishment request.
10.Upon receiving the InitEventRequest, the Initiator uses the LinkID to
associate the Event L2CAP connection with the corresponding Command/Data
L2CAP connection and marks the link as active. If the LinkID is
unrecognized, a LinkFail packet MUST be sent in response to the
InitEventRequest.
11.The Initiator sends an InitLinkAck packet containing the LinkID to the
responder over the Command/Data connection to indicate that the MTP link
has now been fully established and that standard MTP Transactions will now
commence over this link.
Errors which occur during any phase of the link establishment MUST be
acknowledged by sending a LinkFail packet first over the link being established
and then over any previously established link. For example, if the MTP Responder is
unable to establish a local dynamic endpoint to use for the Event Connection, it
must respond to the InitCommandRequest with a LinkFail packet. No additional
LinkFail packets should be sent. However, if the MTP Initiator rejects the
InitEventRequest, the LinkFail packet must first be sent over the just established
Event connection and then over the previously established Command/Data
connection.
2.4.3 Responder Driven Link Establishment

The process by which a Responder requests the establishment of an MTP link is:
1. The Responder begins by performing an SDP query to discover if the remote

device supports the MTP Initiator Service. If the device does not support the
MTP Initiator Service no link is possible and the link establishment aborts.
2. The Responder creates a local Event L2CAP dynamic endpoint to send events
to the Initiator device.
3. The Responder initiates an Event L2CAP connection request to the PSM
specified in the MTP Initiator Service record from the remote device
specifying the local L2CAP dynamic channel. The Responder requests the

license agreement.
MTP over Bluetooth
highest level of L2CAP Flow Control and Retransmission options that it is

capable of supporting.
4. As appropriate Bluetooth security protocols are handled to guarantee the
required security level according to the Bluetooth version in use.
5. Upon acknowledgement that the link is available, the Responder generates a
UUID LinkID to identify this particular link.
6. The Responder sends an InitEventRequest packet to the Initiator over the
bound Event L2CAP channel containing the newly generated LinkID and the
L2CAP PSM to which the Initiator should connect to establish the
Command/Data link.
7. Upon receiving the InitEventRequest and associated LinkID and remote
PSM, the Initiator creates a local L2CAP dynamic endpoint to use for sending
Command/Data.
8. The Initiator starts a Command/Data L2CAP connection request to the
Responder using the PSM specified in the InitEventRequest. The Initiator
requests the highest level of L2CAP Flow Control and Retransmission options
that it is capable of supporting.
9. Upon acknowledgement that the link is available, the Initiator sends an
InitCommandRequest packet to the Responder containing the LinkID from
the InitEventRequest packet and an empty (0) PSM to indicate that this is
in response to a Responder initiated link establishment request.
10.Upon receiving the InitCommandRequest, the Responder uses the LinkID
to associate the Command/Data L2CAP connection with the corresponding
Event L2CAP connection and marks the link as active.
11.The Responder sends an InitLinkAck packet containing the LinkID to the
Initiator over the Event connection to indicate that the MTP link has now been
fully established and that standard MTP Transactions will now commence over
this link.
Errors which occur during any phase of the link establishment MUST be
acknowledged by sending a LinkFail packet first over the link being established
and then over any previously established link. For example, if the MTP Initiator is
unable to establish a local dynamic endpoint to use for the Command/Data
Connection, it must respond to the InitEventRequest with a LinkFail packet. No
additional LinkFail packets should be sent. However, if the MTP Responder rejects
the InitCommandRequest, the LinkFail packet must first be sent over the just
established Command/Data connection and then over the previously established
Event connection.
2.4.4 Race Conditions in Link Establishment

Since both devices are capable of simultaneously establishing an MTP link, the
connection started by the Initiator gets the preference over the Responder.
Therefore the Initiator should examine the MAC address for all Responder initiated

license agreement.
MTP over Bluetooth
link establishments which contain an unknown LinkID and validate that a pending
request to the same device is not already in process. If such a pending request is
located, the Initiator MUST respond to the device with a LinkFail packet and specify
FAIL_PENDING_REQUEST as the reason.
2.4.5 MTP Bluetooth Link Power Management

Bluetooth has been optimized for use in low-power environments. In some cases
higher level constructs such as MTP Sessions need to be handled with care to match
Bluetooth power requirements. Toward this each Bluetooth device must take
specific set of actions to optimize MTP Bluetooth link power states.
An Initiator MUST:
1. Support entering into SNIFF mode when no MTP transactions are pending.
2. Throttle to the lowest power transmission mode for all command and event
transmissions.
3. Elevate to the highest power transmission mode for all data transmissions
A Responder MUST:
1. Support entering into SNIFF mode when no MTP transactions are pending
2. Throttle to the lowest power transmission mode for all response and event
transmissions
3. Elevate to the highest power transmission mode for all data transmissions
2.4.6 Shutdown of MTP Bluetooth Link

Given the issues resulting from general wireless interference and the limited range
of the underlying Bluetooth connection, all attempts should be made to maintain a
connection for as long as possible. Only the Initiator may authoritatively issue the
request to tear down the link on an otherwise valid Bluetooth connection. This
requirement is in place to make sure that the Initiator has an opportunity to
complete all pending operations, or otherwise notify an MTP application, before the
link is destroyed. However, a Responder may request that the link be terminated by
sending a RequestLinkDestroy packet on the Event channel to inform the Initiator
that it desires to terminate the currently active MTP Bluetooth link.
The process for destroying the MTP Bluetooth link is:
1. The Initiator determines that the link should be closed in response to some
MTP application request, a timeout determination, or a specific request from
the Responder via a RequestLinkDestroy packet arriving on the Event
connection.
2. The Initiator closes the Command/Data L2CAP connection to the Responder to
indicate that the link should be destroyed.

license agreement.
MTP over Bluetooth
3. Upon determining that the Command/Data L2CAP connection has been

closed, the Responder closes the Event connection.
In the event that either device receives an unexpected notification that the
Command/Data or Event connection is closed, it should assume that the devices are
no longer within Bluetooth range and forcibly close the current MTP Session as well
as close any L2CAP link associated with the link that is still active. It should be
understood that the formal and unexpected disconnect appears the same from the
Responders perspective and, given the transactional nature of MTP, it is safe to
assume that an incomplete transaction or unclosed session is an indication that the
link was unexpectedly disconnected.
2.5 Transfer Packet Types

To promote as much reuse as possible of existing code, an effort has been made to
maintain a packet model that closely resembles the MTP/IP specification. However
due to the unreliable nature of the Bluetooth L2CAP Basic Mode some changes are
needed to handle error detection. In addition, changes to the link setup and destroy
packets have been introduced to better suit Bluetooth environments.
2.5.1 Packet Header and Identifiers

All MTP Bluetooth data is sent in the form of well-defined packets. All packets
except the DataPacket MUST be sent using the smallest available packet over the
Bluetooth Baseband.
All multi-byte values in an MTP Bluetooth packet are in little-endian format.
The general format of the MTP Bluetooth packet is:
Field Size Data Type Description

(Bytes)
Length 4 UINT32 Total size of the packet, in bytes,
including the header
PacketType 1 UINT8 Identifies the type of MTP packet
being sent. See details below.
TransportID 1 UINT8 Identifies the transport type for this
packet. For MTP Bluetooth packets
the Transport ID MUST be 0x01.
SequenceID 2 UINT16 Monotonically increasing value
used in L2CAP Basic Mode to

license agreement.
MTP over Bluetooth
handle transport reliability.

Payload ?? ?? As defined by packet type
PacketType must be set to one of the following valid packet types 8:
PacketType Description
0x00 Invalid Value
0x01 0x04 Reserved
0x05 Link Fail Packet
0x06 Operation Request Packet
0x07 Operation Response

Packet
0x08 Event Packet
0x09 Start Data Packet
0x0B Cancel Packet
0x0C Reserved
0x0D Probe Request Packet
0x0E Probe Response Packet
0x0F Reserved
0x11 Init Command Request

Packet
0x12 Init Event Request Packet
0x13 Init Link

Acknowledgement
0x14 End Data Packet
0x15 Transport Error Packet
0x16 Transport Ready Packet
0x17 Request Link Destroy
8
Implementers familiar with the MTP/IP specification will appreciate that the packet types
described here align with the standard MTP/IP types. However, the size of the packet type
field has been reduced from a UINT32 to a UINT8 to accommodate both the TransportID
and SequenceID fields. Ordering of the fields accommodates the Big Endian ordering of
the MTP/IP UINT32 PacketType value. To use a similar header structure for MTP/IP parsing
the TransportID for MTP/IP MUST be 0 and the SequenceID must also be 0.
license agreement.
MTP over Bluetooth
Packet
0x18 Data Packet
0x19 0xFF Reserved
2.5.2 Parameter Optimizations

Many MTP operations, responses, and events do not require all of the available
parameters. Only non-zero parameters must be sent except in the case where a
zero-value parameter precedes a non-zero parameter. Parameters that are not sent
are assumed to have a zero value by the receiving device.
The following examples demonstrate when it is valid to omit parameters:
The operation only requires 3 parameters and space is available for 5. Only
the first 3 parameters need to be sent.
The operation requires 5 parameters, space is available for 5, but all
parameters are zero. All parameters may be omitted.
The following examples demonstrate when it is invalid to omit parameters:
The operation requires 4 parameters. The first and third parameters are zero,
the second and forth parameters are non-zero. All of the first 4 parameters
need to be sent, the fifth parameter may be omitted.
2.5.3 Link Fail Packet

The LinkFail packet is used by either the MTP Bluetooth Initiator or Responder to
indicate that the attempt to establish an MTP Bluetooth Link failed. This packet is
always sent on the same channel, Command/Data or Event, on which the failing
initialization request was received.

(Bytes)
2.6 Length 2.7 4 2.8 UINT3 2.9 Total size of the packet, in
2 bytes, including the header

TransportID 1 UINT8 Identifies the transport type for

this packet. For MTP Bluetooth
packets the Transport ID MUST be

license agreement.
MTP over Bluetooth
0x01.

Reason 4 UINT32 Reason why the link establishment

failed
The following failure codes are defined:
2.9.1 Operation Request Packet

The OperationRequest packet is used by the Initiator to start a transaction and
request an operation of the Responder. This packet is always sent by the Initiator to
the Responder on the Command/Data channel.

(Bytes)


SequenceID 2 UINT16 Monotonically increasing value used

in L2CAP Basic Mode to handle
transport reliability.
Data Phase 4 UINT32 Specifies the direction of the data

Info phase to follow9. Values are defined
as:
0x00000001 No Data or Data
In
0x00000002 Data Out
0x00000000 Unknown Data
phase
Unless the Initiator knows that it will
be sending data, based on the
operation specified, the Initiator
should specify 0x00000001 (No Data
9
See MTP/IP specification for more details about how data phase MUST be set.
license agreement.
MTP over Bluetooth
or Data In)
Operation 2 UINT16 MTP Operation Code
Code
Transaction ID 4 UINT32 Current Transaction ID
Parameter1 4 UINT32 First operation parameter
Parameter2 4 UINT32 Second operation parameter
Parameter3 4 UINT32 Third operation parameter
Parameter4 4 UINT32 Fourth operation parameter
Parameter5 4 UINT32 Fifth operation parameter
2.9.2 Operation Response Packet

The OperationResponse is sent by the Responder when it completes the desired
MTP operation. This packet is always sent by the Responder to the Initiator on the
Command/Data channel.

(Bytes)



Response 2 UINT16 MTP Response Code

Code
Parameter1 4 UINT32 First response parameter
Parameter2 4 UINT32 Second response parameter
Parameter3 4 UINT32 Third response parameter
Parameter4 4 UINT32 Fourth response parameter
Parameter5 4 UINT32 Fifth response parameter
2.9.3 Event Packet

The Event packet is used to inform the Initiator of events taking place on the
Responder. The Event packet is always sent by the Responder to the Initiator on the
Event channel.

license agreement.
MTP over Bluetooth
(Bytes)



Event Code 2 UINT16 MTP Event Code

Transaction ID 4 UINT32 Transaction ID. If the event
corresponds to a previously initiated
transaction, this field SHALL hold the
TransactionID of that operation. If the
event is not specific to a particular
transaction then this field SHALL be
set to 0xFFFFFFFF.
Parameter1 4 UINT32 First event parameter
Parameter2 4 UINT32 Second event parameter
Parameter3 4 UINT32 Third event parameter
2.9.4 Start Data Packet

The StartData packet is used by either the Initiator or Responder to indicate the
beginning of a data phase. This packet is always transmitted on the Command/Data
channel.

(Bytes)




license agreement.
MTP over Bluetooth

Total Data 8 UINT64 Contains the total length of the data
Length phase to follow. In the event that the
exact length of the data is not known
this parameter may be set to
0xFFFFFFFFFFFFFFFF and the length
will be determined by the count of
bytes transmitted in each data
packet. Devices are encouraged to
send a length value as the receiving
device is typically able to better
optimize how data packets are
handled when this value is present.
2.9.5 Cancel Packet

The Cancel packet is used by the Initiator to cancel the current transaction. The
Cancel packet is always sent by the Initiator to the responder on both the
Command/Data and Event connection.

(Bytes)



Special care must be taken to ensure that the Cancel packet is retrieved from both
the Command/Data and Event channel when it is detected. All packets associated
with the specified TransactionID MAY be removed and discarded from either data
channel in response to receiving this packet.

license agreement.
MTP over Bluetooth
2.9.6 Probe Request Packet

The ProbeRequest packet is used by both the Initiator and the Responder to
validate that the receiving device is still active and processing requests. Upon
receiving a ProbeRequest packet the device MUST respond immediately with a
ProbeResponse packet. If no response is received within a reasonable amount of
time, the device issuing the ProbeRequest packet may assume that the other
device is no longer active and initiate closing the connection. Devices MUST be
judicious with their use of the ProbeRequest packet as extensive transmission of
this packet will degrade the overall throughput of the Bluetooth link and consume
additional power. The ProbeRequest packet is always sent on the Event channel.

(Bytes)



2.9.7 Probe Response Packet

The ProbeResponse packet is used to respond to a ProbeRequest packet from a
sending device. This packet MUST be sent immediately upon receipt of the
ProbeRequest packet. The ProbeResponse packet is always sent on the Event
channel.

(Bytes)



license agreement.
MTP over Bluetooth

Device Status 4 UINT32 MTP defined device status code:

0x00002001 Status OK
0x00002019 Device Busy
If a device is currently processing a transaction when a ProbeRequest packet is

received, the device MUST return 0x00002019 (Device Busy) in the
ProbeResponse packet. If the device is not processing a transaction it MUST
return 0x00002001 (Status OK) in the ProbeResponse packet. MTP Initiator
devices may use the result of a probe request to determine whether or not a device
has successfully completed a transaction. If the Initiator has issued an
OperationRequest packet and is expecting either data or response to be returned
from the device, the Initiator may probe the device via ProbeRequest to determine
if the device is working on the request. If the device reports 0x00002019 (Device
Busy) the Initiator MAY assume that the device is still processing the request. If the
device reports 0x00002001 (Status OK) the Initiator MUST check again for either
data or an operation response on the Command/Data channel. If no data is present,
the Initiator MAY assume that the device has either failed to receive or complete the
operation correctly and start any desired abort behavior.
2.9.8 Init Command Request Packet

The InitCommandRequest packet is always sent by the Initiator to the Responder
to initialize the Command/Data connection in the MTP link. This packet may be sent
in response to a connection event generated on the Initiator or to an
InitEventRequest packet from a Responder. This packet is always the first packet
sent on the Command/Data channel.

(Bytes)



license agreement.
MTP over Bluetooth

LinkID 16 UINT128 UUID to be associated with this MTP
link. The LinkID is either a new UUID
generated by the Initiator or the UUID
received in the LinkID parameter via
the InitEventRequest packet.
PSM 2 UINT16 The L2CAP PSM which identifies
where the device receiving this
packet should connect to send
events. The PSM is either valid or 0 if
the InitCommandRequest packet is
being sent in response to receiving an
InitEventRequest packet.
2.9.9 Init Event Request Packet

The InitEventRequest packet is always sent by the Responder to the Initiator to
initialize the Event connection in the MTP link. The packet may be sent in response
to a connection event generated on the Responder or to an InitCommandRequest
packet from an Initiator. This packet is always the first packet sent on the Event
channel.

(Bytes)



LinkID 16 UINT128 UUID to be associated with this MTP

link. The LinkID is either a new UUID
generated by the Responder or the

license agreement.
MTP over Bluetooth
UUID received in the LinkID

parameter via the
InitCommandRequest packet.
PSM 2 UINT16 The L2CAP PSM which identifies
where the device receiving this
packet should connect to send
command and data. The PSM is
either valid or 0 if the
InitEventRequest packet is being
sent in response to receiving an
InitCommandRequest packet.
2.9.10 Init Link Acknowledgement Packet

The InitLinkAck packet is sent when a successful MTP link has been established. It
is always sent on the channel which initiated the MTP link and by the device which
established the link:
If an Initiator started the link establishment process, the InitLinkAck packet

is sent on the Command/Data link by the Initiator once the Event connection
for the specified LinkID has been established.
If a Responder started the link establishment process, the InitLinkAck
packet is sent on the Event link by the Responder once the Command/Data
connection for the specified LinkID has been established.

(Bytes)

TransportID 1 UINT8 Identifies the transport type for

this packet. For MTP Bluetooth
packets the Transport ID MUST be
0x01.

LinkID 16 UINT128 UUID to be associated with this

license agreement.
MTP over Bluetooth
MTP link.
2.9.11 End Data Packet

The EndData packet is sent following the final Data packet containing the end of
the data being transferred. The EndData packet carries no data10. EndData
packets are always sent on the same channel as the associated StartData and
Data packets.

(Bytes)




CRC-32 4 UINT32 CRC-32 of the data that was
transferred. When operating in Basic
L2CAP Mode this value should be
compared against the value
calculated by the receiving device for
accurate data transmission. If Basic
L2CAP Mode is not in use this field
SHALL be set to 0xFFFFFFFF.
In the event that no data needs to be transferred during the data phase, the
StartData packet will be followed immediately by the EndData packet.
2.9.12 Transport Error Packet

The TransportError packet is used in Basic L2CAP Mode to notify the sending
device that the receiving device detected some form of transport error.
TransportError MUST only be sent when L2CAP Basic Mode operation is being
10
This is a significant difference from MTP/IP. In order to better support streaming
implementations operating in Basic L2CAP Mode, it was necessary to remove the data from
the EndData packet so that the CRC-32 could be transmitted without having to go back to
the top of the packet to update data.
license agreement.
MTP over Bluetooth
used. The TransportError packet is always sent by the device detecting the error
on both the Command/Data and Event channel.

(Bytes)



Transaction ID 4 UINT32 Transaction ID. If the transport error

corresponds to a transaction ID, this
field MUST hold the TransactionID of
that operation. If the error is not
specific to a particular transaction
then this field SHALL be set to
0xFFFFFFFF.
Link ID 16 UINT128 UUID associated with this MTP link.
Reason Code 4 UINT32 Identifies the reason the transport
error was indicated:
When an Initiator Device receives a TransportError from a Responder on either

channel, the Initiator MUST treat the TransportError as a cancellation request from
the device. If the Initiator is sending data to the device it MUST stop sending data
for the current transaction and notify clients that the transaction was cancelled. If
the Initiator is waiting for data from the device it MUST flush all data on the
Command/Data channel and notify clients that the transaction was cancelled. The
initiator MUST remove all events on the EVENT channel until a TransportReady
notification. Once a TransportReady notification is received normal operations
may resume.
When a Responder Device receives a TransportError from an Initiator on either

channel, the Responder MUST treat the TransportError as a cancellation request
from the initiator. MTP Responder clients should be notified of the cancellation as if
this was a formal cancellation request from the Initiator. However, the Response
license agreement.
MTP over Bluetooth
SHOULD not send an Operation Response packet indicating that the transaction was
cancelled. As with a normal cancellation request, the Responder MUST halt sending
of additional data and also flush all data on the Command/Data channel. All
information on the Event channel MUST also be flushed. Upon completion of these
operations, the Responder MUST send a TransportReady packet to resume normal
operation. As with the standard cancel operation, there is no requirement for a MTP
Responder to cache data associated with the current transaction in order to fully roll
back from a cancelled transaction.
2.9.13 Transport Ready Packet

The TransportReady packet is used in Basic L2CAP Mode to notify the Initiator and
Responder that each side of the link has recovered from a previous TransportError
state. TransportReady MUST only be sent when L2CAP Basic Mode operation is
being used. The TransportReady handshake is always started by the Initiator and
is sent over both the Command and Event channel. The Responder only sends a
TransportReady packet over the Command and Event channels in response to
receiving a packet from the Initiator.

(Bytes)



Link ID 16 UINT128 UUID associated with this MTP Link.
Upon receipt of a TransportReady packet the Initiator MAY resume normal MTP
operations. After sending a TransportReady packet in response to the Initiator,
the Responder MUST enter the wait for next operation state.
2.9.14 Request Link Destroy Packet

The RequestLinkDestroy packet is sent by the Responder to the Initiator to
indicate that it desires to initiate a formal shutdown of the MTP Bluetooth link. This
packet is always sent by the Responder to the Initiator on the Event channel.
license agreement.
MTP over Bluetooth

(Bytes)



Link ID 16 UINT128 UUID associated with this MTP Link.
Upon receipt of a RequestLinkDestroy packet, the Initiator MUST determine that

no active transactions are currently pending. Once the current transaction has
completed, the Initiator SHOULD begin an orderly shutdown of the MTP Bluetooth
Link by starting a close operation on the Command/Data L2CAP channel.
2.9.15 Data Packet

The Data packet is sent following the StartPacket and contains the data to be
transferred during the data phase. Data may be split among multiple Data packets
using simple chunking models for better resource management. Data packets are
always sent on the same channel as the StartData packet that initiated the
transfer.

(Bytes)



license agreement.
MTP over Bluetooth

Running CRC- 4 UINT32 When Basic L2CAP mode is in use this
32 field contains the running CRC-32
resulting from CRC-32 computations
on the data in the previous data
packet transferred. In this mode the
first data packet SHALL always
contain 0xFFFFFFFF in this field as
there is no previous packet over
which the CRC-32 will have been
calculated. When Basic L2CAP mode
is not in use this field is not used and
SHALL always be set to a value of
0xFFFFFFFF
Data Payload ?? UINT8 Data being transferred. Note that
when operating in a mode where the
total data length has not been
specified, only the length of the Data
Payload should be used to determine
the length.
If the data phase is zero bytes in length, no Data packet should be sent. Only an
EndData packet should be sent.
2.10 L2CAP Basic Mode Support

By itself the Bluetooth L2CAP Basic Mode does not meet the reliability requirements
of the MTP specification. In order to enable semi-reliable transmission of MTP
transactions in this environment, a few accommodations have been made in the
MTP/BT packet definitions to handle detection of errors introduced by the unreliable
transport. However these accommodations only go as far as error detection. Unlike
L2CAP Enhanced Mode no attempt is made to attempt a transport level
retransmission of data in an attempt to recover from an error condition. In addition,
no effort is made to throttle L2CAP traffic to avoid transmission errors due to flow
issues. The L2CAP Basic Mode support within the MTP profile assumes best effort
delivery and is intended to only detect when an error has occurred so that
appropriate action may be taken by MTP Initiator and Responder clients.
2.10.1 Error Handling

The error handling model defined takes advantage of the fact that the MTP protocol
already has a cancel semantic defined. In a traditional cancel scenario either the
MTP Initiator or the MTP Responder may elect to halt the current MTP transaction by
issuing a cancel request. In response to the request, the current transaction is
license agreement.
MTP over Bluetooth
terminated and both the Initiator and Responder return to their wait for next
command states. The exact mechanics of how Initiators and Responders forward
the cancel request to applications and how they respond is outside the scope of this
specification.
In general when the L2CAP Basic Mode Support is in effect the underlying MTP/BT
transport, it generates a cancel operation on behalf of the transport whenever an
error is detected. For example when the Initiators MTP/BT stack detects a transport
error it behaves as if it has just received a cancel event from the device and
forwards that notification up its stack. Similarly when a Responder detects a
transport error it forwards a cancel operation up its stack just as if a cancel packet
had been received from the Initiator. In both cases a TransportError packet is also
sent, triggering similar error recovery behaviors by the other end of the Link
whether as an Initiator or Responder The receipt of a TransportError packet
causes a cancel request to be forwarded up the stack.
A key aspect of the error handling protocol is the use of the TransportReady
acknowledgement between Initiator and Responder before regular MTP operations
are restarted. The protocol is designed in such a way that regardless of where the
error was detected, by the Initiator or Responder, the flush and restart mode are
identical to simplify implementation.
2.10.1.1 Initiator Detected Error Handling Protocol

When a MTP Initiator determines that the underlying Basic L2CAP link has caused
data to be lost or corrupted, it employs the following error handling protocol:
1. Initiators MTP/BT transport detects an error condition.

2. Initiators MTP/BT transport immediately stops queuing additional data to be
transmitted.
3. A cancellation request is forwarded by the Initiators MTP/BT transport as if
it had received a CancelTransaction MTP Event to waiting applications.
Application handling of the CancelTransaction behavior is beyond the scope
of this specification.
4. The Initiators MTP/BT transport sends a TransportError packet on both the
Command and Event channels including the LinkID and reason for the error.
5. When ready to begin normal MTP operations again, the Initiator sends a
TransportReady packet on both the Command and Event channels
containing the LinkID of the link being reset.
6. The Initiators MTP/BT transport flushes all pending data received from the
Responder until a TransportReady packet with the appropriate LinkID is
received on both the Command and Event channels.
7. Upon receipt of the TransportError packet on either the Command or Event
channel, the Responders MTP/BT transport immediately stops queuing
additional data to be transmitted.
license agreement.
MTP over Bluetooth
8. The Responders MTP/BT transport notifies waiting applications that the

current transaction is being cancelled as if it had received a Cancel packet
from the Initiator. Application handling of the Cancel packet is beyond the
scope of this specification.
9. The Responders MTP/BT transport flushes all pending data received from the
Initiator until a TransportReady packet with the appropriate LinkID is
10.The Responders MTP/BT transport resets the incoming Sequence ID for both
the Command and Event channels based on the Sequence ID present in the
11.The Responders MTP/BT transport sends a TransportReady packet with the
associated LinkID on both the Command and Event Channels and returns to
the wait for next command state.
12.Upon receipt of the TransportReady packet with the correct LinkID on both
Command and Event channels, the Initiators MTP/BT transport re-initializes
the Sequence ID for both the Command and Event channels based on the
Sequence ID present in the TransportReady packet.
13.The Initiator resumes standard MTP operation.
2.10.1.2 Responder Detected Error Handling Protocol

When a MTP Responder determines that the underlying Basic L2CAP link has caused
data to be lost or corrupted it employs the following error handling protocol:
1. Responders MTP/BT Transport detects an error condition

2. Responders MTP/BT Transport immediately stops queuing additional data to
be transmitted.
3. A cancellation request is forwarded by the Responders MTP/BT transport as
if it had received a Cancel packet from the MTP Initiator. Application
handling of the Cancel packet is beyond the scope of this specification.
4. The Responders MTP/BT Transport sends a TransportError packet on both
the Command and Event channels including the LinkID for this connection
and reason for the error.
5. The Responders MTP/BT transport flushes all pending data received from the
6. Upon receipt of the TransportError packet on either the Command or Event
channel, the Initiators MTP/BT transport immediately stops queuing
additional data to be transmitted.
7. The Initiators MTP/BT transport notifies waiting applications that the current
transaction is being cancelled as if it had received a CancelTransaction Event
from the Responder. Application handling of the CancelTransaction Event is
beyond the scope of this specification.

license agreement.
MTP over Bluetooth
8. When ready to begin normal MTP operations again, the Initiator sends a
TransportReady packet on both the Command and Event channels
containing the LinkID of the link being reset.
9. The Initiatorss MTP/BT transport flushes all pending data received from the
10.The Responders MTP/BT transport resets the incoming Sequence ID for both
the Command and Event channels based on the Sequence ID present in the
11.The Responders MTP/BT transport sends a TransportReady packet with the
associated LinkID on both the Command and Event Channels and returns to
the wait for next command state.
12.Upon receipt of the TransportReady packet with the correct LinkID on both
Command and Event channels, the Initiators MTP/BT transport re-initializes
the Sequence ID for both the Command and Event channels based on the
Sequence ID present in the TransportReady packet.
13.The Initiator resumes standard MTP operation.
2.10.2 Error Detection Fields

MTP/BT packet structures include a SequenceID and Running CRC-32, and CRC-
32 field to allow detection of error conditions. In environments where L2CAP Flow
Control and Retransmission support is enabled, MTP Bluetooth implementations
MUST NOT enable L2CAP Basic Mode Support behaviors within the MTP Bluetooth
packets. When MTP Bluetooth L2CAP Basic Mode support is disabled, a sending
device MUST specify that the functionality is disabled by setting all bits in the
SequenceID, Running CRC-32, and CRC-32 fields to 1. If the receiving device
detects that the sending device has disabled L2CAP Basic Mode Support behaviors
and determines that L2CAP Flow Control and Retransmission options are not
present, the receiving device MUST ignore the packet and MUST respond with an
TransportError Packet with the reason code set to
FAIL_INVALID_ERROR_DETECTION_MODE.
2.10.2.1 Sequence ID
The general MTP/BT packet header contains both a Transport Identifier and
additional transport specific data. MTP over Bluetooth defines that the UINT16
format reserved for transport specific data to contain a SequenceID. A
monotonically increasing UINT16 value, the SequenceID is incremented for every
packet header that originates from a particular MTP Bluetooth device. The value 0
is illegal and the value 0xffff is reserved to indicate that SequenceID is disabled
because L2CAP Flow Control and Retransmission is in use. Upon exhausting all
SequenceID values by incrementing to 0xFFFE, the SequenceID value should be
reset to 0x0001 and continue incrementing. Care needs to be taken when
evaluating SequenceID progression to account for rollover.
license agreement.
MTP over Bluetooth
The sending device may choose to initialize SequenceID to any starting value other
than 0x0 and 0xFFFF. Receiving devices are encouraged to initialize internal
tracking values to 0x0 upon startup or following any discontinuity in SequenceID
and assign them to the first SequenceID received. All packets following this initial
packet must resume standard progression requirements for SequenceID values.
Note that a sending device does not increment SequenceID upon receipt of a
packet; it is only incremented when it sends a packet.
To determine whether or not a transport error has caused a packet to be lost, a

receiving device MUST do the following:
1. Keep track of the last received SequenceID from the sending device in
LastSequenceID
2. Compare the SequenceID of the current packet to LastSequenceID + 1
taking into account rollover.
a. If the values match, the packet is OK and is accepted. No further work
is done.
b. If the values do not match, the receiving device initiates transaction
cancel behavior and transmits a TransportError packet on the
Command/Data and Event channel in accordance with the Transport
Error Handling section.
2.10.2.2 Running CRC-32 and CRC-32

The second addition is a UINT32 Running CRC-32 value in the Data packet and
the CRC-32 value in the EndData packet. While L2CAP and the underlying
Bluetooth Baseband support a level of error detection, it has been found to be
ineffective over large datasets. This CRC-32 value is calculated as defined in ISO
3309 and a reference for a fast ANSI C implementation is available as part of the
PNG specification (http://www.w3.org/TR/PNG/#D-CRCAppendix). The calculation of
the CRC-32 value always excludes the packet header information.
The CRC-32 fields in the Data packet and the EndData packet are subtly different.
The Running CRC-32 field in the Data packet takes into account all data
previously transmitted but not the data in the current packet. It is also not a final
CRC- it is the current intermediate value as calculated by the update_crc call in
the ANSI C implementation referenced above. The value of the CRC-32 in the
EndData packet takes into account all data transferred and is the full, complete
CRC-32 as defined by the crc function in the ANSI C implementation referenced.
The CRC-32 value is used to determine data errors as follows:
1. The sending device sends a StartData packet to the receiving device.

license agreement.
MTP over Bluetooth
2. The receiving device performs the necessary operations to begin receiving

the data.
3. The sending and receiving devices initializes the CRC-32 to the default value
of 0xFFFFFFFF.
4. The sending device begins sending Data packets to the receiving device
incrementing the SequenceID and storing the current value of the Running
CRC-32 value in the header. As the data is sent the Running CRC-32 value
is calculated over the just the current data in preparation to send it in the
following Data packet.
5. As the receiving device receives each Data packet it validates SequenceID
against the expected value and Running CRC-32 against what it calculated
for the previous Data buffer received.
a. If the receiving device determines that the SequenceID and Running
CRC-32 fields are accurate it accepts the Data packet and calculates
the Running CRC-32 value over just the data contained in the packet.
b. If the receiving device determines that either the SequenceID field or
the Running CRC-32 field contains invalid data, a TransportError
packet on the Command/Data and Event channels is sent in
accordance with the Transport Error Handling section.
6. The sending device continues to send Data packets as described until all
data has been sent. The receiving device continues to process Data packets
as described until all data has been received.
7. After sending all data, the sending device transmits an EndData packet
containing the final CRC-32 value it has calculated.
8. Upon receipt of the EndData packet, the receiving device compares the
CRC-32 value received from the sending device to the CRC-32 value it has
calculated.
a. If the values match the data is OK and is accepted. No further work is
done.
b. If the values do not match, the receiving device transmits a
TransportError packet on the Command/Data and Event channel in
accordance with the Transport Error handling section.

license agreement.

MTP Over BT Profile Specification

Uploaded by

Copyright:

Available Formats

MTP Over BT Profile Specification

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MTP Over BT Profile Specification

Uploaded by

Copyright:

Available Formats

MTP over Bluetooth Profile

2008 Microsoft Corporation. All rights reserved.

2008 Microsoft Corporation. All rights reserved.

2008 Microsoft Corporation. All rights reserved.

2008 Microsoft Corporation. All rights reserved.

2008 Microsoft Corporation. All rights reserved.

2008 Microsoft Corporation. All rights reserved.

2008 Microsoft Corporation. All rights reserved.

1.2 Key MTP Concepts

additional interaction being established.

1.3 Conformance with MTP/USB and MTP/IP

MTP places a set of requirements on transport layers to guarantee correct behavior:

1. Disconnection Events: The Bluetooth baseband operation includes a keep-

1.4 RFC 2119 Compliance

2008 Microsoft Corporation. All rights reserved.

2 MTP implementation over Bluetooth

2.2 Transport Model

2.2.1 Maximum Transmission Unit (MTU) Requirements

2.2.2 SDP Records

In order for an Initiator to support incoming connections from a Responder, it MUST

In order for a Responder to support incoming connections from an Initiator it MUST

2.2.3 Role Determination

There is no restriction on a device publishing both an MTP Initiator and MTP

Bluetooth 2.0 and earlier implementations MUST support Security mode 2

When establishing connections between two Bluetooth devices of differing

2008 Microsoft Corporation. All rights reserved.

2.2.6 L2CAP Flow Control and Retransmission Support

2.3 MTP Bluetooth Service Definitions

2.3.1 MTP Initiator Service Definition Record

Item Definition Type/Size Value AttributeI

Protocol1SpecificParame Version UInt16 0x0100

2.3.2 MTP Responder Service Definition Record

Item Definition Type/Size Value AttributeI

2.4 Transport Channel Management

2.4.1 Bluetooth Pairing

2.4.2 Initiator Driven Link Establishment

1. The Initiator begins by performing an SDP query to discover if the remote

2008 Microsoft Corporation. All rights reserved.

7. Upon receiving the InitCommandRequest and associated LinkID and

2.4.3 Responder Driven Link Establishment

1. The Responder begins by performing an SDP query to discover if the remote

2008 Microsoft Corporation. All rights reserved.

highest level of L2CAP Flow Control and Retransmission options that it is

2.4.4 Race Conditions in Link Establishment

2008 Microsoft Corporation. All rights reserved.

2.4.5 MTP Bluetooth Link Power Management

2.4.6 Shutdown of MTP Bluetooth Link

The process for destroying the MTP Bluetooth link is:

2008 Microsoft Corporation. All rights reserved.

3. Upon determining that the Command/Data L2CAP connection has been

2.5 Transfer Packet Types

2.5.1 Packet Header and Identifiers

All multi-byte values in an MTP Bluetooth packet are in little-endian format.

The general format of the MTP Bluetooth packet is:

Field Size Data Type Description

2008 Microsoft Corporation. All rights reserved.

handle transport reliability.

PacketType must be set to one of the following valid packet types 8:

0x01 0x04 Reserved

0x05 Link Fail Packet