Bluetooth Access Points and Profile Specifications: Descriptions and Recommendations

The objective of this document is to provide a concise technical reference of the various existing and new Bluetooth profiles available from the Bluetooth SIG. Special emphasis is given to the relevant profiles that are necessary for an architecture implementing Bluetooth network access points.

Additionally the document includes a discussion on possible modifications and adjustments to some of the new profiles under development at the time of writing this report. This is a summary of the outcome of the study carried out by the various P1118 partners.

The profiles have been developed in order to describe how implementations of user models are to be accomplished. The user models describe a number of user scenarios where Bluetooth performs the radio transmission. A profile can be described as a vertical slice through the protocol stack. It defines options in each protocol that are mandatory for the profile. It also defines parameter ranges for each protocol. The profile concept was used to decrease the risk of interoperability problems between different manufacturers' products.

The Bluetooth profile structure and the dependencies of the profiles are depicted above. A profile is dependent upon another profile if it re-uses parts of that profile, by implicitly or explicitly referencing it. Dependency is illustrated in the figure: a profile has dependencies on the profile(s) in which it is contained – directly and indirectly. For example, the Object Push profile is dependent on Generic Object Exchange, Serial Port, and Generic Access profiles.

This chapter describes briefly the main features of the existing profiles (Bluetooth Specification V1.1, 22/02/01) that have been judged relevant to the implementation of Bluetooth Access points.

As already stated, what follows is a short description of the main features of some of the profiles described in the Bluetooth specification. The aim is to give the reader a broad understanding of what are the features that the various profiles may enable on Bluetooth devices. More detailed descriptions can be found in the Annex where the full documents produced by each partner throughout the duration of this task are enclosed.

The Generic Access Profile defines the generic procedures related to discovery of Bluetooth devices and link management aspects of connecting to Bluetooth devices. It is the core on which all other profiles are based and its main purpose is to describe the use of the lower layers of the Bluetooth protocol stack. This profile describes the general procedures that can be used for establishing connections to other Bluetooth devices that are in mode that allows them to accept connections and service requests.

The Service Discovery Profile (SDP) allows Bluetooth devices to discover which services are present on other Bluetooth devices they are connected to, and to retrieve information relevant to those services. The way this is performed is by having the service discovery user application in a local device interfaces with the Bluetooth SDP client to send service inquiries and receive service inquiry responses from the SDP servers of remote devices.

This profile defines the requirements for Bluetooth devices necessary for the support of the intercom functionality within the 3-in-1 phone use case. The scenarios targeted by this use case are typically those where a direct speech link is required between two devices (phone, computer, …), established using telephony-based signaling. A typical scenario covered by this profile is the one of two (cellular) phone users engaged in a speech call, on a direct phone-to-phone connection using Bluetooth only. More popularly, this is often referred to as the ‘walkie-talkie’ usage of Bluetooth.

This is perhaps the most important profile in any of the four Access Scenarios considered in the above architecture, as it provides the Bluetooth device with the opportunity of using the traditional applications relying on a TCP/IP stack. The LAN access profile specification defines how Bluetooth–enabled devices can access the services of a LAN using PPP. Additionally it shows how the same PPP mechanisms are used to form a network consisting of two Bluetooth-enabled devices.

The LAN Access profile enables Bluetooth devices to connect wirelessly to a nearby LAN (e.g. Ethernet, Token Ring, Fiber Channel, Cable Modem, Firewire, USB, Home Networking). The connection is provided by means of a LAN Access Point (LAP). The LAP provides the services of a PPP Server while the Bluetooth terminal is the PPP client. The PPP connection to the LAN is carried over RFCOMM. RFCOMM is used to transport the PPP packets and it can also be used for flow control of the PPP data stream.

The LAN Access point can be used in one of three modes, namely:

• A dedicated personal Access Point: Here the LAN Access Point is used to access a network via a personal secure point to access email, corporate LAN or Internet. This mode has the advantage of exclusive use of access point in own work space freely and without being wired.
• Shared Access Point: Here the LAN Access Point is placed in a common room (e.g. meeting room) to be shared among a number of users. Access can be limited using PIN codes.
• Public Access point: Here a number of LAN Access Point are wired together to allow access to a larger number of users in open areas e.g. airport, shopping mole, etc. In this set-up the access to information based services is facilitated e.g. local advertising of services. It is important to note that Access Points located in shared areas provide either open or secure access. Secure access must be provided by a separate IDs or PINs.

