SIM Access Profile

This SIM Access Profile defines the protocols and procedures that shall be used to access a GSM SIM card, a UICC card or a R-UIM card via a Bluetooth link. Unless otherwise specified the term “Subscription module” shall be used to refer to the GSM SIM card, a UICC card or a R-UIM card.

With the SIM Access Profile, the user can personalize his/her car-embedded phone with a subscription module in an external device, which is connected via a Bluetooth wireless link. The external device can either be a simple SIM card holder or a portable phone, which is brought into the car.

The SIM Access Profile builds on the well-defined interface between the telephone and a subscription module (see [3] and [6]). It also enables multiple card operations as defined in [4], [8] and [11].

Figure 1.1 below shows the Bluetooth profile structure and the dependencies of the profiles. 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 below: a profile has dependencies on the profile(s) in which it is contained directly or indirectly.

Figure 1.1. Profile Dependencies

Figure 2.1 shows the protocols and entities used in this profile.

Figure 2.1. Protocol Stack

The Baseband, LMP and L2CAP are the OSI layer 1 and 2 Bluetooth protocols. RFCOMM is the Bluetooth serial port emulation entity. SDP is the Bluetooth Service Discovery Protocol. See [1] for more details on these topics.

The messages of the SIM Access Profile are defined in this document. It also contains the interoperability guidelines for the applications in the Client and Server.

Error! Reference source not found. shows the basic system configuration, which is taken as a reference in this profile document:

Figure 2.2. Basic System Configuration

The following two roles are defined for this profile:

Server - The SIM Access Server has direct (galvanic) access to a subscription module. It acts as a SIM card reader, which assists the Client in accessing and controlling the subscription module via the Bluetooth link.

Client - The SIM Access Client is connected via a Bluetooth link to the SIM Access Server. The Client accesses and controls the subscription module inside the Server via the Bluetooth link.

Typical examples of a Server are a simple SIM card holder or a portable phone in the car environment. A typical example of a Client is a car phone, which uses a subscription module in the Server for a connection to the cellular network.

Both the subscription module and the cellular network play an important role in the SIM Access Profile. However, the presence of either entity is not mandatory during the operation of the profile.

In general, the SIM Access Server functions as a SIM card reader for the SIM Access Client. The SIM Access Profile enables all scenarios that are also possible with wired SIM card readers.

Two scenarios are depicted here, as they serve as building blocks for other scenarios. Both scenarios will be referenced throughout the document.

2.3.2. Scenario 2: Proactive SIM in the Client and Additional SIM in the Server

below shows a scenario, in which the Client contains a proactive subscription module. The Client uses this subscription module for connecting to the cellular network.

Furthermore, the proactive subscription module may request the Client to control the additional subscription module, which is located in the Server (see [4], [8] and [11]). For this purpose the SIM Access Profile provides the necessary means to perform all functions that are required by [4], [8] and [11]. For example, it is possible to

• power the card in the Server on or off,

• reset the card in the Server or

• get the status of the card and the card reader (i.e. the Server).

Figure 2.3. System Configuration with Proactive SIM in the Client

The SIM Access Profile describes the messages and procedures for accessing a subscription module over a Bluetooth link. It is especially designed for usage with:

The SIM Access Server contains a subscription module and is responsible for establishing and maintaining the physical connection to the subscription module. The Server also acts as the mediator for all messages (APDUs) exchanged between the SIM Access Client and the subscription module. Furthermore, if the Client requests information from the Server about the subscription module or about the Server itself, the Server shall respond by sending the requested data over the Bluetooth link.

The Client is in most cases a phone, which behaves according to the relevant GSM, 3GPP or 3GPP2 specifications. This behavior is fully supported by the SIM Access Profile, by providing the necessary framework.

The Server might also be a phone, which apart from the SIM Access Profile functionality has the ability to use the subscription module for its own cellular network connection. According to the GSM, 3GPP and 3GPP2 specifications, this is only allowed, if the Server is outside of a SIM Access Profile connection (see Sections 4.1, 4.2 and 4.3 for details).

In general, the Server may establish a SIM Access Profile connection, even if there is no subscription module in the Server. Similarly, the Server may establish a connection, even if its subscription module is powered off. In order to handle these different situations, the Client shall be informed about the status of the subscription module during connection setup (see Sections 4.1 and 4.9).

The application of the profile is limited to one Server, which establishes a SIM Access Profile connection to one Client. Similarly, the Server shall only grant the Client access to a single GSM application, USIM application or an R-UIM application on a subscription module card in the context of this profile.

