11 Application protocol

11.113GPPRelease 1999Specification of the Subscriber Identity Module - Mobile Equipment (SIM-ME) InterfaceTS

When involved in GSM administrative management operations, the SIM interfaces with appropriate terminal equipment. These operations are outside the scope of this standard.

When involved in GSM network operations the SIM interfaces with an ME with which messages are exchanged. A message can be a command or a response.

‑ A GSM command/response pair is a sequence consisting of a command and the associated response.

‑ A GSM procedure consists of one or more GSM command/response pairs which are used to perform all or part of an application‑oriented task. A procedure shall be considered as a whole, that is to say that the corresponding task is achieved if and only if the procedure is completed. The ME shall ensure that, when operated according to the manufacturer’s manual, any unspecified interruption of the sequence of command/response pairs which realize the procedure, leads to the abortion of the procedure itself.

‑ A GSM session of the SIM in the GSM application is the interval of time starting at the completion of the SIM initialization procedure and ending either with the start of the GSM session termination procedure, or at the first instant the link between the SIM and the ME is interrupted.

During the GSM network operation phase, the ME plays the role of the master and the SIM plays the role of the slave.

The SIM shall execute all GSM and SIM Application Toolkit commands or procedures in such a way as not to jeopardise, or cause suspension, of service provisioning to the user. This could occur if, for example, execution of the RUN GSM ALGORITHM is delayed in such a way which would result in the network denying or suspending service to the user.

Some procedures at the SIM/ME interface require MMI interactions. The descriptions hereafter do not intend to infer any specific implementation of the corresponding MMI. When MMI interaction is required, it is marked "MMI" in the list given below.

Some procedures are not clearly user dependent. They are directly caused by the interaction of the MS and the network. Such procedures are marked "NET" in the list given below.

Some procedures are automatically initiated by the ME. They are marked "ME" in the list given below.

The list of procedures at the SIM/ME interface in GSM network operation is as follows:

General Procedures:

‑ Reading an EF ME

‑ Updating an EF ME

‑ Increasing an EF ME

SIM management procedures:

‑ SIM initialization ME

‑ GSM session termination ME

‑ Emergency call codes request ME

– Extended language preference request ME

‑ Language preference request ME

‑ Administrative information request ME

‑ SIM service table request ME

‑ SIM phase request ME

CHV related procedures:

‑ CHV verification MMI

‑ CHV value substitution MMI

‑ CHV disabling MMI

‑ CHV enabling MMI

‑ CHV unblocking MMI

GSM security related procedures:

‑ GSM algorithms computation NET

‑ IMSI request NET

‑ Access control information request NET

‑ Higher Priority PLMN search period request NET

‑ Location Information NET

? GPRS Location Information NET

? Cipher key NET

? GPRS Cipher key NET

‑ BCCH information NET

‑ Forbidden PLMN information NET

‑ LSA information NET

Subscription related procedures:

‑ Dialling Numbers (ADN, FDN, MSISDN, LND, SDN, BDN) MMI/ME

‑ Short messages (SMS) MMI

‑ Advice of Charge (AoC) MMI

‑ Capability Configuration Parameters (CCP) MMI

‑ PLMN Selector MMI

‑ HPLMN Selector with Access Technology MMI

‑ User controlled PLMN Selector with Access Technology MMI

‑ Operator controlled PLMN Selector with Access Technology MMI

‑ Investigation Scan request NET

‑ CPBCCH information NET

‑ Cell Broadcast Message Identifier (CBMI) MMI

‑ Group Identifier Level 1 (GID1) MMI/ME

‑ Group Identifier Level 2 (GID2) MMI/ME

‑ Service Provider Name (SPN) ME

‑ Voice Group Call Service (VGCS) MMI/ME

‑ Voice Broadcast Service (VBS) MMI/ME

‑ Enhanced Multi Level Pre-emption and Priority (eMLPP) MMI/ME

‑ Depersonalisation Control Keys ME

‑ Short message status reports (SMSR) MMI

‑ Network’s indication of alerting ME

SIM Application Toolkit related procedures:

‑ Data Download via SMS‑CB (CBMID) NET

‑ Data Download via SMS‑PP NET

‑ Menu selection MMI

‑ Call Control MMI/ME/NET

‑ Proactive SIM MMI/ME/NET

‑ Mobile Originated Short Message control by SIM MMI/ME/NET

‑ Image Request MMI/ME

MExE related procedures:

– Reading of MExE_ST ME

– Reading of root public keys on the SIM (ORPK, ARPK,TPRPK) ME/NET

The procedures listed in subclause 11.2 are basically required for execution of the procedures in subclauses 11.3, 11.4 and 11.5. The procedures listed in subclauses 11.3 and 11.4 are mandatory (see TS 02.17 [6]). The procedures listed in subclause 11.5 are only executable if the associated services, which are optional, are provided in the SIM. However, if the procedures are implemented, it shall be in accordance with subclause 11.5.

If a procedure is related to a specific service indicated in the SIM Service Table, it shall only be executed if the corresponding bits denote this service as "allocated and activated" (see subclause 10.3.7). In all other cases this procedure shall not start.

11.1 General procedures

11.1.1 Reading an EF

The ME selects the EF and sends a READ command. This contains the location of the data to be read. If the access condition for READ is fulfilled, the SIM sends the requested data contained in the EF to the ME. If the access condition is not fulfilled, no data will be sent and an error code will be returned.

11.1.2 Updating an EF

The ME selects the EF and sends an UPDATE command. This contains the location of the data to be updated and the new data to be stored. If the access condition for UPDATE is fulfilled, the SIM updates the selected EF by replacing the existing data in the EF with that contained in the command. If the access condition is not fulfilled, the data existing in the EF will be unchanged, the new data will not be stored, and an error code will be returned.

In the case when updating EFLOCI with data containing the TMSI value and the card reports the error ’92 40′ (Memory Problem), the ME shall terminate GSM operation.

11.1.3 Increasing an EF

The ME selects the EF and sends an INCREASE command. This contains the value which has to be added to the contents of the last updated/increased record. If the access condition for INCREASE is fulfilled, the SIM increases the existing value of the EF by the data contained in the command, and stores the result. If the access condition is not fulfilled, the data existing in the EF will be unchanged and an error code will be returned.

NOTE: The identification of the data within an EF to be acted upon by the above procedures is specified within the command. For the procedures in subclauses 11.1.1 and 11.1.2 this data may have been previously identified using a SEEK command, e.g. searching for an alphanumeric pattern.

11.2 SIM management procedures

Phase 2 MEs shall support all SIMs which comply with the mandatory requirements of Phase 1, even if these SIMs do not comply with all the mandatory requirements of Phase 2. Furthermore, Phase 2 MEs shall take care of potential incompatibilities with Phase 1 SIMs which could arise through use of inappropriate commands or misinterpretation of response data. Particular note should be taken of making a false interpretation of RFU bytes in a Phase 1 SIM having contradictory meaning in Phase 2; e.g. indication of EF invalidation state.

11.2.1 SIM initialization

After SIM activation (see subclause 4.3.2), the ME selects the Dedicated File DFGSM and optionally attempts to select EFECC If EFECC is available, the ME requests the emergency call codes.

The ME requests the Extended Language Preference. The ME only requests the Language Preference (EFLP) if at least one of the following conditions holds:

– EFELP is not available;

– EFELP does not contain an entry corresponding to a language specified in ISO 639[30];

– the ME does not support any of the languages in EFELP.

