It's crunch time in the automotive manufacturing market. With regulators pushing hard to pass legislation mandating handsfree operation in autos, manufacturers need to provide handsfree systems in future car designs.
Bluetooth could hold the key for making these handsfree systems come to life. By implementing Bluetooth chip or module technology along with a handsfree profile, auto manufacturers can implement a handsfree system in future car designs without the need for pesky wires. Here's how it works.
Getting a grip on the profile
The basic system architecture of a Bluetooth-enabled handsfree system has one controller or 'master' that is responsible for controlling up to 7 'slave' units in a configuration called a piconet. In the handsfree profile, only one active phone call at a time is allowed implying that only a point-to-point connection should be supported. In fact, this is not entirely accurate. Multiple cell phones, or audio gateways, can be connected to a handsfree device concurrently, yet only one phone can be in an active conversation. In this situation, the handsfree device serves as a master device, controlling the physical connections to all cell phones present in the car.
As shown in Figure 1, the client device can be either the handsfree device (HF) or audio gateway (AG). It initiates communication with the server at the application layer only. It is important to set the server device up correctly in terms of configuring it as is shown in the figure. In this figure, the radio hardware is shown to be initialized to be discoverable and connectable. In other words, it will respond to Inquiry messages and allow other devices the ability to establish a physical layer connection.
Click here for Figure 1
Figure 1: Configuring the server device correctly is mandatory when developing a handsfree profile for automotive applications.
The security module is configured to trigger authentication, authorization and encryption when a connection request is made to establish a peer-to-peer connection at the RFCOMM layer. This is shown in the figure by a connection that is made between the Security module and L2CAP.
The service discovery database must be populated with relevant and necessary information regarding Bluetooth services offered as well as the required protocol in supporting the application layer. RFCOMM Port #4 is identified as the port to use when accessing service. Proper server configuration is necessary.
Peeking at the Protocol
Figure 2 illustrates the handsfree protocol employed in automotive designs. At the physical layer, a unique Bluetooth specific address is used in messaging between devices in a way similar to the way the Ethernet MAC address is used. At the L2CAP layer, a channel ID (CID) is assigned to both sides of the link allowing multiple connections to exist between one device, the master, and multiple slaves.
Figure 2: Required protocol connections in supporting handsfree service
A protocol service multiplexor (PSM) identifies the module to which incoming data packets are routed to above the L2CAP layer. The security module in this example was shown to trigger after the L2CAP layer established a peer-to-peer connection prior to an RFCOMM connection being created. This is defined as being 'mode 2' security' in Bluetooth parlance.
Mode 2 allows the security mechanism to be assigned to trigger at any one of several places in the stack. The security mechanism triggers at the following protocol layer:
- L2CAP
- RFCOMM ( L2CAP layer, PSM = 0x0003 )
- TCS (wireless telephony / intercom module)
- SDP (Service discovery module)
- BNEP (Bluetooth Network Encapsulation Protocol level)
- Application layer
These trigger points are set during the initialization of the service database; the data entity governing the behavior of the security function. As is shown in Figure 1 above, the security module is set to monitor all connect activity at the L2CAP, PSM value = 0x0003. This corresponds to the service access point though which messages are sent to the RFCOMM module.
Security is key
Security is very important for the handsfree profile since it is the mechanism that is responsible for linking a specific cell phone (or set of cell phones) to a single handsfree device. This is what prevents the handsfree device from communicating to other cell phones that may reside in the car next to you at a stoplight.
Operationally, Figure 3 illustrates where security measures are initiated--when the protocol stack is invoked up to and including the RFCOMM module. Generally speaking, all layers of the stack are established when a service level connection is requested at the application layer - but more on this later.
Figure 3: State machine showing sequence of activity traversed to prepare for the handsfree profile.
Figure 3 illustrates three different phases that are traversed in order to facilitate a single phone call. This will provide an example that is useful in explaining the steps required. Let us assume that a Bluetooth enabled cell phone, capable of serving as an audio gateway comes into the vicinity of a handsfree device in your car.
The handsfree device could be periodically sending inquiry requests out with the intention of identifying other Bluetooth devices that are within communications range--this generally being 30 feet. The cell phone, upon receiving an inquiry message (and being configured to be discoverable), will respond with its unique Bluetooth address. The handsfree device, using this address, makes a request to connect to the cell phone and if configured as connectable and if the application accepts this connect request, a radio connection is created.
The handsfree device becomes the 'master'. It performs a service discovery function, determines that the cell phone is capable of supporting handsfree profile and that RFCOMM port #4 is the port with which to connect in gaining access to this service (figures 1 and 2). The RF connection can now be maintained in expectation that it will be used in support of the handsfree service profile.
The first time the profile is invoked, a unique sequence of events occurs. The L2CAP layer is established and then security triggers when the RFCOMM layer attempts to create a connection.
Once security is triggered, the process of authentication is started which proceeds transparent to the end user. Authorization also completes and encryption is started on the link between devices. This procedure will proceed without any user intervention only if some level of setup has occurred before the application is actually put into use. Pairing and bonding must have been completed and this is done prior to using the handsfree profile.
Automakers challenge
Auto manufacturers have the responsibility of making this event very easy since consumers do not want to read manuals. Basically, when the handset device and the cell phone are introduced to each other for the first time, an identical personal ID number (PIN) must be entered into both devices and pairing is completed. This information is then used to pass authentication and a unique link key is created and stored for future use, eliminating the need to re-enter the PIN again in future sessions when security is triggered. Only the cell phones that have been bonded to the handsfree device in this manner will pass security, all others will be asked for a PIN, restricting access to the handsfree device.
Completion of the security procedures allows the application to establish a service level connection, this being the beginning of the handsfree application profile. The handsfree profile can then provide its basic service of supporting phone conversation as well as a variety of other functions, which are outlined in Table 1.
Table 1
| Feature |
Description |
| Dial Number |
HF device commands the AG to dial a specified number |
| Memory Dial |
Provide the AG with a memory location and it will dial the number in that location |
| Hold Call |
Places the current call into hold mode as supported on the AG |
| Caller ID |
Enables and disables caller ID on the AG (if supported) |
| Generate DTMF |
Sends a DTMF tone during a call |
| Redial Last Number |
Redials last number called on the AG |
| Enable/Disable Voice Recognition |
Voice recognition enabled / disabled on the AG if supported by the cell phone |
| Enable/Disable Call Waiting |
Call waiting enabled / disabled on the AG if this is supported by the cell phone |
| Enable/Disable Echo Canellation/Noise Reduction in AG |
Self explanatory, if supported on the AG font> |
A signaling channel is used in conveying important messages between handsfree device and the audio gateway. An additional audio channel is assigned in response to messaging on this signaling channel. Audio is used in supporting voice as well as what is called in-band signaling, better known as the ringing sound you hear when attempting to connect to the other side.
Other functions that are supported on the audio gateway can be enabled from the handsfree unit via commands sent to the AG.
With the initial bonding process completed and the handsfree device being linked with the cell phone, subsequent calls are managed differently. Figure 4 illustrates the procedure followed when setting up an incoming call coming through the audio gateway.
Figure 4: The audio gateway or handsfree can assume the client or server role.
Initially a connection at the physical layer needs to be in place. This is usually done automatically by either the handsfree device or the audio gateway when they come into proximity of one another. It may be beneficial for the handsfree device to periodically send inquiry messages out to determine if cell phones are within range since they have a power source that offers much greater longevity - the car battery. Alternately, the cell phone can be instructed through user intervention to proactively establish an RF connection with a handsfree device that is within range. The assumption is that both units have been bonded.
An RF connection is then maintained as long as both devices are within close proximity. Next, the application invokes a service level connection, which allows the AG to send to the HF device status information. Information sent includes:
- whether the AG is in-service or out-of-service
- if the AG is already in a call or not in a call
Successful connection implies that the full protocol stack has established peer connections and security has passed. With an incoming call, the AG uses the signaling channel to send the sequence of messages
as shown in Figure 4 above.
A ring message is sent informing the HF device that a call is being made to the AG; the HF device generates an audio tone to alert the user to the call. The user responds by acknowledging the call resulting in an answer response. The connection is completed by the AG, call status is updated and sent to the HF unit for display, and an audio channel is created. Voice traffic is then passed over this two-way channel; the quality of which is as good as that experienced in a normal phone conversation.
Concluding Thoughts
The power of Bluetooth communication is in its use of power; its greatest benefit is its ability to consume very little battery power making it very attractive for use on cell phones. Enhancing this ability is the implementation of "park" mode that can be used in the handsfree implementation, putting the handsfree device into a dormant state. Terminating the RF transmission originating from the cell phone in this mode significantly reduces power required by the slave unit that is parked.
Implementing the handsefree profile should be a straightforward exercise. The Bluetooth protocol stack provides a simplified API that will allow designers to port the profile quickly to their handsfree system architectures.
Brian Senese is a field application engineer at Extended Systems. He is the author of two books Bluetooth Application Developers Guide and Managing Successful High-tech Product Introduction . Brian holds and M.E.Sc from the Unoversity of Western Ontario, Canada and can be reached at brian.senese@extendedsystems.com.