The configuration of the LAN Access Point will clearly depends on the mode of operation required. In this project the third operation mode has been investigated in more detail as it defines the necessary configuration requirements for both the open and secure public access (see Appendix for details).

The LAN access profile is one member of the Bluetooth networking profiles group that in turn includes the dial-up networking and fax profiles. It is important to notice that all these profiles include an element of access to either a local area or a wide area network for data communication.

The Object Push profile defines the requirements for applications providing the object push usage model. Typical scenarios covered by this profile involve the pushing/pulling of data objects between Bluetooth devices

This profile is used in conjunction with the GOEP (Generic Object Exchange Protocol) to send and receive small objects. Example would be the exchange of electronic calling cards.

This chapter describes the new Bluetooth profiles currently being implemented and focuses on strengths / weaknesses of the specifications for those profiles that are relevant to the Bluetooth implementation of Access Points.

It must be noted that most of the following profiles were still under development at the time of writing this report and a more detailed description can be found in the Annex.

The Bluetooth Service Discovery Profile (SDP) enables Bluetooth devices to determine services of other devices within the realm of a Bluetooth system. This means the SDP limits the discovery of services to active devices in a Piconet. The Extended Service Discovery Profile Working Group therefore aims to develop Bluetooth profiles that provide mappings of industry Service Discovery Protocols over Bluetooth. These mappings shall be discovered via the Bluetooth Service Discovery Protocol (SDP). ESDP will enable Bluetooth Devices to discover services beyond the realms of a Piconet. UPnP was the first profile to be adopted and published as a draft to all members of the Bluetooth SIG.

UPnP (www.upnp.org) is a service discovery protocol on top of common technologies like TCP/IP, http and others enabling the seamless and media independent device connectivity and control.

This profile is very relevant to Public Bluetooth access as well as private and semi- public access, because it enables an easy interaction with a wide range of service offerings for end- users. Furthermore it eases the integration of service offerings in public places for service providers.

The work of the Extended Service Discovery Profile Working Group, greatly enhances the integration of Bluetooth into a service infrastructure, where every service gets discoverable via standardized protocols, which not necessarily belong or are restricted to Bluetooth. The results of the Extended Service Discovery Profile Working Group may greatly enhance the usability of Bluetooth as an access technology and therefore help to establish Bluetooth Public Access as a vital part of future telecommunication and networking infrastructures.

There may be a need to give feedback to the Extended Service Discovery Profile Working Group to ensure that the standardised names/categories for services can reflect the fact that some services are being offered for free, while some are to be paid for, etc.

Very briefly, the Personal Area Networking (PAN) Profile allows ad-hoc IP networking between Bluetooth enabled devices in a piconet and external networks via a Network Access Point (NAP).

The main purpose is to ease communication between applications on a user’s personal devices. Many electronic devices are now easily portable or even wearable, and a PAN could exploit the proximity of such devices allowing them to communicate over a wireless network.

For example a single I/O interface in a PAN could potentially control many local devices, such as mobile phones, PDAs, and MP3 players. As a result new user conveniences and services could become feasible.

The PAN profile in Bluetooth describes how a number of Bluetooth-enabled devices can form an ad-hoc network, and also how such a network would communicate with a network access point. The current version of the profile is Phase I.

The main protocol considered for this profile is IP. That is why the PAN profile is usually considered as an enabler of IP-based networking for participating devices. Because of this, it is one of the most critical profiles for both private and public Bluetooth Access.

The PAN profile is very relevant to Public Bluetooth access as a whole, as it would enable greater service offerings to end-users and increase user convenience in accessing services over their Bluetooth-enabled devices.

The concept of the Network Access Point (NAP) maps nicely to our idea of the Public Bluetooth Access Point.

• A basic set of required configuration settings should be included in the PAN profile, besides the common IP information. This is needed because of the nature of the Personal Area Networks requires some extra information, such as device number within the PAN, this will really help and simplify the implementation of new applications.

• In order to take advantage of all the new type of applications that could be enabled by the use of the PAN profile in the context of ad-hoc IP networking, a basic set of synchronisation, and re-synchronisation guidelines should be included in the PAN profile, because the PAN network may not have an always connected characteristic that is required by many IP-based applications. Such guidelines might include, how often a device needs to check for synchronisation, how long between disconnections should they check for synchronisations, etc.
• The mobile gateway use case would be very difficult to implement given the lack of programmability on mobile terminals, the possibility of using a mobile phone not only as a modem but as gateway with networking and routing capabilities will need to be standardised within Bluetooth and adopted by most vendors in order to succeed.
• The PBAP authentication mechanism is the most relevant feature of the PAN profile for a PBAP access scenario, and the concept used in the PAN profile is very consistent and points in the same direction to the PBAP concept of this project. The PBAP plays the role of a NAP. We add the authentication mechanism on top of the existing PAN specification, and allow access for the multiple devices in the PAN by sending the information on all devices when the first device authenticates itself.