If both EFs are not available or none of the languages in the EFs is supported then the ME selects a default language. It then runs the CHV1 verification procedure.

If the CHV1 verification procedure is performed successfully, the ME then runs the SIM Phase request procedure.

For a SIM requiring PROFILE DOWNLOAD, then the ME shall perform the PROFILE DOWNLOAD procedure in accordance with TS 11.14 [27]. When BDN is enabled on a SIM, the PROFILE DOWNLOAD procedure is used to indicate to the SIM whether the ME supports the "Call Control by SIM" facility. If so, then the SIM is able to allow the REHABILITATE command to rehabilitate EFIMSI and EFLOCI.

If the ME detects a SIM of Phase 1, it shall omit the following procedures relating to FDN and continue with the Administrative Information request. The ME may omit procedures not defined in Phase 1 such as Higher Priority PLMN Search Period request.

For a SIM of Phase 2 or greater, GSM operation shall only start if one of the two following conditions is fulfilled:

‑ if EFIMSI and EFLOCI are not invalidated, the GSM operation shall start immediately;

‑ if EFIMSI and EFLOCI are invalidated, the ME rehabilitates these two EFs.

MEs without FDN capability but with Call control by SIM facility shall not rehabilitate EFIMSI and/or EFLOCI if FDN is enabled in the SIM and therefore have no access to these EFs. GSM operation will therefore be prohibited;

MEs without FDN capability and without Call control by SIM facility shall not rehabilitate EFIMSI and/or EFLOCI and therefore have no access to these EFs. GSM operation will therefore be prohibited.

It is these mechanisms which are used for control of services n°3 and n°31 by the use of SIMs for these services which always invalidate these two EFs at least before the next command following selection of either EF.

NOTE: When FDN and BDN are both enabled, and if the ME supports FDN but does not support the Call control by SIM facility, the rehabilitation of EFIMSI and EFLOCI will not be successful because of a restriction mechanism of the REHABILITATE command linked to the BDN feature.

When EFIMSI and EFLOCI are successfully rehabilitated, if the FDN capability procedure indicates that:

i) FDN is allocated and activated in the SIM; and FDN is set "enabled", i.e. ADN "invalidated" or not activated; and the ME supports FDN; or

ii) FDN is allocated and activated in the SIM; and FDN is set "disabled", i.e. ADN "not invalidated"; or

iii) FDN is not allocated or not activated;

then GSM operation shall start.

In all other cases GSM operation shall not start.

Afterwards, the ME runs the following procedures, subject to the service being supported both by the ME and the SIM:

‑ Administrative Information request;

‑ SIM Service Table request;

‑ IMSI request;

‑ Access Control request;

‑ Higher Priority PLMN Search Period request;

‑ Investigation scan request;

‑ PLMN selector request;

‑ HPLMN Selector with Access Technology request;

‑ User controlled PLMN Selector with Access Technology request;

‑ Operator controlled PLMN Selector with Access Technology request;

‑ Location Information request;

– GPRS Location Information request;

‑ Cipher Key request;

‑ GPRS Cipher Key request;

‑ BCCH information request;

‑ CPBCCH information request;

‑ Forbidden PLMN request;

‑ LSA information request;

‑ CBMID request;

‑ Depersonalisation Control Keys request;

‑ Network’s indication of alerting request.

If the SIM service table indicates that the proactive SIM service is active, then from this point onwards, the ME, if it supports the proactive SIM service, shall send STATUS commands at least every 30s during idle mode as well as during calls, in order to enable the proactive SIM to respond with a command. The SIM may send proactive commands (see TS 11.14 [27]), including a command to change the interval between STATUS commands from the ME, when in idle mode. In‑call requirements for STATUS for SIM Presence Detection are unchanged by this command.

After the SIM initialization has been completed successfully, the MS is ready for a GSM session.

11.2.2 GSM session termination

NOTE 1: This procedure is not to be confused with the deactivation procedure in subclause 4.3.2.

The GSM session is terminated by the ME as follows.

The ME runs all the procedures which are necessary to transfer the following subscriber related information to the SIM, subject to the service being supported both by the ME and the SIM:

‑ Location Information update;

‑ GPRS Location Information update;

‑ Cipher Key update;

‑ GPRS Cipher Key update;

‑ BCCH information update;

‑ CPBCCH information update;

‑ Advice of Charge increase;

‑ Forbidden PLMN update.

As soon as the SIM indicates that these procedures are completed, the ME/SIM link may be deactivated.

Finally, the ME deletes all these subscriber related information elements from its memory.

NOTE 2: If the ME has already updated any of the subscriber related information during the GSM Session, and the value has not changed until GSM session termination, the ME may omit the respective update procedure.

11.2.3 Emergency Call Codes

Request: The ME performs the reading procedure with EFECC.

Update: The ME performs the updating procedure with EFECC.

NOTE: The update procedure is only applicable when access conditions of ADM for update is set to ALW, CHV1 or CHV2.

11.2.4 Language preference

Request: The ME performs the reading procedure with EFLP.

Update: The ME performs the updating procedure with EFLP.

11.2.5 Administrative information request;

The ME performs the reading procedure with EFAD.

11.2.6 SIM service table request

The ME performs the reading procedure with EFSST.

11.2.7 SIM phase request

The ME performs the reading procedure with EFPhase.

11.2.8 SIM Presence Detection and Proactive Polling

As an additional mechanism, to ensure that the SIM has not been removed during a card session, the ME sends, at frequent intervals, a STATUS command during each call. A STATUS command shall be issued within all 30 second periods of inactivity on the SIM‑ME interface during a call. Inactivity in this case is defined as starting at the end of the last communication or the last issued STATUS command. If no response data is received to this STATUS command, then the call shall be terminated as soon as possible but at least within 5 seconds after the STATUS command has been sent. If the DF indicated in response to a STATUS command is not the same as that which was indicated in the previous response, or accessed by the previous command, then the call shall be terminated as soon as possible but at least within 5 seconds after the response data has been received. This procedure shall be used in addition to a mechanical or other device used to detect the removal of a SIM.

If the ME supports the proactive SIM service, and the SIM has this service activated in its Service Table, then during idle mode the ME shall send STATUS commands to the SIM at intervals no longer than the interval negotiated with the SIM (see TS 11.14 [27]).

11.2.9 Extended Language preference

Request: The ME performs the reading procedure with EFELP.

Update: The ME performs the updating procedure with EFELP.

11.3 CHV related procedures

A successful completion of one of the following procedures grants the access right of the corresponding CHV for the GSM session. This right is valid for all files within the GSM application protected by this CHV.

After a third consecutive presentation of a wrong CHV to the SIM, not necessarily in the same GSM session, the CHV status becomes "blocked" and if the CHV is "enabled", the access right previously granted by this CHV is lost immediately.

An access right is not granted if any of the following procedures are unsuccessfully completed or aborted.

11.3.1 CHV verification

The ME checks the CHV status.

In the case of CHV1 the following procedure applies:

– if the CHV1 status is "blocked" and CHV1 is "enabled", the procedure ends and is finished unsuccessfully;

– if the CHV1 status is "blocked" but CHV1 is "disabled", the procedure ends and is finished successfully. The ME shall, however, accept SIMs which do not grant access rights when CHV1 is "blocked" and "disabled". In that case ME shall consider those SIMs as "blocked";

– if the CHV1 status is not "blocked" and CHV1 is "disabled", the procedure is finished successfully;

