6 Proactive SIM

3GPP51.014Release 4Specification of the SIM Application Toolkit for the Subscriber Identity Module - Mobile Equipment (SIM - ME) interfaceTS

6.1 Introduction

TS 51.011 [20] defines the communication protocols between the ME and the SIM, and defines a mechanism to transport "proactive" commands using these protocols.The SIM can issue a variety of commands through this mechanism, given in alphabetical order:

CLOSE CHANNEL, which requests the ME to close the specified data channel (if class "e" is supported).

DISPLAY TEXT, which displays text or an icon on screen. A high priority is available, to replace anything else on screen.

GET CHANNEL STATUS, which requests the ME to return the current status of all available data channel(s) (if class "e" is supported).

GET INKEY, which sends text or an icon to the display and requests a single character response in return. It is intended to allow a dialogue between the SIM and the user, particularly for selecting an option from a menu.

GET INPUT, which sends text or an icon to the display and requests a response in return. It is intended to allow a dialogue between the SIM and the user.

GET READER STATUS, which gives information about the additional reader(s) and inserted card(s) (Card x state, e.g. powered on or not, Card x Presence), if class "a" is supported.

LANGUAGE NOTIFICATION, which allows the SIM to notify the ME about the currently used language in text strings issued by the SIM Application Toolkit application.

  • LAUNCH BROWSER, which requests a browser inside a browser enabled ME to interpret the content corresponding to a URL.

MORE TIME, which does not request any action from the ME. The ME is required to respond with TERMINAL RESPONSE (OK) as normal – see below. The purpose of the MORE TIME command is to provide a mechanism for the SIM Application Toolkit task in the SIM to request more processing time.

OPEN CHANNEL, which requests the ME to open a data channel with parameters indicated in the command (if class "e" is supported.)

PERFORM CARD APDU, which requests the ME to send an APDU command to the additional card, if class "a" is supported. This command is compatible with any protocol between the ME and the additional card.

PLAY TONE, which requests the ME to play a tone in its earpiece, ringer, or other appropriate loudspeaker.

POLL INTERVAL, which negotiates how often the ME sends STATUS commands to the SIM during idle mode. Polling is disabled with POLLING OFF. Use of STATUS for the proactive SIM is described in TS 51.011 [20].

POWER OFF CARD, which closes the session with the additional card, if class "a" is supported.

POWER ON CARD, which initiates a session with the additional card and returns all the ATR bytes, if class "a" is supported.

PROVIDE LOCAL INFORMATION which requests the ME to pass local information to the SIM, for example the mobile country and network codes (MCC + MNC) of the network on which the user is registered.

RECEIVE DATA, which requests the ME to return to the SIM data received on the specified channel (if class "e" is supported).

REFRESH, which requests the ME to carry out a SIM initialization according to TS 51.011 , and/or advises the ME that the contents or structure of EFs on the SIM have been changed. The command also makes it possible to restart a card session by resetting the SIM.

RUN AT COMMAND, which will convey an AT Command to the ME, and cause the response to the AT Command to be returned to the SIM.

SELECT ITEM, where the SIM supplies a list of items, and the user is expected to choose one. The ME presents the list in an implementation-dependent way.

SEND DATA, which requests the ME to send on the specified channel data provided by the SIM (if class "e" is supported).

SEND DTMF, which requests the ME to send DTMF tone(s) during an established call.

SEND SHORT MESSAGE, which sends a short message or SMS-COMMAND to the network.

SEND SS, which sends an SS request to the network.

SEND USSD, which sends a USSD string to the network.

SET UP CALL, of which there are three types:

– set up a call, but only if not currently busy on another call;

– set up a call, putting all other calls (if any) on hold;

– set up a call, disconnecting all other calls (if any);

SET UP EVENT LIST where theSIMsupplies a list of events which it wants the ME to provide details of when these events happen.

SET UP IDLE MODE TEXT, which supplies a text string to be used by the ME as stand-by mode text.

SET UP MENU, where the SIM supplies a list of items to be incorporated into the ME’s menu structure.

TIMER MANAGEMENT, which requests the ME to manage a timer in a way described in the command (start, deactivate and get the current value) and, in the case of starting a timer, for a duration indicated in the command.

The ME tells the SIM if the command was successful or not using the command result procedure defined in subclause 6.7. Responsibility for what happens after that (whether to repeat the command, try another one immediately, try again sometime later, or not to try again at all) lies with the SIM application. However, the SIM application needs to know why the command failed, so the ME provides the SIM with the result of the command.

Results are grouped into three main types:

– OK.

– Temporary problem. These results are further broken down into types of temporary problems, and specific causes. Generally, they indicate to the SIM that it may be worth trying again.

– Permanent problem. These results are again further broken down into types of permanent problems, and specific causes. Generally, they indicate to the SIM that it is not worth trying again during this GSM session.

If the SIM issues an instruction to the ME to initiate a Mobile Originated transaction (e.g. SEND SMS, SEND USSD or SEND DTMF), then unless explicitly stated elsewhere in the present document or in TS 51.011 [20], the content supplied by the SIM for onward transmission by the ME shall not be altered by the ME.

6.2 Identification of proactive SIMs and of ME support

See TS 102 223 [37].

6.3 General procedure

See TS 102 223 [37].

6.4 Proactive SIM commands and procedures

6.4.1 DISPLAY TEXT

See TS 102 223 [37].

6.4.2 GET INKEY

See TS 102 223 [37].

6.4.3 GET INPUT

See TS 102 223 [37].

6.4.4 MORE TIME

See TS 102 223 [37].

6.4.5 PLAY TONE

See TS 102 223 [37].

6.4.6 POLL INTERVAL

See TS 102 223 [37].

6.4.7 REFRESH

The purpose of this command is to enable the ME to be notified of the changes to the SIM configuration that have occurred as the result of a SIM application activity. It is up to the SIM application to ensure that this is done correctly.

The command supports five different modes:

– SIM Initialization. This mode tells the ME to carry out SIM initialization as it is defined in TS 51.011 [20], starting after the CHV1 verification procedure. The ME shall not reset the SIM electrically.

– File Change Notification. This mode advises the ME of the identity of the EFs that have been changed (in structure and/or contents) in the SIM. This information can be used by the ME if there is an image of SIM EFs (e.g. the ADN file) in the ME’s memory, to determine whether it needs to update this image.

– SIM Initialization and File Change Notification. This is a combination of the first two modes above.

– SIM Initialization and Full File Change Notification. This mode causes the ME to perform the SIM initialization procedure of the first mode above and advises the ME that several EFs have been changed (in structure or contents) in the SIM. If there is an image of SIM EFs in the ME’s memory, the ME shall completely update this image.

