SAP and Remote Network Access Instruction Manual

SAP AND REMOTE NETWORK ACCESS

Revision History

Revision: Date: Description
D05r01: 29 November 2011: Initial Draft
D05r02: 30 November 2011: Editorials
D05r03: 20 February 2012: Editorials
D05r04: 27 March 2012: Changes after CWG review
D05r05: 11 April 2012: Changes after 2nd CWG review
D05r06: 22 May 2012: Changes after BARB review
D05r07: 25 May 2012: Editorials CWG
D05r08: 25 June 2012: Further editorials and consolidation
D05r09: 04 July 2012: Changes following Terry’s comments
D05r10: 10 September 2012: Editorials
D05r11: 16 September 2012: Editorials
D05r12: 24 September 2012: Formatting, spell checking
V10: 23 October 2012: Approved by the Bluetooth SIG Board of Directors

Contributors

Name: Company

Tim Howes: Accenture
Gerald Stöckl: Audi
Joachim Mertz: Berner&Mattner
Stephan Schneider: BMW
Burch Seymour: Continental
Meshach Rajsingh: CSR
Stefan Hohl: Daimler
Robert Hrabak: GM
Alexey Polonsky: Jungo
Kyle Penri-Williams:   Parrot
Andreas Eberhardt: Porsche
Thomas Frambach:   VW

1. Scope

The SIM Access Profile (SAP) allows a Bluetooth enabled device to access data contained in the SIM card of another Bluetooth enabled device. In a typical use case a network access device (NAD) for a cellular network is built into a vehicle, but does not contain a SIM card. Instead, an SAP connection will be made with a mobile phone. The NAD will use the security credentials stored in the SIM card to register with the cellular network.
In this case, the portable phone is acting as an SAP server while the NAD is the SAP client device. All data contained in the phone’s SIM card, including phone book entries and SMS related data, can be accessed by using commands provided by SAP. SAP enables premium telephony for several reasons (see also 2.1). However, when the mobile phone has accepted to operate as an SAP server it will not be able to obtain cellular network services in general, and an
Internet connection in particular. Current Bluetooth specifications do not describe a method for a mobile phone to maintain a data connection in parallel with an SAP session. This affects the acceptance of SAP in particular in the smartphone market as these devices require a permanent Internet access.
This paper describes methods and recommendations to avoid these connectivity problems.

2. Motivation

2.1 BENEFITS OF SAP

For suitable car kit solutions the SIM Access Profile provides a number of benefits compared to the HFP Profile.

2.1.1 LOW ACCEPTANCE OF DEVICE CRADLES BY CONSUMER

Phone cradles may be used to couple the antenna1 of the mobile phone to an external car antenna.
However, consumers perceive cradles as inconvenient and cumbersome, and desire an experience which is seamless and effortless. When entering the car the customer wants to leave the phone in a pocket or bag and not be required to take it out to place it in a cradle. Assuming the user does successfully connect a phone through a cradle, this adds the risk of forgetting the phone when leaving the car.
The next acceptance problem for cradles is device scalability. The customer must buy a new cradle when he exchanges his phone. Frequently, new cradles are not available immediately after market release of new devices, and for many phones, cradles are not available at all. This restricts the available device choices for the user.
Thus, today the overall market acceptance of cradles is very restricted. When using SAP, no consumer device cradle is required

2.1.2 ENHANCED TELEPHONY FEATURES

The enhanced telephony features of SAP enable the customer to modify important call-related telephony features on the fly while driving, or provide the customer more detailed information. In many countries legal authorities prohibit the usage of the consumer device while driving; the car’s infotainment user interface is the only legal way to interact with the consumer device.
Examples of telephony features available in SAP are

• Caller ID: activate, deactivate, request current status
• Call forwarding: activate, deactivate, modify
• Manual vs. automatic network selection: modify
• (De-)Activate “Roaming allowed” for data transfer via the SIM
• Display the service provider name instead of network operator name.

Because the HFP Profile does not provide access to those telephony features, SAP is the only profile to enable these use cases for drivers.