– if the CHV1 status is not "blocked" and CHV1 is "enabled", the ME uses the VERIFY CHV function. If the CHV1 presented by the ME is equal to the corresponding CHV1 stored in the SIM, the procedure is finished successfully. If the CHV1 presented by the ME is not equal to the corresponding CHV1 stored in the SIM, the procedure ends and is finished unsuccessfully.

In the case of CHV2 the following procedure applies:

– if the CHV2 status is "blocked", the procedure ends and is finished unsuccessfully;

– if the CHV2 status is not "blocked", the ME uses the VERIFY CHV function. If the CHV2 presented by the ME is equal to the corresponding CHV2 stored in the SIM, the procedure is finished successfully. If the CHV2 presented by the ME is not equal to the corresponding CHV2 stored in the SIM, the procedure ends and is finished unsuccessfully.

11.3.2 CHV value substitution

The ME checks the CHV status. If the CHV status is "blocked" or "disabled", the procedure ends and is finished unsuccessfully.

If the CHV status is not "blocked" and the enabled/disabled indicator is set "enabled", the ME uses the CHANGE CHV function. If the old CHV presented by the ME is equal to the corresponding CHV stored in the SIM, the new CHV presented by the ME is stored in the SIM and the procedure is finished successfully.

If the old CHV and the CHV in memory are not identical, the procedure ends and is finished unsuccessfully.

11.3.3 CHV disabling

Requirement: Service n°1 "allocated and activated".

The ME checks the CHV1 status. If the CHV1 status is "blocked", the procedure ends and is finished unsuccessfully.

If the CHV1 status is not "blocked", the ME reads the CHV1 enabled/disabled indicator. If this is set "disabled", the procedure ends and is finished unsuccessfully.

If the CHV1 status is not "blocked" and the enabled/disabled indicator is set "enabled", the ME uses the DISABLE CHV function. If the CHV1 presented by the ME is equal to the CHV1 stored in the SIM, the status of CHV1 is set "disabled" and the procedure is finished successfully. If the CHV1 presented by the ME is not equal to the CHV1 stored in the SIM, the procedure ends and is finished unsuccessfully.

11.3.4 CHV enabling

The ME checks the CHV1 status. If the CHV1 status is "blocked", the procedure ends and is finished unsuccessfully.

If the CHV1 status is not "blocked", the ME reads the CHV1 enabled/disabled indicator. If this is set "enabled", the procedure ends and is finished unsuccessfully.

If the CHV1 status is not "blocked" and the enabled/disabled indicator is set "disabled", the ME uses the ENABLE CHV function. If the CHV1 presented by the ME is equal to the CHV1 stored in the SIM, the status of CHV1 is set "enabled" and the procedure is finished successfully. If the CHV presented by the ME is not equal to the CHV1 stored in the SIM, the procedure ends and is finished unsuccessfully.

11.3.5 CHV unblocking

The execution of the CHV unblocking procedure is independent of the corresponding CHV status, i.e. being blocked or not.

The ME checks the UNBLOCK CHV status. If the UNBLOCK CHV status is "blocked", the procedure ends and is finished unsuccessfully.

If the UNBLOCK CHV status is not "blocked", the ME uses the UNBLOCK CHV function. If the UNBLOCK CHV presented by the ME is equal to the corresponding UNBLOCK CHV stored in the SIM, the relevant CHV status becomes "unblocked" and the procedure is finished successfully. If the UNBLOCK CHV presented by the ME is not equal to the corresponding UNBLOCK CHV stored in the SIM, the procedure ends and is finished unsuccessfully.

11.4 GSM security related procedures

11.4.1 GSM algorithms computation

The ME selects DFGSM and uses the RUN GSM ALGORITHM function (see subclause 8.16). The response SRES‑Kc is sent to the ME when requested by a subsequent GET RESPONSE command.

11.4.2 IMSI request

The ME performs the reading procedure with EFIMSI.

11.4.3 Access control request

The ME performs the reading procedure with EFACC.

11.4.4 Higher Priority PLMN search period request

The ME performs the reading procedure with EFHPPLMN.

11.4.5 Location information

Request: The ME performs the reading procedure with EFLOCI.

Update: The ME performs the updating procedure with EFLOCI.

11.4.6 Cipher key

Request: The ME performs the reading procedure with EFKc.

Update: The ME performs the updating procedure with EFKc.

11.4.7 BCCH information

Request: The ME performs the reading procedure with EFBCCH.

Update: The ME performs the updating procedure with EFBCCH.

11.4.8 Forbidden PLMN

Request: The ME performs the reading procedure with EFPLMN.

Update: The ME performs the updating procedure with EFPLMN.

11.4.9 LSA information

Request: The ME performs the reading procedure with EFSAI, EFSLL and its associated LSA Descriptor files.

Update: The ME performs the updating procedure with EFSLL.

11.4.10 GPRS Location information

Requirement: Service n°38 "allocated and activated".

Request: The ME performs the reading procedure with EFLOCIGPRS.

Update: The ME performs the updating procedure with EFLOCIGPRS.

11.4.11 GPRS Cipher key

Requirement: Service n°38 "allocated and activated".

Request: The ME performs the reading procedure with EFKcGPRS.

Update: The ME performs the updating procedure with EFKcGPRS.

11.5 Subscription related procedures

11.5.1 Dialling numbers

The following procedures may not only be applied to EFADN and its associated extension files EFCCP and EFEXT1 as described in the procedures below, but also to EFEDN, EFMSISDN, EFLND, EFBDN and EFSDN and their associated extension files. If these files are not allocated and activated, as denoted in the SIM service table, the current procedure shall be aborted and the appropriate EFs shall remain unchanged.

As an example, the following procedures are described as applied to ADN.

Requirement: Service n°2 "allocated and activated"

(Service n°3 for FDN,

Service n°9 for MSISDN,

Service n°13 for LND,

Service n°18 for SDN),

Service n°31 for BDN)

Update: The ME analyses and assembles the information to be stored as follows (the byte identifiers used below correspond to those in the description of the EFs in subclauses 10.5.1, 10.5.4 and 10.5.10):

i) The ME identifies the Alpha‑tagging, Capability/Configuration Identifier and Extension1 Record Identifier.

ii) The dialling number/SSC string shall be analysed and allocated to the bytes of the EF as follows:

‑ if a "+" is found, the TON identifier is set to "International";

‑ if 20 or less "digits" remain, they shall form the dialling number/SSC string;

‑ if more than 20 "digits" remain, the procedure shall be as follows:

Requirement:

Service n°10 "allocated and activated";

(Service n°10 applies also for MSISDN and LND;

Service n°11 for FDN;

Service n°19 for SDN;

Service n°32 for BDN).

The ME seeks for a free record in EFEXT1. If an Extension1 record is not marked as "free", the ME runs the Purge procedure. If an Extension1 record is still unavailable, the procedure is aborted.

The first 20 "digits" are stored in the dialling number/SSC string. The value of the length of BCD number/SSC contents is set to the maximum value, which is 11. The Extension1 record identifier is coded with the associated record number in the EFEXT1. The remaining digits are stored in the selected Extension1 record where the type of the record is set to "additional data". The first byte of the Extension1 record is set with the number of bytes of the remaining additional data. The number of bytes containing digit information is the sum of the length of BCD number/SSC contents of EFADN and byte 2 of all associated chained Extension1 records containing additional data (see subclauses 10.5.1 and 10.5.10).

iii) If a called party subaddress is associated to the ADN/SSC the procedure shall proceed as follows:

Requirement:

Service n°10 "allocated and activated"