The SIM Access Profile addresses the problem of personalizing a car embedded phone using a mobile phone brought into the car. The car embedded phone will therefore use the subscription data stored on the SIM card located in the mobile phone via Bluetooth. Car embedded phones usually offer more efficient RF- engines, high quality hands-free and voice recognition capabilities and a special design perfectly integrates into the car.

The relevance of profile for public Bluetooth access in its current status is rather marginal. However, when the restricted mode of operation is removed from the profile specification, a number of applications may benefit from this and therefore the relevance of the profile for public Bluetooth access may become quite high.

Applications may be:

• authentication of users who want to use the public Bluetooth access infrastructure via their mobile phone for billing and accounting purposes
• use of the SIM as a trusted device to compute e-signatures and other security relevant operations

The project should try to influence the car working group to incorporate the proposed changes into the SIM Access Profile for two reasons:

1. This would pave the way especially for public access by enabling convenient user authentication and other security related operations
2. When the profile in its current status is approved, mobile phone vendors will implement it as is and the chances for the incorporation of the mentioned additions will become quite negligible.

The Hands-Free Profile outlines a series of messages and procedures that allow the user to interface the Bluetooth device built in the car with the cellular phone in an automatic way. This specification is particularly aimed at drivers and enables them to use their mobile phone without taking their hands off the wheel and exclusively with the help of voice commands.

In more generic terms, the Car Working Group Charter Usage Models reveals that a Car Profile essentially should allow for two types of services:

1. services delivered to the driver or a passenger in which case the car would be a sort of semi-public access point (hands-free telephony, mobile Internet access etc.);
2. services which are car-specific (car maintenance logs, diagnostics, fleet management etc.).

The Hands Free profile could have some relevance for the Public Bluetooth Access as it is essentially making the car look like a mobile semi-public access point. In addition to the services enabled by the car profile, other functional blocks such as authentication and billing "boxes" could be exploited in this project. These functional blocks will enable the car manufacturer to provide a comprehensioveBluetooth infrastructure for the car.

The Printing Profile will provide Bluetooth devices the capability to discover the presence of nearby printers and give the user the opportunity to print documents from his mobile devices (laptop, mobile phone, PDA) as well as from his wired devices (e.g. desktop).

If Bluetooth is used only as cable replacement within offices then one can imagine that relevance of this profile for Public Bluetooth Access is limited. However scenarios where printing is a service that the user is charged for upon usage, may not be uncommon in the future. This implies that print servers may need to interface with billing engines and allow printing to be deployed as a separate add-on service available e.g. in public hotspot Bluetooth access points.

Non-standardised products already exist in the market however it is envisaged that wireless printing will be one of the most needed applications for mobile users and a wide range of printing solutions should emerge once the Bluetooth Printing Profile is published.

The Local Positioning profile defines the protocols and procedures that shall be used by Bluetooth devices implementing the following usage models:

• Position determination
• Location awareness

Position refers to a numeric description within a coordinate system, whereas location refers to information about surrounding objects and their inter-relationships. Because Bluetooth uses a relatively short-range radio, devices at unknown positions can estimate their positions by proximity to devices with known positions.

The specification defines the data transfer mechanism and related data formats. The SIG BLT-WG is investigating a suitable compact algorithm for LP use, and a decision on whether to licence this will be made in due course. The minimum mandatory requirement is for LP-compatible clients to locate, select, and pull LP data (16-byte payload containing co-ordinates plus associated accuracy and confidence) from LP-compatible servers. If the server does not know its position accurately, it can degrade the accuracy to up to 1800 km and/or it can degrade its confidence to 0% (position undefined).

LP devices may act as both clients and servers.

The profile is designed to be compatible with Bluetooth 1.0 and 1.1 devices and to provide enhanced performance with future Bluetooth 1.x devices, incorporating improvements to the Bluetooth core specification.

As for Public Bluetooth Access, this seems to be a strategic profile, because it enables a very strong interaction (theoretically uninterrupted) between a user and his local environment with many potential benefits for telco operators.

The following information is extracted from the charter of the Radio2 Working Group dated 8^th June 2000.