The Client initiates the connection to the Server and performs device discovery and paging. The Server therefore shall be discoverable and connectable according to the Generic Access Profile. See Section 8 for details.

In order to ensure secure communication between Client and Server, several security measures from the Bluetooth specification are mandatory.

Bonding - Client and Server shall be bonded before setting up a SIM Access Profile connection. Security mode 2 or 3 is required for devices implementing the Bluetooth 2.0+EDR, or earlier, specification. Security mode 4 is required for devices implementing the Bluetooth 2.1+EDR, or later, specification. Details are given in Section 8.2.

Encryption - The link between Client and Server shall be encrypted using Bluetooth baseband encryption.

Server Initiated Authentication - The SIM Access Server shall always initiate the authentication procedure.

Link Keys – Only standard combination keys or authenticated combination keys shall be used for SIM Access Profile connections. This means that the ‘just works’ association model shall not be used with SAP as it results in an unauthenticated combination key and does not protect against man-in-the middle attacks. An implementation (client or server) shall support combination keys being changed at each new SIM Access Profile connection. An implementation should change the combination keys at each new SIM Access Profile connection. For increased security, this is encouraged..

Encryption Key Length - A SAP-enabled device shall support the maximum length encryption key as given in the Bluetooth specification. A connected pair of devices may use an encryption key smaller than the specification maximum when required by the laws of the country where the devices are being used, with the restriction that the length of the encryption key shall be at least 64 bits. For increased security, use of the maximum length is suggested.

PIN - When standard combination keys are used, the PIN shall have the length of 16 digits. Additionally, it is strongly recommended that the PIN satisfies the complexity requirements described in [12]. Fixed PINs shall not be used. When authenticated combination keys are used either a passkey or numerical comparison value shall be used depending on the I/O capabilities of the two devices. The length of this passkey or numerical comparison value shall be six digits. The Authentication_Requirements parameter shall be set to MITM Protection Required.

If conformance to this profile is claimed, all capabilities indicated mandatory for this profile shall be supported in the specified manner (process mandatory). This also applies for all optional and conditional capabilities for which support is indicated. All mandatory capabilities, and optional and conditional capabilities for which support is indicated, are subject to verification as part of the Bluetooth qualification program.

Connection Management - The ability to establish and terminate a SIM Access Profile connection between Client and Server.

An established SIM Access Profile connection is the prerequisite for all other features.

Transfer APDU - The ability to send APDUs (Application Protocol Data Units) over the Bluetooth link in both directions.

APDUs sent to the subscription module are called Command APDUs, while APDUs sent by the subscription module are called Response APDUs. Command APDUs and Response APDUs only occur as pairs, where each Command APDU is followed by a Response APDU. The APDU exchange shall always be initiated by the Client.

The format and content of the APDUs are defined in [3], [4] for CommandAPDU parameter, and in [12] for CommandAPDU7816 parameter (see section 5.2.6).

Transfer ATR - The ability to send the content of the ATR (Answer to Reset) from the Server to the Client over the Bluetooth link.

The ATR shall be sent by the subscription module to the Server after the subscription module has been powered on or reset. It contains information about the interface provided by the subscription module and the services on the GSM SIM, the UICC or the R-UIM.

The format and content of the ATR are defined in [2].

Power SIM Off - The ability to power the subscription module off remotely.

This feature gives the Client a means to power the subscription module in Server off remotely. It is needed for the Application Toolkit^[2] purposes as shown in Scenario 2 (Section 2.3.2).

Power SIM On - The ability to power the subscription module on remotely.

This feature gives the Client a means to power the subscription module in the Server on remotely. It is e.g. needed for Application Toolkit^[2] purposes as shown in Scenario 2 (Section 2.3.2).

Reset SIM - The ability to reset the SIM remotely.

This feature gives the Client a means to reset the subscription module in the Server. It is e.g. needed for Application Toolkit^[2], as shown in Scenario 2 (Section 2.3.2).

Report Status - The Server's ability to inform the Client about the status of the physical connection between the Server and the subscription module.

This feature enables the Client to react appropriately, if the subscription module is e.g. removed or inserted in the Server.

Transfer Card Reader Status - The ability to send the Card Reader Status from the Server to the Client over the Bluetooth link.

The card reader status contains some basic information about the Card Reader and the subscription module (e.g. the size of the SIM or if the SIM is removable). This information is required for Application Toolkit¹ purposes as shown in Scenario 2 (Section 2.3.2) and specified in [4], [8] and [11].