(Service n°10 applies also for MSISDN and LND;

Service n°11 for FDN;

Service n°19 for SDN;

Service n°32 for BDN.)

If the length of the called party subaddress is less than or equal to 11 bytes (see TS 04.08 [15] for coding):

– the ME seeks for a free record in EFEXT1. If an Extension1 record is not marked as "free", the ME runs the Purge procedure. If an Extension1 record is still unavailable, the procedure is aborted;

– the ME stores the called party subaddress in the Extension1 record, and sets the Extension1 record type to "called party subaddress".

If the length of the called party subaddress is greater than 11 bytes (see TS 04.08 [15] for coding):

– the ME seeks for two free records in EFEXT1. If no such two records are found, the ME runs the Purge procedure. If two Extension1 records are still unavailable, the procedure is aborted;

– the ME stores the called party subaddress in the two Extension1 records. The identifier field in the Extension1 record containing the first part of the subaddress data is coded with the associated EFEXT1 record number containing the second part of the subaddress data. Both Extension1 record types are set to "called party subaddress".

Once i), ii), and iii) have been considered the ME performs the updating procedure with EFADN. If the SIM has no available empty space to store the received ADN/SSC, or if the procedure has been aborted, the ME advises the user.

NOTE 1: For reasons of memory efficiency the ME is allowed to analyse all Extension1 records to recognize if the additional or subaddress data to be stored is already existing in EFEXT1. In this case the ME may use the existing chain or the last part of the existing chain from more than one ADN (LND, MSISDN). The ME is only allowed to store extension data in unused records. If existing records are used for multiple access, the ME shall not change any data in those records to prevent corruption of existing chains.

Erasure: The ME sends the identification of the information to be erased. The content of the identified record in EFADN is marked as "free".

Request: The ME sends the identification of the information to be read. The ME shall analyse the data of EFADN (subclause 10.5.1) to ascertain, whether additional data is associated in EFEXT1 or EFCCP. If necessary, then the ME performs the reading procedure on these EFs to assemble the complete ADN/SSC.

Purge: The ME shall access each EF which references EFEXT1 (EFEXT2) for storage and shall identify records in these files using extension data (additional data or called party subaddress). Note that existing chains have to be followed to the end. All referred Extension1 (Extension2) records are noted by the ME. All Extension1 (Extension2) records not noted are then marked by the ME as "free" by setting the whole record to ‘FF’.

NOTE 2: Dependent upon the implementation of the ME, and in particular the possibility of erasure of ADN/SSC records by Phase 1 MEs, which have no knowledge of the EFEXT1, it is possible for Extension1 records to be marked as "used space" (not equal to ‘FF’), although in fact they are no longer associated with an ADN/SSC record.

The following three procedures are only applicable to service n°3 (FDN).

FDN capability request. The ME has to check the state of service n°3, i.e. if FDN is "enabled" or "disabled". In case of enabled FDN, the ME has to switch to a restrictive terminal mode (see TS 02.07). To ascertain the state of FDN, the ME checks in EFSST whether or not ADN is activated. If ADN is not activated, service n°3 is enabled. If ADN is activated, the ME checks the response data of EFADN. If EFADN is invalidated, service n°3 is enabled. In all other cases service n°3 is disabled.

FDN disabling. The FDN disabling procedure requires that CHV2 verification procedure has been performed successfully and that ADN is activated. If not, FDN disabling procedure will not be executed successfully. To disable FDN capability, the ME rehabilitates EFADN. The invalidate/rehabilitate flag of EFADN, which is implicitly set by the REHABILITATE command, is at the same time the indicator for the state of the service n°3. If ADN is not activated, disabling of FDN is not possible and thus service n°3 is always enabled (see FDN capability request).

NOTE 3: If FDN is disabled (by rehabilitating EFADN) using an administrative terminal then the FDN disabling procedure of this administrative terminal need also to rehabilitate EFIMSI and EFLOCI to ensure normal operation of the SIM in a phase 1 ME or a phase 2 ME which does not support FDN.

FDN enabling. The FDN enabling procedure requires that CHV2 verification procedure has been performed successfully. If not, FDN enabling procedure will not be executed successfully. To enable FDN capability, the ME invalidates EFADN. The invalidate/rehabilitate flag of EFADN, which is implicitly cleared by the invalidate command, is at the same time the indicator for the state of the service n°3 (see FDN capability request). If ADN is not activated, service n°3 is always enabled.

Invalidated ADNs may optionally still be readable and updatable depending on the file status (see subclause 9.3)

The following three procedures are only applicable to service n°31 (BDN).

BDN capability request. The ME has to check the state of service n°31, i.e. if BDN is "enabled" or "disabled". BDN service is "enabled" only if service n°31 is allocated and activated, and EFBDN is not invalidated. In all other cases, the BDN service is "disabled".

BDN disabling. The BDN disabling procedure requires that CHV2 verification procedure has been performed successfully. If not, BDN disabling procedure will not be executed successfully. To disable BDN capability, the ME invalidates EFBDN. The invalidate/rehabilitate flag of EFBDN, which is implicitly cleared by the INVALIDATE command, is at the same time the indicator for the state of the service n°31 (see BDN capability request).

BDN enabling. The BDN enabling procedure requires that CHV2 verification procedure has been performed successfully. If not, BDN enabling procedure will not be executed successfully. To enable BDN capability, the ME rehabilitates EFBDN. The invalidate/rehabilitate flag of EFBDN, which is implicitly set by the REHABILITate command, is at the same time the indicator for the state of the service n°31 (see BDN capability request).

Invalidated BDNs (when BDN capability is disabled) may optionally still be readable and updatable depending on the file status (see subclause 9.3).

11.5.2 Short messages

Requirement: Service n°4 "allocated and activated".

Request: The SIM seeks for the identified short message. If this message is found, the ME performs the reading procedure with EFSMS.

If service n°35 is "allocated and activated" and the status of the SMS is ‘1D’ (status report requested, received and stored in EFSMSR), the ME performs the reading procedure with the corresponding record in EFSMSR. If the ME does not find a corresponding record in EFSMSR, then the ME shall update the status of the SMS with ’15’ (status report requested, received but not stored in EFSMSR).

If the short message is not found within the SIM memory, the SIM indicates that to the ME.

Update: The ME looks for the next available area to store the short message. If such an area is available, it performs the updating procedure with EFSMS.

If there is no available empty space in the SIM to store the received short message, a specific MMI will have to take place in order not to loose the message.

Erasure: The ME will select in the SIM the message area to be erased. Depending on the MMI, the message may be read before the area is marked as "free". After performing the updating procedure with EFSMS, the memory allocated to this short message in the SIM is made available for a new incoming message. The memory of the SIM may still contain the old message until a new message is stored in this area.

If service n°35 is "allocated and activated" and the status of the SMS is ‘1D’ (status report requested, received and stored in EFSMSR), the ME performs the erasure procedure for EFSMSR with the corresponding record in EFSMSR.

11.5.3 Advice of Charge (AoC)

Requirement: Service n°5 "allocated and activated".

Accumulated Call Meter.

Request: The ME performs the reading procedure with EFACM. The SIM returns the last updated value of the ACM.

Initialization: The ME performs the updating procedure with EFACM using the new initial value.

Increasing: The ME performs the increasing procedure with EFACM sending the value which has to be added.

Accumulated Call Meter Maximum Value.

Request: The ME performs the reading procedure with EFACMmax.

Initialization: The ME performs the updating procedure with EFACMmax using the new initial maximum value.

Price per Unit and Currency Table (PUCT).