2.1.3 OPTIMIZED NETWORK COVERAGE

SAP provides a significant improvement in terms of network coverage:

• When using SAP, the car’s phone features use the car’s built-in NAD, which establishes a direct connection to the external cellular antenna. This results in improved signal quality and optimized network coverage, reducing the number of signal losses.
• This benefit is dramatically increased when the car is equipped with metalized windows, which are used to reduce the car’s energy consumption for air conditioning. Signal losses of around 20 dB are common when using a mobile phone’s built-in antenna inside such a car. This degraded signal can cause network loss, bad reception, and significantly lower data transfer rates.
• If the user has a phone cradle in his car, the antenna coupling may reduce the transmission quality when this coupling is realized in inductive manner. Typical inductive coupling losses are in the range of 6 to 10 dB.

2.1.4 LOW COMPLEXITY OF SAP

As SAP refers to well-established 3GPP standards (usage of APDU format) and requires only a very simple implementation of an access mechanism to the SIM card, the number of potential interoperability issues when operating SAP is low compared to HFP implementations.

2.1.5 LESS ELECTROMAGNETIC EXPOSURE FOR CUSTOMER

When in SAP operation, the NAD of the mobile phone will not be transmitting. Therefore, the electromagnetic exposure of the driver can be minimized. Without SAP, the transmission power of the phone must be elevated due to the shielding effects of the car body. Additionally, the battery life of the mobile phone is increased.

2.1.6 MWS COEXISTENCE

The coexistence of Bluetooth with other wireless technologies, in particular 4G networks like LTE, may become a critical issue in the near future and is therefore intensively discussed in the Bluetooth SIG (Mobile Wireless Coexistence issue; see also [5] ). SAP can contribute significantly to avoid such issues, as the NAD will use an external cellular antenna with a vastly better antenna separation than the handset.

2.2 USE CASES

This section describes some relevant use cases that are addressed by this white paper.

1. . Internet Access
   * General use case: Internet applications Mobile devices like smartphones require a frequent or permanent Internet access for a variety of applications such as Internet browsing, social networks, blogs, chats, or news feeds.
   Special use case: Emails via MAP Mobile messaging via email has become an important application of Bluetooth technology in the car. Bluetooth has covered this use case by the development of the Message Access Profile (MAP, [1]). However, MAP allows the car kit to be a mail client of the mobile phone. It does not provide capabilities to send/receive mails on the MAP client side.
   Special use case: Personal Information Management The Bluetooth SIG is currently developing a profile enabling access to the calendar data on the mobile phone. As calendar entries are usually delivered via IP networks, a loss of the IP connection would also affect this use case. Therefore, a mobile phone operating in SAP should be able to send and receive such calendar entries

2. SMS
   Mobile messaging via SMS is still an important market. Accordingly, SMS messaging should be possible as well for a mobile phone operated with SAP.

3. Voice only
   The SAP profile dates back to the year 2000, and is therefore focused on voice calling. Smartphones, with their need for a constant Internet connection, were not a consideration. However, using SAP for voice telephony only is still a valid use case. The voice-only use case is covered by the existing specification and should not require any changes.

3. Solutions

3.1 OVERVIEW

The following sections describe the solutions that can be applied to handle the issues as described in section 2:

1. Internet Access:
   A mobile phone or another mobile device acting as SAP server must be enabled to access to the Internet.

2. SMS Transfer:
   A mobile phone or another mobile device acting as SAP server must be enabled to send and receive SMS messages.

3. Voice Only:
   SAP is used for voice telephony only.

As a general constraint, the solutions described in the following sections should be as transparent as possible for the user; the user shouldn’t have to care whether SAP or HFP is in operation.
Additionally, the SAP-server device will remain the central unit for the communication; e.g., the histories of incoming and outgoing communications transactions, like sent or received messages, should still be available on the SAP server.
The handling of MMS in SAP operation is not explicitly described by this white paper. Nevertheless, as MMS requires both the reception of SMS and an IP connection to the MMS server, the problem is implicitly covered by the use cases SMS Transfer and Internet Access.