– SIM Reset. This mode causes the ME to run the GSM session termination procedure and to deactivate the SIM in accordance with TS 51.011 [20]. Subsequently, the ME activates the SIM again and starts a new card session. In case of a 3 Volt technology ME, the ME shall restart the SIM with the same supply voltage as in the previous session, if the ME can ensure that the SIM has not been changed in between. Otherwise, the ME shall perform the supply voltage switching in accordance with TS 11.12 [21]. The ME shall not send the TERMINAL RESPONSE; this is an exception from the normal procedure, where TERMINAL RESPONSE is sent after completion of the command. The SIM Application shall interpret a new activation of the contacts of the SIM as an implicit TERMINAL RESPONSE. The SIM Reset mode is used when a SIM application requires ATR or complete SIM initialization procedures to be performed. SIM Applications should take into account that early implementations of SIM Application Toolkit in some MEs may send a TERMINAL RESPONSE after performing the REFRESH command involving resetting the SIM electrically.

If the ME performs the REFRESH command successfully for only those EFs indicated in the mode, the ME shall inform the SIM using TERMINAL RESPONSE (OK), after it has completed its refreshing.

For REFRESH commands with mode other than "SIM Reset", it is permissible for the ME, as part of its execution of the REFRESH command, to read EFs in addition to those notified by the SIM, or to perform a SIM initialisation, provided that the procedure executed wholly encompasses the mode requested by the SIM. The ME shall not electrically reset the SIM. If the ME does the refreshing successfully, it shall inform the SIM using TERMINAL RESPONSE (Refresh performed with additional EFs read), after the ME has completed its refreshing. It should be noted that reading additional EFs will lengthen the refresh procedure.

If the ME receives a REFRESH command while in a state where execution of the command would be unacceptable, upsetting the current user operation (e.g. notification during a call that the IMSI has changed), the ME shall inform the SIM using TERMINAL RESPONSE (ME currently unable to process command – currently busy on call) or TERMINAL RESPONSE (ME currently unable to process command – screen is busy) as appropriate.

NOTE: Many MEs copy an image of the SIM’s memory to the ME at initialization to speed up access to these fields during a GSM session. One of the purposes of this coding of the REFRESH command is to enable MEs to change such an image efficiently.

If, on receipt of the REFRESH command, the ME replies that it is busy (e.g. in call or navigating menus), the toolkit application may shorten the polling interval utilising the POLL INTERVAL command in order to resend the REFRESH command more frequently.

It is recommended for the ME to minimise the use of sending temporary problem TERMINAL RESPONSE, as during the period between the SIM issuing a REFRESH command and the ME performing the refresh procedure, there may be inconsistencies between data held in the ME and in the SIM. However, responsibility for retrying of all pro-active commands lies with the SIM Application.

6.4.7.1 EFIMSI changing procedure

When EFIMSI is changed via Data Download or a SIM Toolkit application and a REFRESH command is issued by the SIM the following rules apply to the SIM Toolkit and ME:

– SIM Initialization. This command shall not be used if EFIMSI is changed, as the behaviour of the MS is unpredictable.

– File Change Notification. This command shall not be used if EFIMSI is changed, as the behaviour of the MS is unpredictable.

– SIM Initialization and File Change Notification. If EFIMSI is part of the file change notification, the ME shall invoke the MM Restart procedure defined in 03.22 [28].

– SIM Initialization and Full File Change Notification. The ME shall invoke the MM Restart procedure defined in 03.22 [28].

– SIM Reset. Normal SIM Reset procedure is carried out.

If EFIMSI is to be updated, neither EFIMSI nor EFLOCI shall be updated in the SIM before the phase request procedure has been executed by the ME.

6.4.8 SET UP MENU

See TS 102 223 [37].

6.4.9 SELECT ITEM

See TS 102 223 [37].

6.4.10 SEND SHORT MESSAGE

This command requests the ME to send a short message.

Two types are defined in TS 102 223 [37] and apply as follows within the context of this specification:

– a short message to be sent to the network in an SMS-SUBMIT message, or an SMS-COMMAND message, where the user data can be passed transparently;

– a short message to be sent to the network in an SMS-SUBMIT message where the text needs to be packed by the ME.

Where the text has been packed, the text string provided by the SIM shall not be longer than 160 characters. It shall use the SMS default 7-bit coded alphabet, packed into 8-bit octets, in accordance with TS 23.038 [5]. The data coding indication contained in the Data Coding Scheme byte shall be "default alphabet". The text length (which is part of the SMS TPDU) given by the SIM shall state the number of 7-bit characters in the text string. The command details shall indicate "packing not required".

8-bit data Short Messages may be sent by the SIM. The command shall indicate packing not required. The data coding indication contained in the Data Coding Scheme byte shall be "8 bit". The string shall not be longer than 140 bytes, and the length (in SMS TPDU) shall state the number of bytes in the string.

If UCS2 is supported by the ME, 16-bit data Short Messages may be sent by the SIM. The text string provided by the SIM shall not be longer than 70 characters. It shall use the 16-bit UCS2 alphabet format, in accordance with TS 23.038 [5]. The text length (which is part of the SMS TPDU) given by the SIM shall state the number of 16-bit characters in the text string. The command details shall indicate "packing not required".

SMS commands may be sent by the SIM. These shall count as packed text message. The SMS TPDU from the SIM shall indicate SMS-COMMAND. The command details shall indicate "packing not required".

Where packing by the ME is required, the text string provided by the SIM shall not be longer than 160 characters. It shall use the SMS default 7-bit coded alphabet as defined in TS 23.038 [5] with bit 8 set to 0. The text length given by the SIM shall state the number of characters in the text string. The ME shall pack the text string and modify the Data Coding Scheme byte to "default alphabet" in accordance with TS 23.038 [5] before submitting the message to the network.

Optionally, the SIM may include in this command an alpha identifier. See TS 102 223 [37] for the use of this alpha identifier.

If the ME is capable of SMS-MO, then it shall send the data as a Short Message TPDU to the destination address. The ME shall give the result to the SIM using TERMINAL RESPONSE (indicating successful or unsuccessful transmission of the Short Message) after receiving an SMS RP-ACK or RP-Error from the network. If an alpha identifier was provided by the SIM, the ME should not give any information to the user at the reception of SMS RP-ACK or RP-Error.

If the Short Message TPDU is unsuccessfully received by the network (e.g. the reception of a CP-ERROR), the ME shall inform the SIM using TERMINAL RESPONSE (network currently unable to process command). If a null alpha identifier was provided by the SIM, the ME should not give any information to the user at the unsuccessful network reception.

6.4.11 SEND SS

Upon receiving this command, the ME shall decide if it is able to execute the command. Examples are given below, but the list is not exhaustive:

– if the command is rejected because the ME is busy on an SS transaction, the ME informs the SIM using TERMINAL RESPONSE (ME unable to process command – currently busy on SS transaction);

– if the command is rejected because the ME is busy on a USSD transaction, the ME shall inform theSIMusing TERMINAL RESPONSE (ME unable to process command – currently busy on USSD transaction);