Request: The ME performs the reading procedure with EFPUCT.

Update: The ME performs the updating procedure with EFPUCT.

11.5.4 Capability configuration parameters

Requirement: Service n°6 "allocated and activated".

Request: The ME performs the reading procedure with EFCCP.

Update: The ME performs the updating procedure with EFCCP.

Erasure: The ME sends the identification of the requested information to be erased. The content of the identified record in EFCCP is marked as "free".

11.5.5 PLMN selector

Requirement: Service n°7 "allocated and activated".

Request: The ME performs the reading procedure with EFPLMNse1.

Update: The ME performs the updating procedure with EFPLMNse1.

11.5.6 Cell broadcast message identifier

Requirement: Service n°14 "allocated and activated".

Request: The ME performs the reading procedure with EFCBMI.

Update: The ME performs the updating procedure with EFCBMI.

11.5.7 Group identifier level 1

Requirement: Service n°15 "allocated and activated".

Request: The ME performs the reading procedure with EFGID1.

11.5.8 Group identifier level 2

Requirement: Service n°16 "allocated and activated".

Request: The ME performs the reading procedure with EFGID2.

11.5.9 Service Provider Name

Requirement: Service n°17 "allocated and activated".

Request: The ME performs the reading procedure with EFSPN.

11.5.10 Voice Group Call Services

Requirement: Service n°21 "allocated and activated".

Voice Group Call Service

Request: The ME performs the reading procedure with EFVGCS.

Voice Group Call Service Status

Request: The ME performs the reading procedure with EFVGCSS.

Update: The ME performs the updating procedure with EFVGCSS.

11.5.11 Voice Broadcast Services

Requirement: Service n°22 "allocated and activated".

Voice Broadcast Service

Request: The ME performs the reading procedure with EFVBS.

Voice Broadcast Service Status

Request: The ME performs the reading procedure with EFVBSS.

Update: The ME performs the updating procedure with EFVBSS.

11.5.12 Enhanced Multi Level Pre-emption and Priority Service

Requirement: Service n°23 "allocated and activated".

Enhanced Multi Level Pre-emption and Priority

Request: The ME performs the reading procedure with EFeMLPP.

Automatic Answer on eMLPP service

Request: The ME performs the reading procedure with EFAAeM.

Update: The ME performs the updating procedure with EFAAeM.

11.5.13 Cell Broadcast Message range identifier

Requirement: Service n°30 "allocated and activated".

Request: The ME performs the reading procedure with EFCBMIR.

Update: The ME performs the updating procedure with EFCBMIR.

11.5.14 Depersonalisation Control Keys

Requirement: Service n°33 "allocated and activated".

Request: The ME performs the reading procedure with EFDCK.

11.5.15 Short message status report

Requirement: Service n°35 "allocated and activated".

Request: If the status of a stored short message indicates that there is a corresponding status report, the ME performs the seek function with EFSMSR to identify the record containing the appropriate status report. The ME performs the reading procedure with EFSMSR.

Update: If a status report is received, the ME first seeks within the SMS record identifiers of EFSMSR for the same record number it used for the short message in EFSMS. If such a record identifier is found in EFSMSR, it is used for storage. If such a record identifier is not found, then the ME seeks for a free entry in EFSMSR for storage. If no free entry is found the ME runs the Purge procedure with EFSMSR. If there is still no free entry, the status report is not stored.

If the ME found an appropriate record in EFSMSR for storage, it updates the record with the status report setting the record identifier in EFSMSR to the appropriate record number of the short message in EFSMS.

The status in EFSMS is updated accordingly (see subclause 10.5.3) by performing the update procedure with EFSMS.

Erasure: The ME runs the update procedure with EFSMSR by at least storing ’00’ in the first byte of the record. The ME may optionally update the following bytes with ‘FF’.

Purge: The ME shall read the SMS record identifier (byte 1) of each record of EFSMSR. With each record the ME checks the corresponding short messages in EFSMS. If the status (byte 1) of the corresponding SMS is not equal ‘1D’ (status report requested, received and stored in EFSMSR), the ME shall perform the erasure procedure with the appropriate record in EFSMSR.

11.5.16 Network’s indication of alerting

Requirement: Service n°36 "allocated and activated".

Request: The ME performs the reading procedure with EFNIA.

11.5.17 User controlled PLMN Selector with Access Technology

Requirement: Service n°43"allocated and activated".

Request: The ME performs the reading procedure with EFPLMNwAcT.

Update: The ME performs the updating procedure with EFPLMNwAcT.

11.5.18 Operator controlled PLMN Selector with Access Technology

Requirement: Service n°44 "allocated and activated".

Request: The ME performs the reading procedure with EFOPLMNwAcT.

11.5.19 HPLMN Selector with Access Technology

Requirement: Service n°45 "allocated and activated".

Request: The ME performs the reading procedure with EFHPLMNAcT.

11.4.20 CPBCCH information

Requirement: Service n°46 "allocated and activated".

Request: The ME performs the reading procedure with EFCPBCCH.

Update: The ME performs the updating procedure with EFCPBCCH.

11.5.21 Investigation Scan

Requirement: Service n°47 "allocated and activated".

Request: The ME performs the reading procedure with EFInvScan.

11.5.22 Void

11.6 SIM Application Toolkit related procedures

SIM Application Toolkit is an optional feature. The higher level procedures, and contents and coding of the commands, are given in TS 11.14 [27]. Procedures relating to the transmission of commands and responses across the SIM/ME interface are given in this section. A SIM or ME supporting SIM Application Toolkit shall conform to the requirements given in this section.

11.6.1 Initialization procedure

A SIM supporting SIM Application Toolkit shall indicate this through relevant data in EFPhase and EFSST, as defined in the relevant sections above.

An ME supporting SIM Application Toolkit shall perform initialization as defined in the SIM Initialization section above.

11.6.2 Proactive polling

An ME supporting proactive SIM (part of SIM Application Toolkit) shall support the polling procedure as defined above.

11.6.3 Support of commands

A SIM or ME supporting SIM Application Toolkit shall support the commands TERMINAL PROFILE, ENVELOPE, FETCH and TERMINAL RESPONSE.

These commands shall never be used if either the SIM or ME does not support SIM Application Toolkit. Therefore standard SIMs and MEs do not need to support these commands.

11.6.4 Support of response codes

A SIM or ME supporting SIM Application Toolkit shall support the response status words (SW1 SW2) ’91 XX’, and ’93 00′ and ‘9E XX’. The SIM shall send ‘9E XX’ only to an ME indicating in TERMINAL PROFILE that it supports the handling of these status words.

These responses shall never be used if either the SIM or ME does not support SIM Application Toolkit. Therefore standard SIMs and MEs do not need to support them.

11.6.5 Command-response pairs

Using the terminology where the ME issues a command and the SIM a response, ending in status words SW1 SW2, a command‑response pair is considered as a single transaction. Each transaction is initiated by the ME and terminated by the SIM. One transaction must be completed before the next one can be initiated. This protocol applies to SIM Application Toolkit in the same way as it does to normal operation.

11.6.6 Independence of normal GSM and SIM Application Toolkit tasks

Normal GSM operation (relating to general, CHV related, GSM security related, and subscription related procedures) and SIM Application Toolkit operation shall be logically independent, both in the SIM and in the ME.

Specifically, this means:

‑ the currently selected EF and current record pointer in the normal GSM task shall remain unchanged, if still valid, as seen by the ME, irrespective of any SIM Application Toolkit activity;