Error Handling - The ability to handle invalid formatted messages.

If the Server receives an invalid formatted message from the Client, the Server shall send an appropriate error message (see section 5.3).

Set Transport Protocol - The client’s ability to request the use of another Transport Protocol than T=0 from the server.

The server shall reset the subscription module and switch to the desired protocol if supported by subscription module and Server.

The features "Power SIM off" and "Transfer Reader Status" are only applicable for Scenario 2 (Section 2.3.2). All other features are applicable for both Scenarios.

In order to start the SIM Access Profile connection and negotiate important parameters adherent to the connection, the messages CONNECT_REQ, CONNECT_RESP, STATUS_IND, TRANSFER_ATR_REQ and TRANSFER_ATR_RESP are used as described below.

Before the Client may send a SIM Access Profile message to the Server, the two devices must have established an L2CAP and RFCOMM connection (see also Section 7).

After the RFCOMM connection is established, the Client may issue a CONNECT_REQ message to the Server. The Server shall answer with the CONNECT_RESP message^[3]. These two messages may be repeated as described in Section 4.11 in order to negotiate the maximum message size to be deployed in the SIM Access Profile connection.

Note: The term ‘ongoing calls’ includes both fully established and set-up-in-progress calls.

If the Server contains a subscription module that is currently powered on, the Server shall ensure that the subscription module is in a well-defined state. This shall be done without affecting ongoing calls on the server device. The T=0 transport protocol shall be internally used by the server. To change the transport protocol, the feature ‘Set Transport Protocol’ shall be used.

After the Server has sent the CONNECT_RESP message with the parameter "ConnectionStatus" set to "OK, Server can fulfil requirements" (see Section 5.3.2), it shall inform the Client about the status of its subscription module connection by sending the STATUS_IND message (see Section 4.9 for details).

If the message size negotiation succeeds, but the server cannot reset the SIM due to an ongoing call, the server shall send the CONNECT_RESP with the parameter "OK, ongoing call”. The server shall reset the SIM card and send the STATUS_IND (“Card reset”) message as soon as the ongoing call has been released.

If a subscription module is inserted in the Server and powered on (i.e. STATUS_IND message contains the parameter "Card reset"), the Client shall request the ATR of the subscription module with the TRANSFER_ATR_REQ message. If the T=0 protocol is not supported (i.e. STATUS_IND message contains the parameter "Card_not_accessible"), the Client may request the ATR of the subscription module with the TRANSFER_ATR_REQ message to retrieve information about protocols supported by the subscription module and use the Set Transport Protocol feature subsequently. In both cases the Server shall answer with the TRANSFER_ATR_RESP message as described in Section 4.5.

Figure 4.1 illustrates how the Client and Server connect successfully:

Figure 4.1. Client Connecting to Server

The successful performance of the connection setup procedure is a precondition for all of the following procedures.

If the Server is unable to connect to the Client, it indicates this in the CONNECT_RESP message with the parameter "ConnectionStatus" set to "Error, Server unable to establish connection" (see Section 5.3.2). In this case, the SIM Access Profile connection between Client and Server is not established.

If the Client wants to release the SIM Access Profile connection, it first shall terminate any existing GSM application session, USIM application session or R-UIM application session which involves the subscription module in the Server. The Client shall then send a DISCONNECT_REQ message to the Server.

The Server shall answer with a DISCONNECT_RESP message and the SIM Access Profile is successfully released.

After the disconnection of a SIM Access Profile connection, the Client shall immediately disconnect the corresponding RFCOMM data channel between the Client and the Server.

Note: After sending the DISCONNECT_RESP message, the Server may use the subscription module for another SIM Access Profile connection or for its own cellular network connection.

Figure 4.2 illustrates how the Client initiates a disconnect from the Server:

Figure 4.2. Client Disconnecting from Server (Initiated by the Client)

If the Server wants to release the SIM Access Profile connection, it shall send the DISCONNECT_IND message to the Client. Within this message the Server shall indicate, if it wants to release the SIM Access Profile connection immediately or gracefully.

If the Server requests an immediate release, no more messages shall be exchanged and the SIM Access Profile connection shall be released directly after the DISCONNECT_IND message. Furthermore, the Client immediately shall terminate any existing GSM application session, USIM application session or R-UIM application session in order to be compliant to the relevant GSM specifications, 3GPP specifications and 3GPP2 specifications. In this case the RFCOMM channel between the Client and the Server shall be immediately disconnected by the Server.

