Extended Service Discovery Profile for Universal Plug & Play
This document is a Bluetooth Extended Service
Discovery Profile (ESDP) for Universal Plug and Play (UPnP). The profile
defines how devices with Bluetooth wireless communications can use the
Bluetooth Service Discovery Protocol (SDP) initially to discover other
devices that support UPnP services and retrieve information about these
services. This profile further defines 3 ways how a device with Bluetooth
wireless communications can support UPnP services over the Bluetooth
protocol stack using
- the L2CAP layer or an
- Internet Protocol (IP) stack using the Personal
Area Network (PAN) Profile or an
- Internet Protocol (IP) stack using the Local
Area Network (LAN) Access Profile.
For more details : Download the EDSP Profile from the Bluetooth.org
website.
Typically, the Bluetooth Service
Discovery Protocol (SDP) enables the discovery of available services
in a Bluetooth system. SDP provides the mechanism for a device with
Bluetooth wireless communications to locate services offered by other such
devices. Since Logical Link Control and Adaptation
Protocol (L2CAP) does not provide robust networking functions, it
limits the discovery of services to the active devices in a given
Bluetooth piconet. In a networked computing environment, it is desirable
for devices to be able to discover services beyond their current Bluetooth
piconet to extend the functionality of the device. In addition, extended
service discovery could enable devices with Bluetooth wireless technology
to control remote resources on other devices (that may or may not employ
Bluetooth wireless communications) within and outside their piconets.
Universal Plug & Play (UPnP) is therefore used in this profile to
create a Bluetooth ESDP
Note: Universal Plug & Play (UPnP) is
a distributed, open networking architecture that is designed to enable
simple, ad hoc communication among distributed devices and services. UPnP
uses TCP/IP and the web model to provide seamless, media independent,
peer-to-peer device connectivity and control. UPnP is a computing,
electronics, telephony, and networking industry initiative designed to
enable connectivity among standalone devices and Personal Computers (PCs)
from many different vendors.
This profile defines two approaches to implementing
UPnP within a Bluetooth system:
- L2CAP -based solution focused on layering UPnP
services over the L2CAP layer of the Bluetooth
protocol stack for use by devices that lack IP support.
Definitions used in this profile:
- L2CAP-based solution: By an L2CAP-based solution we mean UPnP
over the L2CAP layer of the Bluetooth protocol stack. This
configuration does not include an IP stack and the UPnP messages are
transmitted directly over a connection-oriented L2CAP channel between
peer devices with Bluetooth wireless communications.
- IP-based solution: By an IP-based solution we mean UPnP over
an IP stack provided by either PAN or LAN Access profiles. In this
configuration the UPnP messages are transmitted appropriately over TCP
or UDP layers on top of the IP stack provided by the PAN or LAN Access
profiles.
- Control point: The control point consists of
a set of software modules that enables communication with UPnP device.
A control point initiates discovery and communication with UPnP
devices, and receives events from UPnP devices. Control points are
typically implemented on devices that have a user interface. This user
interface is used to interact with UPnP devices over the network.
- UPnP device: The UPnP device consists of a
set of software modules that enables communication with a UPnP control
point. UPnP devices respond to discovery requests, accept incoming
communications from control points and may send events to control
points.
- Local Device (LocDev): A LocDev is the device that initiates
the service discovery process. A LocDev must contain at least the
client portion for Bluetooth SDP. A LocDev contains the service
discovery application (SrvDscApp) used by a user to initiate
discoveries and display the results of these discoveries.
- Remote Device(s) (RemDev(s)): A RemDev is any device that
participates in the service discovery process by responding to the
service inquiries generated by a LocDev. A RemDev must contain at
least the server portion for Bluetooth SDP. A RemDev contains a
service record database, which the server portion of SDP consults to
create responses to service discovery requests.
The L2CAP-based solution is dependent upon the Generic
Access Profile (as are all profiles). While there is no direct
dependency upon the Service Discovery Application
Profile (SDAP), that profile does provide guidance relevant to the SDP
discovery facets of the ESDP for UPnP.
The IP-based solution is dependent upon at least one
of the IP profiles (PAN or LAN Access), as described below:
- The IP-based solution using PAN profile is dependent upon the PAN
profile, that in turn is dependent on other profiles.
- The IP-based solution using LAN Access profile is dependent upon the
LAN Access profile, which in turn is dependent upon the Serial
Port and Generic Access profiles; it also has the same
relationship to SDAP noted above for the L2CAP-based solution.
IP-based Solution using PAN Profile
The figure below shows the Bluetooth protocols and supporting entities
for the L2CAP-based solution.
Image reprinted from Bluetooth ESDP Profile, Figure
2.3 , page 13
The UPnP protocol stack in the LocDev or the RemDev
may either be a UPnP control point or a UPnP device. UPnP uses the
connection-oriented transport service in L2CAP, which in turn uses the
baseband asynchronous connectionless (ACL) links to carry UPnP messages
over the air-interface.
Discovery of UPnP services is performed by SDP.
Service discovery entails discovering Bluetooth services in proximity
after establishing an L2CAP connection.
IP-based Solution using PAN Profile
The next figure below shows the Bluetooth protocols
and supporting entities for the IP-based solution using the PAN profile.
Image reprinted from Bluetooth ESDP Profile, Figure
2.4 , page 14
UPnP uses the TCP and UDP transport services over
the IP stack provided by the PAN profile. Initial discovery for the
availability of UPnP services is performed using SDP. Following the
discovery of UPnP services within LocDev and RemDev, further networking
functions such as discovery, description, control, eventing, and
presentation can be performed using the UPnP services.
IP-based Solution using LAN Access Profile
The final figure below shows the Bluetooth protocols
and supporting entities for IP-based solution using the LAN Access
profile.
Image reprinted from Bluetooth ESDP Profile, Figure
2.5 , page 14
UPnP uses the TCP and UDP transport services over
the IP support provided by the LAN Access profile. In this scenario SDP
may not be used to discover UPnP services (although it is likely to be
used to discover support for the LAN Access profile). Discovery of UPnP
services across the LAN Access Point can be performed using the UPnP
service discovery mechanisms SSDP and GENA.
There are a number of user scenarios covered in each
solution:
L2CAP-based Solution
The following scenarios are covered by this profile:
- Two devices with the L2CAP-based solution establish a peer-to-peer
connection. Once connected, the devices can avail themselves of all
the services provided by UPnP networking functions.
- A device with an L2CAP-based solution establishes a peer-to-peer
connection with a device supporting UPnP services. This peer device
may be the bridge device if it supports UPnP services or a device
supporting UPnP services that can be reached via a bridge device. The
bridge device may also proxy UPnP services available across the
bridge. Once connected, the devices can avail themselves of all the
services provided by UPnP networking functions.
IP-based Solution using PAN Profile
The following scenarios are covered by this profile:
- Two devices with the IP-based solution using PAN profile establish a
peer-to-peer IP connectivity. Once connected, the devices can avail
themselves of all the services provided by UPnP networking functions.
- A device with an IP -based solution using PAN profile establishes
peer-to-peer IP connectivity with a device that may not support UPnP
but does provide IP access to other devices that provide UPnP
services. Once connected, the device with the IP-based solution using
PAN profile can avail itself of UPnP services so long as the other
device remains connected to the devices offering UPnP services.
- A device with an IP -based solution using PAN profile establishes a
peer-to-peer connection with a device supporting UPnP services on or
across a bridge device. The bridge device shall proxy UPnP services
available across the bridge. Once connected, the devices can avail
themselves of all the services provided by UPnP networking functions.
IP-based Solution using LAN Access Profile
The following scenario is covered by this profile:
- A device with an IP -based solution using LAN Access profile
establishes peer-to-peer IP connectivity with a LAN Access Point that
may not support UPnP but does provide IP access to other devices that
provide UPnP services. Once connected, the device with the IP-based
solution using LAN Access profile can avail itself of UPnP services so
long as the LAN Access Point remains connected to the devices offering
UPnP services.
Note: Before any two devices with Bluetooth wireless
communications can communicate with each other each device must be powered
on and initialised, and discovery of another device’s BD_ADDR via the
inquiry process, and the paging of (an)other device(s) to establish a
connection. This profile does not require the use of authentication and/or
encryption.
L2CAP-based Solution
A brief summary of the interactions in establishing
peer-to-peer UPnP networking connectivity between devices supporting UPnP
using L2CAP -based solution is given below. Subsequent sections in this
profile provide more detail for each of the following steps.
- Discover another device’s BD_ADDR via inquiry process and paging
of other device(s).
- If necessary, establish Bluetooth links with these devices and using
SDP find a device that provides UPnP services using the L2CAP-based
solution.
- Select a RemDev that provides UPnP services using L2CAP-based
solution and establish a baseband physical link to the selected device
if one does not exist.
- The devices establish a peer-to-peer L2CAP connection.
- Peer-to-peer UPnP networking connectivity is established.
- At any time either of the devices may terminate the L2CAP connection
thereby also terminating the peer-to-peer UPnP networking connection.
If however the peer-to-peer UPnP networking connection is terminated
the underlying L2CAP connection may or may not also be terminated.
IP-based Solution using PAN Profile
A brief summary of the interactions in establishing
peer-to-peer UPnP networking connectivity between a device supporting UPnP
services using IP -based solutions and a device across an IP network that
supports UPnP services is given below. Note that in this case the
device(s) within radio range of the device supporting UPnP services using
the IP -based solution shall provide IP support using PAN profile but may
not provide UPnP services.
- Discover another device’s BD_ADDR via inquiry process and paging
of other device(s).
- If necessary, establish Bluetooth links with these devices and using
SDP find a RemDev that provides IP support using the PAN profile; also
using SDP determine whether or not that device also provides UPnP
services.
- Select a RemDev that provides IP support using the PAN profile and
preferably also provides UPnP services and establish a baseband
physical link to the selected device if one does not exist.
- The devices establish a peer-to-peer PAN/L2CAP connection that
includes the negotiation of a suitable IP address.
- Once the connection is established, peer-to-peer IP traffic can flow
between the devices.
- Peer-to-peer UPnP networking connectivity is established using the
TCP and UDP transport stack over the IP stack provided by the PAN
profile if the peer device also provides UPnP services. Once
connected, the devices can avail themselves of all the services
provided by UPnP networking functions.
- At any time either of the devices may terminate the PAN connection
thereby also terminating the peer-to-peer UPnP networking connection.
If however the peer-to-peer UPnP networking connection is terminated
the underlying PAN connection may or may not also be terminated.
IP-based Solution using LAN Access Profile
A brief summary of the interactions in establishing
peer-to-peer UPnP networking connectivity between a device supporting UPnP
services using IP -based solution and a device across an IP network that
supports UPnP services is given below. Note that in this case the
device(s) within radio range of the device supporting UPnP services shall
provide IP support but may not provide UPnP services. Subsequent sections
in this profile provide more detail for each of the following steps.
- Discover another device’s BD_ADDR via inquiry process and paging
of other device(s).
- If necessary, establish Bluetooth links with these devices and using
SDP find a RemDev that provides IP support using the LAN Access
profile; also using SDP determine whether or not that device also
provides UPnP services.
- Select a RemDev that provides IP support using the LAN Access
profile. In addition to providing IP support, the RemDev (LAN Access
Point) may also provide UPnP services, i.e., UPnP services are hosted
on the LAN Access Point. The LocDev may preferably select a RemDev
that provides UPnP services in addition to IP support over another
RemDev that only provides IP support. Following the selection of the
desired RemDev, the LocDev shall establish a baseband physical link to
the selected RemDev if one does not exist.
- The devices establish a peer-to-peer connection that includes the
negotiation of a suitable IP address.
- Once the connection is established, peer-to-peer IP traffic can flow
between the devices.
- Peer-to-peer UPnP networking connectivity is established using the
TCP and UDP transport stack over the IP stack provided by the LAN
Access profile if the device also provides UPnP services. Once
connected, the devices can avail themselves of all the services
provided by UPnP networking functions.
- At any time either of the devices may terminate the LAN connection
thereby also terminating the peer-to-peer UPnP networking connection.
If however the peer-to-peer UPnP networking connection is terminated
the underlying LAN connection may or may not also be terminated.
This section describes the feature requirements for
devices with Bluetooth wireless communications using ESDP for UPnP
services.
Discover and Advertise UPnP Services: This
procedure is initiated by the LocDev to discover UPnP services provided by
RemDev(s) within radio range. The RemDev shall advertise the availability
of UPnP services via SDP service records if these services are provided.
The LocDev shall use Bluetooth SDP mechanisms to discover and retrieve
service information.
Operation of UPnP services: Following the
discovery of UPnP services the LocDev establishes a peer-to-peer UPnP
networking connection to the selected RemDev(s) that provide UPnP services
using the L2CAP-based solution This might be done for each selected
RemDev.
Discover IP Support: This procedure
is initiated by the LocDev to discover RemDevs within radio range that
support IP connectivity via the PAN profile. This may include discovery of
a bridge device. The LocDev shall use Bluetooth SDP to discover and
retrieve service information.
Discover and Advertise UPnP Services: This
procedure is initiated by the LocDev to discover UPnP services provided by
RemDev(s) within radio range or across a Bluetooth bridge device or in
another piconet. The LocDev shall use Bluetooth SDP mechanisms to discover
and retrieve service information. The RemDev may advertise the
availability of UPnP services via SDP service records if these services
are provided.
Operation of UPnP Services: Following
the establishment of IP connectivity and possibly the discovery of UPnP
services, the LocDev initiates the UPnP networking functions starting with
the discovery of UPnP services.
Discover IP Support: This procedure
is initiated by the LocDev to discover RemDevs within radio range that
support IP connectivity via the LAN profile. This may include discovery of
a bridge device. The LocDev shall use Bluetooth SDP to discover and
retrieve service information.
Discover and Advertise UPnP Services: This
procedure is initiated by the LocDev to discover UPnP services provided by
RemDev(s) within radio range or across a Bluetooth bridge device or in
another piconet. The LocDev shall use Bluetooth SDP mechanisms to discover
and retrieve service information.
Operation of UPnP Services: Following
the establishment of IP connectivity and possibly the discovery of UPnP
services, the LocDev initiates the UPnP networking functions starting with
the discovery of UPnP services
In this section, SDP transactions for ESDP for UPnP
service discovery are presented. SDP shall be used as the initial
discovery mechanism to determine which of the RemDevs support UPnP
services and/or profile requirements to enable UPnP service discovery
mechanism.
A device with Bluetooth wireless
communications may provide UPnP services using an L2CAP-based solution
and/or an IP -based solution. See Section 8.1 of the ESDP Profile for the
complete list of SDP service records defined for these alternative
methods.
Channel Types: Only connection-oriented channels
shall be used. In particular, no L2CAP broadcasts are to be used for this
profile.
Signalling: In the PSM field on the Connection
Request packet, the value used shall indicate the request for creation of
an L2CAP connection for accessing the UPnP protocol stack.
Configuration Options:
- Maximum Transmission Unit (MTU) :This
profile does not impose any additional restrictions to MTU beyond the
ones stated in L2CAP specification [2] or [3]. If no MTU negotiation
takes place, the default MTU value in L2CAP specification shall be
used.For effecicently, the MTU should be selected as large as
possible.
- Flush Time-out: The UPnP service
transactions are carried over an L2CAP reliable channel. The flush
time-out value shall be set to its default value 0xFFFF.
- Quality of Service: The use of Quality of
Service (QoS) and QoS negotiation is optional. If QoS is to be
negotiated, the default setting shall be used. In particular, UPnP
service traffic shall be treated as best-effort service type traffic.
Connection Management: L2CAP
provides a reliable channel using the mechanisms available at the Baseband
layer. However, currently L2CAP does not exercise flow control to prevent
data buffer overflow nor does it enforce a reliable channel to ensure data
integrity. The purpose of the connection management layer is to provide a
reliable connection service between peer-to-peer applications using a
connection-oriented L2CAP channel
Data transmissions are classified into 2 categories,
information and control.Data transmissions classified as information are
the actual information-carrying PDUs .Data transmissions classified as
control are used by a device to advertise its receive window size to the
peer transmitting device and they are used primilarily for peer-to-peer
flow control and error recovery.
- Number of Connections: The number of
connections for UPnP services between a pair of peer devices must be
limited to 1 during any particular period of time. In addition,
different UPnP enabled services between the particular pair of peer
devices shall use the already established connection or establish a
connection if one does not already exist, in either of the two
scenarios, the number of connections for UPnP services between the
pair of peer devices is limited to 1.
- Byte and Bit Order: The byte and bit
ordering when defining a connection management PDU and its fields must
use the Little Endian format, with less significant (lower-order)
bytes and bits being transferred before more -significant
(higher-order) bytes and bits.
- Protocol Data Unit Format :The connection
management PDU consists of a PDU header followed by optional data
payload as shown below. The PDU size shall be the minimum supported
MTU for connection-oriented L2CAP packets (MTUcno) negotiated during
L2CAP channel configuration. Note that the negotiated MTUcno for an
established L2CAP connection must be greater than 4 bytes ; else, the
connection management layer terminates the L2CAP connection and
indicates a lack of L2CAP communication resources to the higher layer.
Image reprinted from Bluetooth ESDP Profile, Figure
9.2 , page 42
- Segmentation and Reassembly: Segmentation
and reassembly (SAR) is used to support the peer-to-peer message
exchanges over a connection management layer.
- Flow Control and Error Recovery for Data PDUs: Data
PDU transmissions must use a go back n ARQ protocol with a
modulus of 256 (2 for an 8-bit Sequence Number) for peer-to-peer flow
control and error recovery
- Flow Control and Error Recovery for Window Size Control
PDUs: The flow control and error recovery mechanism for
the Window Size Control PDU transmissions is based on the ARQ protocol
similar to the mechanism described for Data PDUs above. However, there
are differences between the ARQ protocol implementation and ARQ
protocol implementation for Window Size Control PDUs.
Mapping of HTTP Messages to L2CAP
HTTP messages are mapped on to the L2CAP layer via
the intermediate connection management and the multicast emulator layers.
The connection management layer may directly receive HTTP messages with 2
types of schemes, standard HTTP and HTTPU. The connection management layer
may also indirectly receive HTTP messages with HTTPMU scheme from the
multicast emulator layer.
A connection management layer provides peer-to-peer
connectivity over a connection-oriented L2CAP channel. The connection
management layer transfers the higher layer unicast point-to-point message
using either the standard HTTP or HTTPU schemes over a connection-oriented
L2CAP channel between the device originating the message and the
destination device with Bluetooth wireless communications. If the
connection management layer has already established an L2CAP connection
between the peer devices, then the higher layer message is transmitted
over this connection. However, if an L2CAP connection between the
connection management layers of peer devices does not exist, the
connection management layer establishes a connection-oriented L2CAP
channel between the peer devices. Subsequently all message exchanges
between the peer higher layers are transacted over the established
connection.
The connection management layer cannot directly map
higher layer multicast point-to-multipoint message using HTTPMU scheme
since the underlying connection-oriented L2CAP channel only provides
point-to-point connectivity.The multicast emulator layer, in between the
HTTPMU layer and connection management layer maps the point-to-multipoint
message into multiple unicast point-to-point messages, one per each
destination device and transfers them to the connection management layer.
UPnP Service Transactions and L2CAP Connection Lifetime
Since HTTP transactions comprise a sequence of
service messages that constitutes a connectionless datagram service, no
connection is made prior to the peer-to-peer HTTP message exchange. The
UPnP service application delegates the creation of connection on its
behalf to the connectionmanagement layer and also has the responsibility
to request the L2CAP layer to establish and terminate the connection on
its behalf. Note that there is no signalling between the UPnP service
application and the connection management layer. The receipt of data from
the higher layer initiates establishment of connections by the connection
management layer.
Since HTTP transactions are considered stateless,
terminating an L2CAP connection after a UPnP service message is sent will
be detrimental to UPnP service transaction. Moreover, a significant
performance penalty will have to be paid if, for each UPnP service
transmission, a new L2CAP connection is to be created. Therefore it is
suggested that the L2CAP connection for UPnP service messages shall last
more than the transmission of a single UPnP service message.
This profile scenario does not
impose any additional requirements on L2CAP connections other than those
required by PAN/LAN profile.
This profile scenario does not require TCP/UDP/IP
services.
The set of IETF RFCs required for communication are
classified into two categories depending on whether the network layer is
based on IP Version 4 or IP Version 6.See section 10.2.1 of the ESDP
Profile for full details.
The set of IETF RFCs required for communication are
classified into two categories depending on whether the network layer is
based on IP Version 4 or IP Version 6.See section 10.2.2 of the ESDP
Profile for full details.
As noted above, bridge devices per se are outside the scope of this
profile.However, because bridge devices are relevant to a discussion of
the ESDP for UPnP, this informational appendix is supplied.
The Bluetooth bridge device shall interact with
other devices with Bluetooth wireless communications as yet another
piconet member. Since devices may provide UPnP services using an L2CAP
-based solution and/or an IP-based solution, they may communicate with
other devices within their piconet irrespective of whether or not a bridge
device exists within the piconet. The bridge device is primarily intended
to enhance the functionality of devices within a piconet by extending
their reach in service discovery and device control beyond their piconet.
Additionally, the bridge device may also manage UPnP
services based on device/user access lists. Management of UPnP services
based on device/user access lists enables the delivery of customized
services to the users and devices with Bluetooth wireless communications
while potentially improving the Bluetooth wireless bandwidth utilization.
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.
|