3.2 INTERNET ACCESS

3.2.1 GENERAL USE CASE INTERNET ACCESS

Objective:
Provide access to the remote IP network for the SAP-server device while SAP is active Description:
The SAP-server device (e.g., a mobile phone or a smartphone) has provided access to its SIM data for the SAP-client device (e.g., a car kit or a tablet computer) and the SAP client has used this data for the authentication against the mobile network. Accordingly, the SAP server has no access to the mobile network, while the SAP client uses its own network access device (NAD) to communicate with the mobile network.
To provide Internet access for the SAP server, the SAP-client device has to act as a network access point for the SAP server. For that, an IP connection between the SAP-server and SAP-client devices has to be established.
The solution described here uses the Bluetooth BNEP protocol for the IP connection between the two SAP devices, and the PAN profile to provide the network access point. Note that other solutions may be possible, e.g., an IP connection via WiFi.
For the solution defined here, the following pre-conditions must be fulfilled:

• The two devices have an SAP connection established.
• The SAP-server device must support the PANU (PAN-User) role of the PAN profile [3].
• The SAP-client device must support NAP (Network Access Point) role of the PAN profile.

Figure 1 shows the connection setup to enable the SAP-server to access the external IP network:

Figure 1: Sequence of the connection setup PAN/BNEP

1. If the SAP connection is established between the two devices and an application on the SAPserver device requires an IP connection to the remote network, the SAP-server device (PANU role) sets up a PAN/BNEP connection to the SAP client (PAN-NAP role). Typically, this PAN connection establishment will not require a user interaction.
2. The BNEP connection setup should include the transmission of access point name data (APN) or a selection of pre-defined APNs on the SAP-client device side as defined in [4].
3. After the successful establishment of the PAN/BNEP connection, IP datagrams can be automatically transferred between the SAP server device and the remote network where the SAP-client device acts as router to the remote IP network.
4. Several PAN/BNEP connections may be established as described above, e.g., to address several access points in the infrastructure of the mobile network.

The following sections describe the usage of the general mechanism above for some specific applications.

3.2.2 SPECIAL USE CASE: EMAIL ACCESS VIA MAP

Objective:
Enable an SAP-server device to send and receive emails while SAP is active.
Description:
One specific application for the Internet access mechanism described above is the transmission of emails by using the Message Access Profile [1].

For a MAP session with SAP operation the following pre-conditions must be fulfilled:

• The general requirements for Internet access as described in section 3.2.
• The SAP-server device acts as MAP Server Equipment (MSE) and the SAP-client acts as MAP Client Equipment (MCE).
• Both the MSE and the MCE support the MAP features ‘Message Browsing’, ‘Message Upload’, ‘Message Notification’, and ‘Notification Registration’.

Figure 2 describes the sequences and the usage of the MAP functions for an email reception:

Figure 2: Sequence of an email reception in MAP with SAP operation

1. The MAP MSE and MCE devices have established a ‘Message Access Service’ connection and ‘Message Notification Service’ connection.
2. The SAP-server device (as PANU) has established a PAN/BNEP connection to the SAP-client device (as PAN-NAP).
3. The MSE retrieves the email by using the PAN/BNEP connection from the network via the MCE’s NAD.
4. The MSE sends a ‘NewMessage’ notification to the MCE signaling that a new message has been received.
5. The MCE may retrieve the message by a ‘GetMessage’ request.

See also [1] for descriptions of the MAP functions ‘SendEvent’ and ‘GetMessage’.

Figure 3 describes the sequences and the usage of the MAP functions for sending an email:

Figure 3: Sequence for sending an email in MAP with SAP operation