If the Server requests a graceful connection shutdown, a transfer of APDUs may occur before the Client terminates any existing GSM application session, USIM application session or R-UIM application session and sends the DISCONNECT_REQ message. Finally, the Server shall send a DISCONNECT_RESP message and the SIM Access Profile connection shall be released. Similar to the case of disconnect initiated by the Client, in case of graceful disconnection initiated by the Server the Client shall immediately disconnect the corresponding RFCOMM data channel between the Client and the Server.

If after graceful connection shutdown request from the Server certain amount of time (transmitted APDUs) elapsed and no DISCONNECT_REQ message was received from the Client, the Server may initiate an immediate disconnection by sending the DISCONNECT_IND message with DisconnectionType parameter set to immediate.

Figure 4.3 illustrates how the Server initiates a graceful disconnect from the Client. If an immediate disconnect is desired, the server shall send the DISCONNECT_IND message and end the connection.

Figure 4.3. Client Disconnecting Gracefully from Server (Initiated by the Server)

To transfer an APDU between the Client and the Server, the messages TRANSFER_APDU_ REQ and TRANSFER_APDU _RESP shall be used. ADPU transfers shall be initiated by the Client only.

Both messages contain an APDU (as defined for the GSM application in GSM 11.11 or GSM 11.14 and as defined in ISO/IEC 7816-4 for all other applications) in their payload. The message APDU_TRANSFER_REQ shall be used for Command-APDUs (from Client to the subscription module). The message TRANSFER_APDU_RESP shall be used for Response-APDUs (from the subscription module to the Client).

Figure 4.4 illustrates the successful exchange of APDUs between Client and Server:

Figure 4.4. APDU Transfer between Client and Server

If no error has occurred, the TRANSFER_APDU_RESP message shall contain the result code "OK, request processed correctly" (see Section 5.3.4). In case of an error, the TRANSFER_APDU_RESP message shall contain an appropriate result code (see also Section 5.3.4):

The Client may request the Server to send the ATR from the subscription module. The TRANSFER_ATR_REQ message shall be used for this purpose. Following this request, the Server shall send the ATR to the Client in the payload of the TRANSFER_ATR_RESP message.

Figure 4.5 illustrates the successful ATR transfer:

Figure 4.5. ATR Transfer between Client and Server

If no error has occurred, the TRANSFER_ATR_RESP message shall contain the result code "OK, request processed correctly" (see Section 5.3.4). In case of an error, the TRANSFER_APDU_RESP message shall contain an appropriate result code (see also Section 5.3.4):

If an error has occurred, which cannot adequately be described by any of the previous reasons, the result code "Error, no reason defined" shall be used.

If the Client wants the Server to power off the subscription module, it first shall terminate any existing GSM application session, USIM application session or R-UIM application session which involves the subscription module in the Server.

The Client may then send the POWER_SIM_OFF_REQ message to the Server. Upon receiving this message, the Server shall power off the subscription module, i. e. it removes the voltage from the card. Afterwards, the Server shall send the POWER_SIM_OFF_RESP message to the Client.

Figure 4.6 illustrates the successful case when the Client requests the Server to power off the subscription module:

Figure 4.6. Client Requests Server to Power the SIM Off

If no error has occurred, the POWER_SIM_OFF_RESP message shall contain the result code "OK, request processed correctly" (see Section 5.3.4).

In case of an error, the POWER_SIM_OFF_RESP message shall contain an appropriate result code (see also Section 5.3.4):

If an error has occurred, which cannot adequately be described by any of the previous reasons, the result code "Error, no reason defined" shall be used.

If a subscription module is powered off, the Client may request the Server to power it on again, i. e. to apply the supply voltage and clock signal to the subscription module. The POWER_SIM_ON_REQ message shall be used for this purpose.

Upon receiving this message, the Server powers the subscription module on. The transport protocol which shall be internally used by the server is T=0. To change the transport protocol, the feature ‘Set Transport Protocol’ shall be used. After this has been completed, the Server shall send the POWER_SIM_ON_RESP message to the Client.

If the POWER_SIM_ON_RESP message indicates that the subscription module was powered on successfully (see below), the Client shall request the ATR of the subscription module with the TRANSFER_ATR_REQ message. If the POWER_SIM_ON_RESP message indicates that the SIM doesn’t support the T=0 protocol (see below), the Client may request the ATR of the subscription module with the TRANSFER_ATR_REQ message to retrieve information about the subscription module. In both cases the Server shall answer with the TRANSFER_ATR_RESP message as described in Section 4.5.