‑ between successive SIM Application Toolkit related command‑response pairs, other normal GSM related command‑response pairs can occur. The SIM Application Toolkit task status shall remain unchanged by these command‑response pairs.

11.6.7 Use of BUSY status response

If for any reason the SIM Application Toolkit task of the SIM cannot process an ENVELOPE command issued by the ME at present (e.g. other SIM Application Toolkit processes are already running, and this additional one would cause an overload), the SIM can respond with a status response of ’93 00′. The ME may re‑issue the command at a later stage.

The BUSY status response has no impact on normal GSM operation.

11.6.8 Use of NULL procedure byte

The NULL procedure byte provides a mechanism for the SIM to obtain more time before supplying the response part of a command‑response pair, during which time the ME is unable to send further commands to the SIM.

If a SIM Application Toolkit activity in the SIM runs for too long, this may prevent the ME from sending "normal GSM" commands which are time‑critical, e.g. RUN GSM ALGORITHM. A MORE TIME command is defined in TS 11.14 [27], which ensures that the SIM Application Toolkit task in the SIM gets more processing time, while at the same time freeing the SIM/ME interface. This should be used in preference to NULL procedure bytes (’60’).

11.6.9 Using the TERMINAL PROFILE, ENVELOPE, and TERMINAL RESPONSE commands

These commands are part of the set used by SIM Application Toolkit. The use of the these commands, the occasions where they are required, and the command and response parameters associated with the commands, are specified in TS 11.14 [27]. The ME completes the command parameters/data of the relevant command and sends the command to the SIM. The transmitted data is processed by the SIM in a specific way depending on the tag value in the command parameters.

A SIM or ME not supporting SIM Application Toolkit does not need to support these commands.

11.6.10 Using the FETCH command

This command is used by SIM Application Toolkit. The use of the this command, the occasions where it is required, and the command and response parameters associated with the command, are specified in TS 11.14 [27]. It is similar in function to GET RESPONSE, in that it requests response parameters from the SIM, following a ’91 XX’ status response. The transmitted response data from the SIM is processed by the ME in a specific way depending on the tag value in the response parameters.

A SIM or ME not supporting SIM Application Toolkit does not need to support this command.

11.6.11 Data Download via SMS‑CB

Requirement: Service n°25 "allocated and activated".

The ME shall perform the reading procedure with EFCBMID. On receiving a cell broadcast message with an identifier which matches an identifier in EFCBMID, the ME shall pass the CB message to the SIM using the ENVELOPE command. If a match is not found and service no. 14 is "allocated and activated", then the message identifier is checked against those in EFCBMI.

11.6.12 Data Download via SMS‑PP

Requirement: Service n°26 "allocated and activated".

The procedures and commands for Data Download via SMS‑PP are defined in TS 11.14 [27].

11.6.13 Menu selection

Requirement: Service n°27 "allocated and activated".

The procedures and commands for Menu Selection are defined in TS 11.14 [27].

11.6.14 Call Control

Requirement: Service n°28 "allocated and activated".

The procedures and commands for Call Control are defined in TS 11.14 [27]. It is mandatory for the ME to perform the procedures if it has indicated that it supports Call Control in the TERMINAL PROFILE command. When BDN is enabled, the Call control facility of the ME is used by the SIM to support the BDN service.

11.6.15 Proactive SIM

Requirement: Service n°29 "allocated and activated".

The procedures and commands for Proactive SIM, at the application level, are defined in TS 11.14 [27].

11.6.16 Mobile Originated Short Message control by SIM

Requirement: Service n°37 "allocated and activated".

The procedures and commands for Mobile Originated Short Message control by SIM are defined in TS 11.14 [27]. It is mandatory for the ME to perform the procedures if it has indicated that it supports Mobile Originated Short Message control by SIM in the TERMINAL PROFILE command.

11.6.17 SIM data download error

In case of an ENVELOPE for SIM data download, the SIM can respond with the status words ‘9E XX’ to indicate that response data is available. The ME shall use the GET RESPONSE command to get the response data. The ME shall then send transparently to the network this response data, using the error procedure of the transport mechanism.

11.6.18 Image Request

Requirement: Service n°39 "allocated and activated".

The ME sends the identification of the information to be read. The ME shall analyse the data of EFIMG (subclause 10.6.1.1) to identify the files containing the image’s instances. If necessary, then the ME performs READ BINARY commands on these files to assemble the complete image instance data.

11.7 MExE related procedures

MExE is an optional feature. The higher level procedures, and contents and coding of the commands, are given in TS 23.057 [50]. Procedures relating to the transmission of commands and responses across the SIM/ME interface are given in this section. A SIM or ME supporting MExE shall conform to the requirements given in this section.

11.7.1 MExE ST

Requirement: Service n°49 (MExE) "allocated and activated".

Request: The ME performs the reading procedure with EFMExE_ST.

11.7.2 Operator root public key

Requirement: Service n°49 (MExE) "allocated and activated" and MExE ST service n°1 (EFORPK )" allocated and activated".

Request: The ME performs the reading procedure with EFORPK . The ME shall analyse the data of EFORPK (sub-clause 10.7.2) to identify the files containing the certificate instances. If necessary, then the ME performs READ BINARY commands on these files to assemble the complete certificate instance data.

11.7.3 Administrator root public key

Requirement: Service n°49 (MExE) "allocated and activated" and MExE ST service n°2 (EFARPK) "allocated and activated".

Request: The ME performs the reading procedure with EFARPK. The ME shall analyse the data of EFARPK (sub-clause 10.7.3) to identify the file containing the certificate instance. If necessary, then the ME performs READ BINARY commands on this file to assemble the complete certificate instance data.

11.7.4 Third Party root public key(s)

Requirement: Service n°49 (MExE) "allocated and activated" and MExE ST service n°3 (EFTPRPK) "allocated and activated".

Request: The ME performs the reading procedure with EFTPRPK. The ME shall analyse the data of EFTPRPK (sub-clause 10.7.4) to identify the files containing the certificate instances. If necessary, then the ME performs READ BINARY commands on these files to assemble the complete certificate instance data.

Annex A (normative):
Plug-in SIM

This annex specifies the dimensions of the Plug‑in SIM as well as the dimensions and location of the contacts of the Plug‑in SIM. For further details of the Plug‑in SIM see clause 4.

NOTE: The Plug‑in SIM may be "obtained" by cutting away excessive plastic of an ID‑1 SIM. The values in parenthesis in figure A.1 show the positional relationship between the Plug‑in and the ID‑1 SIM and are for information only.

Figure A.1: Plug-in SIM

Annex B (normative):
Coding of Alpha fields in the SIM for UCS2

If 16 bit UCS2 characters as defined in ISO/IEC 10646 [31] are being used in an alpha field, the coding can take one of three forms. If the ME supports UCS2 coding of alpha fields in the SIM, the ME shall support all three coding schemes for character sets containing 128 characters or less; for character sets containing more than 128 characters, the ME shall at least support the first coding scheme. If the alpha field record contains GSM default alphabet characters only, then none of these schemes shall be used in that record. Within a record, only one coding scheme, either GSM default alphabet, or one of the three described below, shall be used.

1) If the first octet in the alpha string is ’80’, then the remaining octets are 16 bit UCS2 characters, with the more significant octet (MSO) of the UCS2 character coded in the lower numbered octet of the alpha field, and the less significant octet (LSO) of the UCS2 character is coded in the higher numbered alpha field octet, i.e. octet 2 of the alpha field contains the more significant octet (MSO) of the first UCS2 character, and octet 3 of the alpha field contains the less significant octet (LSO) of the first UCS2 character (as shown below). Unused octets shall be set to ‘FF’, and if the alpha field is an even number of octets in length, then the last (unusable) octet shall be set to ‘FF’.