1. The MAP MSE and MCE devices have established a ‘Message Access Service’ connection and ‘Message Notification Service’ connection.
2. The SAP-server device (as PANU) has established a PAN/BNEP connection to the SAP-client device (as PAN-NAP).
3. If the message is created on the MCE device, the MAS Client of the MCE pushes the message to the ‘Outbox’ folder of the MSE. If the message is created on the MSE device and ready to be sent, the message is set in the outbox folder or shifted from the draft folder.
4. If the message has been pushed to the ‘Outbox’ folder, the MSE sends a ‘NewMessage’ notification to the MCE signaling that the message has been accepted. If a message has been created or shifted to the ‘outbox’ folder on the MSE, the MSE sends a ‘MessageShift’ event.
5. The MSE sends the message to the network by using its PAN/BNEP connection.
6. If the message was successfully sent to the network, the MSE shifts the message from the ‘Outbox’ to the ‘Sent’ folder and notifies the MCE accordingly.

See also [1] for description of the MAP functions ‘SendEvent’ and ‘PushMessage’.

3.2.3 SPECIAL USE CASE: CALENDAR DATA ACCESS

Objective:
Enable an SAP-server device to send and receive calendar data while SAP is active.
Description:
Another specific application for the Internet access mechanism (3.2.1) described is the transmission of calendar data entries over an IP network. The development of a calendar profile is in progress as of the writing of this white paper, so there are no detailed functions defined yet.
Thus, only a draft sequence of the required actions is given hereunder. In general, the requirements for this use case will be similar to the requirements for email access ( see 3.2.2 ).

Figure 4: Schematic sequence for the reception of calendar data in SAP operation

Figure 5: Schematic sequence to send calendar data in SAP operation

3.3 USE CASE SMS ACCESS

3.3.1 OVERVIEW

Objective:
Describe the mechanisms for an SAP-server device to send and receive SMS while SAP is active.
Description:
The SAP-server device (e.g., a mobile phone or a smartphone) has provided access to its SIM data for the SAP-client device (e.g., a car kit or a tablet computer) and the SAP client has used this data for the authentication against the mobile network. Thus, the SAP server is no longer able to send or receive SMS messages directly.
To enable a user to send or receive SMS messages, two approaches are described hereunder:

• A simple solution based on SAP only
• A more complex but thorough approach based on MAP

3.3.2 SMS ACCESS WITH SAP ONLY

Receive an SMS:
When operating in SAP mode, the SAP client’s NAD receives an SMS_DELIVER PDU or SMS_STATUSREPORT PDU as defined in 3GPP 23.040 via the NAD’s mobile network protocol stack. Depending on the rules as defined in 3GPP 23.040 and 3GPP 23.038 for the SMS PDU received by the NAD, the SAP-client device may then store the SMS at the (U) SIM of the SAP-server device. For that, it uses the SAP APDU format to request the storage of the PDU via the SAP connection on the (U) SIM in the elementary field EF[SMS] of the (U) SIM (see 3GPP 51.011 v4 chapter 10.5.3 for the definition of the field). Hereby, the updating procedure according to 3GPP 51.011 chapter 11.5.2 and 3GPP 31.101 is performed.
Send an SMS:
The SMS_SUBMIT PDU (see 3GPP 23.040) is sent via the NAD’s mobile network protocol stack. After sending, depending on the rules as defined in 3GPP 23.040 and 3GPP 23.038 for the SMS PDU, the NAD may then store the SMS at the (U) SIM. Again, it uses the SAP APDU format to request to store the PDU and uses the updating procedure according to 3GPP 51.011 chapter 11.5.2 and 3GPP 31.101.

Advantages

• Full compliance to 3GPP mobile network requirements is fulfilled.
• SMS are stored non-volatile on (U)SIM place inside the mobile phone.
• Less complexity compared to ‘Full SMS Access’ solution described in section 3.3.3 as no additional profile is required. Thus, this solution is also suitable for simple devices.

Disadvantages

• Mobile phone implementations might ignore the (U) SIM EF[SMS] so that the customer might not able to access the sent or received SMS via the mobile phone’s user interface after the SAP connection has ended.
• Because the phone does not have access to the SIM card during SAP operation, the messages will not be displayed on the phone during SAP operation.
• No initiation of SMS sending on the mobile phone possible.

3.3.3 FULL SMS ACCESS VIA MAP