Figure 4.7: illustrates the successful case when the Client requests the Server to power on the subscription module:

Figure 4.7. Client Requests Server to Power the SIM On

If no error has occurred, the POWER_SIM_ON_RESP message shall contain the result code "OK, request processed correctly" (see Section 5.3.4).

In case of an error, the POWER_SIM_ON_RESP message shall contain an appropriate result code (see also Section 5.3.4):

If the Client wants the Server to reset the subscription module, it first shall terminate any existing GSM application session, USIM application session or R-UIM application session, which involves the subscription module in the Server.

The Client may then send the RESET_SIM_REQ message to the Server. Upon receiving this message, the Server shall reset the subscription module. The transport protocol which shall be internally used by the server is T=0. To change the transport protocol, the feature ‘Set Transport Protocol’ shall be used. After this has been completed, the Server shall send the RESET_SIM_RESP message to the Client.

If the RESET_SIM_RESP message indicates that the subscription module was reset successfully (see below), the Client shall request the ATR of the subscription module with the TRANSFER_ATR_REQ message. If the RESET_SIM_RESP message indicates that the subscription module doesn’t support the T=0 protocol (see below), the Client may request the ATR of the subscription module with the TRANSFER_ATR_REQ message to retrieve information about the subscription module. In both cases the Server shall answer with the TRANSFER_ATR_RESP message as described in Section 4.5.

Figure 4.8 illustrates the successful case when the Client requests the Server to reset the subscription module:

Figure 4.8. Client Requests the Server to Reset the SIM

If no error has occurred, the RESET_SIM_RESP message shall contain the result code "OK, request processed correctly" (see Section 5.3.4).

In case of an error, the RESET_SIM_RESP message shall contain an appropriate result code (see also Section 5.3.4):

If an error has occurred, which cannot adequately be described by any of the previous reasons, the result code "Error, no reason defined" shall be used.

This procedure is deployed during the connection setup phase (see Section 4.1) or whenever a change in the physical connection between Server and SIM occurs. The STATUS_IND message is used to inform the Client about the status or the status change.

During the connection setup phase (see Section 4.1) three alternatives are possible:

During an ongoing connection, the following changes in the subscription module status can occur:

All of the above cases are independent from those cases, in which the Client detects, that the subscription module is not responding to e. g. Command APDUs. In any case, the behavior of the Client shall be inline with the GSM specifications 3GPP specifications and 3GPP2 specifications [3], [4], [6], [7], [8], [9], [10], [11].

Figure 4.9 illustrates the case when the Server detects a change in the physical connection to the card:

Figure 4.9. Server Reports Status Change to the Client

Please note, that the STATUS_IND message shall not be used in conjunction with a status change due to a POWER_SIM_OFF_REQ, POWER_SIM_ON_REQ or RESET_SIM_REQ message.

The Client may ask the Server to return the Card Reader Status using the TRANSFER_CARD_READER_STATUS_REQ message. Following this request, the Server shall send the Client the Card Reader Status in the TRANSFER_CARD_READER_STATUS_RESP message.

Figure 4.10 shows the allowed signaling flow when the Client requests the Card Reader Status from the Server:

Figure 4.10. Request Card Reader Status

If no error has occurred, the TRANSFER_CARD_READER_STATUS_RESP message shall contain the result code "OK, request processed correctly" (see Section 5.3.4). In case of an error, the TRANSFER_CARD_READER_STATUS_RESP message shall contain an appropriate result code (see also Section 5.3.4):

If the Server cannot send the Card Reader Status for any other reason, the result code "Error, data not available" shall be used.

If any other error has occurred, the result code "Error, no reason defined" shall be used.

The Server shall send an Error Response message ERROR_RESP to the Client whenever it has received a request message from the Client, which was invalid or improperly formatted (see Figure 4.11).

The Client may close the SIM Access Profile Connection after it has received an ERROR_RESP message from the Server.

Figure 4.11. Error Response Message

In all cases, where an error occurred while processing a valid and properly formatted request, the error shall be indicated in the respective response message (e.g. TRANSFER_APDU_RESP).

If the server supports the T=0 protocol, it shall be used as a default protocol (see sections 4.1, 4.7, 4.8). If the server or the subscription module do not support T=0, then the initial STATUS_IND after the CONNECT_RESP shall contain the status “Card not accessible”. The mechanisms described in this chapter shall then be used to select an appropriate protocol.