– if the command is rejected because the ME does not support that Supplementary Service, the ME informs the SIM using TERMINAL RESPONSE (Command beyond ME’s capabilities).

If the ME is able to send the SS request, the ME shall:

– send the SS request immediately, without need to alert the user first;

– optionally, the SIM may include in this command an alpha-identifier. The use of this alpha-identifier by the ME is described below:

– if the alpha identifier is provided by the SIM and is not a null data object, the ME shall use it to inform the user. This is also an indication that the ME should not give any other information to the user on the fact that the ME is sending a SS request. If an icon is provided by the SIM, the icon indicated in the command may be used by the ME to inform the user, in addition to, or instead of the alpha identifier, as indicated with the icon qualifier (see subclause 6.5.4);

– if the alpha identifier is provided by the SIM and is a null data object (i.e. length = ’00’ and no value part), this is an indication that the ME should not give any information to the user on the fact that the ME is sending an SS request;

– if the alpha identifier is not provided by the SIM, the ME may give information to the user concerning what is happening.

– once an SS Return Result message not containing an error has been received from the network, the ME shall inform the SIM that the command has been successfully executed, using TERMINAL RESPONSE. This command shall include the contents of SS Return Result as additional data.
If a null alpha identifier was provided by the SIM, the ME should not give any information to the user at the reception of an SS Return Result message;

– if the command is rejected because the network cannot support or is not allowing the Supplementary Service request, the ME informs the SIM using TERMINAL RESPONSE (SS Return Result error code).
If a null alpha identifier was provided by the SIM, the ME should not give any information to the user at the reception of a SS Return Result message;

– if the SS request is unsuccessfully received by the network, the ME shall inform the SIM using TERMINAL RESPONSE (network currently unable to process command), and not retry to send the request.
If a null alpha identifier was provided by the SIM, the ME should not give any information to the user at the reception of a SS Return Result message.

If the ME supports the Last Number Dialled service, the ME shall not store in EFLND the supplementary service control string sent by the SIM in this command.

The supplementary service control string included in the SEND SS proactive command shall not be checked against those of the FDN list, even if the Fixed Dialling Number service is enabled.

6.4.12 SEND USSD

Upon receiving this command, the ME shall decide if it is able to execute the command. Examples are given below, but the list is not exhaustive:

– If the command is rejected because the ME is busy on a USSD transaction, the ME informs theSIMusing TERMINAL RESPONSE (ME unable to process command – currently busy on USSD transaction);

– If the command is rejected because the ME is busy on a SS transaction, the ME informs the SIM using TERMINAL RESPONSE (ME unable to process command – currently busy on SS transaction).

If the ME is able to send the USSD request, the ME shall:

– send the USSD immediately, without need to alert the user first;

– optionally, the SIM may include in this command an alpha-identifier. The use of this alpha-identifier by the ME is described below:

– If the alpha identifier is provided by the SIM and is not a null data object, the ME shall use it to inform the user. This is also an indication that the ME should not give any other information to the user on the fact that the ME is sending a USSD request. If an icon is provided by the SIM, the icon indicated in the command may be used by the ME to inform the user, in addition to, or instead of the alpha identifier, as indicated with the icon qualifier (see subclause 6.5.4).

– If the alpha identifier is provided by the SIM and is a null data object (i.e. length = ’00’ and no value part), this is an indication that the ME should not give any information to the user on the fact that the ME is sending a USSD request.

– If the alpha identifier is not provided by the SIM, the ME may give information to the user concerning what is happening.

– once the USSD transaction is initiated, a dialogue between the network and the user may occur which involves the MMI of the ME. If an alpha identifier was initially provided by the SIM, this alpha identifier may be discarded during this dialogue;

– once a RELEASE COMPLETE message containing the USSD Return Result message not containing an error has been received from the network, the ME shall inform the SIM that the command has been successfully executed, using TERMINAL RESPONSE. This command shall include the text contained in the USSD Return Result in a Text String data object. If a null alpha identifier was provided by the SIM, the ME should not give any information to the user at the reception of a USSD Return Result message;

– if the MS clears the transaction by sending a RELEASE COMPLETE upon request of the user, the ME shall inform the SIM using TERMINAL RESPONSE (USSD transaction terminated by user);

– if the USSD operation is rejected because the network cannot support or is not allowing mobile initiated USSD, the ME informs the SIM using TERMINAL RESPONSE (USSD Return Result error code). If a null alpha identifier was provided by the SIM, the ME should not give any information to the user at the reception of a USSD Return Result message;

– if the USSD request is unsuccessfully received by the network, the ME shall inform the SIM using TERMINAL RESPONSE (network currently unable to process command), and not retry to send the request. If a null alpha identifier was provided by the SIM, the ME should not give any information to the user at the reception of a USSD Return Result message.

6.4.13 SET UP CALL

This command is issued by the SIM to request a call set up. The procedure is defined in TS 102 223 [37], except when stated otherwise in the present document.

If the Fixed Dialling Number service is enabled, the number included in the SET UP CALL proactive command shall not be checked against those of the FDN list.

Upon receiving this command, the ME shall decide if it is able to execute the command. Examples are given below, but the list is not exhaustive:

– If the command is rejected because the ME is busy on another call, the ME informs the SIM using TERMINAL RESPONSE (ME unable to process command – currently busy on call);

– If the command is rejected because the ME is busy on a SS transaction, the ME informs the SIM using TERMINAL RESPONSE (ME unable to process command – currently busy on SS transaction);

– If the command is rejected because the ME cannot support Call Hold, because the ME does not support Called Party Subaddress or because the ME does not support the capability configuration parameters requested by the SIM, the ME informs the SIM using TERMINAL RESPONSE (Command beyond ME’s capabilities);

– If the command is rejected because the network cannot support or is not allowing Call Hold of a multi party call, the ME informs the SIM using TERMINAL RESPONSE (SS Return Result error code).

– If the command is rejected because the network cannot support or is not allowing Call Hold of a single call, the ME informs the SIM using TERMINAL RESPONSE (Network currently unable to process command).

If the ME is able to set up the call on the serving network, the ME shall:

– Alert the user (as for an incoming call). This is the confirmation phase.

– Optionally, the SIM may include in this command an alpha-identifier. The use of this alpha-identifier by the ME is described below :

If Second Alpha Identifier in SET UP CALL is supported by ME:

– If the first alpha identifier is provided by the SIM and is not a null data object, the ME shall use it during the user confirmation phase. This is also an indication that the ME should not give any other information to the user during the user confirmation phase. If an icon is provided by the SIM, the icon indicated in the command may be used by the ME to inform the user, in addition to, or instead of the alpha identifier, as indicated with the icon qualifier (see subclause 6.5.4).

– If the first alpha identifier is not provided by the SIM or is a null data object (i.e. length = ’00’ and no value part), the ME may give information to the user.