Example 1

Octet 1

Octet 2

Octet 3

Octet 4

Octet 5

Octet 6

Octet 7

Octet 8

Octet 9

’80’

Ch1MSO

Ch1LSO

Ch2MSO

Ch2LSO

Ch3MSO

Ch3LSO

‘FF’

‘FF’

2) If the first octet of the alpha string is set to ’81’, then the second octet contains a value indicating the number of characters in the string, and the third octet contains an 8 bit number which defines bits 15 to 8 of a 16 bit base pointer, where bit 16 is set to zero, and bits 7 to 1 are also set to zero. These sixteen bits constitute a base pointer to a "half-page" in the UCS2 code space, to be used with some or all of the remaining octets in the string. The fourth and subsequent octets in the string contain codings as follows; if bit 8 of the octet is set to zero, the remaining 7 bits of the octet contain a GSM Default Alphabet character, whereas if bit 8 of the octet is set to one, then the remaining seven bits are an offset value added to the 16 bit base pointer defined earlier, and the resultant 16 bit value is a UCS2 code point, and completely defines a UCS2 character.

Example 2

Octet 1

Octet 2

Octet 3

Octet 4

Octet 5

Octet 6

Octet 7

Octet 8

Octet 9

’81’

’05’

’13’

’53’

’95’

‘A6’

‘XX’

‘FF’

‘FF’

In the above example;

– Octet 2 indicates there 5 characters in the string.

– Octet 3 indicates bits 15 to 8 of the base pointer, and indicates a bit pattern of 0hhh hhhh h000 0000 as the 16 bit base pointer number. Bengali characters for example start at code position 0980 (0000 1001 1000 0000), which is indicated by the coding ’13’ in octet 3 (shown by the italicised digits).

– Octet 4 indicates GSM Default Alphabet character ’53’, i.e. "S".

– Octet 5 indicates a UCS2 character offset to the base pointer of ’15’, expressed in binary as follows 001 0101, which, when added to the base pointer value results in a sixteen bit value of 0000 1001 1001 0101, i.e. ‘0995’, which is the Bengali letter KA.

– Octet 8 contains the value ‘FF’, but as the string length is 5, this a valid character in the string, where the bit pattern 111 1111 is added to the base pointer, yielding a sixteen bit value of 0000 1001 1111 1111 for the UCS2 character (i.e. ’09FF’).

3) If the first octet of the alpha string is set to ’82’, then the second octet contains a value indicating the number of characters in the string, and the third and fourth octets contain a 16 bit number which defines the complete 16 bit base pointer to a "half-page" in the UCS2 code space, for use with some or all of the remaining octets in the string. The fifth and subsequent octets in the string contain codings as follows; if bit 8 of the octet is set to zero, the remaining 7 bits of the octet contain a GSM Default Alphabet character, whereas if bit 8 of the octet is set to one, the remaining seven bits are an offset value added to the base pointer defined in octets three and four, and the resultant 16 bit value is a UCS2 code point, and defines a UCS2 character.

Example 3

Octet 1

Octet 2

Octet 3

Octet 4

Octet 5

Octet 6

Octet 7

Octet 8

Octet 9

’82’

’05’

’05’

’30’

‘2D’

’82’

‘D3’

‘2D’

’31’

In the above example

– Octet 2 indicates there are 5 characters in the string.

– Octets 3 and 4 contain a sixteen bit base pointer number of ‘0530’, pointing to the first character of the Armenian character set.

– Octet 5 contains a GSM Default Alphabet character of ‘2D’, which is a dash "-".

– Octet 6 contains a value ’82’, which indicates it is an offset of ’02’ added to the base pointer, resulting in a UCS2 character code of ‘0532’, which represents Armenian character Capital BEN.

– Octet 7 contains a value ‘D3′, an offset of ’53’, which when added to the base pointer results in a UCS2 code point of ‘0583’, representing Armenian Character small PIWR.

Annex C (informative):
FDN/BDN Procedures

NOTE 1: In case of enabled FDN and/or enabled BDN, the EF has been invalidated by the SIM at no later than this stage.

NOTE 2: Invalidation of only one of the two EFs is not allowed for FDN and BDN.

NOTE 3: For SIMs with enabled BDN this procedure is used to check whether the ME supports the Call Control by the SIM facility.

Figure C.1: Example of an Initialization Procedure of a FDN/BDN SIM (see subclause 11.2.1)

NOTE 4: In case of "BDN enabled", the SIM only allows rehabilitation of the EFIMSI and EFLOCI, if the ME has indicated its CC-capability to the SIM (by PROFILE_DOWNLOAD).

NOTE 5: Possibility for future "restricting" services to use the internal SIM mechanism of invalidation of EFIMSI and EFLOCI.

NOTE 6: If the ME does not support all enabled services (e.g. FDN, BDN), it does not operate. In case of enabled BDN, the support of the "Call Control Feature" by the ME is sufficient for operation. For future use, there may be additional "restricting" services, which are not known to the ME. In that case the ME will perform the subsequent rehabilitation procedure but will fail to rehabilitate EFIMSI and EFLOCI (see note 4).

Figure C.1: Example of an Initialization Procedure of a FDN/BDN SIM (continued)

Figure C.2: SIM capability request

Figure C.3: BDN capability request (see subclause 11.5.1)

NOTE 7: In this case FDN is enabled without the possibility of disabling.

Figure C.4: FDN capability request (see subclause 11.5.1)

NOTE 8: If BDN is enabled in the SIM, and if the Profile download procedure has not indicated that the ME supports Call Control, the EF is not rehabilitated by the SIM.

Figure C.5: Procedure to rehabilitate GSM files

Figure C.6: Coding for state of FDN

Annex D (informative):
Suggested contents of the EFs at pre‑personalization

If EFs have an unassigned value, it may not be clear from the main text what this value should be. This annex suggests values in these cases.

File Identification

Description

Value

‘2FE2’

ICC identification

operator dependant (see 10.1.1)

‘2F05’

Extended Language preference

‘FF…FF’

‘6F05’

Language preference

‘FF’

‘6F07’

IMSI

operator dependant (see 10.3.2)

‘6F20’

Ciphering key Kc

‘FF…FF07’

‘6F30’

PLMN selector

‘FF…FF’

‘6F31’

Higher Priority PLMN search period

‘FF’

‘6F37’

ACM maximum value

‘000000’ (see note 1)

‘6F38’

SIM service table

operator dependant (see 10.3.7)

‘6F39’

Accumulated call meter

‘000000’

‘6F3E’

Group identifier level 1

operator dependant

‘6F3F’

Group identifier level 2

operator dependant

‘6F41’

PUCT

‘FFFFFF0000’

‘6F45’

CBMI

‘FF…FF’

‘6F46’

Service provider name

‘FF…FF’

‘6F48’

CBMID

‘FF…FF’

‘6F49’

Service Dialling Numbers

‘FF…FF’

‘6F74’

BCCH information

‘FF…FF’

‘6F78’

Access control class

operator dependant (see 10.3.15)

‘6F7B’

Forbidden PLMNs

‘FF…FF’

‘6F7E

Location information

‘FFFFFFFF xxxxxx 0000 FF 01’
(see note 2)

‘6FAD’

Administrative data

operator dependant (see 10.3.18)