The client may change the transport protocol, by first terminating any existing GSM application session, USIM application session or R-UIM application session, which involves the subscription module in the Server.

The client shall then send the SET_TRANSPORT_PROTOCOL_REQ with a parameter that specifies the transport protocol which the client wants to use.

If the command is supported by the server, the server shall respond with SET_TRANSPORT_PROTOCOL_RESP and status “OK, request processed correctly”. The server shall then internally perform a reset of the subscription module and issue a STATUS_IND with the status “Card reset”. The client shall then continue with TRANSFER_ATR_REQ.

If the command is supported by the server, but the subscription module does not support the selected transport protocol, the status of the STATUS_IND shall be “Card not accessible”. The client may then send the TRANSFER_ATR_REQ to retrieve information about the subscription module.

If the command is supported by the server, but the required transport protocol is not supported by the server, the server shall respond with the error code “Error, not supported” in the SET_TRANSPORT_PROTOCOL_RESP. Before the subscription module can be accessed again, another SET_TRANSPORT_PROTOCOL_REQ is needed.

If the server does not support the command, it shall respond with ERROR_RESP as described in section 4.11.

Figure 4.12. Set transport protocol

Figure 4.13 shows the simplified state machine underlying the SIM Access Profile. The three main states are "Not connected", "Connection under negotiation" and "Connected". Within the "Connected" state, several sub-states exist.

Figure 4.13. Simplified State Machine

As it can be seen from the state machine, each request message (e. g. TRANSFER_APDU_REQ) can in general only be followed by the corresponding response message (TRANSFER_APDU_RESP). However, there are two exceptions. The POWER_SIM_OFF_REQ and RESET_SIM_REQ can be sent in nearly any state, in order to allow the Client to reactivate a not accessible subscription module card.

For simplicity reasons, the messages DISCONNECT_REQ, DISCONNECT_IND, DISCONNECT_RESP, STATUS_IND and ERROR_RESP are not included in the figure. The usage of these messages is as follows:

The Server or the Client can detect a Bluetooth link loss. Whenever either device detects a Bluetooth link loss, the SIM Access Profile connection shall be terminated by that device.

Messages are formatted as shown in Figure 5.1 (length of each field is given in bytes):

Figure 5.1. Message Format

The message header consists of three fields. The field "MsgID" contains the message ID as given in Section 5.2. The field "Number of Parameters" gives the number of parameters in the payload of the message.

Two bytes are reserved for future use and shall be set to 0x0000 until otherwise specified in future revisions of the SIM Access Profile.

The payload itself contains the parameters as listed in the following Sections. Each Parameter is formatted as shown in Figure 5.2 using three fields:

Figure 5.2. Payload Coding

The fields "Parameter ID", "Parameter Length", "Parameter Value", the reserved field and the "Padding Bytes" are repeated for each parameter. The ordering of the parameters shall be as listed in the tables in Section 5.2.

The reserved field and the padding bytes shall be set to 0x00 until otherwise specified in future revisions of the SIM Access Profile.

The "Parameter ID" shall contain the ID of the parameter as listed in Section 5.3. The "Parameter Length" field gives the length of the "Parameter Value" (see Section 5.3).

The length of each Parameter shall be a multiple of four bytes. Therefore, one to three additional bytes have to be added directly after the "Parameter Value".

This section defines the allowed messages in the SIM Access Profile. It is mandatory to implement a message, if the respective procedure is supported by the device.

The following table lists all parameters used in the messages of the SIM Access Profile, their length (in Bytes) and Parameter ID.

Figure 5.3: gives an example of a SIM Access Profile message. It shows the CONNECT_REQ message with the parameter MaxMsgSize=280 (decimal). The values for MsgID and ParameterID are as given in Chapter 5.

Figure 5.3. Message Example

For RFCOMM, no additions to the requirements stated in the Serial Port Profile apply.

For the L2CAP layer, no additions to the requirements stated in the Serial Port Profile apply.

In addition to the LM Interoperability Requirements stated in the Serial Port Profile, this profile mandates the use of link encryption using a standard combination key or an authenticated combination key.

For the Link Controller, no additions to the requirements stated in the Serial Port Profile apply.

Table 8.1 shows the support status for Modes within the SIM Access Profile.

Table 8.2 shows the support status for Security aspects within the SIM Access Profile. Security Mode 2, or 3 or 4 shall be used for a SIM Access Profile connection.

Table 8.3 shows the support status for Idle mode procedures within the SIM Access Profile (see Section 6 of the Generic Access Profile [1]).