– If the second alpha identifier (i.e the one after the mandatory address object) is provided by theSIMand is not a null data object, the ME shall use it during the call set-up phase and during the call. If an icon is provided by the SIM, the icon indicated in the command may be used by the ME to inform the user, in addition to, or instead of the alpha identifier, as indicated with the icon qualifier (see subclause 6.5.4).

– If the second alpha identifier is not provided by the SIM or is a null data object (i.e. length = ’00’ and no value part), the ME may give information to the user.

If Second Alpha Identifier in SET UP CALL is not supported by ME:

– If the alpha identifier is provided by the SIM, the ME shall use it to inform the user, at the latest when the user is alerted. The ME may also use it to inform the user during the call set-up. If an icon is provided by the SIM, the icon indicated in the command may be used by the ME to inform the user, in addition to, or instead of the alpha identifier, as indicated with the icon qualifier (see subclause 6.5.4).

– If the user accepts the call, the ME shall then set up a call to the destination address given in the response data, with the relevant capability configuration parameters and called party subaddress (if provided by the SIM);

– If the user does not accept the call, or rejects the call, then the ME informs the SIM using TERMINAL RESPONSE (user did not accept the proactive command). The operation is aborted;

– If the user has indicated the need to end the proactive SIM session, the ME shall send a TERMINAL RESPONSE with "Proactive SIM session terminated by the user" result value.

– Optionally, during call set-up, the ME can give some audible or display indication concerning what is happening;

– Once a CONNECT message has been received from the network (defined in TS 04.08), the ME shall inform the SIM that the command has been successfully executed, using TERMINAL RESPONSE. Operation of the call then proceeds as normal.

6.4.14 POLLING OFF

See TS 102 223 [37].

6.4.15 PROVIDE LOCAL INFORMATION

This command requests the ME to send current local information to the SIM. At present, this information is restricted to:

– location information: the mobile country code (MCC), mobile network code (MNC), location area code (LAC) and cell ID of the current serving cell;

– the IMEI of the ME;

– the Network Measurement Results and the BCCH channel list;

– the current date, time and time zone;

– the current ME language setting;

– the Timing Advance;

  • and the current access technology.

The ME shall return the requested local information within a TERMINAL RESPONSE. Where location information or Network Measurement Results has been requested and no service is currently available, then the ME shall return TERMINAL RESPONSE (ME currently unable to process command – no service). Where location information or Network Measurement Results has been requested and the ME is on limited service (e.g. emergency calls only), the ME shall return the data requested in the TERMINAL RESPONSE with the general result (Limited Service).

If the NMR are requested and a call is in progress, the value of all the returned parameters provided by the ME in the response to the command will be valid. The NMR returned when a call is in progress from MEs supporting multiband operation, shall be according to the value of the multiband reporting parameter as defined in TS 04.08 [8]. If a call is not in progress (i.e. ME is in idle mode) some of the returned parameters (e.g. RXQUAL) may be invalid. In idle mode, MEs supporting multiband operation shall ignore the value of the multiband reporting parameter and the NMR returned shall be as defined in TS 04.08 [8] when the multiband reporting parameter equals zero.

NOTE 1: When in idle mode, the only information element on which it is possible to rely on is the RXLEV-FULL-SERVING-CELL, which contains the value of the received signal strength on the BCCH of the current serving cell.

NOTE 2: Network Measurement Results are defined in TS 04.08 [8] as Measurement Results.

The ME shall return the current date and time as set by the user. If available, the ME shall also return the time zone known from the network with the NITZ feature (see TS 22.042 [26]). If the time zone information is not available, the ME shall return ‘FF’ for this element.

If language setting is requested, the ME shall return the currently used language.

If the Timing Advance is requested, the ME shall return the timing advance value that was received from the BTS during the last active dedicated connection (e.g. for call or SMS). Timing advance is defined in TS 04.08 [8]. An ME supporting the Timing Advance feature shall be able to store the last value of timing advance. In addition to the timing advance value, the ME shall return its current status (i.e. ME is in idle mode or not) in order for the application to be aware of potential misinterpretation of the timing advance value. Caution should be taken if using the Timing Advance value for distance measurement as reflections from the external environment (buildings etc.) may affect the accuracy.

If the access technology is requested, the ME shall return the current access technology that the ME is using.

6.4.16 SET UP EVENT LIST

See TS 102 223 [37].

6.4.17 PERFORM CARD APDU

See TS 102 223 [37].

6.4.18 POWER OFF CARD

See TS 102 223 [37].

6.4.19 POWER ON CARD

See TS 102 223 [37].

6.4.20 GET READER STATUS

See TS 102 223 [37].

6.4.21 TIMER MANAGEMENT

See TS 102 223 [37].

6.4.22 SET UP IDLE MODE TEXT

See TS 102 223 [37].

6.4.23 RUN AT COMMAND

See TS 102 223 [37].

6.4.24 SEND DTMF

See TS 102 223 [37].

6.4.25 LANGUAGE NOTIFICATION

See TS 102 223 [37].

6.4.26 LAUNCH BROWSER

Upon receiving this command, the ME shall decide if it is able to execute the command. Examples are given below, but the list is not exhaustive:

– if the command is rejected because the browser on the ME is busy or not available, the ME informs the SIM using TERMINAL RESPONSE (ME unable to process command – browser unavailable ;

– if the command is rejected because the ME is busy on a SS transaction, the ME informs the SIM using TERMINAL RESPONSE (ME unable to process command – ME currently unable to process command);

– if the command is rejected because the bearer provided in the command is not available, the ME informs the SIM using TERMINAL RESPONSE (ME unable to process command – bearer unavailable).

If the ME is able to execute the command:

– the ME shall inform the SIM that the command has been successfully taken into account, using TERMINAL RESPONSE;

– the SIM shall end the proactive session;

– the ME shall request content using the URL.

If the gateway addresses and/or the bearer objects are present in the command and are non null data objects, then the browser shall use these data to request content using the URL. If the gateway adresses, bearer objects, Provisioning File Reference, Browser Identity or URL are null objects or missing, then the ME shall use the default values, i.e. the provisionning data defined in [32] for exemple.

The way the ME requests content using the URL is out of the scope of the present document. This is specified in RFC 1738 [32] Annex K for example.

NOTE: There is a maximum size for the URL that can be given in argument of this proactive command.

6.4.27 OPEN CHANNEL

6.4.27.1 OPEN CHANNEL for CSD

This subclause applies only if class "e" is supported.

This command is issued by the SIM to request a channel opening. The procedure is defined in TS 102 223 [37], except when stated otherwise in the present document.

The SIM may request the use of an automatic reconnection mechanism according to TS 22.001 [38].

Upon receiving this command, the ME shall decide if it is able to execute the command. In addition to the examples given in TS 102 223 [37] the following example applies:

– If the command is rejected because the ME is busy on a SS transaction, the ME informs the SIM using TERMINAL RESPONSE (ME unable to process command – currently busy on SS transaction). The operation is aborted;

6.4.27.2 OPEN CHANNEL related to GPRS

The procedures defined in TS 102 223 [37] apply, understanding that:

– "packet data service" means GPRS,

– "activation of packet data service" means activation of a PDP context.

Upon receiving this command, the ME shall decide if it is able to execute the command. In addition to the examples given in TS 102 223 [37] the following example applies:

– If the command is rejected because the class B ME is busy on a SS transaction, the ME informs the SIM using TERMINAL RESPONSE (ME unable to process command – currently busy on SS transaction). The operation is aborted;

6.4.27.3 OPEN CHANNEL related to Default (network) Bearer

This subclause applies only if class "e" is supported.

Upon receiving this command, the ME shall decide if it is able to execute the command. The SIM shall indicate whether the ME should establish the link immediately or upon receiving the first transmitted data (on demand).

The ME is responsible for providing the parameters necessary to establish the connection (e.g. APN for GPRS, Address for CSD, …).

Upon receiving this command, the ME shall decide if it is able to execute the command. Example behaviours are listed in clauses for the selected bearer.

The ME shall inform the SIM that the command has been successfully executed using TERMINAL RESPONSE:

– If immediate connection is requested (link establishment or PDP context activation), the ME allocates buffers, sets up the link or activates the PDP context (depending of the kind of connection), and informs the SIM and reports the channel identifier using TERMINAL RESPONSE (Command performed successfully);

– If on demand connection is requested (link establishment or PDP context activation), the ME allocates buffers, informs the SIM and reports the channel identifier using TERMINAL RESPONSE (Command performed successfully);

If the ME is able to set up the channel on the serving network, the ME shall follow the different actions of the chosen bearer (see appropriate sections).

6.4.27.4 OPEN CHANNEL related to local bearer

See TS 102 223 [37].

6.4.28 CLOSE CHANNEL

See TS 102 223 [37].

6.4.29 RECEIVE DATA

See TS 102 223 [37].

6.4.30 SEND DATA

See TS 102 223 [37].

6.4.31 GET CHANNEL STATUS

See TS 102 223 [37].

6.4.32 SERVICE SEARCH

See TS 102 223 [37].

6.4.33 GET SERVICE INFORMATION

See TS 102 223 [37].

6.4.34 DECLARE SERVICE

See TS 102 223 [37].

6.5 Common elements in proactive SIM commands

6.5.1 Command number

See TS 102 223 [37].

6.5.2 Device identities

See TS 102 223 [37].

Device Identities are given in clause 14 of the present document.

6.5.3 Alpha identifier

See TS 102 223 [37].

6.5.4 Icon identifiers

See TS 102 223 [37].

6.6 Structure of proactive SIM commands

The general structure of proactive SIM commands using TLV objects is described in Annex D.

The structure of the commands is described hereafter. For some commands, additionnal TLV objects are defined in TS 102 223 [37].

6.6.1 DISPLAY TEXT

See TS 102 223 [37].

6.6.2 GET INKEY

See TS 102 223 [37].

6.6.3 GET INPUT

See TS 102 223 [37].

6.6.4 MORE TIME

See TS 102 223 [37].

6.6.5 PLAY TONE

See TS 102 223 [37].

6.6.6 POLL INTERVAL

See TS 102 223 [37].

6.6.7 SET-UP MENU

See TS 102 223 [37].

6.6.8 SELECT ITEM

See TS 102 223 [37].

6.6.9 SEND SHORT MESSAGE

Description

Section

M/O

Min

Length

Proactive SIM command Tag

13.2

M

Y

1

Length (A+B+C+D+E+F)

M

Y

1 or 2

Command details

12.6

M

Y

A

Device identities

12.7

M

Y

B

Alpha identifier

12.2

O

N

C

Address

12.1

O

N

D

SMS TPDU (SMS-SUBMIT or SMS-COMMAND)

12.13

M

Y

E

Icon identifier

12.31

O

N

F

The address data object holds the RP_Destination_Address of the Service Centre. If no RP_Destination_Address is transferred, then the ME shall insert the default Service Centre address.

6.6.10 SEND SS

Description

Section

M/O

Min

Length

Proactive SIM command Tag

13.2

M

Y

1

Length (A+B+C+D+E)

M

Y

1 or 2

Command details

12.6

M

Y

A

Device identities

12.7

M

Y

B

Alpha identifier

12.2

O

N

C

SS string

12.14

M

Y

D

Icon identifier

12.31

O

N

E

6.6.11 SEND USSD

Description

Section

M/O

Min

Length

Proactive SIM command Tag

13.2

M

Y

1

Length (A+B+C+D+E)

M

Y

1 or 2

Command details

12.6

M

Y

A

Device identities

12.7

M

Y

B

Alpha identifier

12.2

O

N

C

USSD String

12.17

M

Y

D

Icon identifier

12.31

O

N

E

6.6.12 SET UP CALL

See TS 102 223 [37].

6.6.13 REFRESH

Description

Section

M/O

Min

Length

Proactive SIM command Tag

13.2

M

Y

1

Length (A+B+C)

M

Y

1 or 2

Command details

12.6

M

Y

A

Device identities

12.7

M

Y

B

File List

12.18

M/O

N

C

For the refresh modes "File Change Notification" and "SIM Initialization and File Change Notification", the SIM shall supply a File List data object, indicating which EFs need to be refreshed. For other modes, inclusion of a File List is optional, and the ME shall ignore it.

6.6.14 POLLING OFF

See TS 102 223 [37].

6.6.15 PROVIDE LOCAL INFORMATION

See TS 102 223 [37].

6.6.16 SET UP EVENT LIST

See TS 102 223 [37].

6.6.17 PERFORM CARD APDU

This subclause applies only if class "a" is supported.

See TS 102 223 [37].

6.6.18 POWER OFF CARD

This subclause applies only if class "a" is supported.

See TS 102 223 [37].

6.6.19 POWER ON CARD

This subclause applies only if class "a" is supported.

See TS 102 223 [37].

6.6.20 GET READER STATUS

This subclause applies only if class "a" is supported.

See TS 102 223 [37].

6.6.21 TIMER MANAGEMENT

See TS 102 223 [37].

6.6.22 SET UP IDLE MODE TEXT

See TS 102 223 [37].

6.6.23 RUN AT COMMAND

This subclause applies only if class "b" is supported.

See TS 102 223 [37].

6.6.24 SEND DTMF COMMAND

See TS 102 223 [37].

6.6.25 LANGUAGE NOTIFICATION

See TS 102 223 [37].

6.6.26 LAUNCH BROWSER

See TS 102 223 [37].

The ME shall ask the user for confirmation using the Alpha Identifier/Icon Identifier (user confirmation phase) if present, when it receives a LAUNCH BROWSER command which requests the existing browser session connected to a new URL or to terminate a browser session.

6.6.27 OPEN CHANNEL

6.6.27.1 OPEN CHANNEL related to a CS bearer

See TS 102 223 [37].

6.6.27.2 OPEN CHANNEL related to GPRS

Description

Section

M/O

Min

Length

Proactive SIM command Tag

13.2

M

Y

1

Length (A+B+C+D+E+F+G+H+I+J+K+L)

M

Y

1 or 2

Command details

12.6

M

Y

A

Device identities

12.7

M

Y

B

Alpha identifier

12.2

O

N

C

Icon identifier

12.31

O

N

D

Bearer description

12.52

M

Y

E

Buffer size

12.55

M

Y

F

Network Access Name

12.61

O

N

G

Other address (local address)

12.58

O

N

H

Text String (User login)

12.15

O

N

I

Text String (User password)

12.15

O

N

J

SIM/ME interface transport level

12.59

O

N

K

Data destination address

12.58

O

N

L

The Network Access Name parameter may be requested. The Network Access Name parameter contains an Access Point Name (APN) identifying the Gateway GSN (GGSN) which provides interworking with an external packet data network. If the parameter is not present, the mobile may use the default Access Point Name in the mobile configuration or the default subscription value.

The local address parameter (see 12.58) provides information to the ME necessary to identify the local device. If the parameter is present and length is not null, it provides an IP address that identifies the SAT application in the address area applicable to the PDN. If local address length is null, dynamic local address allocation is required for the SAT application. If parameter is not present, the mobile may use the mobile default local address configuration.

The ME may support a remote access login feature. If supported by the ME, the SIM may provide ‘User login’ and ‘User password’ parameters, which can be used for authentication. If only one parameter is present, it is considered as the User Login and the ME shall use default Password configuration if any. If the parameters are not present, the ME shall use default Login/Password configuration if any. If no authentication challenge is requested, the user login and password parameters shall be ignored.

If the SIM/ME interface transport level is present in the command, then the ME shall provide the requested transport layer protocols under the channel and shall use this object containing a set of parameters required to make the transport connection. The data that is exchanged at the SIM/ME interface in the RECEIVE DATA/SEND DATA commands are SDUs. When the SAT application sends an SDU, the transport layer within the ME is in charge to add the transport header to the SDU in order to build the Transport-PDU. When the SAT application requests to receive an SDU, the transport layer within the ME is in charge to remove the transport header of the Transport-PDU, and to forward the SDU to the SAT. If the parameter is not present, the SIM/ME interface is the bearer level (serial link or packet link as defined in TS 27.007 [27]) and the SAT application is in charge of the network and transport layer.

The Data Destination Address is the end point destination address of sent data. This data destination address is requested when a SIM/ME interface transport is present, otherwise it is ignored. The data destination address is a data network address (e.g. IP address).

6.6.27.3 OPEN CHANNEL related to Default (network) Bearer

Description

Section

M/O

Min

Length

Proactive SIM command Tag

13.2

M

Y

1

Length (A+B+C+D+E+F+H+I+J+K+L)

M

Y

1 or 2

Command details

12.6

M

Y

A

Device identities

12.7

M

Y

B

Alpha identifier

12.2

O

N

C

Icon identifier

12.31

O

N

D

Bearer description

12.52

M

Y

E

Buffer size

12.55

M

Y

F

Other address (local address)

12.58

O

N

H

Text String (User login)

12.15

O

N

I

Text String (User password)

12.15

O

N

J

SIM/ME interface transport level

12.59

O

N

K

Data destination address

12.58

O

N

L

The local address parameter (see 12.58) provides information to the ME necessary to identify the local device. If the parameter is present and length is not null, it provides an IP address that identifies the SAT application in the address area applicable to the PDN. If local address length is null, dynamic local address allocation is required for the SAT application. If parameter is not present, the mobile may use the mobile default local address configuration.

The ME may support a remote access login feature. If supported by the ME, the SIM may provide ‘User login’ and ‘User password’ parameters, which can be used for authentication. If only one parameter is present, it is considered as the User Login and the ME shall use default Password configuration if any. If the parameters are not present, the ME shall use default Login/Password configuration if any. If no authentication challenge is requested, the user login and password parameters shall be ignored.

If the SIM/ME interface transport level is present in the command, then the ME shall provide the requested transport layer protocols under the channel and shall use this object containing a set of parameters required to make the transport connection. The data that is exchanged at the SIM/ME interface in the RECEIVE DATA/SEND DATA commands are SDUs. When the SAT application sends an SDU, the transport layer within the ME is in charge to add the transport header to the SDU in order to build the Transport-PDU. When the SAT application requests to receive an SDU, the transport layer within the ME is in charge to remove the transport header of the Transport-PDU, and to forward the SDU to the SAT. If the parameter is not present, the SIM/ME interface is the bearer level (serial link or packet link as defined in TS 27.007 [27]) and the SAT application is in charge of the network and transport layer.

The Data Destination Address is the end point destination address of sent data. This data destination address is requested when a SIM/ME interface transport is present, otherwise it is ignored. The data destination address is a data network address (e.g. IP address).

6.6.27.4 OPEN CHANNEL related to local bearer

See TS 102 223 [37].

6.6.28 CLOSE CHANNEL

See TS 102 223 [37].

6.6.29 RECEIVE DATA

See TS 102 223 [37].

6.6.30 SEND DATA

See TS 102 223 [37].

6.6.31 GET CHANNEL STATUS

See TS 102 223 [37].

6.6.32 SERVICE SEARCH

See TS 102 223 [37].

6.6.33 GET SERVICE INFORMATION

See TS 102 223 [37].

6.6.34 DECLARE SERVICE

See TS 102 223 [37].

6.7 Command results

Once the ME has made its attempt to execute a proactive command from the SIM, the ME shall inform the SIM of the success or otherwise of that command, by using TERMINAL RESPONSE

This procedure is defined in TS 102 223, and applies here except for the following statements.

Successful commands are further defined as:

– Command performed successfully. There were no problems;

– Command performed with partial comprehension. Here the ME receives a command with one or more SIMPLE-TLV data objects that are unrecognized or unexpected, all of which do not have their "comprehension required" flag set (subclause 13.3), but the parent BER-TLV data object still has the minimum set of SIMPLE-TLV data objects required to perform the command;

– Command performed, with missing information. The ME received at least the minimum set of component parts, but did not receive all of the parts that it believed mandatory for the SIM to send;

– Command performed, but modified by call control. This is sent by the ME to indicate that call control modified the type of request indicated in the proactive command, and that the action requested by call control was performed successfully;

– Command performed with modification. This is sent by the ME to indicate that it is unable to process the command using the exact parameters provided by the SIM. The command is processed with the best possible parameters.

Temporary problems are further defined as:

– ME is currently unable to process the command. Specific causes for this are listed in TS 102 223 [37]; in addition to these, the following causes may be returned within the USAT context:

– ME currently busy on SS transaction;

– ME currently busy on USSD operation;

If none of these can be made to apply, a "no cause can be given" value can be used.

– Network is currently unable to process the command. Specific cause values are the cause values given by the network, as defined in TS 04.08 [8].

– In some proactive commands, the ME is required to solicit and receive approval of the user before executing the proactive command. In the case that the user does not give approval for the execution of the proactive command, it shall not be executed by the ME and the terminal response "user did not accept the proactive command" shall be returned by the ME to the SIM.

– The user cleared down the call, before the call connected (CONNECT received from network, as defined in TS 04.08 [8]) or before the network released the call.

– Action in contradiction with the current timer state. This is where the SIM requests an action for a timer to be taken by the ME and the state of the timer does not allow that action.

– Interaction with call control by SIM, temporary problem. This is sent by the ME to indicate that call control modified the type of request indicated in the proactive command, and that the action requested by call control encounters a temporary problem.

Permanent problems are defined as in TS 102 223 [37], with the addition of:

– SS Return Error. This is given to the SIM when the network returns a SS error in response to a previous SS command. Specific cause values are the same as given by the network in the Return Error message.

– USSD Return Error. This is given to the SIM when the network returns a USSD error in response to a previous USSD command. Specific cause values are the same as given by the network in a Return Error message.

– SMS RP-ERROR. This is given to the SIM when the network returns an error in response to the ME trying to send a short message. Specific cause values are the same as the cause value of RP‑Cause in an RP-ERROR message.

– Error, required values are missing. This is given when the command type is understood by the ME, but it does not receive the minimum set of SIMPLE-TLV data objects that it requires to perform the command. These components are shown by the "Min" column in the command structure definitions.

– Interaction with MO short message control by SIM, permanent problem. This is sent by the ME to indicate that :

– MO short message control by SIM does not allow the action corresponding to the proactive command or

– MO short message control by SIM has modified the type of request indicated in the proactive command and that the action requested by call control encounters a permanent problem.

6.8 Structure of TERMINAL RESPONSE

Direction: ME to SIM

The command header is specified in TS 51.011 [20]. Length (A+B+C+D+E+F+G+H+I+J+K+L+M+N+P+Q+ R+S+T+U+V+W+X) is indicated by P3 of the header.

Command parameters/data:

Description

Section

M/O

Min

Length

Command details

12.6

M

Y

A

Device identities

12.7

M

N

B

Result

12.12

M

Y

C

Duration (only required in response to a POLL INTERVAL proactive command)

12.8

M/O

Y/N

D

Text string (only required in response to a GET INKEY or GET INPUT or SEND USSD proactive command)

12.15

M/O

Y/N

E

Item identifier (only required in response to SELECT ITEM proactive command)

12.10

M/O

Y/N

F

Local information (only required in response to PROVIDE LOCAL INFORMATION proactive command)

12.19, 12.20, 12.22, 12.29, 12.39, 12.45 & 12.46

M/O

Y/N

G

Call control requested action (only required if call control by SIM has modified a proactive command SET UP CALL, SEND SS or SEND USSD in another type of request).

12.30

M/O

Y/N

H

Result data object 2 (only required if call control by SIM has modified a proactive command SET UP CALL, SEND SS or SEND USSD in another type of request).

12.12

M/O

Y/N

I

Card reader status (only required in response to GET READER STATUS command). According to the requested information, one Card reader status object for each card interface reported or one Card reader identifier object is required.

(only if class "a" is supported)""

12.33, 12.57

M/O

N

J0 + … + Jn

or J

Card ATR (only required in response to POWER ON CARD).

(only if class "a" is supported)

12.34

M/O

N

K

R-APDU (only required in response to PERFORM CARD APDU).

(only if class "a" is supported)

12.36

M/O

N

L

Timer identifier (only required in response to a TIMER MANAGEMENT proactive command)

12.37

M/O

Y/N

M

Timer value (only required in response to a TIMER MANAGEMENT proactive command)

12.38

M/O

Y/N

N

AT Response (only required in response to RUN AT COMMAND proactive command)

(only if class "b" is supported)

12.41

M/O

Y/N

P

Text string2 (only required if call control by SIM has modified the proactive command SET UP CALL or SEND SS into a USSD request)

12.15

M/O

Y/N

Q

Channel data (only required in response to RECEIVE DATA)

(only if class "e" is supported)

12.53

M/O

Y/N

R

Channel status (only required in response to GET CHANNEL STATUS or OPEN CHANNEL proactive command)

(only if class "e" is supported)

12.56

M/O

Y/N

S0 + … + Sn

Channel data length (only required in response to RECEIVE DATA or SEND DATA proactive command)

(only if class "e" is supported)

12.54

M/O

Y/N

T

Bearer description (only required in response to OPEN CHANNEL proactive command)

(only if class "e" is supported)

12.52

M/O

Y/N

U

Buffer size (only required in response to OPEN CHANNEL proactive command)

(only if class "e" is supported)

12.55

M/O

Y/N

V

Service availability (only required in response to SERVICE SEARCH proactive command)

12.66

C

N

W

Service record (only required in response to GET SERVICE INFORMATION proactive command)

12.62

C

N

X

Specific rules apply for the coding of the TERMINAL RESPONSE, see TS 102 223 [37]

Response parameters/data: None.

6.8.1 Command details

See TS 102 223 [37].

6.8.2 Device identities

See TS 102 223 [37].

6.8.3 Result

See TS 102 223 [37].

6.8.4 Duration

See TS 102 223 [37].

6.8.5 Text string

TS 102 223 [37] applies, with the addition of the following procedure.

When the ME issues a successful TERMINAL RESPONSE for a SEND USSD command, it shall supply the text returned within the Return Result message from the network for the USSD command, no matter what type of string was returned.

6.8.6 Item identifier

When the ME issues a successful TERMINAL RESPONSE (‘0X’ result value – refer to subclause 12.12) for a SELECT ITEM command, it shall supply the identifier of the item selected by the user in the Item identifier data object. If the ME issues a TERMINAL RESPONSE with result "Help information required by the user" for a SELECT ITEM command, it shall supply the identifier of the item for which the user is requiring help information.

6.8.7 Local information

When the ME issues a successful TERMINAL RESPONSE for a PROVIDE LOCAL INFORMATION command, it shall supply the requested local information.

– Where the SIM has requested location information, TERMINAL RESPONSE shall contain the location information data object. All other types of TERMINAL RESPONSE do not need to include location information. If one is included by the ME, the SIM shall ignore it.

– Where theSIMhas requested the IMEI, TERMINAL RESPONSE shall contain the IMEI data object. All other types of TERMINAL RESPONSE do not need to include IMEI information. If one is included by the ME, the SIM shall ignore it.

– Where the SIM has requested the Network Measurement Results the TERMINAL RESPONSE shall contain the NMR data object and the BCCH channel list data object. All other types of TERMINAL RESPONSE do not need to include the NMR information or the BCCH channel list. If one is included by the ME, the SIM shall ignore it.

– Where the SIM has requested the date, time and time zone the TERMINAL RESPONSE shall contain the Date-Time and Time zone data object. All other types of TERMINAL RESPONSE do not need to include the Date-Time and Time zone information. If one is included by the ME, the SIM shall ignore it.

– Where the SIM has requested the currently used language, the TERMINAL RESPONSE shall contain the Language data object. All other types of TERMINAL RESPONSE need not to include the Language information. If one is included by the ME, the SIM shall ignore it.

– Where theSIMhas requested the Timing Advance, the TERMINAL RESPONSE shall contain the Timing Advance data object. All other types of TERMINAL RESPONSE do not need to include the Timing Advance information. If one is included by the ME, the SIM shall ignore it.

6.8.8 Call control requested action

When the ME issues a TERMINAL RESPONSE for a proactive command SET UP CALL, SEND SS or SEND USSD which has been modified by call control by SIM in another type of request, it shall supply the response data given in response to the ENVELOPE (CALL CONTROL).

6.8.9 Result data object 2

When the ME issues a TERMINAL RESPONSE for a proactive command SET UP CALL, SEND SS or SEND USSD which has been modified by call control by SIM in another type of request, it shall supply the Result data object it would have supplied for the proactive command equivalent to the action requested by call control, and given in the Call control request data element.

6.8.10 Card reader status

See TS 102 223 [37].

6.8.11 Card ATR

See TS 102 223 [37].

6.8.12 R-APDU

See TS 102 223 [37].

6.8.13 Timer identifier

See TS 102 223 [37].

6.8.14 Timer value

See TS 102 223 [37].

6.8.15 AT Response

See TS 102 223 [37].

6.8.16 Text string 2

When the ME issues a successful TERMINAL RESPONSE for a proactive command SET UP CALL or SEND SS which has been modified by "call control" by SIM into a USSD request (’05’ result value), it shall supply the Text string2. The Text string2 shall contain the text returned within the Return Result message from the network for the USSD response. Text string2 is equivalent to the Text string in the Terminal Response to a SEND USSD command.

6.8.17 Channel data

See TS 102 223 [37].

6.8.18 Channel status

See TS 102 223 [37].

6.8.19 Channel data length

See TS 102 223 [37].

6.8.20 Bearer description

See TS 102 223 [37].

6.8.21 Buffer size

See TS 102 223 [37].

6.8.22 Service Availability

See TS 102 223 [37].

6.8.23 Service Record

See TS 102 223 [37].

6.9 Proactive SIM session and ME display interaction

During a proactive session the ME display shall be refreshed by any display data contained in the first and each subsequent proactive command. The refresh shall occur once the ME has retrieved the proactive command using the Fetch instruction, following the proactive command pending status response.

If no proactive command is pending (status response of ’90 00′ following the Terminal Response), then the session releases the display back into ME control. If this session was terminated in a backwards move, and the session was initiated from an Envelope command containing a Menu Selection, it is recommended that the display returns to the Setup Menu.

If the text is to be sustained, the ME shall display the text of applicable DISPLAY TEXT commands beyond the sending of the TERMINAL RESPONSE and possibly beyond the end of the proactive session.

6.10 Handling of unknown, unforeseen and erroneous messages

See TS 102 223 [37].

6.11 Proactive commands versus possible Terminal response

The following table shows for each proactive command the possible terminal response returned (marked by a "" character).

Proactive Command

RE-FRESH

MORE TIME

POLL INTER-VAL

POLLING OFF

SETUP EVENT LIST

SET UP CALL

SEND SS

SEND USSD

SEND SMS

SEND DTMF

LAUNCH BROWSER

PLAY TONE

DISPLAY TEXT

GET INKEY

GET INPUT

SELECT ITEM

SET UP MENU

PRO-VIDE LOCAL INFO

TIMER

MAN-AGE-

MENT

SETUP IDLE MODE TEXT

Terminal response

’01’

’02’

’03’

’04’

’05’

’10’

’11’

’12’

’13’

’14’

’15’

’20’

’21’

’22’

’23’

’24’

’25’

’26’

’27’

’28’

’00’

Command performed successfully

’01’

Command performed with partial comprehension

’02’

Command performed, with missing info

’03’

REFRESH performed with additional EFs read

’04’

Command performed succesfully, but requested icon could not be displayed

’05’

Command performed, but modified by call control by SIM.

’06’

Command performed successfully, limited service

’07’

Command performed with modification

Continued……

’10’

Proactive SIM session terminated by user

’11’

Backward move in the proactive SIM session requested by the user

’12’

No response from user

’13’

Help information required by the user

’14’

USSD/SS Transact terminated by user

’20’

ME currently unable to process command

’21’

Network currently unable to process command

’22’

User did not accept the proactive command

’23’

User cleared down call before connection or network release

’24’

Action in contradiction with the current timer state

’25’

Interaction with call control by SIM, temporary problem

’26’

Launch Browser generic error

’30’

Command beyond MEs capabilities

’31’

Command type not understood by ME

’32’

Command data not understood by ME

’33’

Command number not known by ME

’34’

SS Return Error

’35’

SMS RPERROR

’36’

Error, required values are missing

’37’

USSD return error

’38’

Multiple Card command error

’39’

Interaction with call control by SIM or MO SM control by SIM, permanent problem.

‘3A’

Bearer Independent Protocol error

Proactive Command

CARD APDU

POWER ON CARD

POWER OFF CARD

GET READ-ER STATUS

RUN AT COMM-AND

LANG NOTIFI CA TION

OPEN CHANNEL

CLOSE CHANNEL

RECEIVE DATA

SEND DATA

GET CHANNEL STATUS

Terminal response

’30’

’31’

’32’

’33’

’34’

’35’

’40’

’41’

’42’

’43’

’44’

’00’

Command performed successfully

’01’

Command performed with partial comprehension

’02’

Command performed, with missing info

’03’

REFRESH performed with additional EFs read

’04’

Command performed succesfully, but requested icon could not be displayed

’05’

Command performed, but modified by call control by SIM.

’06’

Command performed successfully, limited service

’07’

Command performed with modification

’10’

Proactive SIM session terminated by user

’11’

Backward move in the proactive SIM session requested by the user

’12’

No response from user

’13’

Help information required by the user

’14’

USSD/SS Transact terminated by user

’20’

ME currently unable to process command

’21’

Network currently unable to process command

’22’

User did not accept the proactive command

’23’

User cleared down call before connection or network release

’24’

Action in contradiction with the current timer state

’25’

Interaction with call control by SIM, temporary problem

’26’

Launch Browser generic error

’30’

Command beyond MEs capabilities

’31’

Command type not understood by ME

’32’

Command data not understood by ME

’33’

Command number not known by ME

’34’

SS Return Error

’35’

SMS RPERROR

’36’

Error, required values are missing

’37’

USSD return error

’38’

Multiple Card command error

’39’

Interaction with call control by SIM or MO SM control by SIM, permanent problem

‘3A’

Bearer Independent Protocol error