‘6FAE’

Phase identification

see 10.3.16

‘6F3A’

Abbreviated dialling numbers

‘FF…FF’

‘6F3B’

Fixed dialling numbers

‘FF…FF’

‘6F3C’

Short messages

’00FF…FF’

‘6F3D’

Capability configuration parameters

‘FF…FF’

‘6F40’

MSISDN storage

‘FF…FF’

‘6F42’

SMS parameters

‘FF…FF’

‘6F43’

SMS status

‘FF…FF’

‘6F44’

Last number dialled

‘FF…FF’

‘6F47’

Short message status reports

’00FF…FF’

‘6F4A’

Extension 1

‘FF…FF’

‘6F4B’

Extension 2

‘FF…FF’

‘6F4C’

Extension 3

‘FF…FF’

‘6F4D’

Barred dialling numbers

‘FF…FF’

‘6F4E’

Extension 4

‘FF…FF’

‘6F4F’

Extended capability configuration parameters

‘FF…FF’

‘6F51’

Network’s indication of alerting

‘FF…FF’

‘6F52’

GPRS Ciphering key KcGPRS

‘FF…FF07’

‘6F53’

GPRS Location Information

‘FFFFFFFF FFFFFF xxxxxx 0000 FF 01’

(see note 2)

‘6F54’

SetUpMenu Elements

operator dependant (see 10.3.34)

‘6F58’

Comparison method information

‘FF…FF’

‘6F60’

User controlled PLMN Selector with Access Technology

‘FFFFFF0000..FFFFFF0000’

‘6F61’

Operator controlled PLMN Selector with Access Technology

‘FFFFFF0000..FFFFFF0000’

‘6F62’

HPLMN Selector with Access Technology

‘FFFFFF0000..FFFFFF0000’

‘6F63’

CPBCCH information

‘FF..FF’

‘6F64’

Investigation Scan

’00’

‘4F20’

Image data

’00FF…FF’

‘4F30’

SoLSA Access Indicator)

’00FF…FF’

‘4F31’

SoLSA LSA List

‘FF…FF’

NOTE 1: The value ‘000000’ means that ACMmax is not valid, i.e. there is no restriction on the ACM. When assigning a value to ACMmax, care should be taken not to use values too close to the maximum possible value ‘FFFFFF’, because the INCREASE command does not update EFACM if the units to be added would exceed ‘FFFFFF’. This could affect the call termination procedure of the Advice of Charge function.

NOTE 2: xxxxxx stands for any valid MCC and MNC, coded according to TS 04.08 [15].

Annex E (informative):
SIM application Toolkit protocol diagrams

The diagrams in this annex are intended to illustrate the data protocols of the SIM toolkit application in various situations. The SIM application is shown as initiated by SMS Data Download messages. Other possibilities exist (as defined in TS 11.14) such as data entry from a menu selection.

Case 1: Simple

This shows the simple case where an SMS for SIM updating is received from the network, passed to the SIM by the ME and processed immediately by the SIM application. This requires no ME action except to acknowledge the SMS.

Case 2: Simple with short delay

This shows the simple case where an SMS for SIM updating is received from the network, passed to the SIM by the ME and which requires some time to process by the SIM application. The processing time is "not long" and is obtained by the SIM application sending "null procedure bytes" to the ME. Each byte has the effect of restarting the work waiting time so that the ME does not abort the transaction before the SIM application has finished processing the command(s) sent in the SMS.

Guidelines on timings:

1. The SMS Ack must be sent back before the network times out and sends the SMS again.

2. Use of null procedure bytes must not be excessive as during this time the ME is unable to issue normal GSM commands to the SIM.

Case 3: Simple with short delay and SIM Acknowledgement

This shows the same case as previously where an SMS for SIM updating is received from the network, passed to the SIM by the ME and which requires some time to process by the SIM application. However in this case the SIM application has SIM acknowledgement data to include in the SMS acknowledgement being returned to the network by the ME.

Guideline on timings:

The SMS Ack must be sent back before the network times out and sends the SMS again.

Case 4: A Toolkit command generated by the SIM application as a result of an SMS from the network

This shows the case where an SMS for SIM updating is received from the network, passed to the SIM by the ME and processed by the SIM application which then generates a command for action by the ME (e.g. PLAYTONE).

NOTE: If a positive acknowledgement to the network of completion of execution of the instructions given in the SMS message is required then the SIM application can issue a command to the ME to send a MO SMS.

Case 5: A normal GSM command requires processing before the ME can respond to the 91XX from the SIM

This shows the case where an SMS for SIM updating is received from the network, passed to the SIM by the ME and processed by the SIM application which then generates a command for action by the ME (e.g. PLAYTONE). However a normal GSM command requires processing before the ME can FETCH the command which the SIM is waiting to give it. The response to the normal GSM command is ’91XX’ in this case to remind the ME of the outstanding SIM application command request.

Case 6: MORE TIME Command

This shows the case where an SMS for SIM updating is received from the network, passed to the SIM by the ME and requires a considerable period of time to be processed by the SIM application. In this case the use of null procedure bytes only is inappropriate as the ME must be given the opportunity to process normal GSM commands. The opportunities gained by the SIM application for processing, and the opportunities for normal GSM commands are shown in the diagram above. The sequence of 91XX, FETCH and MORETIME commands can be repeated if required.

Opportunities to process normal GSM commands are shown thus:

Opportunities for SIM application processing are shown thus:

Case 7: SIM Application Busy

While the SIM application is busy processing a SMS for the SIM application arrives from the network and is sent to the SIM by the ME in the usual manner. The SIM operating system recognizes that the SIM application is busy, and it sends a busy response (‘9300’) to the ME. The ME then sends negative acknowledgement to the network. The responsibility for a retry rests with the network.

Annex F (informative):
Examples of coding of LSA Descriptor files for SoLSA

The length of all the records is determined by the LSA descriptor containing the largest number of bytes. Combinations containing different numbers of LSA IDs, LAC+ CI and CI or LAC can therefore be done. Various examples are show. Due to the OTA management of the records it is recommended that the record length is maximum 100 bytes in order to leave room for command descriptor and signature information in the SMS.

This first example contains two LSAs, one described by two LSA IDs and another described by three Cell IDs, giving a record length of 8 bytes.

1st record:

LSA descriptor type = LSA ID and number = 2 (1 byte)

LSA ID (3 bytes)

LSA ID (3 bytes)

Identifier (1 byte)

2nd record:

LSA descriptor type = CI and number = 3 (1 byte)

CI (2 bytes)

CI (2 bytes)

CI (2 bytes)

Identifier (1 byte)

The second example contains two LSAs, one described by one LSA ID and one described by two Cell Ids, giving a record length of 6 bytes.

1st record:

LSA descriptor type = LSA ID and number = 1 (1 byte)

LSA ID (3 bytes)

‘FF’

Identifier (1 byte)

2nd record:

LSA descriptor type = CI and number = 2 (1 byte)

CI (2 bytes)

CI (2 bytes)

Identifier (1 byte)

Annex G (normative):
Image Coding Schemes

The following image coding schemes are applicable to rectangular raster images. Raster image points are assumed to be of square shape. They are numbered sequentially from 1 onwards, starting at the upper left corner, proceeding line by line downwards, each line in turn proceeding from left to right, and ending at the image’s lower right corner.

The following example illustrates the numbering scheme for raster image points by showing how the corner points are numbered, assuming an image length of x points and an image height of y points.

1

x

(x * (y-1) + 1)

(x * y)