1111 8e0
1111 8e0
1111 8e0
0 (2007-06) Mobile Equipment (SIM - ME) interface Technical Specification (Release 1999)
3GPP TS 11.11
The present document has been developed within the 3 rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organisational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organisational Partners accept no liability for any use of this Specification. Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organisational Partners' Publications Offices.
Release 1999
Keywords
Internet
http://www.3gpp.org
Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media.
2007, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TTA, TTC). All rights reserved.
3GPP
Release 1999
Contents
Contents....................................................................................................................................................3 Foreword...................................................................................................................................................9 1 Scope....................................................................................................................................................10 2 References............................................................................................................................................10 3 Definitions, abbreviations and symbols.................................................................................................12
3.1 Definitions...........................................................................................................................................................12 3.2 Abbreviations.......................................................................................................................................................13 3.3 Symbols................................................................................................................................................................15
4 Physical characteristics.........................................................................................................................15
4.1 Format and layout................................................................................................................................................15 4.1.1 ID-1 SIM...........................................................................................................................................................15 4.1.2 Plug-in SIM......................................................................................................................................................15 4.2 Temperature range for card operation.................................................................................................................16 4.3 Contacts...............................................................................................................................................................16 4.3.1 Provision of contacts.........................................................................................................................................16 4.3.2 Activation and deactivation..............................................................................................................................16 4.3.3 Inactive contacts...............................................................................................................................................16 4.3.4 Contact pressure...............................................................................................................................................16 4.4 Precedence...........................................................................................................................................................17 4.5 Static Protection...................................................................................................................................................17
6 Logical Model......................................................................................................................................23
6.1 General description..............................................................................................................................................23 6.2 File identifier.......................................................................................................................................................23 6.3 Dedicated files.....................................................................................................................................................24 6.4 Elementary files...................................................................................................................................................24 6.4.1 Transparent EF.................................................................................................................................................24 6.4.2 Linear fixed EF.................................................................................................................................................24 6.4.3 Cyclic EF..........................................................................................................................................................25 6.5 Methods for selecting a file.................................................................................................................................26 6.6 Reservation of file IDs.........................................................................................................................................26
7 Security features...................................................................................................................................27
7.1 Authentication and cipher key generation procedure.........................................................................................27 7.2 Algorithms and processes....................................................................................................................................28 7.3 File access conditions..........................................................................................................................................28
3GPP
Release 1999
8.6 UPDATE RECORD.............................................................................................................................................31 8.7 SEEK 32 8.8 INCREASE..........................................................................................................................................................32 8.9 VERIFY CHV......................................................................................................................................................33 8.10 CHANGE CHV..................................................................................................................................................33 8.11 DISABLE CHV.................................................................................................................................................33 8.12 ENABLE CHV..................................................................................................................................................34 8.13 UNBLOCK CHV...............................................................................................................................................34 8.14 INVALIDATE...................................................................................................................................................34 8.15 REHABILITATE...............................................................................................................................................35 8.16 RUN GSM ALGORITHM.................................................................................................................................35 8.17 SLEEP................................................................................................................................................................35 8.18 TERMINAL PROFILE......................................................................................................................................35 8.19 ENVELOPE.......................................................................................................................................................35 8.20 FETCH...............................................................................................................................................................36 8.21 TERMINAL RESPONSE..................................................................................................................................36
3GPP
Release 1999
10.3.8 EFACM (Accumulated call meter)................................................................................................................60 10.3.9 EFGID1 (Group Identifier Level 1)...............................................................................................................61 10.3.10 EFGID2 (Group Identifier Level 2).............................................................................................................61 10.3.11 EFSPN (Service Provider Name).................................................................................................................61 10.3.12 EFPUCT (Price per unit and currency table)...............................................................................................62 10.3.13 EFCBMI (Cell broadcast message identifier selection)...............................................................................63 10.3.14 EFBCCH (Broadcast control channels).......................................................................................................64 10.3.15 EFACC (Access control class).....................................................................................................................64 10.3.16 EFFPLMN (Forbidden PLMNs)...................................................................................................................65 10.3.17 EFLOCI (Location information)..................................................................................................................66 10.3.18 EFAD (Administrative data)........................................................................................................................67 10.3.19 EFPhase (Phase identification).....................................................................................................................68 10.3.20 EFVGCS (Voice Group Call Service)..........................................................................................................69 10.3.21 EFVGCSS (Voice Group Call Service Status).............................................................................................70 10.3.22 EFVBS (Voice Broadcast Service)...............................................................................................................71 10.3.23 EFVBSS (Voice Broadcast Service Status)..................................................................................................73 10.3.24 EFeMLPP (enhanced Multi Level Pre-emption and Priority).....................................................................73 10.3.25 EFAAeM (Automatic Answer for eMLPP Service).....................................................................................74 10.3.26 EFCBMID (Cell Broadcast Message Identifier for Data Download)..........................................................75 10.3.27 EFECC (Emergency Call Codes).................................................................................................................76 10.3.28 EFCBMIR (Cell broadcast message identifier range selection)..................................................................77 10.3.29 EFDCK De-personalization Control Keys...................................................................................................78 10.3.30 EFCNL (Co-operative Network List) ..........................................................................................................78 10.3.31 EFNIA (Network's Indication of Alerting)..................................................................................................79 10.3.32 EFKcGPRS (GPRS Ciphering key KcGPRS)..............................................................................................80 10.3.33 EFLOCIGPRS (GPRS location information)...............................................................................................80 10.3.34 EFSUME (SetUpMenu Elements)................................................................................................................82 10.3.35 EFPLMNwAcT (User controlled PLMN Selector with Access Technology)..............................................82 10.3.36 EFOPLMNwAcT (Operator controlled PLMN Selector with Access Technology)....................................84 10.3.37 EFHPLMNwAcT (HPLMN Selector with Access Technology)..................................................................85 10.3.38 EFCPBCCH (CPBCCH Information)..........................................................................................................85 10.3.39 EFInvScan (Investigation Scan)...................................................................................................................86 10.3.40 Void 87 10.4 Contents of DFs at the GSM application level..................................................................................................87 10.4.1 Contents of files at the GSM SoLSA level.....................................................................................................87 10.4.1.1 EFSAI (SoLSA Access Indicator)...............................................................................................................87 10.4.1.2 EFSLL (SoLSA LSA List)...........................................................................................................................88 10.4.1.3 LSA Descriptor files....................................................................................................................................90 10.4.2 Contents of files at the MExE level................................................................................................................91 10.4.2.1 EFMExE-ST (MExE Service table)............................................................................................................91 10.4.2.2 EFORPK (Operator Root Public Key).........................................................................................................92 10.4.2.3 EFARPK (Administrator Root Public Key)................................................................................................94 10.4.2.4 EFTPRPK (Third Party Root Public key)...................................................................................................94 10.4.2.5 Trusted Key/Certificates Data Files............................................................................................................95 10.5 Contents of files at the telecom level.................................................................................................................95 10.5.1 EFADN (Abbreviated dialling numbers).......................................................................................................95 10.5.2 EFFDN (Fixed dialling numbers)..................................................................................................................99 10.5.3 EFSMS (Short messages)...............................................................................................................................99 10.5.4 Capability configuration parameters............................................................................................................100 10.5.4.1 EFCCP (Capability configuration parameters).........................................................................................100 10.5.4.2 EFECCP (Extended Capability configuration parameters)......................................................................101 10.5.5 EFMSISDN (MSISDN)................................................................................................................................102 10.5.6 EFSMSP (Short message service parameters).............................................................................................102 10.5.7 EFSMSS (SMS status)..................................................................................................................................103 10.5.8 EFLND (Last number dialled).....................................................................................................................104 10.5.9 EFSDN (Service Dialling Numbers)............................................................................................................105 10.5.10 EFEXT1 (Extension1)................................................................................................................................105 10.5.11 EFEXT2 (Extension2)................................................................................................................................107 10.5.12 EFEXT3 (Extension3)................................................................................................................................107 10.5.13 EFBDN (Barred Dialling Numbers)..........................................................................................................107 10.5.14 EFEXT4 (Extension4)................................................................................................................................108 10.5.15 EFSMSR (Short message status reports)...................................................................................................108 10.5.16 EFCMI (Comparison Method Information)...............................................................................................109 10.6 DFs at the telecom level..................................................................................................................................109
3GPP
Release 1999
10.6.1 Contents of files at the telecom graphics level.............................................................................................109 10.6.1.1 EFIMG (Image).........................................................................................................................................109 10.6.1.2 Image Instance Data Files.........................................................................................................................111 10.7 Files of GSM....................................................................................................................................................112
11 Application protocol.........................................................................................................................115
11.1 General procedures..........................................................................................................................................117 11.1.1 Reading an EF..............................................................................................................................................117 11.1.2 Updating an EF.............................................................................................................................................117 11.1.3 Increasing an EF...........................................................................................................................................117 11.2 SIM management procedures..........................................................................................................................118 11.2.1 SIM initialization..........................................................................................................................................118 11.2.2 GSM session termination.............................................................................................................................119 11.2.3 Emergency Call Codes.................................................................................................................................120 11.2.4 Language preference.....................................................................................................................................120 11.2.5 Administrative information request; ...........................................................................................................120 11.2.6 SIM service table request..............................................................................................................................120 11.2.7 SIM phase request........................................................................................................................................120 11.2.8 SIM Presence Detection and Proactive Polling............................................................................................120 11.2.9 Extended Language preference....................................................................................................................121 11.3 CHV related procedures..................................................................................................................................121 11.3.1 CHV verification...........................................................................................................................................121 11.3.2 CHV value substitution.................................................................................................................................121 11.3.3 CHV disabling..............................................................................................................................................121 11.3.4 CHV enabling...............................................................................................................................................122 11.3.5 CHV unblocking...........................................................................................................................................122 11.4 GSM security related procedures.....................................................................................................................122 11.4.1 GSM algorithms computation......................................................................................................................122 11.4.2 IMSI request.................................................................................................................................................122 11.4.3 Access control request..................................................................................................................................122 11.4.4 Higher Priority PLMN search period request..............................................................................................122 11.4.5 Location information....................................................................................................................................122 11.4.6 Cipher key.....................................................................................................................................................123 11.4.7 BCCH information.......................................................................................................................................123 11.4.8 Forbidden PLMN..........................................................................................................................................123 11.4.9 LSA information...........................................................................................................................................123 11.4.10 GPRS Location information.......................................................................................................................123 11.4.11 GPRS Cipher key........................................................................................................................................123 11.5 Subscription related procedures......................................................................................................................123 11.5.1 Dialling numbers..........................................................................................................................................123 11.5.2 Short messages..............................................................................................................................................126 11.5.3 Advice of Charge (AoC)...............................................................................................................................126 11.5.4 Capability configuration parameters............................................................................................................126 11.5.5 PLMN selector..............................................................................................................................................127 11.5.6 Cell broadcast message identifier.................................................................................................................127 11.5.7 Group identifier level 1................................................................................................................................127 11.5.8 Group identifier level 2................................................................................................................................127 11.5.9 Service Provider Name.................................................................................................................................127 11.5.10 Voice Group Call Services.........................................................................................................................127 11.5.11 Voice Broadcast Services...........................................................................................................................127 11.5.12 Enhanced Multi Level Pre-emption and Priority Service..........................................................................128 11.5.13 Cell Broadcast Message range identifier....................................................................................................128 11.5.14 Depersonalisation Control Keys.................................................................................................................128 11.5.15 Short message status report........................................................................................................................128 11.5.16 Network's indication of alerting.................................................................................................................128 11.5.17 User controlled PLMN Selector with Access Technology.........................................................................129 11.5.18 Operator controlled PLMN Selector with Access Technology..................................................................129 11.5.19 HPLMN Selector with Access Technology................................................................................................129 11.4.20 CPBCCH information.................................................................................................................................129 11.5.21 Investigation Scan......................................................................................................................................129 11.5.22 Void 129 11.6 SIM Application Toolkit related procedures...................................................................................................129 11.6.1 Initialization procedure................................................................................................................................129 11.6.2 Proactive polling...........................................................................................................................................129
3GPP
Release 1999
11.6.3 Support of commands...................................................................................................................................130 11.6.4 Support of response codes............................................................................................................................130 11.6.5 Command-response pairs.............................................................................................................................130 11.6.6 Independence of normal GSM and SIM Application Toolkit tasks............................................................130 11.6.7 Use of BUSY status response.......................................................................................................................130 11.6.8 Use of NULL procedure byte........................................................................................................................130 11.6.9 Using the TERMINAL PROFILE, ENVELOPE, and TERMINAL RESPONSE commands....................131 11.6.10 Using the FETCH command......................................................................................................................131 11.6.11 Data Download via SMS-CB......................................................................................................................131 11.6.12 Data Download via SMS-PP......................................................................................................................131 11.6.13 Menu selection............................................................................................................................................131 11.6.14 Call Control................................................................................................................................................131 11.6.15 Proactive SIM.............................................................................................................................................131 11.6.16 Mobile Originated Short Message control by SIM....................................................................................131 11.6.17 SIM data download error............................................................................................................................132 11.6.18 Image Request.............................................................................................................................................132 11.7 MExE related procedures................................................................................................................................132 11.7.1 MExE ST......................................................................................................................................................132 11.7.2 Operator root public key...............................................................................................................................132 11.7.3 Administrator root public key......................................................................................................................132 11.7.4 Third Party root public key(s)......................................................................................................................132
Annex A (normative): Plug-in SIM..........................................................................................133 Annex B (normative): Coding of Alpha fields in the SIM for UCS2......................................134 Annex C (informative): FDN/BDN Procedures.........................................................................136 Annex D (informative): Suggested contents of the EFs at pre-personalization........................141 Annex E (informative): SIM application Toolkit protocol diagrams.......................................143 Annex F (informative): Examples of coding of LSA Descriptor files for SoLSA....................148 Annex G (normative): Image Coding Schemes........................................................................149 G.1 Basic Image Coding Scheme...........................................................................................................149 G.2 Colour Image Coding Scheme.........................................................................................................150 Annex H (normative): Coding of EFs for NAM and GSM-AMPS Operational Parameters152 H.1 Elementary File Definitions and Contents.......................................................................................152
H.1.1 EFMIN (Mobile Identification Number).......................................................................................................152 H.1.2 EFACCOLC (Access Overload Class)..........................................................................................................153 H.1.3 EFSID (System ID Of Home System)...........................................................................................................153 H.1.4 EFIPC (Initial Paging Channel)....................................................................................................................154 H.1.5 EFGPI (Group ID).........................................................................................................................................154 H.1.6 EFS-ESN (SIM Electronic Serial Number)...................................................................................................155 H.1.7 EFCOUNT (Call Count)................................................................................................................................155 H.1.8 EFPSID (Positive/Favoured SID list)............................................................................................................156 H.1.9 EFNSID (Negative/Forbidden SID List).......................................................................................................157 H.1.10 EFSPL (Scanning Priority List)...................................................................................................................158 H.1.11 EFNETSEL (Network Selection Activation Flag)......................................................................................159 H.1.12 EFCSID (Current/Last Registered SID)......................................................................................................160 H.1.13 EFREG-THRESH (Registration Threshold)...............................................................................................160 H.1.14 EFCCCH (Current Control Channel)..........................................................................................................160
3GPP
Release 1999
H.1.15 EFLDCC (Latest DCC)................................................................................................................................161 H.1.16 EFGSM-RECON (GSM Reconnect Timer)................................................................................................161 H.1.17 EFAMPS-2-GSM (AMPS to GSM Rescan Timing Table).........................................................................162 H.1.18 EF*FC1 (Feature Activation Codes)...........................................................................................................162 H.1.19 EFAMPS-UI (AMPS USAGE INDICATORS)...........................................................................................163
Annex I (informative): EF changes via Data Download or SIM Toolkit applications............169 Annex J (informative): Change history.....................................................................................172
3GPP
Release 1999
Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document.
3GPP
Release 1999
10
Scope
The present document defines the interface between the Subscriber Identity Module (SIM) and the Mobile Equipment (ME) for use during the network operation phase of GSM as well as those aspects of the internal organization of the SIM which are related to the network operation phase. This is to ensure interoperability between a SIM and an ME independently of the respective manufacturers and operators. The concept of a split of the Mobile Station (MS) into these elements as well as the distinction between the GSM network operation phase, which is also called GSM operations, and the administrative management phase are described in the TS 02.17 [6]. The present document defines: the requirements for the physical characteristics of the SIM, the electrical signals and the transmission protocols; the model which shall be used as a basis for the design of the logical structure of the SIM; the security features; the interface functions; the commands; the contents of the files required for the GSM application; the application protocol.
Unless otherwise stated, references to GSM also apply to DCS 1800 and PCS 1900. The present document does not specify any aspects related to the administrative management phase. Any internal technical reallocation of either the SIM or the ME are only specified where these reflect over the interface. It does not specify any of the security algorithms which may be used. The present document defines the SIM/ME interface for GSM Phase 2. While all attempts have been made to maintain phase compatibility, any issues that specifically relate to Phase 1 should be referenced from within the relevant Phase 1 specification.
References
References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific. For a specific reference, subsequent revisions do not apply.
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document . [1] [2] [3] [4] [5] [6] [7] not used 3GPP TS 01.04: "Abbreviations and acronyms". 3GPP TS 02.07: "Mobile Stations (MS) features". 3GPP TS 02.09: " Security aspects". 3GPP TS 22.011: " Service accessibility". 3GPP TS 02.17: "Subscriber Identity Modules (SIM) Functional characteristics". 3GPP TS 22.024: " Description of Charge Advice Information (CAI)".
3GPP
Release 1999
11
[8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35]
3GPP TS 02.30: "Man-Machine Interface (MMI) of the Mobile Station (MS)". 3GPP TS 22.086: "Advice of charge (AoC) Supplementary Services - Stage 1". 3GPP TS 23.003: "Numbering, addressing and identification". 3GPP TS 03.20: "Security related network functions". 3GPP TS 23.038: "Alphabets and language-specific information". 3GPP TS 23.040: "Technical realization of the Short Message Service (SMS) Point-to-Point (PP)". 3GPP TS 23.041: "Technical realization of Short Message Service Cell Broadcast (SMSCB)". 3GPP TS 04.08: "Mobile radio interface layer 3 specification". 3GPP TS 24.011: "Point-to-Point (PP) Short Message Service (SMS) support on mobile radio interface". 3GPP TS 09.91: " Interworking aspects of the Subscriber Identity Module - Mobile Equipment (SIM - ME) interface between Phase 1 and Phase 2". CCITT Recommendation E.118: "The international telecommunication charge card". CCITT Recommendation E.164: "Numbering plan for the ISDN era". CCITT Recommendation T.50: "International Alphabet No. 5". (ISO 646: 1983, "Information processing - ISO 7-bits coded characters set for information interchange".) ISO/IEC 7810 (1995): "Identification cards - Physical characteristics". ISO/IEC 7811-1 (1995): "Identification cards - Recording technique - Part 1: Embossing". Void ISO/IEC 7816-1 : "Identification cards - Integrated circuit cards Part 1: Card with contacts: Physical characteristics". ISO/IEC 7816-2 : "Identification cards - Integrated circuit cards Part 2: Card with contacts: Dimensions and locations of the contacts". ISO/IEC 7816-3: "Identification cards - Integrated circuit cards. Part 3: Cards with contacts: Electronic signals and transmission protocols". 3GPP TS 11.14: "Specification of the SIM Application Toolkit for the Subscriber Identity Module - Mobile Equipment (SIM - ME) interface". 3GPP TS 11.12: " Specification of the 3 Volt Subscriber Identity Module - Mobile Equipment (SIM - ME) interface". 3GPP TS 22.022: "Personalization of Mobile Equipment (ME) Mobile functionality specification". ISO 639 (1988): "Code for the representation of names of languages". ISO/IEC 10646-1 (1993): "Information technology - Universal Multiple-Octet Coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane". 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2". 3GPP TS 23.073: "Support of Localised Service Area (SoLSA); Service description; Stage 2". 3GPP TS 11.19: "Specification of the Cordless Telephony System Subscriber Identity Module for both Fixed Part and Mobile Station". ISO/IEC 7816-4 : "Identification cards - Integrated circuit cards Part 4: Organization, security and commands for interchange".
3GPP
Release 1999
12
[36] [37] [38] [39] [40] [41] [42] [43] [44] [45] [46] [47] [48] [49] [50] [51] [52]
TIA/EIA-136-005: "Introduction, Identification, and Semi-Permanent Memory, November 1998". TIA/EIA-136-123-A: "Digital Control Channel Layer 3, November 1998". TIA/EIA-136-140-A: "Analogue Control Channel, November 1998". TIA/EIA-136-510-A: "Authentication, Encryption of Signaling Information/User Data and Privacy, November 1998". ANSI TIA/EIA-41: "Cellular Radio Telecommunications Intersystem Operations". EIA/TIA-553: "Mobile Station-Land Station Compatibility Specification". 3GPP TS 22.067: "Enhanced Multi Level Pre-emption and Priority (eMLPP) Services - Stage 1". TR45 AHAG "Common Cryptographic Algorithms, Revision C," October 27, 1998. ETS 300.812: "Terrestrial Trunk Radio; Specification of the Subscriber Identity Module - Mobile Equipment (SIM - ME) interface". 3GPP TS 03.22: "Functions related to Mobile Station (MS) in idle mode and group receive mode". 3GPP TS 05.05: "Radio transmission and reception". 3GPP TS 24.008: "Mobile Radio Interface Layer 3 specification, Core Network Protocols". 3GPP TS 04.18: "Mobile radio interface layer 3 specification, Radio Resource Control Protocol". 3GPP TS 04.60: "General Packet Radio Service (GPRS); Mobile Station (MS) - Base Station System (BSS) interface; Radio Link Control/ Medium Access Control (RLC/MAC) protocol". 3GPP TS 23.057: "Mobile Station Application Execution Environment (MExE);Functional description; Stage 2". 3GPP TS 23.122: "Technical Specification Group Core Network; NAS Functions related to Mobile Station (MS) in idle mode". 3GPP TS 31.102: "Characteristics of the USIM application".
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply: access conditions: set of security attributes associated with a file. application: application consists of a set of security mechanisms, files, data and protocols (excluding transmission protocols). application protocol: set of procedures required by the application. card session: link between the card and the external world starting with the ATR and ending with a subsequent reset or a deactivation of the card. current directory: latest MF or DF selected. current EF: latest EF selected. data field: obsolete term for Elementary File. Dedicated File (DF): file containing access conditions and, optionally, Elementary Files (EFs) or other Dedicated Files (DFs). directory: general term for MF and DF.
3GPP
Release 1999
13
Elementary File (EF): file containing access conditions and data and no other files. file: directory or an organized set of bytes or records in the SIM. file identifier: 2 bytes which address a file in the SIM. GSM, DCS 1800 or PCS 1900 application: set of security mechanisms, files, data and protocols required by GSM, DCS 1800 or PCS 1900. GSM session: that part of the card session dedicated to the GSM operation. IC card SIM: obsolete term for ID-1 SIM. ID-1 SIM: SIM having the format of an ID-1 card (see ISO/IEC 7816-1 [24]). Master File (MF): unique mandatory file containing access conditions and optionally DFs and/or EFs. normal GSM operation: relating to general, CHV related, GSM security related and subscription related procedures. padding: one or more bits appended to a message in order to cause the message to contain the required number of bits or bytes. plug-in SIM: Second format of SIM (specified in clause 4). proactive SIM: SIM which is capable of issuing commands to the ME. Part of SIM Application Toolkit (see clause 11). record: string of bytes within an EF handled as a single entity (see clause 6). record number: number which identifies a record within an EF. record pointer: pointer which addresses one record in an EF. root directory: obsolete term for Master File. SIM application toolkit procedures: defined in TS 11.14 [27].
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply, in addition to those listed in TS 01.04 [2]: A3 A38 A5 A8 ACM ADM ADN AHAG A-Key ALW AMPS ANSI AoC APDU ATR BCCH BCD BDN BTS CB CBMI CCITT CCP Algorithm 3, authentication algorithm; used for authenticating the subscriber A single algorithm performing the functions of A3 and A8 Algorithm 5, cipher algorithm; used for enciphering/deciphering data Algorithm 8, cipher key generator; used to generate K c Accumulated Call Meter Access condition to an EF which is under the control of the authority which creates this file Abbreviated Dialling Number Ad-Hoc Authentication Group Authentication Key ALWays Analogue Mobile Phone System American National Standards Institute Advice of Charge Application Protocol Data Unit Answer To Reset Broadcast Control CHannel Binary Coded Decimal Barred Dialling Number Base Transmitter Station Cell Broadcast Cell Broadcast Message Identifier The International Telegraph and Telephone Consultative Committee (now ITU Telecommunications Standardization sector) Capability/Configuration Parameter
3GPP
Release 1999
14
CHV CLA CNL CPBCCH CTS DCK DCS DF DTMF ECC EF EIA eMLPP ETSI etu FDN GSM HPLMN IC ICC ID IEC IMSI ISO Kc Ki LAI lgth LND LSA LSA ID LSB MCC ME MF MMI MNC MS MSB MSISDN NAM NET NEV NPI OFM OPLMN OTA PDC PIN/PIN2 PLMN PPS PUK/PUK2 RAND RFU SDN SID SIM SMS SoLSA SRES
Card Holder Verification information; access condition used by the SIM for the verification of the identity of the user CLAss Co-operative Network List COMPACT Packet BCCH Cordless Telephony System De-personalization Control Keys Digital Cellular System Dedicated File (abbreviation formerly used for Data Field) Dual Tone Multiple Frequency Emergency Call Code Elementary File Electronics Industries Alliance (North America) enhanced Multi-Level Precedence and Pre-emption Service European Telecommunications Standards Institute elementary time unit Fixed Dialling Number Global System for Mobile communications Home PLMN Integrated Circuit Integrated Circuit(s) Card IDentifier International Electrotechnical Commission International Mobile Subscriber Identity International Organization for Standardization Cryptographic key; used by the cipher A5 Subscriber authentication key; the cryptographic key used by the authentication algorithm, A3, and cipher key generator, A8 Location Area Information; information indicating a cell or a set of cells The (specific) length of a data unit Last Number Dialled Localised Service Area Localised Service Area Identity Least Significant Bit Mobile Country Code Mobile Equipment Master File Man Machine Interface Mobile Network Code Mobile Station Most Significant Bit Mobile Station international ISDN number Numeric Assignment Module NETwork NEVer Numbering Plan Identifier Operational Feature Monitor Operator Controlled PLMN (Selector List) Over The Air Personal Digital Communications Personal Identification Number / Personal Identification Number 2 (obsolete terms for CHV1 and CHV2, respectively) Public Land Mobile Network Protocol and Parameter Select (response to the ATR) PIN Unblocking Key / PIN2 Unblocking Key (obsolete terms for UNBLOCK CHV1 and UNBLOCK CHV2, respectively) A RANDom challenge issued by the network Reserved for Future Use Service Dialling Number System IDentity Subscriber Identity Module Short Message Service Support of Localised Service Area Signed RESponse calculated by a SIM
3GPP
Release 1999
15
SSC Supplementary Service Control string SW1/SW2 Status Word 1 / Status Word 2 TETRA TErrestrial Trunk RAdio TIA Telecommunications Industries Association (North America) TMSI Temporary Mobile Subscriber Identity TON Type Of Number TP Transfer layer Protocol TPDU Transfer Protocol Data Unit TS Technical Specification UNBLOCK CHV1/2 value to unblock CHV1/CHV2 VBS Voice Broadcast Service VGCS Voice Group Call Service VPLMN Visited PLMN
3.3 Symbols
For the purposes of the present document, the following symbols apply: Vcc Supply voltage Vpp Programming voltage '0' to '9' and 'A' to 'F' the sixteen hexadecimal digits
Physical characteristics
Two physical types of SIM are specified. These are the "ID-1 SIM" and the "Plug-in SIM". The physical characteristics of both types of SIM shall be in accordance with ISO/IEC 7816-1,2 [24, 25] unless otherwise specified. The following additional requirements shall be applied to ensure proper operation in the GSM environment.
3GPP
Release 1999
16
4.3 Contacts
4.3.1 Provision of contacts
ME: Contacting elements in the ME in positions C4 and C8 are optional, and are not used in the GSM application. They shall present a high impedance to the SIM card in the GSM application. If it is determined that the SIM is a multi-application ICC, then these contacts may be used. Contact C6 need not be provided for Plug-in SIMs. Contacts C4 and C8 need not be provided by the SIM, but if they are provided, then they shall not be connected internally in the SIM if the SIM only contains the GSM application. Contact C6 shall not be bonded in the SIM for any function other than supplying Vpp.
SIM:
3GPP
Release 1999
17
4.4 Precedence
See TS 02.17 [6] for precedence.
Electronic signals and transmission protocols shall be in accordance with ISO/IEC 7816-3 [26] unless specified otherwise. The following additional requirements shall be applied to ensure proper operation in the GSM environment. The choice of the transmission protocol(s), to be used to communicate between the SIM and the ME, shall at least include that specified and denoted by T=0 in ISO/IEC 7816-3 [26]. The values given in the tables hereafter are derived from ISO/IEC 7816-3 [26] with the following considerations: VOH and VOL always refer to the device (ME or SIM) which is driving the interface. V IH and VIL always refer to the device (ME or SIM) which is operating as a receiver on the interface. this convention is different to the one used in ISO/IEC 7816-3 [26], which specifically defines an ICC for which its current conventions apply. The following clauses define the specific core requirements for the SIM, which provide also the basis for Type Approval. For each state (VOH, VIH, VIL and VOL) a positive current is defined as flowing out of the entity (ME or SIM) in that state.
The current consumption of the SIM shall not exceed the value given in table 1 during any state (including activation and deactivation as defined in subclause 4.3.2). When the SIM is in idle state (see below) the current consumption of the card shall not exceed 200 A at 1 MHz and 25C. If clock stop mode is allowed, then the current consumption shall also not exceed 200 A while the clock is stopped. The ME shall source the maximum current requirements defined above. It shall also be able to counteract spikes in the current consumption of the card up to a maximum charge of 40 nAs with no more than 400 ns duration and an amplitude of at most 200 mA, ensuring that the supply voltage stays in the specified range. NOTE: A possible solution would be to place a capacitor (e.g. 100 nF, ceramic) as close as possible to the contacting elements.
3GPP
Release 1999
18
3GPP
Release 1999
19
5.6 States
There are two states for the SIM while the power supply is on: the SIM is in operating state when it executes a command. This state also includes transmission from and to the ME; the SIM is in idle state at any other time. It shall retain all pertinent data during this state.
The SIM may support a clock stop mode. The clock shall only be switched off subject to the conditions specified in the file characteristics (see clause 9). Clock stop mode. An ME of Phase 2 or later shall wait at least 1 860 clock cycles after having received the last character, including the guard time (2 etu), of the response before it switches off the clock (if it is allowed to do so). It shall wait at least 744 clock cycles before it sends the first command after having started the clock. To achieve phase compatibility, the following procedure shall be adhered to: a SIM of Phase 2 or later shall always send the status information "normal ending of the command" after the successful interpretation of the command SLEEP received from a Phase 1 ME. An ME of Phase 2 or later shall not send a SLEEP command; a Phase 1 ME shall wait at least 744 clock cycles after having received the compulsory acknowledgement SW1 SW2 of the SLEEP command before it switches off the clock (if it is allowed to do so). It shall wait at least 744 clock cycles before it sends the first command after having started the clock.
5.7 Baudrate
The initial baudrate (during ATR) shall be: (clock frequency)/372. Subsequent baudrate shall be: (clock frequency)/372 unless the PPS procedure has been successfully performed. In that case the negotiated baudrate shall be applied according to subclause 5.8.2.
3GPP
Release 1999
20
Table 5: ATR
Character 1. Initial character TS 2. Format character T0 3. Interface character (global) TA1 4. Interface character (global) TB1 5. Interface character (global) TC1 6. Interface character TD1 7. Interface character (specific) TA2 8. Interface character (global) TB2 9. Interface character (specific) TC2 10. Interface character TDi (i>1) Contents coding convention for all subsequent characters (direct or inverse convention) subsequent interface characters, number of historical characters parameters to calculate the work etu sent by the card always a) evaluation by the ME b) reaction by the ME a) always b) using appropriate convention always a) always b) identifying the subsequent characters accordingly a) always if present b) if TA1 is not '11' or '01', PPS procedure shall be used (see subclause 5.8.2) parameters to calculate the programming voltage and current parameters to calculate the extra guardtime requested by the card; no extra guardtime is used to send characters from the card to the ME protocol type; indicator for the presence of interface characters, specifying rules to be used for transmissions with the given protocol type not used for protocol T=0 optional a) always if present b) if PI1 is not 0, then reject the SIM (in accordance with subclause 5.10) optional a) always if present b) if TC1 is neither 0 nor 255, then reject the SIM (in accordance with subclause 5.10); see the note after the table always, if T=15 indicated in TDi (i>1) optional a) always if present b) identifying the subsequent characters accordingly a) optional b) -------parameter to calculate the programming voltage never the allowed value of TB1 above defines that an external programming voltage is not applicable
optional
optional
protocol type; indicator for the presence of interface characters, specifying rules to be used for transmissions with the given protocol type
optional
(continued)
3GPP
Release 1999
21
NOTE:
Figure 1: PPS procedure PPS Request and PPS Response consist of the three (3) characters PPSS, PPSO and PCK of which PPSS is sent first. After this procedure the protocol T=0 and the parameters F=372, D=1 and N=0 shall be used.
3GPP
Release 1999
22
Figure 2: PPS procedure requesting enhanced speed values (F=512, D=8, see clause 5.8.3) PPS Request and PPS Response consist of the four (4) characters PPSS, PPSO, PPS1 and PCK, of which PPSS is sent first. After this procedure, the protocol T=0 and the parameters F=512, D=8 and N=0 shall be used.
3GPP
Release 1999
23
Logical Model
This clause describes the logical structure for a SIM, the code associated with it, and the structure of files used.
EF
EF
....
Figure 3: Organization of memory Files are composed of a header, which is internally managed by the SIM, and optionally a body part. The information of the header is related to the structure and attributes of the file and may be obtained by using the commands GET RESPONSE or STATUS. This information is fixed during the administrative phase. The body part contains the data of the file.
File IDs shall be subject to the following conditions: the file ID shall be assigned at the time of creation of the file concerned; no two files under the same parent shall have the same ID;
3GPP
Release 1999
24
a child and any parent, either immediate or remote in the hierarchy, e.g. grandparent, shall never have the same file ID.
All four files are immediate children of the Master File (MF) and may coexist on a multi-application card. 2nd level DFs are defined in this specification under DF GSM. All 2nd level DFs are immediate children of the DFGSM and may coexist on a multi-application card.
6.4.1 Transparent EF
An EF with a transparent structure consists of a sequence of bytes. When reading or updating, the sequence of bytes to be acted upon is referenced by a relative address (offset), which indicates the start position (in bytes), and the number of bytes to be read or updated. The first byte of a transparent EF has the relative address '00 00'. The total data length of the body of the EF is indicated in the header of the EF.
Header Body Sequence of bytes
NOTE:
3GPP
Release 1999
25
Header Body
Figure 5: Structure of a linear fixed file There are several methods to access records within an EF of this type: absolutely using the record number; when the record pointer is not set it shall be possible to perform an action on the first or the last record by using the NEXT or PREVIOUS mode; when the record pointer is set it shall be possible to perform an action on this record, the next record (unless the record pointer is set to the last record) or the previous record (unless the record pointer is set to the first record); by identifying a record using pattern seek starting: forwards from the beginning of the file; forwards from the record following the one at which the record pointer is set (unless the record pointer is set to the last record); backwards from the end of the file; backwards from the record preceding the one at which the record pointer is set (unless the record pointer is set to the first record).
If an action following selection of a record is aborted, then the record pointer shall remain set at the record at which it was set prior to the action. According to ISO/IEC 7816-4 [35] it is not possible to have more than 254 records in a file of this type, and each record can not be more than 255 bytes using the short command APDU format. NOTE: This structure was previously referred to as "formatted" in GSM.
6.4.3 Cyclic EF
Cyclic files are used for storing records in chronological order. When all records have been used for storage, then the next storage of data shall overwrite the oldest information. An EF with a cyclic structure consists of a fixed number of records with the same (fixed) length. In this file structure there is a link between the last record (n) and the first record. When the record pointer is set to the last record n, then the next record is record 1. Similarly, when the record pointer is set to record 1, then the previous record is record n. The last updated record containing the newest data is record number 1, and the oldest data is held in record number n.
Header Body Record 1 Record 2 : : Record n
Figure 6: Structure of a cyclic file For update operations only PREVIOUS record shall be used. For reading operations, the methods of addressing are Next, Previous, Current and Record Number. After selection of a cyclic file (for either operation), the record pointer shall address the record updated or increased last. If an action following selection of a record is aborted, then the record pointer shall remain set at the record at which it was set prior to the action.
3GPP
Release 1999
26
NOTE:
It is not possible, at present, to have more than 255 records in a file of this type, and each record cannot be greater than 255 bytes.
This means in particular that a DF shall be selected prior to the selection of any of its EFs. All selections are made using the file ID. The following figure gives the logical structure for the GSM application. GSM defines only two levels of DFs under the MF.
Figure 7: Logical structure The following table gives the valid selections for GSM for the logical structure in figure 7. Reselection of the last selected file is also allowed but not shown. Table 6: File selection
Last selected file MF DF1 DF2 DF3 EF1 EF2 EF3 EF5 Valid Selections DF1, DF2, EF1 MF, DF2, DF3, EF2 MF, DF1, EF3, EF4 MF, DF1, EF5 MF, DF1, DF2 MF, DF1, DF2, DF3 MF, DF1, DF2, EF4 MF, DF1, DF3
3GPP
Release 1999
27
'7F 10' (DFTELECOM), '7F 20' (DFGSM), '7F 21' (DFDCS1800), '7F 22' (DFIS-41), '7F 23' (DFFP-CTS) (see TS 11.19 [34]), '7F 24' (DFTIA/EIA-136), '7F 25' (DFTIA/EIA-95), and '7F 2X', where X ranges from '6' to 'F'. NOTE: '7F 80' (DFPDC) is used in the Japanese PDC specification. '7F 90' (DFTETRA) is used in the ETSI TETRA specification [44] '7F 31' (DFiDEN) is used in the iDEN specification.
reserved under '7F20': '5F30' (DFIRIDIUM), '5F31' (DFGlobalstar), '5F32' (DFICO), '5F33' (DFACeS), '5F3C' (DFMExE), '5F3X', where X ranges from '4' to 'B' and 'D' to 'F'; '5F40'(DFEIA/TIA-553), '5F4Y' where Y ranges from '1' to 'F'; '5F5X' where X ranges from '0' to 'F'; '5F60'(DFCTS), '5F6Y' where Y ranges from '1' to 'F'; '5F70' (DFSoLSA), '5F7Y' where Y ranges from '1' to 'F'; '5FYX' where Y ranges from '8' to 'F' and X from '0' to 'F'.
Elementary files: administrative use: '6F XX' in the DFs '7F 4X'; '4F XX' in the DFs '5F 1X', '5F2X' '6F 1X' in the DFs '7F 10', '7F 20', '7F 21'; '4F 1X' in all 2nd level DFs '2F 01', '2F EX' in the MF '3F 00'; operational use: '6F 2X', '6F 3X', '6F 4X' in '7F 10' and '7F 2X'; '4F YX', where Y ranges from '2' to 'F' in all 2 nd level DFs. '2F 1X' in the MF '3F 00'. In all the above, X ranges, unless otherwise stated, from '0' to 'F'.
7
-
Security features
authentication of the subscriber identity to the network; data confidentiality over the radio interface; file access conditions.
The security aspects of GSM are described in the normative references TS 02.09 [4] and TS 03.20 [11]. This clause gives information related to security features supported by the SIM to enable the following:
3GPP
Release 1999
28
The network sends a Random Number (RAND) to the MS. The ME passes the RAND to the SIM in the command RUN GSM ALGORITHM. The SIM returns the values SRES and Kc to the ME which are derived using the algorithms and processes given below. The ME sends SRES to the network. The network compares this value with the value of SRES which it calculates for itself. The comparison of these SRES values provides the authentication. The value Kc is used by the ME in any future enciphered communications with the network until the next invocation of this mechanism. A subscriber authentication key Ki is used in this procedure. This key Ki has a length of 128 bits and is stored within the SIM for use in the algorithms described below.
These algorithms may exist either discretely or combined (into A38) within the SIM. In either case the output on the SIM/ME interface is 12 bytes. The inputs to both A3 and A8, or A38, are Ki (128 bits) internally derived in the SIM, and RAND (128 bits) across the SIM/ME interface. The output is SRES (32 bits)/Kc (64 bits) the coding of which is defined in the command RUN GSM ALGORITHM in clause 9.
No file access conditions are currently assigned by GSM to the MF and the DFs. The access condition levels are defined in the following table: Table 7: Access condition level coding
Level 0 1 2 3 4 to 14 15 Access Condition ALWays CHV1 CHV2 Reserved for GSM Future Use ADM NEVer
The meaning of the file access conditions is as follows: ALWAYS: The action can be performed without any restriction; CHV1 (card holder verification 1): The action shall only be possible if one of the following three conditions is fulfilled: a correct CHV1 value has already been presented to the SIM during the current session; the CHV1 enabled/disabled indicator is set to "disabled"; Some Phase 1 and Phase 2 SIMs do not necessarily grant access when CHV1 is "disabled" and "blocked".
NOTE: -
UNBLOCK CHV1 has been successfully performed during the current session;
CHV2: The action shall only be possible if one of the following two conditions is fulfilled:
3GPP
Release 1999
29
a correct CHV2 value has already been presented to the SIM during the current session; UNBLOCK CHV2 has been successfully performed during the current session;
ADM: Allocation of these levels and the respective requirements for their fulfilment are the responsibility of the appropriate administrative authority The definition of access condition ADM does not preclude the administrative authority from using ALW, CHV1, CHV2 and NEV if required. NEVER: The action cannot be performed over the SIM/ME interface. The SIM may perform the action internally. Condition levels are not hierarchical. For instance, correct presentation of CHV2 does not allow actions to be performed which require presentation of CHV1. A condition level which has been satisfied remains valid until the end of the GSM session as long as the corresponding secret code remains unblocked, i.e. after three consecutive wrong attempts, not necessarily in the same card session, the access rights previously granted by this secret code are lost immediately. A satisfied CHV condition level applies to both DF GSM and DFTELECOM. The ME shall determine whether CHV2 is available by using the response to the STATUS command. If CHV2 is "not initialized" then CHV2 commands, e.g. VERIFY CHV2, shall not be executable.
This clause gives a functional description of the commands and their respective responses. Associated status conditions, error codes and their corresponding coding are specified in clause 9. It shall be mandatory for all cards complying with this Standard to support all functions described in this Standard. The command GET RESPONSE which is needed for the protocol T=0 is specified in clause 9. The following table lists the file types and structures together with the functions which may act on them during a GSM session. These are indicated by an asterisk (*). Table 8: Functions on files in GSM session
File Function SELECT STATUS READ BINARY UPDATE BINARY READ RECORD UPDATE RECORD SEEK INCREASE INVALIDATE REHABILITATE MF * * DF * * EF transparent * * * * EF linear fixed * * EF cyclic * *
* * * * * * *
* * * * *
8.1 SELECT
This function selects a file according to the methods described in clause 6. After a successful selection the record pointer in a linear fixed file is undefined. The record pointer in a cyclic file shall address the last record which has been updated or increased. Input: file ID.
3GPP
Release 1999
30
file ID, total memory space available, CHV enabled/disabled indicator, CHV status and other GSM specific data; if the selected file is an EF: file ID, file size, access conditions, invalidated/not invalidated indicator, structure of EF and length of the records in case of linear fixed structure or cyclic structure.
8.2 STATUS
This function returns information concerning the current directory. A current EF is not affected by the STATUS function. It is also used to give an opportunity for a pro-active SIM to indicate that the SIM wants to issue a SIM Application Toolkit command to the ME. Input: none.
Output: file ID, total memory space available, CHV enabled/disabled indicator, CHV status and other GSM specific data (identical to SELECT above).
Output: none.
3GPP
Release 1999
31
NEXT: The record pointer is incremented before the READ RECORD function is performed and the pointed record is read. If the record pointer has not been previously set within the selected EF, then READ RECORD (next) shall read the first record and set the record pointer to this record. If the record pointer addresses the last record in a linear fixed EF, READ RECORD (next) shall not cause the record pointer to be changed, and no data shall be read. If the record pointer addresses the last record in a cyclic EF, READ RECORD (next) shall set the record pointer to the first record in this EF and this record shall be read. PREVIOUS: The record pointer is decremented before the READ RECORD function is performed and the pointed record is read. If the record pointer has not been previously set within the selected EF, then READ RECORD (previous) shall read the last record and set the record pointer to this record. If the record pointer addresses the first record in a linear fixed EF, READ RECORD (previous) shall not cause the record pointer to be changed, and no data shall be read. If the record pointer addresses the first record in a cyclic EF, READ RECORD (previous) shall set the record pointer to the last record in this EF and this record shall be read. Input: mode, record number (absolute mode only) and the length of the record.
Output: none.
3GPP
Release 1999
32
8.7 SEEK
This function searches through the current linear fixed EF to find a record starting with the given pattern. This function shall only be performed if the READ access condition for this EF is satisfied. Two types of SEEK are defined: Type 1 Type 2 NOTE: The record pointer is set to the record containing the pattern, no output is available. The record pointer is set to the record containing the pattern, the output is the record number. A Phase 1 SIM only executes type 1 of the SEEK function.
The SIM shall be able to accept any pattern length from 1 to 16 bytes inclusive. The length of the pattern shall not exceed the record length. Four modes are defined: from the beginning forwards; from the end backwards; from the next location forwards; from the previous location backwards.
If the record pointer has not been previously set (its status is undefined) within the selected linear fixed EF, then the search begins: with the first record in the case of SEEK from the next location forwards; or with the last record in the case of SEEK from the previous location backwards.
After a successful SEEK, the record pointer is set to the record in which the pattern was found. The record pointer shall not be changed by an unsuccessful SEEK function. Input: type and mode; pattern; length of the pattern.
8.8 INCREASE
This function adds the value given by the ME to the value of the last increased/updated record of the current cyclic EF, and stores the result into the oldest record. The record pointer is set to this record and this record becomes record number 1. This function shall be used only if this EF has an INCREASE access condition assigned and this condition is fulfilled (see bytes 8 and 10 in the response parameters/data of the current EF, clause 9). The SIM shall not perform the increase if the result would exceed the maximum value of the record (represented by all bytes set to 'FF'). Input: the value to be added.
Output: value of the increased record; value which has been added.
3GPP
Release 1999
33
If the access condition for a function to be performed on the last selected file is CHV1 or CHV2, then a successful verification of the relevant CHV is required prior to the use of the function on this file unless the CHV is disabled. If the CHV presented is correct, the number of remaining CHV attempts for that CHV shall be reset to its initial value 3. If the CHV presented is false, the number of remaining CHV attempts for that CHV shall be decremented. After 3 consecutive false CHV presentations, not necessarily in the same card session, the respective CHV shall be blocked and the access condition can never be fulfilled until the UNBLOCK CHV function has been successfully performed on the respective CHV. Input: indication CHV1/CHV2, CHV.
Output: none.
The old and new CHV shall be presented. If the old CHV presented is correct, the number of remaining CHV attempts for that CHV shall be reset to its initial value 3 and the new value for the CHV becomes valid. If the old CHV presented is false, the number of remaining CHV attempts for that CHV shall be decremented and the value of the CHV is unchanged. After 3 consecutive false CHV presentations, not necessarily in the same card session, the respective CHV shall be blocked and the access condition can never be fulfilled until the UNBLOCK CHV function has been performed successfully on the respective CHV. Input: - indication CHV1/CHV2, old CHV, new CHV. Output: - none.
3GPP
Release 1999
34
Input: CHV1.
Output: none.
Output: none.
8.14 INVALIDATE
This function invalidates the current EF. After an INVALIDATE function the respective flag in the file status shall be changed accordingly. This function shall only be performed if the INVALIDATE access condition for the current EF is satisfied. An invalidated file shall no longer be available within the application for any function except for the SELECT and the REHABILITATE functions unless the file status of the EF indicates that READ and UPDATE may also be performed. Input: none.
Output: none.
3GPP
Release 1999
35
8.15 REHABILITATE
This function rehabilitates the invalidated current EF. After a REHABILITATE function the respective flag in the file status shall be changed accordingly. This function shall only be performed if the REHABILITATE access condition for the current EF is satisfied. If BDN is enabled (see subclause 11.5.1) then the REHABILITATE function shall not rehabilitate the invalidated EFIMSI and EFLOCI until the PROFILE DOWNLOAD procedure is performed indicating that the ME supports the "Call control by SIM" facility (see TS 11.14 [27]). Input: none.
Output: none.
The contents of Kc shall be presented to algorithm A5 by the ME in its full 64 bit format as delivered by the SIM.
8.17 SLEEP
This is an obsolete GSM function which was issued by Phase 1 MEs. The function shall not be used by an ME of Phase 2 or later.
Output: none.
8.19 ENVELOPE
This function is used to transfer data to the SIM Application Toolkit applications in the SIM. Input: data string.
3GPP
Release 1999
36
8.20 FETCH
This function is used to transfer an Application Toolkit command from the SIM to the ME. Input: none.
Output: data string containing an SIM Application Toolkit command for the ME.
Output: none.
This clause states the general principles for mapping the functions described in clause 8 onto Application Protocol Data Units which are used by the transmission protocol.
An APDU is transported by the T=0 transmission protocol without any change. Other protocols might embed an APDU into their own transport structure (ISO/IEC 7816-3 [26]). The bytes have the following meaning: CLA is the class of instruction (ISO/IEC 7816-3 [26]), 'A0' is used in the GSM application; INS is the instruction code (ISO/IEC 7816-3 [26]) as defined in this subclause for each command; P1, P2, P3 are parameters for the instruction. They are specified in table 9. 'FF' is a valid value for P1, P2 and P3. P3 gives the length of the data element. P3='00' introduces a 256 byte data transfer from the SIM in an outgoing data transfer command (response direction). In an ingoing data transfer command (command direction), P3='00' introduces no transfer of data; SW1 and SW2 are the status words indicating the successful or unsuccessful outcome of the command.
3GPP
Release 1999
37
For some of the functions described in clause 8 it is necessary for T=0 to use a supplementary transport service command (GET RESPONSE) to obtain the output data. For example, the SELECT function needs the following two commands: the first command (SELECT) has both parameters and data serving as input for the function; the second command (GET RESPONSE) has a parameter indicating the length of the data to be returned.
If the length of the response data is not known beforehand, then its correct length may be obtained by applying the first command and interpreting the status words. SW1 shall be '9F' and SW2 shall give the total length of the data. Other status words may be present in case of an error. The various cases are: Case 1: No input / No output
CLA INS P1 P2 P3 lgth (='00') SW1 '90' SW2 '00'
NOTE:
P1
P2
P3 lgth2
SW1 '90'
SW2 '00'
P1
P2
P3 lgth2
SW1 '90'
SW2 '00'
For cases 3 and 5, when SW1/SW2 indicates there is response data (i.e. SW1/SW2 = '9FXX'), then, if the ME requires to get this response data, it shall send a GET RESPONSE command as described in the relevant case above. For case 5, in case of an ENVELOPE for SIM data download, SW1/SW2 may also indicate that there is response data with the value '9EXX', and the ME shall then send a GET RESPONSE command to get this response data. If the GSM application is one of several applications in a multi-application card, other commands with CLA not equal to 'A0' may be sent by the terminal. This shall not influence the state of the GSM application.
3GPP
Release 1999
38
The following diagrams show how the five cases of transmission protocol identified in the above diagrams can all be used to send pro-active SIM commands. For further information on the diagrams below see TS 11.14 [27]. Case 1: No input / "OK" response with no output, plus additional command from SIM
CLA INS P1 P2 P3 lgth (='00') SW1 '91' SW2 lgth1
INS
P1
P2
P3 lgth1
SW1 '90'
SW2 '00'
NOTE:
Case 2: No input / "OK" response with data of known length, plus additional command from SIM
CLA INS P1 P2 P3 lgth DATA with length lgth SW1 '91' SW2 lgth1
INS
P1
P2
P3 lgth1
SW1 '90'
SW2 '00'
NOTE:
lgth='00' causes a data transfer of 256 bytes. The same applies to lgth 1.
Case 3: No Input / "OK" response with data of unknown length, plus additional command from SIM
CLA INS P1 P2 P3 lgth (='00') SW1 '9F' SW2 lgth1
P1
P2
P3 lgth2
SW1 '91'
SW2 lgth3
INS
P1
P2
P3 lgth3
SW1 '90'
SW2 '00'
Case 4: Input / "OK" response with no output data, plus additional command from SIM
CLA INS P1 P2 P3 lgth DATA with length lgth SW1 '91' SW2 lgth1
INS
P1
P2
P3 lgth1
SW1 '90'
SW2 '00'
3GPP
Release 1999
39
Case 5: Input / "OK" response with data of known or unknown length, plus additional command from SIM
CLA
INS
P1
P2
P3 lgth
SW1 '9F'
SW2 lgth1
P1
P2
P3 lgth2
SW1 '91'
SW2 lgth3
INS
P1
P2
P3 lgth3
SW1 '90'
SW2 '00'
3GPP
Release 1999
40
NOTE:
If the UNBLOCK CHV command applies to CHV1 then P2 is coded '00'; if it applies to CHV2 then P2 is coded '02'.
Definitions and codings used in the response parameters/data of the commands are given in subclause 9.3.
9.2.1 SELECT
COMMAND SELECT CLASS 'A0' INS 'A4' P1 '00' P2 '00' P3 '02'
Command parameters/data:
Byte(s) 1-2 Description File ID Length 2
3GPP
Release 1999
41
Bytes 1 - 22 are mandatory and shall be returned by the SIM. Bytes 23 and following are optional and may not be returned by the SIM. NOTE 1: Byte 35 and following are RFU. NOTE 2: The STATUS information of the MF, DFGSM and DFTELECOM provide some identical application specific data, e.g. CHV status. On a multi-application card the MF should not contain any application specific data. Such data is obtained by terminals from the specific application directories. ME manufacturers should take this into account and therefore not use application specific data which may exist in the MF of a mono-application SIM. Similarly, the VERIFY CHV command should not be executed in the MF but in the relevant application directory (e.g. DFGSM). Detail 1: File characteristics
b8 b7 b6 b5 b4 b3 b2 b1 Clock stop (see below) For running the authentication algorithm, or the ENVELOPE command for SIM Data Download, a frequency is required of at least 13/8 MHz if b2=0 and 13/4 MHz if b2=1 Clock stop (see below) for coding (see TS 11.12 [28]) RFU b8=0: CHV1 enabled; b8=1: CHV1 disabled
If bit b1 (column 1) is coded 1, stopping the clock is allowed at high or low level. In this case columns 2 (bit b3) and 3 (bit b4) give information about the preferred level (high or low, respectively) at which the clock may be stopped. If bit b1 is coded 0, the clock may be stopped only if the mandatory condition in column 2 (b3=1, i.e. stop at high level) or column 3 (b4=1, i.e. stop at low level) is fulfilled. If all 3 bits are coded 0, then the clock shall not be stopped.
3GPP
Release 1999
42
2 1 1 3 1 1 1 1 -
Bytes 1-14 are mandatory and shall be returned by the SIM. Byte 15 is mandatory in case of linear fixed or cyclic EFs and shall be returned by the SIM. Byte 15 is optional in case of transparent EFs and may not be returned by the SIM. Byte 16 and following (when defined) are optional and may not be returned by the SIM. Detail 3: Byte 8 For transparent and linear fixed EFs this byte is RFU. For a cyclic EF all bits except bit 7 are RFU; b7=1 indicates that the INCREASE command is allowed on the selected cyclic file. Detail 4: Byte 15 For cyclic and linear fixed EFs this byte denotes the length of a record. For a transparent EF, this byte shall be coded '00', if this byte is sent by the SIM.
9.2.2 STATUS
COMMAND STATUS CLASS 'A0' INS 'F2' P1 '00' P2 '00' P3 lgth
The response parameters/data are identical to the response parameters/data of the SELECT command in case of an MF or DF.
3GPP
Release 1999
43
Response parameters/data:
Byte(s) 1 - lgth Description Data to be read Length lgth
Command parameters/data:
Byte(s) 1 - lgth Description Data Length lgth
Parameter P2 specifies the mode: '02' = next record; '03' = previous record; '04' = absolute mode/current mode, the record number is given in P1 with P1='00' denoting the current record.
For the modes "next" and "previous" P1 has no significance and shall be set to '00' by the ME. To ensure phase compatibility between Phase 2 SIMs and Phase 1 MEs, the SIM shall not interpret the value given by the ME. Response parameters/data:
Byte(s) 1 - lgth Description The data of the record Length lgth
Parameter P2 specifies the mode: '02' = next record; '03' = previous record; '04' = absolute mode/current mode; the record number is given in P1 with P1='00' denoting the current record.
For the modes "next" and "previous" P1 has no significance and shall be set to '00' by the ME. To ensure phase compatibility between Phase 2 SIMs and Phase 1 MEs, the SIM shall not interpret the value given by the ME. Command parameters/data:
Byte(s) 1 - lgth Description Data Length lgth
3GPP
Release 1999
44
9.2.7 SEEK
COMMAND SEEK CLASS 'A0' INS 'A2' P1 '00' P2 Type/Mode P3 lgth
Parameter P2 specifies type and mode: 'x0' = from the beginning forward; 'x1' = from the end backward; 'x2' = from the next location forward; 'x3' = from the previous location backward; with x='0' specifies type 1 and x='1' specifies type 2 of the SEEK command. Command parameters/data:
Byte(s) 1 - lgth Description Pattern Length lgth
There are no response parameters/data for a type 1 SEEK. A type 2 SEEK returns the following response parameters/data:
Byte(s) 1 Description Record number Length 1
9.2.8 INCREASE
COMMAND INCREASE CLASS 'A0' INS '32' P1 '00' P2 '00' P3 '03'
Command parameters/data:
Byte(s) 1-3 Description Value to be added Length 3
Response parameters/data:
Byte(s) 1-X X+1 - X+3 Description Value of the increased record Value which has been added Length X 3
NOTE:
3GPP
Release 1999
45
Command parameters/data:
Byte(s) 1-8 Description CHV value Length 8
Command parameters/data:
Byte(s) 1-8 9 - 16 Description Old CHV value New CHV value Length 8 8
Command parameters/data:
Byte(s) 1-8 Description CHV1 value Length 8
Command parameters/data:
Byte(s) 1-8 Description CHV1 value Length 8
Parameter P2 specifies the CHV: 00 = CHV1; 02 = CHV2. The coding '00' for CHV1 differs from the coding of CHV1 used for other commands.
NOTE:
3GPP
Release 1999
46
Command parameters/data:
Byte(s) 1-8 9 - 16 Description UNBLOCK CHV value New CHV value Length 8 8
9.2.14 INVALIDATE
COMMAND INVALIDATE CLASS 'A0' INS '04' P1 '00' P2 '00' P3 '00'
9.2.15 REHABILITATE
COMMAND REHABILITATE CLASS 'A0' INS '44' P1 '00' P2 '00' P3 '00'
Command parameters/data:
Byte(s) 1 - 16 Description RAND Length 16
Response parameters/data:
Byte(s) 1-4 5 - 12 Description SRES Cipher Key Kc Length 4 8
The most significant bit of SRES is coded on bit 8 of byte 1. The most significant bit of Kc is coded on bit 8 of byte 5.
9.2.17 SLEEP
COMMAND SLEEP CLASS 'A0' INS 'FA' P1 '00' P2 '00' P3 '00'
NOTE:
The response data depends on the preceding command. Response data is available after the commands RUN GSM ALGORITHM, SEEK (type 2), SELECT, INCREASE, and ENVELOPE. If the command GET RESPONSE is executed, it is required that it is executed immediately after the command it is related to (no other command shall come between the command/response pair and the command GET RESPONSE). If the sequence is not respected, the SIM shall send the status information "technical problem with no diagnostic given" as a reaction to the GET RESPONSE.
3GPP
Release 1999
47
Since the MF is implicitly selected after activation of the SIM, GET RESPONSE is also allowed as the first command after activation. The response data itself is defined in the subclause for the corresponding command.
Command parameters/data: length lgth. The structure of the command parameters is defined in TS 11.14 [27]. Response parameters/data: none available
9.2.20 ENVELOPE
COMMAND ENVELOPE CLASS 'A0' INS 'C2' P1 '00' P2 '00' P3 lgth
Command parameters/data: length lgth. The structure of the command parameters is defined in TS 11.14 [27]. Response parameters/data: The structure of the data is defined in TS 11.14 [27].
9.2.21 FETCH
COMMAND FETCH CLASS 'A0' INS '12' P1 '00' P2 '00' P3 lgth
Command parameters/data: none. Response parameters/data: length lgth. The structure of the data is defined in TS 11.14 [27].
Command parameters/data: length lgth. The structure of the command parameters is defined in TS 11.14 [27]. Response parameters/data: none available.
3GPP
Release 1999
48
Bit b3 may be set to 1 in special circumstances when it is required that the EF can be read and updated even if the EF is invalidated, e.g. reading and updating the EF ADN when the FDN feature is enabled, or reading and updating the EFBDN when the BDN feature is disabled. Structure of file '00' transparent; '01' linear fixed; '03' cyclic.
Type of File '00' RFU; '01' MF; '02' DF; '04' EF.
Coding of CHVs and UNBLOCK CHVs A CHV is coded on 8 bytes. Only (decimal) digits (0-9) shall be used, coded in CCITT T.50 [20] with bit 8 set to zero. The minimum number of digits is 4. If the number of digits presented by the user is less than 8 then the ME shall pad the presented CHV with 'FF' before sending it to the SIM. The coding of the UNBLOCK CHVs is identical to the coding of the CHVs. However, the number of (decimal) digits is always 8. Coding of Access Conditions The access conditions for the commands are coded on bytes 9, 10 and 11 of the response data of the SELECT command. Each condition is coded on 4 bits as shown in table 10.
3GPP
Release 1999
49
Entries marked "*" in the table above, are also available for use as administrative codes in addition to the ADM access levels '4' to 'E' (refer to subclause 7.3) if required by the appropriate administrative authority. If any of these access conditions are used, the code returned in the Access Condition bytes in the response data shall be the code applicable to that particular level. Byte 9:
b8 b7 b6 b5 b4 b3 b2 b1 UPDATE READ; SEEK
Byte 10:
b8 b7 b6 b5 b4 b3 b2 b1 RFU INCREASE
Byte 11:
b8 b7 b6 b5 b4 b3 b2 b1 INVALIDATE REHABILITATE
3GPP
Release 1999
50
'98'
'50'
NOTE:
A Phase 1 SIM may send this error code after the third consecutive unsuccessful CHV verification attempt or the tenth consecutive unsuccessful unblocking attempt.
NOTE:
'XX' gives the correct length or states that no additional information is given ('XX' = '00').
3GPP
Release 1999 9 0 Commands Select Status Update Binary Update Record Read Binary Read Record Seek Increase Verify CHV Change CHV Disable CHV Enable CHV Unblock CHV Invalidate Rehabilitate Run GSM Algorithm Sleep Get Response Terminal Profile Envelope Fetch Terminal Response * * * * * * * * * * 0 0 * * * * * * * * * * * * * 9 1
51 9 9 9 E F 3 9 2 9 2 9 4 0 0 9 4 0 2 9 4 0 4 * 9 4 0 8
X X X 0 X X X 0 * * * * * * * * * * * * * * * *
0 4 X 0 * * * * * * * * * * * * * * * * * *
* * * * * * * *
* * * * * *
* * *
* * * * * * * * * * *
* * * * * * * * * * * * * * * * * *
* * * * * * * * * * * * *
* * *
The responses '91 XX', and '93 00' and '9E XX' can only be given by a SIM supporting SIM Application Toolkit, to an ME also supporting SIM Application Toolkit. For the SEEK command the response '91 XX' can be given directly after a Type 1 SEEK command. Following the Type 2 SEEK command the SIM can give the response '91 XX' only after the GET RESPONSE command.
10
This clause specifies the EFs for the GSM session defining access conditions, data items and coding. A data item is a part of an EF which represents a complete logical entity, e.g. the alpha tag in a EF ADN record. EFs or data items having an unassigned value, or, which during the GSM session, are cleared by the ME, shall have their bytes set to 'FF'. After the administrative phase all data items shall have a defined value or have their bytes set to 'FF'. If a data item is 'deleted' during a GSM session by the allocation of a value specified in another GSM TS, then this value shall be used, and the data item is not unassigned; e.g. for a deleted LAI in EF LOCI the last byte takes the value 'FE' (TS 04.08 [15] refers). EFs are mandatory (M) or optional (O). The file size of an optional EF may be zero. All implemented EFs with a file size greater than zero shall contain all mandatory data items. Optional data items may either be filled with 'F', or, if located at the end of an EF, need not exist. When the coding is according to CCITT Recommendation T.50 [20], bit 8 of every byte shall be set to 0. For an overview containing all files see figure 8.
3GPP
Release 1999
52
Identification number Contents: according to CCITT Recommendation E.118 [18]. However, network operators who are already issuing Phase 1 SIM cards with an identification number length of 20 digits may retain this length. Purpose: card identification number. Coding: BCD, left justified and padded with 'F'; after padding the digits within a byte are swapped (see below). However, network operators who are already issuing Phase 1 SIM cards where the digits within a byte are not swapped may retain this configuration. Byte 1:
b8 b7 b6 b5 b4 b3 b2 b1 LSB : : MSB LSB : : MSB of Digit 1 of Digit 1 of Digit 2 of Digit 2
Byte 2:
b8 b7 b6 b5 b4 b3 b2 b1 LSB : : MSB LSB : : MSB of Digit 3 of Digit 3 of Digit 4 of Digit 4
etc.
3GPP
Release 1999
53
When the CB Message Identifier capability is both allocated and activated, the ME selects only those CB messages the language of which corresponds to an entry in this EF or in EF LP, whichever of these EFs is used (see subclause 11.2.1). The CB message language is defined by the Data Coding Scheme (DCS: see TS 23.038 [12]) received with the CB message. The ME shall be responsible for translating the language coding indicated in the Data Coding Scheme for the Cell Broadcast Service (as defined in TS 23.038 [12]) to the language coding as defined in ISO 639 [30] if it is necessary to check the language coding in EF ELP.
Identifier: '2F 05' File size: 2n bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 to 2 3 to 4 2n-1 to 2n Structure: transparent Optional Update activity: low ALW CHV1 ADM ADM M/O O O O Length 2 bytes 2 bytes 2 bytes
Description 1st language code (highest prior.) 2nd language code nth language code (lowest prior.)
Coding: each language code is a pair of alpha-numeric characters, as defined in ISO 639 [30]. Each alpha-numeric character shall be coded on one byte using the SMS default 7-bit coded alphabet as defined in TS 23.038 [12] with bit 8 set to 0. Unused language entries shall be set to 'FF FF'.
Only the contents of DFSoLSA and DFMExE are specified in the present document. For details of the EFs contained in the DFCTS, see TS 11.19 [34].
3GPP
Release 1999
54
Scheme for the Cell Broadcast Service (as defined in TS 23.038 [12]) to the language coding as defined in ISO 639 [30] if it is necessary to check the language coding in EF ELP.
Identifier: '6F05' File size: 1-n bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 2 n Structure: transparent Mandatory Update activity: low ALW CHV1 ADM ADM M/O M O O Length 1 byte 1 byte 1 byte
Description 1st language code (highest prior.) 2nd language code nth language code (lowest prior.)
Coding: according to language codings contained in the Data Coding Scheme (see TS 23.038 [12]). Using the command GET RESPONSE, the ME can determine the size of the EF.
length of IMSI Contents: The length indicator refers to the number of significant bytes, not including this length byte, required for the IMSI. Coding: according to TS 04.08 [15].
IMSI Contents: International Mobile Subscriber Identity. Coding: This information element is of variable length. If a network operator chooses an IMSI of less than 15 digits, unused nibbles shall be set to 'F'.
3GPP
Release 1999
55
Byte 2:
b8 b7 b6 b5 b4 b3 b2 b1 1 0 0 Parity LSB of Digit 1 : : MSB of Digit 1
etc.
Ciphering key Kc Coding: The least significant bit of Kc is the least significant bit of the eighth byte. The most significant bit of Kc is the most significant bit of the first byte.
NOTE:
TS 04.08 [15] defines the value of n=111 as "key not available". Therefore the value '07' and not 'FF' should be present following the administrative phase.
3GPP
Release 1999
56
Description 1st PLMN (highest priority) 8th PLMN 9th PLMN nth PLMN (lowest priority)
PLMN Contents: Mobile Country Code (MCC) followed by the Mobile Network Code (MNC). Coding: according to TS 04.08 [15]. If storage for fewer than the maximum possible number n is required, the excess bytes shall be set to 'FF'. For instance, using 246 for the MCC and 81 for the MNC and if this is the first and only PLMN, the contents reads as follows: Bytes 1-3: '42' 'F6' '18' Bytes 4-6: 'FF' 'FF' 'FF' etc.
3GPP
Release 1999
57
Coding: The time interval is coded in integer multiples of n minutes. The range is from n minutes to a maximum value. The value '00' indicates that no attempts shall be made to search for any higher priority PLMN. The encoding is: '00': No higher priority PLMN search attempts '01': n minutes '02': 2n minutes : :
All other values shall be interpreted by the ME as a default period. For specification of the integer timer interval n, the maximum value and the default period refer to TS 22.011 [5].
Maximum value Contents: maximum value of the Accumulated Call Meter (ACM) Coding: First byte:
b8 b7 b6 b5 b4 b3 b2 b1
223
222
221
220
219
218
217
216
Second byte:
b8 b7 b6 b5 b4 b3 b2 b1
215
214
213
212
211
210
29
28
3GPP
Release 1999
58
Third byte:
b8 b7 b6 b5 b4 b3 b2 b1
27
26
25
24
23
22
21
20
For instance, '00' '00' '30' represents 2 5+24. All ACM data is stored in the SIM and transmitted over the SIM/ME interface as binary. ACMmax is not valid, as defined in TS 22.024 [7], if it is coded '000000'.
Access Conditions: READ CHV1 UPDATE ADM INVALIDATE ADM REHABILITATE ADM Bytes Description 1 Services n1 to n4 2 Services n5 to n8 3 Services n9 to n12 4 Services n13 to n16 5 Services n17 to n20 6 Services n21 to n24 7 Services n25 to n28 8 Services n29 to n32 etc. X Services (4X-3) to (4X)
M/O M M O O O O O O O
Length 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte
3GPP
Release 1999
59
-Services Contents:
Service n1 : Service n2 : Service n3 : Service n4 : Service n5 : Service n6 : Service n7 : Service n8 : Service n9 : Service n10: Service n11: Service n12: Service n13: Service n14: Service n15: Service n16: Service n17: Service n18: Service n19: Service n20: Service n21: Service n22: Service n23: Service n24: Service n25: Service n26: Service n27: Service n28: Service n29: Service n30: Service n31: Service n32: Service n33: Service n34: Service n35: Service n36: Service n37: Service n38: Service n39: Service n40: Service n41: Service n42: Service n43: Service n 44: Service n 45 Service n 46: Service n 47: Service n48: Service n49: Service n50
CHV1 disable function Abbreviated Dialling Numbers (ADN) Fixed Dialling Numbers (FDN) Short Message Storage (SMS) Advice of Charge (AoC) Capability Configuration Parameters (CCP) PLMN selector RFU MSISDN Extension1 Extension2 SMS Parameters Last Number Dialled (LND) Cell Broadcast Message Identifier Group Identifier Level 1 Group Identifier Level 2 Service Provider Name Service Dialling Numbers (SDN) Extension3 RFU VGCS Group Identifier List (EFVGCS and EFVGCSS) VBS Group Identifier List (EFVBS and EFVBSS) enhanced Multi-Level Precedence and Pre-emption Service Automatic Answer for eMLPP Data download via SMS-CB Data download via SMS-PP Menu selection Call control Proactive SIM Cell Broadcast Message Identifier Ranges Barred Dialling Numbers (BDN) Extension4 De-personalization Control Keys Co-operative Network List Short Message Status Reports Network's indication of alerting in the MS Mobile Originated Short Message control by SIM GPRS Image (IMG) SoLSA (Support of Local Service Area) USSD string data object supported in Call Control RUN AT COMMAND command User controlled PLMN Selector with Access Technology Operator controlled PLMN Selector with Access Technology HPLMN Selector with Access Technology CPBCCH Information Investigation Scan Extended Capability Configuration Parameters MExE Reserved and shall be ignored
For a phase 2 SIM, the EF shall contain at least two bytes which correspond to the Phase 1 services. Further bytes may be included, but if the EF includes an optional byte, then it is mandatory for the EF to also contain all bytes before that byte. Other services are possible in the future and will be coded on further bytes in the EF. The coding falls under the responsibility of ETSI. NOTE 1: Service N8 was used in Phase 1 for Called Party Subaddress. To prevent any risk of incompatibility Service N8 should not be reallocated. NOTE 2: As the BDN service relies on the Call Control feature, service n31 (BDN) should only be allocated and activated if service n28 (Call control) is allocated and activated. Coding: 2 bits are used to code each service: first bit = 1: service allocated first bit = 0: service not allocated where the first bit is b1, b3, b5 or b7; second bit = 1: service activated
3GPP
Release 1999
60
second bit = 0: service not activated where the second bit is b2, b4, b6 or b8. Service allocated means that the SIM has the capability to support the service. Service activated means that the service is available for the card holder (only valid if the service is allocated). The following codings are possible: first bit = 0: service not allocated, second bit has no meaning; first bit = 1 and second bit = 0: service allocated but not activated; first bit = 1 and second bit = 1: service allocated and activated.
The bits for services not yet defined shall be set to RFU. For coding of RFU see subclause 9.3. First byte:
b8 b7 b6 b5 b4 b3 b2 b1 Service Service Service Service n1 n2 n3 n4
Second byte:
b8 b7 b6 b5 b4 b3 b2 b1 Service Service Service Service n5 n6 n7 n8
etc. The following example of coding for the first byte means that service n1 "CHV1-Disabling" is allocated but not activated:
b8 X b7 X b6 X b5 X b4 X b3 X b2 0 b1 1
If the SIM supports the FDN feature (FDN allocated and activated) a special mechanism shall exist in the SIM which invalidates both EFIMSI and EFLOCI once during each GSM session. This mechanism shall be invoked by the SIM automatically if FDN is enabled. This invalidation shall occur at least before the next command following selection of either EF. FDN is enabled when the ADN is invalidated or not activated. If the SIM supports the BDN feature (BDN allocated and activated) a special mechanism shall exist in the SIM which invalidates both EFIMSI and EFLOCI once during each GSM session and which forbids the REHABILITATE command to rehabilitate both EFIMSI and EFLOCI until the PROFILE DOWNLOAD procedure is performed indicating that the ME supports the "Call control by SIM" facility. This mechanism shall be invoked by the SIM automatically if BDN is enabled. The invalidation of EF IMSI and EFLOCI shall occur at least before the next command following selection of either EF. BDN is enabled when the EF BDN is not invalidated.
3GPP
Release 1999
61
Identifier: '6F39' Record length: 3 bytes Access Conditions: READ UPDATE INCREASE INVALIDATE REHABILITATE Bytes 1 to 3
Structure: cyclic Optional Update activity: high CHV1 CHV1/CHV2 (fixed during administrative management) CHV1 ADM ADM M/O M Length 3 bytes
Accumulated count of units Contents: value of the ACM Coding: see the coding of EFACMmax
NOTE:
The structure of EFGID1 and EFGID2 are identical. They are provided to allow the network operator to enforce different levels of security dependant on application.
3GPP
Release 1999
62
Identifier: '6F46' File Size: 17 bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 2 to 17
Structure: transparent Optional Update activity: low ALWAYS ADM ADM ADM M/O M M Length 1 byte 16 bytes
Display Condition Contents: display condition for the service provider name in respect to the registered PLMN (see TS 02.07 [3]). Coding: see below Byte 1:
b8 b7 b6 b5 b4 b3 b2 b1 b1=0: display of registered PLMN not required b1=1: display of registered PLMN required RFU (see subclause 9.3)
Service Provider Name Contents: service provider string to be displayed Coding: the string shall use either the SMS default 7-bit coded alphabet as defined in TS 23.038 [12] with bit 8 set to 0. The string shall be left justified. Unused bytes shall be set to 'FF'; or one of the UCS2 code options defined in annex B.
3GPP
Release 1999
63
bytes 1, 2 and 3 are the respective first, second and third character of the alpha identifier. This alpha-tagging shall use the SMS default 7-bit coded alphabet as defined in TS 23.038 [12] with bit 8 set to 0. Price per unit Contents: price per unit expressed in the currency coded by bytes 1-3. Coding: Byte 4 and bits b1 to b4 of byte 5 represent the Elementary Price per Unit (EPPU) in the currency coded by bytes 1-3. Bits b5 to b8 of byte 5 are the decimal logarithm of the multiplicative factor represented by the absolute value of its decimal logarithm (EX) and the sign of EX, which is coded 0 for a positive sign and 1 for a negative sign. Byte 4:
b8 b7 b6 b5 b4 b3 b2 b1
211
210
29
28
27
26
25
24
of EPPU
Byte 5:
b8 b7 b6 b5 b4 23 b3 22 b2 21 b1 20 of EPPU Sign of EX 20 of Abs(EX) 21 of Abs(EX) 22 of Abs(EX)
The computation of the price per unit value is made by the ME in compliance with TS 22.024 [7] by the following formula: price per unit = EPPU * 10EX. The price has to be understood as expressed in the coded currency.
3GPP
Release 1999
64
Cell Broadcast Message Identifier Coding: as in TS 23.041, "Message Format on BTS-MS Interface - Message Identifier". Values listed show the types of message which shall be accepted by the MS. Unused entries shall be set to 'FF FF'.
BCCH information Coding: The information is coded as octets 2-17 of the "neighbour cells description information element" in TS 04.08 [15].
Access control classes Coding: Each ACC is coded on one bit. An ACC is "allocated" if the corresponding bit is set to 1 and "not allocated" if this bit is set to 0. Bit b3 of byte 1 is set to 0.
3GPP
Release 1999
65
Byte 1:
b8 15 b7 14 b6 13 b5 12 b4 11 b3 10 b2 09 b1 08 Number of the ACC (except for bit b3)
Byte 2:
b8 07 b7 06 b6 05 b5 04 b4 03 b3 02 b2 01 b1 00 Number of the ACC
PLMN Contents: Mobile Country Code (MCC) followed by the Mobile Network Code (MNC). Coding: according to TS 04.08 [15]. For instance, using 246 for the MCC and 81 for the MNC and if this is stored in PLMN 3 the contents is as follows: Bytes 7-9: '42' 'F6' '18' If storage for fewer than 4 PLMNs is required, the unused bytes shall be set to 'FF'.
3GPP
Release 1999
66
TMSI Contents: Temporary Mobile Subscriber Identity Coding: according to TS 04.08 [15].
TMSI TIME Contents: Current value of Periodic Location Updating Timer (T3212). This byte is used by Phase 1 MEs, but it shall not be used by Phase 2 MEs.
Location update status Contents: status of location update according to TS 04.08 [15].
3GPP
Release 1999
67
Coding: Byte 11: Bits: b3 b2 b1 0 0 0 : updated 0 0 1 : not updated 0 1 0 : PLMN not allowed 0 1 1 : Location Area not allowed 1 1 1 : reserved Bits b4 to b8 are RFU (see subclause 9.3).
Bytes Description M/O Length 1 MS operation mode M 1 byte 2 to 3 Additional information M 2 bytes 4 length of MNC in the IMSI O 1 byte 5 to 3+X RFU O (X-1) bytes NOTE: If X=0 no optional field is present; If X=1 byte 4 is present but no RFU field is present; When the RFU field is present (X 2) then byte 4 shall be present.
MS operation mode Contents: mode of operation for the MS Coding: Initial value normal operation type approval operations normal operation + specific facilities type approval operations + specific facilities maintenance (off line) cell test operation '00' '80' '01' '81' '02' '04'
3GPP
Release 1999
68
Byte 3:
b8 b7 b6 b5 b4 b3 b2 b1 b1=0: OFM to be disabled by the ME b1=1: OFM to be activated by the ME RFU
The OFM bit is used to control the Ciphering Indicator as specified in TS 02.07 [3] ME manufacturer specific information (if b2=1 in byte 1).
Length of MNC in the IMSI : Contents: The length indicator refers to the number of digits, used for extracting the MNC from the IMSI Coding: Byte 4:
b8 b7 b6 b5 b4 b3 b2 b1 This value codes the number of digits of the MNC in the IMSI. Only the values '0010' and '0011' are currently specified, all other values are reserved for future use. RFU (see subclause 9.3).
SIM Phase Coding: '00': phase 1 '02': phase 2 '03': phase 2 and PROFILE DOWNLOAD required (see TS 11.14 [27]). All other codings are reserved for specification by ETSI TC SMG. Codings '04' to '0F' indicate that the SIM supports, as a minimum, the mandatory requirements defined in this specification.
This phase identification does not preclude a SIM to support some features of a phase later than the one indicated in EFPhase. For example : if EFPhase is coded '00', it may be assumed by the ME that some Phase 2 or Phase 2+ features are
3GPP
Release 1999
69
supported by this SIM; if EF Phase is coded '02' or '03', it may be assumed by the ME that some Phase 2+ features are supported by this SIM. However, the services n3 (FDN) and/or n5 (AoC) shall only be allocated and activated in SIMs of phase 2 or later with EFPhase being coded '02' or greater. Similarly, service n31 (BDN) shall only be allocated and activated in SIMs with EFPhase being coded '03' or greater. If EFPhase is coded '03' or greater, an ME supporting SIM Application Toolkit shall perform the PROFILE DOWNLOAD procedure, as defined in TS 11.14 [27].
Group ID Contents: VGCS Group ID, according to TS 23.003 [10] Coding: The VGCS Group ID is of a variable length with a maximum length of 8 digits. Each VGCS Group ID is coded on four bytes, with each digit within the code being coded on four bits corresponding to BCD code. If a VGCS Group ID of less than 8 digits is chosen, then the unused nibbles shall be set to 'F'. VGCS Group ID Digit 1 is the most significant digit of the Group ID. Byte 1:
b8 b7 b6 b5 b4 b3 b2 b1 LSB : : MSB LSB : : MSB of Digit 1 of Group ID 1 of Digit 1 of Group ID 1 of Digit 2 of Group ID 1 of Digit 2 of Group ID 1
Byte 2:
b8 b7 b6 b5 b4 b3 b2 b1 LSB : : MSB LSB : : MSB of Digit 3 of Group ID 1 of Digit 3 of Group ID 1 of Digit 4 of Group ID 1 of Digit 4 of Group ID 1
3GPP
Release 1999
70
Byte 3:
b8 b7 b6 b5 b4 b3 b2 b1 LSB : : MSB LSB : : MSB of Digit 5 of Group ID 1 of Digit 5 of Group ID 1 of Digit 6 of Group ID 1 of Digit 6 of Group ID 1
Byte 4:
b8 b7 b6 b5 b4 b3 b2 b1 LSB : : MSB LSB : : MSB of Digit 7 of Group ID 1 of Digit 7 of Group ID 1 of Digit 8 of Group ID 1 of Digit 8 of Group ID 1
If storage for fewer than the maximum possible number n of VGCS Group IDs, is required, the excess bytes shall be set to 'FF'.
Activation/Deactivation Flags Contents: Activation/Deactivation Flags of the appropriate Group IDs Coding:
3GPP
Release 1999
71
etc Byte 7:
b8
b7
b6
b5
b4
b3
b2
Group ID Contents: VBS Group ID, according to TS 23.003 [10] Coding: The VBS Group ID is of a variable length with a maximum length of 8 digits. Each VBS Group ID is coded on four bytes, with each digit within the code being coded on four bits corresponding to BCD code. If a VBS Group ID of less than 8 digits is chosen, then the unused nibbles shall be set to 'F'. VBS Group ID Digit 1 is the most significant digit of the Group ID.
3GPP
Release 1999
72
Byte 1:
b8 b7 b6 b5 b4 b3 b2 b1 LSB : : MSB LSB : : MSB of Digit 1 of Group ID 1 of Digit 1 of Group ID 1 of Digit 2 of Group ID 1 of Digit 2 of Group ID 1
Byte 2:
b8 b7 b6 b5 b4 b3 b2 b1 LSB : : MSB LSB : : MSB of Digit 3 of Group ID 1 of Digit 3 of Group ID 1 of Digit 4 of Group ID 1 of Digit 4 of Group ID 1
Byte 3:
b8 b7 b6 b5 b4 b3 b2 b1 LSB : : MSB LSB : : MSB of Digit 5 of Group ID 1 of Digit 5 of Group ID 1 of Digit 6 of Group ID 1 of Digit 6 of Group ID 1
Byte 4:
b8 b7 b6 b5 b4 b3 b2 b1 LSB : : MSB LSB : : MSB of Digit 7 of Group ID 1 of Digit 7 of Group ID 1 of Digit 8 of Group ID 1 of Digit 8 of Group ID 1
If storage for fewer than the maximum possible number n of VBS Group IDs, is required, the excess bytes shall be set to 'FF'.
3GPP
Release 1999
73
Activation/Deactivation Flags Contents: Activation/Deactivation Flags of the appropriate Group IDs Coding: see coding of EFVGCS
Priority levels Contents: The eMLPP priority levels subscribed to. Coding: Each eMLPP priority level is coded on one bit. Priority levels subscribed to have their corresponding bits set to 1. Priority levels not subscribed to have their corresponding bits set to 0. Bit b8 is reserved and set to 0. Byte 1:
b8 b7 b6 b5 b4 b3 b2 b1 priority priority priority priority priority priority priority 0 level level level level level level level A B 0 1 2 3 4
3GPP
Release 1999
74
NOTE:
Priority levels A and B can not be subscribed to (see TS 22.067 [42] for details). If priority levels 0, 1 and 2 are subscribed to, EF eMLPP shall be coded '1C'.
EXAMPLE 1: -
Fast call set-up conditions Contents: For each eMLPP priority level, the capability to use a fast call set-up procedure. Coding: Each eMLPP priority level is coded on one bit. Priority levels for which fast call set-up is allowed have their corresponding bits set to 1. Priority levels for which fast call set-up is not allowed have their corresponding bits set to 0. Bit b8 is reserved and set to 0. Byte 2: fast call set-up condition for:
b8 b7 b6 b5 b4 b3 b2 b1 fast fast fast fast fast fast fast 0 call call call call call call call set-up set-up set-up set-up set-up set-up set-up condition condition condition condition condition condition condition for for for for for for for priority priority priority priority priority priority priority level level level level level level level A B 0 1 2 3 4
EXAMPLE 2:
If fast call set-up is allowed for priority levels 0 and 1, then byte 2 of EF eMLPP is coded '0C'.
Automatic answer priority levels Contents: For each eMLPP priority level, the capability for the mobile station to answer automatically to incoming calls (with the corresponding eMLPP priority level). Coding: Each eMLPP priority level is coded on one bit. Priority levels allowing an automatic answer from the mobile station have their corresponding bits set to 1. Priority levels not allowing an automatic answer from the mobile station have their corresponding bits set to 0. Bit b8 is reserved and set to 0.
3GPP
Release 1999
75
Byte 1:
b8 b7 b6 b5 b4 b3 b2 b1 Automatic Automatic Automatic Automatic Automatic Automatic Automatic 0 answer answer answer answer answer answer answer priority priority priority priority priority priority priority for for for for for for for priority priority priority priority priority priority priority level level level level level level level A B 0 1 2 3 4
EXAMPLE:
If automatic answer is allowed for incoming calls with priority levels A, 0 and 1, then EF AAeMLPP is coded '0D'.
Cell Broadcast Message Identifier Coding: as in TS 23.041 [14]. Values listed show the identifiers of messages which shall be accepted by the MS to be passed to the SIM. Unused entries shall be set to 'FF FF'.
3GPP
Release 1999
76
Description Emergency Call Code 1 Emergency Call Code 2 Emergency Call Code n
Emergency Call Code Contents: Emergency Call Code Coding: The emergency call code is of a variable length with a maximum length of 6 digits. Each emergency call code is coded on three bytes, with each digit within the code being coded on four bits as shown below. If a code of less that 6 digits is chosen, then the unused nibbles shall be set to 'F'. Byte 1:
b8 b7 b6 b5 b4 b3 b2 b1 LSB : : MSB LSB : : MSB of Digit 1 of Digit 1 of Digit 2 of Digit 2
Byte 2:
b8 b7 b6 b5 b4 b3 b2 b1 LSB : : MSB LSB : : MSB of Digit 3 of Digit 3 of Digit 4 of Digit 4
3GPP
Release 1999
77
Byte 3:
b8 b7 b6 b5 b4 b3 b2 b1 LSB : : MSB LSB : : MSB of Digit 5 of Digit 5 of Digit 6 of Digit 6
Description CB Message Identifier Range 1 CB Message Identifier Range 2 CB Message Identifier Range n
Cell Broadcast Message Identifier Ranges Contents: CB Message Identifier ranges: Coding: bytes one and two of each range identifier equal the lower value of a cell broadcast range, bytes three and four equal the upper value of a cell broadcast range, both values are coded as in TS 23.041 [14] "Message Format on BTS-MS Interface - Message Identifier". Values listed show the ranges of messages which shall be accepted by the MS. Unused entries shall be set to 'FF FF FF FF'.
3GPP
Release 1999
78
Description 8 digits of network de-personalization control key 8 digits of network subset de-personalization control key 8 digits of service provider de-personalization control key 8 digits of corporate de-personalization control key
Co-operative Network List Contents: PLMN network subset, service provider ID and corporate ID of co-operative networks. Coding: For each 6 byte list element
3GPP
Release 1999
79
Byte 5:
b8 b7 b6 b5 b4 b3 b2 b1 LS : : MS LS : : MS bit of service provider digit 1 bit of service provider digit 1 bit of service provider digit 2 bit of service provider digit 2
Byte 6:
b8 b7 b6 b5 b4 b3 b2 b1 LS : : MS LS : : MS bit of corporate digit 1 bit of corporate digit 1 bit of corporate digit 2 bit of corporate digit 2
Empty fields shall be coded with 'FF'. The end of the list is delimited by the first MCC field coded 'FFF'.
3GPP
Release 1999
80
Coding: according to TS 04.08 [15]. Value 'FF' means that no information on alerting category is available. Informative text Contents: text describing the type of terminating traffic associated with the category. Coding: see the coding of the Alpha Identifier item of the EF ADN (subclause 10.5.1). The maximum number of characters for this informative text is indicated in TS 02.07 [3].
Description Ciphering key KcGPRS Ciphering key sequence number n for GPRS
Ciphering key KcGPRS Coding: The least significant bit of KcGPRS is the least significant bit of the eighth byte. The most significant bit of KcGPRS is the most significant bit of the first byte.
NOTE:
TS 04.08 [15] defines the value of n=111 as "key not available". Therefore the value '07' and not 'FF' should be present following the administrative phase.
3GPP
Release 1999
81
Identifier: '6F53' File size: 14 bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 to 4 5 to 7 8 to 13 14
Structure: transparent Optional Update activity: high CHV1 CHV1 ADM ADM M/O M M M M Length 4 bytes 3 bytes 6 bytes 1 byte
Description P-TMSI P-TMSI signature value RAI Routing Area update status
P-TMSI Contents: Packet Temporary Mobile Subscriber Identity Coding: according to TS 04.08 [15]. Byte 1: first byte of P-TMSI
b8 MSB b7 b6 b5 b4 b3 b2 b1
P-TMSI signature value Contents: Packet Temporary Mobile Subscriber Identity signature value Coding: according to TS 04.08 [15]. Byte 5: first byte of P-TMSI signature value
b8 MSB b7 b6 b5 b4 b3 b2 b1
RAI Contents: Routing Area Information Coding: according to TS 04.08 [15]. Byte 8: first byte of RAI
b8 MSB b7 b6 b5 b4 b3 b2 b1
Routing area update status Contents: status of routing area update according to TS 04.08 [15]. Coding: Byte 14: Bits: b3 0 0 b2 0 0 b1 0 : updated 1 : not updated
3GPP
Release 1999
82
0 1 0 : PLMN not allowed 0 1 1 : Routing Area not allowed 1 1 1 : reserved Bits b4 to b8 are RFU (see subclause 9.3).
Title Alpha Identifier Contents: this field contains the Alpha Identifier Simple TLV defining the menu title text. Coding: according to TS 11.14 [27].
Title Icon Identifier Contents: this field contains the Icon Identifier Simple TLV defining the menu title icon. Coding: according to GSM 11.14 [27]. If not present the field shall be set to 'FF'. Unused bytes of this file shall be set to 'FF'.
3GPP
Release 1999
83
Identifier:'6F60' File size: 5n (n 8) bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 to 3 4 to 5 6 to 8 9 to 10 : 36 to 38 39 to 40 41 to 43 44 to 45 : (5n-4) to (5n-2) (5n-1) to 5n
Structure: transparent Optional Update activity: low CHV1 CHV1 ADM ADM M/O M M M M M M O O O O Length 3 bytes 2 bytes 3 bytes 2 bytes 3 bytes 2 bytes 3 bytes 2 bytes 3 bytes 2 bytes
Description 1st PLMN (highest priority) 1st PLMN Access Technology Identifier 2nd PLMN 2nd PLMN Access Technology Identifier : 8th PLMN 8th PLMN Access Technology Identifier 9th PLMN 9th PLMN Access Technology Identifier : Nth PLMN (lowest priority) Nth PLMN Access Technology Identifier
PLMN Contents: Mobile Country Code (MCC) followed by the Mobile Network Code (MNC). Coding: according to TS 24.008 [47].
Access Technologies Contents: The Access Technologies of a PLMN that the MS will assume when searching for a listed PLMN. Coding: - 2 bytes are used to select the access technology where the meaning of each bit is as follows: - bit = 1: access technology selected; - bit = 0: access technology not selected.
Byte 5n-1:
b8 b7 b6 b5 b4 b3 b2 b1 RFU RFU RFU RFU RFU RFU RFU Reserved (see 3G TS 31.102 [52])
Byte 5n:
3GPP
Release 1999
84
b8
b7
b6
b5
b4
b3
b2
The RFU bits are coded with '0' in the bit positions.
Description 1st PLMN (highest priority) 1st PLMN Access Technology Identifier : 8th PLMN 8th PLMN Access Technology Identifier 9th PLMN 9th PLMN Access Technology Identifier : Nth PLMN (lowest priority) Nth PLMN Access Technology Identifier
PLMN Contents: Mobile Country Code (MCC) followed by the Mobile Network Code (MNC). Coding: according to TS 24.008 [47].
Access Technologies Contents: The Access Technologies of a PLMN that the MS will assume when searching for a listed PLMN. Coding: See EFPLMNwAcT for coding.
3GPP
Release 1999
85
Description 1st PLMN (highest priority) 1st PLMN Access Technology Identifier 2nd PLMN 2nd PLMN Access Technology Identifier : Nth PLMN (lowest priority) Nth PLMN Access Technology Identifier
PLMN Contents: Mobile Country Code (MCC) followed by the Mobile Network Code (MNC). Coding: according to TS 24.008 [47]. Access Technology Contents: The Access Technology of the HPLMN that the MS will assume when searching for the HPLMN, in priority order. The first Access Technology in the list has the highest priority. Coding: See EFPLMNwAcT for coding.
3GPP
Release 1999
86
ARFCN (10 bits) as defined in TS 05.05 [46]. High/Low band indicator: If the ARFCN indicates possibly a channel in the DCS 1800 or a channel in the PCS 1900 band, if the bit is set to '1' the channel is in the higher band (GSM 1900). If the bit is set to '0', the lower band (GSM 1800) is indicated. If ARFCN indicates a unique channel, this indicator shall be set to '0'. Empty indicator: If this bit is set to '1', no CPBCCH carrier is stored in this position. If the Empty Indicator is set to '1', the content of the CPBCCH carrier field shall be ignored. The empty indicator shall also be used, and set to '1', if storage of fewer than maximum number n, of CPBCCH carrier fields is required.
3GPP
Release 1999
87
A '1' in a bit position indicates that the investigation scan shall be performed for the condition corresponding to that bit position and a '0' that it shall not be performed. If this elementary file is not present, no investigation scan shall be performed.
10.3.40 Void
10.4.1.1
This EF contains the 'LSA only access indicator'. This EF shall always be allocated if DF SoLSA is present. If the indicator is set, the network will prevent terminated and/or originated calls when the MS is camped in cells that are not included in the list of allowed LSAs in EF SLL. Emergency calls are, however, always allowed. The EF also contains a text string which may be displayed when the MS is out of the served area(s).
Identifier: '4F30' File size: X + 1 bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 2 to X+1 Structure: transparent Optional Update activity: low CHV1 ADM ADM ADM M/O M M Length 1 byte X bytes
Description LSA only access indicator LSA only access indication text
LSA only access indicator Contents: indicates whether the MS is restricted to use LSA cells only or not. Coding:
b8 b7 b6 b5 b4 b3 b2 b1 b1=0: LSA only access not activated b1=1: LSA only access activated RFU
LSA only access indication text Contents: text to be displayed by the ME when it's out of LSA area. Coding: the string shall use either the SMS default 7-bit coded alphabet as defined in TS 23.038 [12] with bit 8 set to 0. The alpha identifier shall be left justified. Unused bytes shall be set to 'FF'; or one of the UCS2 coded options as defined in annex B.
3GPP
Release 1999
88
10.4.1.2
This EF contains information describing the LSAs that the user is subscribed to. This EF shall always be allocated if DFSoLSA is present. Each LSA is described by one record that is linked to a LSA Descriptor file. Each record contains information of the PLMN, priority of the LSA, information about the subscription and may also contain a text string and/or an icon that identifies the LSA to the user. The text string can be edited by the user.
Identifier: '4F31' Record length: X + 10 bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 to X X+1 X+2 X+3 X+4 X+5 to X+7 X+8 to X+9 X+10 Structure: linear fixed Optional Update activity: low CHV1 CHV1 ADM ADM M/O O M M M M M M M Length X bytes 1 byte 1 byte 1 byte 1 byte 3 bytes 2 byte 1 byte
Description LSA name Configuration parameters RFU Icon Identifier Priority PLMN code LSA Descriptor File Identifier LSA Descriptor Record Identifier
LSA name Contents: LSA name string to be displayed when the ME is camped in the corresponding area, dependant on the contents of the LSA indication for idle mode field. Coding: the string shall use either the SMS default 7-bit coded alphabet as defined in TS 23.038 [12] with bit 8 set to 0. The alpha identifier shall be left justified. Unused bytes shall be set to 'FF'; or one of the UCS2 coded options as defined in annex B.
Configuration parameters Contents: Icon qualifier, control of idle mode support and control of LSA indication for idle mode. Coding:
b8 b7 b6 b5 b4 b3 b2 b1 Icon qualifier Idle mode support LSA indication for idle mode RFU
Icon qualifier: Contents: The icon qualifier indicates to the ME how the icon is to be used. b2, b1: 00: icon is not to be used and may not be present 01: icon is self-explanatory, i.e. if displayed, it replaces the LSA name 10: icon is not self-explanatory, i.e. if displayed, it shall be displayed together with the LSA name 11: RFU Idle mode support: Contents: The idle mode support is used to indicate whether the ME shall favour camping on the LSA cells in idle mode.
3GPP
Release 1999
89
b3 = 0: b3 = 1:
LSA indication for idle mode: Contents: The LSA indication for idle mode is used to indicate whether or not the ME shall display the LSA name when the ME is camped on a cell within the LSA. b4 = 0: b4 = 1: LSA indication for idle mode disabled LSA indication for idle mode enabled
Bits b5 to b8 are RFU (see subclause 9.3). Icon Identifier Contents: The icon identifier addresses a record in EF IMG. Coding: binary. Priority Contents: Priority of the LSA which gives the ME the preference of this LSA relative to the other LSAs. Coding:
b8 b7 b6 b5 b4 b3 b2 b1 Priority RFU
'0' is lowest priority, 'F' is highest. PLMN code Contents: MCC + MNC for the LSA. Coding: according to GSM 04.08 [15] and EF LOCI. LSA Descriptor File Identifier: Contents: these bytes identify the EF which contains the LSA Descriptors forming the LSA. Coding: byte X+8: high byte of the LSA Descriptor file; byte X+9: low byte of the LSA Descriptor file. LSA Descriptor Record Identifier: Contents: this byte identifies the number of the first record in the LSA Descriptor file forming the LSA. Coding: binary.
3GPP
Release 1999
90
10.4.1.3
Residing under DFSoLSA, there may be several LSA Descriptor files. These EFs contains one or more records again containing LSA Descriptors forming the LSAs. LSAs can be described in four different ways. As a list of LSA IDs, as a list of LAC + CIs, as a list of CIs or as a list of LACs. As the basic elements (LSA ID, LAC + CI, CI and LAC) of the four types of lists are of different length, they can not be mixed within one record. Different records may contain different kinds of lists within the EFs. Examples of codings of LSA Descriptor files can be found in annex F.
Identifier: '4FXX' Record length: n*X+2 bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 2 to X+1 X+2 to 2X+1 (n-1)*X+2 to n*X+1 n*X+2 Structure: linear fixed Optional Update activity: low CHV1 ADM ADM ADM M/O M M M M M Length 1 byte X bytes X bytes X bytes 1 byte
Description LSA descriptor type and number 1st LSA Descriptor 2nd LSA Descriptor nth LSA Descriptor Record Identifier
LSA descriptor type and number: Contents: The LSA descriptor type gives the format of the LSA descriptor and the number of valid LSA Descriptors within the record. Coding:
b8 b7 b6 b5 b4 b3 b2 b1 LSA descriptor type Number of LSA Descriptors
LSA descriptor type: Contents: Gives the format of the LSA Descriptors. b2, b1: 00: LSA ID. 01: LAC + CI 10: CI 11: LAC
Number of LSA Descriptors: Contents: Gives the number of valid LSA Descriptors in the record. Coding: binary, with b8 as MSB and b3 as LSB leaving room for 64 LSA Descriptors per record. LSA Descriptor Contents: Dependant of the coding indicated in the LSA descriptor type: in case of LSA ID the field length 'X' is 3 bytes; in case of LAC + CI the field length 'X' is 4 bytes; in case of CI the field length 'X' is 2 bytes; in case of LAC the field length 'X' is 2 bytes.
3GPP
Release 1999
91
Record Identifier: Contents: This byte identifies the number of the next record containing the LSA Descriptors forming the LSA. Coding: record number of next record. 'FF' identifies the end of the chain.
This file utilises the concept of chaining as for EF EXT1. The identifier '4FXX' shall be different from one LSA Descriptor file to the other and different from the identifiers of EFSAI and EFSLL. For the range of 'XX', see subclause 6.6.
10.4.2.1
This EF indicates which MExE services are allocated, and whether, if allocated, the service is activated. If a service is not allocated or not activated in the SIM, the ME shall not select this service.
Identifier: '4F40' File size: X bytes, X 1 Structure: transparent Optional Update activity: low
Access Conditions: READ CHV1 UPDATE ADM INVALIDATE ADM REHABILITATE ADM Bytes Description 1 Services n1 to n4 2 Services n5 to n8 etc. X Services (4X-3) to (4X) -Services Contents:
M/O M O O
Operator root public key Administrator root public key Third party root public key RFU
Coding: 2 bits are used to code each service: first bit = 1: service allocated first bit = 0: service not allocated where the first bit is b1, b3, b5 or b7; second bit = 1: service activated second bit = 0: service not activated where the second bit is b2, b4, b6 or b8. Service allocated means that the SIM has the capability to support the service. Service activated means that the service is available for the card holder (only valid if the service is allocated). The following codings are possible: - first bit = 0: service not allocated, second bit has no meaning; - first bit = 1 and second bit = 0: service allocated but not activated; - first bit = 1 and second bit = 1: service allocated and activated. The bits for services not yet defined shall be set to RFU. For coding of RFU see subclause 9.3.
3GPP
Release 1999
92
First byte:
b8 b7 b6 b5 b4 b3 b2 b1 Service Service Service Service n1 n2 n3 n4
10.4.2.2
This EF contains the descriptor(s ) of certificates containing the Operator Root Public Key. This EF shall only be allocated if the operator wishes to verify applications and certificates in the MExE operator domain using a root public key held on the SIM. Each record of this EF contains one certificate descriptor. For example, Operator may provide a second key for recover disaster procedure in order to limit OTA data to load.
Identifier: '4F41' Record length : X + 10 bytes, X 1 Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 2 3 4 to 5 6 to 7 8 to 9 10 11 to 10+X Structure: linear fixed Optional Update activity: low CHV1 ADM ADM ADM M/O M M M M M M M M Length 1 byte 1 byte 1 byte 2 bytes 2 bytes 2 bytes 1 byte X bytes
Description Parameters indicator Flags Type of certificate Key/certificate file identifier Offset into key/certificate file Length of key/certificate data Key identifier length (X) Key identifier
Parameter indicator Contents: The parameter indicator indicates if record is full and which optional parameters are present Coding: bit string
b8 b7 b6 b5 b4 b3 b2 b1 Certificate descriptor is valid (bit1=0 key descriptor is valid) Reserved bit set to 1 (bitx=0 optional parameter present)
Flags Contents: The authority flag indicates whether the certificate identify an authority (i.e. CA or AA) or not.
3GPP
Release 1999
93
Type of certificate Contents: This field indicates the type of certificate containing the key. Coding: binary : 0 : WTLS 1 : X509 2 : X9.68 Other values are reserved for further use Key/certificate File Identifier Contents: these bytes identify an EF which is the key/certificate data file (see subclause 10.7.5), holding the actual key/certificate data for this record. Coding: byte 4: high byte of Key/certificate File Identifier; byte 5: low byte of Key/certificate File Identifier. Offset into Key/certificate File Contents: these bytes specify an offset into the transparent key/certificate data File identified in bytes 4 and 5. Coding: byte 6: high byte of offset into Key/certificate Data File; byte 7: low byte of offset into Key/certificate Data File Length of Key/certificate Data Contents: these bytes yield the length of the key/certificate data, starting at the offset identified in "Offset into Key/certificate File" field. Coding: byte 8: high byte of Key/certificate Data length; byte 9: low byte of Key/certificate Data length. Key identifier length Contents: This field gives length of key identifier Coding: binary Key identifier Contents: This field provides a means of identifying certificates that contain a particular public key (chain building) and linking the public key to its corresponding private key. For more information about value and using see TS 23.057 [50]. Coding: octet string transparent key/certificate data longer than 256 bytes may be read using successive READ BINARY commands.
Note:
3GPP
Release 1999
94
10.4.2.3
This EF contains the descriptor(s ) of certificates containing the Administrator Root Public Key. This EF shall only be allocated if the SIM issuer wishes to control the Third Party certificates on the terminal using an Administrator Root Public Key held on the SIM. Each record of this EF contains one certificate descriptor. This file shall contain only one record.
Identifier: '4F42' Record length: X + 10 bytes, X 1 Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 2 3 4 to 5 6 to 7 8 to 9 10 11 to 10+X Structure: linear fixed Optional Update activity: low CHV1 ADM ADM ADM M/O M M M M M M M M Length 1 byte 1 byte 1 byte 2 bytes 2 bytes 2 bytes 1 byte X bytes
Description Parameters indicator Flags Type of certificate Key/certificate file identifier Offset into key/certificate file Length of key/certificate data Key identifier length (X) Key identifier
For contents and coding of all data items see the respective data items of the EF ORPK (sub-clause 10.4.2.1).
10.4.2.4
This EF contains descriptor(s ) of certificates containing the Third Party Root Public key (s). This EF shall only be allocated if the SIM issuer wishes to verify applications and certificates in the MExE Third Party domain using root public key(s) held on the SIM. This EF can contain one or more root public keys. Each record of this EF contains one certificate descriptor. For example, an operator may provide several Third Party root public keys.
Identifier: '4F43' Structure: linear fixed Optional Record length : X + Y + 11 bytes, X 1; Update activity: low Y1 Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 2 3 4 to 5 6 to 7 8 to 9 10 11 to 10+X 11+X 12+X to 11+X+Y CHV1 ADM ADM ADM M/O M M M M M M M M M M Length 1 byte 1 byte 1 byte 2 bytes 2 bytes 2 bytes 1 byte X bytes 1 byte Y bytes
Description Parameters indicator Flags Type of certificate Key/certificate file identifier Offset into key/certificate file Length of key/certificate data Key identifier length (X) Key identifier Certificate identifier length (m) Certificate identifier
3GPP
Release 1999
95
Contents: This field gives length of certificate identifier Coding: binary Certificate identifier Contents: This field identify the issuer and provide a easy way to find a certificate. For more information about value and usage, see TS 23.057 [50]. Coding: Octet string
For contents and coding of all other data items see the respective data items of the EF ORPK (sub-clause 10.7.1).
10.4.2.5
Residing under DFMExE, there may be several key/certificates data files. These EFs containing key/certificates data shall have the following attributes:
Identifier: '4FXX' File size: Y bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 to Y Structure: transparent Optional Update activity: low CHV1 ADM ADM ADM M/O M Length Y bytes
Contents and coding: Key/certificate data are accessed using the key/certificates descriptors provided by EF TPRPK (see sub-clause 10.4.2.4). The identifier '4FXX' shall be different from one key/certificate data file to the other. For the range of 'XX', see subclause 6.6. The length Y may be different from one key/certificate data file to the other.
3GPP
Release 1999
96
Identifier: '6F3A' Record length: X+14 bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 to X X+1 X+2 X+3 to X+12 X+13 X+14
Structure: linear fixed Optional Update activity: low CHV1 CHV1 CHV2 CHV2 M/O O M M M M M Length X bytes 1 byte 1 byte 10 bytes 1 byte 1 byte
Description Alpha Identifier Length of BCD number/SSC contents TON and NPI Dialling Number/SSC String Capability/Configuration Identifier Extension1 Record Identifier
Alpha Identifier Contents: Alpha-tagging of the associated dialling number. Coding: this alpha-tagging shall use either the SMS default 7-bit coded alphabet as defined in TS 23.038 [12] with bit 8 set to 0. The alpha identifier shall be left justified. Unused bytes shall be set to 'FF'; or one of the UCS2 coded options as defined in annex B.
NOTE 1: The value of X may be from zero to 241. Using the command GET RESPONSE the ME can determine the value of X. Length of BCD number/SSC contents Contents: this byte gives the number of bytes of the following two data items containing actual BCD number/SSC information. This means that the maximum value is 11, even when the actual ADN/SSC information length is greater than 11. When an ADN/SSC has extension, it is indicated by the extension1 identifier being unequal to 'FF'. The remainder is stored in the EF EXT1 with the remaining length of the additional data being coded in the appropriate additional record itself (see subclause 10.5.10). Coding: according to TS 04.08 [15]. TON and NPI Contents: Type of number (TON) and numbering plan identification (NPI). Coding: according to TS 04.08 [15]. If the Dialling Number/SSC String does not contain a dialling number, e.g. a control string deactivating a service, the TON/NPI byte shall be set to 'FF' by the ME (see note 2). NOTE 2: If a dialling number is absent, no TON/NPI byte is transmitted over the radio interface (see TS 04.08 [15]). Accordingly, the ME should not interpret the value 'FF' and not send it over the radio interface.
3GPP
Release 1999
97
b8
b7
b6
b5
b4
b3
b2
b1 NPI TON 1
Dialling Number/SSC String Contents: up to 20 digits of the telephone number and/or SSC information. Coding: according to TS 04.08 [15] , TS 02.30 [8] and the extended BCD-coding (see table 12). If the telephone number or SSC is longer than 20 digits, the first 20 digits are stored in this data item and the remainder is stored in an associated record in the EF EXT1. The record is identified by the Extension1 Record Identifier. If ADN/SSC require less than 20 digits, excess nibbles at the end of the data item shall be set to 'F'. Where individual dialled numbers, in one or more records, of less than 20 digits share a common appended digit string the first digits are stored in this data item and the common digits stored in an associated record in the EFEXT1. The record is identified by the Extension 1 Record Identifier. Excess nibbles at the end of the data item shall be set to 'F'. Byte X+3
b8 b7 b6 b5 b4 b3 b2 b1 LSB : : MSB LSB : : MSB of Digit 1 of Digit 1 of Digit 2 of Digit 2
Byte X+4:
b8 b7 b6 b5 b4 b3 b2 b1 LSB : : MSB LSB : : MSB of Digit 3 of Digit 3 of Digit 4 of Digit 4
etc. Capability/Configuration Identifier Contents: capability/configuration identification byte. This byte identifies the number of a record in the EF CCP containing associated capability/configuration parameters required for the call. The use of this byte is optional. If it is not used it shall be set to 'FF'. Coding: binary. Extension1 Record Identifier Contents:
3GPP
Release 1999
98
extension1 record identification byte. This byte identifies the number of a record in the EF EXT1 containing an associated called party subaddress or additional data. The use of this byte is optional. If it is not used it shall be set to 'FF'. If the ADN/SSC requires both additional data and called party subaddress, this byte identifies the additional record. A chaining mechanism inside EF EXT1 identifies the record of the appropriate called party subaddress (see subclause 10.5.10). Coding: binary. NOTE 3: As EFADN is part of the DFTELECOM it may be used by GSM and also other applications in a multi-application card. If the non-GSM application does not recognize the use of Type of Number (TON) and Number Plan Identification (NPI), then the information relating to the national dialling plan must be held within the data item dialling number/SSC and the TON and NPI fields set to UNKNOWN. This format would be acceptable for GSM operation and also for the non-GSM application where the TON and NPI fields shall be ignored. EXAMPLE: SIM storage of an International Number using E.164 [19] numbering plan. TON GSM application Other application compatible with GSM 001 000 NPI 0001 0000 Digit field abc... xxx...abc...
where "abc..." denotes the subscriber number digits (including its country code), and "xxx..." denotes escape digits or a national prefix replacing TON and NPI. NOTE 4: When the ME acts upon the EF ADN with a SEEK command in order to identify a character string in the alpha-identifier, it is the responsibility of the ME to ensure that the number of characters used as SEEK parameters are less than or equal to the value of X if the MMI allows the user to offer a greater number. Table 12: Extended BCD coding
BCD Value '0' ... '9' 'A' 'B' 'C' 'D' 'E' Character/Meaning "0" ... "9" "*" "#" DTMF Control digit separator (TS 02.07 [3]) "Wild" value This will cause the MMI to prompt the user for a single digit (see TS 02.07 [3]). Expansion digit ("Shift Key"). It has the effect of adding '10' to the following digit. The following BCD digit will hence be interpreted in the range of '10'-'1E'. The purpose of digits in this range is for further study. Endmark e.g. in case of an odd number of digits
'F'
BCD values 'C', 'D' and 'E' are never sent across the radio interface. NOTE 5: The interpretation of values 'D', 'E' and 'F' as DTMF digits is for further study. NOTE 6: A second or subsequent 'C' BCD value will be interpreted as a 3 second PAUSE (see TS 02.07 [3]).
3GPP
Release 1999
99
Description Alpha Identifier Length of BCD number/SSC contents TON and NPI Dialling Number/SSC String Capability/Configuration Identifier Extension2 Record Identifier
M/O O M M M M M
For contents and coding of all data items see the respective data items of the EF ADN (subclause 10.5.1), with the exception that extension records are stored in the EF EXT2. NOTE: The value of X (the number of bytes in the alpha-identifier) may be different to the length denoted X in EFADN.
Status Contents: Status byte of the record which can be used as a pattern in the SEEK command. For MS originating messages sent to the network, the status shall be updated when the MS receives a status report, or sends a successful SMS Command relating to the status report.
3GPP
Release 1999
100
Coding:
b8 b7 b6 b5 b4 b3 X X 0 0 1 b2 X X 0 1 1 b1 0 1 1 1 1 free space used space message received by MS from network; message read message received by MS from network; message to be read MS originating message; message to be sent RFU (see subclause 9.3) b8 b7 b6 b5 X 0 0 1 1 b4 X 0 1 0 1 b3 1 1 1 1 1 b2 0 0 0 0 0 b1 1 1 1 1 1 MS originating message; message sent to status report not requested status report requested but not (yet) status report requested, received but in EF-SMSR; status report requested, received and in EF-SMSR; RFU (see subclause 9.3) the network: received; not stored stored
Remainder Contents: This data item commences with the TS-Service-Centre-Address as specified in TS 24.011 [16]. The bytes immediately following the TS-Service-Centre-Address contain an appropriate short message TPDU as specified in TS 23.040 [13], with identical coding and ordering of parameters. Coding: according to TS 23.040 [13] and TS 24.011 [16]. Any TP-message reference contained in an MS originated message stored in the SIM, shall have a value as follows: message to be sent: message sent to the network: Value of the TP-message-reference: 'FF' the value of TP-Message-Reference used in the message sent to the network.
Any bytes in the record following the TPDU shall be filled with 'FF'. It is possible for a TS-Service-Centre-Address of maximum permitted length, e.g. containing more than 18 address digits, to be associated with a maximum length TPDU such that their combined length is 176 bytes. In this case the ME shall store in the SIM the TS-Service-Centre-Address and the TPDU in bytes 2-176 without modification, except for the last byte of the TPDU, which shall not be stored.
This EF contains parameters of required network and bearer capabilities and ME configurations associated with a call established using an abbreviated dialling number, a fixed dialling number, an MSISDN, a last number dialled, a service dialling number or a barred dialling number. For compatibility reasons, this file may be present for release 98 or earlier MEs in order to support Capability Configuration Parameters service.
3GPP
Release 1999
101
Identifier: '6F3D' Record length: 14 bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 to 10 11 to 14
Structure: linear fixed Optional Update activity: low CHV1 CHV1 ADM ADM M/O M M Length 10 bytes 4 bytes
Bearer capability information element Contents and Coding: see TS 04.08 [15]. The Information Element Identity (IEI) shall be excluded. i.e. the first byte of the EFCCP record shall be Length of the bearer capability contents. Bytes 11-14 shall be set to 'FF' and shall not be interpreted by the ME.
10.5.4.2
This EF contains parameters of required network and bearer capabilities and ME configurations associated with a call established using an abbreviated dialling number, a fixed dialling number, an MSISDN, a last number dialled, a service dialling number or a barred dialling number. The number of records of the EF ECCP shall be equal to the number of records of the EF CCP. Each record of the EFCCP shall have a corresponding record in the EF ECCP with the same record number. If an ME has to update a record, then the ME shall update each record of both files, EF CCP with 10 bytes and EFECCP with X bytes (X15). If an ME has to read a record, then the ME shall check the consistency between the record of the EF ECCP and the corresponding record of the EF CCP and update the record of the EF ECCP with the value of the corresponding record of the EFCPP.
Identifier: '6F4F' Record length: X (X15) Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 to X Structure: linear fixed Optional Update activity: low CHV1 CHV1 ADM ADM M/O M Length X bytes
Bearer capability information element Contents and Coding: see TS 24.008 [47]. The Information Element Identity (IEI) shall be excluded, i.e. the first byte of the EFECCP record shall be Length of the bearer capability contents. Unused bytes are filled with 'FF'.
3GPP
Release 1999
102
Description Alpha Identifier Length of BCD number/SSC contents TON and NPI Dialling Number/SSC String Capability/Configuration Identifier Extension1 Record Identifier
For contents and coding of all data items see the respective data items of EF ADN. NOTE 1: If the SIM stores more than one MSISDN number and the ME displays the MSISDN number(s) within the initialization procedure then the one stored in the first record shall be displayed with priority. NOTE 2: The value of X (the number of bytes in the alpha-identifier) may be different to the length denoted X in EFADN.
Description Alpha-Identifier Parameter Indicators TP-Destination Address TS-Service Centre Address TP-Protocol Identifier TP-Data Coding Scheme TP-Validity Period
Storage is allocated for all of the possible SMS parameters, regardless of whether they are present or absent. Any bytes unused, due to parameters not requiring all of the bytes, or due to absent parameters, shall be set to 'FF'.
3GPP
Release 1999
103
Alpha-Identifier Contents: Alpha Tag of the associated SMS-parameter. Coding: see subclause 10.5.1 (EFADN).
NOTE: -
The value of Y may be zero, i.e. the alpha-identifier facility is not used. By using the command GET RESPONSE the ME can determine the value of Y.
Parameter Indicators Contents: Each of the default SMS parameters which can be stored in the remainder of the record are marked absent or present by individual bits within this byte. Coding: Allocation of bits: Bit number Parameter indicated 1 TP-Destination Address 2 TS-Service Centre Address 3 TP-Protocol Identifier 4 TP-Data Coding Scheme 5 TP-Validity Period 6 reserved, set to 1 7 reserved, set to 1 8 reserved, set to 1 Bit value 0 1 Meaning Parameter present Parameter absent
TP-Destination Address Contents and Coding: As defined for SM-TL address fields in TS 23.040 [13].
TP-Service Centre Address Contents and Coding: As defined for RP-Destination address Centre Address in TS 24.011 [16].
TP-Validity Period Contents and Coding: As defined in TS 23.040 [13] for the relative time format.
3GPP
Release 1999
104
Identifier: '6F43' File size: 2+X bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 2 3 to 2+X
Structure: transparent Optional Update activity: low CHV1 CHV1 ADM ADM M/O M M O Length 1 byte 1 byte X bytes
Description Last Used TP-MR SMS "Memory Cap. Exceeded" Not. Flag RFU
Last Used TP-MR. Contents: the value of the TP-Message-Reference parameter in the last mobile originated short message, as defined in TS 23.040 [13]. Coding: as defined in TS 23.040 [13].
SMS "Memory Capacity Exceeded" Notification Flag. Contents: This flag is required to allow a process of flow control, so that as memory capacity in the MS becomes available, the Network can be informed. The process for this is described in TS 23.040 [13]. Coding: b1=1 means flag unset; memory capacity available b1=0 means flag set b2 to b8 are reserved and set to 1.
Description Alpha Identifier Length of BCD number/SSC contents TON and NPI Dialling Number/SSC String Capability/Configuration Identifier Extension1 Record Identifier
3GPP
Release 1999
105
The value of X in EFLND may be different to both the value of X in EF ADN and of X in EFFDN. If the value of X in EFLND is longer than the length of the -tag of the number to be stored, then the ME shall pad the -tag with 'FF'. If the value of X in EF LND is shorter than the length of the -tag of the number to be stored, then the ME shall cut off excessive bytes.
Description Alpha identifier Length of BCD number/SSC contents TON and NPI Dialling Number/SSC String Capability/Configuration Identifier Extension3 Record Identifier
For contents and coding of all data items see the respective data items of the EF ADN (subclause 10.5.1), with the exception that extension records are stored in the EF EXT3. NOTE: The value of X (the number of bytes in the alpha-identifier) may be different to the length denoted X in EFADN.
3GPP
Release 1999
106
Coding:
b8 b7 b6 b5 b4 b3 b2 b1 Called Party Subaddress Additional data RFU
b3-b8 are reserved and set to 0; a bit set to 1 identifies the type of record; only one type can be set; '00' indicates the type "unknown". The following example of coding means that the type of extension data is "additional data":
b8 0 b7 0 b6 0 b5 0 b4 0 b3 0 b2 1 b1 0
Extension data Contents: Additional data or Called Party Subaddress depending on record type. Coding: Case 1, Extension1 record is additional data: The first byte of the extension data gives the number of bytes of the remainder of ADN/SSC (respectively MSISDN, LND). The coding of remaining bytes is BCD, according to the coding of ADN/SSC (MSISDN, LND). Unused nibbles at the end have to be set to 'F'. It is possible if the number of additional digits exceeds the capacity of the additional record to chain another record inside the EXT1 Elementary File by the identifier in byte 13. Case 2, Extension1 record is Called Party Subaddress: The subaddress data contains information as defined for this purpose in TS 04.08 [15]. All information defined in TS 04.08, except the information element identifier, shall be stored in the SIM. The length of this subaddress data can be up to 22 bytes. In those cases where two extension records are needed, these records are chained by the identifier field. The extension record containing the first part of the called party subaddress points to the record which contains the second part of the subaddress.
Identifier Contents: identifier of the next extension record to enable storage of information longer than 11 bytes. Coding: record number of next record. 'FF' identifies the end of the chain.
EXAMPLE:
Of a chain of extension records being associated to an ADN/SSC. The extension1 record identifier (Byte 14+X) of ADN/SSC is set to 3.
Type : : 02 xx 01 01 : : Extension Data : : xx ........xx xx ........xx xx ........xx xx ........xx : : Next : : 06 xx FF 05 : : Record
In this example ADN/SSC is associated to additional data (record 3) and a called party subaddress whose length is more than 11 bytes (records 6 and 5).
3GPP
Release 1999
107
Description Alpha Identifier Length of BCD number/SSC contents TON and NPI Dialling Number/SSC String Capability/Configuration Identifier Extension4 Record Identifier Comparison Method Pointer
3GPP
Release 1999
108
For contents and coding of all data items, except for the Comparison Method Pointer, see the respective data items of the EFADN (subclause 10.5.1), with the exception that extension records are stored in the EF EXT4. The Comparison Method Pointer refers to a record number in EF CMI. NOTE: The value of X (the number of bytes in the alpha-identifier) may be different to the length denoted X in EFADN.
SMS record identifier Contents: This data item identifies the corresponding SMS record in EF SMS, e.g. if this byte is coded '05' then this status report corresponds to the short message in record #5 of EF SMS. Coding: '00' - empty record
'01' - 'FF' - record number of the corresponding SMS in EF SMS. SMS status report
3GPP
Release 1999
109
Contents: This data item contains the SMS-STATUS-REPORT TPDU as specified in TS 23.040 [13], with identical coding and ordering of parameters. Coding: according to TS 23.040 [13]. Any bytes in the record following the TPDU shall be filled with 'FF'.
Alpha Identifier Contents: Alpha-tagging of the associated Comparison Method Identifier Coding: Same as the alpha identifier in EF ADN.
Comparison Method Identifier Contents: this byte describes the comparison method which is associated with a BDN record. Its interpretation is not specified but it shall be defined by the operators implementing the BDN feature. Coding: '00' - 'FE' = Comparison Method Identifier. 'FF' = Default method.
10.6.1.1
EFIMG (Image)
Each record of this EF identifies instances of one particular graphical image, which graphical image is identified by this EF's record number.
3GPP
Release 1999
110
Image instances may differ as to their size, having different resolutions, and the way they are coded, using one of several image coding schemes. As an example, image k may represent a company logo, of which there are i instances on SIM, of various resolutions and perhaps encoded in several image coding schemes. Then, the i instances of the company's logo are described in record k of this EF.
Identifier: '4F20' Record length: 9n+1 or 9n+2 bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 2 to 10 11 to 19 : 9 (n-1) + 2 to 9n + 1 9n + 2 Structure: linear fixed Optional Update activity: low CHV1 ADM ADM ADM M/O M M O O O Length 1 byte 9 bytes 9 bytes 9 bytes 1 byte
Description Number of Actual Image Instances Descriptor of Image Instance 1 Descriptor of Image Instance 2 Descriptor of Image Instance n RFU
Number of Actual Image Instances Contents: this byte gives the number of actual image instances described in the following data items (i.e. unused descriptors are not counted). Coding: binary
Image Instance Descriptor Contents: a description of an image instance Coding: see below Byte 1: Image Instance Width Contents: this byte specifies the image instance width, expressed in raster image points. Coding: binary. Byte 2: Image Instance Height Contents: this byte specifies the image instance height, expressed in raster image points. Coding: binary. Byte 3: Image Coding Scheme Contents: this byte identifies the image coding scheme that has been used in encoding the image instance. Coding: '11' - basic image coding scheme as defined in annex G;
3GPP
Release 1999
111
'21' - colour image coding scheme as defined in annex G; other values are reserved for future use. Bytes 4 and 5: Image Instance File Identifier Contents: these bytes identify an EF which is the image instance data file (see subclause 10.6.1.2), holding the actual image data for this particular instance. Coding: byte 4: high byte of Image Instance File Identifier; byte 5: low byte of Image Instance File Identifier. Bytes 6 and 7: Offset into Image Instance File Contents: these bytes specify an offset into the transparent Image Instance File identified in bytes 4 and 5. Coding: byte 6: high byte of offset into Image Instance File; byte 7: low byte of offset into Image Instance File Bytes 8 and 9: Length of Image Instance Data Contents: these bytes yield the length of the image instance data, starting at the offset identified in bytes 6 and 7. For the colour image coding scheme, as defined in annex G, the length of image instance data excludes the CLUT. Coding: byte 8: high byte of Image Instance Data length; byte 9: low byte of Image Instance Data length. NOTE: Transparent image instance data longer than 256 bytes may be read using successive READ BINARY commands.
10.6.1.2
Residing under DFGRAPHICS, there may be several image instance data files. These EFs containing image instance data shall have the following attributes.
Identifier: '4FXX' Record length: Y bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 to Y Structure: transparent Optional Update activity: low CHV1 ADM ADM ADM M/O M Length Y bytes
Contents and coding: Image instance data are accessed using the image instance descriptors provided by EF IMG (see subclause 10.6.1.1).
3GPP
Release 1999
112
The identifier '4FXX' shall be different from one image instance data file to the other. For the range of 'XX', see subclause 6.6. The length Y may be different from one image instance data file to the other.
3GPP
Release 1999
113
3GPP
Release 1999
114 MF '3F00'
DFGSM '7F20'
DFTELECOM '7F10'
DFIS-41 '7F22'
DFFP-CTS '7F23'
see GSM 11.19
EFICCID '2FE2'
EFELP '2F05'
EFADN '6F3A'
EFFDN '6F3B'
EFSMS '6F3C'
EFCCP '6F3D'
EFMSISDN '6F40'
EFSMSP '6F42'
EFSMSS '6F43'
EFLND '6F44'
EFSMSR '6F47'
EFSDN '6F49'
EFEXT1 '6F4A'
EFEXT2 '6F4B'
EFEXT3 '6F4C'
EFBDN '6F4D'
EFEXT4 '6F4E'
DFGRAPHICS '5F50'
EFIMG '4F20'
DFIRIDIUM '5F30'
DFGLOBST '5F31'
DFICO '5F32'
DFACeS '5F33'
DFEIA/TIA-553 '5F40'
DFCTS '5F60'
see GSM 11.19
DFSoLSA '5F70'
EFSAI '4F30'
EFSLL '4F31'
DFMExE '5F3C'
EFMExE-ST
EFORPK
EFARPK
EFTPRPK
'4F40'
'4F41'
'4F42'
'4F43'
EFLP '6F05'
EFIMSI '6F07'
EFKc '6F20'
EFPLMNsel '6F30'
EFHPPLMN '6F31'
EFACMmax '6F37'
EFSST '6F38'
EFACM '6F39'
EFGID1 '6F3E'
EFGID2 '6F3F'
EFPUCT '6F41'
EFCBMI '6F45'
EFSPN '6F46'
EFCBMID '6F48'
EFBCCH '6F74'
EFACC '6F78'
EFFPLMN '6F7B'
EFLOCI '6F7E'
EFAD '6FAD'
EFPHASE '6FAE'
EFVGCS '6FB1'
EFVGCSS '6FB2'
EFVBS '6FB3'
EFVBSS '6FB4'
EFeMLPP '6FB5'
EFAAeM '6FB6'
EFECC '6FB7'
EFCBMIR '6F50'
EFNIA '6F51'
EFKcGPRS '6F52'
EFLOCIGPRS '6F53'
EFSUME '6F54'
EFPLMNwAcT '6F60'
EFOPLMNwAcT '6F61'
EFHPLMNAcT '6F62'
EFCPBCCH '6F63'
EFINVSCAN
3GPP
115
11
Application protocol
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 Updating an EF Increasing an EF ME ME ME
SIM management procedures: SIM initialization GSM session termination Emergency call codes request Extended language preference request Language preference request Administrative information request SIM service table request ME ME ME ME ME ME ME
3GPP
Release 1999
116
ME
CHV related procedures: CHV verification CHV value substitution CHV disabling CHV enabling CHV unblocking MMI MMI MMI MMI MMI
GSM security related procedures: GSM algorithms computation IMSI request Access control information request Higher Priority PLMN search period request Location Information NET NET NET NET NET NET NET NET NET NET NET
GPRS Location Information Cipher key GPRS Cipher key BCCH information Forbidden PLMN information LSA information
Subscription related procedures: Dialling Numbers (ADN, FDN, MSISDN, LND, SDN, BDN) MMI/ME Short messages (SMS) Advice of Charge (AoC) Capability Configuration Parameters (CCP) PLMN Selector HPLMN Selector with Access Technology User controlled PLMN Selector with Access Technology Operator controlled PLMN Selector with Access Technology Investigation Scan request CPBCCH information Cell Broadcast Message Identifier (CBMI) Group Identifier Level 1 (GID1) Group Identifier Level 2 (GID2) Service Provider Name (SPN) Voice Group Call Service (VGCS) Voice Broadcast Service (VBS) MMI MMI MMI MMI MMI MMI MMI NET NET MMI MMI/ME MMI/ME ME MMI/ME MMI/ME
3GPP
Release 1999
117
Enhanced Multi Level Pre-emption and Priority (eMLPP) Depersonalisation Control Keys Short message status reports (SMSR) Network's indication of alerting
MMI/ME ME MMI ME
SIM Application Toolkit related procedures: Data Download via SMS-CB (CBMID) Data Download via SMS-PP Menu selection Call Control Proactive SIM Mobile Originated Short Message control by SIM Image Request NET NET MMI MMI/ME/NET MMI/ME/NET MMI/ME/NET MMI/ME
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.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.
3GPP
Release 1999
118
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.
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 EF IMSI 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 EF IMSI 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 n3 and n31 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 EF IMSI 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
3GPP
Release 1999
119
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.
3GPP
Release 1999
120
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.
3GPP
Release 1999
121
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]).
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.
3GPP
Release 1999
122
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.
3GPP
Release 1999
123
3GPP
Release 1999
124
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 n10 "allocated and activated"; (Service n10 applies also for MSISDN and LND; Service n11 for FDN; Service n19 for SDN; Service n32 for BDN). The ME seeks for a free record in EF EXT1. 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 EF EXT1. 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 EF ADN 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 n10 "allocated and activated" (Service n10 applies also for MSISDN and LND; Service n11 for FDN; Service n19 for SDN; Service n32 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 EF EXT1. 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 EF EXT1 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 EF ADN. 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.
3GPP
Release 1999
125
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 EF EXT1. 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: Request: The ME sends the identification of the information to be erased. The content of the identified record in EFADN is marked as "free". 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 EF EXT1 or EFCCP. If necessary, then the ME performs the reading procedure on these EFs to assemble the complete ADN/SSC. The ME shall access each EF which references EF EXT1 (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'.
Purge:
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 EF EXT1, 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 n3 (FDN). FDN capability request. The ME has to check the state of service n3, 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 n3 is enabled. If ADN is activated, the ME checks the response data of EF ADN. If EFADN is invalidated, service n3 is enabled. In all other cases service n3 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 EF ADN. The invalidate/rehabilitate flag of EF ADN, which is implicitly set by the REHABILITATE command, is at the same time the indicator for the state of the service n3. If ADN is not activated, disabling of FDN is not possible and thus service n3 is always enabled (see FDN capability request). NOTE 3: If FDN is disabled (by rehabilitating EF ADN) using an administrative terminal then the FDN disabling procedure of this administrative terminal need also to rehabilitate EF IMSI 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 EF ADN, which is implicitly cleared by the INVALIDATE command, is at the same time the indicator for the state of the service n3 (see FDN capability request). If ADN is not activated, service n3 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 n31 (BDN). BDN capability request. The ME has to check the state of service n31, i.e. if BDN is "enabled" or "disabled". BDN service is "enabled" only if service n31 is allocated and activated, and EF BDN 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 EF BDN, which is implicitly cleared by the INVALIDATE command, is at the same time the indicator for the state of the service n31 (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 EF BDN, which is implicitly set by the REHABILITATE command, is at the same time the indicator for the state of the service n31 (see BDN capability request).
3GPP
Release 1999
126
Invalidated BDNs (when BDN capability is disabled) may optionally still be readable and updatable depending on the file status (see subclause 9.3).
Accumulated Call Meter Maximum Value. Request: Initialization: The ME performs the reading procedure with EF ACMmax. The ME performs the updating procedure with EF ACMmax using the new initial maximum value.
Price per Unit and Currency Table (PUCT). Request: Update: The ME performs the reading procedure with EF PUCT. The ME performs the updating procedure with EF PUCT.
3GPP
Release 1999
127
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".
Voice Group Call Service Status Request: Update: The ME performs the reading procedure with EF VGCSS. The ME performs the updating procedure with EF VGCSS.
Voice Broadcast Service Status Request: The ME performs the reading procedure with EF VBSS.
3GPP
Release 1999
128
Update:
Automatic Answer on eMLPP service Request: Update: The ME performs the reading procedure with EF AAeM. The ME performs the updating procedure with EF AAeM.
Update:
3GPP
Release 1999
129
11.5.22 Void
3GPP
Release 1999
130
3GPP
Release 1999
131
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.
3GPP
Release 1999
132
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.7.1 MExE ST
Requirement: Request: Service n49 (MExE) "allocated and activated". The ME performs the reading procedure with EF MExE_ST.
3GPP
Release 1999
133
2 ,7 5 m a x
L e ft e d g e
P2
P3
R1
_0 +
,1
3 ,3
5 ,2 9 m a x
4 ,4 5 m in
7 ,8 3 m a x
6 ,9 9 m in
9 ,5 3 m in
1 0 ,3 7 m a x
7 ,5
P1
1 2 ,0 7 m in
_+ 0,
R1
4 m ax 6 m in 1 1 ,6 2 m a x 1 3 ,6 2 m in
1 _+ 0,
3 0 ,1
(6 ,2 5 )
NOTE:
2 5 0 ,1
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.
3GPP
1 5 0 ,1
(1 6 ,4 8 )
2 0 ,8
R1
_0 +
,1
R1
_ 0, +
1
3 0 ,1
Release 1999
134
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 '81' Octet 2 '05' Octet 3 '13' Octet 4 '53' Octet 5 '95' Octet 6 'A6' Octet 7 'XX' Octet 8 'FF' Octet 9 '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 (0 000 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').
3GPP
Release 1999
135
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 '82' Octet 2 '05' Octet 3 '05' Octet 4 '30' Octet 5 '2D' Octet 6 '82' Octet 7 'D3' Octet 8 '2D' Octet 9 '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.
3GPP
Release 1999
136
S e le c t D F
G SM
G et R esponse
V e r ify C H V 1 ( if n o t d is a b le d )
Phase 1
S IM P hase? Phase 2
Phase 2+
P e r f o r m P r o file D o w n lo a d
(s e e n o te 3 )
M E : u n r e s t r ic t e d o p e r a t io n
S e le c t E F
LO C I
(s e e n o te 1 )
G et R esponse ( e v a lu a t io n o f in v a lid a t io n f la g )
S e le c t E F
IM S I
(s e e n o te 1 )
G et R esponse ( e v a l u a t io n o f i n v a l i d a t i o n f la g )
n o t in v a lid a t e d (s e e n o te 2 )
S ta tu s E F IM S I a n d E F LOCI
in v a lid a t e d
M E : u n r e s tr ic te d o p e r a tio n
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)
3GPP
Release 1999
137
yes
ME supports CC ?
no
all
no
no
EF
IMSI
EF
IMSI
no (note 5)
no (note 5)
r e s tr ic te d o r u n re s tr ic te d n o o p e r a tio n o p e r a tio n , a c c o r d in g to th e s ta te ( e n a b le d /d is a b le d ) o f th e v a r io u s s e r v ic e s (F D N , C C )
F D N o p e r a tio n
NOTE 4: In case of "BDN enabled", the SIM only allows rehabilitation of the EF IMSI 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 EF IMSI 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 EF IMSI and EFLOCI (see note 4).
3GPP
Release 1999
138
Select EF Read EF
SST
SST
yes
no
Select DF Select EF
TELECOM
BDN
no
EF invalidated
BDN
yes
BDN enabled
BDN disabled
No BDN SIM
3GPP
Release 1999
139
Select EF
SST
Read EF
SST
yes
no
yes
Select DF Select EF
Telecom
ADN
no
invalidated ?
FDN enabled
NOTE 7: In this case FDN is enabled without the possibility of disabling.
FDN disabled
No FDN SIM
3GPP
Release 1999
140
Rehabilitate EF IMSI EF LOCI
Select EF
IMSI
Rehabilitate EF IMSI
(Note 8)
Select EF
LOCI
Rehabilitate EF RehabilitaLOCI te
(Note 8)
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.
no
Boolean Equation: FD = FDA.(NOT(ADA)+ADA.ADI) where FD = FDN enabled FDA = FDN allocated and activated ADA = ADN allocated and activated ADI = EFADN invalidated
yes
yes
EF
ADN
EF
no
no
invalidated ?
yes
FDN enabled
3GPP
Release 1999
141
3GPP
Release 1999
142
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 EF ACM 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].
3GPP
Release 1999
143
SMS
SIM
_Data_Download/Class_2
ENV(SMS) (SMS)
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.
3GPP
Release 1999
144
SMS
SIM
_Data_Download/Class_2
60
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.
3GPP
Release 1999
145
SMS
SIM
_Data_Download/Class_2
60
(9F10) 9F10 Get Response (16 bytes) (SIM Ack) SIM Ack SMS Ack (with SIM Ack)
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.
3GPP
Release 1999
146
Case 5: A normal GSM command requires processing before the ME can respond to the 91XX from the SIM
Network ME GSM SIM SIM Application
SMSSIM
_Data_Download/Class_2
91XX
9000
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.
3GPP
Release 1999
147
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:
BUSY SMS
SIM
_Data_Download/Class_2
ENV(SMS)
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.
3GPP
Release 1999
148
2nd record:
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:
CI (2 bytes)
CI (2 bytes)
Identifier (1 byte)
3GPP
Release 1999
149
1 (x * (y-1) + 1)
x (x * y)
G.1
This coding scheme applies to rectangular raster images made up of raster points that are either set or not set. This coding scheme does not support any notion of colour. Image data are coded as follows:
Byte(s) 1 2 3 to K+2 Description image width = X image height = Y image body Length 1 1 K
Coding of image body: The status of each raster image point is coded in one bit, to indicate whether the point is set (status = 1) or not set (status = 0). Byte 1:
b8 b7 b6 b5 b4 b3 b2 b1 status status status status status status status status of of of of of of of of raster raster raster raster raster raster raster raster point point point point point point point point 8 7 6 5 4 3 2 1
Byte 2:
b8 b7 b6 b5 b4 b3 b2 b1 status status status status status status status status of of of of of of of of raster raster raster raster raster raster raster raster point point point point point point point point 16 15 14 13 12 11 10 9
3GPP
Release 1999
150
G.2
This coding scheme applies to coloured rectangular raster images. Raster image point colours are defined as references into a colour look-up table (CLUT), which contains a subset of the red-green-blue colour space. The CLUT in turn is located in the same transparent file as the image instance data themselves, at an offset defined within the image instance data. Image data are coded as follows:
Byte(s) 1 2 3 4 5 to 6 7 to K+6 Description Image width = X Image height = Y Bits per raster image point = B Number of CLUT entries = C Location of CLUT (Colour Look-up Table) Image body Length 1 1 1 1 2 K
Bits per raster image point: Contents: The number B of bits used to encode references into the CLUT, thus defining a raster image point's colour. B shall have a value between 1 and 8. Coding: Binary.
Number of entries in CLUT: Contents: The number C of entries in the CLUT which may be referenced from inside the image body. CLUT entries are numbered from 0 to C-1. C shall have a value between 1 and 2**B. Coding: Binary. The value 0 shall be interpreted as 256.
Location of CLUT: Contents: This item specifies where the CLUT for this image instance may be found. The CLUT is always located in the same transparent file as the image instance data themselves, at an offset determined by these two bytes. Coding: Byte 1: high byte of offset into Image Instance File. Byte 2: low byte of offset into Image Instance File.
Image body: Coding: Each raster image point uses B bits to reference one of the C CLUT entries for this image instance. The CLUT entry being thus referenced yields the raster image point's colour. The image body is arrayed as for the Basic Colour Image Coding Scheme, that is, starting with the highest bit of the first raster image point's colour information.
3GPP
Release 1999
151
Byte 1:
b8 b7 b6 b5 b4 b3 b2 b1 ... etc ... etc ... etc ... etc ... etc Bit B-2 of raster point 1 CLUT reference Bit B-1 of raster point 1 CLUT reference Bit B (MSB) of raster point 1 CLUT reference
etc. Unused bits shall be set to 1. The CLUT (Colour Look-up Table) for an image instance with C colours is defined as follows: Contents: C CLUT entries defining one colour each. Coding: The C CLUT entries are arranged sequentially:
Byte(s) of CLUT 1-3 ... 3*(C-1) +1 to 3*C CLUT Entry entry 0 ... Entry C-1
Each CLUT entry in turn comprises 3 bytes defining one colour in the red-green-blue colour space:
Byte(s) of CLUT enty 1 2 3 Intensity of Colour Red Green Blue
A value of 'FF' means maximum intensity, so the definition 'FF' '00' 00' stands for fully saturated red. NOTE 1: Two or more image instances located in the same file can share a single CLUT. NOTE 2: Most MEs capable of displaying colour images are likely to support at least a basic palette of red, green, blue and white.
3GPP
Release 1999
152
Annex H (normative): Coding of EFs for NAM and GSM-AMPS Operational Parameters
If the EIA/TIA-553 DF is provisioned on the SIM, then EFs specified in this annex and indicated as mandatory under the DF shall be provided. TIA/EIA-41 [40] based radio access systems should use this DF for storage of NAM parameters. All quantities shown in the EF descriptions abide by the following rules unless otherwise specified: all unused bits of allocated parameters shall be set by default to 0; all unused bytes in a series of values (e.g. Partner, Favoured, or Forbidden SID List) should be set by default to 'FF'.
H.1
The MIN field is coded as follows: 6 most significant bits are unused; next 10 bits are MIN2; 24 least significant bits are MIN1; default MIN is '00 00 00 00 00' or 'FF FF FF FF FF'. In either case the ME shall interpret this as an invalid MIN and shall not transmit this value over the radio interface.
3GPP
Release 1999
153
H.1.2 EF
ACCOLC
This file contains the Access Overload Class (ACCOLC). The ACCOLC is a 4-bit indicator used to identify which overload class field controls the access attempts by the mobile station. See EIA/TIA-553 [41] for further details on ACCOLC.
Identifier: '4F89' File size: 1 byte Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 Description ACCOLC (possible values from '00' to '0F') CHV1 CHV2 ADM ADM M/O M Length 1 byte Structure: transparent Update Activity: low Mandatory
Byte 1:
b8 b7 b6 b5 b4 b3 b2 b1 ACCOLC Set to 0
This file contains the system identity of the home system. The SID is a 15-bit number that uniquely identifies an AMPS or TIA/EIA-41 system. See EIA/TIA-553 [41] for further details on Home SID.
Identifier: '4F80' File size: 2 bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1-2 Description System ID of Home System (SID) ( Most significant bit = 0) CHV1 CHV2 ADM ADM M/O M Length 2 bytes Structure: transparent Update Activity: low Mandatory
3GPP
Release 1999
154
The Initial (First) Paging Channel contains two 11-bit first paging channels (FIRSTCHP p-pri and FIRSTCHP p-sec) used to identify the channel number of the first paging channel when the mobile station is 'home'. See EIA/TIA-553 [41] for further details on First (Initial) Paging Channel.
Identifier: '4F82' File size: 2-4 bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1-2 34 Description FIRSTCHPpri (Initial Paging Channel) FIRSTCHPp-sec CHV1 CHV2 ADM ADM M/O M O Length 2 bytes 2 bytes Structure: transparent Update Activity: low Mandatory
In the absence of the FIRSTCHPp-sec, the mobile station shall default to '02C4' if the primary channel = '014D' or '02E1' if the primary channel = '014E' A file size of 4 bytes may not be backwards compatible with the current dual-mode mobile equipment
The default of FISRTCHPpri value shall be '014D' for A systems, or '014E' for B systems.
This file defines a subset of the most significant bits of the system identification (SID) that is used to identify a group of cellular systems for local control purposes. If the local control option is enabled within the mobile station and the bits of the home system identification that comprise the group identification match the corresponding bits of the SID read by the mobile station over the air, then the Local Control status shall be enabled. Otherwise, the Local Control status shall be disabled. Refer to EIA/TIA-553 [41] for additional details.
Identifier: '4F81' File size: 1 byte Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 Description Group ID CHV1 CHV2 ADM ADM M/O M Length 1 byte Structure: transparent Update Activity: low Mandatory
3GPP
Release 1999
155
H.1.6 EF
S-ESN
This file stores a 32-bit electronic serial number (ESN) that is unique to the GSM-ANSI-136 SIM. The S-ESN can be unrelated to the ESN of any host equipment to which the GSM-ANSI-136 SIM may be attached. The S-ESN can be used for registration in conjunction with the MIN. The S-ESN may also be used in conjunction with the A-key and CAVE algorithm for authentication. See the ANSI-136 Usage Indicator file for details on the ESN usage indicator which specifies to the mobile equipment how the S-ESN should be used. See EIA/TIA-553 [41] for details on the ESN as it applies to registration and authentication. The contents of this EF shall not be changed by any over-the-air procedures.
Identifier: '4F8B' File size: 4 bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 14 Description SIM ESN CHV1 NEVER ADM ADM M/O M Length 4 bytes Structure: transparent Update Activity: low Mandatory
Byte 1
Byte 2
Byte 3
Manufacturer Code
H.1.7 EF
COUNT
(Call Count)
This file contains the CALL COUNT parameter. The CALL COUNT is used as a simple 'clone' detector in TIA/EIA136 and AMPS modes. During the network access signalling in AMPS and other TIA/EIA-41 based networks, the SIM reports its CALL COUNT value to the network. If the value is consistent with the network perception of the CALL COUNT for that SIM, then the network will likely grant access based on the authentication process. During an AMPS or other TIA/EIA-41 based systems call, the value of the CALL COUNT may be incremented upon a command from the network. The value of the CALL COUNT, when incremented, is incremented by 1 using the INCREASE command. See EIA/TIA-553 [41] for further details on COUNTs-p.
Identifier: '4F83' File size: 3*N bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE CHV1 ADM ADM ADM Structure: Cyclic Update Activity: high Mandatory
3GPP
Release 1999 Bytes Most Recent Record --Rec N ... Description CALL COUNT
156
H.1.8 EF
PSID
This file contains a list of Favoured SIDs for use in identifying Favoured service providers while performing network selection (intelligent roaming).
Identifier: '4F85' File size: 2*N bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 12 (2N-1) (2N) Description Favoured SID 1 Favoured SID 2 Favoured SID N CHV1 ADM ADM ADM M/O M O O Length 2 bytes 2 bytes Structure: transparent Update Activity: low Optional
EOF (End of File) is indicated by 'FFFF'. An entry with all zeros is considered filler. The most significant bit of the Favoured SID field is not used and it is set to 0. Coding of the Favoured SID field (2-byte coding) The default value in the first two bytes shall be 'FFFF'. Byte 1:
b8 b7 b6 b5 b4 b3 b2 b1 : : : : : : MS bit of Favoured SID Set to 0
3GPP
Release 1999
157
Byte 2:
b8 b7 b6 b5 b4 b3 b2 b1 LS bit of Favoured SID : : : : : : :
H.1.9 EF
NSID
This file contains a list of Forbidden SIDs, for use in identifying Forbidden service providers while performing network selection (intelligent roaming).
Identifier: '4F84' File size: 2*N bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 12 (2N-1) (2N) Description Forbidden SID 1 Forbidden SID 2 Forbidden SID N CHV1 ADM ADM ADM M/O M O O Length 2 bytes 2 bytes Structure: transparent Update Activity: low Optional
EOF (End of File) is indicated by 'FFFF.' An entry with all zeros is considered filler. The most significant bit of the Forbidden SID field is not used and it is set to 0. Coding of the Forbidden SID field (2-byte coding) The default value in the first two bytes shall be 'FFFF'. Byte 1:
b8 b7 b6 b5 b4 b3 b2 b1 : : : : : :
3GPP
Release 1999
158
Byte 2:
b8 b7 b6 b5 b4 b3 b2 b1
H.1.10 EF
SPL
This file contains the Scanning Priority List. The Scanning Priority List is an array that defines the various types of systems that can be found. It also acts as a reference table, pointing to the various data structures in the SIM. This file is for backwards compatibility with GSM/AMPS mobile equipment. A Mobile Station supporting both TIA/EIA-136 and EIA/TIA-553 [41] is not expected to support this EF for network selection.
Identifier: '4F87' File size: 27 bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 23 25 26 27 Value 9 Pointer 9 M M 1 byte 2 bytes Description Value 1 Pointer 1 CHV1 ADM ADM ADM M/O M M Length 1 byte 2 bytes Structure: transparent Update Activity: low Optional
The position of the pointers is fixed in this file. Highest priority level is 1, lowest priority level is 7. No two entries can have the same priority level with the exception the last two fields (Forbidden PLMNs and Negative SIDs) which both will have a value of 0. Default values are in parentheses. The values 1 or 2 shall reside in the first position (Home PLMN), and the second position (Last registered PLMN) shall contain a higher priority than position 3 (Preferred PLMNs List ) and 4 (Any Other PLMNs).
3GPP
Release 1999
159
Format:
Priority Value 1 7 (2) 1 7 (1) 1 7 (3) 1 7 (6) 1 7 (4) 1 7 (5) 1 7 (7) 0 0 Pointer SIM ('6F07') SIM ('6F7E') SIM ('6F30') 0 SIM ('4F80') SIM ('4F85') 0 SIM ('6F7B') SIM ('4F84') Reserved For Home PLMN Last Registered PLMN Preferred PLMNs List Any Other PLMNs Home SID Positive SIDs List Any Other SIDs Forbidden PLMNs List Negative SIDs List
Constraints on the Priority List: Mandatory PLMN priority order (highest to lowest): Home PLMN or Last Registered PLMN, Preferred PLMNs, Any Other PLMNs Mandatory SID priority order (highest to lowest): Home SID, Positive SIs, Any Other SIDs.
H.1.11 EF
NETSEL
This file contains the Network Selection Activation Flag. This flag is used to enable/disable the Manual Mode and some MMI functionality within the ME.
Identifier: '4F86' File size: 1 byte Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 Description Network Selection Activation Flag CHV1 CHV1 ADM ADM M/O M Length 1 byte Structure: transparent Update Activity: low Mandatory
Enables / disables Manual Mode and some MMI functionality within the ME, in both AMPS and GSM modes. Default value = 05 Hex. Coding: Bit 0 =0 GSM Manual Mode disabled =1 GSM Manual Mode enabled (default) Bit 1 =0 AMPS Manual Mode disabled (default) =1 AMPS Manual Mode enabled Bit 2 =0 Scanning Sequence Flags disabled =1 Scanning Sequence Flags enabled (default)
3GPP
Release 1999
160
Bit 3 =0 Disallow home only AMPS selection (default) =1 Allow home only AMPS selection Bits 4 through 7 are not used and set to zero.
H.1.12 EF
Identifier: '4F8C' File size: 2 bytes
CSID
This file contains the SIDsp value. The most significant bit is unused and set to 0.
Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 -2 Description SIDsp CHV1 CHV1 ADM ADM M/O M Length 2 bytes
H.1.13 EF
REG-THRESH
(Registration Threshold)
This file contains the NXTREGsp value, specified in EIA/TIA-553 [41]. The three most significant bits are unused and are set to 0.
Identifier: '4F8D' File size: 3 bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 13 Description NXTREGsp value CHV1 CHV1 ADM ADM M/O M Length 3 bytes Structure: transparent Update Activity: low Optional
H.1.14 EF
CCCH
This file contains the Current Control Channel information related to the Last Paging Control Channel on which the AMPS phone camped on.
Identifier: '4F8E' Structure: transparent Optional
3GPP
Release 1999
161
File size: 2 bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 12 Description Current Control Channel
H.1.15 EF
Identifier: '4F8F' File size: 1 byte
LDCC
(Latest DCC)
Structure: transparent Update Activity: low Optional
This file contains the DCC value associated with the saved Current Control Channel.
Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 Description DCC (Default value = '00') CHV1 CHV1 ADM ADM M/O M Length 1 byte
H.1.16 EF
GSM-RECON
This file specifies, in seconds, the time the ME should remain scanning the GSM-1900 spectrum, after loss of service from a GSM-1900 system, before any scanning of the AMPS spectrum is allowed.
Identifier: '4F90' File size: 2 bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes Description CHV1 ADM ADM ADM M/O Length Structure: transparent Update Activity: low Optional
3GPP
Release 1999
162
1-2
2 bytes
H.1.17 EF
AMPS-2-GSM
The EF specifies, in minutes, a series of (typically increasing) intervals for scanning the GSM-1900 spectrum, used while in-service on an AMPS network while in Dual-Mode operation. The time is measured from the end of the last GSM-1900 scan to the start of the next GSM-1900 scan. If the table is not completely filled (i.e. the end-of-table value 'FF' is found), the last filled value may be repeated indefinitely. If a value of 'F0' is encountered, the table is terminated, as are all rescans to GSM until the current AMPS system is lost.
Identifier: '4F91' File size: 10 bytes Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 2 3 4 5 6 7 8 9 10 Description
Optional
CHV1 ADM ADM ADM M/O M M M M M M M M M M Length 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte 1 byte
First Rescan Attempt Interval (Default = '02') Second Rescan Attempt Interval (Default = '03') Third Rescan Attempt Interval (Default = '04') Fourth Rescan Attempt Interval (Default = '05') Fifth Rescan Attempt Interval (Default = '06') Sixth Rescan Attempt Interval (Default = 'FF') Seventh Rescan Attempt Interval (Default = 'FF') Eighth Rescan Attempt Interval (Default = 'FF') Ninth Rescan Attempt Interval (Default = 'FF') Tenth Rescan Attempt Interval (Default = 'FF')
H.1.18 EF
Identifier: '4F8A' File size: 2 bytes Access Conditions:
*FC1
This file contains the feature code table as specified in EIA/TIA-553 [41].
3GPP
Release 1999 READ UPDATE INVALIDATE REHABILITATE Bytes 1-2 Description Default value 'B990'.
M/O M
Length 2 bytes
H.1.19 EF
Identifier: 4F93
AMPS-UI
This file contains usage indicators for local control and extended address method.
File size: 2 bytes (minimum) Access Conditions: READ UPDATE INVALIDATE REHABILITATE Bytes 1 2 Description Number of Services (S) Services no1 to no8
-Services: Contents
Local Control Indicator (see Note 1) Extended Address Method indicator included in any access attempts (see Note 2) RFU
Number of Services Contents: This byte refers to the number of services defined in the following byte. Coding: This byte is coded as BCD
Services Contents: This byte describes the services Coding: One bit is used to code each service
3GPP
Release 1999
164
If the bit = 0: service is not enabled If the bit = 1: service is enabled The bits for services not yet defined shall be set to RFU. For coding of RFU see subclause 9.3.
Byte 2:
b8 b7 b6 b5 b4 b3 b2 b1 :Service no1 :Service no2 :Service no3 :Service no4 :Service no5 :Service no6 :Service no7 :service no8
NOTE 1: The Local Control Indicator is a means provided within the mobile station to enable or disable the local control option. Local Control is a mechanism that allows a cellular system to customise operation for home mobile stations, and for those roaming mobile stations whose home systems are members of a group, by sending local orders with the order field set to local control (which informs the mobile station to examine the local control field), and by sending one or both of two local control global action overhead messages. A group of systems could be formed by participating systems agreeing to a common set of local control protocols and whose system identifications (SID) are recognised by mobile stations as a common group. NOTE 2: The Extended Address Method indicator determines if the extended address word must be included in all access attempts.
H.2
Authentication Functionality
H.3
-
Authentication commands
Generation of Authentication Signature data, and generation of ciphering keys. Validation and storage of entered A-Key's
It is necessary to provide six interfaces to the CAVE Algorithm and Secret Data areas, as listed below:
3GPP
Release 1999
165
Ask Random task (generates RANDBS) Update Shared Secret Data (Generates SSD_A_NEW, SSD_B_NEW and AUTHBS values) Confirm Shared Secret Data (Updates SSD values) CMEA Encryption of voice channel data digits NOTE: For each task, the expected normal (i.e. success) status code is listed in the status word description. A list of possible error codes that apply to all tasks can be found in the SIM Status Codes.
The interpretation of these instruction codes (INS in the table below) is valid only for class A0.
CLA 'A0'
INS '88'
P1 '00'
P2 '00'
Lc '0F'
Bit 0 0=RANDs, 1= RANDU Bit 1 Generate Key Bits flag (0= No, 1= Yes) Bit 2 Load Internal key flag: (0= pass all generated key bytes to handset, 1= load first 8 bytes of generated keys internally to SIM, pass all remaining key bytes to ME) Bits 3-7 Bytes 1-4 or Bytes 1-3 Byte 4 Byte 5 RANDU (for Unique Challenge-Response Procedures) = 0 (MIN2 will be filled in by SIM) Digits Length (in bits, =0, 4, 8, 12, 16, 20 or 24, Unused, future expansion RANDs (for Registrations, Originations, and Terminations)
3GPP
Release 1999
166
Bytes 6-8 =0,0,0 (for Registrations, Terminations, Unique Challenge Response Procedures) = Last Dialed Digits, unused bits filled with 0's (for Originations). If more than 6 digits are dialed, these are the last 6 digits in the origination string. If less than 6 digits are dialed, MIN1 will be filled in by the SIM for the unused bits. Byte 9 Use ME ESN (='00')
Bytes 10-13 ESN Byte 14 Key_size (=0 if Byte 0, Bit 1= 0, =8 (or more) if Byte 0, Bit 1 = 1)
The output of this task shall be: Status Bytes: SW1 (='9F' if success) SW2 (='nn' if success) ('nn' is 03+Key_size if Byte 0, Bit 2 above =0, 03+Key_size-08 if Byte 0, Bit 2 above =1)
Coding: Bytes 0 - 12 Authentication digits string (first digit in Most-Significant nibble of byte 0, last digit in Least-Significant nibble of Byte 12, for a total of 26 digits) Byte 13 Use ME ESN (='00')
Bytes 14-17 ESN The output of this task shall be: Status Bytes: SW1 (='90' if success) SW2 (='00' if success)
CLA 'A0'
INS '8A'
P1 '00'
P2 '00'
Lc '04'
Coding: Bytes 0-3 RANDSeed The output of this task shall be:
3GPP
Release 1999
167
Coding: Bytes 0-6 Byte 7 Bytes 8-11 RANDSSD Use ME ESN (='00') ESN
The output of this task shall be: Status Bytes: SW1 (='90' if success, ='98' if failure) SW2 (='00' if success, ='04' if failure)
Coding: Bytes 0-2 AUTHBSs The output of this task shall be: Status Bytes: SW1 (='90' if success) SW2 (='00' if success)
3GPP
Release 1999
168
Bytes 0 - (n-1)
The output of this task shall be: Status Bytes: SW1 (='9F' if success) SW2 (='nn' if success) ('nn' is hex value of data length n)
Error Codes: 92, 40 94, 08 98, 04 98, 34 67, xx 6B, xx 6D, xx 6E, xx 6F, xx 6F, 00 Error, memory problem Error, file is inconsistent with the command Error, no CHV1 has been presented successfully Error, Update SSD order sequence not respected (should be used if SSD Update commands are received out of sequence). Error, incorrect parameter P3 (ISO code) Error, incorrect parameter P1 or P2 (ISO code) Error, unknown instruction code given in the command (ISO code) Error, wrong instruction class given in the command (ISO code) Error, technical problem with no diagnostic given (ISO code) Error, invalid input parameters to authentication computation
3GPP
Release 1999
169
3GPP
Release 1999
170
File identification '2F05' '2FE2' '4F20' '4Fxx' '6F05' '6F07' '6F20' '6F2C' '6F30' '6F31' '6F32' '6F37' '6F38' '6F39' '6F3A' '6F3B' '6F3C' '6F3D' '6F3E' '6F3F' '6F40' '6F41' '6F42' '6F43' '6F44' '6F45' '6F46' '6F47' '6F48' '6F49' '6F4A' '6F4B' '6F4C' '6F4D' '6F4E' '6F50' '6F51' '6F52' '6F53' '6F58' '6F60' '6F61' '6F62' '6F63' '6F64' '6F74' '6F78' '6F7B' '6F7E' '6FAD' '6FAE'
Description
Extended Language preference ICC identification Image data Image Instance data Files Language preference IMSI Ciphering key Kc De-personalization Control Keys PLMN selector Higher Priority PLMN search period Co-operative network ACM maximum value SIM service table Accumulated call meter Abbreviated dialling numbers Fixed dialling numbers Short messages Capability configuration parameters Group identifier level 1 Group identifier level 2 MSISDN storage PUCT SMS parameters SMS status Last number dialled CBMI Service provider name Short message status reports CBMID Service Dialling Numbers Extension 1 Extension 2 Extension 3 Barred dialling numbers Extension 4 CBMIR Network's indication of alerting GPRS Ciphering key KcGPRS GPRS Location Information Comparison method information User controlled PLMN Selector with Access Technology Operator controlled PLMN Selector with Access Technology HPLMN Selector with Access Technology CPBCCH information Investigation scan BCCH information Access control class Forbidden PLMNs Location information Administrative data Phase identification
Change advised Yes No Yes Yes Yes Caution (note) No Caution Caution Caution Caution Yes Caution Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Caution Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Caution No Caution
see 3GPP TS 22.011 Caution Caution
Continued.....
3GPP
Release 1999
171
File identification Description Change advised Voice Group Call Service '6FB1' Yes Voice Group Call Service Status '6FB2' Yes Voice Broadcast Service '6FB3' Yes Voice Broadcast Service Status '6FB4' Yes Enhanced Multi Level Pre-emption and Priority '6FB5' Yes Automatic Answer for eMLPP Service '6FB6' Yes Emergency Call Codes '6FB7' Caution NOTE: If EFIMSI is changed, the SIM should issue REFRESH as defined in TS 11.14 [27] and update EFLOCI accordingly.
3GPP
Release 1999
172
s16 s17
709/95 154/95 4.15.0 A008 R96 1 SIM Speed Enhancement 5.0.0 062/96 147/95 5.0.0 A006 R96 B Service Dialling Numbers 5.1.0 060/96 06/96 A009 R96 B ASCI for VGCS and VBS 060/96 06/96 A010 R96 B ASCI for eMLPP 059/96 204/95r A013 R96 C Interaction between FDNs and ADNs 061/96 05/96 A014 R96 D Correction of baud rate for SIM Speed enhancement s18 263/96 57/96 5.1.0 A011 3 R96 B SIM Application Toolkit protocol enhancements 5.2.0 260/96 45/96 A016 R96 A SIM presence detection clarification 261/96 54/96 A018 R96 A Reponse codes and coding of SIM service table 262/96 55/96 A020 R96 A Reference to International Standards s19 374/96 102/96 5.2.0 A012 R96 C Contacting elements 5.3.0 373/96 105/96 A023 R96 A Clarification of clock stop timing 409/96 107/96 A024 1 R96 B Emergency Call Codes (ECC) 374/96 108/96 A025 R96 C Using ranges of CBMIs s20 580/96 206/96 5.3.0 A021 R96 B Barred Dialling Numbers 5.4.0 734/96 197/96 A026 R96 B Addition of Cooperative Network List EF 734/96 197/96 A027 R96 B Addition of ME Depersonalisation feature and EF 702/96 207/96 A031 R96 D RFU bit taken into use in GSM 11.12 s21 101/97 97/079 5.4.0 A032 2 R96 D Ammendment to BDN diagrams in Annex B 5.5.0 101/97 97/086 A033 1 R96 B DFs for MSS/ PCS1900/other use 101/97 97/056 A034 R96 C Reading of EFDCK during SIM initialisation 101/97 97/058 A036 R96 D Administrative Access Conditions 101/97 97/059 A037 R96 B Format of EFCNL to include fields for Corporate Personal. Code 101/97 97/089 A041 R96 B Administrative Data field s22 356/97 183/97 5.5.0 A042 R97 B Extended language preference 5.6.0 356/97 163/97 A044 1 R96 A Clarification of electrical/mechanical SIM/ME interface 356/97 179/97 A045 R96 D Security procedures for 2nd level; DFs located under DF GSM 356/97 187/97 A047 R96 F Number of bytes returned after a SELECT command 356/97 093/97 A048 R96 D Serivce table and "radio interface" 356/97 109/97 A049 R96 F Update Access condition of EFDCK (aligns 11.11 & 02.22) s23 788/97 97/249 5.6.0 A046 2 R97 B Short Message Status Reports 5.7.0 788/97 97/243 A050 R96 F Addition of SDN and BDN in the description of EFCCP 788/97 97/259 A051 1 R97 C SIM and ME behaviour when SIM is disabled and blocked 788/97 97/262 A053 R96 F Response data following an ENVELOPE command 788/97 97/260 A054 R96 F Coding of EFPhase 788/97 97/271 A055 R97 C Changes to Dialling Number Files and extensions 788/97 97/261 A056 R97 B Network's indication of alerting in the MS s24 97-0886 97/365 5.7.0 A052 2 R97 b Introduction of UCS2 5.8.0 97-0886 97/383 A057 R97 c MO SMS control by SIM At SMG #25, it was decided to create a version 6.0.0 of every specification that contained at least one release '97 work item and a version 7.0.0 of every specification that contained at least one release '98 work item. s25 98-0157 98p052 5.8.0 A058 2 R97 B Addition of EFs for GPRS 6.0.0 98-0157 98p108 A059 R97 F Clarification regarding EFCCP records 98-0157 98p094 A061 1 R96 A Clarification of removal of the SIM s26 98-0398 98p228 6.0.0 A062 2 R98 B Icons - addition of EF IMG and DF GRAPHICS 7.0.0 98-0398 98p227 A064 R98 B Operation of ME with multiple card readers 98-0400 98p237 A065 R98 F Deletion of all release 97 markers from the R98 version 98-0398 98p240 A066 R97 F RP-ACK RP-ERROR for SIM data download error 98-0398 98p263 A069 R97 D Allocation of file ID for IS-41 (continued)
3GPP
Release 1999
173
3GPP
Release 1999
Meet ing Plenary tdoc WG tdoc VERS CR RV Rel- CAT ease
174
s27 s28
s29
s30
s31
s32
98-0671 98-0671 P-99-185 P-99-185 P-99-185 P-99-185 P-99-185 P-99-185 P-99-185 P-99-188 P-99-412 P-99-412 P-99-412 P-99-670 P-99-670 P-99-670 P-99-670 P-99-670 P-99-670 P-99-670 P-99-670 P-00-137 P-00-137 P-00-137 P-00-137 P-00-137 P-00-137 P-00-137 P-00-137 P-00-137 P-00-139 P-00-139 P-00-296 P-00-296 P-00-296 P-00-296
98p339 9-99-076 9-99-037 9-99-066 9-99-095 9-99-072 9-99-093 9-99-097 9-99-163 9-99-180 9-99-208 9-99-260 9-99-277 9-99-281 9-99-294 9-99-310 9-99-300 9-99-311 9-99-258 9-00-0088 9-00-0092 9-00-0095 9-00-0098 9-00-0133 9-00-0146 9-00-0151 9-00-0163 9-00-0155 9-00-0161 9-00-0159 9-00-0232 9-00-0276 9-00-0275 9-00-0273
7.0.0 7.1.0
7.2.0
8.0.0
8.1.0
8.2.0
A071 A072 A073 A074 A075 A076 A077 A078 A080 A082 A083 A084 A085 A089 A090 A091 A092 A093 A094 A095 A097 A098 A101 A104 A107 A108 A109 A110 A111 A112 A113 A114 A120 A122 A123 A124
1 1 1 1
1 1
R98 R98 R98 R98 R98 R98 R98 R98 R98 R98 R98 R98 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99 R99
C D F B B B C B C D C F C A D F B F F B A F F F F F F D B B B B B C A F
Enhanced image coding schemes (colour icons) Addition of reference to PCS 1900 Alignment with 2nd edition of ISO/IEC 7816-3 (1997) Addition of SoLSA data fields Addition of CTS fields Definition of a file containing the title of the main menu USSD format indication in the SIM Service Table Informative annex on EF changes Additional GPRS field Deletion of $(.......)$ release markers EF IMSI changes via data download or SIM toolkit application Addition of RUN AT COMMAND to the SIM service table Alignment of maximum of records in a linear fixed file in GSM 11.11 with ISO/IEC 7816-4 Correction for coding of SoLSA "Priority" field Clarification of the Ciphering Indicator disable bit in the EFad File on the SIM Introduction of a new DF for the TIA/EIA-136 technology Addition of EF definitions under the PCS 1900 DF Clarification about "Memory Problem" error for EFLOCI update Execution time of SIM toolkit procedures Introduction of a new DF for the TIA/EIA-95 technology Clarification of Optional Status for GPRS files Clarification of interactions for CBS and the language files on the SIM to coding of ASCI EF eMLPP. Correction Addition of coding for ASCI Efs (VGCS and VBS) Correction of the byte numbering related to EF LOCIGPRS Corrections and additions to DF-5F40 Clarification of manual entry of the A-Key. Addition of reference to the File ID as used in the TETRA specification. COMPACT Cell Selection COMPACT Cell Selection - Investigation Scan indicator for packet only systems Enhancement to CCP coding (CR number incorrect in P-00139) Enhancement of BDN feature (CR number incorrect in P-00139) DFs for MExE HPLM length LAI, RAI and CNL : alignment with GSM 04.08 PLMN Selection Corrections regarding RFU bits
7.1.0 7.2.0
8.0.0
8.1.0
8.2.0
8.3.0
Following the closure of ETSI SMG and the agreement of the 3GPP in July 2000 to undertake responsibility for remaining GSM specifications, the change requests listed below were approved by 3GPP TSG-T. This change in responsibility also changed the specification number from "GSM 11.11" to "3GPP TS 11.11". TP-09 TP-000176 TP-000176 TP-000148 TP-11 TP-010038 TP-010038 TP-14 TP-010244 TP-16 TP-020167 9-00-0253 9-00-0269 T3-000479 T3-010047 T3-010045 T3-010743 T3-020427 8.3.0 A116 A119 A126 A127 A128 A130 A131 A132 A133 R99 R99 R99 R99 R99 R99 R99 F C F F F F F PLMN Selection Corrections and additions for EDGE Addition of RPLMN file Standardise the current GAIT commands and reserving these CLA/INSof codes Addition file ID for indicating iDEN access technology Correction to default HPLMN RAT Corrections The identifier of EFRPLMNAcT (RPLMN Last used Access Technology) is inconsistent within the specification Inconsistent record length of EF(IMG) Essential corrections file size and record lengths in several EFs Editorial changes to the ranges of bytes within the file as concluded at T3#25. Removal of comments in clause 11 as given in action AP9/26 to the secretary at T3#26. Correction to SMS CR to delete Elementary File EFRPLMNAcT, in accordance with TP-020168 from TP#16 in Marco Island. Correction to procedures for service no 21, 22 and 23 Alignment of EF-HPLMN Search Period with 22.011 and 23.122 8.4.0
R99 F R99 F
8.9.0 TP-21 TP-030177 T3-030652 8.9.1 TP-030186 T3-030725 A135 A136 R99 F R99 F R99 F R99 F R99 F R99 F R99 F
8.9.1 8.10.0
TP-22 TP-030247 T3-030948 8.10.0 A137 TP-030304 A138 TP-23 TP-040029 TP-040129 8.110 A139
8.11.0
CP-28 CP-050136 C6-050367 8.12.0 A140 CP-28 CP-050136 C6-050488 8.12.0 A141
Correction of image instance descriptor for colour icons ISO/IEC 7816-series revision ISO/IEC 7811-Series Revision
3GPP
Release 1999
CP-36 CP-070286 C6-070309 8.13.0 A142 1 R99 F
175
3GPP