The objective of Radio2 Working Group is to improve radio 1.0 concerning radio, baseband and Link Manager Protocol specification. A gross rate of 2 Mbit/s and a high-rate mode with at least 10 Mbit/s is striven for. The overall goal of positioning Bluetooth as the low cost, low power, world-wide available PAN targeted for mobile consumer electronics should not be compromised for performance (range and rate). A throughput as good as possible for cost-effective, small, battery powered consumer devices should be achieved.

Radio 2.0 will influence quality and time consumption and therefore the acceptance of a lot of services to be offered in public access points.

The work and the results of this working group should be observed in detail. Since it seems that this group doesn’t concern security or access issues, an influence by P1118 is not necessary.

The following description is extracted from the charter of the Coexistence at 2.4 GHz Working Group dated 25^th June 2000.

The Bluetooth radio occupies spectrum which is unlicensed and therefore shared with other wireless equipment and accompanying standards. The Coexistence working group will address the issues of coexistence between Bluetooth and other equipment sharing the common radio band.

In public areas, several network access points using WLAN (82.11b) and Bluetooth technology are likely to coexist. Therefore a large number of equipment operating in the 2.4 GHz ISM-Band must be expected. tThe rules, advice and hints available from this working group should be followed to guarantee the success of Bluetooth Public Access commercially.

As soon as released, the results and advice of this working group should be regarded in detail concerning the hot spot and public scenarios.

The draft specifications V0.95 consists of 5 parts: Generic Audio/Video Distribution Profile (AV GAVDP), Advanced Audio Distribution Profile (AV A2DP), Audio Video Remote Control Profile (AV RCP), Audio/Video Distribution Transport Protocol (AV DTP) and Audio/Video Control Transport Protocol (AV CTP). It must be pointed out that Video Distribution Profile is still under development at the time of writing this report.

The Audio/Video Distribution Transport Protocol (AV DTP) and Audio/Video Control Transport Protocol (AV CTP) are two new fundamental layers added to the original Bluetooth protocol layers to negotiate, establish, transmit and control A/V stream. The other 3 profiles sit on top as application layer in order to deliver audio/video stream to users.

As and when they will be available, the devices including these profiles will have, in the short term a limited use in the public hotspot, see the usage examples listed in the corresponding section of the appendix. However a wide usage in the PAN configuration, offices and certainly homes, is envisioned.

For public access, it is believed that the current profiles need to be extended/modified/integrated to allow a central device configured with the audio and video distribution profiles to be remotely controlled by another Bluetooth device e.g. PDA in order to download music/video to a headphone/VCR for example. The central device can be a Bluetooth audio/video server with a LAN access profile so it can also be a client to another application server at an ISP location.

The profile is currently in a draft state awaiting review responses. A stable specifications is likely to be available sometime next year (2002).

This profile defines the requirements necessary for Bluetooth™ devices to support the Basic Imaging Profile usage models. The requirements are expressed by defining the features, functions, and underlying profiles which are required for interoperability among Bluetooth devices in the Basic Imaging Profile usage models. This profile does not mandate that either the server or the client enters the discoverable or connectable mode automatically even if they are able to do so.

Examples of the usage of the profile would be: using a PC to browse the set of pictures on a digital camera, sending images to a projector from a laptop, sending an image to a mobile phone for forwarding, etc.

The relevance of this profile for Bluetooth Access is that it widens the number of features and services than can be offered over a Bluetooth device. The simple transfer of files is not enough for the exchange of images as the quality and size of this type of files requires an optimisation of the transfer mode. In the same way that short messages are exchanged in today’s mobile phones, the availability to retrieve images in public places as well as residential areas using a Bluetooth Access Point will be one of the key areas to make a success of Bluetooth-based services. Some examples of specific services which might be offered at PBAPs are:

• Users can have picture taken of themselves with in-built camera in PBAP and transfer them to their device.
• Images of the PBAP location can be offered to anyone with a compliant device.
• Pictures of users can be altered (e.g. with humorous background) and transferred to user.
• Colour printing can be offered
• Images can be sent on, in email format or transmitted by EMS/MMS (i.e. possibly cheaper than by GPRS/3G)

This profile should not be considered until the devices are available, the specifications version from which this description was extracted is still in a draft phase. However, in the long term the use of imaging-based services and applications using this profile has to be considered, the required infrastructure is not yet in place to be considered at this stage. The standardisation process is in a review phase so trying to make any substantial change in the profile description falls out of the scope of this project.