The main purpose of the approach described here is to have the SAP-server device always included into the SMS communication. This ensures that the SMS access is fully transparent for the user, as all histories of sent and received SMS messages are in the message repository of the SAP-server device.
For that, the SMS PDUs received from the remote network are automatically transferred from the SAPclient’s NAD to the SAP client, and vice versa, for sending by using the OBEX functions of the Message Access Profile. For this solution, the following pre-conditions must be fulfilled:

• The two devices have an SAP connection established.
• The SAP-server device acts as MAP Server Equipment (MSE) and  the SAP-client device acts as MAP Client Equipment (MCE).
• Both the MSE and the MCE support the MAP features ‘Message Browsing’, ‘Message Upload’, ‘Message Notification’, and ‘Notification Registration’.
• The two devices have established a ‘Message Access Service’ (MAS) connection and a ‘Message Notification Service’ (MNS) connection.

Figure 6 describes the sequences and the usage of the MAP functions for an SMS reception:

Figure 6: Sequence of an SMS reception by using MAP in SAP operation

1. The SAP-Client/MCE receives the SMS by its NAD from the network.
2. The MAS Client of the MCE pushes the SMS-PDU or – in case of a concatenated SMS – the SMS-PDUs to the ‘Inbox’ folder of the MSE in native SMS PDU format.
3. If the SMS is for the user (i.e., no class-2 SMS), the MSE sends a ‘NewMessage’ notification tothe MCE signaling that a new SMS has  been received.

Figure 7 describes the sequence and the usage of the MAP functions for sending an SMS:

1. If the SMS is created on the SAP-client/MCE device, the MAS Client of the MCE pushes the SMS to the ‘Outbox’ folder of the MSE. The SMS is transcoded to SMS submit-PDU format by the MSE, if it has been pushed in textual format. If the SMS is created on the MSE device and isready to be sent, the message is set in the ‘Outbox’ folder or shifted from the draft folder.
2. The MCE retrieves the SMS-submit-PDU from the MSE’s ‘Outbox’ folder by a ‘GetMessage’ request and sends it to the network.
3. When successfully sent to the network, the MCE sets the status of the message to ‘sent’.
4. The MSE shifts the message from the ‘Outbox’ to the ‘Sent’ folder and notify the MC accordingly.

Advantages:

• Qualifiable solution.
• SMS are shared back to the phone while in SAP operation.

Disadvantages:

• Complex implementation requires having both MAP and SAP implemented on both devices.
• Requires both MAP and SAP to be connected and running at the same time for no SMS to be lost.
• Because the phone may not have access to the SIM card during SAP operation, the messages may not be displayed on the phone during SAP operation.

3.4 USE CASE SAP TELEPHONY ONLY

An SAP server and an SAP client may have an SAP connection established with the only purpose to provide voice telephony in best quality. In this case no further requirements as defined for SAP must be considered.

4. Abbreviations

Abbreviation or Acronym: Meaning

3GPP: 3rd Generation Partnership Project
BNEP: Bluetooth Network Encapsulation Protocol
GSM:   Global System for Mobile communication
HFP: Hands-Free-Profile
IP: Internet Protocol
MAS: Message Access Service
MAP:   Message Access Profile
MCE:   Message Client Equipment
MMS: Multimedia Message Service
MNS:   Message Notification Service
MSE: Message Server Equipment
MWS: Mobile Wireless Coexistence
NAD: Network Access Device
PAN: Personal Area Networking Profile
PDU:   Protocol Data Unit
SAP:   SIM Access Profile
SIM: Subscriber Identity Module
SMS:   Short Message Service

5. References

1. Message Access Profile 1.0
2. SIM Access Profile 1.0
3. Personal Area Networking Profile (PAN) 1.0
4. Bluetooth Network Encapsulation Protocol (BNEP), Version 1.2 or later
5. MWS Coexistence Logical Interface, Bluetooth Core Specification Addendum 3 rev. 2

SAP and Remote Network Access Instruction Manual – Optimized PDF
SAP and Remote Network Access Instruction Manual – Original PDF

Read User Manual Online (PDF format)

Read User Manual Online (PDF format)  >>

Download This Manual (PDF format)

Download this manual  >>