The variety and diversity in the range of vehicles on the marketplace today is incredible; manufacturers constantly tempt us with cost-effective finance schemes, along with handsome options for additional features. Automotive industries continually strive to incorporate better and more luxurious features into their range of models, increasing the gadget-factor and, as such, tempting potential new owners into purchasing their vehicles. The high-end, more luxurious vehicles continually struggle to compete with lower-end vehicle packages, as these nowadays find themselves technically on par with the higher-end range. With the introduction of Bluetooth-enabled applications and its low-cost attraction, it would seem that both-end vehicle market ranges would also benefit from another gadget: wireless technology. Indeed, some major manufacturers have already announced their intention to incorporate Bluetooth technology. It is open and widely available and, in turn, three new car-specific profiles have been introduced.
The number of car profiles currently under development comprises the Hands-Free, Phone Access and SIM Access Profiles. Each profile addresses specific functionality enabled within the vehicle environment; we discuss this in more detail in the following section.
This section now considers both existing and future usage models through scenarios that may be typical for the Car Profiles, as illustrated in our introduction. We begin by exploring the existing models, where at face value the Car Profiles provide us with the ability to combine our Bluetooth-enabled mobile phone with hands-free or in-car embedded Bluetooth units. In future usage models, we consider other usage scenarios that lend themselves quite well to the diversity of these new profiles.
In exploring our existing usage models, we compare each profile; as such, we clearly demonstrate their differences and specific usage cases. However, before moving on to discuss the range of possibilities, we need to consider some safety aspects of using these features in a moving vehicle. The immediate two sections that follow help us understand what considerations should be made and when exactly the user should be allowed to operate such devices.
The exploration of the usage models takes into consideration the safety requirements and common sense that drivers should apply in their vehicles. It is assumed that appropriate safety measures have been integrated within the car environment to ensure driver and passenger safety which, in turn, will have a positive effect upon fellow road users and pedestrians. Current research in the United Kingdom places the same emphasis on using a mobile or hands-free device as driving when over the legal alcohol limit. However, attempts at enforcing a ban on using a hands-free device, for example, have recently been thwarted. Officers are unsure if a driver is using a hands-free device or just singing along to music. Nonetheless, if legislation is drafted enforcing new laws that make it illegal for any type of device to be operated in a vehicle, vehicle manufactures will be forced to consider alternative methods of in-car communication.
Safety is paramount in a moving vehicle and the temptation to peruse your calendar or other mobile-menu specific items on your in-car display unit is clearly a serious distraction and potentially dangerous. The increase in voice-activated functionality would help alleviate the distraction from the road to your in-car display unit, as would an incorporated microphone and speaker system, which are indeed becoming more common. Voice announcements would equally lend themselves well to incoming call notification. [1] If a caller’s name is in the phonebook of the mobile phone unit, then an audible announcement of the caller can be made. Otherwise, a ring tone accompanied by an announcement of caller unknown or number withheld would also help keep the driver’s eyes firmly focused on the road. Similarly, using voice activated dialling would also help alleviate the fingering required to navigate through your list of names and numbers. In reducing the amount of time needed to bring the eyes down to focus on your in-car display unit, the more confident manufacturers can concern themselves with driver and passenger safety when they operate such devices.
Most mobile phone manufacturers provide the ability to configure a mobile phone for a particular operating environment. In this context, it refers to a specific configuration that meets with environmental needs. Such examples may include Silent, for discreet operation in a restaurant or Outdoors, where the ring volume needs to be a little louder, since the surrounding noise is a distraction. In-car configurations may be supported to allow the exporting of mobile phone or PDA-specific data for perusal within the in-car display unit and control by a button-operated steering wheel. Furthermore, the configuration would also identify what specific functionality can be operated by the in-car system, and therefore restrict the perusal of certain data. Using the Phone Access or SIM Access Profiles, a user would be able to select what specific data to export and perhaps limit the temptation to scan the names and addresses. Any calendar or reminder function can also be exported, but again using voice audible announcements rather than beeps, or the like. Such audible triggers can be used to uniquely identify the alert, which again would allow the driver to keep his or her eyes on the road.
One luxury automotive manufacturer inhibits the use of the vehicle’s extended menu functionality while the vehicle is in motion. That is, the menu can only be accessed when the vehicle has become stationary, such as at a set of traffic lights or during the more commonplace traffic delays. This restriction removes the temptation to play with your device while it is moving. Nevertheless, even while your vehicle is stationery, scanning the names and numbers still poses a distraction. This is because your eyes are not focused on the traffic ahead or indeed on the colour of the traffic lights. You may experience other drivers’ frustration as the driver behind beeps his or her horn to alert you that you need to move forward.
There has to be a satisfactory consensus on how we choose to develop and subsequently integrate this technology into our vehicles. Above all removing temptation, adding safety features and providing a satisfactory user experience are three key immediate considerations.
We see more and more in-car display units being integrated, providing on-board statistics such as average speed and average fuel consumption. The availability of this display unit lends itself quite well to the profiles illustrated in this chapter. Each will require the use of some output display, informing the user what activity or function they wish to enable or select. Furthermore, button-operated steering wheels are also commonly available. Extending the functionality to the steering wheel removes the need to reach for the centre console and change environment settings. Drivers already have the ability to change the volume level or select a track or disc on their integrated multi-CD player.
The Car Hands-Free Profile provides the ability for a user to enable their mobile handset to function with a hands-free kit within the vehicle. The hands-free unit may already be integrated into the in-car speaker and microphone system, thus allowing the user to accept incoming and make outgoing calls from the mobile phone handset. Figure 17-1 provides an illustration representing the scenario created by this profile. A hands-free unit may also interoperate with a Headset compliant product when no such hands-free kit is present. We talked in some detail about the headset usage models in our earlier chapter (see the Headset Profile, Chapter 7). The provision here is that the user has the ability to select either environment to make use of the mobile phone. You may remember that the user already has the ability to move audio functions from the mobile phone to the headset and vice versa; similarly, audio functions and control can be exported between the mobile phone and the hands-free car kit.
Figure 17-1. The new Car Hands-Free Profile enables mobile phone users to interoperate their devices with existing car hand-free kits, where the audio functionality has been integrated within the vehicle’s speaker and microphone system.
As we mentioned, the introduction of button-operated steering wheels and in-car display units is feasible as a means to control the function provided within your mobile phone, PDA or notebook. The Phone Access Profile allows you to export the functionality inherent within your mobile devices to your in-car system and Figure 17-2 provides an illustration, representing the scenario created by this profile.
Figure 17-2. The new Car Phone Access Profile follows from the Car Hands-Free Profile, where remote control capability, phonebook and possibly calendar access are exported to the in-car embedded system. These are provided by the button-operated steering wheel and in-car display unit.
In the final car profile, the SIM Access allows the downloading of SIM-specific data from your mobile phone or PDA to an in-car embedded unit and, as such, the vehicle would have its own integrated Bluetooth device. The advantage of this profile allows the user to occupy a company car and to be able to personalise it with their own configuration previously saved on their mobile phone. Similarly, any changes made within the vehicle can also be saved back into the mobile phone for later retrieval. Using your mobile phone as a keyless system would enable the driver to enter the vehicle. During his or her approach to the car, the vehicle would automatically detect their mobile device and begin downloading their in-car personality. It is also important to note that relevant billing information is addressed to the driver accordingly. Finally, Figure 17-3 provides the illustration representing the scenario created by this profile.
Figure 17-3. The new Car SIM Access Profile enables a user to communicate with the in-car embedded phone unit. Data such as the phonebook, as well as calendar information, can be exported. Other data, such as seat and mirror positions may also be saved within a mobile phone for later use in a company car.
The potential number of usage models is numerous, but at the same time we must consider all safety aspects imposed by the nature of a moving vehicle. Some functionality can be made available under certain conditions, as previously outlined. Functionality can be offered when stationary, although passengers may access some functionality when the car is in motion.
The use of a mobile phone as a keyless entry system to your vehicle is quite attractive; we introduced this concept in Section 17.2.3, Existing Usage Models. This is not just limited to a car, but the mobile phone can act as a keyless entry system to a variety of environments, such as the office or accessing a computer, although we are moving out of scope with these ideas for this profile.
In the PAN Profile: An Overview, Chapter 16, we introduced the concept of a mobile phone acting as a Network Access Point (NAP) and, as such, the ability for passengers to access the Internet or the corporate office is a seamless and natural extension to our in-car personality. As we previously described, such technologies as General Packet Radio Service (GPRS) network or a Universal Mobile Telecommunications Service (UMTS) network may exist to provide a permanent connection, although a charge is imposed according to the amount of data transferred. The Dial-up Networking Profile, Chapter 8, may also be part of the profile already supported by the mobile phone and, as such, this may be an alternative and cheaper solution. Providing such networking capability within the car must be used safely; clearly, the driver would not be able to use such functionality. However, passengers with appropriately enabled Bluetooth devices can use such facilities.
A more adventurous usage model for Bluetooth devices within the vehicle environment is to provide the ability to configure certain personality characteristics. Bluetooth Driver Personalities (BDP) would allow you to provide other interested drivers, within suitable radio range, with your individual information, physical characteristics and other interests.
A more pragmatic use, aimed at the more safety conscious audience Bluetooth-enabled in-car units would provide the ability for police traffic enforcement units to interrogate the vehicle, where your current speed may be requested and whether the vehicle is insured and serviced. The provision here is that the driver has enabled such a feature and has openly allowed the car to be interrogated in this manner. People who demonstrate repeated traffic offences may find themselves having such a unit enforced upon them.
Taking this one step further, in areas where your speed is an important observation, such as in close proximity to a school, Bluetooth speed units may be installed and your car, and subsequently the driver, informed of the speed in the area. Furthermore, the driver has configured his car to operate at the speed governed within the area and, as such, the car accommodates the new speed limit whilst the vehicle remains under the driver’s control.
A more obvious usage model is the ability to interrogate a car when it is brought into a dealership for a regular service or when the car has a problem. Diagnostic and service-related data is passed onto the technician who can quickly identify any problems. This can also be extended to racing car technicians who need to diagnose quickly the problems that the car may have.
A convenient use of in-car wireless systems is to provide automatic access to home garages, allocated parking spaces or entry systems and public use parking areas, where a subscription has been previously paid. Similarly, toll bridges may also benefit from automatic wireless entry systems with the provision of a valid Bluetooth ticket.
This chapter addresses three new car profiles. We introduce a breakdown of the three profiles into their respective sections and cover the typical components, such as Profile Principles and User Expectations, which we have already become familiar with in previous chapters.
The Hands-Free Profile provides two new roles: an Audio Gateway (AG) and a Hands-Free unit (HF). The HF device may already be installed as part of the in-car hands-free kit, where it is configured to use in-car audio functionality that extends to the speaker and microphone system. The AG provides full duplex audio support, where such devices include a mobile phone. In Figure 17-4, we can see how the new Hands-Free components are integrated with the existing Bluetooth protocol stack.
Figure 17-4. The components of the Bluetooth protocol stack are shown, illustrating the newer components of the Hands-Free Profile.
The profile defines a set of protocols and procedures, which are required to realise the profile implementation. Support for one Synchronous Connection Oriented (SCO) audio link is provided and, as such, only the two participating devices can operate at any one time. The profile mandates support for audio CODECs, [2] where the resulting audio is monophonic and has a data rate of 64 Kb/s, although no obvious degradation should be observed.
In Figure 17-5, we provide a conceptual illustration representing the dependencies that make up the Hands-Free Profile; the areas that are shaded are relevant to this profile. As you can see, the profile depends upon the basic functionality offered to us by the Generic Access Profile, Chapter 2, the Service Discovery Application Profile, Chapter 3 and the Serial Port Profile, Chapter 6.
Figure 17-5. The dependent components of the Bluetooth protocol stack that make up the Hands-Free Profile. The areas that are shaded are relevant to this profile.
The Hands-Free Profile does not operate strict master-slave roles and either the AG or HF may initiate the connection. As such, the initiating party is referred to as DeviceA, or the initiator; and DeviceB is the acceptor. Any initiating device is the master of the relationship, but no master-slave role switch is required from the accepting device.
Figure 17-4 illustrated the components that made up our Hands-Free Profile. The profile is also dependent on the Serial Port Profile, Chapter 6, in its implementation. Like the Headset Profile, Chapter 7, a series of AT commands are also used to enable control signalling. On closer inspection, you will also notice that the AG device provides audio port emulation, whereas the HF provides an audio driver. It is also assumed that some management entity exists, where access to lower components of the stack is provided; in some cases, a direct Pulse Code Modulation (PCM) route is used to enable faster audio throughput.
In this example, we will use our mobile phone and our in-car hands-free kit as our usage models to explain the interaction and sequence of events between these two devices. There is some degree of overlap with the Headset Profile, since this itself achieves exactly the same functionality as the Hands-Free Profile. Nevertheless, as it is, more and more products on the market now offer support for dual capability encompassing both the Headset and Hands-Free Profiles; refer back to our previous chapter the Headset Profile, Chapter 7, for more information.
As you know and have become more familiar with, Bluetooth Profiles supports the general philosophy of a good user experience. It is therefore important to consider how the user would experience the access and usability of the services provided by an HF. In the following sections, we consider the specific actions of creating a connection, terminating and losing the connection between the AG and HF and how the user may experience such operations. With a small display, the mobile phone may only provide a user-friendly description of the discovered HF device, although an extended menu may exist to specifically interrogate the device further; whereas a PDA however, may typically have a larger display offering further details about the discovered device. Nonetheless, each device may have an option to allow you to customise the HF device.
A user or an internal event would realise the creation of an audio connection, where a SCO link is established between the AG and HF, although it is implied that a Service Level Connection already exists, see Figure 17-6. This pre-condition to setting up the SCO connection essentially mandates that these two devices already have a prior relationship, where an inquiry, discovery and optional authentication has already taken place, although if no prior relationship exists between both parties then one is created. Formal procedures also exist to accommodate parking, [3] unparking, connection termination and release.
It is assumed that both the AG and HF already have an existing SCO connection ready for use, as outlined in our previous section. The AG may initiate a call by using the function already inherent in the mobile phone device, using the buttons provided by the handset. This does require the driver or user to reach down or across to operate the device. Figure 17-7 shows the specific set of events that are used to enable a call and how the AG and HF coordinate the audio effort.
A call can be accepted by the function already provided by the mobile phone using the buttons provided on the handset. The in-car system has alerted the driver to an incoming call through the use of an in-band ringing tone or through a voice announcement, as we previously described. Figure 17-8 shows the specific set of events that are used to accept a call and how the AG and HF coordinate the audio effort.
A call can be rejected by the function already provided by the mobile phone handset. The in-car system has alerted the driver to an incoming call through the use of an in-band ringing tone or through a voice announcement. The driver would depress the associated button provided by the mobile handset to reject the call and have it diverted to voice mail. Similarly, a call can be terminated using the same function. In both instances, an audible confirmation may be used to alert the driver that the call has been rejected or terminated.
It is assumed that the HF unit is capable of supporting this function through the AG and, as such, has the ability to retrieve numbers using voice activation from the AG and to subsequently dial them. Voice activation is enabled through the use of the mobile phone handset, which places the AG unit into a momentary-on state, where it waits for the driver’s announcement. This function, if not used, may timeout or be deactivated using the same or similar function from the mobile phone handset. Figure 17-9 shows the activation events that occur during the use of the voice function; it also demonstrates the coordinated audio effort between the AG and HF.
The Phone Access Profile provides two new roles: a Mobile Equipment (ME) and a Terminal Equipment unit (TE). In a similar manner to the AG, the ME provides full duplex audio support and such devices include a mobile phone. The TE is the device that provides remote control functionality and such devices would include an in-car kit or in-car embedded unit. In Figure 17-10, we can see the new Phone Access components integrated with the existing Bluetooth protocol stack.
Figure 17-10. The components of the Bluetooth protocol stack are shown, illustrating the newer components of the Phone Access Profile.
The functionality of the ME is exported to the TE for control and operation and only one TE can control an ME. As such, only one audio connection exists between the two devices. Like the Hands-Free Profile, the profile mandates support for audio CODECs where the resulting audio is monophonic and has a data rate of 64 Kb/s.
In Figure 17-11, we provide a conceptual illustration representing the dependencies that make up the Phone Access Profile; the areas that are shaded are relevant to this profile. As you can see, the profile depends upon the basic functionality offered to us by the Generic Access Profile, Chapter 2, the Service Discovery Application Profile, Chapter 3 and the Serial Port Profile, Chapter 6.
Figure 17-11. The dependent components of the Bluetooth protocol stack that make up the Phone Access Profile. The areas that are shaded are relevant to this profile.
In Figure 17-10, we illustrated the components that made up our Phone Access Profile. The profile is also dependent on the Serial Port Profile, Chapter 6, in its implementation. Like the Hands-Free Profile, we introduced earlier, a series of AT commands are also used to enable control signalling. On closer inspection, you will notice that the ME device provides audio-port emulation, whereas the TE provides an audio driver. It is also assumed that some management entity exists, where access to lower components of the stack is provided; in some cases, a direct PCM route is used to enable faster audio throughput.
Like the Hands-Free Profile, the Phone Access Profile does not operate strict master-slave roles and either the ME or TE may initiate the connection.
There is some degree of overlap with the Phone Access and Hands-Free Profiles; the extent of the overlap goes as far as the audio transfer between the two devices. In addition to the audio transfer, this profile provides remote control support to allow the user to control the ME using the TE. In this example, we use a mobile phone and our in-car embedded device to best illustrate our usage model in explaining the interaction and sequence of events between these two devices.
The profile mandates a minimum set of key features that is required for any device to be considered compliant with the Phone Access Profile. These are shown in Table 17-1.
A user or an internal event would realise the creation of an audio connection, where a SCO link is established between the TE and ME, although it is implied that a Service Level Connection already exists. This pre-condition to setting up the SCO connection essentially mandates that these two devices already have a prior relationship. That is an inquiry, discovery and optional authentication has already taken place. If no prior relationship exists between both parties, then one is created. Formal procedures also exist to accommodate parking and unparking, connection, termination and release.
Table 17-1. The minimum set of key features that are required for this profile.
|
FEATURE |
DESCRIPTION | |
|---|---|---|
|
1 |
Call control support |
This feature provides core functionality to include accepting, terminating and making calls. |
|
2 |
Phonebook support |
This support provides the user with the ability to sort, scroll and select entries from their phonebook. |
|
3 |
Phone status information |
This feature provides general information about the status of the phone to include support for signal strength, call status and operator name. |
|
4 |
SIM PIN status information |
Here the user may request the status indication of the PIN code and entry status. |
|
5 |
Supplementary services |
The features supported can normally be found with any mobile phone; they provide the user with a common set of features, to include three-way calling, call forwarding, and barring. |
|
6 |
Short Message Service (SMS) |
This provides extended functionality to the user, that is, all the SMS capabilities of a mobile phone. |
|
7 |
Miscellaneous |
This feature allows the user to query and configure capabilities within the device to provide such information as voice recognition activation, volume control and data call indication. |
It is assumed that both the TE and ME already have an existing SCO connection ready for use. The TE may initiate a call by using the function available though the in-car embedded unit. A button-operated steering wheel and in-car display unit, inherent in the vehicle, would be used to provide navigation for the phonebook in order to select the name of the person to call. Figure 17-12 shows the specific set of events that are used to enable a call and illustrates how the TE and ME coordinate the audio and remote control effort.
A call can be accepted by the function already provided by the mobile phone. The exported functionality to a vehicle environment allows the user to accept a call from the button-operated steering wheel. The in-car system has alerted the driver to an incoming call through the use of an in-band ringing tone or through a voice announcement. Figure 17-13 shows the specific set of events that are used to accept a call and how the TE and ME coordinate the audio and remote control effort.
A call can be rejected by the function already provided by the mobile phone. The in-car system has alerted the driver to an incoming call through the use of an in-band ringing tone or through a voice announcement. The exported functionality to a vehicle environment would allow the user to reject the call from the button-operated steering wheel. The remote control handling of this sequence would allow the caller to be transferred to voice mail. Similarly, the call can be terminated using the same function. In both instances, an audible confirmation can be used notifying the user that the call as been rejected or terminated.
It is assumed that the ME unit is capable of supporting this function through the TE and, as such, has the ability to retrieve numbers using voice activation from the ME and to subsequently dial them. Voice activation can be entered using the button-operated steering wheel, as well as the feature already provided by the mobile phone handset, which places the ME unit into a momentary-on state, where it waits for the driver’s announcement. This function, if not used, may timeout or be deactivated using the same or similar functions from the steering wheel and mobile phone handset. Figure 17-9 showed the activation events that occur during the use of the voice function. It demonstrates the coordinated audio and remote control efforts between the TE and ME.
As illustrated in Table 17-1, the range of functionality that is exported by the ME allows the TE to effectively take control of the unit, where the driver can safely operate the device without too much distraction.
The application determines if authentication and encryption is enforced and if the procedures as prescribed in the Generic Access Profile, Chapter 2, are applied. However, the Phone Access Profile does mandate several security features.
During pairing Link Level Enforced Security and Service Level Enforced Security (see the Generic Access Profile, Chapter 2, for more information) are recommended with the addition of authentication and encryption. User intervention is required during this process when first establishing a connection.
The Subscriber Identity Module (SIM) Access Profile provides two new roles: a SIM Client and a SIM Server. This profile mandates the exchange of SIM-specific data between a SIM client and SIM server. As such, it is not limited to the car profiles and may be used for other application usage models. The SIM client unit forms part of an in-car embedded environment, where its backbone supports the audio and remote control nature of the usage scenarios, as previously outlined in our earlier sections. No audio and remote control hand-off is required, since the in-car SIM client Bluetooth-enabled device is an integral component to the operation of the in-car embedded phone unit. Furthermore, since the embedded device is a GSM capable unit, calls can be connected, terminated and rejected in the usual manner. In Figure 17-14, we can see the new SIM Access components integrated with the existing Bluetooth protocol stack.
Figure 17-14. The components of the Bluetooth protocol stack are shown, illustrating the newer components of the SIM Access Profile.
The profile defines a set of protocols and procedures, which are required to realise the profile implementation. The functionality of the SIM server exports its SIM-specific data to the SIM client to allow it to make use of phonebook, calendar and other mobile phone or PDA related data.
In Figure 17-15, we provide a conceptual illustration representing the dependencies that make up the SIM Access Profile; the areas that are shaded are relevant to this profile. As you can see, the profile depends upon the basic functionality offered to us by the Generic Access Profile, Chapter 2, the Service Discovery Application Profile, Chapter 3 and the Serial Port Profile, Chapter 6.
Figure 17-15. The dependent components of the Bluetooth protocol stack that make up the SIM Access Profile. The areas that are shaded are relevant to this profile.
The SIM Access Profile does not operate strict master-slave roles and either the SIM Client or the SIM Server may initiate the connection.
The user expectations are almost transparent to the usage model prescribed by this profile. With the inquiry and discovery procedures that are typical for a Bluetooth connection, no other visual process occurs. The profile mandates the transfer of SIM subscription and other related data to the SIM client, where it can then register the client on a GSM network. Furthermore, existing procedures are available within the in-car embedded unit to conduct the operation of making and receiving GSM network calls as you would expect from your mobile phone handset. As a result of data sharing with the SIM client, the in-car embedded unit has access to the phonebook and, in some cases, calendar specific information. As a minimum, the SIM Access Profile provides the ability to exchange data from one SIM to another.
In part, the profile has been based upon the GSM 11.11 Specification of the Subscriber Identity Module – Mobile Equipment (SIM-ME) Interface. It is also based on the GSM 11.14 Specification of the SIM Application Toolkit for the Subscriber Identity Module – Mobile Equipment (SIM-ME) Interface, see Figure 17-14, which provides an illustration outlining how these components are integrated within the Bluetooth protocol stack.
The profile mandates a minimum set of key application features that is required for any device to be considered compliant with the SIM Access Profile. These are shown in Table 17-2.
Stronger Bluetooth security methods are encouraged for this profile, inasmuch as particularly sensitive and confidential data are being exchanged between the two parties. Any eavesdropping could result in unwanted identification of personal data. Support should be provided for at least Link Level Enforced Security and Service Level Enforced Security (see the Generic Access Profile, Chapter 2, for more information) and pairing is mandatory for both devices.
Table 17-2. The minimum set of key features that are required for this profile.
|
FEATURE |
DESCRIPTION | |
|---|---|---|
|
1 |
Connection Management |
This feature provides core functionality to allow the connection, disconnection and status procedures for both parties. |
|
2 |
Transfer Application Protocol Data Units (APDUs) |
This feature provides the ability to communicate over the connection using APDUs. It is the client that initiates the APDU, where the payload data relates to the transfer of client-server specific parameters. |
|
3 |
Transfer Answer to Reset (ATR) |
This denotes the ability of the server to send the ATR in response to a reset. The process may be initiated by the client requesting the server to send it from the SIM. |
|
4 |
Power SIM On/Off |
The client may request that the server switch off the SIM, where all GSM connections have ended. Similarly, it may also request that it be switched on if it has been previously switched off. |
|
5 |
Reset SIM |
The client may request the server to reset the SIM if all GSM connections have been terminated. |
|
6 |
Report Status |
This feature is used to identify any changes within the client-server relationship (connection status) and during the connection set-up procedure. |
|
7 |
Transfer Card Read Status |
The client may request Card Reader Status which, in turn, provides the client operation status of the SIM. In turn, details regarding the SIM size and so on are reported. |
|
8 |
Error Handling |
Generic handling procedures are an inherent process for the features presented in this table. |
Furthermore, the use of encryption is strongly recommended, along with use of longer Bluetooth Passkeys, [4] where the navigation of user interaction is encouraged during all exchanges between SIM devices.
The Car Profiles have three new profiles: Hands-Free, Phone Access and SIM Access.
The Hands-Free Profile provides audio hand-off to an in-car hands-free kit, but its operation is still coordinated through the mobile phone handset interface.
There is an overlap of the Hands-Free Profile with the Headset Profile since both provide audio hand-off.
The Phone Access Profile also provides audio hand-off, but extends this to remote control of the ME, where navigation of a phonebook can be managed through the button-operated steering wheel and visual output is provided by the in-car display unit.
The SIM Access Profile provides the exchange of SIM-specific data between two devices, primarily a mobile phone handset and an in-car embedded handset, where the in-car unit can take control.
When SIM-specific data has been exchanged with the in-car embedded handset, the user can make and disconnect calls using the button-operated steering wheel and the in-car display unit.
[1] The temptation here is to look down at your in-car display to identify the caller, in much the same way we look at our mobile phone. With an announcement, the caller can be audibly identified. This removes the need to seek further information from the in-car display unit.
[2] Bluetooth technology has provision for two types of audio-encoding schemes. The Pulse Code Modulation (PCM) has two types of logarithmic compression, these are A-law and µ-law; Continuous Variable Slope Delta (CVSD) provides the second scheme, which is particularly efficient for voice communication. Further information about Bluetooth Audio can be found in the Cordless Telephony Profile, Chapter 4, Intercom, Chapter 5 and Headset Profiles, Chapter 7.
[3] The parking and unparking operations refer to the baseband connection state, where devices may be placed into park mode and subsequently unparked. This state is a lower power usage model where partying devices conserve their battery life.
[4] The Bluetooth Passkey is a user-level entered parameter that is required for the pairing procedure and thus enables subsequent authentication.