3GPP TS 31.102
3GPP TS 31.102
3GPP TS 31.102
3GPP TS 31.102
Technical Specification Group Core Network and Terminals;
V15.21.0 (2018-0610)
Characteristics of the
Universal Subscriber Identity Module (USIM) application
Technical Specification
(Release 15)
The present document has been developed within the 3rd 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 15 2 3GPP TS 31.102 V15.21.0 (2018-0610)
Keywords
UMTS, SIM, card, LTE
3GPP
Postal address
Internet
http://www.3gpp.org
Copyright Notification
© 2018, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).
All rights reserved.
UMTS™ is a Trade Mark of ETSI registered for the benefit of its members
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
LTE™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
GSM® and the GSM logo are registered and owned by the GSM Association
3GPP
Release 15 3 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents
Foreword...................................................................................................................................................12
Introduction...............................................................................................................................................12
1 Scope...............................................................................................................................................13
2 References.......................................................................................................................................13
3 Definitions, symbols, abbreviations and coding conventions.........................................................17
3.1 Definitions.................................................................................................................................................17
3.2 Symbols.....................................................................................................................................................18
3.3 Abbreviations............................................................................................................................................18
3.4 Coding Conventions..................................................................................................................................20
4 Contents of the Files.......................................................................................................................20
4.1 Contents of the EFs at the MF level..........................................................................................................20
4.2 Contents of files at the USIM ADF (Application DF) level.....................................................................21
4.2.1 EFLI (Language Indication).................................................................................................................21
4.2.2 EFIMSI (IMSI).......................................................................................................................................22
4.2.3 EFKeys (Ciphering and Integrity Keys).................................................................................................23
4.2.4 EFKeysPS (Ciphering and Integrity Keys for Packet Switched domain)................................................23
4.2.5 EFPLMNwAcT (User controlled PLMN selector with Access Technology).............................................24
4.2.6 EFHPPLMN (Higher Priority PLMN search period)................................................................................25
4.2.7 EFACMmax (ACM maximum value).......................................................................................................26
4.2.8 EFUST (USIM Service Table)...............................................................................................................28
4.2.9 EFACM (Accumulated Call Meter)........................................................................................................31
4.2.10 EFGID1 (Group Identifier Level 1)........................................................................................................31
4.2.11 EFGID2 (Group Identifier Level 2)........................................................................................................32
4.2.12 EFSPN (Service Provider Name)...........................................................................................................32
4.2.13 EFPUCT (Price per Unit and Currency Table).......................................................................................33
4.2.14 EFCBMI (Cell Broadcast Message identifier selection).........................................................................34
4.2.15 EFACC (Access Control Class)..............................................................................................................35
4.2.16 EFFPLMN (Forbidden PLMNs)...............................................................................................................35
4.2.17 EFLOCI (Location Information).............................................................................................................36
4.2.18 EFAD (Administrative Data).................................................................................................................37
4.2.19 Void.....................................................................................................................................................39
4.2.20 EFCBMID (Cell Broadcast Message Identifier for Data Download).......................................................39
4.2.21 EFECC (Emergency Call Codes)...........................................................................................................40
4.2.22 EFCBMIR (Cell Broadcast Message Identifier Range selection)............................................................41
4.2.23 EFPSLOCI (Packet Switched location information)................................................................................41
4.2.24 EFFDN (Fixed Dialling Numbers).........................................................................................................43
4.2.25 EFSMS (Short messages).......................................................................................................................43
4.2.26 EFMSISDN (MSISDN).............................................................................................................................45
4.2.27 EFSMSP (Short message service parameters).........................................................................................45
4.2.28 EFSMSS (SMS status).............................................................................................................................47
4.2.29 EFSDN (Service Dialling Numbers).......................................................................................................47
4.2.30 EFEXT2 (Extension2).............................................................................................................................48
4.2.31 EFEXT3 (Extension3).............................................................................................................................48
4.2.32 EFSMSR (Short message status reports).................................................................................................49
4.2.33 EFICI (Incoming Call Information)......................................................................................................49
4.2.34 EFOCI (Outgoing Call Information)......................................................................................................53
4.2.35 EFICT (Incoming Call Timer)...............................................................................................................54
4.2.36 EFOCT (Outgoing Call Timer)..............................................................................................................54
4.2.37 EFEXT5 (Extension5).............................................................................................................................55
4.2.38 EFCCP2 (Capability Configuration Parameters 2).................................................................................55
4.2.39 EFeMLPP (enhanced Multi Level Precedence and Pre-emption)............................................................56
4.2.40 EFAaeM (Automatic Answer for eMLPP Service).................................................................................57
4.2.41 Void.....................................................................................................................................................58
4.2.42 EFHiddenkey (Key for hidden phone book entries)...................................................................................58
3GPP
Release 15 4 3GPP TS 31.102 V15.21.0 (2018-0610)
4.2.43 Void.....................................................................................................................................................58
4.2.44 EFBDN (Barred Dialling Numbers).......................................................................................................58
4.2.45 EFEXT4 (Extension4).............................................................................................................................59
4.2.46 EFCMI (Comparison Method Information)...........................................................................................59
4.2.47 EFEST (Enabled Services Table)...........................................................................................................60
4.2.48 EFACL (Access Point Name Control List)............................................................................................60
4.2.49 EFDCK (Depersonalisation Control Keys)............................................................................................61
4.2.50 EFCNL (Co-operative Network List).....................................................................................................61
4.2.51 EFSTART-HFN (Initialisation values for Hyperframe number).................................................................63
4.2.52 EFTHRESHOLD (Maximum value of START)..........................................................................................63
4.2.53 EFOPLMNwACT (Operator controlled PLMN selector with Access Technology).....................................63
4.2.54 EFHPLMNwAcT (HPLMN selector with Access Technology)...................................................................64
4.2.55 EFARR (Access Rule Reference)...........................................................................................................65
4.2.56 Void.....................................................................................................................................................66
4.2.57 EFNETPAR (Network Parameters)...........................................................................................................66
4.2.58 EFPNN (PLMN Network Name)...........................................................................................................68
4.2.59 EFOPL (Operator PLMN List)...............................................................................................................69
4.2.60 EFMBDN (Mailbox Dialling Numbers)..................................................................................................70
4.2.61 EFEXT6 (Extension6).............................................................................................................................71
4.2.62 EFMBI (Mailbox Identifier)...................................................................................................................71
4.2.63 EFMWIS (Message Waiting Indication Status)......................................................................................71
4.2.64 EFCFIS (Call Forwarding Indication Status).........................................................................................73
4.2.65 EFEXT7 (Extension7).............................................................................................................................74
4.2.66 EFSPDI (Service Provider Display Information)...................................................................................74
4.2.67 EFMMSN (MMS Notification)................................................................................................................75
4.2.68 EFEXT8 (Extension 8)............................................................................................................................77
4.2.69 EFMMSICP (MMS Issuer Connectivity Parameters)................................................................................77
4.2.70 EFMMSUP (MMS User Preferences).......................................................................................................80
4.2.71 EFMMSUCP (MMS User Connectivity Parameters).................................................................................81
4.2.72 EFNIA (Network's Indication of Alerting)............................................................................................81
4.2.73 EFVGCS (Voice Group Call Service).....................................................................................................82
4.2.74 EFVGCSS (Voice Group Call Service Status).........................................................................................84
4.2.75 EFVBS (Voice Broadcast Service).........................................................................................................84
4.2.76 EFVBSS (Voice Broadcast Service Status)............................................................................................86
4.2.77 EFVGCSCA (Voice Group Call Service Ciphering Algorithm)...............................................................87
4.2.78 EFVBSCA (Voice Broadcast Service Ciphering Algorithm)...................................................................88
4.2.79 EFGBABP (GBA Bootstrapping parameters)..........................................................................................88
4.2.80 EFMSK (MBMS Service Keys List)......................................................................................................89
4.2.81 EFMUK (MBMS User Key)...................................................................................................................90
4.2.82 Void.....................................................................................................................................................91
4.2.83 EFGBANL (GBA NAF List)....................................................................................................................91
4.2.84 EFEHPLMN (Equivalent HPLMN)...........................................................................................................92
4.2.85 EFEHPLMNPI (Equivalent HPLMN Presentation Indication)...................................................................92
4.2.86 EFLRPLMNSI (Last RPLMN Selection Indication)..................................................................................93
4.2.87 EFNAFKCA (NAF Key Centre Address)..................................................................................................93
4.2.88 EFSPNI (Service Provider Name Icon)..................................................................................................94
4.2.89 EFPNNI (PLMN Network Name Icon)..................................................................................................95
4.2.90 EFNCP-IP (Network Connectivity Parameters for USIM IP connections).............................................95
4.2.91 EFEPSLOCI (EPS location information)...................................................................................................98
4.2.92 EFEPSNSC (EPS NAS Security Context)..............................................................................................100
4.2.93 EFUFC (USAT Facility Control)......................................................................................................102
4.2.94 EFNASCONFIG (Non Access Stratum Configuration).............................................................................102
4.2.95 EFUICCIARI (UICC IARI)......................................................................................................................106
4.2.96 EFPWS (Public Warning System)........................................................................................................107
4.2.97 EFFDNURI (Fixed Dialling Numbers URI)...........................................................................................107
4.2.98 EFBDNURI (Barred Dialling Numbers URI).........................................................................................108
4.2.99 EFSDNURI (Service Dialling Numbers URI)........................................................................................109
4.2.100 EFIWL (IMEI(SV) White Lists)..........................................................................................................110
4.2.101 EFIPS (IMEI(SV) Pairing Status).......................................................................................................111
4.2.102 EFIPD (IMEI(SV) of Pairing Device).................................................................................................112
4.2.103 EFePDGId (Home ePDG Identifier).......................................................................................................113
3GPP
Release 15 5 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 6 3GPP TS 31.102 V15.21.0 (2018-0610)
4.4.6.1 Introduction.................................................................................................................................159
4.4.6.2 EFACSGL (Allowed CSG Lists)......................................................................................................159
4.4.6.3 EFCSGT (CSG Type)......................................................................................................................162
4.4.6.4 EFHNBN (Home NodeB Name)......................................................................................................164
4.4.6.5 EFOCSGL (Operator CSG Lists)......................................................................................................164
4.4.6.6 EFOCSGT (Operator CSG Type).....................................................................................................166
4.4.6.7 EFOHNBN (Operator Home NodeB Name).....................................................................................167
4.4.7 Void...................................................................................................................................................167
4.4.8 Contents of files at the DF ProSe level.............................................................................................167
4.4.8.1 Introduction.................................................................................................................................167
4.4.8.2 EFPROSE_MON (ProSe Monitoring Parameters)................................................................................167
4.4.8.3 EFPROSE_ANN (ProSe Announcing Parameters)..............................................................................168
4.4.8.4 EFPROSEFUNC (HPLMN ProSe Function)........................................................................................169
4.4.8.5 EFPROSE_RADIO_COM (ProSe Direct Communication Radio Parameters)..........................................170
4.4.8.6 EFPROSE_RADIO_MON (ProSe Direct Discovery Monitoring Radio Parameters)................................172
4.4.8.7 EFPROSE_RADIO_ANN (ProSe Direct Discovery Announcing Radio Parameters)...............................173
4.4.8.8 EFPROSE_POLICY (ProSe Policy Parameters).....................................................................................174
4.4.8.9 EFPROSE_PLMN (ProSe PLMN Parameters)......................................................................................176
4.4.8.10 EFPROSE_GC (ProSe Group Counter)...............................................................................................177
4.4.8.11 EFPST (ProSe Service Table)........................................................................................................179
4.4.8.12 EFPROSE_UIRC (ProSe UsageInformationReportingConfiguration).................................................179
4.4.8.12 EFPROSE_GM_DISCOVERY (ProSe Group Member Discovery Parameters)...........................................183
4.4.8.13 EFPROSE_RELAY (ProSe Relay Parameters)......................................................................................184
4.4.8.14 EFPROSE_RELAY_DISCOVERY (ProSe Relay Discovery Parameters)......................................................185
4.4.9 Contents of files at the DF ACDC level............................................................................................188
4.4.9.1 Introduction.................................................................................................................................188
4.4.9.2 EFACDC_LIST (ACDC List)..............................................................................................................188
4.4.9.3 EFACDC_OS_CONFIG (ACDC OS configuration).................................................................................189
4.4.10 Contents of files at the DF TV level.................................................................................................190
4.4.10.1 Introduction.................................................................................................................................190
4.4.10.2 EFTVUSD (TV User Service Description).......................................................................................190
4.4.11 Contents of files at the DF5GS level....................................................................................................191
4.4.11.1 Introduction.................................................................................................................................191
4.4.11.2 EF5GS3GPPLOCI (5GS 3GPP location information)...........................................................................191
4.4.11.3 EF5GSN3GPPLOCI (5GS non-3GPP location information)..................................................................193
4.4.11.4 EF5GS3GPPNSC (5GS 3GPP Access NAS Security Context)............................................................193
4.4.11.5 EF5GSN3GPPNSC (5GS non-3GPP Access NAS Security Context)...................................................195
4.4.11.6 EF5GAUTHKEYS (5G authentication keys).........................................................................................196
4.4.11.7 EFUAC_AIC (UAC Access Identities Configuration)............................................................................197
4.4.11.8 EFSUCI_Calc_Info (Subscription Concealed Identifier Calculation Information EF)................................197
4.4.11.9 EFSteering_of_UE_in_VPLMN (Steering of UE in VPLMN)............................................................................199
4.5 Contents of Efs at the TELECOM level.................................................................................................200
4.5.1 EFADN (Abbreviated dialling numbers)..............................................................................................200
4.5.2 EFEXT1 (Extension1)...........................................................................................................................200
4.5.3 EFECCP (Extended Capability Configuration Parameter)...................................................................200
4.5.4 EFSUME (SetUpMenu Elements).........................................................................................................201
4.5.5 EFARR (Access Rule Reference).........................................................................................................201
4.5.6 EFICE_DN (In Case of Emergency – Dialling Number).......................................................................201
4.5.7 EFICE_FF (In Case of Emergency – Free Format)................................................................................202
4.5.8 EFRMA (Remote Management Actions)..............................................................................................202
4.5.9 EFPSISMSC (Public Service Identity of the SM-SC).............................................................................203
4.6 Contents of DFs at the TELECOM level................................................................................................203
4.6.0 List of DFs at the TELECOM level..................................................................................................203
4.6.1 Contents of files at the DFGRAPHICS level............................................................................................203
4.6.1.1 EFIMG (Image)..............................................................................................................................203
4.6.1.2 EFIIDF (Image Instance Data Files)...............................................................................................205
4.6.1.3 EFICE_graphics (In Case of Emergency – Graphics).................................................................205
4.6.1.4 Void.............................................................................................................................................206
4.6.1.5 Void.............................................................................................................................................206
4.6.2 Contents of files at the DFPHONEBOOK under the DFTELECOM.................................................................206
4.6.3 Contents of files at the DFMULTIMEDIA level.........................................................................................206
3GPP
Release 15 7 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 8 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 9 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 10 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 11 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 12 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 13 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 14 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 15 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 16 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 17 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 18 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 19 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 20 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 21 3GPP TS 31.102 V15.21.0 (2018-0610)
Foreword
This Technical Specification (TS) 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:
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.
Introduction
The present document defines the Universal Subscriber Identity Module (USIM) application. This application resides
on the UICC, an IC card specified in TS 31.101 [11]. In particular, TS 31.101 [11] specifies the application independent
properties of the UICC/terminal interface such as the physical characteristics and the logical structure.
TS 31.101 [11] is one of the core documents for this specification and is therefore referenced in many places in the
present document.
3GPP
Release 15 22 3GPP TS 31.102 V15.21.0 (2018-0610)
1 Scope
The present document defines the USIM application for 3G telecom network operation.
- file structures;
- security functions;
- application protocol to be used on the interface between UICC (USIM) and ME.
This is to ensure interoperability between a USIM and an ME independently of the respective manufacturer, card issuer
or operator.
The present document does not define any aspects related to the administrative management phase of the USIM. Any
internal technical realisation of either the USIM or the ME is only specified where these are reflected over the interface.
The present document does not specify any of the security algorithms which may be used.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
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.
[4] 3GPP TS 22.030: "Man-Machine Interface (MMI) of the User Equipment (UE)".
[6] 3GPP TS 23.040: "Technical realization of the Short Message Service (SMS)".
[7] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2".
[8] 3GPP TS 22.067: "enhanced Multi Level Precedence and Pre-emption service (eMLPP) -
Stage 1".
[9] 3GPP TS 24.008: "Mobile Radio Interface Layer 3 specification; Core Network Protocols; Stage
3".
[10] 3GPP TS 24.011: "Point-to-Point (PP) Short Message Service (SMS) support on mobile radio
interface".
3GPP
Release 15 23 3GPP TS 31.102 V15.21.0 (2018-0610)
[15] 3GPP TS 22.086: "Advice of charge (AoC) Supplementary Services - Stage 1".
[18] 3GPP TS 51.011 Release 4: "Specification of the Subscriber Identity Module – Mobile Equipment
(SIM – ME) interface".
[19] ISO 639 (1988): "Code for the representation of names of languages".
[20] ISO/IEC 7816-4: "Integrated circuit cards, Part 4: Organization, security and commands for
interchange".
[21] Void.
[22] ITU-T Recommendation E.164: "The international public telecommunication numbering plan".
[23] 3GPP TS 23.073: "Support of Localised Service Area (SoLSA); Stage 2".
[26] Void.
[28] 3GPP TS 44.018 "Mobile Interface Layer3 Specification, Radio Resource control protocol".
[29] 3GPP TS 23.022: "Functions related to Mobile Station (MS) in idle mode and group receive
mode".
[30] 3GPP TS 23.057: "Mobile Execution Environment (MexE);Functional description; Stage 2".
[31] 3GPP TS 23.122: "NAS Functions related to Mobile Station (MS) in idle mode".
[32] Void.
[35] ISO/IEC 8825-1 (2008): "Information technology – ASN.1 encoding rules : Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules
(DER)".
[37] Void.
[38] 3GPP TS 23.140 Release 6: "Multimedia Messaging Service (MMS); Functional description; stage
2".
[39] ETSI TS 102 222 V7.1.0: "Administrative commands for telecommunications applications".
[40] 3GPP TS 24.234 Release 12: "3GPP System to WLAN Interworking; UE to Network
protocols;Stage 3".
[41] 3GPP TS 33.234 Release 12: "3G Security; Wireless Local Area Network (WLAN) interworking
security".
3GPP
Release 15 24 3GPP TS 31.102 V15.21.0 (2018-0610)
[44] 3GPP TS 43.020: "Technical Specification Group Services and system Aspects; Security related
network functions"
[45] 3GPP2 X.S0016-000-A v1.0: "3GPP2 Multimedia Messaging System MMS Specification
Overview, Revision A"
[46] 3GPP TS 43.068: "Technical Specification Group Core Network; Voice Group Call Service
(VGCS); Stage 2".
[47] 3GPP TS 33.110: "Key establishment between a Universal Integrated Circuit Card (UICC) and a
terminal".
[48] IETF RFC 3629 (2003): "UTF-8, a transformation format of ISO 10646".
[50] ETSI TS TS 102 483 V8.1.0: "UICC-Terminal interface; Internet Protocol connectivity between
UICC and Terminal".
[51] 3GPP TS 24.301: "Technical Specification Group Core Network and Terminals; Non-Access-
Stratum (NAS) protocol for Evolved Packet Systems (EPS): Stage 3".
[52] 3GPP TS 33.401: "3GPP System Architecture Evolution (SAE); Security architecture".
[53] 3GPP2 C.S0074-A v1.0: "UICC-Terminal Interface Physical and Logical Characteristics for
cdma2000 Spread Spectrum Systems"
[54] 3GPP TS 22.220: "Service requirements for Home NodeBs and Home eNodeBs ".
[57] IETF RFC 3629 (2003): "UTF-8, a transformation format of ISO 10646".
[58] 3GPP TS 24.285: "Allowed Closed Subscriber Group (CSG) list; Management Object (MO)"
[61] IETF RFC 2046: "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types".
[62] ETSI TS 101 220 : "Smart Cards; ETSI numbering system for telecommunication application
providers".
[63] 3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP)
and Session Description Protocol (SDP); Stage 3"
[64] 3GPP TS 31.103: "Characteristics of the IP Multimedia Services Identity Module (ISIM)
application".
[65] 3GPP TS 24.368: "Non-Access Stratum (NAS) configuration Management Object (MO)".
[66] ETSI TS 102 484 V10.1.0: ''Smart Cards; Secure channel between a UICC and end-point
terminal"
3GPP
Release 15 25 3GPP TS 31.102 V15.21.0 (2018-0610)
[67] ISO/IEC 7816-15:2004: "Identification cards -- Integrated circuit cards -- Part 15: Cryptographic
information application"
[69] 3GPP TS 23.401: "General Packet Radio Service (GPRS) enhancements for Evolved Universal
Terrestrial Radio Access Network (E-UTRAN) access".
[74] 3GPP TS 36.331: "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource
Control (RRC); Protocol specification"
[75] 3GPP TS 23.032: " Technical Specification Group Services and System Aspects; Universal
Geographical Area Description (GAD)"
[76] 3GPP TS 33.187: "Security aspects of Machine-Type Communications (MTC) and other mobile
data applications communications enhancements"
[78] 3GPP TS 23.682: "Technical Specification Group Services and System Aspects; Architecture
enhancements to facilitate communications with packet data networks and applications"
[79] 3GPP TS 24.302: "Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access
networks".
[80] IETF RFC 4122: "A Universally Unique IDentifier (UUID) URN Namespace".
[81] 3GPP TS 24.105: "Application specific Congestion control for Data Communication (ACDC)
Management Object (MO)".
[82] Void
[83] Void
[85] 3GPP TS 36.306: "Technical Specification Group Radio Access Network; Evolved Universal
Terrestrial Radio Access (E-UTRA); User Equipment (UE) radio access capabilities"
[86] 3GPP TS 24.607: "Originating Identification Presentation (OIP) and Originating Identification
Restriction (OIR) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol
specification"
[87] 3GPP TS 24.417: "Management Object (MO) for Originating Identification Presentation (OIP)
and Originating Identification Restriction (OIR) using IP Multimedia (IM) Core Network (CN)
subsystem; Stage 3".
[88] 3GPP TS 24.167: "3GPP IMS Management Object (MO); Stage 3".
[90] 3GPP TS 23.379: "Functional architecture and information flows to support mission critical push
to talk (MCPTT); Stage 2".void
[92] 3GPP TS 36.101: "Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE)
radio transmission and reception".
3GPP
Release 15 26 3GPP TS 31.102 V15.21.0 (2018-0610)
[93] 3GPP TS 24.424: "Management Object (MO) for Extensible Markup Language (XML)
Configuration Access Protocol (XCAP) over the Ut interface for Manipulating Supplementary
Services (SS)".
[94] 3GPP TS 24.391: "Unstructured Supplementary Service Data (USSD) using IP Multimedia (IM)
Core Network (CN) subsystem (IMS) Management Object (MO)".
[95] 3GPP TS 24.275: "Management Object (MO) for basic communication part of IMS multimedia
telephony (MMTEL) communication service".
[96] 3GPP TS 24.368: "Non-Access Stratum (NAS) configuration Management Object (MO)".
[98] 3GPP TS 24.386: "User Equipment (UE) to V2X control function; protocol aspects ".
[99] 3GPP TS 26.346: " Technical Specification Group Services and System Aspects; Multimedia
Broadcast/Multicast Service (MBMS); Protocols and codecs"[100] OMA-DDS-DM_ConnMO-
V1_0-20081107-A: " Standardized Connectivity Management Objects".
[101] 3GPP TS 24.424: "Management Object (MO) for Extensible Markup Language (XML)
Configuration Access Protocol (XCAP) over the Ut interface for Manipulating Supplementary
Services (SS)".
[102] 3GPP TS 24.623: "Extensible Markup Language (XML) Configuration Access Protocol (XCAP)
over the Ut interface for Manipulating Supplementary Services".
[104] 3GPP TS 24.501: "Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3".
[106] 3GPP TS 22.261: "Service requirements for the 5G system; Stage 1".
3.1 Definitions
For the purposes of the present document, the following definition applies.
ADM: access condition to an EF which is under the control of the authority which creates this file.
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, PIN,
PIN2 and NEV if required.
A terminal does not need to evaluate access conditions indicated as ADM in the present document.
PIN/ADM: A terminal is required to evaluate the access condition and verify it in order to access the EF if the access
condition is set to PIN or PIN2.
3GPP
Release 15 27 3GPP TS 31.102 V15.21.0 (2018-0610)
EHPLMN: represents the Equivalent HPLMNs for network selection purposes. The behaviour of EHPLMNs is defined
in TS 23.122 [31].
3.2 Symbols
For the purposes of the present document, the following symbols apply:
|| Concatenation
Exclusive OR
f1 Message authentication function used to compute MAC
f1* A message authentication code (MAC) function with the property that no valuable information can
be inferred from the function values of f1* about those of f1, ..., f5 and vice versa
f2 Message authentication function used to compute RES and XRES
f3 Key generating function used to compute CK
f4 Key generating function used to compute IK
f5 Key generating function used to compute AK
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
3GPP
Release 15 28 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 29 3GPP TS 31.102 V15.21.0 (2018-0610)
All lengths are presented in bytes, unless otherwise stated. Each byte is represented by bits b8 to b1, where b8 is the
most significant bit (MSB) and b1 is the least significant bit (LSB). In each representation, the leftmost bit is the MSB.
The coding of Data Objects in the present document is according to TS 31.101 [11].
'XX': Single quotes indicate hexadecimal values. Valid elements for hexadecimal values are the numbers
'0' to '9' and 'A' to 'F'.
A file is associated with attributes that depending of the file type indicates how data is to be accessed e.g. file size,
record length etc. Although in the present document some files and data items stored in a file are indicated as having a
fixed length; when reading such structures the terminal shall derive the length of the data item from the attributes
provided in the file information i.e. not use the fixed value specified for the file in the present document. Although the
terminal is able to read the entire structure it should only use those elements in the data item which is recognised by the
terminal.
For any EF, when the SFI is not indicated in the description of the file it is not allowed to assign an SFI. If in the
description of the file an SFI value is indicated the file shall support SFI. The SFI value shall be assigned by the card
issuer. It is mandatory for Efs stating an SFI value ('YY') in the description of their structure to provide an SFI. For files
where in the file description the SFI is indicated as 'Optional' the file may support an SFI.
For an overview containing all files see figures 4.1 and 4.2.
3GPP
Release 15 30 3GPP TS 31.102 V15.21.0 (2018-0610)
This information may also be used for the screening of Cell Broadcast messages in a preferred language, as follows.
When the CB Message Identifier capability is available, the ME selects only those CB messages the language of which
corresponds to an entry in this EF or in EFLI, whichever of these Efs is used (see clause 5.1.1). The CB message
language is defined by the Data Coding Scheme (see TS 23.038 [5]) 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 [5]) to the language coding as defined in ISO 639 [19] if it is necessary to check the language
coding in EFPL.
The File Ids '6F1X' (for Efs), '5F1X' and '5F2X' (for DFs) with X ranging from '0' to 'F' are reserved under the USIM
ADF for administrative use by the card issuer.
When the CB Message Identifier capability is available, the ME selects only those CB messages the language of which
corresponds to an entry in this EF or in EFPL, whichever of these Efs is used (see clause 5.1.1). The CB message
language is defined by the Data Coding Scheme (DCS: see TS 23.038 [5]) 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 [5]) to the language coding as defined in ISO 639 [19] if it is necessary to check the language
coding in EFPL.
Coding:
each language code is a pair of alpha-numeric characters, defined in ISO 639 [19]. Each alpha-numeric character
shall be coded on one byte using the SMS default 7-bit coded alphabet as defined in TS 23.038 [5] with bit 8 set
to 0.
3GPP
Release 15 31 3GPP TS 31.102 V15.21.0 (2018-0610)
- 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 24.008 [9].
- 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'.
Byte 2:
b8 B7 b6 B5 b4 b3 b2 b1
1
0
0
Parity
LSB of Digit 1
:
:
MSB of Digit 1
Byte 3:
b8 b7 b6 B5 b4 b3 b2 b1
LSB of Digit 2
:
:
MSB of Digit 2
LSB of Digit 3
:
:
MSB of Digit 3
etc.
3GPP
Release 15 32 3GPP TS 31.102 V15.21.0 (2018-0610)
b8 b7 b6 b5 b4 b3 b2 b1
KSI
bits b4 to b8 are coded 0
4.2.4 EFKeysPS (Ciphering and Integrity Keys for Packet Switched domain)
This EF contains the ciphering key CKPS, the integrity key IKPS and the key set identifier KSIPS for the packet
switched (PS) domain.
b8 b7 b6 b5 b4 b3 b2 b1
KSIPS
bits b4 to b8 are coded 0
3GPP
Release 15 33 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains the coding for n PLMNs, where n is at least eight. This information is determined by the user and
defines the preferred PLMNs of the user in priority order. The first record indicates the highest priority and the n th
record indicates the lowest. The EF also contains the Access Technologies for each PLMN in this list. (see
TS 23.122 [31])
- PLMN
Contents:
- Mobile Country Code (MCC) followed by the Mobile Network Code (MNC).
Coding:
- according to TS 24.008 [9].
- Access Technology Identifier:
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.
3GPP
Release 15 34 3GPP TS 31.102 V15.21.0 (2018-0610)
Byte5n-1:
b8 b7 b6 b5 b4 b3 b2 b1
RFU
RFU
RFU
NG-RAN
E-UTRAN in NB-S1 mode (see table below)
E-UTRAN in WB-S1 mode (see table below)
E-UTRAN (see table below)
UTRAN
b7 b6 b5 Description
0 x x E-UTRAN not selected
1 0 0 E-UTRAN in WB-S1 mode and NB-S1 mode
1 0 1 E-UTRAN in NB-S1 mode only
1 1 0 E-UTRAN in WB-S1 mode only
1 1 1 E-UTRAN in WB-S1 mode and NB-S1 mode
Byte 5n:
b8 b7 b6 b5 b4 b3 b2 b1
RFU
RFU
GSM (see table below)
EC-GSM-IoT (see table below)
cdma2000 1xRTT
cdma2000 HRPD
GSM COMPACT
GSM (see table below)
b8 b4 b3 Description
0 x x GSM and EC-GSM-IoT not selected
1 0 0 GSM and EC-GSM-IoT
1 0 1 GSM without EC-GSM-IoT
1 1 0 EC-GSM-IoT only
1 1 1 GSM and EC-GSM-IoT
3GPP
Release 15 35 3GPP TS 31.102 V15.21.0 (2018-0610)
- Time interval.
Contents:
the time interval between two searches.
Coding:
For all UEs except those only supportingnot using any of the following at the time of starting the timer, or a
combination of: NB-IoT, GERAN EC-GSM-IoT and Category M1 of E-UTRAN enhanced-MTC as specified in 3GPP
TS 36.306 [85], the time interval is coded in integer multiples of n minutes. The range is from n minutes to a maximum
value. The encoding is:
For UEs using only supporting any of the following at the time of starting the timer, or a combination of,: NB-IoT,
GERAN EC-GSM-IoT and Category M1 of E-UTRAN enhanced-MTC as specified in 3GPP TS 36.306 [85], the time
interval is coded as follows. The range is from n hours to a maximum value. The encoding is:
- '00': No higher priority PLMN search attempts;
- '01': n hours (2 hours);
- '02' to '28': 2n hours (i.e. range from 4 hours to 80 hours with step of 2 hours);
- '29' to '50': 4n-80 hours (i.e. range from 84 hours to 240 hours with step of 4 hours).
For specification of the integer timer interval n, the maximum value and the default period refer to 3GPP
TS 23.122 [31].
NOTE: Care should be taken in the configuration of this EF, as the value stored can be interpreted in different
ways depending on the type of device used.
- Maximum value.
Contents:
- maximum value of the Accumulated Call Meter (ACM).
Coding:
First byte:
b8 b7 b6 b5 b4 b3 b2 b1
Second byte:
3GPP
Release 15 36 3GPP TS 31.102 V15.21.0 (2018-0610)
b8 b7 b6 b5 b4 b3 b2 b1
Third byte:
b8 b7 b6 b5 b4 b3 b2 b1
27 26 25 24 23 22 21 20
All ACM data is stored in the USIM and transmitted over the USIM/ME interface as binary.
If a GSM application is present on the UICC and the ACMmax value is to be shared between the GSM and the USIM
application this file shall be shared between the two applications.
3GPP
Release 15 37 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 38 3GPP TS 31.102 V15.21.0 (2018-0610)
-Services
Contents: Service n°1: Local Phone Book
Service n°2: Fixed Dialling Numbers (FDN)
Service n°3: Extension 2
Service n°4: Service Dialling Numbers (SDN)
Service n°5: Extension3
Service n°6: Barred Dialling Numbers (BDN)
Service n°7: Extension4
Service n°8: Outgoing Call Information (OCI and OCT)
Service n°9: Incoming Call Information (ICI and ICT)
Service n°10: Short Message Storage (SMS)
Service n°11: Short Message Status Reports (SMSR)
Service n°12: Short Message Service Parameters (SMSP)
Service n°13: Advice of Charge (AoC)
Service n°14: Capability Configuration Parameters 2 (CCP2)
Service n°15: Cell Broadcast Message Identifier
Service n°16: Cell Broadcast Message Identifier Ranges
Service n°17: Group Identifier Level 1
Service n°18: Group Identifier Level 2
Service n°19: Service Provider Name
Service n°20: User controlled PLMN selector with Access Technology
Service n°21: MSISDN
Service n°22: Image (IMG)
Service n°23: Support of Localised Service Areas (SoLSA)
Service n°24: Enhanced Multi-Level Precedence and Pre-emption Service
Service n°25: Automatic Answer for eMLPP
Service n°26: RFU
Service n°27: GSM Access
Service n°28: Data download via SMS-PP
Service n°29: Data download via SMS-CB
Service n°30: Call Control by USIM
Service n°31: MO-SMS Control by USIM
Service n°32: RUN AT COMMAND command
Service n°33: shall be set to '1'
Service n°34: Enabled Services Table
Service n°35: APN Control List (ACL)
Service n°36: Depersonalisation Control Keys
Service n°37: Co-operative Network List
Service n°38: GSM security context
Service n°39: CPBCCH Information
Service n°40: Investigation Scan
Service n°41: MexE
Service n°42: Operator controlled PLMN selector with Access Technology
Service n°43: HPLMN selector with Access Technology
Service n°44: Extension 5
Service n°45: PLMN Network Name
Service n°46: Operator PLMN List
Service n°47: Mailbox Dialling Numbers
Service n°48: Message Waiting Indication Status
Service n°49: Call Forwarding Indication Status
Service n°50: Reserved and shall be ignored
Service n°51: Service Provider Display Information
Service n°52 Multimedia Messaging Service (MMS)
Service n°53 Extension 8
Service n°54 Call control on GPRS by USIM
Service n°55 MMS User Connectivity Parameters
Service n°56 Network's indication of alerting in the MS (NIA)
Service n°57 VGCS Group Identifier List (EFVGCS and EFVGCSS)
Service n°58 VBS Group Identifier List (EFVBS and EFVBSS)
Service n°59 Pseudonym
Service n°60 User Controlled PLMN selector for I-WLAN access
Service n°61 Operator Controlled PLMN selector for I-WLAN access
Service n°62 User controlled WSID list
Service n°63 Operator controlled WSID list
Service n°64 VGCS security
Service n°65 VBS security
Service n°66 WLAN Reauthentication Identity
Service n°67 Multimedia Messages Storage
Service n°68 Generic Bootstrapping Architecture (GBA)
3GPP
Release 15 39 3GPP TS 31.102 V15.21.0 (2018-0610)
Service n°46 can only be declared "available" if service n°45 is declared "available".
3GPP
Release 15 40 3GPP TS 31.102 V15.21.0 (2018-0610)
Service n°95, n°99 and n°115 shall not be declared "available" if an ISIM application is present on the UICC.
Service n°125 shall only be taken into account if Service n°xxx is declared "available". If Service n°124 and Service
n°125 are declared "available", the "SUCI calculation is to be performed by the USIM". If Service n°124 is declared
"available" and Service n°125 is not declared "available", the "SUCI calculation is to be performed by the ME".
Coding:
- Service available means that the USIM has the capability to support the service and that the service is available
for the user of the USIM unless the service is identified as "disabled" in EFEST.
Service not available means that the service shall not be used by the USIM user, even if the USIM has the
capability to support the service.
First byte:
b8 b7 b6 B5 B4 b3 b2 b1
Service n°1
Service n°2
Service n°3
Service n°4
Service n°5
Service n°6
Service n°7
Service n°8
Second byte:
b8 b7 b6 B5 B4 b3 b2 b1
Service n°9
Service n°10
Service n°11
Service n°12
Service n°13
Service n°14
Service n°15
Service n°16
etc.
This EF contains the total number of units for both the current call and the preceding calls.
NOTE: The information may be used to provide an indication to the user for advice or as a basis for the
calculation of the monetary cost of calls (see TS 22.086 [15]).
3GPP
Release 15 41 3GPP TS 31.102 V15.21.0 (2018-0610)
If a GSM application is present on the UICC and the ACM value is to be shared between the GSM and the USIM
application this file shall be shared between the two applications.
This EF contains identifiers for particular USIM-ME associations. It can be used to identify a group of USIMs for a
particular application.
This EF contains identifiers for particular USIM-ME associations. It can be used to identify a group of USIMs for a
particular application.
3GPP
Release 15 42 3GPP TS 31.102 V15.21.0 (2018-0610)
NOTE: The structure of EFGID1 and EFGID2 is identical. They are provided to allow the network operator to enforce
different levels of security dependant on an application.
This EF contains the service provider name in text format and appropriate requirements for the display by the ME. The
service provider name may also be provided in a graphical format in EFSPNI. The ME shall use the service provider
name in the text format or the graphical format or both to display the service provider name according to the rules
defined in section 4.2.88.
- Display Condition
Contents: display condition for the service provider name in respect to the registered PLMN (see TS 22.101 [24]).
Coding:
b8 b7 b6 b5 b4 b3 b2 b1
Coding:
the string shall use:
- either the SMS default 7-bit coded alphabet as defined in TS 23.038 [5] 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 the annex of TS 31.101 [11].
3GPP
Release 15 43 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains the Price per Unit and Currency Table (PUCT). The PUCT is Advice of Charge related information
which may be used by the ME in conjunction with EFACM to compute the cost of calls in the currency chosen by the
subscriber, as specified in TS 22.024 [3].
- Currency code
Contents:
the alpha-identifier of the currency code.
Coding:
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 [5] with bit 8 set to 0.
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
to 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
Byte 5:
b8 b7 b6 b5 b4 b3 b2 b1
23 22 21 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 [3] by the
following formula:
If a GSM application is present on the UICC and the PUCT information is to be shared between the GSM and the
USIM application, then this file shall be shared between the two applications.
3GPP
Release 15 44 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains the Message Identifier Parameters which specify the type of content of the cell broadcast messages
that the subscriber wishes the UE to accept.
Any number of CB Message Identifier Parameters may be stored in the USIM. No order of priority is applicable.
Byte 1:
b8 b7 b6 b5 b4 b3 b2 b1
Byte 2:
3GPP
Release 15 45 3GPP TS 31.102 V15.21.0 (2018-0610)
b8 b7 b6 b5 b4 b3 b2 b1
A PLMN is written to the EF if a network rejects a Location Update with the cause "PLMN not allowed". The ME shall
manage the list as follows.
When n FPLMNs are held in the EF, and rejection of a further PLMN is received by the ME from the network, the ME
shall modify the EF using the UPDATE command. This new PLMN shall be stored in the nth position, and the existing
list "shifted" causing the previous contents of the first position to be lost.
When less than n FPLMNs exist in the EF, storage of an additional FPLMN shall not cause any existing FPLMN to be
lost.
Dependent upon procedures used to manage storage and deletion of FPLMNs in the EF, it is possible, when less than n
FPLMNs exist in the EF, for 'FFFFFF' to occur in any position. The ME shall analyse all the EF for FPLMNs in any
position, and not regard 'FFFFFF' as a termination of valid data.
- PLMN
Contents:
Mobile Country Code (MCC) followed by the Mobile Network Code (MNC).
Coding:
according to TS 24.008 [9].
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 to 9: '42' 'F6' '18'.
If storage for fewer than n PLMNs is required, the unused bytes shall be set to 'FF'.
3GPP
Release 15 46 3GPP TS 31.102 V15.21.0 (2018-0610)
- TMSI
Contents:
Temporary Mobile Subscriber Identity.
Coding:
according to TS 24.008 [9].
B8 b7 b6 b5 b4 B3 b2 b1
MSB
- LAI
Contents:
Location Area Information.
Coding:
according to TS 24.008 [9].
b8 b7 b6 b5 b4 b3 b2 b1
MSB
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 TS 31.101 [11]).
3GPP
Release 15 47 3GPP TS 31.102 V15.21.0 (2018-0610)
It also provides an indication about how some ME features shall work during normal operation as well as information
about the length of the MNC, which is part of the International Mobile Subscriber Identity (IMSI).
- UE operation mode:
Contents:
mode of operation for the UE
Coding:
Initial value
- '00' normal operation.
- '80' type approval operations.
- '01' normal operation + specific facilities.
- '81' type approval operations + specific facilities.
- '02' maintenance (off line).
- '04' cell test operation.
All other values are RFU
- Additional information:
Contents:
additional information depending on the UE operation mode
Coding:
- specific facilities (if b1=1 in byte 1):
b8 b7 b6 b5 b4 b3 b2 b1
b8 b7 b6 b5 b4 b3 b2 b1
b2 is used to indicate which CSGs the UE shall display during manual CSG selection. This bit
corresponds to the value of OperatorCSGEntries_Only leaf described in TS 24.285 [58]. This bit shall be
ignored when service n°92 is not "available".
- b2=0: for every PLMN not included in EF_OCSGL, or for which a CSG display indicator tag is not
present, all available CSGs can be displayed without any restriction.
3GPP
Release 15 48 3GPP TS 31.102 V15.21.0 (2018-0610)
- b2=1: for every PLMN not included in EF_OCSGL or any PLMN for which a CSG display indicator
tag is not present, only the available CSGs found in the Operator CSG list shall be displayed.
b3 is used to indicate whether the USIM enables the Public Safety UE to use the ME provisioning
parameters for Public Safety usage, in the cases described in TS 24.334 [70].
- b3=0: the ME is not authorized for ProSe services for Public Safety usage (i.e. Direct Discovery and
Direct Communication as per TS 24.334 [70]) without contacting the ProSe Function.
- b3=1: the ME is authorized to use the parameters stored in the USIM or in the ME for ProSe
services for Public Safety usage, as described in TS 24.334 [70] without contacting the ProSe
Function.
b4 is used to indicate whether the UICC polling interval to retrieve proactive commands can be modified
(as described in TS 31.101 [11]) or weather the UICC interface can be deactivated (as described in clause
5.1.11) during extended DRX cycle.
- b4=0: the ME is not authorized to modify the polling interval and/or disable the UICC interface
during extended DRX cycle.
- b4=1: the ME is authorized to modify the polling interval and/or disable the UICC interface during
extended DRX cycle.
B8 b7 b6 B5 B4 b3 b2 b1
Any value
B8 b7 b6 b5 B4 b3 b2 b1
Any value
Coding:
Byte 4:
b8 b7 b6 b5 b4 b3 b2 b1
4.2.19 Void
This EF contains the message identifier parameters which specify the type of content of the cell broadcast messages
which are to be passed to the USIM.
Any number of CB message identifier parameters may be stored in the USIM. No order of priority is applicable.
3GPP
Release 15 49 3GPP TS 31.102 V15.21.0 (2018-0610)
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 than 6
digits is chosen, then the unused nibbles shall be set to 'F'.
Byte 1:
b8 b7 b6 b5 b4 b3 b2 b1
LSB of Digit 1
::
::
MSB of Digit 1
LSB of Digit 2
:
:
MSB of Digit 2
Byte 2:
3GPP
Release 15 50 3GPP TS 31.102 V15.21.0 (2018-0610)
b8 b7 b6 b5 b4 b3 b2 b1
LSB of Digit 3
:
:
MSB of Digit 3
LSB of Digit 4
:
:
MSB of Digit 4
Byte 3:
b8 b7 b6 b5 b4 b3 b2 b1
LSB of Digit 5
:
:
MSB of Digit 5
LSB of Digit 6
:
:
MSB of Digit 6
Coding:
this alpha-tagging shall use
either:
- the SMS default 7-bit coded alphabet as defined in TS 23.038 [5] 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 the annex of TS 31.101 [11].
Coding:
Coding according to TS 24.008 [9].
This EF contains ranges of cell broadcast message identifiers that the subscriber wishes the UE to accept.
Any number of CB Message Identifier Parameter ranges may be stored in the USIM. No order of priority is applicable.
3GPP
Release 15 51 3GPP TS 31.102 V15.21.0 (2018-0610)
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 [16] "Message Format on BTS-MS
Interface - Message Identifier". Values listed show the ranges of messages which shall be accepted by the UE.
Unused entries shall be set to 'FF FF FF FF'.
- P-TMSI.
Contents:
Packet Temporary Mobile Subscriber Identity.
Coding:
according to TS 24.008 [9].
b8 b7 B6 B5 B4 B3 b2 b1
MSB
Coding:
according to TS 24.008 [9].
B8 b7 B6 B5 B4 B3 b2 b1
MSB
3GPP
Release 15 52 3GPP TS 31.102 V15.21.0 (2018-0610)
- RAI
Contents:
Routing Area Information.
Coding:
according to TS 24.008 [9].
b8 b7 b6 b5 b4 b3 b2 b1
MSB
Coding:
byte 14:
Bits: b3 b2 b1.
0 0 0 : updated.
0 0 1 : not updated.
0 1 0 : PLMN not allowed.
0 1 1 : Routing Area not allowed.
1 1 1 : reserved.
Bits b4 to b8 are RFU (see TS 31.101 [11]).
This EF contains Fixed Dialling Numbers (FDN) and/or Supplementary Service Control strings (SSC). In addition it
contains identifiers of associated network/bearer capabilities and identifiers of extension records at the USIM ADF
level. It may also contain an associated alpha-tagging. If this file is present in the USIM, the Enabled Services
Table (EFEST) shall also be present.
For contents and coding of all data items see the respective data items of the EF ADN (clause 4.4.2.3), with the exception
that extension records are stored in the EFEXT2.
By default, destination addresses which are not in EFFDN shall not be allowed on any CS bearer service/teleservice, or
IMS communication or SMS when FDN is enabled.
For the FDN procedures related to SMS see TS 22.101 [24] and TS 31.111 [12].
3GPP
Release 15 53 3GPP TS 31.102 V15.21.0 (2018-0610)
NOTE: The value of X (the number of bytes in the alpha-identifier) may be different to the length denoted X in
EFADN.
This EF contains information in accordance with TS 23.040 [6] comprising short messages (and associated parameters)
which have either been received by the UE from the network, or are to be used as an UE originated message.
- Status.
Contents:
Status byte of the record which can be used as a pattern in the SEARCH RECORD command. For UE originating
messages sent to the network, the status shall be updated when the UE receives a status report, or sends a successful
SMS Command relating to the status report.
Coding:
b8 b7 b6 b5 b4 b3 b2 b1
X X 0 free space
X X 1 used space
b8 b7 b6 b5 b4 b3 b2 b1
- Remainder.
Contents:
This data item commences with the TS-Service-Centre-Address as specified in TS 24.011 [10]. The bytes
immediately following the TS-Service-Centre-Address contain an appropriate short message TPDU as specified in
TS 23.040 [6], with identical coding and ordering of parameters.
3GPP
Release 15 54 3GPP TS 31.102 V15.21.0 (2018-0610)
Coding:
according to TS 23.040 [6] and TS 24.011 [10]. Any TP-message reference contained in an UE originated message
stored in the USIM, shall have a value as follows:
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 USIM the TS-Service-Centre-Address and the TPDU in bytes 2 to 176 without modification, except
for the last byte of the TPDU, which shall not be stored.
This EF contains MSISDN(s) related to the subscriber. In addition it contains identifiers of associated network/bearer
capabilities and identifiers of extension records at the USIM ADF level. It may also contain an associated
alpha-tagging.
For contents and coding of all data items see the respective data items of EF ADN.
If the USIM stores more than one MSISDN number and the ME displays the MSISDN number(s) within the
initialisation procedure then the one stored in the first record shall be displayed with priority.
NOTE: The value of X (the number of bytes in the alpha-identifier) may be different to the length denoted X in
EFADN.
This EF contains values for Short Message Service header Parameters (SMSP), which can be used by the ME for user
assistance in preparation of mobile originated short messages. For example, a service centre address will often be
common to many short messages sent by the subscriber.
The EF consists of one or more records, with each record able to hold a set of SMS parameters. The first (or only)
record in the EF shall be used as a default set of parameters, if no other record is selected.
To distinguish between records, an alpha-identifier may be included within each record, coded on Y bytes.
3GPP
Release 15 55 3GPP TS 31.102 V15.21.0 (2018-0610)
The SMS parameters stored within a record may be present or absent independently. When a short message is to be sent
from the UE, the parameter in the USIM record, if present, shall be used when a value is not supplied by the user.
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'.
- Alpha-Identifier.
Contents:
Alpha Tag of the associated SMS-parameter.
Coding:
see clause 4.4.2.3 (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.
- TP-Destination Address.
Contents and Coding:
as defined for SM-TL address fields in TS 23.040 [6].
- TP-Protocol Identifier.
3GPP
Release 15 56 3GPP TS 31.102 V15.21.0 (2018-0610)
- TP-Validity Period.
Contents and Coding:
as defined in TS 23.040 [6] for the relative time format.
Coding:
- as defined in TS 23.040 [6].
Coding:
b1=1 means flag unset; memory capacity available;
b1=0 means flag set;
b2 to b8 are reserved and set to 1.
This EF contains special service numbers (SDN) and/or the respective supplementary service control strings (SSC). In
addition it contains identifiers of associated network/bearer capabilities and identifiers of extension records at the USIM
ADF level. It may also contain associated alpha-tagging. If the service n° 89 is available this file will contain the eCall
test and reconfiguration numbers that are used by an UE in eCall and normal service mode.
3GPP
Release 15 57 3GPP TS 31.102 V15.21.0 (2018-0610)
For contents and coding of all data items see the respective data items of the EF ADN (clause 4.4.2.3), with the exception
that extension records are stored in the EFEXT3 and capability/configuration parameters are stored in EFCCP2.
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 15 58 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains information in accordance with TS 23.040 [6] comprising short message status reports which have
been received by the UE from the network.
Each record is used to store the status report of a short message in a record of EFSMS. The first byte of each record is the
link between the status report and the corresponding short message in EFSMS.
Coding:
- '00' - empty record;
- '01' to 'FF' - record number of the corresponding SMS in EFSMS.
Coding:
- according to TS 23.040 [6]. Any bytes in the record following the TPDU shall be filled with 'FF'.
This EF is located within the USIM application. The incoming call information can be linked to the phone book stored
under DFTELECOM or to the local phone book within the USIM. The EFICI contains the information related to incoming
calls.
The time of the call and duration of the call are stored in this EF. This EF can also contain associated alpha identifier
that may be supplied with the incoming call. In addition it contains identifiers of associated network/bearer capabilities
and identifiers of extension records at the USIM ADF level. The structure of this EF is cyclic, so the contents shall be
updated only after a call is disconnected.
If CLI is supported and the incoming phone number matches a number stored in the phone book the incoming call
information is linked to the corresponding information in the phone book. If the incoming call matches an entry but is
indicated as hidden in the phone book the link is established but the information is not displayed by the ME if the code
for the secret entry has not been verified. The ME shall not ask for the secret code to be entered at this point.
Optionally the ME may store the link to phone book entry in the file, so that it does not need to look again for a match
in the phone book when it reuses the entry. But the ME will have to check that the incoming call number still exits in
3GPP
Release 15 59 3GPP TS 31.102 V15.21.0 (2018-0610)
the linked phone book entry, as the link might be broken (entry modified). When not used by the ME or no link to the
phone book has been found, this field shall be set to 'FFFFFF'.
The first byte of this link is used to identify clearly the phone book location either global (i.e. under DF TELECOM) or local
(i.e. USIM specific). To allow the reuse of the referring mechanism in further implementation of the phonebook under
discussion, this byte can be used to indicate those.
For the current version of the phone book, the phone book entry is identified as follows:
- the record number in the EFPBR which indicates the EFADN containing the entry;
Structure of EFICI
NOTE: When the contents except incoming call status are invalid, they are filled with 'FF'.
Content:
the date and time are defined by the ME.
Coding:
it is according to the extended BCD coding from Byte1 to Byte 7. The first 3 bytes show year, month and day
(yy.mm.dd). The next 3 bytes show hour, minute and second (hh.mm.ss). The last Byte 7 is Time Zone. The Time Zone
indicates the difference, expressed in quarters of an hour, between the local time and GMT. Bit 4 in Byte 7 represents
the algebraic sign of this difference (0: positive, 1: negative). If the terminal does not support the Time Zone, Byte 7
shall be "FF". Byte X+15: Year.
B8 b7 b6 b5 b4 b3 b2 b1
3GPP
Release 15 60 3GPP TS 31.102 V15.21.0 (2018-0610)
b8 b7 b6 b5 b4 b3 b2 b1
b8 b7 b6 b5 b4 b3 b2 b1
b8 b7 b6 b5 b4 b3 b2 b1
b8 b7 b6 b5 b4 b3 b2 b1
b8 b7 b6 b5 b4 b3 b2 b1
3GPP
Release 15 61 3GPP TS 31.102 V15.21.0 (2018-0610)
b8 b7 b6 b5 b4 b3 b2 b1
Byte X+22:
b8 b7 b6 b5 b4 b3 b2 b1
Byte X+23:
b8 b7 b6 b5 b4 b3 b2 b1
Byte X+24:
b8 b7 b6 b5 b4 b3 b2 b1
27 26 25 24 23 22 21 20
Byte X+25:
b8 b7 b6 b5 b4 b3 b2 b1
For the current implementation of the phone book the following coding applies:
Byte X+26:
3GPP
Release 15 62 3GPP TS 31.102 V15.21.0 (2018-0610)
b8 b7 b6 b5 b4 b3 b2 b1
This EF is located within the USIM application. The outgoing call information can be linked to the phone book stored
under DFTELECOM or to the local phone book within the USIM. The EFOCI contains the information related to outgoing
calls.
The time of the call and duration of the call are stored in this EF. It may also contain associated alpha identifier. In
addition it contains identifiers of associated network/bearer capabilities and identifiers of extension records at the USIM
ADF level. The structure of this file is cyclic, so the contents shall be updated only after a call is disconnected.
If the dialled phone number matches a number stored in the phone book the outgoing call information might be linked
to the corresponding information in the phone book. The dialled number may match with a hidden entry in the phone
book. If the dialled number matches a hidden entry in the phone book the link is established but the information related
to the phone book entry is not displayed by the ME, if the hidden code has not been verified. The ME shall not perform
hidden code verification at this point.
Optionally, the ME may store the link to phone book entry in the file, so that it does not need to look again for a match
in the phone book when it reuses the entry. But the ME will have to check that the outgoing call number still exists in
the linked phone book entry, as the link might be broken (entry modified). When not used by the ME or no link to the
phone book has been found, this field shall be set to 'FFFFFF'.
Structure of EFOCI
NOTE: When the contents are invalid, they are filled with 'FF'.
3GPP
Release 15 63 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains the accumulated incoming call timer duration value for the current call and previous calls. The EF is
USIM specific and resides within the USIM application.
Structure of EFICT
Coding:
Byte 1:
b8 b7 b6 b5 b4 b3 b2 b1
Byte 2:
b8 b7 b6 b5 b4 b3 b2 b1
Byte 3:
b8 b7 b6 b5 b4 b3 b2 b1
27 26 25 24 23 22 21 20
This EF contains the accumulated outgoing call timer duration value for the current call and previous calls. The EF is
USIM specific and resides within the USIM application. The contents of this EF shall be updated only after a call is
disconnected. The coding of this EF is the same as EFICT.
3GPP
Release 15 64 3GPP TS 31.102 V15.21.0 (2018-0610)
Structure of EFOCT
This EF contains extension data of EFICI, EFOCI and EFMSISDN of the USIM application.
This EF contains parameters of required network and bearer capabilities and terminal configurations associated with a
call established using a fixed dialling number, a barred dialling number, an MSISDN, a service dialling number, an
incoming call, an outgoing call or an MBDN. It is referred by EFFDN, EFBDN, EFMSISDN, EFSDN, EFICI, EFOCI, EFMBDN and
EFCFIS at USIM ADF level.
3GPP
Release 15 65 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains information about priority levels and fast call set-up conditions for the enhanced Multi Level
Precedence and Pre-emption service that can be used by the subscriber.
- 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 level A
priority level B
priority level 0
priority level 1
priority level 2
priority level 3
priority level 4
0
NOTE: Priority levels A and B can not be subscribed to (see TS 22.067 [5] for details).
EXAMPLE 1: If priority levels 0, 1 and 2 are subscribed to, EFeMLPP shall be coded '1C'.
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.
3GPP
Release 15 66 3GPP TS 31.102 V15.21.0 (2018-0610)
b8 b7 b6 b5 b4 b3 b2 b1
EXAMPLE 2: If fast call set-up is allowed for priority levels 0, and 1, then byte 2 of EFeMLPP is coded '0C'.
This EF contains those priority levels (of the Multi Level Precedence and Pre-emption service) for which the ME shall
answer automatically to incoming calls.
Byte 1:
b8 b7 b6 b5 b4 b3 b2 b1
EXAMPLE: If automatic answer is allowed for incoming calls with priority levels A, 0 and 1, then EF AaeM is
coded '0D'.
3GPP
Release 15 67 3GPP TS 31.102 V15.21.0 (2018-0610)
4.2.41 Void
- Hidden Key.
Coding:
- the hidden key is coded on 4 bytes using BCD coding. The minimum number of digits is 4. Unused digits are
padded with 'F'.
NOTE 1: Digits are not swapped, i.e. for instance the key "1234" is coded as '12 34 FF FF'.
NOTE 2: The phone book entries marked as hidden are not scrambled by means of the hidden key. They are stored
in plain text in the phone book.
4.2.43 Void
This EF contains Barred Dialling Numbers (BDN) and/or Supplementary Service Control strings (SSC). In addition it
contains identifiers of associated network/bearer capabilities and identifiers of extension records. It may also contain an
associated alpha-tagging. As the BDN service relies on the Call Control feature, BDN shall only be available if Call
Control is available. If this file is present in the USIM, the Enabled Services Table (EF EST) shall also be present.
For contents and coding of all data items, except for the Comparison Method Pointer, see the respective data items of
EFADN, with the exception that extension records are stored in the EFEXT4 and capability/configuration parameters are
stored in EFCCP2. The Comparison Method Pointer refers to a record number in EFCMI.
3GPP
Release 15 68 3GPP TS 31.102 V15.21.0 (2018-0610)
NOTE: The value of X (the number of bytes in the alpha-identifier) may be different to the length denoted X in
EFADN.
This EF contains the list of Comparison Method Identifiers and alpha-tagging associated with BDN entries (see EF BDN).
- Alpha Identifier.
Contents:
Alpha-tagging of the associated Comparison Method Identifier.
Coding:
Same as the alpha identifier in EFADN.
Coding:
- binary; values from 0 to 255 are allowed.
The default coding 255 is reserved for empty field.
3GPP
Release 15 69 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF indicates which services are enabled. If a service is not indicated as enabled in this table, the ME shall not
select the service.
-Services
Contents: Service n°1: Fixed Dialling Numbers (FDN)
Service n°2: Barred Dialling Numbers (BDN)
Service n°3: APN Control List (ACL)
The EF shall contain at least one byte. Further bytes may be included, but if the EF includes an optional byte, then the
EF shall also contain all bytes before that byte. Other services are possible in the future. The coding falls under the
responsibility of the 3GPP.
Coding:
A service which is listed in this table is enabled if it is indicated as available in the USIM Service Table (UST) and
indicated as activated in the Enabled Services Tables (EST) otherwise this service is, either not available or disabled.
First byte:
b8 b7 b6 B5 b4 b3 b2 b1
Service n°1
Service n°2
Service n°3
Service n°4
Service n°5
Service n°6
Service n°7
Service n°8
etc.
This EF contains the list of allowed APNs (Access Point Names) or DNNs. If this file is present in the USIM, the
Enabled Services Table (EFEST) shall also be present.
3GPP
Release 15 70 3GPP TS 31.102 V15.21.0 (2018-0610)
For contents and coding of APN/DNN-TLV values see TS 23.003 [25]. The tag value of the APN/DNN-TLV shall be
'DD'. "Network provided APN/DNN" is coded with a TLV object of length zero.
This EF provides storage for the de-personalization control keys associated with the OTA de-personalization cycle of
TS 22.022 [27].
This EF contains the Co-operative Network List for the multiple network personalization services defined in
TS 22.022 [27].
3GPP
Release 15 71 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents:
- PLMN network subset, service provider ID and corporate ID of co-operative networks.
Coding:
- For each 6 byte list element.
Byte 4:
b8 b7 b6 b5 b4 b3 b2 b1
Byte 5:
b8 b7 b6 b5 b4 b3 b2 b1
Byte 6:
b8 b7 b6 b5 b4 b3 b2 b1
- The end of the list is delimited by the first MCC field coded 'FFF'.
3GPP
Release 15 72 3GPP TS 31.102 V15.21.0 (2018-0610)
- STARTCS
Contents: Initialisation value for Hyperframe number – CS domain.
Coding: The LSB of STARTCS is stored in bit 1 of byte 3. Unused nibbles are set to 'F'.
- STARTPS
Contents: Initialisation value for Hyperframe number – PS domain.
Coding: As for STARTCS.
This EF contains the coding for n PLMNs where n is determined by the operator. This information is determined by the
operator and defines the preferred PLMNs in priority order. The first record indicates the highest priority and the n th
record indicates the lowest. The EF also contains the Access Technologies for each PLMN in this list. (see
TS 23.122 [31])
3GPP
Release 15 73 3GPP TS 31.102 V15.21.0 (2018-0610)
- PLMN.
Contents:
- Mobile Country Code (MCC) followed by the Mobile Network Code (MNC).
Coding:
- according to TS 24.008 [9].
The HPLMN Selector with access technology data field shall contain the HPLMN code, or codes together with the
respected access technology in priority order (see TS 23.122 [31]).
- PLMN
Contents:
Mobile Country Code (MCC) followed by the Mobile Network Code (MNC).
Coding:
3GPP
Release 15 74 3GPP TS 31.102 V15.21.0 (2018-0610)
- Access Technology:
Contents: The Access Technology of the HPLMN that the ME 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.
This EF contains one or more records containing access rule information according to the reference to expanded format
as defined in ISO/IEC 7816-4 [20]. Each record represents an access rule. Unused bytes in the record are set to 'FF'.
If the card cannot access EFARR , any attempt to access a file with access rules indicated in this EFARR shall not be
granted.
3GPP
Release 15 75 3GPP TS 31.102 V15.21.0 (2018-0610)
4.2.56 Void
Network Parameter storage may reduce the extent of the terminal search of FDD, TDD or GSM carriers when selecting
a cell. The network parameters stored in the USIM shall be in accordance with the procedures specified in this clause.
The RF carrier frequency information is stored on 2 bytes and coded on 16 bits starting from 0,0 MHz. Each increment
of the 16 bit value is an increment of 200 kHz in frequency. This allows the exact channel frequency to be stored in this
data field making it independent of any band information. It is up to the terminal to associate the indicated frequency
with a particular band, e.g. GSM 900, GSM 1800 etc. This means that a range from 0 to 13,1 GHz can be covered, with
the resolution of 200 kHz. The frequency indicated is always the terminal receiver carrier frequency.
The EF provides a minimum storage capacity of 46 bytes in order to provide the capability of storing at least two cell
information TLV objects, e.g. GSM/FDD or FDD/TDD in its minimum configuration, i.e. the terminal can rely on the
required memory space for storing at least two cell information lists offering 8 GSM neighbour carrier frequencies and
8 Intra/Inter frequencies, respectively. In what configuration the available memory actually is being used is up to the
terminal.
A terminal shall ignore a TLV object or the value of a carrier frequency which is beyond its capabilities, i.e. an FDD
only terminal shall ignore the GSM related frequency information. When updating this file, the terminal shall update it
with the current values available in the terminal. Updating of this file shall start from the beginning of the file. The
terminal need not respect the structure of any information previously stored, i.e. an FDD only terminal may overwrite
the GSM parameters stored in this file by another terminal.
The GSM cell information constructed TLV object contains the information of the BCCH channel frequency that the
terminal is currently camped on, indicated by tag '80'. The constructed TLV object also contains an indication of up to
32 neighbour BCCH carrier frequencies indicated by tag '81'. In order to store a complete set of GSM network
parameters, a total of 72 bytes is required. The terminal shall convert the BCCH channel information, as specified in
TS 44.018 [28], received from the network into the corresponding frequency before storing it in the USIM.
The FDD cell information constructed TLV object contains the scrambling code information for the intra frequency
carrier, tag '80', and the inter frequency scrambling codes, tag '81'. The intra frequency carrier information may contain
up to 32 scrambling codes (m) while there is a limitation of the number of inter frequency scrambling codes (n1, n2,
n3). The number of inter frequencies that can be indicated is limited to three and the total amount of scrambling codes
for the inter frequencies is limited to 32 (n1+n2+n3 <= 32), i.e. if only one inter frequency carrier is indicated, it can
contain up to 32 scrambling codes. If two or more inter frequency carriers are indicated, a total of 32 scrambling codes
can be provided. How the information is split between the inter frequency carriers is determined by the terminal. In
order to store a complete set of FDD cell information a total of 146 bytes is required. The terminal shall convert the
UARFCN information, as specified in TS 25.101 [33], received from the network into the corresponding frequency
before storing it in the USIM.
The TDD cell information constructed TLV object has the same structure as the FDD cell information TLV object.
NOTE: Currently there is no inter frequency cell information required for the TDD case.
3GPP
Release 15 76 3GPP TS 31.102 V15.21.0 (2018-0610)
- GSM Cell Information, if tag 'A0' is present in this EF the content of this TLV is as follows:
Description Value M/O Length
GSM Cell Information Tag 'A0'' M 1
Length '4+ (2+2*m) M 1
(<=70) '
Current camped cell BCCH frequency '80' M 1
information tag
Length '02' M 1
Current camped BCCH frequency M 2
Neighbour Cell BCCH Frequency '81' O 1
information tag
Length 2*m (=< 32) O 1
Neighbour BCCH carrier frequencies O 2*m
(8 <= m <= 32)
- FDD Cell Information. If tag 'A1' is present in this EF the content of this TLV is as follows:
3GPP
Release 15 77 3GPP TS 31.102 V15.21.0 (2018-0610)
- TDD Cell Information: If tag 'A2' is present in this EF the content of this TLV is as follows:
This EF contains the full and short form versions of the network name for the registered PLMN. The ME shall use these
versions in place of its own versions of the network name for the PLMN (stored in the ME's memory list), and also in
place of the versions of the network name received when registered to the PLMN, as defined by TS 24.008 [9].
This file may also contain PLMN additional information to be displayed to the user during the Manual Network
Selection procedures as defined in TS 23.122 [31].
If the EFOPL is not present, then the first record in this EF is used for the default network name when registered in the
HPLMN (if the EHPLMN list is not present or is empty) or an EHPLMN (if the EHPLMN list is present).
3GPP
Release 15 78 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains a prioritised list of Location Area Information (LAI) or Tracking Area Identity (TAI) identities that
are used to associate a specific operator name contained in EFPNN or EFPNNI with the LAI/TAI. The ME shall use this EF
in association with the EFPNN in place of any network name stored within the ME's internal list and any network name
received when registered to the PLMN, as defined by TS 24.008 [9] or TS 24.301 [51]. The PLMN Network Name may
also be provided in a graphical format in EFPNNI. The ME shall use the text format or the graphical format or both to
display the service provider name according to the rules defined in section 4.2.89.
Contents:
Location Area Information, this comprises of the MCC, MNC and LAC
Tracking Area Identity, this comprises of the MCC, MNC and TAC
Coding:
PLMN : according to TS 24.008 [9]/TS 24.301 [51]
A BCD value of 'D' in any of the MCC and/or MNC digits shall be used to indicate a "wild" value for that
corresponding MCC/MNC digit
3GPP
Release 15 79 3GPP TS 31.102 V15.21.0 (2018-0610)
Two values for the LAC/TAC are stored in order to allow a range of LAC/TAC values to be specified for a
given PLMN. A value of '0000' stored in bytes 4 to 5 and a value of 'FFFE' stored in bytes 6 to 7 shall be
used to indicate the entire range of LACs/TACs for the given PLMN. In the case where only a single
LAC/TAC value is to be specified then the value stored in bytes 4 to 5 shall be identical to the value stored
in bytes 6 to 7 for the given PLMN. If a range of LAC/TAC values are to be specified, then the value stored
in bytes 4 to 5 shall be the start of the LAC/TAC range and the value stored in bytes 6 to 7 shall be the end
of the LAC/TAC range for the given PLMN.
Contents:
Identifier of operator name to be displayed
Coding:
A value of '00' indicates that the name is to be taken from other sources, see TS 22.101 [24]
A value in the range '01' to 'FE' indicates the record number in EFPNN that shall be displayed as the registered
PLMN name. It also indicates the record number in EFPNNI that may be displayed as the registered PLMN
name icon.
NOTE: The intent of this file is to provide exceptions to the other sources of a network name. Care should be
taken not to introduce too many PLMN entries. An excessive number of entries could result in a longer
initialisation period.
This EF contains dialling numbers to access mailboxes associated with Voicemail, Fax, Electronic Mail and other
messages. It may also contain associated alpha-tags for each supported mailbox. Each dialling number shall be
associated with a message waiting indication group type using EFMBI (see TS 23.038 [5] for message waiting indication
group types).
For contents and coding of all data items see the respective data items of the EF ADN (clause 4.4.2.3), with the exception
that extension records are stored in the EFEXT6 and with the exception that Capability/Configuration parameters are
stored in the EFCCP2.
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 15 80 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains information to associate mailbox dialling numbers in EFMBDN with a message waiting indication group
type and subscriber profile (as defined in TS 23.097 [36]). A message waiting indication group type may either be
Voicemail, Fax, Electronic Mail, Other or Videomail (as defined in TS 23.040 [6]).
This EF contains as many records as there are subscriber profiles (shall be record to subscriber profile). Each record
contains references to mailbox dialling numbers in EFMBDN (one reference for each message waiting indication group
type).
- Mailbox Dialling Number Identifier (message waiting group type = Voicemail, Fax, Electronic Mail, Other or
Videomail).
Contents:
Identifies the mailbox dialling number to be associated with message waiting type.
Coding:
'00' – no mailbox dialling number associated with message waiting indication group type.
'xx' – record number in EFMBDN associated with message waiting indication group type.
3GPP
Release 15 81 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains the status of indicators that define whether or not a Voicemail, Fax, Electronic Mail, Other or
Videomail message is waiting (as defined in TS 23.040 [6]). The ME uses the status after re-activation to determine
whether or not to display the respective message-waiting indication on its display.
This EF contains as many records as there are subscriber profiles (shall be record to subscriber profile) as defined in
TS 23.097 [36] for MSP.
Coding:
The indicator status for each indicator type is 1 bit long and set as follows:
bit = 1: Set Indication Active
bit = 0: Set Indication Inactive
b8 b7 B6 b5 b4 b3 b2 b1
Coding:
Binary.
Coding:
Binary.
Coding:
Binary.
3GPP
Release 15 82 3GPP TS 31.102 V15.21.0 (2018-0610)
Coding:
Binary.
Coding:
Binary.
This EF contains the status of indicators that are used to record whether call forward is active. The ME uses the status
after re-activation to determine whether or not to display the respective Call Forwarding indicator on its display.
This EF contains as many records as there are subscriber profiles (shall be record to subscriber profile) as defined in
TS 23.097 [36] for MSP.
NOTE: For contents and coding of data items not detailed below, see the respective data items of EF ADN (clause
4.4.2.3), Capability/Configuration2 Record Identifier and Extension 7 Record Identifier.
MSP number:
Contents:
The MSP number contains the Profile Identity of the subscriber profile. The Profile Identity shall be between 1and 4
as defined in TS 23.097 [36] for MSP.
Coding:
Binary.
Contents:
Indicates the status of the call forward unconditional indicator. Service code = 21 (CFU) or 002 (for CFU part of all
CF), as defined in TS 22.030 [4]
Coding:
The indicator status for each indicator type is 1 bit long and is set as follows:
bit = 1: Set indication active
bit = 0: Set indication inactive.
3GPP
Release 15 83 3GPP TS 31.102 V15.21.0 (2018-0610)
B8 b7 b6 b5 b4 b3 b2 b1
This EF contains information regarding the service provider display i.e. the service provider PLMN list.
The service provider display information object is a constructed TLV coded according to ISO/IEC 8825-1 [35].
3GPP
Release 15 84 3GPP TS 31.102 V15.21.0 (2018-0610)
Coding:
- MMS Status
Content:
The status bytes contain the status information of the notification.
Coding:
b1 indicates whether there is valid data or if the location is free. B2 indicates whether the MMS notification has been read
or not. Bits b3-b4 of the first byte indicate the MM retrieval, MM rejection, or MM forwarding status, Bits b5-b8 of the
first byte and the entire second byte are reserved for future use.
First byte:
b8 b7 b6 b5 b4 b3 b2 b1
X X X 0 Free space
X X X 1 Used space
3GPP
Release 15 85 3GPP TS 31.102 V15.21.0 (2018-0610)
X X 1 1 Notification read
0 0 X 1 MM not retrieved
0 1 X 1 MM retrieved
1 0 X 1 MM rejected
1 1 X 1 MM forwarded
Second byte:
b8 b7 b6 b5 b4 b3 b2 b1
- MMS Implementation
Contents:
The MMS Implementation indicates the used implementation type, e.g. WAP.
Coding:
Allocation of bits:
Bit number Parameter indicated
1 WAP implementation of MMS as defined in TS 23.140 [38]
2 Reserved for 3GPP2: M-IMAP implementation of MMS as defined in X.S0016-000-A v1.0 [45]
3 Reserved for 3GPP2: SIP implementation of MMS as defined in X.S0016-000-A v1.0 [45]
4-8 Reserved for future use
- MMS Notification
Contents:
The MMS Notification contains the MMS notification.
Coding:
The MMS Notification is coded according to the MMS Implementation as indicated in Byte 3.
Any unused byte shall be set to 'FF'.
3GPP
Release 15 86 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains extension data of a MMS Notification (Multimedia Messaging Service - see 4.2.67).
The structure of this EF is identical to the structure of EFEXT1 (see clause 4.4.2.4).
- Record type.
Contents:
type of the record, see clause 4.4.2.4
Coding:
according to the "additional data" type
- Extension data.
Contents:
additional data (MMS notification extension)
Coding:
the first byte of the extension data gives the number of bytes of the remainder of the MMS notification in this record.
The following bytes contain the extension of the MMS notification.
- Identifier.
Contents:
identifier of the next extension record (in EXT8) to enable longer storage of information.
Coding:
record number of next record. 'FF' identifies the end of the chain.
This EF contains values for Multimedia Messaging Connectivity Parameters as determined by the issuer, which can be
used by the ME for MMS network connection. This file may contain one or more sets of Multimedia Messaging Issuer
Connectivity Parameters. The first set of Multimedia Messaging Issuer Connectivity Parameters is used as the default
set. Each set of Multimedia Messaging Issuer Connectivity Parameters may consist of one or more Interface to Core
Network and Bearer information TLV objects, but shall contain only one MMS implementation TLV object, one MMS
Relay/Server TLV object and one Gateway TLV object. The order of the Interface to Core Network and Bearer
information TLV objects in the MMS Connectivity TLV object defines the priority of the Interface to Core Network
and Bearer information, with the first TLV object having the highest priority.
3GPP
Release 15 87 3GPP TS 31.102 V15.21.0 (2018-0610)
Access Conditions:
READ PIN
UPDATE ADM
DEACTIVATE ADM
ACTIVATE ADM
3GPP
Release 15 88 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 89 3GPP TS 31.102 V15.21.0 (2018-0610)
Coding:
The coding is according to the guideline provided in TS 23.140 [38].
An Example for the coding of these parameters can be found in Annex J.2.
This EF contains values for Multimedia Messaging Service User Preferences, which can be used by the ME for user
assistance in preparation of mobile multimedia messages (e.g. default values for parameters that are often used).
Access Conditions:
READ PIN
UPDATE PIN
DEACTIVATE ADM
ACTIVATE ADM
3GPP
Release 15 90 3GPP TS 31.102 V15.21.0 (2018-0610)
- the SMS default 7-bit coded alphabet as defined in TS 23.038 [5] with bit 8 set to 0. The alpha identifier shall be left
justified.
Or:
- one of the UCS2 coded options as defined in the annex of TS 31.101 [11].
An Example for the coding of these parameters can be found in Annex J.1.
This EF contains values for Multimedia Messaging Connectivity Parameters as determined by the user, which can be
used by the ME for MMS network connection. This file may contain one or more sets of Multimedia Messaging User
Connectivity Parameters. Each set of Multimedia Messaging User Connectivity Parameters may consist of one or more
Interface to Core Network and Bearer information TLV objects, but shall contain only one MMS implementation TLV
object, one MMS Relay/Server TLV object and one Gateway TLV object. The order of the Interface to Core Network
and Bearer information TLV objects in the MMS Connectivity TLV object defines the priority of the Interface to Core
Network and Bearer information, with the first TLV object having the highest priority.
Access Conditions:
READ PIN
UPDATE PIN/PIN2
(fixed during administrative management)
DEACTIVATE ADM
ACTIVATE ADM
This EF contains categories and associated text related to the Network's indication of alerting in the MS service defined
in TS 22.101 [24].
3GPP
Release 15 91 3GPP TS 31.102 V15.21.0 (2018-0610)
- Alerting category
Contents:
Coding:
according to TS 24.008 [9]. 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 EFADN. The maximum number of characters for this
informative text is indicated in TS 22.101 [24].
This EF contains a list of those VGCS group identifiers the user has subscribed to. The elementary file is used by the
ME for group call establishment and group call reception.
Access Conditions:
READ PIN
UPDATE ADM
DEACTIVATE ADM
ACTIVATE ADM
- Group ID
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.
3GPP
Release 15 92 3GPP TS 31.102 V15.21.0 (2018-0610)
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
Byte 2:
b8 b7 b6 b5 b4 b3 b2 b1
Byte 3:
b8 b7 b6 b5 b4 b3 b2 b1
Byte 4:
b8 b7 b6 b5 b4 b3 b2 b1
3GPP
Release 15 93 3GPP TS 31.102 V15.21.0 (2018-0610)
b8 b7 b6 b5 b4 b3 b2 b1
If storage for fewer than the maximum possible number n of VGCS Group Ids, is required, the excess
bytes shall be set to 'FF'.
This EF contains the status of activation for the VGCS group identifiers. The elementary file is directly related to the
EFVGCS. This EF shall always be allocated if EFVGCS is allocated.
Access Conditions:
READ PIN
UPDATE PIN/ADM
(fixed during administrative management)
DEACTIVATE ADM
ACTIVATE ADM
Activation/Deactivation Flags
Byte 1:
b8 b7 b6 b5 b4 b3 b2 b1
Group ID 1
:
:
:
:
:
:
Group ID 8
etc : : : : : : : :
3GPP
Release 15 94 3GPP TS 31.102 V15.21.0 (2018-0610)
Byte 7:
b8 b7 b6 b5 b4 b3 b2 b1
Group ID 49
Group ID 50
b3=1
b4=1
b5=1
b6=1
b7=1
b8=1
This EF contains a list of those VBS group identifiers the user has subscribed to. The elementary file is used by the ME
for broadcast call establishment and broadcast call reception.
Access Conditions:
READ PIN
UPDATE ADM
DEACTIVATE ADM
ACTIVATE ADM
Group ID
Byte 1:
b8 b7 b6 b5 b4 b3 b2 b1
3GPP
Release 15 95 3GPP TS 31.102 V15.21.0 (2018-0610)
Byte 2:
b8 b7 b6 b5 b4 b3 b2 b1
Byte 3:
b8 b7 b6 b5 b4 b3 b2 b1
Byte 4:
b8 b7 b6 b5 b4 b3 b2 b1
b8 b7 b6 b5 b4 b3 b2 b1
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 15 96 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains the status of activation for the VBS group identifiers. The elementary file is directly related to the
EFVBS. This EF shall always be allocated if EFVBS is allocated.
Access Conditions:
READ PIN
UPDATE PIN/ADM
(fixed during administrative management)
DEACTIVATE ADM
ACTIVATE ADM
Activation/Deactivation Flags
This EF contains the ciphering algorithm identifiers for each of the Master Group Key (V_Ki) of each VGCS group that
the user has subscribed to (defined in EFVGCS).
Access Conditions:
READ PIN
UPDATE ADM
DEACTIVATE ADM
ACTIVATE ADM
3GPP
Release 15 97 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents: Ciphering Algorithm identifier for the specified Master Group Key of each Voice Call Group
Coding:
Value
‘00’ no ciphering
‘01’ ciphering with algorithm GSM A5/1
‘02’ ciphering with algorithm GSM A5/2
‘03’ ciphering with algorithm GSM A5/3
‘04’ ciphering with algorithm GSM A5/4
‘05’ ciphering with algorithm GSM A5/5
‘06’ ciphering with algorithm GSM A5/6
‘07’ ciphering with algorithm GSM A5/7
‘08’ to ‘FF’ RFU
This EF contains the ciphering algorithm identifiers for each of the Master Group Key (V_Ki) of each VBS group that
the user has subscribed to (defined in EFVBS).
Access Conditions:
READ PIN
UPDATE ADM
DEACTIVATE ADM
ACTIVATE ADM
Contents: Ciphering Algorithm identifier for the specified Master Group Key of each Voice Broadcast
Group
Coding: See coding of EFVGCSCA
This EF contains the AKA Random challenge (RAND) and Bootstrapping Transaction Identifier (B-TID) associated
with a GBA bootstrapping procedure.
3GPP
Release 15 98 3GPP TS 31.102 V15.21.0 (2018-0610)
Length of RAND
Contents: number of bytes, not including this length byte, of RAND field
RAND
Length of B-TID
Contents: number of bytes, not including this length byte, of B-TID field
B-TID
Contents: number of bytes, not including this length byte, of key lifetime field
Key lifetime
A record of this EF contains the list of MBMS Service Keys (MSK) and associated parameters, which are related to an
MBMS Key Domain. There are up to two MSKs per Key Domain ID/Key Group ID pair, where the Key Group ID is
the Key Group part of the MSK ID as defined in TS 33.246 [43]. Two 4 byte MSK IDs stored within a record have the
same value for the 2 byte Key Group part.
3GPP
Release 15 99 3GPP TS 31.102 V15.21.0 (2018-0610)
MSK ID:
Content: Identifier of MBMS Service Key (MSK) within a particular Key Domain.
Coding: As defined in TS 33.246 [43]
Content: Counter for MIKEY replay protection in MTK delivery. Each counter is associated with a
particular MSK.
Coding: As defined in TS 33.246 [43]
This EF contains the identifier of the MBMS User Key (MUK) that is used to protect the transfer of MBMS Service
Keys (MSK). The file also contains the Time Stamp Counter associated with the MUK, which is used for Replay
Protection in MSK transport messages. This EF shall not contain MUK IDs with the same Idi part.
3GPP
Release 15 100 3GPP TS 31.102 V15.21.0 (2018-0610)
- MUK ID Tag 'A0'. This constructed data object consists of the Idr, and the Idi
- Idr Tag '80'
Content:
Idr part of MBMS User Key (MUK).
Coding:
As defined in TS 33.246 [43]
- Idi Tag '82'
Content:
Idi part of MBMS User Key (MUK).
Coding:
As defined in TS 33.246 [43]
3GPP
Release 15 101 3GPP TS 31.102 V15.21.0 (2018-0610)
4.2.82 Void
This EF contains the list of NAF_ID and B-TID associated to a GBA NAF derivation procedure.
This EF contains the coding for n EHPLMNs. The usage of EHPLMN is defined in TS 23.122 [31]. This data field may
contain the HPLMN code derived from the IMSI as an EHPLMN entry.
3GPP
Release 15 102 3GPP TS 31.102 V15.21.0 (2018-0610)
- EHPLMN
Contents:
- Mobile Country Code (MCC) followed by the Mobile Network Code (MNC).
Coding:
- according to TS 24.008 [9].
This EF contains an indication to the ME for the presentation of the available EHPLMN(s). The usage of the EHPLMN
presentation indication is defined in TS 23.122 [31].
This EF contains an indication to the ME for the selection of the RPLMN or the home network at switch on, or
following recovery from lack of coverage. The usage of the Last RPLMN Selection Indication is defined in
TS 23.122 [31].
3GPP
Release 15 103 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains one or more NAF Key Centre addresses. The first record in the EF shall be considered to be of the
highest priority. The last record in the EF shall be considered to be the lowest priority.
Access Conditions:
READ PIN
UPDATE ADM
DEACTIVATE ADM
ACTIVATE ADM
Contents:
Fully qualified Domain Name (FQDN) of the NAF Key Centre used in the Local Key Establishment
procedures (see TS 33.110 [47]).
3GPP
Release 15 104 3GPP TS 31.102 V15.21.0 (2018-0610)
Coding:
Encoded to an octet string according to UTF-8 encoding rules as described in IETF RFC 3629 [48].
This EF may contain one or several links to the service provider name icon. When more than one link is available, it is
up to the ME to choose the link type to be used (e.g. the link type that is supported by the ME). The requirements for
the display by the ME are defined in section 4.2.12.
This file may contain one or several service provider name Icon TLV object(s). The coding of the service provider
name Icon TLV objects is described hereafter:
- Icon Tag
Contents: Tag value.
- When the Icon Link is an URI, the Tag value shall be set to '80'.
- When the Icon Link is a pointer to the record number of the corresponding image in EFIMG, the Tag value
shall be set to '81'.
Coding: binary.
- Icon Qualifier
Contents: The icon qualifier indicates to the ME how the icon shall be used.
- '01' = icon is self-explanatory, i.e. if displayed, it replaces the corresponding name in text format.
- '02' = icon is not self-explanatory, i.e. if displayed, it shall be displayed together with the corresponding
name in text format.
Coding: binary.
- Icon Link
Contents: Link to the icon. This link shall point to a UICC resource.
Coding:
3GPP
Release 15 105 3GPP TS 31.102 V15.21.0 (2018-0610)
- When the Tag value indicates an URI (i.e. Tag = '80') , the Icon Link shall be encoded to an octet string
according to UTF-8 encoding rules as described in IETF RFC 3629 [48] (e.g.
http://127.0.0.1:3516/pub/files/spng.jpg).
- When the Tag value indicates that the Icon Link contains the record number of the corresponding image in
EFIMG (i.e. Tag = '81'), the Icon Link shall be encoded in binary.
This EF contains one or several links to the PLMN network name icon. When more than one link is available in a
record, it is up to the ME to choose the link type to be used (e.g. the link type that is supported by the ME).
Each record may contain one or several PLMN network name Icon TLV object(s). The coding of the Icon TLV
object(s) is described in EFSPNI.
This EF contains the network activation parameters to be used by the ME for establishing a data channel (e.g. PDP
context activation) for UICC remote IP connectivity as described in ETSI TS 102 483 [50].
Each record contains a network connectivity parameters set. A network connectivity parameters set may comprise an
Access Point Name, a Login and Password of the Access Point Name, a Data Destination Address Range and the
Bearer Description. The priority order of the different Network Connectivity Parameters sets is the same as the order of
the record numbers.
Each network connectivity parameters set provides a condition and the network connectivity parameters to be used
when this condition is met:
- The network activation parameters present in a record shall be associated with this Data Destination Address
Range in the same record (i.e. if a record contains a Data Destination Address Range, all IP packets that are sent
by the UICC to any network destination address belonging to this Address Range shall transit through a network
connection established using the parameters provided in that record).
Note: A Data Destination Address Range TLV with a zero length prefix matches all addresses of the
address type.
In a record, if the Access Point Name has a value part, the associated Login and Password may be provided. If
supported by the ME, the Login and Password may be used for Access Point Name authentication. If only the Login is
present, the ME shall use its default Password configuration if any. If the Login and Password are not present, the ME
shall use its default Login/Password configuration if any. If no authentication is requested, the Login and Password
shall be ignored. The Password TLV can only be provided in a record if a Login TLV is provided in the same record.
In any record, if the Access Point Name has no value part, the ME may use its default Access Point Name or the default
subscription value together with the other network connectivity parameters of that record.
3GPP
Release 15 106 3GPP TS 31.102 V15.21.0 (2018-0610)
When present, the Bearer Description TLV provides recommended values for parameters that the ME should use to
establish the data link for UICC remote IP connections. However if the ME or network does not support these values,
the ME selects the most appropriate values.
Structure of EFNCP-IP
Coding: the coding of the Data Destination Address Range TLV object is described hereafter.
- Type of Address
Coding:
- Prefix length
Contents: the number N of valid bits of the prefix of the address range. A prefix length of zero denotes
the default "all IP addresses" range.
Coding: binary
- Prefix
3GPP
Release 15 107 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents: Prefix, i.e. the leftmost bits of the address range. All addresses where the leftmost N bits match
the prefix belong to the address range.
Coding:
- the leftmost N bits encode the prefix of the address range. If N is not an integer multiple of 8, the
prefix is right padded with zeroes to the next octet boundary.
Coding: the coding of the Access Point Name TLV object is described hereafter. The Access Point Name
Value is coded as defined in TS 23.003 [25].
- Login TLV
Contents: the login of the Access Point Name.
Coding: the coding of the Login TLV object is described hereafter. The Login Value is coded as for SMS Data
coding scheme defined in TS 23.038 [5]. Parts of the data coding scheme other than the character set
indication shall be ignored.
- Password TLV
Contents: the password of the Access Point Name.
Coding: the coding of the Password TLV object is described hereafter. The Password Value is coded as for
SMS Data coding scheme defined in TS 23.038 [5]. Parts of the data coding scheme other than the
character set indication shall be ignored.
-
- Bearer Description TLV
Contents: bearer description.
Coding: the coding of the Bearer Description TLV object is described hereafter. The Bearer Description Value
is encoded as the value part of the "Bearer description" TLV data object defined in TS 31.111 [12].
3GPP
Release 15 108 3GPP TS 31.102 V15.21.0 (2018-0610)
- GUTI.
Contents:
Coding:
as the GUTI part of the EPS mobile identity information element defined in TS 24.301 [51]. Byte 1
corresponds to "octet 2" of an EPS mobile identity information element containing a GUTI. Byte 12
corresponds to "octet 13" of an EPS mobile identity information element information element containing
a GUTI.
b8 b7 b6 b5 b4 b3 b2 b1
MSB
Coding:
as the content of the tracking area identity information element defined in TS 24.301 [51]. Byte 13
corresponds to "octet 2" of a tracking area identity information element. Byte 17 corresponds to "octet 6"
of a tracking area identity information element.
b8 b7 b6 b5 b4 b3 b2 b1
MSB
3GPP
Release 15 109 3GPP TS 31.102 V15.21.0 (2018-0610)
Coding:
byte 18:
Bits: b3 b2 b1.
0 0 0 : UPDATED.
0 0 1 : NOT UPDATED.
0 1 0 : ROAMING NOT ALLOWED.
0 1 1 : reserved.
1 0 0 : reserved.
1 0 1 : reserved.
1 1 0 : reserved.
1 1 1 : reserved.
Bits b4 to b8 are RFU (see TS 31.101 [11]).
3GPP
Release 15 110 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains the EPS NAS Security context as defined in TS 33.401 [52]. This file shall contain only one record.
Contents:
The ASME key set identifier as defined in TS 33.401 [52]. In this release the KSIASME is coded on 1 byte.
Coding:
b8 b7 b6 b5 b4 b3 b2 b1
KSIASME
bits b4 to b8 are coded 0
3GPP
Release 15 111 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents:
The ASME Key as defined in TS 33.401 [52]. In this release a valid ASME key is coded on 32 bytes. The
ME shall treat any ASME key values stored in this EF as invalid if the ASME key set identifier indicates
that no ASME key is available or if the length indicated in the ASME key TLV is set to '00',
Coding:
The most significant bit of KASME is the most significant bit of the 1st byte of this TLV value field. The least
significant bit of KASME is the least significant bit of the last byte of this TLV value field.
Contents:
The uplink NAS count as defined in TS 33.401 [52]. In this release the Uplink NAS count is coded on 4
bytes.
Coding:
The most significant bit of the uplink NAS count is the most significant bit of the 1st byte of this TLV value
field. The least significant bit of the uplink NAS count is the least significant bit of the last byte of this
TLV value field.
Contents:
The downlink NAS count as defined in TS 33.401 [52]. In this release the downlink NAS count is coded on 4
bytes.
Coding:
The most significant bit of the downlink NAS count is the most significant bit of the 1st byte of this TLV
value field. The least significant bit of the downlink NAS count is the least significant bit of the last byte
of this TLV value field.
Contents:
The identifiers of selected NAS integrity and encryption algorithms as defined in TS 33.401 [52] and TS
24.301 [51]. In this release the identifiers of selected NAS integrity and encryption algorithms are coded
on 1 byte.
Coding:
as the content of the NAS security algorithms information element defined in TS 24.301 [51].
Byte 1 of this TLV value field: first byte of the NAS security algorithms information element
b8 b7 b6 b5 b4 b3 b2 b1
MSB
3GPP
Release 15 112 3GPP TS 31.102 V15.21.0 (2018-0610)
The facility list has the same format as the TERMINAL PROFILE defined in TS 31.111 [12].
By setting the corresponding bits to 1, the facility list defines facilities which can only be provided by the MT and
which are not allowed to be provided by the TE.
If a TERMINAL PROFILE is longer than the facility list, for the purpose of facility control, the exceeding bytes of the
TERMINAL PROFILE shall be compared according to the generic rules found in TS 31.111 [12].
Access Conditions:
READ PIN
UPDATE ADM
ACTIVATE ADM
DEACTIVATE ADM
3GPP
Release 15 113 3GPP TS 31.102 V15.21.0 (2018-0610)
- NMO I Behaviour
3GPP
Release 15 114 3GPP TS 31.102 V15.21.0 (2018-0610)
Content:
As described in TS 24.368 [65], indicates whether the "NMO I, Network Mode of Operation I" indication is
applied by the UE.
Coding:
b8 b7 b6 b5 b4 b3 b2 b1
3GPP
Release 15 115 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents:
As described in TS 24.368 [65], used to determine whether the NAS signalling priority included in NAS
messages can be overriden.
Coding:
b8 b7 b6 b5 b4 b3 b2 b1
The Override NAS signalling low priority tag and the Override Extended access barring tag shall be set to the same
value, e.g., if the UE is configured to override the NAS signalling low access priority indicator, then it has also to be
configured to override Extended access barring (see 3GPP TS 23.401 [69] subclause 4.3.17.4).
The Override Extended access barring tag and the Override NAS signalling low priority tag shall be set to the same
value, e.g., if the UE is configured to override Extended access barring, then it has also to be configured to override
the NAS signalling low access priority indicator (see 3GPP TS 23.401 [69] subclause 4.3.17.4).
- SM_RetryWaitTime
Contents:
As described in TS 24.368 [65], provides a configured UE retry wait time value applicable when in HPLMN or
EHPLMN (see 3GPP TS 23.122 [31]) for controlling the UE session management retry behaviour when prior
session management request was rejected by the network with cause value #8, #27, #32, #33 as specified in
3GPP TS 24.008 [9] and 3GPP TS 24.301 [51].
3GPP
Release 15 116 3GPP TS 31.102 V15.21.0 (2018-0610)
Coding:
b8 b7 b6 b5 b4 b3 b2 b1
- SM_RetryAtRATChange
Contents:
As described in TS 24.368 [65], indicates the UE's retry behaviour when in HPLMN or EHPLMN (see
3GPP TS 23.122 [31]) after inter-system change between S1 mode and A/Gb or Iu mode as specified in 3GPP
TS 24.008 [9] and 3GPP TS 24.301 [51].
Coding:
b8 b7 b6 b5 b4 b3 b2 b1
- Default_DCN_ID
Contents:
As described in 3GPP TS 24.368 [65], indicates the default DCN-ID which is provided by NAS to the lower
layers at establishment of the NAS signalling connection as specified in 3GPP TS 24.301 [51].
Coding:
As the DCN-ID value inside the DCN-ID IEI defined in TS 24.008 [9] clause 10.5.5.35.
- Exception Data Reporting Allowed
Contents:
As described in 3GPP TS 24.368 [65], for the UE in NB-S1 mode indicates whether the UE is allowed to use the
RRC establishment cause mo-ExceptionData, as specified in 3GPP TS 24.301 [51].
Coding:
b8 b7 b6 b5 b4 b3 b2 b1
If any of these NAS configuration parameters is neither included in EFNASCONFIG nor stored in the ME's non-volatile
memory, the default value as defined for the corresponding leaf in TS 24.368 [65] shall apply.
As specified in TS 24.229 [63] a ME includes the list of IARIs for the IMS applications it intends to use when sending
an initial registration or when sending subsequent registrations to the IMS in the form of a SIP REGISTER request.
This EF contains a list of IARIs associated with active applications installed on the UICC that are included in the SIP
REGISTER request in accordance with the procedures of TS 24.229 [63].
NOTE: If this file is present in both the USIM and the ISIM, the file in the ISIM is used. It is assumed that the
presence of this file in the USIM when an ISIM is present on the UICC is an incorrect configuration of
the UICC.
3GPP
Release 15 117 3GPP TS 31.102 V15.21.0 (2018-0610)
- Coding:
IMS Application Reference Identifier: shall be coded as specified in TS 24.229 [63].
Access Conditions:
READ ALW
UPDATE ADM
ACTIVATE ADM
DEACTIVATE ADM
Contents:
Configuration for PWS
Coding:
First byte:
b8 b7 b6 b5 b4 b3 b2 b1
3GPP
Release 15 118 3GPP TS 31.102 V15.21.0 (2018-0610)
Successive bytes:
RFU (see TS 31.101 [11])
This EF contains a list of FDN stored in URI address format. It may also contain an associated alpha-tagging.
Structure of EFFDNURI
- URI Address.
Content:
The URI Address associated to the referenced file Record number.
Coding:
Same as URI TLV data object in EFIMPU defined in TS 31.103 [64].
- 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 [5] 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 the annex of TS 31.101 [11].
If FDN is enabled, the ME shall only allow outgoing calls using destination addresses which are in EF FDNURI, in addition
to the EFFDN entries, following the same principle as defined in the Fixed Number Dialling description in TS 22.101
[24] applied to URI addresses.
NOTE: The value of Y (the number of bytes in the alpha-identifier) may be different to the length denoted X in
EFFDN.
This EF contains a list of BDN stored in URI address format. It may also contain an associated alpha-tagging.
3GPP
Release 15 119 3GPP TS 31.102 V15.21.0 (2018-0610)
Structure of EFBDNURI
- URI Address.
Content:
The URI Address associated to the referenced file Record number.
Coding:
Same as URI TLV data object in EFIMPU defined in TS 31.103 [64].
- 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 [5] 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 the annex of TS 31.101 [11].
If BDN is enabled, the ME shall only allow outgoing calls using destination addresses which are neither in EF BDNURI nor
in the EFBDN entries, following the same principle as defined in the Barring of Dialled Numbers described in TS 22.101
[24] applied to URI addresses.
NOTE: The value of Y (the number of bytes in the alpha-identifier) may be different to the length denoted X in
EFBDN.
This EF contains a list of SDN stored in URI address format. It may also contain an associated alpha-tagging. If the
service n°112 is available this file will contain the eCall test and reconfiguration URIs that are used by an UE in eCall
and normal service mode.
3GPP
Release 15 120 3GPP TS 31.102 V15.21.0 (2018-0610)
Structure of EFSDNURI
- URI Address.
Content:
The URI Address associated to the referenced file Record number.
Coding:
Same as URI TLV data object in EFIMPU defined in TS 31.103 [64].
- 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 [5] 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 the annex of TS 31.101 [11].
If SDN is enabled, the ME shall perform SDN procedure using destination addresses which are in EF SDNURI or in EFSDN
entries, following the same principle as defined in the Service Dialling Numbers description in TS 22.101 [24] applied
to URI addresses.
NOTE: The value of Y (the number of bytes in the alpha-identifier) may be different to the length denoted X in
EFSDN.
This file shall be present if USAT Application Pairing is supported as defined in this specification.
This file shall contain at least one IMEI(SV) range of values to which the USIM is authorized to be paired.
3GPP
Release 15 121 3GPP TS 31.102 V15.21.0 (2018-0610)
Detail 1:
Following the Length of the TLV, the range is defined as follow: [lower value][higher value].
The authorized values of IMEI or IMEISV in an authorized range of values include the lower and higher
values of the specified range.
To define an authorized individual IMEI or IMEISV, the lower value and the higher value of a range shall
both be equal to the value of the authorized IMEI or IMEISV.
For an IMEI, the Check Digit is not considered in the evaluation
For an IMEISV, the TAC|SNR part and the SVN part may be evaluated separately
Coding:
IMEI and IMEISV coding is defined in 3GPP TS 23.003 [25] and 3GPP TS 24.008 [9]
Unused nibble (IMEI) is set to 'F'
UICC OTA mechanism is used to update the file EF IWL stored in the USIM. This mechanism provides dynamic
management of the pairing to change the allowed combinations of USIM and MTC ME(s) by adding or removing
authorized IMEI(SV) ranges in the file EF IWL.
This file shall be present if USAT Application Pairing is supported as defined in this specification.
The status flag of pairing check (with value "OK" or "KO") stored in the file EFIPS can be read by any terminal hosting
the UICC. The information stored in the file EFIPS provides a mechanism to detect changes of association between a
USIM and a MTC ME. The information stored in the file EFIPS can be read locally by e.g. the maintenance person.
Structure of EFIPS
3GPP
Release 15 122 3GPP TS 31.102 V15.21.0 (2018-0610)
Due to the frequency of the pairing procedure, it is recommended that this file contain at least 100 records.
Detail 1:
These 2 bytes contain the status of the last pairing procedure as defined below:
- If the pairing is successful then:
1. Byte 1 is the character "O"
2. Byte 2 is the character "K"
- If the pairing is not successful then:
1. Byte 1 is the character "K"
2. Byte 2 is the character "O"
- The characters are coded using the SMS default 7-bit coded alphabet as defined in TS 23.038 [5] with bit 8 set to
0.
Detail 2:
This byte contains a link to a record of EFIPD file:
- Unsigned integer coded from '01' to 'FE'
This file shall be present if USAT Application Pairing is supported as defined in this specification.
Coding:IMEI and IMEISV coding is defined in 3GPP TS 23.003 [25] and 3GPP TS 24.008 [9]
Unused nibble (IMEI) is set to 'F'
3GPP
Release 15 123 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains zero or more Home Evolved Packet Data Gateway (ePDG) Identifier data objects as defined in the
"Selection of the ePDG" UE procedure of 3GPP TS 24.302 [79].
Access Conditions:
READ PIN
UPDATE ADM
DEACTIVATE ADM
ACTIVATE ADM
Contents:
- Address of Evolved Packet Data Gateway, in the format of a FQDN, an IPv4 address, or an IPv6 address.
Coding:
- The tag value of this Home ePDG Identifier TLV data object shall be '80'. The format of the data object is as
follows:
- This field shall be set to the type of the ePDG address according to the following:
Contents:
Coding:
- When the Address Type is set to '00', the corresponding ePDG FQDN Address shall be encoded to an octet
string according to UTF-8 encoding rules as specified in IETF RFC 3629 [48].
3GPP
Release 15 124 3GPP TS 31.102 V15.21.0 (2018-0610)
- When the Address Type is set to '01', the corresponding ePDG IPv4 Address is in octet 5 to octet 8 of the
Home ePDG Identifier TLV data object. Bit 8 of octet 5 represents the most significant bit of the IP address
and bit 1 of octet 8 the least significant bit.
- When the Address Type is set to '02', the corresponding ePDG IPv6 Address is in octet 5 to octet 20 of the
Home ePDG Identifier TLV data object. Bit 8 of octet 5 represents the most significant bit of the IP address
and bit 1 of octet 20 the least significant bit.
This EF contains Evolved Packet Data Gateway (ePDG) selection information for one or more PLMNs as defined in the
"Selection of the ePDG" UE procedure of 3GPP TS 24.302 [79].
Access Conditions:
READ PIN
UPDATE ADM
DEACTIVATE ADM
ACTIVATE ADM
The file contains one ePDG selection information TLV data object. The ePDG selection information TLV data object
contains a list of PLMNs which are preferred for ePDG selection. The list of PLMNs may include the HPLMN. For
each PLMN, it is indicated:
the preference order (priority) given to ePDG of a PLMN and
whether selection of an ePDG in such PLMN should be based on Tracking/Location Area Identity FQDN or on
Operator Identifier FQDN,
as specified in the "Selection of the ePDG" UE procedure of 3GPP TS 24.302 [79].
PLMN:
Contents:
- Mobile Country Code (MCC) followed by the Mobile Network Code (MNC).
Coding:
3GPP
Release 15 125 3GPP TS 31.102 V15.21.0 (2018-0610)
- A BCD value of 'D' in any of the MCC and/or MNC digits shall be used to indicate a "wild" value for that
corresponding MCC/MNC digit.
ePDG Priority:
Contents:
- The PLMN Priority represents the preference order given to ePDGs of a PLMN.
Coding:
Contents:
- Indicates whether the selection of an ePDG in this PLMN should be based on Tracking/Location Area
Identity FQDN or on Operator Identifier FQDN (see 3GPP TS 24.302 [79]).
Coding:
- '00': Indicates that Operator Identifier FQDN format shall be used (see 3GPP TS 24.302 [79]).
- '01': Indicates that location based FQDN format shall be used (see 3GPP TS 24.302 [79]).
This EF contains zero or more Emergency Evolved Packet Data Gateway (ePDG) Identifier data objects.
Access Conditions:
READ PIN
UPDATE ADM
DEACTIVATE ADM
ACTIVATE ADM
3GPP
Release 15 126 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains Evolved Packet Data Gateway (ePDG) selection information for Emergency Services.
Access Conditions:
READ PIN
UPDATE ADM
DEACTIVATE ADM
ACTIVATE ADM
It shall be possible to define if the UE uses the From header field for the determination of the originating party identity
in the OIP service. For more detailed description see 3GPP TS 24.607 [86] subclause 4.5.2.12.
NOTE: If this file is present in both the USIM and the ISIM, the file in the ISIM is used. It is assumed that the
presence of this file in the USIM when an ISIM is present on the UICC is an incorrect configuration of
the UICC.
- Status.
Contents:
Status byte indication if From header field is used or not.
Coding:
b8 b7 b6 b5 b4 b3 b2 b1
This EF contains the IMS configuration data object as specified in 3GPP TS 24.167 [88].
3GPP
Release 15 127 3GPP TS 31.102 V15.21.0 (2018-0610)
For the structure, content and coding of this file, see EFIMSConfigData in 3GPP TS 31.103 [2]
This EF contains the configuration of the parameters related to TV service provided via a PLMN.
- PLMN
Contents:
As described in TS 24.117 [91], the identity of the PLMN for which the TV service configuration applies.
Coding:
According to TS 24.008 [9].
- TMGI
Contents:
- USD File Id
3GPP
Release 15 128 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents:
File identifier of the EFTVUSD inside the DFTV containing the User Service Description (USD).
Coding:
According to TS 31.101 [11]
- Service type
Contents:
Type of service for which the entry is valid.
Coding:
b8 b7 b6 b5 b4 b3 b2 b1
This EF contains information about which SIP and non SIP Services are 3GPP PS Data Off Exempt.
Coding:
- each service that can be 3GPP PS Data Off exempt is coded on one bit.
Byte 1:
3GPP
Release 15 129 3GPP TS 31.102 V15.21.0 (2018-0610)
b8 b7 b6 b5 b4 b3 b2 b1
Byte 2:
b8 b7 b6 b5 b4 b3 b2 b1
3GPP
Release 15 130 3GPP TS 31.102 V15.21.0 (2018-0610)
- Coding:
IMS Communication Service Identifier: shall be coded as specified in TS 24.229 [63].
This EF contains the XCAP configuration data object as specified in 3GPP TS 24.424 [101], OMA OMA-TS-
XDM_MO-V1_1-20080627-A [103] and OMA-DDS-DM_ConnMO-V1_0-20081107-A [100]:
For the structure, content and coding of this file, see EFXCAPConfigData in 3GPP TS 31.103 [2].
NOTE: If this file is present in both the USIM and the ISIM, the file in the ISIM is used. It is assumed that the
presence of this file in the USIM when an ISIM is present on the UICC is an incorrect configuration of
the UICC.
This EF contains NAS configuration MO having a list of EARFCNs and associated geographical area coordinates
configured in the UE for initial cell search of MTC carrier or NB-IoT carrier.
Each EARFCN List TLV data object shall contain one EARFCN and one or more Geographical Area objects.
3GPP
Release 15 131 3GPP TS 31.102 V15.21.0 (2018-0610)
NOTE: The upper limit of 15 specified in 3GPP TS 23.032 [9] for the number of points in a polygon shape does
not apply to the number of coordinates in a geographical area described as a polygon here.
This EF contains the following 5GS location information for 3GPP access:
b8 b7 b6 b5 b4 b3 b2 b1
MSB
3GPP
Release 15 132 3GPP TS 31.102 V15.21.0 (2018-0610)
b8 b7 b6 b5 b4 b3 b2 b1
MSB
Coding:
byte 18:
Bits: b3 b2 b1.
0 0 0 : 5U1 UPDATED.
0 0 1 : 5U2 NOT UPDATED.
0 1 0 : 5U3 ROAMING NOT ALLOWED.
0 1 1 : reserved.
1 0 0 : reserved.
1 0 1 : reserved.
1 1 0 : reserved.
1 1 1 : reserved.
Bits b4 to b8 are RFU (see TS 31.101 [11]).
This EF contains KAUSF and KSEAF that are generated on the ME using CK and IK as part of AKA procedures as
described in TS 33.501 [105].
3GPP
Release 15 133 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents:
- KAUSF as described in TS 33.501[105]).
Coding:
- The most significant bit of KAUSF is the most significant bit of the 1st byte of this TLV value field. The least
significant bit of KAUSF is the least significant bit of the last byte of this TLV value field.
Contents:
- KSEAF as described in TS 33.501[105]).
Coding:
- The most significant bit of KSEAF is the most significant bit of the 1st byte of this TLV value field. The least
significant bit of KSEAF is the least significant bit of the last byte of this TLV value field.
This EF contains the 5GS 3GPP access NAS security context as defined in TS 24.501 [104], consisting of K AMF with the
associated key set identifier, the UE security capabilities, and the uplink and downlink NAS COUNT values. This file
shall contain one record.
3GPP
Release 15 134 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents:
The ngKSI (Key Set Identifier in 5G) as defined in TS 33.501 [105] is coded on 1 byte.
Coding:
b8 b7 b6 b5 b4 b3 b2 b1
ngKSI
bits b4 to b8 are coded 0
Contents:
The KAMF as defined in TS 33.501 [105] is coded on 32 bytes. The ME shall treat any KAMF values stored in this EF
as invalid if the ngKSI indicates that no KAMF is available or if the length indicated in the KAMF TLV is set to '00',
Coding:
The most significant bit of KAMF is the most significant bit of the 1st byte of this TLV value field. The least
significant bit of KAMF is the least significant bit of the last byte of this TLV value field.
Contents:
Coding:
The most significant bit of the uplink NAS count is the most significant bit of the 1st byte of this TLV value field.
The least significant bit of the uplink NAS count is the least significant bit of the last byte of this TLV value
field.
Contents:
3GPP
Release 15 135 3GPP TS 31.102 V15.21.0 (2018-0610)
Coding:
The most significant bit of the downlink NAS count is the most significant bit of the 1st byte of this TLV value field.
The least significant bit of the downlink NAS count is the least significant bit of the last byte of this TLV value
field.
Contents:
The identifiers of selected NAS integrity and encryption algorithms as defined in TS 33.501 [105] and TS 24.501
[104]. In this release the identifiers of selected NAS integrity and encryption algorithms are coded as 4-bit
identifiers.
Coding:
Least significant bit of the security algorithm identifier is the b1 of this TLV value field. Most siginificant bit of the
security algorithm identifier is b4 of this TLV value field as per the NAS security algorithms identifer element
defined in TS 33.501 [105].
b8 b7 b6 b5 b4 b3 b2 b1
This EF contains the 5GS non-3GPP access NAS security context as defined in TS 24.501 [104], consisting of K AMF
with the associated key set identifier, the UE security capabilities, and the uplink and downlink NAS COUNT values.
This file shall contain one record.
3GPP
Release 15 136 3GPP TS 31.102 V15.21.0 (2018-0610)
If "SUCI calculation is to be performed by the USIM" (i.e. Service n°124 is "available" and Service n°125 is
"available"), this file shall not be available to the ME.
If Service n°124 is not "available", this file shall not be available to the ME. This EF contains at least one SUCI
calculation Information data object information needed by the ME for the support of sSubscription identifier privacy as
defined in 3GPP TS 33.501[105]. The number of SUCI calculation information data object depends on the number of
Home Network Public Keys.
3GPP
Release 15 137 3GPP TS 31.102 V15.21.0 (2018-0610)
The Protection Scheme Identifier represents a protection scheme as described in 3GPP TS 33.501 [105] and it is
coded in one byte as follows:
b8 b7 b6 b5 b4 b3 b2 b1
The Key Index is coded in one byte such that its value indicates the position of the Home Network Public Key in the
Home Network Public Key List data object, that is applicable to the Protection Scheme. A Key Index with a value
of "1" refers to the first Network Public Key entry in the Home Network Public Key List, and so on. A Key Index
with a value of "0" indicates that there is no Home Network Public Key associated with that Protection Scheme
(e.g., in the case of null-scheme).
Contents:
This data object contains a list of the Home Network Public Key and the corresponding Home Network Public Key
Identifier that shall be used by the ME to calculate the SUCI.
This data object may not be be present if none of the protection scheme profiles identified by the Protection Scheme
Identifiers included in the Protection Scheme Identifier List data object use the Home Network Public Key (e.g.
null-scheme). If this data object is present, it shall contain at least one Home Network Public Key and the
corresponding Home Network Public Key Identifier..
Coding:
Each Home Network Public Key data object shall only contain one Home Network Public Key Identifier and one
Home Network Public Key value.
3GPP
Release 15 138 3GPP TS 31.102 V15.21.0 (2018-0610)
Editor’s Note: Coding of the Home Network Public Key Identifier and Home Network Public Key are FFS.
- Routing Information TLV data object.
Contents:
This data object contains Routing Indicator that allows together with the MCC and MNC to route network signalling
with SUCI to AUSF and UDM instances capable to serve the subscriber, as specified in 3GPP TS 23.003 [25]. This
data object may not be present in the case of null-scheme. If this data object is present, it shall have a valid Routing
Indicator.
Coding:
Description Value M/O/C Length (bytes)
Routing Information TLV data object tag 'A2' C 1
Routing Information TLV data object L1 C Note 1
length
Routing Information TLV data object value -- C L1
Note 1: The length is coded according to ISO/IEC 8825-1 [35]
Editor’s Note: Contents and coding of the above data object TLV value is are FFS.
This EF contains the configuration information pertaining to access identities allocated for specific high priority
services that can be used by the subscriber. The assigned access identities are used, in combination with
an access category, to control the access attempts. For more information see TS°22.261°[106] and
TS°24.501°[104].
- Configuration of certain Unified Access Control (UAC) access identities specified in configuration according
to TS°24.501°[104]°subclause°4.5.2.
Coding:
3GPP
Release 15 139 3GPP TS 31.102 V15.21.0 (2018-0610)
Byte 1:
b8 b7 b6 b5 b4 b3 b2 b1
Byte(s) 2 to 4X:
This file allows the HPLMN to configure the support of the USIM for Steering of UE in VPLMN. The procedure is
specified in 3GPP TS 23.122 [31]
Coding:
Byte 1:
3GPP
Release 15 140 3GPP TS 31.102 V15.21.0 (2018-0610)
b8 b7 b6 b5 b4 b3 b2 b1
Byte 2 is RFU.
DFGSM-ACCESS '5F3B'.
DFMexE '5F3C'.
DFWLAN '5F40'.
DFHNB '5F50'.
DFSoLSA '5F70'.
DFProSe '5F90'.
DFACDC '5FA0'
DFTV '5FB0'
DF5GS '5FC0'
Note 1: The DF identifier '5F80' is reserved for OMA BCAST Smart Card Profile [49]
Note 2: DF for application specific phonebook. This DF has the same structure as the DFPHONEBOOK under DFTELECOM.
The Efs contain information about the users subscribed local service areas.
3GPP
Release 15 141 3GPP TS 31.102 V15.21.0 (2018-0610)
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 EFSLL. 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).
Access Conditions:
READ PIN
UPDATE ADM
DEACTIVATE ADM
ACTIVATE ADM
Contents: indicates whether the MS is restricted to use LSA cells only or not.
Coding:
b8 b7 b6 b5 b4 b3 b2 b1
- the SMS default 7-bit coded alphabet as defined in TS 23.038 [5] 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 the annex of TS 31.101 [11].
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.
3GPP
Release 15 142 3GPP TS 31.102 V15.21.0 (2018-0610)
Access Conditions:
READ PIN
UPDATE PIN
DEACTIVATE ADM
ACTIVATE ADM
- 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.
- the SMS default 7-bit coded alphabet as defined in TS 23.038 [5] with bit 8 set to 0. The alpha identifier
shall be left justified. Unused bytes shall be set to 'FF'; or
- 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
Contents: The idle mode support is used to indicate whether the ME shall favour camping on the LSA cells in
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.
3GPP
Release 15 143 3GPP TS 31.102 V15.21.0 (2018-0610)
- Icon Identifier
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
- PLMN code
Contents: these bytes identify the EF which contains the LSA Descriptors forming the LSA.
Contents: this byte identifies the number of the first record in the LSA Descriptor file forming the LSA.
Coding: binary.
3GPP
Release 15 144 3GPP TS 31.102 V15.21.0 (2018-0610)
Access Conditions:
READ PIN
UPDATE ADM
DEACTIVATE ADM
ACTIVATE ADM
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
Coding: binary, with b8 as MSB and b3 as LSB leaving room for 64 LSA Descriptors per record.
- LSA Descriptor
3GPP
Release 15 145 3GPP TS 31.102 V15.21.0 (2018-0610)
- 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.
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 3GPP TS 31.101 [11].
The UICC may contain a global phonebook, or application specific phonebooks, or both in parallel. When both
phonebook types co-exist, they are independent and no data is shared. In this case, when the terminal supports
application specific phonebooks, it shall be possible for the user to select which phonebook the user would like to
access.
Support of the global phonebook is mandatory, except for Terminals of type ND, NK or NS, as specified in 3GPP TS
31.111 [12] Annex P, for which support is optional. Terminals that support the global phonebook shall conditionally
support, the application specific phonebooks, also known as local phonebook. The support of local phone book is:
NOTE 1: Such terminals could be of type "Smartphone" as described in GSMA: "IMEI Allocation and Approval
Process" [84].
NOTE 2: Such terminals could be of type "Feature Phone" as described in GSMA: "IMEI Allocation and Approval
Process" [84].
It is recommended that the terminal searches for the global phonebook located under DF TELECOM as its presence is not
indicated anywhere in the USIM application.
The global phonebook is located in DFPHONEBOOK under DFTELECOM.. Each specific USIM application phonebook is
located in DFPHONEBOOK of its respective Application ADFUSIM. The organisation of files in DFPHONEBOOK under ADFUSIM
and under DF TELECOM follows the same rules. Yet DFPHONEBOOK under ADFUSIM may contain a different set of files than
DFPHONEBOOK under DFTELECOM. All phonebook related Efs are located under their respective DFPHONEBOOK. USIM specific
phonebooks are dedicated to application specific entries. Each application specific phonebook is protected by the
application PIN.
EFADN and EFPBR shall always be present if the DFPhonebook is present. If any phonebook file other than EFADN or EFEXT1,
is used, then EFPBC shall be present.
If a GSM application resides on the UICC, the Efs ADN and EXT1 from one DFPHONEBOOK (defined at GSM application
installation) are mapped to DFTELECOM. Their file Ids are specified in 3GPP TS 51.011 [18], i.e. EFADN = '6F3A' and
EFEXT1 = '6F4A', respectively.
If the UICC is inserted into a terminal accessing the ADN and EXT1 files under DF TELECOM; and a record in these files
has been updated, a flag in the corresponding entry control information in the EFPBC is set from 0 to 1 by the UICC. If
the UICC is later inserted into a terminal that supports the global and/or application specific phonebook, the terminal
shall check the flag in EFPBC and if this flag is set, shall update the EFCC, and then reset the flag. A flag set in EFPBC
results in a full synchronisation of the phonebook between an external entity and the UICC (if synchronisation is
requested).
The EF structure related to the public phonebook is located under DFPHONEBOOK in DFTELECOM. A USIM specific
phonebook may exist for application specific entries. The application specific phonebook is protected by the application
PIN. The organisation of files in the application specific phonebook follows the same rules as the one specified for the
3GPP
Release 15 146 3GPP TS 31.102 V15.21.0 (2018-0610)
public phone book under DFTELECOM. The application specific phonebook may contain a different set of files than the one
in the public area under DFTELECOM.
Certain kinds of Efs can occur more than once in the phonebook, e.g. there may be two entities of Abbreviated Dialling
Numbers, EFADN and EFADN1. For these kinds of Efs, no fixed FID values are specified. Instead, the value '4FXX'
indicates that the value is to be assigned by the card issuer. These assigned values are then indicated in the associated
TLV object in EFPBR.
The SFI value assigned to an EF which is indicated in EFPBR shall correspond to the SFI indicated in the TLV object in
EFPBR.
The reference file is a file that contains information how the information in the different files is to be combined together
to form a phone book entry. The reference file contains records. Each record specifies the structure of up to 254 entries
in the phone book. Each phone book entry consists of data stored in files indicated in the reference file record. The
entry structure shall be the same over all the records in the EF PBR. If more than 254 entries are to be stored, a second
record is needed in the reference file. The structure of a phone book entry is defined by different TLV objects that are
stored in a reference file record. The reference file record structure describes the way a record in a file that is part of the
phonebook is used to create a complete entry. Three different types of file linking exist.
Type 1 files: Files that contain as many records as the reference/master file (EF ADN, EFADN1) and are linked on
record number bases (Rec1 -> Rec1). The master file record number is the reference.
Type 2 files: Files that contain less entries than the master file and are linked via pointers in the index
administration file (EFIAP).
Type 3 files: Files that are linked by a record identifier within a record.
The first file ID in the first record of EFPBR indicated using constructed Tag 'A8' is called the master EF. Access
conditions for all other files in the Phonebook structure using Tags 'A8', 'A9' or 'AA' is set to the same as for the master
EF unless otherwise specified in the present document.
File Ids indicated using constructed Tag 'A8' is a type 1 file and contains the same number of records as the first file
that is indicated in the data part of this TLV object. All files following this Tag are mapped one to one using the record
numbers/Ids of the first file indicated in this TLV object.
File Ids indicated using constructed Tag 'A9' are mapped to the master EF (the file ID indicated as the first data object
in the TLV object using Tag 'A8') using the pointers in the index administration file. The order of the pointers in the
index administration file is the same as the order of the file Ids presented after Tag 'A9'. If this Tag is not present in the
reference file record the index administration file is not present in the structure. In case the index administration file is
not present in the structure it is not indicated in the data following tag 'A8'.
File Ids indicated using constructed Tag 'AA' indicate files that are part of the reference structure but they are addressed
using record identifiers within a record in one or more of the files that are part of the reference structure. The length of
the tag indicates whether the file to be addressed resides in the same directory or if a path to the file is provided in the
TLV object.
3GPP
Release 15 147 3GPP TS 31.102 V15.21.0 (2018-0610)
Type 2 and type 3 files contain records that may be shared between several phonebook entries (except when otherwise
indicated). The terminal shall ensure that a shared record is emptied when the last phonebook entry referencing it is
modified in such a way that it doesn't reference the record anymore.
NOTE: in the current version of the specification, only type 3 files contain records that may be shared.
Each constructed Tag contains a list of primitive Tags indicating the order and the kind of data (e.g. ADN, IAP,…) of
the reference structure.
The primitive tag identifies clearly the type of data, its value field indicates the file identifier and, if applicable, the SFI
value of the specified EF. That is, the length value of a primitive tag indicates if an SFI value is available for the EF or
not:
Table 4.2: Tag definitions for the phone book kind of file
Table 4.3 (below) lists the allowed types for each kind of file:
3GPP
Release 15 148 3GPP TS 31.102 V15.21.0 (2018-0610)
At the end of each record, unused bytes, if any, shall be filled with 'FF'.
The EF contains pointers to the different records in the files that are part of the phone book. The index administration
file record number/ID is mapped one to one with the corresponding EFADN (shall be record to record). The index
administration file contains the same amount of records as EFADN. The order of the pointers in an EFIAP shall be the same
as the order of file Ids that appear in the TLV object indicated by Tag 'A9' in the reference file record. The amount of
bytes in a record is equal to the number of files indicated the EFPBR following tag 'A9'.
The value 'FF' is an invalid record number/ID and is used in any location in to indicate that no corresponding record in
the indicated file is available.
3GPP
Release 15 149 3GPP TS 31.102 V15.21.0 (2018-0610)
- 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 [5] 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 the annex of TS 31.101 [11].
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.
Coding:
- according to TS 24.008 [9].
Coding:
- according to TS 24.008 [9]. 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 24.008 [9]). Accordingly, the ME should not interpret the value 'FF' and not send it over the radio
interface.
B8 b7 b6 b5 b4 b3 b2 b1
NPI
TON
1
3GPP
Release 15 150 3GPP TS 31.102 V15.21.0 (2018-0610)
Coding:
- according to TS 24.008 [9], TS 22.030 [4] and the extended BCD-coding (see table 4.4). 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 EFEXT1. 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 of Digit 1
:
:
MSB of Digit 1
LSB of Digit 2
:
:
MSB of Digit 2
Byte X+4:
B8 b7 B6 b5 b4 b3 b2 b1
LSB of Digit 3
:
:
MSB of Digit 3
LSB of Digit 4
:
:
MSB of Digit 4
etc.
Coding:
- binary.
Coding:
- binary.
3GPP
Release 15 151 3GPP TS 31.102 V15.21.0 (2018-0610)
NOTE 3: EFADN in the public phone book under DFTELECOM may be used by USIM, GSM and also other applications
in a multi-application card. If the non-GSM application does not recognise the use of Type of Number
(TON) and Number Plan Identification (NPI), then the information relating to the national dialling plan
shall be held within the data item dialling number/SSC and the TON and NPI fields set to UNKNOWN.
This format would be acceptable for 3G 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 [22] numbering plan.
NOTE 4: When the ME acts upon the EFADN with a SEARCH RECORD 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 SEARCH RECORD parameters are less than or equal to the value of X if the MMI allows the
user to offer a greater number.
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 22.101 [24]).
- an ADN/SSC which is greater than the 20 digit capacity of the ADN/SSC Elementary File or where common
digits are required to follow an ADN/SSC string of less than 20 digits. The remainder is stored in this EF as a
record, which is identified by a specified identification byte inside the ADN/SSC Elementary File. The EXT1
record in this case is specified as additional data;
- an associated called party subaddress. The EXT1 record in this case is specified as subaddress data.
3GPP
Release 15 152 3GPP TS 31.102 V15.21.0 (2018-0610)
- Record type.
Contents:
- type of the record.
Coding:
B8 b7 b6 b5 b4 b3 b2 b1
The following example of coding means that the type of extension data is "additional data":
B8 b7 b6 b5 b4 b3 b2 b1
0 0 0 0 0 0 1 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. The coding
of remaining bytes is BCD, according to the coding of ADN/SSC. Unused nibbles at the end shall 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. In this case byte 2 (first byte
of the extension data) of all records for additional data within the same chain indicates the number of
bytes ('01' to '0A') for ADN/SSC (respectively MSISDN, LND) within the same record unequal to 'FF'.
Case 2, Extension1 record is Called Party Subaddress:
- The subaddress data contains information as defined for this purpose in TS 24.008 [9]. All information
defined in TS 24.008, except the information element identifier, shall be stored in the USIM. 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.
3GPP
Release 15 153 3GPP TS 31.102 V15.21.0 (2018-0610)
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 EFADN is set to 3.
In this example, ADN/SSC is associated to additional data (records 3 and 4) which represent the last 27 or 28 digits of
the whole ADN/SSC (the first 20 digits are stored in EFADN) and a called party subaddress whose length is more than 11
bytes (records 6 and 1).
The content of EFPBC is linked to the associated EFADN record by means of the ADN record number/ID (there is a one to
one mapping of record number/identifiers between EFPBC and EFADN).
Coding:
3GPP
Release 15 154 3GPP TS 31.102 V15.21.0 (2018-0610)
b8 B7 b6 B5 b4 B3 b2 B1
- Hidden Information.
Contents:
indicates to which USIM application of the UICC this phone book entry belongs, so that the corresponding secret code
can be verified to display the phone book entry. If the secret code is not verified, then the phone book entry is hidden.
Coding:
'00' – the phone book entry is not hidden;
'xx' – the phone book entry is hidden. 'xx' is the record number in EFDIR of the associated USIM application.
Content:
- indicates if the associated entry is part of a group, in that case it contains the record number of the group name in
EFGAS.
- One entry can be assigned to a maximum of 10 groups.
Coding:
- '00' – no group indicated;
'XX' – record number in EFGAS containing the alpha string naming the group of which the phone book entry is a
member.
3GPP
Release 15 155 3GPP TS 31.102 V15.21.0 (2018-0610)
Structure of EFAAS
Content:
- user defined text for additional number.
Coding:
- same as the alpha identifier in EFADN.
Structure of EFGAS
Content:
- group names.
Coding:
- same as the alpha identifier in EFADN.
3GPP
Release 15 156 3GPP TS 31.102 V15.21.0 (2018-0610)
Structure of EFANR
Content:
- describes the type of the additional number defined in the file EFAAS.
Coding:
- '00' – no additional number description;
'xx' – record number in EFAAS describing the type of number (e.g. "FAX");
'FF' – free record.
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 additional number/SSC information
length is greater than 11. When the additional number/SSC has extension, it is indicated by the extension1 identifier
being unequal to 'FF'. The remainder is stored in the EFEXT1 with the remaining length of the additional data being coded
in the appropriate additional record itself (see clause 4.4.2.4).
Coding:
- same as the length of BCD number/SSC string byte in EFADN.
Contents:
- Type of number (TON) and numbering plan identification (NPI).
Coding:
- same as the TON and NPI byte in EFADN.
Content:
- up to 20 digits of the additional phone number and/or SSC information linked to the phone book entry.
Coding:
- same as the dialling number /SSC string in EFADN.
3GPP
Release 15 157 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents:
- This byte identifies the number of a record in the EFCCP1 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.
Contents:
- 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 number requires both additional data and called party subaddress, this byte identifies the additional record. A
chaining mechanism inside EFEXT1 identifies the record of the appropriate called party subaddress (see clause 4.4.2.4).
Coding:
- binary.
Content:
- Short File identifier of the associated EFADN file.
Coding:
- as defined in the UICC specification.
Content:
- record identifier of the associated phone book entry.
Coding:
- 'xx' – record identifier of the corresponding ADN record.
Structure of EFSNE
Content:
- string defining the second name of the phone book entry.
3GPP
Release 15 158 3GPP TS 31.102 V15.21.0 (2018-0610)
Coding:
- as the alpha identifier for EFADN.
Content:
- Short File identifier of the associated EFADN file.
Coding:
- as defined in the UICC specification.
Content:
record identifier of the associated phone book entry.
Coding:
'xx' – record identifier of the corresponding ADN record.
Structure of EFCCP1
If synchronisation is supported in the phonebook, then EFPSC, EFUID, EFPUID and EFCC are all mandatory.
3GPP
Release 15 159 3GPP TS 31.102 V15.21.0 (2018-0610)
If/when the PBID is regenerated, all UIDs for the entry in the phone book shall be assigned new values starting from 1.
If more than one EFUID exists (i.e. multiple phone book file sets) then all values of UIDs used in that phone book shall
be unique over all phone book file sets within that phone book. The new value of the UID for each entry shall then be
kept until the PBID is regenerated again.
Structure of EFUID
Content:
- number to unambiguously identify the phone book entry for synchronisation purposes.
Coding:
- hexadecimal value. At initialisation all UIDs are personalised to ''00 00'' (i.e. empty).
The PSC is also used to regenerate the UIDs and reset the CC to prevent them from running out of range. When the
UIDs or the CC has reached its maximum value, a new PSC is generated. This leads to a scenario where neither the CC
nor the UIDs will run out of range.
The PSC shall be regenerated by the terminal if one of the following situation applies:
- the values of the UIDs have run out of range;
- the whole phone book has been reset/deleted;
- the value of the CC has run out of range.
Structure of EFPSC
3GPP
Release 15 160 3GPP TS 31.102 V15.21.0 (2018-0610)
Content:
number to unambiguously identify the status of the phone book for synchronisation purposes.
Coding:
hexadecimal value.
The phone book identifier (PBID) coding based on the EFPSC is described hereafter:
- PBID = ICCid (10bytes) "fixed part" + 4 bytes (in EFPSC) "variable part".
- PBID = 10 last bytes of (ICCid XOR AID) "fixed part" + 4 bytes (in EFPSC) "variable part".
To be able to detect if the PSC needs to be regenerated (i.e. the variable part) the following test shall be made by
the terminal before for each update of either the CC or the assignment of a new UID:
- Each time the terminal has to increment the value of the UID the following test is needed:
{Increment PSC mod 'FF FF FF FF'; all the UIDs shall be regenerated}.
- Each time the terminal has to increment the value of CC the following test is needed:
NOTE: If the phonebook is deleted then the terminal will change the PSC according to:
Every update/deletion of an existing phone book entry or the addition of a new phone book entry causes the terminal to
increment the EFCC. The concept of having a CC makes it possible to update the phone book in different terminals,
which still are able to detect the changes (e.g. changes between different handset and/or 2 nd and 3rd generation of
terminals).
Structure of EFCC
Content:
- indicates recent change(s) to phone book entries for synchronisation purposes.
3GPP
Release 15 161 3GPP TS 31.102 V15.21.0 (2018-0610)
Coding:
- hexadecimal value. At initialisation, CC shall be personalised to '00 00' (i.e. empty).
Structure of EFPUID
Content:
- Previous number that was used to unambiguously identify the phone book entry for synchronisation purposes.
Coding:
- As for EFUID
Structure of EFEMAIL
3GPP
Release 15 162 3GPP TS 31.102 V15.21.0 (2018-0610)
- E-mail Address.
Content:
- string defining the e-mail address
Coding:
- the SMS default 7-bit coded alphabet as defined in TS 23.038 [5] with bit 8 set to 0. The alpha identifier shall be left
justified. Unused bytes shall be set to 'FF'.
Content:
- short File identifier of the associated EFADN file.
Coding:
- as defined in TS 31.101 [11].
Content:
- record identifier of the associated phone book entry.
Coding:
- binary.
- if an EFPBR file contains more than one record, then they shall all be formatted identically on a type-by-type
basis, e.g. if EFPBR record #1 contains one type 1 e-mail then all EFPBR records shall have one type 1 email;
- if an EFPBR record contains more than one reference to one kind of file, such as two EFEMAIL files, then they shall
all be formatted identically on a type-by-type basis, e.g. if an EFPBR record has 2 email addresses, then they shall
have the same record size and the same number of records in each EFPBR entry;
- an EFPBR record may contain TLV entries indicating that the file exist as a type 1 and 2 file, e.g. a phonebook
entry may have two emails, one with a one-to-one mapping (type 1) and one with a indirect mapping (type 2).
Regardless of the type, files in all entries shall have the same record configuration;
- an EFPBR record shall not contain more than one occurrence of a given kind of file indicated in tag 'AA' (type 3
link). For instance, an EFPBR record may only contain one reference to an EFEXT1.
3GPP
Release 15 163 3GPP TS 31.102 V15.21.0 (2018-0610)
Structure of EFPURI
- URI Address.
Content:
- The URI Address associated to the ADN Record.
Coding:
- Same as URI TLV data object in EFIMPU defined in TS 31.103 [64].
Content:
- Short File identifier of the associated EFADN file.
Coding:
- as defined in TS 31.101 [11].
Content:
- record identifier of the associated phone book entry.
Coding:
- binary.
The presence of this DF and thus the support of a GSM access is indicated in the 'USIM Service Table' as service no.
'27' being available.
3GPP
Release 15 164 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains the ciphering key Kc and the ciphering key sequence number n for enciphering in a GSM access
network.
b8 b7 b6 b5 b4 b3 b2 b1
N
bits b4 to b8 are coded 0
NOTE: TS 24.008 [9] defines the value of n=111 as "key not available". Therefore the value '07' and not 'FF'
should be present following the administrative phase.
This EF contains the ciphering key KcGPRS and the ciphering key sequence number n for GPRS (see TS 23.060 [7]).
3GPP
Release 15 165 3GPP TS 31.102 V15.21.0 (2018-0610)
b8 b7 b6 b5 b4 b3 b2 b1
n
bits b4 to b8 are coded 0
NOTE: TS 24.008 [9] defines the value of n=111 as "key not available". Therefore the value '07' and not 'FF'
should be present following the administrative phase.
4.4.3.3 Void
CPBCCH storage may reduce the extent of a Mobile Station's search of CPBCCH carriers when selecting a cell. The
CPBCCH carrier lists shall be in accordance with the procedures specified TS 23.022 [29]. The MS stores CPBCCH
information (from the System Information 19 message, Packet System Information 3, and Packet System Information 3
bis) on the USIM. The same CPBCCH carrier shall never occur twice in the list.
b8 b7 b6 b5 b4 b3 b2 b1
LSB of ARFCN
:
:
:
:
:
:
:
b8 b7 b6 b5 b4 b3 b2 b1
:
MSB of ARFCN
High/Low band indicator
bits b4 to b7 are RFU
Empty indicator
- 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',
3GPP
Release 15 166 3GPP TS 31.102 V15.21.0 (2018-0610)
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 valid 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.
This EF contains two flags used to control the investigation scan for higher prioritized PLMNs not offering voice
services.
Coding:
b8 b7 b6 b5 b4 b3 b2 b1
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.
The presence of this DF is indicated in the 'USIM Service Table' as service no. '41' being available.
The Efs in the Dedicated File DFMexE contain execution environment related information.
3GPP
Release 15 167 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF indicates which MexE services are available. If a service is not indicated as available in the USIM, the ME
shall not select this service.
-Services
Contents: Service n°1: Operator Root Public Key
Service n°2: Administrator Root Public Key
Service n°3: Third Party Root Public Key
Service n°4: RFU
Coding:
the coding rules of the USIM Service Table apply to this table.
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 in the USIM. Each record of this EF contains one certificate descriptor.
For example, an operator may provide a second key for recover disaster procedure in order to limit OTA data to load.
- Parameter indicator
Contents:
The parameter indicator indicates if record is full and which optional parameters are present
3GPP
Release 15 168 3GPP TS 31.102 V15.21.0 (2018-0610)
b8 b7 b6 b5 b4 b3 b2 b1
- Flags
Contents:
The authority flag indicates whether the certificate identify an authority (i.e. CA or AA) or not.
b8 b7 b6 b5 b4 b3 b2 b1
- 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
Contents:
these bytes identify an EF which is the key/certificate data file (see clause 4.4.4.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.
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
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.
3GPP
Release 15 169 3GPP TS 31.102 V15.21.0 (2018-0610)
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 [30].
Coding:
octet string
NOTE: transparent key/certificate data longer than 256 bytes may be read using successive READ BINARY
commands.
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 in the USIM. Each record of this EF contents one certificate descriptor.
For contents and coding of all data items see the respective data items of the EF ORPK (clause 4.4.4.2).
3GPP
Release 15 170 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains descriptor(s) of certificates containing the Third Party root public key (s). This EF shall only be
allocated if the USIM issuer wishes to verify applications and certificates in the MexE Third Party domain using root
public key(s) held in the USIM. 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.
Coding:
binary
- Certificate identifier
Contents:
This field identifies the issuer and provides an easy way to find a certificate. For more information about the value and
usage see TS 23.057 [30].
Coding:
Octet string
For contents and coding of all other data items see the respective data items of the EF ORPK (clause 4.4.4.2).
3GPP
Release 15 171 3GPP TS 31.102 V15.21.0 (2018-0610)
Key/certificate data are accessed using the key/certificates descriptors provided by EF TPRPK (see clause 4.4.4.4).
The identifier '4FXX' shall be different from one key/certificate data file to another. For the range of 'XX', see
TS 31.101 [11]. The length Y may be different from one key/certificate data file to another.
DFWLAN shall be present at the ADFUSIM level if either of the services nº59, nº60, nº61, nº62, nº63, nº66, n°81, n°82,
n°83, n°84 or n°88 are "available" in the corresponding EFUST (USIM Service Table).
This EF contains a temporary user identifier (pseudonym) for subscriber identification. Pseudonyms may be provided
as part of a previous authentication sequence. Pseudonyms are used as defined in TS 24.234 [40].
-Pseudonym Length
Contents:
- these bytes give the number of bytes of the following data item containing the Pseudonym value.
Coding:
- unsigned length coded on 2 bytes
- Pseudonym.
Contents:
Coding:
- As described for the user portion of the NAI in TS 33.234 [41]. Unused bytes shall be set to 'FF' and shall
not be considered as a part of the value.
3GPP
Release 15 172 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains the coding for preferred PLMNs to be used for WLAN PLMN Selection. This information is
determined by the user and defines the preferred PLMNs of the user in priority order. The first PLMN entry indicates
the highest priority and the nth PLMN entry indicates the lowest. It shall be possible to store at least the number of
PLMNs specified in TS 24.234 [40].
- PLMN
Contents:
- Mobile Country Code (MCC) followed by the Mobile Network Code (MNC).
Coding:
- according to TS 24.008 [9].
This EF contains the coding for operator preferred PLMNs to be used for WLAN PLMN Selection. This information is
determined by the operator and defines the operator preferred PLMNs in priority order. The first PLMN entry indicates
the highest priority and the nth PLMN entry indicates the lowest. It shall be possible to store at least the number of
PLMNs specified in TS 24.234 [40].
3GPP
Release 15 173 3GPP TS 31.102 V15.21.0 (2018-0610)
- PLMN
Contents:
- Mobile Country Code (MCC) followed by the Mobile Network Code (MNC).
Coding:
- according to TS 24.008 [9].
This file contains the user preferred list of WLAN specific identifier (WSID) for WLAN selection in priority order. The
first record indicates the highest priority and the nth record indicates the lowest. This file is used for WLAN selection
and shall store a list of at least the number of WSIDs specified in TS 24.234 [40].
-Length of WSID
Contents:
- this byte gives the number of bytes of the following data item containing the WSID.
Coding:
- unsigned length coded on one byte
-WSID
Contents:
- WLAN specific identifier (WSID) as defined in TS 24.234 [40].
Coding:
- binary. Unused bytes shall be set to 'FF' and not used either as a part of the value or for length calculation.
This file contains the operator preferred list of WLAN specific identifier (WSID) for WLAN selection in priority order.
The first record indicates the highest priority and the nth record indicates the lowest. This file is used for WLAN
selection It shall be possible to store at least the number of PLMNs specified in TS 24.234 [40].
3GPP
Release 15 174 3GPP TS 31.102 V15.21.0 (2018-0610)
-Length of WSID
Contents:
- this byte gives the number of bytes of the following data item containing the WSID.
Coding:
- unsigned length coded on one byte
-WSID
Contents:
- WLAN specific identifier (WSID) as defined in TS 24.234 [40].
Coding:
- binary. Unused bytes shall be set to 'FF' and not used either as a part of the value or for length calculation.
This EF contains a list of parameters linked to a re-authentication identity to be used in fast re-authentication. Re-
authentication identities and related parameters (Master Key and Counter Value) are provided as part of a previous
authentication sequence.
- Reauthentication Identity
Contents:
- Re-authentication identity TLV to be used as the username part of the NAI.
Coding:
Tag '80'
Unsigned length on 1 byte
Value: As described for the user portion of the NAI in TS 33.234 [41]. Unused bytes shall be set to 'FF' and shall not be
considered as a part of the value.
- Master Key
Contents:
- Master Key TLV.
Coding:
Tag '81'
Unsigned length on 1 byte
Value: As described in TS 33.234 [41].
3GPP
Release 15 175 3GPP TS 31.102 V15.21.0 (2018-0610)
- Counter
Contents:
- Counter TLV
Coding:
Tag '82'
Unsigned length on 1 byte
Value: As described in TS 33.234 [41].
This file contains the Home I-WLAN specific identifier list (WSID list) for I-WLAN selection in priority order. The
WSIDs in this list are known to connect to the HPLMN. The first record indicates the highest priority and the n th record
indicates the lowest. This file is used for I-WLAN selection. It shall be possible to store at least the number of WSIDs
specified in TS 24.234 [40].
This EF contains an indication to the ME for the presentation of the available EHPLMN(s) during I-WLAN selection
procedures. The usage of the I-WLAN EHPLMN presentation indication is defined in TS 24.234 [40].
Coding:
- '00' - No preference for the display mode
3GPP
Release 15 176 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains an indication to the ME for the selection of the I-WLAN EHPLMN or the I-WLAN last Registered
PLMN. The usage of the I-WLAN HPLMN Priority Indication file is defined in TS 24.234 [40].
Coding:
- '00' - The UE shall attempt registration on the last I-WLAN RPLMN as described in TS 24.234 [40]
- '01' - The UE shall attempt registration on the I-WLAN home network as described in TS 24.234 [40]
This EF contains I-WLAN Last Registered PLMN Selection. The usage of the I-WLAN Last Registered PLMN is
defined in TS 24.234 [40].
Coding:
- according to TS 24.008 [9].
3GPP
Release 15 177 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains HPLMN Direct Access related informations. The usage of the HPLMN Direct Access Indicator file is
defined in TS 24.234 [40].
Coding:
- '00' – HPLMN Direct Access Indicator is disabled
4.4.6.1 Introduction
This clause describes the additional files that are used for Home (e)NodeB purposes.
DFHNB shall be present at the ADFUSIM level if service nº86 and/or service nº90 isare "available" in EFUST .
This EF contains the coding for CSG ID belonging to the Allowed CSG lists. Furthermore, for each CSG ID in the list,
a link to the corresponding HNB name and CSG Type may be provided.
The CSG List TLV object shall contain only one PLMN TLV object, Tag '80', and at least one CSG information TLV,
Tag '81'. A record may contain one or more CSG List TLV objects. This means that all CSG Ids in one CSG List TLV
object belong to the same PLMN.
3GPP
Release 15 178 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents:
Mobile Country Code (MCC) followed by the Mobile Network Code (MNC).
Coding:
Contents:
Coding:
a value of '00' indicates that the CSG Type is to be taken from other sources (e.g. stored in the non-
volatile memory of the ME). A value in the range '01' to 'FE' indicates the record number in EF CSGT
that shall be displayed as the CSG Type.
Contents:
Coding:
3GPP
Release 15 179 3GPP TS 31.102 V15.21.0 (2018-0610)
a value of '00' indicates that the HNB name is to be taken from other sources (e.g. broadcasted by the
Home Node B or stored in the non-volatile memory of the ME). A value in the range '01' to 'FE'
indicates the record number in EFHNBN that shall be displayed as the HNB name.
- CSG ID
Contents:
Coding:
the CSG ID shall be encoded as defined in TS 23.003 [25]. The CSG ID is coded left justified, i.e. the
most significant bit of the CSG ID is coded on bit 8 of byte 3, over the number of bits as specified in
TS 23.003 [25] using bytes 3 to W . The unused rightmost bits of byte W shall be set 1.
3GPP
Release 15 180 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains the CSG Type. The CSG Type is defined in TS 22.220 [54]. The association between a CSG ID and
the corresponding CSG Type is provided in EFACSGL. The CSG Type may be provided in text or in graphic format.
Contents:
CSG Type contains either Text CSG Type or Graphic CSG Type or both the Graphic and Text CSG Types
Coding:
Contents:
3GPP
Release 15 181 3GPP TS 31.102 V15.21.0 (2018-0610)
Coding:
- '89' = the Text CSG Type is coded using one of the UCS2 code options as defined in TS 31.101 [11].
Contents:
Tag value for the CSG Type in graphic format with the Icon Qualifier or an Icon Link
Coding:
- '81' = the Graphic CSG Type Icon Link is a pointer to the record number of the corresponding image in
EFIMG,
The icon qualifier indicates to the ME how the icon shall be used.
Coding:
- '01' = icon is self-explanatory, i.e. if displayed, it replaces the corresponding name in text format.
- '02' = icon is not self-explanatory, i.e. if displayed, it shall be displayed together with the corresponding
name in text format.
Coding:
- When the Tag value indicates an URI (i.e. Tag = '80') , the Icon Link shall be encoded to an octet string
according to UTF-8 encoding rules as described in IETF RFC 3629 [48] (e.g.
http://127.0.0.1:3516/pub/files/csgtype.jpg).
- When the Tag value indicates that the Icon Link contains the record number of the corresponding image in
EFIMG (i.e. Tag = '81'), the Icon Link shall be encoded in binary.
3GPP
Release 15 182 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains the HNB name. The HNB name is defined in TS 22.220 [54]. HNB name is a common name referring
to HNB/HeNB. The association between a CSG ID and the corresponding HNB name is provided in EF ACSGL.
Contents:
Coding:
coded using one of the UCS2 code options as defined in TS 31.101 [11].
This EF contains the coding for CSG Ids belonging to the Operator CSG lists. Furthermore, for each CSG ID in the list,
a link to the corresponding HNB name and CSG type may be provided. Within one PLMN the first occurrence of CSG
ID indicates the highest priority CSG ID and the last occurrence indicates the lowest.
NOTE 1: There is no requirement for the ME to take the priority into account.
Additionally, if service n°92 is "available", this EF allows the HPLMN to control, on a per PLMN basis, which
available CSGs are displayed by the ME during a manual CSG selection. If there is no CSG display indicator for a
PLMN, the ME shall display the available CSGs according to the value in EFAD byte 3 bit 2.
NOTE 2: Operators should ensure that all CSG display indicators have the same value if the same PLMN is used in
multiple CSG List TLV objects.
3GPP
Release 15 183 3GPP TS 31.102 V15.21.0 (2018-0610)
The Operator CSG List TLV object shall contain only one PLMN TLV object, Tag '80', and at least one Operator CSG
information TLV, Tag '81'. A record may contain one or more Operator CSG List TLV objects. This means that all
CSG Ids in one Operator CSG List TLV object belong to the same PLMN.
Additionally, the Operator CSG List TLV object may contain one CSG Display Indicator TLV object, if service n°92 is
available.
Contents:
Mobile Country Code (MCC) followed by the Mobile Network Code (MNC).
Coding:
3GPP
Release 15 184 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents:
Coding:
a value of '00' indicates that the CSG Type is to be taken from other sources (e.g. stored in the
non-volatile memory of the ME). A value in the range '01' to 'FE' indicates the record number in
EFCSGT that shall be displayed as the CSG Type.
Contents:
Coding:
a value of '00' indicates that the HNB name is to be taken from other sources (e.g. broadcasted by
the Home Node B or stored in the non-volatile memory of the ME). A value in the range '01' to
'FE' indicates the record number in EFHNBN that shall be displayed as the HNB name.
- CSG ID
Contents:
Coding:
the CSG ID shall be encoded as defined in TS 23.003 [25]. The CSG ID is coded left justified, i.e.
the most significant bit of the CSG ID is coded on bit 8 of byte 3, over the number of bits as
specified in TS 23.003 [25] using bytes 3 to W. The unused rightmost bits of byte W shall be set 1.
Coding:
- '00' All available CSG Ids can be displayed during a manual CSG selection
- '01' Only CSG Ids contained in Operator CSG lists shall be displayed during a manual CSG
selection
This EF contains the Operator CSG Types. The CSG Type is defined in TS 22.220 [54]. The association between an
Operator CSG ID and the corresponding Operator CSG Type is provided in EFOCSGL. The Operator CSG Type may be
provided in text or in graphic format.
3GPP
Release 15 185 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains the Operator HNB names. The HNB name is defined in TS 22.220 [54]. HNB Name is a common
name referring to HNB/HeNB. The association between an Operator CSG ID and the corresponding Operator HNB
name is provided in EFOCSGL.
4.4.7 Void
4.4.8.1 Introduction
This clause describes the additional files that are used for ProSe purposes.
DFProSe shall be present at the ADFUSIM level if service nº101 is "available" in EFUST .
This EF contains the authorized PLMNs for restricted ProSe direct discovery for public safety as described in TS
24.334 [70]. This file shall be used only if the ME is authorized as per content of EFAD or received service authorization
from the ProSe Function.
Each record shall be associated with a different PLMN.
3GPP
Release 15 186 3GPP TS 31.102 V15.21.0 (2018-0610)
- PLMN
Contents:
As described in TS 24.333 [71], the PLMN code of the operator in which the UE is authorised to use ProSe
direct discovery monitoring.
Coding:
As defined for the <X>/MonitoringPolicy/<X>/PLMN leaf in TS 24.333 [71].
- Model
Contents:
Model used for the ProSe direct discovery, as described in TS 24.334 [70].
Coding:
b8 b7 b6 b5 b4 b3 b2 b1
This EF contains the authorized PLMNs for restricted ProSe direct discovery for public safety, as described in TS
24.334 [70]. This file shall be used only if the ME is authorized as per content of EFAD or received service authorization
from the ProSe Function.
3GPP
Release 15 187 3GPP TS 31.102 V15.21.0 (2018-0610)
- PLMN
Contents:
As described in TS 24.333 [71], the PLMN code of the operator in which the UE is authorised to use ProSe
direct discovery announcing.
Coding:
As defined for the <X>/AnnouncingPolicy/<X>/PLMN leaf in TS 24.333 [71].
- Model
Contents:
Model used for the ProSe direct discovery, as described in TS 24.334 [70].
Coding:
b8 b7 b6 b5 b4 b3 b2 b1
NOTE: only usage of the first record is supported in the current release of the specification.
3GPP
Release 15 188 3GPP TS 31.102 V15.21.0 (2018-0610)
- Address type
Contents:
Coding:
A value of '00' indicates FQDN, a value of '01' indicates IPv4, a value of '02' indicates IPv6. All other
values are reserved.
Contents:
Coding:
Depending on the Address type. When the HPLMN ProSe Function type is set to '00', the
corresponding HPLMN ProSe Function Address shall be encoded to an octet string according to UTF-
8 encoding rules as specified in IETF RFC 3629 [48].
This EF contains the radio paramenters to be used for ProSe direct communication for public safety when the UE is not
served by E-UTRAN, as described in TS 24.334 [70]. This file shall be used only if the ME is authorized as per content
of EFAD or received service authorization from the ProSe Function.
The file may contain one or more ProSe Radio parameters TLV data objects.
3GPP
Release 15 189 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents:
Indicates if the ME is authorized to perform ProSe Direct Communication and/or one-to-one ProSe direct
communication when not served by E-UTRAN.
Coding:
b8 b7 b6 b5 b4 b3 b2 b1
Each ProSe Radio parameters TLV data object shall contain one or more Geographical Area objects and one Radio
parameters object.
NOTE: The upper limit of 15 specified in 3GPP TS 23.032 [9] for the number of points in a polygon shape does
not apply to the number of coordinates in a geographical area described as a polygon for ProSe
communications.
3GPP
Release 15 190 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains the radio paramenters to be used for ProSe direct communication for public safety when the UE is not
served by E-UTRAN, as described in TS 24.334 [70]. This file shall be used only if the ME is authorized as per content
of EFAD or received service authorization from the ProSe Function.
Contents:
Indicates if the ME is authorized to perform restricted ProSe Direct Discovery monitoring when not served by
E-UTRAN.
Coding:
b8 b7 b6 b5 b4 b3 b2 b1
Each ProSe Radio parameters TLV data object shall contain one or more Geographical Area objects and one Radio
parameters object.
3GPP
Release 15 191 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents:
A geographical area defined by a polygon with 3 or more points.
Coding:
1 to 3 Latitude of point 1 M 3 bytes
4 to 6 Longitude of point 1 M 3 bytes
7 to 9 Latitude of point 2 M 3 bytes
10 to 12 Longitude of point 2 M 3 bytes
13 to 15 Latitude of point 3 M 3 bytes
16 to 18 Longitude of point 3 M 3 bytes
: : : :
(6n-5) to 6n-3 Latitude of point n M 3 bytes
(6n-2) to 6n Longitude of point n M 3 bytes
Latitude and longitude are coded as defined in subclause 6.1 of 3GPP TS 23.032 [75].
NOTE: The upper limit of 15 specified in 3GPP TS 23.032 [9] for the number of points in a polygon shape does
not apply to the number of coordinates in a geographical area described as a polygon for ProSe
communications.
This EF contains the radio paramenters to be used for ProSe direct communication for public safety when the UE is not
served by E-UTRAN, as described in TS 24.334 [70]. This file shall be used only if the ME is authorized as per content
of EFAD or received service authorization from the ProSe Function.
Contents:
Indicates if the ME is authorized to perform restricted ProSe Direct Discovery announcing when not served by
E-UTRAN.
Coding:
b8 b7 b6 b5 b4 b3 b2 b1
3GPP
Release 15 192 3GPP TS 31.102 V15.21.0 (2018-0610)
Each ProSe Radio parameters TLV data object shall contain one or more Geographical Area objects and one Radio
parameters object.
NOTE: The upper limit of 15 specified in 3GPP TS 23.032 [9] for the number of points in a polygon shape does
not apply to the number of coordinates in a geographical area described as a polygon for ProSe
communications.
This EF contains the policy paramenters to be used for ProSe direct communication for public safety, as described in
TS 24.334 [70]. This file shall be used only if the ME is authorized as per content of EFAD or received service
authorization from the ProSe Function.
3GPP
Release 15 193 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents:
Coding:
Contents:
Contains the ProSe UE ID, equivalent to the layer-2 source address of the sending UE, as defined in
TS 23.303 [73]
Coding:
Contents:
3GPP
Release 15 194 3GPP TS 31.102 V15.21.0 (2018-0610)
IPv4 or IPv6 group IP multicast addressed to be used for ProSe direct communication associated with
the corresponding layer-2 group ID.
Coding:
Contents:
Type of IP address.
Coding:
A value of '01' indicates IPv4, a value of '02' indicates IPv6. All other values are reserved.
Contents:
IPv4 addressed to be used as source, in case of IPv4 address. This TLV shall be ignored if address
type is different from IPv4.
Coding:
IPv4 address
Contents:
Coding:
Contents:
Coding:
This EF contains the authorized PLMNs for ProSe direct communication for public safety, as described in TS 24.334
[70]. This file shall be used only if the ME is authorized as per content of EFAD or received service authorization from
the ProSe Function.
3GPP
Release 15 195 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents:
Contains the PLMNs in which the UE is authorised to perform ProSe direct communication when
served by E-UTRAN
Coding:
Contents:
Indicates if the UE is authorised to use one-to-one and/or one-to-many ProSe direct communication.
Coding:
b8 b7 b6 b5 b4 b3 b2 b1
This EF contains the PTK ID and Counter associated with the PGK currently in use for a ProSe Group.
3GPP
Release 15 196 3GPP TS 31.102 V15.21.0 (2018-0610)
- PTK ID
Contents:
Contains the PTK value, as defined in TS 33.303 [72]
Coding:
As per TS 33.303 [72]
- Counter
Contents:
Contains the Counter for the PGK used in the group, as defined in TS 33.303 [72]
Coding:
As per TS 33.303 [72]
3GPP
Release 15 197 3GPP TS 31.102 V15.21.0 (2018-0610)
-Services
Contents: Service n°1: ProSe direct discovery parameters
Service n°2: HPLMN ProSe Function
Service n°3: ProSe Direct Communication radio parameters
Service n°4: ProSe Direct Discovery monitoring radio parameters
Service n°5: ProSe Direct Discovery announcing radio parameters
Service n°6: ProSe policy parameters
Service n°7: ProSe group counter
Service n°8: ProSe Usage Information Reporting configuration
Service n°9: UICC ProSe Direct Communication usage information reporting
Service n°10 ProSe Group Member Discovery parameters
Service n°11 ProSe Relay parameters
The EF shall contain at least one byte. 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.
Coding:
This EF contains the description of the configuration to be used by the UE for reporting the usage information for direct
communication for public safety, as described in TS 24.334 [70] and TS 32.277 [77]. This file shall be used only if the
UE is authorized for direct communication as per content of EFAD or received service authorization from the ProSe
Function.
3GPP
Release 15 198 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 199 3GPP TS 31.102 V15.21.0 (2018-0610)
- ProSe ServerAddress
Contents:
As described in TS 24.333 [71], used to determine the IPv4 or IPv6 address the UE or the USIM shall use to
send the usage report to. If no server address is provided, the UE shall upload the usage information reports to
the IP address of the HPLMN ProSe Function. If the USIM supports storage of the usage information, the server
address is mandatory.
Coding:
As defined for the ProSe ServerAddress leaf in TS 24.333 [71].
- ProSe CollectionPeriod
Contents:
As described in TS 24.333 [71], contains the time interval, in unit of minutes, at which the UE shall generate the
usage information reports. Setting the CollectionPeriod to a value of 0 disables generation of usage information
reports at the UE.
Coding:
As defined for the ProSe CollectionPeriod leaf in TS 24.333 [71].
- ProSe ReportingWindow
3GPP
Release 15 200 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents:
As described in TS 24.333 [71], contains the time window, in units of minutes, during which the UE shall upload
the usage information report to the server. Setting the ReportingWindow to a value of 0 disables upload of the
usage information reports by the UE.
Coding:
As defined for the ProSe ReportingWindow leaf in TS 24.333 [71].
- ProSe ReportGroupParameters
Contents:
As described in TS 24.333 [71], indicates whether or not the UE shall report the group parameters for one-to-
many ProSe direct communication in the usage information. The default value 0 applies if this TLV is not
provisioned.
Coding:
As defined for the ProSe ReportGroupParameters leaf in TS 24.333 [71].
- ProSe ReportTimeStampsFirstTransmissionAndReception
Contents:
As described in TS 24.333 [71], indicates whether or not the UE shall report the time stamps of the first
transmission/reception during the collection period in the usage information. The default value 0 applies if this
TLV is not provisioned
Coding:
As defined for the ProSe ReportTimeStampsFirstTransmissionAndReception leaf in TS 24.333 [71].
- ProSe ReportDataTransmitted
Contents:
As described in TS 24.333 [71], indicates whether or not the UE shall report the amount of data transmitted
during the collection period in the usage information, and whether with location information. The default value 1
applies if this TLV is not provisioned
Coding:
As defined for the ProSe ReportDataTransmitted leaf in TS 24.333 [71].
- ProSe ReportDataReceived
Contents:
As described in TS 24.333 [71], indicates whether or not the UE shall report the amount of data received during
the collection period in the usage information, and whether with location information. The default value 1
applies if this TLV is not provisioned
Coding:
As defined for the ProSe ReportDataReceived leaf in TS 24.333 [71].
- ProSe ReportTimeStampsOutOfCoverage
Contents:
As described in TS 24.333 [71], indicates whether or not the UE shall report the time stamps when it went in and
out of E-UTRAN coverage during the collection period in the usage information. The default value 0 applies if
this TLV is not provisioned
Coding:
As defined for the ProSe ReportTimeStampsOutOfCoverage leaf in TS 24.333 [71].
- ProSe ReportLocationInCoverage
Contents:
As described in TS 24.333 [71], indicates whether or not the UE shall report the list of locations of the UE when
in E-UTRAN coverage during the collection period in the usage information.
Coding:
As defined for the ProSe ReportLocationInCoverage leaf in TS 24.333 [71].
- ProSe ReportRadioParameters
3GPP
Release 15 201 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents:
As described in TS 24.333 [71], indicates whether or not the UE shall report the radio parameters used for ProSe
direct communication (i.e. indicator of which radio resources used and radio frequency used) during the
reporting period in the usage information.
Coding:
As defined for the ProSe ReportRadioParameters leaf in TS 24.333 [71].
4.4.8.12 EFPROSE_GM_DISCOVERY (ProSe Group Member Discovery Parameters)
If service n°10 is "available" in the ProSe Service Table, this file shall be present.
This EF contains the ProSe discovery parameters for public safety, as described in TS 24.334 [70]. This file shall be
used only if the ME is authorized as per content of EFAD or received service authorization from the ProSe Function.
Each record shall contain at most one Group member discovery parameters information.
Contents:
Indicates the user information which is sent by the announcing or discoverer or discoveree UE over
the air during Group Member Discovery procedures.
Coding:
Contents:
Indicates the group ID of the discovery group that the UE belongs to when group member discovery
is performed.
Coding:
3GPP
Release 15 202 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents:
Indicates the Application Layer Group ID identifying an application layer group that the UE belongs
to.
Coding:
This EF contains the authorized PLMNs for ProSe UE-to-network relay for public safety, as described in TS 24.334
[70]. This file shall be used only if the ME is authorized as per content of EFAD or received service authorization from
the ProSe Function.
Contents:
Contains the PLMNs in which the UE is authorised to act as a ProSe UE-to-network relay and/or use
a ProSe UE-to-network relay.
Coding:
Contents:
3GPP
Release 15 203 3GPP TS 31.102 V15.21.0 (2018-0610)
Indicates if the UE is authorized to act as a ProSe UE-to-network relay and/or use a ProSe UE-to-
network relay.
Coding:
b8 b7 b6 b5 b4 b3 b2 b1
This EF contains the ProSe direct discovery parameters when it is used for ProSe UE-to-network relay discovery for
public safety, as described in TS 24.334 [70]. This file shall be used only if the ME is authorized as per content of EF AD
or received service authorization from the ProSe Function.
User Info ID
Contents:
Indicates the user information which is sent by the announcing or discoverer or discoveree UE over the air during
Group Member Discovery procedures.
Coding:
3GPP
Release 15 204 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents:
Indicates the connectivity service that the ProSe UE-to-network relay provides to public safety
applications.
Coding:
Contents:
Indicates the user information of the ProSe UE-to-network relay that the remote UE seeks to discover
during ProSe UE-to-network relay discovery procedures.
Coding:
Contents:
Indicates the IP version(s) that the remote UE can use for the relay traffic associated with the Relay
Service Code.
Coding:
A value of '01' indicates IPv4, a value of '02' indicates IPv6, a value of '03' indicates IPv4v6. All other
values are reserved.
Contents:
Coding:
3GPP
Release 15 205 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents:
Indicates the connectivity service that the ProSe UE-to-network relay provides to public safety
applications.
Coding:
Contents:
Indicates the IP version of the PDN connection to be used for the relayed traffic associated with a
Relay Service Code.
Coding:
A value of '01' indicates IPv4, a value of '02' indicates IPv6. All other values are reserved.
Contents:
Indicates the PDN connection that the ProSe UE-to-network relay uses for the relayed traffic
associated with a Relay Service Code. If this TLV is missing, then the default APN is used for the
PDN connectivity.
3GPP
Release 15 206 3GPP TS 31.102 V15.21.0 (2018-0610)
Coding:
Contents:
Indicates the link layer identifier used for direct communication associated with a Relay Service
Code.
Coding:
Contents:
Coding:
4.4.9.1 Introduction
This clause describes the additional files that are used for ACDC configuration.
DFACDC shall be present at the ADFUSIM level if service nº108 is "available" in EFUST (USIM Service Table).
This EF contains the link to EFs containing the ACDC for each operating system identifier. The ME parses the content
of the EFACDC_LIST and retrieves the file id and optionally the SFI to further access the relevant ACDC configuration.
3GPP
Release 15 207 3GPP TS 31.102 V15.21.0 (2018-0610)
- OS Id
Contents:
The Operating System identifier
Coding:
A Universally Unique IDentifier (UUID) as specified in IETF RFC 4122 [80].
- File Id
Contents:
File Id of the EF containing the ACDC configuration for the Operating System
Coding:
According to TS 31.101 [11]
- SFI
Contents:
Short File Identifier of the EF containing configuration for the Operating System
Coding:
According to TS 31.101 [11]. The value '0' indicates that SFI is not allocated for the file.
3GPP
Release 15 208 3GPP TS 31.102 V15.21.0 (2018-0610)
ACDC App Id
- ACDC category
Contents:
The ACDC category indicates the category to which the identified application belongs.
Coding:
As the ACDCCategory leaf in 24.105 [81]
- OS App Id
Contents:
indicates an OS specific application identifier
Coding:
As the OSAppId leaf in 24.105 [81]
4.4.10.1 Introduction
This clause describes the additional files that are used for TV service configuration.
DFTV shall be present at the ADFUSIM level if service nº116 is "available" in EFUST (USIM Service Table).
Multiple EFTVUSD files may exist in the DF, each one associated with a different entry in EF TVCONFIG.
3GPP
Release 15 209 3GPP TS 31.102 V15.21.0 (2018-0610)
USD:
Contents:
Coding:
4.4.11.1 Introduction
This clause describes the files that are specific for 5GS.
DF5GS shall be present at the ADFUSIM level if any of the following services are "available" in EFUST (USIM Service
Table):
Service n°122 5GS Mobility Management Information
Service n°123 5G Security Parameters
Service n°124 Subscription identifier privacy support
Service n°125 SUCI calculation by the USIM
Service n°126 UAC Access Identities support
Service n°127 Steering of UE in VPLMN
This EF contains the following 5GS location information for 3GPP access:
3GPP
Release 15 210 3GPP TS 31.102 V15.21.0 (2018-0610)
Coding:
as the 5G-GUTI part of the 5GS mobile identity information element defined in TS 24.501 [104]. Byte 1
corresponds to "octet 2" of an 5GS mobile identity information element containing a 5G-GUTI. Byte 12
corresponds to "octet 13" of an 5GS mobile identity information element information element containing
a 5G-GUTI.
b8 b7 b6 b5 b4 b3 b2 b1
MSB
Last visited registered Tracking Area Identity in 5GS for 3GPP access.
Coding:
as the content of the tracking area identity information element defined in TS 24.501 [104]. Byte 13
corresponds to "octet 2" of a tracking area identity information element. Byte 18 corresponds to "octet 7"
of a tracking area identity information element.
Byte 13: first byte of last visited registered TAI for 3GPP access
b8 b7 b6 b5 b4 b3 b2 b1
MSB
Coding:
byte 19:
3GPP
Release 15 211 3GPP TS 31.102 V15.21.0 (2018-0610)
Bits: b3 b2 b1.
0 0 0 : 5U1 UPDATED.
0 0 1 : 5U2 NOT UPDATED.
0 1 0 : 5U3 ROAMING NOT ALLOWED.
0 1 1 : reserved.
1 0 0 : reserved.
1 0 1 : reserved.
1 1 0 : reserved.
1 1 1 : reserved.
Bits b4 to b8 are RFU (see TS 31.101 [11]).
This EF contains the following 5GS location information for non-3GPP access:
This EF contains the 5GS 3GPP access NAS security context as defined in TS 24.501 [104], consisting of K AMF with the
associated key set identifier, the UE security capabilities, and the uplink and downlink NAS COUNT values. This file
shall contain one record.
3GPP
Release 15 212 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents:
The ngKSI (Key Set Identifier in 5G) as defined in TS 33.501 [105] is coded on 1 byte.
Coding:
b8 b7 b6 b5 b4 b3 b2 b1
ngKSI
bits b4 to b8 are coded 0
Contents:
The KAMF as defined in TS 33.501 [105] is coded on 32 bytes. The ME shall treat any KAMF values stored in
this EF as invalid if the ngKSI indicates that no KAMF is available or if the length indicated in the KAMF
TLV is set to '00',
Coding:
The most significant bit of KAMF is the most significant bit of the 1st byte of this TLV value field. The least
significant bit of KAMF is the least significant bit of the last byte of this TLV value field.
Contents:
Coding:
3GPP
Release 15 213 3GPP TS 31.102 V15.21.0 (2018-0610)
The most significant bit of the uplink NAS count is the most significant bit of the 1st byte of this TLV value
field. The least significant bit of the uplink NAS count is the least significant bit of the last byte of this
TLV value field.
Contents:
Coding:
The most significant bit of the downlink NAS count is the most significant bit of the 1st byte of this TLV
value field. The least significant bit of the downlink NAS count is the least significant bit of the last byte
of this TLV value field.
Contents:
The identifiers of selected NAS integrity and encryption algorithms as defined in TS 33.501 [105] and TS
24.501 [104]. In this release the identifiers of selected NAS integrity and encryption algorithms are coded
as 4-bit identifiers.
Coding:
Coding is same as the content of the NAS security algorithms information element defined in
TS 24.501 [104].
Byte 1 of this TLV value field: first byte of the value part of the NAS security algorithms information
element
b8 b7 b6 b5 b4 b3 b2 b1
MSB
Least significant bit of the security algorithm identifier is the b1 of this TLV value field. Most siginificant bit
of the security algorithm identifier is b4 of this TLV value field as per the NAS security algorithms
identifer element defined in TS 33.501 [105].
b8 b7 b6 b5 b4 b3 b2 b1
3GPP
Release 15 214 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains the 5GS non-3GPP access NAS security context as defined in TS 24.501 [104], consisting of K AMF
with the associated key set identifier, the UE security capabilities, and the uplink and downlink NAS COUNT values.
This file shall contain one record.
This EF contains KAUSF and KSEAF that are generated on the ME using CK and IK as part of AKA procedures as
described in TS 33.501 [105].
Contents:
- KAUSF as described in TS 33.501[105]).
Coding:
- The most significant bit of KAUSF is the most significant bit of the 1st byte of this TLV value field. The least
significant bit of KAUSF is the least significant bit of the last byte of this TLV value field.
Contents:
- KSEAF as described in TS 33.501[105]).
Coding:
3GPP
Release 15 215 3GPP TS 31.102 V15.21.0 (2018-0610)
- The most significant bit of KSEAF is the most significant bit of the 1st byte of this TLV value field. The least
significant bit of KSEAF is the least significant bit of the last byte of this TLV value field.
This EF contains the configuration information pertaining to access identities allocated for specific high priority
services that can be used by the subscriber. The assigned access identities are used, in combination with an access
category, to control the access attempts. For more information see TS 22.261 [106] and TS 24.501 [104].
- Configuration of certain Unified Access Control (UAC) access identities specified in TS 24.501 [104]
subclause 4.5.2.
Coding:
Byte 1:
b8 b7 b6 b5 b4 b3 b2 b1
Bytes 2 to 4:
NOTE: Access Identities 11 to 15 (as specified in TS 24.501 [104]) are configured as Access Classes 11 to 15 in
EFACC, specified in clause 4.2.15.
3GPP
Release 15 216 3GPP TS 31.102 V15.21.0 (2018-0610)
If "SUCI calculation is to be performed by the USIM" (i.e. service n°124 is "available" in EF UST and service n°125 is
"available" in EFUST), this file shall not be available to the ME.
If service n°124 is not "available" in EFUST, this file shall not be available to the ME. This EF contains information
needed by the ME for the support of subscription identifier privacy as defined in 3GPP TS 33.501[105].
The Protection Scheme Identifier represents a protection scheme as described in 3GPP TS 33.501 [105] and it is
coded in one byte as follows:
b8 b7 b6 b5 b4 b3 b2 b1
The Key Index is coded in one byte such that its value indicates the position of the Home Network Public Key in the
Home Network Public Key List data object, that is applicable to the Protection Scheme. A Key Index with a value
of "1" refers to the first Network Public Key entry in the Home Network Public Key List, and so on. A Key Index
with a value of "0" indicates that there is no Home Network Public Key associated with that Protection Scheme
(e.g., in the case of null-scheme).
3GPP
Release 15 217 3GPP TS 31.102 V15.21.0 (2018-0610)
This file allows the HPLMN to indicate that the UE is to receive control plane based Steering of Roaming information
in a Registration Accept message during initial registration in a VPLMN. The control plane based Steering of Roaming
procedure is specified in 3GPP TS 23.122 [31]
3GPP
Release 15 218 3GPP TS 31.102 V15.21.0 (2018-0610)
Coding:
Byte 1:
b8 b7 b6 b5 b4 b3 b2 b1
Byte 2 is RFU.
A 3G ME shall not access this file. The information is accessible for a 3G ME in EFADN under DFPHONEBOOK.
A 3G ME shall not access this file. The information is accessible for a 3G ME in EFEXT1 under DFPHONEBOOK.
3GPP
Release 15 219 3GPP TS 31.102 V15.21.0 (2018-0610)
not be any EFCCP (with a file-id of '6F3D') under DFTELECOM because otherwise a GSM terminal could create
inconsistencies within the phonebook.
A 3G ME shall not access this file. The information is accessible for a 3G ME in EFCCP1 under DFPHONEBOOK.
This EF contains one or more records containing access rule information according to the reference to expanded format
as defined in ISO/IEC 7816-4 [20]. Each record represents an access rule. Unused bytes in the record are set to 'FF'.
If the card cannot access EFARR, any attempt to access a file with access rules indicated in this EFARR shall not be
granted.
This file shall be deactivated if the user does not wish the ICE information contained in this file to be available and
activated if the user wishes the ICE information in this file to be available.
Coding:
3GPP
Release 15 220 3GPP TS 31.102 V15.21.0 (2018-0610)
As for EFADN
This file shall be deactivated if the user does not wish the ICE information contained in this file to be available and
activated if the user wishes the ICE information in this file to be available.
Contents:
This TLV contains a label that summarises the type of content that is contained in the associated ICE Free
Format Content TLV (e.g. "medical alert information").
Coding:
ICE Free Format Label TLV is coded as follows:
Tag value is '80'
Length is coded according to ISO/IEC 8825-1 [35].
Value is as for value part of the text string TLV in 3GPP TS 31.111 [12]. If the length is 0 and there is no
value part then the terminal shall interpret this as no label is used.
Contents:
This TLV contains a ICE Free Format Content (e.g. "Allergy to work").
Coding:
ICE Free Format Content TLV is coded as follows:
Tag value is '81'
Length is coded according to ISO/IEC 8825-1 [35].
Value is as for value part of the text string TLV in 3GPP TS 31.111 [12]. If the length is 0 and there is no
value part then the terminal shall interpret this as no label is used.
3GPP
Release 15 221 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains the Public Service Identity of the SM-SC (either a SIP URI or tel URI) that the ME shall use to submit
SMS over IP as defined in 24.341 [55].
Access Conditions:
READ PIN
UPDATE PIN
DEACTIVATE ADM
ACTIVATE ADM
- URI
Contents:
- SIP URI or tel URI of the Public Service Identity of the SM-SC.
Coding:
- For contents and syntax of URI TLV data object values see IETF RFC 3261 [56]. The URI shall be encoded
to an octet string according to UTF-8 encoding rules as specified in IETF RFC 3629 [57]. The tag value of
the URI TLV data object shall be '80'.
- DFGRAPHICS '5F50'.
- DFPHONEBOOK '5F3A'.
(DF for public phone book. This DF has the same structure as DFPHONEBOOK under ADF USIM).
- DFMULTIMEDIA '5F3B'.
- DFMMSS '5F3C'
(The contents of DF for MMSS are defined in C.S0074-A [53]. This DF for MMSS is not applicable to 3GPP only
terminals).
- DFMCSDFMCPTT '5F3D'.
- DFV2X '5F3E'.
3GPP
Release 15 222 3GPP TS 31.102 V15.21.0 (2018-0610)
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 in the UICC, 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.
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.
Contents:
- a description of an image instance.
Coding:
- Byte 1: Image Instance Width
Contents:
- this byte specifies the image instance width, expressed in raster image points.
Coding:
- binary.
Contents:
- this byte specifies the image instance height, expressed in raster image points.
Coding:
- binary.
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 B;
- '21' - colour image coding scheme as defined in annex B;
- '22' - colour image coding scheme with transparency as defined in annex B;
other values are reserved for future use.
3GPP
Release 15 223 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents:
- these bytes identify an EF which is the image instance data file (see clause 4.6.1.2), holding the actual image data
for this particular instance.
Coding:
- byte 4: high byte of Image Instance Data File Identifier;
- byte 5: low byte of Image Instance Data File Identifier.
Contents:
- these bytes specify an offset into the transparent Image Instance Data File identified in bytes 4 and 5. The data for
this image instance is found starting at this offset in the Image Instance Data File.
Coding:
- byte 6: high byte of offset into Image Instance Data File;
byte 7: low byte of offset into Image Instance Data File.
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 B, 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.
The identifier '4FXX' shall be different from one image instance data file to the other. For the range of 'XX',
TS 31.101 [11]. The length Y may be different from one image instance data file to the other.
This file shall be deactivated if the user does not wish the ICE information contained in this file to be available and
activated if the user wishes the ICE information in this file to be available.
3GPP
Release 15 224 3GPP TS 31.102 V15.21.0 (2018-0610)
For this EF the Total File Size data object shall be present within the FCP template in order for the ME to fit the picture
to the available memory.
4.6.1.4 Void
4.6.1.5 Void
This file contains information about the MM data stored in EFMMDF. MM information are encapsulated in a BER-TLV
data object. Each data object in EFMML points to a corresponding MM in EFMMDF.
3GPP
Release 15 225 3GPP TS 31.102 V15.21.0 (2018-0610)
Access Conditions:
READ PIN
UPDATE PIN
DEACTIVATE ADM
ACTIVATE ADM
- MMS Implementation
Contents:
The MMS Implementation indicates the used implementation type, e.g. WAP.
Coding:
Allocation of bits:
Bit number Parameter indicated
1 WAP implementation of MMS
2 to 8 Reserved for future use
Coding:
according to TS 31.101 [11].
3GPP
Release 15 226 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents:
tag indentifying a MM (i.e. identifying a data object) within EFMMDF.
Coding:
according to TS 31.101 [11].
- MM Size
Contents:
size of the corresponding MM stored in EFMMDF.
Coding:
according to TS 31.101 [11].
- MM Status
Contents:
The status bytes contain the status information of the stored Multimedia Message.
Coding:
First byte:
bit b1 indicates whether the MM has been read or not. Bit b2 indicates the MM forwarding status. Bit b3 indicates
whether it is a received MM or an originated MM. Bits b4 to b8 are reserved for future use.
Second byte:
Coding of the second byte depends on whether the MM has been identified as a received MM or originated MM in the
first byte:
- Received MM coding:
bits b1 and b2 are used to provide information on Read-reply reports. Bits b3 to b8 are reserved for
future use.
- Originated MM coding:
bit b1 is used to provide information on Delivery-report. Bits b2 to b8 are reserved for future use.
First byte:
b8 b7 b6 b5 b4 b3 b2 b1
MM forwarded, bit = 1
RFU, bit = 0
b8 b7 b6 b5 b4 b3 b2 b1
RFU, bit = 0
b8 b7 b6 b5 b4 b3 b2 b1
3GPP
Release 15 227 3GPP TS 31.102 V15.21.0 (2018-0610)
MM sent, bit = 1
RFU, bit = 0
- MM Alpha Identifier
Contents:
information about the MM to be displayed to the user (e.g. sender, subject, date etc).
Coding:
this alpha identifier shall use either:
- the SMS default 7-bit coded alphabet as defined in TS 23.038 [5] 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 the annex of TS 31.101 [11].
Residing under DFMULTIMEDIA, this EF contains Multimedia Messages data. The structure of this EF is BER-TLV (see
TS 31.101 [11]). Each MM in this file is identified by a tag. The tag value for a particular MM in this file is stored in
EFMML.
Contents:
The Multimedia Message content consists of MM headers and a message body. The content of the Multimedia Message
data depends on whether the MM has been identified as a received MM or an originated MM:
- For a received message, the stored Multimedia Message data consists of the information elements (i.e.
relevant MM control information and MM content) of the MM1_retrieve.RES (see TS 23.140 [38]).
- For an originated message, the stored Multimedia Message data consists of the information elements (i.e.
relevant MM control information and MM content) of the MM1_submit.REQ (see TS 23.140 [38]).
Coding:
The MM data encapsulation scheme and encoding rules are defined by the MMS Implementation.
3GPP
Release 15 228 3GPP TS 31.102 V15.21.0 (2018-0610)
Contents:
Indicates the coding used for all the MCSMCPTT management objects stored in the DFMCSDFMCPTT.
Coding:
A value of '00' indicates the XML format described in TS 24.483 [89]. All other values are reserved.
Editor’s Note: the definition of other encoding formats is for future study.
The EF shall contain at least one byte for 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.
-Services
Contents: Service n°1: MCPTT UE configuration data
Service n°2: MCPTT User profile dataUser configuration data
Service n°3: MCS Group configuration data
Service n°4: MCPTT Service configuration data
Service n°5: MCS UE initial configuration data
Service n°6: MCData UE configuration data
Service n°7: MCData user profile data
Service n°8: MCData service configuration data
Service n°9: MCVideo UE configuration data
Service n°10: MCVideo user profile data
Service n°11: MCVideo service configuration data
Coding:
Same as coding of USIM Service Table.
3GPP
Release 15 229 3GPP TS 31.102 V15.21.0 (2018-0610)
This EF contains zero, one or more MCPTT configuration data objects, as specified in 3GPP TS 24.483 [89] Annex
B.2, Annex B3, Annex B.4 and Annex B.5.
The MCSPTT configuration data is encoded as specified in the MCSPTT Service Table.
4.6.4.3 Void
4.6.4.4 Void
3GPP
Release 15 230 3GPP TS 31.102 V15.21.0 (2018-0610)
4.6.4.5 Void
Contents:
Indicates the coding used for all the V2X management objects.stored in the DF V2X.
Coding:
A value of '00' indicates the XML format described in TS 24.385 [97]. All other values are reserved.
Editor’s Note: the definition of other encoding formats is for future study.
The EF shall contain at least one byte for 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.
Services
Contents: Service n°1: V2X configuration data
Coding:
Same as coding of USIM Service Table.
3GPP
Release 15 231 3GPP TS 31.102 V15.21.0 (2018-0610)
The V2X configuration data is encoded as specified in the V2X Service Table.
3GPP
Release 15 232 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 233 3GPP TS 31.102 V15.21.0 (2018-0610)
MF
'3F00'
DFCD see TS
'7F11' 31.101 [11]
DFTELECOM
'7F10'
EFPSISMSC
'6FE5'
DFGRAPHICS
'5F50'
DFPHONEBOOK
'5F3A'
EFEMAIL EFPURI
'4FXX' '4FXX'
DFMULTIMEDIA
'5F3B'
EFMML EFMMDF
'4F47' '4F48'
DFMMSS See
'5F3C' C.S0074-
A[53]
3GPP
Release 15 234 3GPP TS 31.102 V15.21.0 (2018-0610)
DFMCSPTT
'5F3D'
EFMST EFMCSPTT
_CONFIG
'4F01' '4F02'
DFV2X
'5F3E'
EFVST EFV2X_CONFIG
'4F01' '4F02'
NOTE 1: Files under DFTELECOM with shaded background are defined in 3GPP TS 51.011 [18].
NOTE 2: Void.
NOTE 3: Files under DFMMSS are defined in C.S0074-A [53].
NOTE 4: The values '4F03', '4F04' and '4F05' under DFMCSPTT were used in earlier versions of this specification, and
should not be re-assigned in future versions.
3GPP
Release 15 235 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 236 3GPP TS 31.102 V15.21.0 (2018-0610)
ADFUSIM
3GPP
Release 15 237 3GPP TS 31.102 V15.21.0 (2018-0610)
EF5GSN3GPPNSC EFSteering_of_UE_i
n_VPLMN
'6F01 '6F05'
DFPHONEBOOK
'5F3A'
EFEMAIL EFPURI
'4FXX' '4FXX'
DFGSM-ACCESS
'5F3B'
DFMexE
'5F3C'
DFSoLSA
'5F70'
EFSAI EFSLL
'4F30' '4F31'
DFWLAN
'5F40'
3GPP
Release 15 238 3GPP TS 31.102 V15.21.0 (2018-0610)
EFHPLMNDAI
'4F4B'
DFHNB
'5F50'
EFOHNBN
'4F86'
DFProSe
'5F90'
DFACDC
'5FA0'
EFACDC_LIST EFACDC_OS_CON
FIG
'4F01' '4FXX'
DFTV
'5FB0'
EFTVUSD
'4FXX'
DF5GS
'5FC0'
3GPP
Release 15 239 3GPP TS 31.102 V15.21.0 (2018-0610)
NOTE 5: The value '6F65' under ADFUSIM was used in earlier versions of this specification, and should not be re-
assigned in future versions.
5 Application protocol
The requirements stated in the corresponding section of TS 31.101 [11] apply to the USIM application.
The procedures listed in clause "USIM management procedures" are required for execution of the procedures in the
subsequent clauses "USIM security related procedures" and "Subscription related procedures". The procedures listed in
clauses "USIM security related procedures" are mandatory. The procedures listed in "Subscription related procedures"
are only executable if the associated services, which are optional, are provided in the USIM. However, if the procedures
are implemented, it shall be in accordance with clause "Subscription related procedures".
If a procedure is related to a specific service indicated in the USIM Service Table, it shall only be executed if the
corresponding bits denote this service as "service available" (see clause "EFUST"). In all other cases the procedure shall
not start.
5.1.1 Initialisation
NOTE: there may be cards that need to be reset before selecting the GSM application.
After a successful USIM application selection, the selected USIM (AID) is stored on the UICC. This application is
referred to as the last selected USIM application. The last selected USIM application shall be available on the UICC
after a deactivation followed by an activation of the UICC.
If a USIM application is selected using partial DF name, the partial DF name supplied in the command shall uniquely
identify a USIM application. Furthermore if a USIM application is selected using a partial DF name as specified in
TS 31.101 [11] indicating in the SELECT command the last occurrence the UICC shall select the USIM application
stored as the last USIM application. If, in the SELECT command, the options first, next/previous are indicated, they
have no meaning if an application has not been previously selected in the same session and shall return an appropriate
error code.
The ME requests the Language Indication. The preferred language selection shall always use the EF LI in preference to
the EFPL at the MF unless any of the following conditions applies:
- if the EFLI has the value 'FFFF' in its highest priority position, then the preferred language selection shall be the
language preference in the EFPL at the MF level according the procedure defined in TS 31.101 [11];
- if the ME does not support any of the language codes indicated in EFLI , or if EFLI is not present, then the
language selection shall be as defined in EFPL at the MF level according the procedure defined in
TS 31.101 [11];
- if neither the languages of EFLI nor EFPL are supported by the terminal, then the terminal shall use its own
internal default selection.
3GPP
Release 15 240 3GPP TS 31.102 V15.21.0 (2018-0610)
The ME then runs the user verification procedure. If the procedure is not performed successfully, the USIM
initialisation stops.
In case FDN is enabled, an ME which does not support FDN shall allow emergency calls but shall not allow MO calls
and MO-SMS.
If BDN is enabled, an ME which does not support Call Control shall allow emergency calls but shall not allow MO
calls.
If ACL is enabled, an ME which does not support ACL shall not send any APN to the network.
If all these procedures have been performed successfully then 3G session shall start. In all other cases 3G session shall
not start.
Afterwards, the ME runs the following procedures if the ME and the USIM support the related services:
- IMSI request;
- EHPLMN request
- Location Information request for CS-and/or PS-mode and/or EPS and/or 5GS;
- Cipher key and integrity key request for CS- and/or PS-mode;
- CBMID request;
- Depending on the further services that are supported by both the ME and the USIM the corresponding Efs have
to be read.
After the USIM initialisation has been completed successfully, the ME is ready for a 3G session and shall indicate this
to the USIM by sending a particular STATUS command.
3GPP
Release 15 241 3GPP TS 31.102 V15.21.0 (2018-0610)
The ME shall indicate to the USIM by sending a particular STATUS command that the termination procedure is
starting.
The ME then runs all the procedures which are necessary to transfer the following subscriber related information to the
USIM, if the ME and the USIM support the related services:
- Location Information update for CS-and/or PS-domain and/or EPS and/or 5GS.
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 3G session, and the
value has not changed until 3G session termination, the ME may omit the respective update procedure.
To actually terminate the session, the ME shall then use one of the mechanisms described in TS 31.101 [11].
- CPBCCH information update (if the ME supports the GSM compact access technology);
NOTE: The update procedure is only applicable when access conditions of ADM for update is set to ALW, PIN
or PIN2.
3GPP
Release 15 242 3GPP TS 31.102 V15.21.0 (2018-0610)
5.1.8 Void
The ME may suspend the UICC presence detection based on STATUS commands in case it has an active PDP context,
or an active EPS bearer context or an active 5GS PDU session, but has not exchanged any data with the network within
a 30s period of inactivity on the UICC-ME interface, and resume it as soon as data is exchanged with the network,
sending immediately a new STATUS command. For emergency services, if UICC presence detection fails during a call
the service may not be terminated.
If the UICC supports the UICC suspension mechanism (SUSPEND UICC command), the ME may suspend the UICC
after entering the PSM. In this case, the ME shall successfully resume the UICC before it can leave the PSM.
If the UICC does not support the UICC suspension mechanism, and only in case the PIN of the USIM is disabled, the
ME may optionally deactivate the UICC (as specified in clause 6A.1 of 3GPP TS 31.101 [11]) after entering the PSM.
In this case, the ME shall perform these steps before it can leave the PSM:
- re-activate the UICC (as specified in clause 6A.1 of 3GPP TS 31.101 [11]),
- re-initialize the USIM (as specified in clause 5.1.1), with the exception of re-reading EFs that are not required for
the verification of the USIM,
Verification shall include at least the check of the content of the following EFs: EF ICCID, EFIMSI, EFLOCI, EFPSLOCI and
EFEPSLOCI.
When the UE is in PSM and in case the ME wants to deactivate the UICC, it shall wait until the current proactive UICC
session, if any, is terminated and/or any currently open BIP session is closed.
3GPP
Release 15 243 3GPP TS 31.102 V15.21.0 (2018-0610)
ME may suspend the UICC during the extended idle mode DRX cycle. In this case, the ME shall resume the UICC
successfully before the end of the extended idle mode DRX cycle or before any other transmission to the network.
In case the UICC does not support the UICC suspension mechanism, the PIN of the USIM is disabled and deactivation
of UICC is authorized in EFAD, the UE may optionally deactivate the UICC (as specified in clause 6A.1 of
3GPP TS 31.101 [11]) during the extended idle mode DRX cycle. In this case, the UE shall re-activate the UICC (as
specified in clause 6A.1 of 3GPP TS 31.101 [11]), re-initialize the USIM (as specified in clause 5.1.1) and take
appropriate steps to verify that the same USIM is used, before the end of the extended idle mode DRX cycle or before
any other transmission to the network.
Verification shall include at least the check of the content of the following EFs: EF ICCID, EFIMSI, EFLOCI, EFPSLOCI and
EFEPSLOCI.
When the UE is in extended idle mode DRX cycle and in case the ME wants to deactivate the UICC, it shall wait until
the current proactive UICC session, if any, is terminated and/or any currently open BIP session is closed.
After a successful AUTHENTICATE command, the ME shall perform cipher and integrity key update procedure.
In the case when updating EFLOCI with data containing the TMSI value and the card reports the error '6581' (Memory
Problem), the ME shall terminate 3G operation.
3GPP
Release 15 244 3GPP TS 31.102 V15.21.0 (2018-0610)
5.2.8 Void
Request: The ME performs the reading procedure with EFSAI, EFSLL and its associated LSA Descriptor files.
3GPP
Release 15 245 3GPP TS 31.102 V15.21.0 (2018-0610)
After a successful GBA_U Procedure, the ME shall update the B-TID field and the Key Life Time field in EF GBABP
5.2.24 Void
3GPP
Release 15 246 3GPP TS 31.102 V15.21.0 (2018-0610)
In order to prevent UICC memory wear out due to excessive writing, the update of EPS NAS security context shall be
according to the rules and procedures specified in TS 33.401 [52].
For each NAS configuration parameter, a parameter provided in EFNASCONFIG shall take precedence over the
corresponding parameter stored in the ME's non-volatile memory.
Request: The ME performs the reading procedure with EF5GS3GPPLOCI or with EF5GSN3GPPLOCI.
Update: The ME performs the updating procedure with EF5GS3GPPLOCI or with EF5GSN3GPPLOCI.
Request: The ME performs the reading procedure with EF5GS3GPPNSC and EF5GSN3GPPNSC.
Update: The ME performs the updating procedure with EF5GS3GPPNSC and EF5GSN3GPPNSC.
In order to prevent UICC memory wear out due to excessive writing, the update of 5GS NAS security context shall be
according to the rules and procedures specified in TS 33.501 [104].
3GPP
Release 15 247 3GPP TS 31.102 V15.21.0 (2018-0610)
5.3.1.1 Initialisation
The ME first reads the content of EFPBR to determine the configuration phonebook. If the EFIAP file is indicated in EFPBR
following tag 'A8' the ME reads the content of EFIAP in order to establish the relation ship between the content in the
files indicated using tag 'A9' and files indicated by tag 'A8'. The ME may read the contents of the phone book related
files in any order.
In case of deletion of a complete or part of an entry the data shall be deleted first followed by the reference pointer for
that data element. In case of deletion of a complete entry the contents of EF ADN is the last to be deleted.
Even if the terminal does not support the Hidden Key Procedures, a hidden phone book entry shall not be displayed by
the terminal.
- Service n°1 "available" for ADN located under the local phonebook;
- Presence of EFADN in EFPBR for ADN located under the global phonebook;
The following procedures may not only be applied to EFADN and its associated extension files EFCCP1 and EFEXT1 as
described in the procedures below, but also to EFANR, EFFDN, EFMSISDN, EFBDN, EFSDN, EFOCI, EFICI, and EFMBDN and their
associated extension files. If these files are not "available", as denoted in the USIM service table, the current procedure
shall be aborted and the appropriate Efs shall remain unchanged.
3GPP
Release 15 248 3GPP TS 31.102 V15.21.0 (2018-0610)
Update: The ME analyses and assembles the information to be stored as follows (the byte identifiers used
below correspond to those in the definition of the relevant Efs in the present document):
i) The ME identifies the Alpha-tagging, Capability/Configuration1 Record 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 20 or less "digits" remain, they shall form the dialling number/SSC string;
- The ME seeks for a free record in EFEXT1. If an Extension1 record is not marked as "free", the ME runs the Purge
procedure. If an Extension1 record is still unavailable, the procedure is aborted.
- The first 20 "digits" are stored in the dialling number/SSC string. The value of the length of BCD number/SSC
contents is set to the maximum value, which is 11. The Extension1 record identifier is coded with the associated record
number in the EFEXT1. The remaining digits are stored in the selected Extension1 record where the type of the record is
set to "additional data". The first byte of the Extension1 record is set with the number of bytes of the remaining
additional data. The number of bytes containing digit information is the sum of the length of BCD number/SSC
contents of EFADN and byte 2 of all associated chained Extension1 records containing additional data.
iii) If a called party subaddress is associated to the ADN/SSC the procedure shall proceed as follows:
- If the length of the called party subaddress is less than or equal to 11 bytes (see TS 24.008 [9] for coding):
- The ME seeks for a free record in EFEXT1. If an Extension1 record is not marked as "free", the ME runs the Purge
procedure. If an Extension1 record is still unavailable, the procedure is aborted.
- The ME stores the called party subaddress in the Extension1 record, and sets the Extension1 record type to "called
party subaddress".
- If the length of the called party subaddress is greater than 11 bytes (see TS 24.008 [9] 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 USIM has no
available empty space to store the received ADN/SSC, or if the procedure has been aborted, the ME advises the user.
For reasons of memory efficiency, the ME may analyse all Extension1 records to recognise if the additional or
subaddress data to be stored is already existing in EFEXT1. In this case, the ME may use the existing chain or the last part
of the existing chain from more than one ADN. The ME is only allowed to store extension data in unused records. If
existing records are used for multiple access, the ME shall not change any data in those records to prevent corruption of
existing chains.
Erasure: The ME sends the identification of the information to be erased. The content of the identified
record in EFADN is marked as "free".
Request: The ME sends the identification of the information to be read. The ME shall analyse the data of
EFADN to ascertain, whether additional data is associated in EFEXT1 or EFCCP1. If necessary, then the
ME performs the reading procedure on these Efs to assemble the complete ADN/SSC.
3GPP
Release 15 249 3GPP TS 31.102 V15.21.0 (2018-0610)
Purge: The ME shall access each EF which references EFEXT1 (EFEXT2, EFEXT6) 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,
Extension6) records are noted by the ME. All Extension1 (Extension2, Extension6) records not
noted are then marked by the ME as "free" by setting the whole record to 'FF'.
The following three procedures are only applicable to service n°2 (FDN).
FDN capability request. The ME shall check the state of service n°2, i.e. if FDN is "enabled" or "disabled". If FDN is
enabled, the ME shall only allow outgoing calls as defined in the fixed number dialling description in TS 22.101 [24].
To ascertain the state of FDN, the ME shall check in EFUST and EFEST if FDN is enabled (service activated and
available). In all other cases service n°2 is disabled.
The following three procedures are only applicable to service n°6 (BDN).
- BDN capability request. The ME shall check the state of service n°6, i.e. if BDN is "enabled" or "disabled". To
ascertain the state of BDN, the ME shall check in EFUST and EFEST if BDN is "enabled" (service available and
activated). In all other cases, the BDN service is "disabled".
Request: The USIM seeks for the identified short message. If this message is found, the ME performs the
reading procedure with EFSMS.
If service n°10 is "available" and the status of the SMS is '1D' (status report requested, received
and stored in EFSMSR), the ME performs the reading procedure with the corresponding record in
EFSMSR. If the ME does not find a corresponding record in EFSMSR, then the ME shall update the
status of the SMS with '15' (status report requested, received but not stored in EFSMSR).
If the short message is not found within the USIM memory, the USIM indicates that to the ME.
Update: The ME looks for the next available area to store the short message. If such an area is available, it
performs the updating procedure with EFSMS.
If there is no available empty space in the USIM to store the received short message, a specific
MMI will have to take place in order not to loose the message.
Erasure: The ME will select in the USIM the message area to be erased. Depending on the MMI, the
message may be read before the area is marked as "free". After performing the updating procedure
with EFSMS, the memory allocated to this short message in the USIM is made available for a new
incoming message. The memory of the USIM may still contain the old message until a new
message is stored in this area.
If service n°11 is "available" and the status of the SMS is '1D' (status report requested, received
and stored in EFSMSR), the ME performs the erasure procedure for EFSMSR with the corresponding
record in EFSMSR.
3GPP
Release 15 250 3GPP TS 31.102 V15.21.0 (2018-0610)
Request: The ME performs the reading procedure with EFACM. The USIM returns the last updated value of
the ACM.
Initialisation: The ME performs the updating procedure with EFACM using the new initial value.
Increasing: The ME performs the increasing procedure with EFACM sending the value which has to be added.
Initialisation: The ME performs the updating procedure with EFACMmax using the new initial maximum value.
Erasure: The ME sends the identification of the requested information to be erased. The content of the
identified record in EFCCP2 is marked as "free".
3GPP
Release 15 251 3GPP TS 31.102 V15.21.0 (2018-0610)
Request: If the status of a stored short message indicates that there is a corresponding status report, the ME
performs the reading procedure on the records of EFSMSR and identifies the record containing the
appropriate status report.
Update: If a status report is received, the ME first seeks within the SMS record identifiers of EF SMSR for the
same record number it used for the short message in EFSMS. If such a record identifier is found in
EFSMSR, it is used for storage. If such a record identifier is not found, then the ME seeks for a free
entry in EFSMSR for storage. If no free entry is found the ME runs the Purge procedure with EFSMSR.
If there is still no free entry, the status report is not stored.
If the ME found an appropriate record in EFSMSR for storage, it updates the record with the status
report setting the record identifier in EFSMSR to the appropriate record number of the short message
in EFSMS.
The status in EFSMS is updated accordingly by performing the update procedure with EFSMS.
Erasure: The ME runs the update procedure with EFSMSR by at least storing '00' in the first byte of the
record. The ME may optionally update the following bytes with 'FF'.
Purge: The ME shall read the SMS record identifier (byte 1) of each record of EFSMSR. With each record
the ME checks the corresponding short messages in EFSMS. If the status (byte 1) of the
corresponding SMS is not equal '1D' (status report requested, received and stored in EFSMSR), the
ME shall perform the erasure procedure with the appropriate record in EFSMSR.
Enabling: The ME activates service n°3 in EFEST (bit n°3 set to "1").
Disabling: The ME deactivates service n°3 in EFEST (bit n°3 set to "0").
When the APN Control List service is enabled, the ME shall check that the entire APN of any PDP context is listed in
EFACL before requesting this PDP context activation from the network. If the APN is not present in EF ACL, the ME shall
not request the corresponding PDP context activation from the network.
In the case that the APN Control List is enabled and no APN is indicated in the PDP context request, indicating that a
network provided APN is to be used, then the ME shall only request the PDP context activation if "network provided
APN" is contained within EFACL.
3GPP
Release 15 252 3GPP TS 31.102 V15.21.0 (2018-0610)
If the APN Control List service is enabled and the ME is to provide an APN as part of attach for PDN connectivity,
then the ME shall verify that the APN value is present in the EFACL and if it is not the ME shall not proceed with the
attach procedure. If the APN Control List service is enabled and the ME does not indend to provide an APN as part of
the attach for PDN connectivity and use a network provided APN, the ME shall not check if "network provided APN"
is contained within EFACL.
If the APN Control List service is enabled and the ME is to provide a DNN as part of PDU session establishment, then
the ME shall verify that the DNN value is present in the EFACL and if it is not the ME shall not proceed with the PDU
session establishment procedure. If the APN Control List service is enabled and the ME does not intend to provide a
DNN as part of the PDU session establishment and use a network provided DNN, the ME shall not check if "network
provided DNN" is contained within EFACL.
3GPP
Release 15 253 3GPP TS 31.102 V15.21.0 (2018-0610)
Request: The ME sends the identification of the information to be read, then the ME performs the reading
procedure with EFMMSN. If Service n°53 is available the ME shall analyse the data of EFMMSN to
ascertain, whether additional data is associated in EFEXT8. If necessary, then the ME performs the
reading procedure on EFEXT8 to assemble the complete MMS notification.
Update: The ME analyses and assembles the MMS notification to be stored as follows:
3GPP
Release 15 254 3GPP TS 31.102 V15.21.0 (2018-0610)
- if the MMS notification contains not more bytes than the maximum possible number for EFMMSN then the ME looks
for the next available area to store the MMS notification. If such an area is available, it performs the updating procedure
with EFMMSN.
- if the MMS notification contains more bytes than the maximum possible number for EFMMSN then the ME seeks for
a sufficient number of free records in EFEXT8 to store the complete MMS notification.
- If there is not a sufficient number of EFEXT8 records marked as "free" to store the complete MMS
notification, the procedure is aborted.
- Otherwise, the ME performs the updating procedure and stores as many bytes as possible in EF MMSN. The
Extension file record number of EFMMSN is coded with the associated record number in the EFEXT8. The
remaining bytes are stored in the selected EFEXT8 record where the type of the record is then set to
"additional data". The second byte of the EFEXT8 record is set with the number of bytes of the remaining
additional data. It is possible, if the number of additional digits exceeds the capacity of the additional
record, to chain another record inside the EFEXT8 by the identifier in the last byte of the record. In this case
byte 2 of each record for additional data within the same chain indicates the number of bytes within the
same record.
If there is no available empty space in the USIM to store the MMS notification, it is up to ME
implementation how the notification is handled.
Erasure: The ME will select in the USIM the MMS notification to be erased. Depending on the MMI, the
MMS notification may be read before the area is marked as "free". The memory of the USIM may
still contain the old MMS notification until a new message is stored. If Service n°53 is available
all associated records in EFEXT8 are then marked by the ME as "free" by setting them to 'FF'.
3GPP
Release 15 255 3GPP TS 31.102 V15.21.0 (2018-0610)
As defined in TS 23.140 [38] a Multimedia Message consists of content, or multimedia objects, and headers to describe
various properties of that content. An MM is stored in EFMMDF, a BER-TLV structured file.
A list of multimedia messages is stored in the BER-TLV file EFMMLwhere each data object identifies one Multimedia
Message stored in EFMMDF.
Request: The ME performs the reading procedures on EFMML to verify the presence and to get the location
information of the targeted MM. Then the ME performs the reading procedure of the EF MMDF file
to get the MM.
Update: The ME chooses a free identity (i.e. not listed in EFMML) for the multimedia message and check for
available space in the EFMMDF file. This procedure could be done for each update or once at the
startup of the UE and after a REFRESH command involving one of the DFMULTIMEDIA files. Then
the ME performs the following procedures:
If there is no available empty space in the EFMMDF file to store the MM, the procedure is aborted
and the user is notified.
Else, the ME stores the MM in EFMMDF, then updates the information in EFMML accordingly.
Erasure: After a successful deletion of an MM in EFMMDF the terminal updates the information in EFMML
accordingly.
Request: The ME performs the reading procedure with EFSPN and EFSPNI.
Request: The ME performs the reading procedure with EFPNN and EFPNNI.
Request: The terminal performs the read procedure with EFICE_DN and/or EFICE_FF and/or EFICE_graphics.
Update: The terminal performs the update procedure with EFICE_DN and/or EFICE_FF and/or
EFICE_graphics.
Disable ICE display: The terminal performs the deactivate procedure consecutively on all the supported files
(EFICE_DN, EFICE_FF and EFICE_graphics).
3GPP
Release 15 256 3GPP TS 31.102 V15.21.0 (2018-0610)
Enable ICE display: The terminal performs the activate procedure consecutively on all the supported files (EF ICE_DN,
EFICE_FF and EFICE_graphics ).
The content of the EFICE_DN, EFICE_FF and EFICE_graphics shall be preserved when enabling and disabling the ICE display.
Depending on the type of eCall support and the domain, EFFDN or EFSDN or EFFDNURI or EFSDNURI is used to provide the
eCall functionality.
If eCall only calls are supported, then EFFDN shall only contain two entries. The first entry shall contain the eCall test
number and the second entry shall contain the eCall reconfiguration number. These numbers are used for eCall over CS
domain. If Service n° 112 or Service n° 99 are not available, these numbers are used also for eCall over IMS
Emergency Services using the PS domain in E-UTRAN, after being converted into tel URIs. A terminal in eCall only
mode performs the FDN related procedures.
Requirement: Service n° 112 and Service n° 99 are "available" and FDN is enabled (Service n° 2 is "available"
and FDN service is enabled in EFEST).
If eCall only calls are supported, then EFFDNURI shall only contain two entries. The first entry shall contain the eCall test
URI and the second entry shall contain the eCall reconfiguration URI. These URIs are used for eCall over IMS
Emergency Services using the PS domain in E-UTRAN. A terminal in eCall only mode performs the FDN related
procedures.
If eCall and normal calls are supported, then the last two entries of EFSDN shall contain the eCall test number and the
eCall reconfiguration number respectively. These numbers are used for eCalls over CS domain. If Service n° 112 or
Service n° 99 are not available, these numbers are used also for eCall over IMS Emergency Services using the PS
domain in E-UTRAN, after being converted into tel URIs. A terminal in eCall and normal mode performs the SDN
related procedures.
Requirement: Service n° 112 and Service n° 99 and Service n° 4 are "available" and FDN is disabled (either
Service n°2 is not "available" or FDN service is disabled in EFEST).
If eCall and normal calls are supported, then the last two entries of EFSDNURI shall contain the eCall test URI and the
eCall reconfiguration URI respectively. These URIs are used for eCall over IMS Emergency Services using the PS
domain in E-UTRAN. A terminal in eCall and normal mode performs the SDN related procedures.
3GPP
Release 15 257 3GPP TS 31.102 V15.21.0 (2018-0610)
- UICC Reset
- 3G Session Reset
5.3.41 SM-over-IP
Requirement: Service n°12 and n°91 "available".
The procedures and command for "UICC access to IMS" are defined in TS 31.111 [12]. An ME supporting UICC
access to IMS shall perform the reading procedure with EFUICCIARI prior to sending a registration to the IMS.
5.3.43 TV Configuration
Requirement: Service n°116 "available".
Request: If the ME supports 3GPP PS Data Off the ME shall perform the reading procedure with
EF3GPPPSDataOff.
Request: If the ME supports 3GPP PS Data Off the ME shall perform the reading procedure with
EF3GPPPSDATAOFFservicelist. If the ME performs the reading procedure with EF3GPPPSDATAOFFservicelist, the UE
shall use the 3GPP PS Data Off Service list in the EF3GPPPSDATAOFFservicelist as described in
TS 24.229 [63] subclauses 4.17, B.3.1.5 and L.3.1.5.
3GPP
Release 15 258 3GPP TS 31.102 V15.21.0 (2018-0610)
Request: As part of the SUCI calculation performed by the ME, the ME performs the reading procedure
with EFSUCI_Calc_Info.
Request: The ME uses the GET IDENTITY command in SUCI context to retrieve the SUCI calculated
by the USIM.
Editor's Note: The procedure may need to be updated depending on the decision (in 3GPP TS 24.501 and/or
3GPP TS 33.501) whether the security terminates in the ME or the USIM.
If service n°127 is "available" in the USIM Service Table, the Registration Accept shall contain control plane based
Steering of Roaming information during the initial registration in a VPLMN.
If service n°127 is not "available" in the USIM Service Table, the Registration Accept may contain control plane based
Steering of Roaming information during the initial registration in a VPLMN.
The control plane-based Steering of Roaming procedure and the related information from the HPLMN are specified in
3GPP TS 23.122 [31].
The procedures and commands for Data Download via SMS-PP are defined in TS 31.111 [12].
3GPP
Release 15 259 3GPP TS 31.102 V15.21.0 (2018-0610)
The ME shall perform the reading procedure with EFCBMID, and add the message identifiers to the Cell Broadcast search
list. On receiving a cell broadcast message the procedure defined in TS 31.111 [12] applies.
The procedures and commands for Call Control by USIM are defined in TS 31.111 [12]. It is mandatory for the ME to
perform the procedures if it has indicated that it supports Call Control by USIM in the TERMINAL PROFILE
command.
The procedures and commands for MO-SMS control by USIM are defined in TS 31.111 [12]. It is mandatory for the
ME to perform the procedures if it has indicated that it supports MO-SMS control by USIM in the TERMINAL
PROFILE command.
The procedures and commands for Data Download via USSD and USSD application mode are defined in
TS 31.111 [12].
The procedures and commands for Additional TERMINAL PROFILE after UICC activation are defined in
TS 31.111 [12] and allow the ME to send multiple Terminal Profile downloads.
The procedures and commands for "Terminal Applications" are defined in TS 31.111 [12]
The procedures and commands for Call control on EPS PDN connection by USIM are defined in TS 31.111 [12].
The procedures and commands for Communication Control for IMS by USIM are defined in TS 31.111 [12]. It is
mandatory for the ME to perform the procedures if it has indicated that it supports Communication Control for IMS by
USIM in the TERMINAL PROFILE command.
3GPP
Release 15 260 3GPP TS 31.102 V15.21.0 (2018-0610)
The procedures and commands for "Extended Terminal Applications" are defined in TS 31.111 [12].
To support the USAT Application Pairing procedure, the ME shall support USAT PROVIDE LOCAL
INFORMATION command (IMEI or IMEISV), as specified in 3GPP TS 31.111 [12].
USAT Application Pairing is successful when the IMEI or IMEISV retrieved from the terminal belongs to a range of
values the UICC is configured with in EFIWL.
EFIWL, EFIPS, EFIPD are defined in this document to support this procedure.
If the service n°102 is "available" in the USIM Service Table, the UICC shall start the UICC proactive session
immediately after TERMINAL PROFILE and the first proactive command shall be PROVIDE LOCAL
INFORMATION with IMEI or IMEISV. The ME shall respond with TERMINAL RESPONSE with IMEI or IMEISV
before performing any AUTHENTICATE command.
The UICC shall respond to any AUTHENTICATE command with error status words SW1 SW2 = '69 85' if:
- IMEI or IMEISV provided by the ME is not in the corresponding white list configured in the USIM (EFIWL)
If the AUTHENTICATE command had been executed before the pairing procedure has been successfully performed (in
the case of pre-Rel-12 MEs), the UICC may need to trigger a network attachment procedure by sending a proactive
command REFRESH(3G SESSION RESET).
The procedures and commands for Call control on PDU Session by USIM are defined in TS 31.111 [12].
5.5.1 MexE ST
Requirement: Service n°41 (MexE) "available".
3GPP
Release 15 261 3GPP TS 31.102 V15.21.0 (2018-0610)
Request: The ME performs the reading procedure with EFORPK. The ME shall analyse the data of EFORPK
(clause 4.4.1.4.2) to identify the files containing the certificate instances. If necessary, then the ME
performs READ BINARY commands on these files to assemble the complete certificate instance
data.
Request: The ME performs the reading procedure with EFARPK. The ME shall analyse the data of EFARPK
(clause 4.4.1.4.3) to identify the file containing the certificate instance. If necessary, then the ME
performs READ BINARY commands on this file to assemble the complete certificate instance
data.
Request: The ME performs the reading procedure with EFTPRPK. The ME shall analyse the data of EFTPRPK
(clause 4.4.1.4.4) to identify the files containing the certificate instances. If necessary, then the ME
performs READ BINARY commands on these files to assemble the complete certificate instance
data.
Request: The ME performs the reading procedure with EFTKCDF. The ME shall analyse the data of EFTKCDF
and, if necessary, perform READ BINARY commands on these files
The ME shall read the User, Home and Operator controlled WSIDs, the I-WLAN Equivalent HPLMN Presentation
Indication, I-WLAN HPLMN Priority Indication, the I-WLAN Last Registered PLMN and the HPLMN Direct Access
Indicationfrom the corresponding list files (i.e. EFUWSIDL, EFHWSIDL, EFOWSIDL, EFWEHPLMNPI , EFWLRPLMN, EFWHPI and
EFHPLMDAI)to perform WLAN selection procedures as described in TS 24.234 [40].
The ME shall read the User controlled PLMN selector and/or Operator controlled PLMN selector in EF UPLMNWLAN and
EFOPLMNWLAN respectively for WLAN PLMN Selection procedures as described in TS 24.234 [40].
The user may change the User controlled PLMN selector for WLAN.
3GPP
Release 15 262 3GPP TS 31.102 V15.21.0 (2018-0610)
When the ME tries a full authentication, it shall inspect if a valid Pseudonym is available in EF Pseudo.and use it as the
user name portion of the NAI for WLAN access authentication following the procedures described in TS 24.234 [40].
When the ME tries a fast re-authentication, it shall inspect if a valid reauthentication identity is available in EF WRI and
use it as the user name portion of the NAI for WLAN access re-authentication following the procedures described in
TS 24.234 [40].
The ME shall manage re-authentiction identities, Master Key and counter values as described in TS 24.234 [40].
Request: The terminal performs the read procedure with EFNCP-IP before establishing a remote data link for
UICC remote IP connectivity as described in ETSI TS 102 483 [50].
The ME shall read the allowed CSG Ids from EFACSGL in order to perform H(e)NB selection procedures. The lists in
EFACSGL shall take precedence over the list stored in the ME non-volatile memory.
Request: The terminal performs the read procedure with with EFOCSGL.
The ME shall read the Operator CSG Ids from EFOCSGL in order to perform H(e)NB selection procedures. The list in
EFOCSGL shall take precedence over the list stored in the ME non-volatile memory.
In case of a manual CSG cell selection, the ME shall read EFAD and CSG Lists Display Indicators from EFOCSGL and
display CSG Ids accordingly. The configuration in EFOCSGL shall take precedence over the configuration stored in the
ME non-volatile memory.
If service n°92 is not "available", in case of a manual CSG cell selection, all available CSGs may be displayed without
any restriction.
Request: The terminal performs the read procedure with EFACSGL and EFCSGT.
3GPP
Release 15 263 3GPP TS 31.102 V15.21.0 (2018-0610)
The ME shall discover the association between the selected CSG ID and a CSG Type from EF ACSGL. If this association
exists, the provided CSG Type shall be displayed.
Request: The terminal performs the read procedure with EFOCSGL and EFOCSGT.
The ME shall discover the association between the selected CSG ID and either a CSG Type from EF ACSGL or an
Operator CSG Type from EFOCSGL. The Operator CSG Type has precedence.
Request: The terminal performs the read procedure with EFACSGL and EFHNBN.
Update: The terminal performs the updating procedure with EFACSGL and EFHNBN.
The ME shall discover the association between the selected CSG ID and a HNB name from EF ACSGL. If this association
exists, the provided HNB name shall be displayed.
Request: The terminal performs the read procedure with EFOCSGL and EFOHNBN.
The ME shall discover the association between the selected CSG ID and either a HNB Name from EF ACSGL or an
Operator HNB from EFOCSGL. The Operator HNB Name has precedence. If this association exists, the HNB Name shall
be displayed.
In case of a manual CSG cell selection, the ME shall read EFAD and the CSG Lists Display Indicators from EFOCSGL and
display HNB Name accordingly. The configuration in EFOCSGL shall take precedence over the configuration stored in the
ME non-volatile memory.
If service n°92 is not "available", in case of a manual CSG cell selection, all available CSGs may be displayed without
any restriction.
Request: The ME performs the reading procedure with EFPROSE_MON. and EFPROSE_ANN.
3GPP
Release 15 264 3GPP TS 31.102 V15.21.0 (2018-0610)
Requirement: service n°5 is "available" in the ProSe Service Table and "Prose services for Public Safety" is
enabled in EFAD or the ME received service authorization from the ProSe Function.
Request: The ME performs the reading procedure with EFPROSE_GC. The content from the USIM shall be
combined with that one from the non-volatile memory on the ME, with USIM taking precedence
in case the same group is available in both.
Update: The ME performs the updating procedure with EFPROSE_GC. If the EF does not have free space, the
ME shall use the non-volatile memory on the ME.
The ME is responsible to remove entries no longer used from the EFPROSE_GC in order to guarantee
that EF is not filled with unnecessary entries.
Request: The ME performs the reading procedure with EFPROSE_UIRC. The content from the USIM shall be
used by the ME to construct the content of the usage information report according the procedures
defined in TS 24.334[70], with the USIM configuration parameters taking precedence in case the
usage information reporting configuration parameters have also been provisioned in the ME.
3GPP
Release 15 265 3GPP TS 31.102 V15.21.0 (2018-0610)
Request: The ME performs the reading procedure with EFPROSE_RELAY and EFPROSE_RELAY_DISCOVERY.
Request: The ME performs the reading procedure with EFePDGId. The UE then shall use the Home ePDG
identifier(s) present in the EFePDGId to perform the ePDG selection procedure as defined in
3GPP TS 24.302 [79].
If EFePDGId and EFePDGSelection are empty, the UE shall consider "ePDG configuration information is
configured but empty", then the UE shall follow the procedure specified in the "Selection of the
ePDG" UE procedure as defined in 3GPP TS 24.302 [79].
Request: The ME performs the reading procedure with EFePDGSelection. The UE then shall use the ePDG
selection information present in the EFePDGSelection to perform the ePDG selection procedure as
defined in 3GPP TS 24.302 [79].
If EFePDGId and EFePDGSelection are empty, the UE shall consider "ePDG configuration information is
configured but empty", then the UE shall follow the procedure specified in the "Selection of the
ePDG" UE procedure as defined in 3GPP TS 24.302 [79].
Request: The UE shall consider "ePDG configuration information is configured but empty", then the UE
shall follow the procedure specified in the "Selection of the ePDG" UE procedure as defined in
3GPP TS 24.302 [79].
3GPP
Release 15 266 3GPP TS 31.102 V15.21.0 (2018-0610)
5.12.2 Void
5.12.3 Void
5.12.4 Void
Request: The ME performs the reading procedure with EFePDGIdEm. The UE then shall use the Emergency
ePDG identifier(s) present in the EFePDGIdEm to perform the ePDG selection procedure.
If EFePDGIdEm and EFePDGSelectionEm are empty, the UE shall consider that the ePDG configuration
information for Emergency Services is configured but empty.
Request: The ME performs the reading procedure with EFePDGSelectionEm. The UE then shall use the ePDG
selection information for Emergency Services present in the EFePDGSelectionEm to perform the ePDG
selection procedure.
If EFePDGIdEm and EFePDGSelectionEm are empty, the UE shall consider that the ePDG configuration
information for Emergency Services is configured but empty.
Request: The UE shall consider the ePDG configuration information is configured but empty.
Request: The ME performs the reading procedure with EFFromPreferred. The UE then shall use the From
Preferred value in the EFFromPreferred as described in 3GPP TS 24.607 [86] subclause 4.5.2.12.
3GPP
Release 15 267 3GPP TS 31.102 V15.21.0 (2018-0610)
Request: The ME may perform the reading procedure with EFIMSConfigData. If the ME performs the reading
procedure with EFIMSConfigData, the UE shall use the IMS Configuration Data in the EFIMSConfigData as
described in 3GPP TS 24.229 [32] subclause L.2.2.5.1D and
3GPP TS 24.229 [32] subclause 6.1.1.
Request: The ME may perform the reading procedure with EFXCAPConfigData . If the ME performs the reading
procedure with EFXCAPConfigData , the UE shall use the EFXCAPConfigData as described in TS 24.623
[102] subclause 5.2.1.3 and TS 24.623 [102] subclause B.2
6 Security features
The security aspects of 3G are specified in TS 33.102 [13] and TS 33.103 [14]. This clause gives information related to
security features supported by the USIM to enable the following:
The mechanism achieves mutual authentication by the user and the network showing knowledge of a secret key K
which is shared between and available only to the USIM and the AuC in the user's HE. In addition, the USIM and the
3GPP
Release 15 268 3GPP TS 31.102 V15.21.0 (2018-0610)
HE keep track of counters SQNMS and SQNHE respectively to support network authentication. SQNHE is a counter in the
HLR/AuC, individual for each user and SQNMS denotes the highest sequence number the USIM has ever accepted.
When the SN/VLR initiates an authentication and key agreement, it selects the next authentication vector and sends the
parameters RAND and AUTN (authentication token) to the user. Each authentication token consists of the following
components: a sequence number SQN, an Authentication Management Field (AMF) and a message authentication code
MAC over the RAND, SQN and AMF.
The USIM checks whether AUTN can be accepted and, if so, produces a response RES which is sent back to the
SN/VLR. The SN/VLR compares the received RES with XRES. If they match the SN/VLR considers the authentication
and key agreement exchange to be successfully completed. The USIM also computes CK and IK. The established keys
CK and IK will be used by the ME to perform ciphering and integrity functions.
A permanent secret key K is used in this procedure. This key K has a length of 128 bits or 256 bits and is stored within
the USIM for use in the algorithms described below. Also more than one secret key K can be stored in the USIM. The
active key to be used by the algorithms is signalled within the AMF field in the AUTN.
f1: a message authentication function for network authentication used to compute XMAC;
f1*: a message authentication function for support to re-synchronisation with the property that no
valuable information can be inferred from the function values of f1* about those of f1, ..., f5, f5*
and vice versa;
f2: a message authentication function for user authentication used to compute SRES;
f3: a key generating function to compute the cipher key CK;
f4: a key generating function to compute the integrity key IK;
f5: a key generating function to compute the anonymity key AK (optional);
f5*: a key generating function to compute AK in re-synchronisation procedures with the property that
no valuable information can be inferred from the function values of f5* about those of f1, f1*,
f2, ..., f5 and vice versa.
These cryptographic functions may exist either discretely or combined within the USIM.
- The USIM application shall use a global key reference as PIN and local key reference as PIN2. For access to
DFTELECOM the PIN shall be verified. Access with PIN2 is limited to the ADF(USIM).
- The only valid values for the usage qualifier are '00' (verification requirement is not used) and '08' (user
authentication knowledge based (PIN)) as defined in ISO/IEC 7816-4 [20].
Disabling of PIN2 is allowed. This is, however, not the case if PIN2 is mapped to the CHV2 of a GSM application.
3GPP
Release 15 269 3GPP TS 31.102 V15.21.0 (2018-0610)
7 USIM Commands
7.1 AUTHENTICATE
7.1.1 Command description
The function can be used in several different contexts:
- a 3G security context, when 3G authentication vectors (RAND, XRES, CK, IK, AUTN) are available (i.e. the
UE is located in the UTRAN, or in a GSM radio access network which is connected to a 3G or 3G capable
VLR/SGSN), or
- a GSM security context, when GSM authentication data are available only (i.e. the UE is located in the GSM
radio access network which is connected to a non-3G capable VLR/SGSN)
- a Local Key Establishment security context, when a Local Key Establishment procedure is requested.
The function is used in GSM or 3G security context during the procedure for authenticating the USIM to its HE and
vice versa. In addition, a cipher key and an integrity key are calculated. For the execution of the command the USIM
uses the subscriber authentication key K, which is stored in the USIM.
The function is used in VGCS/VBS security context during the procedure for retrieving the VGCS/VBS Short Term
Key (VSTK) used by the terminal in establishing VGCS/VBS calls.
a) Bootstrapping Mode: during the procedure for mutual authenticating of the USIM and the Bootstrapping Server
Function (BSF) and for deriving bootstrapped key material from the AKA run.
b) NAF Derivation Mode: during the procedure for deriving Network Application Function (NAF) specific keys
from previous bootstrapped key material.
a) MSK Update Mode: during the procedure for updating an MBMS Service Key (MSK).
b) MTK Generation Mode: during the procedure for retrieving the MBMS Traffic Key (MTK) used by the terminal
to decrypt MBMS data.
The function is related to a particular USIM and shall not be executable unless the USIM application has been selected
and activated, and the current directory is the USIM ADF or any subdirectory under this ADF and a successful PIN
verification procedure has been performed (see clause 5).
Then the USIM computes XMAC = f1K (SQN || RAND || AMF) and compares this with the MAC which is included in
AUTN. If they are different, the USIM abandons the function.
Next the USIM verifies that the received sequence number SQN is previously unused. If it is unused and its value is
lower than SQNMS, it shall still be accepted if it is among the last 32 sequence numbers generated. A possible
verification method is described in TS 33.102 [13].
3GPP
Release 15 270 3GPP TS 31.102 V15.21.0 (2018-0610)
NOTE: This implies that the USIM has to keep a list of the last used sequence numbers and the length of the list
is at least 32 entries.
If the USIM detects the sequence numbers to be invalid, this is considered as a synchronisation failure and the USIM
abandons the function. In this case the command response is AUTS, where:
AUTS = Conc(SQNMS) || MACS;
Conc(SQNMS) = SQNMS f5*K(RAND) is the concealed value of the counter SQNMS in the USIM; and.
MACS = f1*K(SQNMS || RAND || AMF) where:
RAND is the random value received in the current user authentication request;
the AMF assumes a dummy value of all zeroes so that it does not need to be transmitted in clear in the
resynchronisation message.
If the sequence number is considered in the correct range, the USIM computes RES = f2 K (RAND), the cipher key
CK = f3K (RAND) and the integrity key IK = f4K (RAND) and includes these in the command response. Note that if this
is more efficient, RES, CK and IK could also be computed earlier at any time after receiving RAND.
The use of AMF is HE specific and while processing the command, the content of the AMF has to be interpreted in the
appropriate manner. The AMF may e.g. be used for support of multiple algorithms or keys or for changing the size of
lists, see TS 33.102 [13].
If Service n°27 is "available", the USIM calculates the GSM response parameter K C, using the conversion function
defined in TS 33.102 [13].
Input:
Output:
Or
Or
- AUTS.
The USIM computes RES = f2K (RAND), the cipher key CK = f3K (RAND) and the integrity key IK = f4K (RAND).
Next the USIM calculates the GSM response parameters SRES and KC, using the conversion functions defined in
TS 33.102 [13].
Input:
- RAND.
Output:
- SRES; KC.
The USIM computes the Short Term Key (VSTK) associated with a particular VGCS/VBS Group Identifier
(Group_Id). For this computation, the USIM uses the Voice Group (for VGCS) or Broadcast Group (for VBS) Key
(V_Ki) identified by their respective Group_Id and Master Group Key Identifier (VK_Id). The USIM retrieves the
Group_Id and the service flag (VGCS or VBS) from the received Voice Service Identifier (Vservice_Id).
3GPP
Release 15 271 3GPP TS 31.102 V15.21.0 (2018-0610)
The USIM shall first search if the Group_Id corresponds to a stored VGCS Group Identifier in EFVGCS or a stored VBS
Group Identifier in EFVBS.
Then, the USIM shall retrieve the V_Ki corresponding to the given Group_Id and VK_Id.
Then the USIM uses V_Ki and VSTK_RAND as input parameters for the A8_V key derivation function (as defined in
TS 43.020 [44]) in order to compute and returns VSTK.
Input:
Output:
- VSTK.
The USIM receives the RAND and AUTN*. The USIM first computes the anonymity key AK = f5K (RAND) and
retrieves the sequence number SQN = (SQN Å AK) Å AK.
The USIM calculates IK = f4K (RAND) and MAC (by performing the MAC modification function described in
TS 33.220 [42]). Then the USIM computes XMAC = f1K (SQN || RAND || AMF) and compares this with the MAC
previously produced. If they are different, the USIM abandons the function.
Then the USIM performs the checking of AUTN* as in UMTS security context. If the USIM detects the sequence
numbers to be invalid, this is considered as a synchronisation failure and the USIM abandons the function. In this case
the command response is AUTS, which is computed as in UMTS security context.
If the sequence number is considered in the correct range, the USIM computes RES = f2 K (RAND) and the cipher key
CK = f3K (RAND).
The USIM then derives and stores GBA_U bootstrapped key material from CK, IK values. The USIM shall also stores
RAND in the RAND field of EFGBABP
The USIM stores GBA_U bootstrapped key material from only one bootstrapping procedure. The previous
bootstrapped key material, if present, shall be replaced by the new one. This key material is linked with the data
contained in EFGBABP : RAND, which is updated by the USIM and B-TID, which shall be further updated by the ME.
NOTE: According to TS 33.220 [42], NAF-specific keys that may be stored on the USIM are not affected by this
bootstrapping operation.
RES is included in the command response after flipping the least significant bit.
Input:
- RAND, AUTN*
Output:
- RES
or
- AUTS
3GPP
Release 15 272 3GPP TS 31.102 V15.21.0 (2018-0610)
The USIM performs Ks_ext_NAF and Ks_int_NAF derivation as defined in TS 33.220 [42] using the key material
from the previous GBA_U bootstrapping procedure.
If no key material is available this is considered as a GBA Bootstrapping failure and the USIM abandons the function.
The status word ‘6985’ (Conditions of use not satisfied) is returned.
Otherwise, the USIM stores Ks_int_NAF and associated B-TID together with NAF_ID. The Ks_int_NAF keys related
to other NAF_Ids, which are already stored in the USIM, shall not be affected. The USIM updates EFGBANL as follows:
- If a record with the given NAF_ID already exists, the USIM updates the B-TID field of this record with the B-
TID value associated to the GBA_U bootstrapped key involved in this GBA_U NAF derivation procedure.
- If a record with the given NAF_ID does not exist, the USIM uses an empty record to store the NAF_ID and the
B-TID value associated to the GBA_U bootstrapped key involved in this GBA_U NAF Derivation procedure.
NOTE: According to TS 33.220 [42], the USIM can contain several Ks_int_NAF together with the associated B-
TID and NAF_ID, but there is at most one pair of Ks_int_NAF and associated B-TID stored per
NAF_ID.
- In case no empty record is available the USIM shall overwrite an existing record to store the NAF_ID and the B-
TID value associated to the GBA_U bootstrapped key involved in this GBA_U NAF Derivation procedure. To
determine the record to overwrite, the USIM shall construct a list of record numbers by storing in the list first
position the record number of the last used (i.e. involved in an Authentication command) or derived
Ks_int_NAF and by shifting down the remaining list elements. The last record number in this list corresponds to
the record to overwrite when the USIM runs out of free records. If an existing record corresponding to a
Ks_int_NAF key in use is overwritten, the application Ks_int_NAF shall not be affected (e.g. in case a
Ks_int_NAF was put into use as an MBMS MUK key, the MUK key shall continue to be available for the
MBMS application).
Input:
- NAF_ID, IMPI
Output:
- Ks_ext_NAF
The USIM receives the MIKEY packet containing an MSK update message. First, the USIM uses the MUK ID to
identify the Ks_int_NAF corresponding with a previous bootstrapping procedure.
The USIM shall check if a new NAF derivation procedure involving the received Idi in the MIKEY message has been
performed or if it is the first time that this Idi is used. If this check cannot be performed because the corresponding
Ks_int_NAF key was overwritten, the USIM abandons the function and returns the status word '6985' (Conditions of
use not satisfied). In case of a new NAF derivation procedure or a new Idi, the USIM shall store the last bootstrapped
Ks_int_NAF as the last generated MUK and update EFMUK as follows:
- If a record with the received Idi (included in the MUK ID: see TS 33.246 [43]) value is already present, then the
MUK ID is stored in the corresponding field of this record, and the associated Time Stamp Counter (TS) field is
reset. Additionally, the USIM internally stores the last successfully used MUK (i.e. MUK that was used during
the last successful MSK update procedure), along with its MUK ID for further use (e.g. to detect Key freshness
failure).
- If a record with the received Idi does not exist, the USIM uses an empty record to include the MUK ID, and reset
the associated TS field.
- In case there is no empty record available in EFMUK the USIM abandons the function and the status word '9867'
(Authentication error, no available memory space in EFMUK) is returned.
3GPP
Release 15 273 3GPP TS 31.102 V15.21.0 (2018-0610)
NOTE: In case no empty record in EFMUK is available the ME should run a MUK Deletion Mode procedure to
free entries in EFMUK before running an MSK Update Mode procedure that involves a new MUK key.
NOTE: In case the ME receives the status word '6985', the ME should derive the required Ks_int_NAF key. In
case the corresponding bootstrapping key Ks is still available, the ME should invoke the Authenticate
command in "GBA - NAF derivation Mode" before invoking again the AUTHENTICATE command in
"MBMS - MSK Update Mode". In case the corresponding bootstrapping key has been updated, the ME
should put the new B-TID into use.
If the received MUK ID does not correspond to the last generated MUK (i.e. last bootstrapped MUK) then the USIM
proceeds as follows:
- If the received MUK ID corresponds to the last successfully used MUK then the USIM uses this MUK to verify
the integrity of the message. If the verification is unsuccessful, the USIM abandons the function and returns the
status word '9862' (Authentication error, incorrect MAC). If the verification is successful, the USIM abandons
the function and returns the status word '9865' (Key Freshness Failure), indicating to the ME that the received
MIKEY message is protected using the last successfully used MUK that does not correspond to the last
generated MUK (the new B-TID shall be put into use: see TS 33.246 [43]). In this case, the USIM shall not
return a MIKEY verification message.
- Otherwise, this is considered as a bootstrapping failure (incorrect MUK) and the USIM abandons the function.
The status word ‘6A88’ (Referenced data not found) is returned.
Otherwise, if the received MUK ID corresponds to the last generated MUK, the USIM uses the MUK value for MSK
validation and derivation functions as described in TS 33.246 [43]. If the validation is unsuccessful, the status word
'9862' (Authentication error, incorrect MAC) is returned and the USIM abandons the function.
After a successful MSK Update procedure the USIM stores the received credentials (e.g. MSK and/or Key Validity
data) and updates EFMSK as follows:
- If a record with the received Key Domain ID and Key Group part (i.e. Key Group part of the MSK ID) already
exists, USIM stores the older MSK ID (if any) and its associated TS as the 2nd MSK ID and TS. The newer MSK
ID is stored as the 1st MSK ID. In case the received MSK message has the same MSK ID as a stored MSK, the
TS associated to this stored MSK is stored as the 1st TS. Otherwise, the 1st TS value is reset. The number of
stored MSK IDs and corresponding TS shall be set to '02' if the USIM stores two different MSK IDs. The USIM
shall not store two MSK IDs with the same Key Number part in the same record.
- If a record with the received Key Domain ID and Key Group part does not exist, the USIM uses an empty record
to include those values. The received MSK ID is stored as the 1st MSK ID and the associated TS is reset. The 2nd
MSK ID and the associated TS are set to 'FF FF'. The number of stored MSK IDs and corresponding TS shall be
set to '01'. In case there is no empty record available in EFMSK the USIM abandons the function and the status
word '9866' (Authentication error, no available memory space) is returned.
- In the case of a BM-SC solicited pull procedure (i.e. when the Key Number part of the MSK ID is set to 0x0),
EFMSK is not updated.
NOTE: In case no empty record is available the ME should run an MSK Deletion Mode procedure to free entries
in EFMSK before running an MSK Update Mode procedure that contains a new MSK key.
Then, the USIM stores the Time Stamp field (retrieved from the MIKEY message) in its corresponding field under
EFMUK.
The USIM stores internally the last successfully used MUK along with its MUK ID for further use. This MUK may be
used beyond its GBA validity (i.e. after the derivation of a new Ks_int_NAF resulting from a new bootstrap procedure)
to verify the integrity of a MIKEY message in order to detect a synchronization failure. This may occur if the last
derived Ks_int_NAF did not reach the BM-SC.
The MSK is not necessarily updated in the MIKEY message, since a MSK transport message can be sent e.g. to update
the Key Validity data or as part of a BM-SC solicited pull procedure. In such a case the USIM shall use the status word
'9000' to inform the ME that the MIKEY message validation using the last generated MUK has succeeded.
Finally, if the V-bit in the HDR field of the received MIKEY message is set then the USIM shall produce a MSK
Verification Message as described in TS 33.246 [43]. In this case the command response is the MIKEY verification
message.
3GPP
Release 15 274 3GPP TS 31.102 V15.21.0 (2018-0610)
Input:
- MIKEY message
Output:
- MIKEY message
or
- None
7.1.1.7 Void
The USIM receives the MIKEY message containing an MBMS MTK and a Salt key (if Salt key is available). First, the
USIM retrieves the MSK with the Key Domain ID and the MSK ID given by the Extension payload of the MIKEY
message (as described in TS 33.246 [43]).
If the needed MSK does not exist, this is considered as a MSK failure and the USIM abandons the function. The status
word '6A88' (Referenced data not found) is returned.
If the key validity data of the MSK indicates an invalidated MSK (i.e. SEQl is greater than SEQu) then the USIM
returns the status word '6985' (Conditions of use not satisfied) and abandons the function. SEQl and SEQu are defined
in TS 33.246 [43].
Otherwise, the USIM performs the MBMS Generation and Validation Function (MGV-F) as described in
TS 33.246 [43] using MSK.
If the USIM detects that the given MTK ID is invalid, this is considered as a SEQp freshness failure and the USIM
abandons the function. The status word '9865' (Key freshness failure) is returned.
If the integrity validation of the MIKEY message is unsuccessful, the USIM abandons the function and returns the
status word '9862' (Authentication error, incorrect MAC).
After successful MGV_F procedure the USIM stores the Time Stamp field (retrieved from the MIKEY message) as the
Time Stamp Counter (TS) associated with the involved MSK under EFMSK
The USIM also stores MTK ID (retrieved from the MIKEY message) as the SEQl associated with MSK.
Then, the USIM returns MTK and Salt key (if Salt key is available).
Input:
- MIKEY message
Output:
The USIM receives the Key Domain ID and the Key Group part of the MSK ID. The USIM shall identify in the EFMSK
the record containing MSK IDs having this Key Domain ID and Key Group part.
If no record is identified, the USIM abandons the function and returns the status word '6A88' (Referenced data not
found).
If a record is found, the USIM shall delete all corresponding MSKs and set to 'FF' the bytes of this record.
3GPP
Release 15 275 3GPP TS 31.102 V15.21.0 (2018-0610)
Input:
Output:
- None.
The USIM shall identify in EFMUK the record containing the received MUK ID.
If no record is identified, the USIM abandons the function and returns the status word '6A88' (Referenced data not
found).
If a record is found, the USIM shall delete the corresponding MUK and set to 'FF' the bytes of this record. If a
corresponding Ks_int_NAF key is present (i.e. with the same NAF_ID), it shall be deleted and its corresponding record
in EFGBANL shall be set to 'FF'. In case the corresponding Ks key is present (i.e. with the same B-TID), it shall be deleted
and the content of EFGBABP shall be set to 'FF'.
Input:
MUK ID TLV
Output:
- None
The USIM receives the NAF_ID corresponding to the NAF Key Centre, the Terminal_ID, the Terminal_appli_ID, the
UICC_appli_ID, RANDx, the Counter Limit value and the MAC as described in TS 33.110 [47].
The USIM uses the NAF_ID to identify the Ks_int_NAF associated to the NAF Key Centre. If no valid Ks_int_NAF is
available, this is considered as a Key Establishment failure and the USIM abandons the function. The status word
'6A88' (Referenced data not found) is returned.
If the Ks_local key derivation is not authorized by the local UICC policy (e.g. Terminal_appli_ID/UICC_appli_ID
association not authorized or Terminal_ID value not authorized), the USIM abandons the function. The status word
'6985' (Conditions of use not satisfied) is returned.
Otherwise, the USIM retrieves the appropriate Ks_int_NAF, derives Ks_local as described in TS 33.110 [47]. The
USIM verifies the MAC value received from the Terminal as described in TS 33.110 [47]:
- If the verification is unsuccessful, the USIM abandons the function and returns the status word '9862'
(Authentication error, incorrect MAC).
- If the verification is successful, the USIM stores Ks_local and associated parameters Terminal_ID,
Terminal_appli_ID, UICC_appli_ID, RANDx and the Ks_local Counter Limit. The USIM returns the Local Key
Establishment Operation Response TLV (indicating a successful Key Derivation operation) and a response
MAC, which is derived as described in TS 33.110 [47].
The minimum number of Local keys that can be stored by the USIM shall be defined by the service provider at the pre-
issuance of the card.
In case the maximum number of Local Key was already reached or there is not enough available memory in the USIM,
the USIM shall overwrite a Local Key and its associated data in order to store the new one. To determine the Ks_local
to overwrite, the USIM shall construct a list of Ks_local identifiers by storing in the list first position the Ks_local
identifier of the last used or derived Ks_local and by shifting down the remaining list elements. The last Ks_local
identifier in this list corresponds to the Ks_local to overwrite when the USIM runs out of free memory or when the
3GPP
Release 15 276 3GPP TS 31.102 V15.21.0 (2018-0610)
maximum number of Ks_local keys is reached. If an existing Ks_local in use is overwritten, the application using
Ks_local shall not be affected.
Input:
- Local Key Establishment Mode (Key Derivation mode), Counter Limit, request MAC, Key Identifier (i.e.
NAF_ID, Terminal_ID, Terminal_appli_ID, UICC_appli_ID, RANDx)
Output:
7.1.1.12 Local Key Establishment security context (Key Availability Check mode)
USIM operations in this security context are supported if service n°68 and service n°76 are "available".
The USIM receives a Ks_local identifier. The USIM checks if a corresponding valid Ks_local is available. If a valid
Ks_local key is available the Local Key Establishment Operation Response TLV (indicating a successful Key
Availability Check operation) is returned. In case no valid Ks_local key is available the command fails and the status
word '6A88' (Referenced data not found) is returned.
Input:
Local Key Establishment Mode (Key Availability Check mode), Key identifier (i.e. NAF_ID, Terminal_ID,
Terminal_appli_ID, UICC_appli_ID, RANDx).
Output:
The ODD instruction code shall be used with the security context specified in table 2, when challenge and response data
is TLV encapsulated regardless of their length. Terminals and UICCs that do not support security context requiring
TLV format (e.g. MBMS), do not have to support AUTHENTICATE command with ODD instruction code.
Code Value
CLA As specified in TS 31.101 [11]
INS '88'
P1 '00'
P2 See table 1 below
Lc See below
Data See below
Le '00', or maximum length of data expected in
response
3GPP
Release 15 277 3GPP TS 31.102 V15.21.0 (2018-0610)
Coding Meaning
b8-b1
'1-------' Specific reference data (e.g. DF
specific/application dependant key)
'----- XXX' Authentication context:
000 GSM context
001 3G context
010 VGCS/VBS context
100 GBA context
The authentication data and the authentication response data are encapsulated in BER-TLV objects structured using tag
'73' for BER-TLV structured data and tag '53' otherwise.
How this command can chain successive blocks of authentication data, or authentication
response data is described in TS 31 101 [11].
Input:
Output:
- None.
Code Value
CLA As specified in TS 31.101 [11]
INS '89'
P1 As specified in TS 31.101 [11]
P2 See table 2 below
Lc Length of the subsequent data field
Data Authentication related data
Le Not present
If P1 indicates "First block of authentication response data" or "Next block of authentication response data":
Input:
- None.
Output:
Code Value
CLA As specified in TS 31.101 [11]
INS '89'
P1 As specified in TS 31.101 [11]
P2 See table 2 below
Lc Not present
Data Not present
Le Length of the response data
Parameter P1 is used to control the data exchange between the terminal and the UICC as defined in TS 31.101 [11].
3GPP
Release 15 278 3GPP TS 31.102 V15.21.0 (2018-0610)
Coding Meaning
b8-b1
'1-------' Specific reference data (e.g. DF specific/application dependant key)
'----- XXX' Authentication context:
101 MBMS context
110 Local Key Establishment mode
Command parameters/data:
The coding of AUTN is described in TS 33.102 [13]. The most significant bit of RAND is coded on bit 8 of byte 2. The
most significant bit of AUTN is coded on bit 8 of byte (L1+3).
The most significant bit of RES is coded on bit 8 of byte 3. The most significant bit of CK is coded on bit 8 of byte
(L3+4). The most significant bit of IK is coded on bit 8 of byte (L3+L4+5).
The coding of AUTS is described in TS 33.102 [13]. The most significant bit of AUTS is coded on bit 8 of byte 3.
3GPP
Release 15 279 3GPP TS 31.102 V15.21.0 (2018-0610)
The most significant bit of SRES is coded on bit 8 of byte 2. The most significant bit of Kc is coded on bit 8 of byte 7.
Vservice_Id is coded in the same way as the octets 2-5 in the Descriptive group or broadcast call reference information
element as defined in TS 24.008 [9].
Coding of VK_Id
Coding Meaning
b8-b1
'00000001' Corresponds to the 1st group key
'00000010' Corresponds to the 2nd group key
The coding of VSTK_RAND is described in TS 43.020 [44]. The VSTK_RAND shall be inserted left-aligned into the
L1 bytes, with unused bits to the right set to zero.
3GPP
Release 15 280 3GPP TS 31.102 V15.21.0 (2018-0610)
Response parameters/data, GBA security context (NAF Derivation Mode), command successful:
Only the MIKEY message shall be transmitted in the MBMS security context mode '01' or '02'.
Only the Key Domain ID (coded on 3 bytes as described in TS 33.246 [43]) concatenated with the Key Group part of
the MSK ID (coded on two bytes as described in TS 33.246 [43] where the last transmitted byte represents the least
significant byte of the Key Group part) shall be transmitted in the MBMS security context mode '03'.
Only the MUK ID TLV shall be transmitted in the MBMS security context mode '04'. The MUK ID TLV, containing
the MUK Idr and MUK Idi only, shall be encoded as described in clause 4.2.81.
Parameter MBMS Security Context Mode specifies the MBMS mode in which MBMS security procedure is performed
as follows:
Coding Meaning
'01' MSK Update Mode
‘02' MTK Generation Mode
'03' MSK Deletion Mode
'04' MUK Deletion Mode
Response parameters/data, MBMS security context (MSK Update Mode), command successful:
3GPP
Release 15 281 3GPP TS 31.102 V15.21.0 (2018-0610)
Response parameters/data, MBMS security context (MTK Generation Mode), command successful:
Response parameters/data, MBMS security context (MSK and MUK Deletion Mode), command successful:
Note: The constructed TLV tag value 'AE' is used by OMA BCAST Smart Card Profile [49] for the encapsulation
of command and response parameters/data.
Operation Status:
'DB': Successful Operation
3GPP
Release 15 282 3GPP TS 31.102 V15.21.0 (2018-0610)
- Key Derivation Data Object content: The TLVs defined in table 4 are included in the Key Derivation Data
Object.
Response parameters/data, Local Key Establishment security context (Key Derivation mode), command successful:
Key Derivation Operation Response Data Object content: The TLVs defined in table 5 are included in the Key
Derivation Operation Response Data Object.
3GPP
Release 15 283 3GPP TS 31.102 V15.21.0 (2018-0610)
7.1.2.6.2 Local Key Establishment security context (Key Availability Check mode)
Command parameters/data:
- Key Availability Check Data Object content: The TLVs defined in table 6 are included in the Key Availability
Check Data Object.
Response parameters/data, Local Key Establishment security context (Key Availability Check mode), command
successful:
- Key Availability Check Operation Response Data Object content: The TLV defined in table 7 is included in the
Key Availability Check Operation Response Data Object.
Table 7: Coding of the Key Availability Check Operation Response Data Object
3GPP
Release 15 284 3GPP TS 31.102 V15.21.0 (2018-0610)
7.2 Void
3GPP
Release 15 285 3GPP TS 31.102 V15.21.0 (2018-0610)
Status Words
AUTHENTICATE
GET IDENTIYY
90 00 * *
91 XX * *
93 00
98 50
98 62 *
98 64 *
98 65 *
98 66 *
98 67 *
62 00 * *
62 81
62 82
62 83
62 F1 *
62 F3 *
63 CX
63 F1 *
64 00 * *
65 00 * *
65 81 * *
67 00 * *
67 XX – (see note) * *
68 00 * *
68 81 * *
68 82 * *
69 81
69 82 * *
69 83
69 84 *
69 85 * *
69 86
6A 80
6A 81 * *
6A 82
6A 83
6A 86 * *
6A 87
6A 88 * *
6B 00 * *
6E 00 * *
6F 00 * *
6F XX – (see note) * *
NOTE:Except SW2 = '00'.
3GPP
Release 15 286 3GPP TS 31.102 V15.21.0 (2018-0610)
Note: OMA BCAST Smart Card Profile [49] defines a command using instruction code INS '1B'
- a SUCI context, to retrieve the SUCI when "SUCI calculation is to be performed by the USIM".
The function is related to a particular USIM and shall not be executable unless the USIM application has been selected
and activated, and the current directory is the USIM ADF or any subdirectory under this ADF and a successful PIN
verification procedure has been performed (see clause 5).
If GET IDENTITY command is not supported by the UICC, then the status word '6D00' (Instruction code not supported
or invalid) shall be returned.
The command returns the SUCI which is a privacy preserving identifier containing the concealed SUPI. The function is
used in 5GS in the specific cases described in 3GPP TS 33.501 [105] prior to mutual authentication between the UE and
the SN.
For the execution of the command, the following information shall be available in the USIM:
- SUPI.
NOTE: Provision and storage of the information in the USIM when "SUCI calculation is to be performed by the
USIM" (i.e. Service n°124 and Service n°125 are "available") is out of the scope of the specification.
The SUCI is designed for one-time use, however, the freshness and randomness of SUCI returned upon each call of the
command depends on the protection scheme configured. There is the special case where the protection scheme used is
null-scheme, in such case SUCI contains the non concealed SUPI.
If the home network public key is not provisioned in the USIM, the SUCI shall be calculated using the null-scheme
irrespective of the protection scheme stored in the USIM.
3GPP
Release 15 287 3GPP TS 31.102 V15.21.0 (2018-0610)
The returned SUCI consists of the concatenation of the following information as described in 3GPP TS 23.003
[25]33.501 [105]:
Editor’s Note: Coding of the following information in SUCI is not yet defined in 3GPP TS 24.501 [104]
- SUPI Type
- Routing indicator.
Editor’s Note: 3GPP TS 33.501 does not specify which information is contained in Home Network identifier. Only
examples are provided in Section 6.12.
- Scheme output, resulting from the protection scheme profile, identified by the protection scheme identifier. The
protection scheme profile shall be one of those defined in Annex C of 3GPP TS 33.501 [105] or one of those
specified by the Home network.
- "SUCI calculation is to be performed by the ME” (i.e. Service n°124 is "available", and Service n°125 is not
"available")
the status word '6985' (Conditions of use not satisfied) shall be returned
Editor’s Note: It is FFS to specify the behavior in case other parameters (e.g. Home network public key identifier,
some necessary data is not provisioned) are not correctly configured
Code Value
CLA As specified in TS 31.101 [11]
INS '78'
P1 '00'
P2 Identity context, see Table X below'
Lc Length of the subsequent data field or not present,
see below
Data See below
Le '00', or maximum length of data expected in
response
3GPP
Release 15 288 3GPP TS 31.102 V15.21.0 (2018-0610)
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 - - - - - - - Global reference data
1 - - - - - - - Special reference data
- X X X X X X X Identity Context (See below)
- 0 0 0 0 0 0 1 SUCI
Response parameters/data:
- SUCI
For contents and coding of the SUCI data object TLV value see 3GPP TS 23.003 [25] and
3GPP TS 24.501 [104]TS 33.501 [105]. The most significant bit of SUCI is the most significant bit of the 1st
byte of this TLV value field. The least significant bit of SUCI is the least significant bit of the last byte of this
TLV value field.
Editor’s Note: Format of SUCI value is still to be completed in 3GPP TS 24.501 [104].not defined yet in 3GPP TS
33.501.
8 Void
3GPP
Release 15 289 3GPP TS 31.102 V15.21.0 (2018-0610)
Annex A (informative):
EF changes via Data Download or USAT applications
This annex defines if changing the content of an EF by the network (e.g. by sending an SMS), or by a USAT
Application, is advisable. Updating of certain EFs "over the air" such as EFACC could result in unpredictable behaviour
of the UE; these are marked "Caution" in the table below. Certain EFs are marked "No"; under no circumstances should
"over the air" changes of these EFs be considered.
3GPP
Release 15 290 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 291 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 292 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 293 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 294 3GPP TS 31.102 V15.21.0 (2018-0610)
Annex B (normative):
Image Coding Schemes
The following image coding schemes are applicable to rectangular raster images. Raster image points are assumed to be
of square shape. They are numbered sequentially from 1 onwards, starting at the upper left corner, proceeding line by
line downwards, each line in turn proceeding from left to right, and ending at the image's lower right corner.
The following example illustrates the numbering scheme for raster image points by showing how the corner points are
numbered, assuming an image length of x points and an image height of y points.
1 x
(x * (y-1) + 1) (x * y)
- 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
Byte 2:
B8 b7 b6 b5 b4 b3 b2 b1
etc.
3GPP
Release 15 295 3GPP TS 31.102 V15.21.0 (2018-0610)
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.
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.
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
3GPP
Release 15 296 3GPP TS 31.102 V15.21.0 (2018-0610)
etc.
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:
Each CLUT entry in turn comprises 3 bytes defining one colour in the red-green-blue colour space:
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.
- Entry number C-1in the colour look-up table (CLUT), where C is the number of entries in the CLUT,
defines transparency. Raster image points which point to this entry are transparent, so that the underlying
colour in the display is shown.
The three colour-coding bytes of entry number C-1 in the CLUT are of no importance when referenced from images
using the '22' coding scheme.
NOTE: Two different descriptors in the EFIMG file with Image Coding Scheme '21' and '22' may point to the same
actual image instance. In that case, the descriptor with Image Coding Scheme '21' would describe an
image where a raster image point pointing to entry number C-1 in the CLUT would have the colour
described in that CLUT entry, while the descriptor with Image Coding Scheme '22' would describe an
image where a raster image point pointing to entry number C-1 in the CLUT is transparent.
3GPP
Release 15 297 3GPP TS 31.102 V15.21.0 (2018-0610)
Annex C (informative):
Structure of the Network parameters TLV objects
Structure of the GSM network parameter TLV object, 0<= m <=32
Tag Length Tag Length BCCH Tag Length BCCH BCCH BCCH
Currently Frequenc Neighbour Neighbour Neighbour ………… Neighbour
Camped y BCCH Frequency Frequency Frequency
Frequenc downlink Frequency 1 2 m
y
'A0' '80' '02' '81'
Tag Length Tag Length Intra Primary Primary Tag Lengt Inter Primary
Intra Frequency Scrambling Scrambling Inter h Frequency Scrambling
frequency downlink code 1 code m frequency downlink code n1
carrier carrier carrier carrier
'A1' '80' '81'
Tag Length Tag Length Intra Primary Primary Tag Lengt Inter Primary
Intra Frequency Scrambling Scrambling Inter h Frequency Scrambling
frequency downlink code 1 code m frequency downlink code n1
carrier carrier carrier carrier
'A2' '80' '81'
3GPP
Release 15 298 3GPP TS 31.102 V15.21.0 (2018-0610)
Annex D (informative):
Tags defined in 31.102
3GPP
Release 15 299 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 300 3GPP TS 31.102 V15.21.0 (2018-0610)
(EFNASCONFIG)
3GPP
Release 15 301 3GPP TS 31.102 V15.21.0 (2018-0610)
'81' Graphics CSG Type tag (Icon link is record number) CSG Type (EFCSGT)
'81' ICE Free Format Content tag In Case of Emergency – Free Format
(EFICE-FF)
'81' MM File Identifier / SFI tag Multimedia Messages List (EFMML)
'81' ProSe CollectionPeriod tag Collection Period Parameter
(EFPROSE_UIRC)
'82' Counter tag WLAN Reauthentication Identity (EFWRI)
'82' MMS User Preference information tag MMS User Preference (EFMMSUP)
'82' Password Tag Network Connectivity Parameters for
USIM IP connections (EFNCP-IP)
'82' Attach with IMSI Tag Non Access Stratum Configuration
(EFNASCONFIG)
'82' MM Content Data Object Tag Multimedia Messages List (EFMML)
'82' ProSe ReportingWindow tag Reporting Window Parameter
(EFPROSE_UIRC)
'802' Home Network Public Key Identifier tag Home Network Public Key Identifier
(EFSUCI_Calc_Info)
'81' KSEAF tag EF5GAUTHKEYS
'83' Data Destination Address Range Tag Network Connectivity Parameters for
USIM IP connections (EFNCP-IP)
'83' Minimum Periodic Search Timer Tag Non Access Stratum Configuration
(EFNASCONFIG)
'83' MM Size tag Multimedia Messages List (EFMML)
'83' ProSe ReportGroupParameters tag Reporting Parameter for Goups
(EFPROSE_UIRC)
'813' Home Network Public Key Value tag Home Network Public Key Value
(EFSUCI_Calc_Info)
'84' Bearer Description Tag Network Connectivity Parameters for
USIM IP connections (EFNCP-IP)
'84' Extended access barring Tag Non Access Stratum Configuration
(EFNASCONFIG)
'84' MM Status tag Multimedia Messages List (EFMML)
'84' ProSe ReportTimeStampsFirstTransmissionAndReception tag Reporting Parameter (EFPROSE_UIRC)
'85' Timer T3245 Behaviour Tag Non Access Stratum Configuration
(EFNASCONFIG)
'85' MM Alpha Identifier tag Multimedia Messages List (EFMML)
'85' ProSe ReportDataTransmitted tag Reporting Parameter for transmitted
Data (EFPROSE_UIRC)
'86' Override NAS signalling low priority Tag Non Access Stratum Configuration
(EFNASCONFIG)
'86' ProSe ReportDataReceived tag Reporting Parameter for received Data
(EFPROSE_UIRC)
'87' Override Extended access barring Tag Non Access Stratum Configuration
(EFNASCONFIG)
'87' ProSe ReportTimeStampsOutOfCoverage tag Reporting Parameter (EFPROSE_UIRC)
'88' Fast First Higher Priority PLMN Search Tag Non Access Stratum Configuration
(EFNASCONFIG)
'88' ProSe ReportLocationInCoverage tag Reporting Parameter (EFPROSE_UIRC)
'89' Text CSG Type tag CSG Type (EFCSGT)
'89' E-UTRA Disabling Allowed for EMM cause #15 Tag Non Access Stratum Configuration
(EFNASCONFIG)
'89' ProSe ReportRadioParameters tag Reporting Parameter for Radio
Parameters (EFPROSE_UIRC)
'8A' SM RetryWaitTime Tag Non Access Stratum Configuration
(EFNASCONFIG)
'8B' SM RetryAtRATChange Tag Non Access Stratum Configuration
(EFNASCONFIG)
'8C' Default_DCN_ID Tag Non Access Stratum Configuration
(EFNASCONFIG)
'8D' Exception Data Reporting Allowed Tag Non Access Stratum Configuration
(EFNASCONFIG)
'A0' MUK ID tag MBMS User Key (EFMUK)
The following tags are encapsulated within 'A0'
'80' MUk IDr tag
'82' MUk IDi tag
'A0' EPS NAS security Context tag EPS NAS Security Context (EFEPSPSC)
The following tags are encapsulated within 'A0'
3GPP
Release 15 302 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 303 3GPP TS 31.102 V15.21.0 (2018-0610)
'A0' CSG List TLV object tag Allowed CSG List (EFACSGL)
The following tags are encapsulated within 'A0'
'80' PLMN tag
'81' CSG Information tag
'A0' GSM cell information Network Parameters (EFNETPAR)
The following tags are encapsulated within 'A0':
'80' GSM Camping Frequency Information data object
'81' GSM Neighbour Frequency Information data object
'A0' Operator CSG List TLV object Tag Operator CSG Lists (EFOCSGL)
The following tags are encapsulated within 'A0'
'80' PLMN Tag
'81' CSG Information Tag
'82' CSG Display indicator tag
'A0' ProSe Discovery monitoring parameters ProSe Monitoring Parameters
The following tags are encapsulated within 'A0': (EFPROSE_MON)
'80' PLMN tag
'81' RFU
'82' Model tag
'A0' ProSe Discovery announcing parameters ProSe Announcing Parameters
The following tags are encapsulated within 'A0': (EFPROSE_ANN)
'80' PLMN tag
'81' Range tag
'82' Model tag
'A0' ProSe Policy parameters ProSe Policy Parameters
The following tags are encapsulated within 'A0': (EFPROSE_POLICY)
'80' ProSe Layer-2 Group ID tag
'81' ProSe UE ID tag
'82' ProSe Group IP multicast address tag
'83' Address type tag
'84' Ipv4 address as source tag
'85' Group related security tag
'86' Application Layer Group ID tag
'A0' ProSe PLMN Parameters tag ProSe PLMN Parameters (EFPROSE_PRMN)
The following tags are encapsulated within 'A0'
'80'PLMN tag
'81' Direct communication authorisation tag
'A0' ProSe Direct Communication parameters tag ProSe Direct Communication Radio
The following tags are encapsulated within 'A0' Parameters (EF PROSE_RADIO_COM)
'80' Geographical Area – Polygon tag
'81' Radio parameters tag
'A0' ProSe Radio parameters tag ProSe Direct Discovery Monitoring
The following tags are encapsulated within 'A0' Radio Parameters (EFPROSE_RADIO_MON)
'80' Geographical Area – Polygon tag
'81' Radio parameters tag
'A0' ProSe Radio parameters tag ProSe Direct Discovery Announcing
The following tags are encapsulated within 'A0' Radio Parameters (EFPROSE_RADIO_ANN)
'80' Geographical Area – Polygon tag
'81' Radio parameters tag
'A0' ACDC OS tag ACDC List (EFACDC_LIST)
'A0' ACDC App Id tag ACDC OS Configuration
The following tags are encapsulated within 'A0' (EFACDC_OS_CONFIG)
'80' ACDC category tag
'81' OS App Id tag
'A0' Group member discovery parameters tag ProSe Group Member Discovery
The following tags are encapsulated within 'A0' Parameters (EFPROSE_GM_DISCOVERY)
'80' User Info ID tag
'81' Discovery Group ID tag
'82' Application Layer Group ID tag
'A0' ProSe Relay Parameters tag ProSe Relay Parameters (EFPROSE_RELAY)
The following tags are encapsulated within 'A0'
'80' PLMN tag
'81' Relay type tag
'A0' Remote UE parameters tag ProSe Relay Discovery Parameters
The following tags are encapsulated within 'A0' (EFPROSE_RELAY_DISCOVERY)
'80' Relay Service Code tag
'81' User Info ID of Relay tag
'82' IP Versions tag
'83' Security content tag
3GPP
Release 15 304 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 305 3GPP TS 31.102 V15.21.0 (2018-0610)
NOTE: the value 'FF' is an invalid tag value. For ASN.1 tag assignment rules see ISO/IEC 8825-1 [35]
3GPP
Release 15 306 3GPP TS 31.102 V15.21.0 (2018-0610)
Annex E (informative):
Suggested contents of the EFs at pre-personalization
If EFs have an unassigned value, it may not be clear from the main text what this value should be. This annex suggests
values in these cases.
3GPP
Release 15 307 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 308 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 309 3GPP TS 31.102 V15.21.0 (2018-0610)
'6F06' Access rule reference (under ADFUSIM and Card issuer/operator dependent
DFTELECOM)
'6F07' IMSI Operator dependent
3GPP
Release 15 310 3GPP TS 31.102 V15.21.0 (2018-0610)
'6F73' Packet switched location information 'FFFFFFFF FFFFFF xxxxxx 0000 FF 01' (see
note 2)
'6F78' Access control class Operator dependent
3GPP
Release 15 311 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 312 3GPP TS 31.102 V15.21.0 (2018-0610)
NOTE 2: xxxxxx stands for any valid MCC and MNC, coded according to TS 24.008 [9].
3GPP
Release 15 313 3GPP TS 31.102 V15.21.0 (2018-0610)
Annex F (informative):
Examples of coding of LSA Descriptor files for SoLSA
The length of all the records is determined by the LSA descriptor containing the largest number of bytes. Combinations
containing different numbers of LSa IDs, LAC+ CI and CI or LAC can therefore be done. Various examples are show.
Due to the OTA management of the records it is recommended that the record length is maximum 100 bytes in order to
leave room for command descriptor and signature information in the SMS.
This first example contains two LSAs, one described by two LSa IDs and another described by three Cell IDs, giving a
record length of 8 bytes.
1st record: LSA descriptor LSA ID (3 bytes) LSA ID (3 bytes) Identifier (1 byte)
type = LSA ID
and number = 2
(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.
3GPP
Release 15 314 3GPP TS 31.102 V15.21.0 (2018-0610)
Annex G (informative):
Phonebook Example
This example phonebook has more than 254 entries. Additional number (3 additional numbers) information, second
name and e-mail information can be added to each ADN entry. In addition each entry has a 2 byte Unique ID (UID)
attached to it. The phonebook also contains three files that are shared EFEXT1, EFAAS and EFGAS. These files are addressed
from inside a file. EFEXT1 is addressed via EFADN, EFADN1, EFAAS is addressed via EFANRA, EFANRA1, EFANRB, EFANRB1,
EFANRC, EFANRC1 and EFGAS is addressed via EFGRP, EFGRP1. The phonebook supports two levels of grouping and hidden
entries in EFPBC.
Two records are needed in the phonebook reference file PBR '4F30' for supporting more than 254 entries. The content
of the phonebook reference file PBR '4F30' records is as shown in table G.2. The structure of the DF PHONEBOOK is shown
in table G.1.
The content of phonebook entries in the range from 1-508 is described in the tables G.3 and G.4.
DFPHONEBOOK
'5F3A'
Common Files
PhoneBook Set1
PhoneBook Set2
3GPP
Release 15 315 3GPP TS 31.102 V15.21.0 (2018-0610)
Tag'C0' L='03' '4F3A' '01' Tag'C5' L='03' '4F09' '02' Tag'C6' L='03' '4F26' '03'
Tag'C4' L='03' '4F11' '04' Tag'C4' L='03' '4F13' '05' Tag'C4' L='03' '4F15' '06'
Tag'C3' L='03' '4F19' '07' Tag'C9' L='03' '4F21' '12' Tag'CA' L='03' '4F50' '09'
Tag'AA' L='0F'
Tag'C2' L='03' '4F4A' '08' Tag'C7' L='03' '4F4B' '14' Tag'C8' L='03' '4F4C' '15'
Tag'C0' L='03' '4F3B' '0A' Tag'C5' L='03' '4F0A' '0B' Tag'C6' L='03' '4F25' '0C'
Tag'C4' L='03' '4F12' '0D Tag'C4' L='03' '4F14' '0E' Tag'C4' L='03' '4F16' '0F'
Tag'C3' L='03' '4F1A' '10' Tag'C9' L='03' '4F20' '13' Tag'CA' L='03' '4F51' '11'
Tag'AA' L='0F'
Tag'C2' L='03' '4F4A' '08' Tag'C7' L='03' '4F4B' '14' Tag'C8' L='03' ‘4F4C '15'
3GPP
Release 15 316 3GPP TS 31.102 V15.21.0 (2018-0610)
Table G.4: Structure of phone book entries 255 to 508 (Rec 1-254)
Phone ADN1 PBC1 GRP1 ANRA1 ANRB1 ANRC1 SNE1 UID1 EXT1 AAS GAS EMAIL1 PURI1
book '4F3B' '4F0A' '4F25' '4F12' '4F14' '4F16' '4F1A' '4F20' '4F4A' '4F4B' '4F4C' '4F51' '4F55'
entry SFI '0A' SFI '0B' SFI '0C' SFI '0D' SFI '0E' SFI '0F' SFI '10' SFI '13' SFI '08' SFI '14' SFI '15' SFI '11' SFI '17'
#255 ADN EXT1 Hidden Rec n°1 ANRA1 ANRB1 ANRC1 Second UID Rec '03' Record Record email SIP
Content Ident. (AID Rec n°3 Rec n°1 Rec n°1 Rec n°1 Name numbers no.'s as address URI/TE
Bytes (Byte Rec n° '00' Alpha as defined L URI
(1- X+14): 3) String defined in in
(X+13)) Rec '03' the ANRs GRP1
#256 ADN EXT1 Not Rec n°2 ANRA1 ANRB1 ANRC1 Second UID Rec '2B' Record Record email SIP
Content Ident. Hidden Rec n°1 Rec n°2 Rec n°2 Rec n°2 Name numbers no.'s as address URI/TE
Bytes (Byte Rec n°3 Alpha as defined L URI
(1- X+14): String defined in in
(X+13)) Rec '2B' the ANRs GRP1
#257
:
:
:
#508
3GPP
Release 15 317 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 318 3GPP TS 31.102 V15.21.0 (2018-0610)
Annex H (normative):
List of SFI Values
This annex lists SFI values assigned in the present document.
3GPP
Release 15 319 3GPP TS 31.102 V15.21.0 (2018-0610)
Other SFI values can be allocated to various EFACDC_OS_CONFIG: these are listed inside EFACDC_LIST.
3GPP
Release 15 320 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 321 3GPP TS 31.102 V15.21.0 (2018-0610)
Annex I (informative):
USIM Application Session Activation/Termination
The purpose of this annex is to illustrate the different Application Session procedures.
3GPP
Release 15 322 3GPP TS 31.102 V15.21.0 (2018-0610)
Annex J (informative):
Example of MMS coding
This annex gives an example for the coding of MMS User Preferences, while the MMS User Information Preference
parameters are coded according to the WAP implementation of MMS.
43 68 72 69 73 74 6D 61 73 20 43 61 72 64
0x81 0x88 (Length = "136") (Length bytes greater than 127 are coded onto 2 bytes according to ISO/IEC 8825-1 [35])
3GPP
Release 15 323 3GPP TS 31.102 V15.21.0 (2018-0610)
0x68 0x74 0x74 0x70 0x3A 0x2F 0x2F 0x6D 0x6D 0x73 0x2D 0x6F 0x70 0x65 0x72 0x61 0x74
0x6F 0x72 0x2E 0x63 0x6F 0x6D
(MMS Relay/Server information = "http://mms-operator.com"; 23 characters; 23 Bytes)
0x08 0x2B 0x34 0x39 0x35 0x33 0x34 0x31 0x39 0x30 0x36 0x00
(address = "+495341906", 12 Bytes)
0x0D 0x64 0x75 0x6D 0x6D 0x79 0x11 0x6E 0x61 0x6D 0x65 0x00
(authentication id = "dummy_name"; 12 Bytes)
0x0E 0x64 0x75 0x6D 0x6D 0x79 0x11 0x70 0x61 0x73 0x73 0x77 0x6F 0x72 0x64 0x00
(authentication pw = "dummy_password"; 16 Bytes)
0x20 0x31 0x37 0x30 0x2E 0x31 0x38 0x37 0x2E 0x35 0x31 0x2E 0x33 0x00
(address = "170.187.51.3"; 14 Bytes)
0x1A 0x64 0x75 0x6D 0x6D 0x79 0x11 0x6E 0x61 0x6D 0x65 0x00
(authentication id = "dummy_name"; 12 Bytes)
0x1B 0x64 0x75 0x6D 0x6D 0x79 0x11 0x70 0x61 0x73 0x73 0x77 0x6F 0x72 0x64 0x00
(authentication pw = "dummy_password"; 16 Bytes)
3GPP
Release 15 324 3GPP TS 31.102 V15.21.0 (2018-0610)
Annex K (informative):
Examples of VService_Id coding
This annex gives examples for the coding of VService_Id,
It is assumed that:
3GPP
Release 15 325 3GPP TS 31.102 V15.21.0 (2018-0610)
Annex L (normative):
USIM-INI and USIM-RN for Relay Nodes
L.1 Introduction
USIM-RN and USIM-INI are used for Relay Node network connections establishment.
USIM-INI, if present on the UICC, and USIM-RN include at least all mandatory files defined for a USIM in the present
document, with the exception of files related to emergency calls.
Editor’s note: It is FFS whether the list of files mandatory to support can be reduced further.
USIM-INI is only required in case of a certificate based solution as described in TS 33.401 [52].
For the certificate-based solution, the UICC shall support BIP-UICC server mode (see TS 31.111 [12]) and may support
the Inter-Chip USB UICC/terminal interface (see TS 31.101 [11]) to perform the TLS handshake.
The USIM-RN is used to ensure a one to one binding with the Relay Node. The security architecture for Relay Nodes is
defined in TS 33.401 [52].
When using pre-shared keys, only a USIM-RN is required, and the Relay Node will establish directly a secure channel
with USIM-RN. It is assumed that the Relay Node knows the "3G application code" within the PIX value reserved for
3GPP USIM-RN.
When using certificate based procedure, the UICC inserted in the Relay Node shall contains two USIMs, the USIM-RN
and USIM-INI. In case initial provisioning is required, the Relay Node will first select USIM-INI, either by direct
application selection or by use of the EF_DIR file.
1. Direct application selection: with full or with partial AID. It is assumed that the Relay Node knows the "3G
application code" within the PIX value reserved for 3GPP USIM-INI.
2. By use of the EF_DIR file: The Relay Node identifies the USIM-INI, which is characterised by an AID with a
"3G application code" within the PIX value reserved for 3GPP USIM-INI, see TS 31.101 [11], and selects the
USIM-INI by AID. The AID of the USIM-RN is characterised by an AID with a "3G application code" within
the PIX value reserved for 3GPP USIM-RN, see TS 31.101 [11]. If the only applications present in EF_DIR are
a USIM-RN and a USIM-INI, the terminal omits user presentation and proceeds to application selection.
The USIM applications USIM-INI and USIM-RN are not simultaneously active. USIM-INI is used to establish an
initial network connection and USIM-INI is deactivated once the network related operations are finished. USIM-INI is
deactivated prior to activating USIM-RN.
USIM-INI may be selected on any logical channel, see TS 31.101 [11]. Prior to selecting USIM-RN a new logical
channel shall be opened using the MANAGE CHANNEL command as specified in TS 31.101 [11], an application to
application secure channel can only be established on a logical channel different from channel 0. USIM-RN is then
selected on the new logical channel.
3GPP
Release 15 326 3GPP TS 31.102 V15.21.0 (2018-0610)
USIM-RN shall be configured to support implicit and explicit application selection. The Relay Node will first select
USIM-INI, according to the application selection mechanisms specified in TS 31.101 [11]. When the USIM-RN is
selected explicitly, the Relay Node shall send a SELECT by AID APDU command in clear text prior to secure channel
establishment. The implicit selection mechanism is performed by specifying USIM-RN AID in the MANAGE
SECURE CHANNEL – Establish Master SA command.
NOTE: The above implies in particular that the AUTHENTICATE command to the USIM-RN is not executed
outside the secure channel.In case the pre-shared key solution is used to establish the secure channel only the USIM-RN
is required for establishing the connection, and the Relay Node will establish directly a secure channel with the USIM-
RN before attaching to the network. The initial network connection using USIM-INI is not required in this case, and
hence USIM-INI is not required.
In case the certificate based solution is used, the UICC inserted in the Relay Node shall contain two USIMs, USIM-RN
and USIM-INI. A TLS handshake shall be used to provide key material for the Master SA for the secured APDU
protocol, according to ETSI TS 102 484 [66].
The Relay Node and the UICC shall support letter class 'e' toolkit commands for BIP, see TS 31.111 [12]. In order to
support toolkit the TERMINAL PROFILE, TERMINAL RESPONSE, ENVELOPE and FETCH commands need to be
supported. These commands are not issued on the secure channel. According to TS 31.111 [12], USAT commands shall
be sent on logical channel 0.
3GPP
Release 15 327 3GPP TS 31.102 V15.21.0 (2018-0610)
An USIM-RN shall contain this file. The content of this file is not intended to be read on UICC-RN interface. It serves
as a storage location for the Relay Node identifier to which the UICC is bound. The file content is described for the
purpose of Over-The-Air update.
3GPP
Release 15 328 3GPP TS 31.102 V15.21.0 (2018-0610)
An USIM with an Application ID in the USIM-RN range shall contain this file.
NOTE: The value of the Secure channel counter is set at personalisation. It is not intended to be updated or modified
as a result of establishing a new Connection SA.
3GPP
Release 15 329 3GPP TS 31.102 V15.21.0 (2018-0610)
Annex M (normative):
USIM application dedicated for IOPS
M.1 Introduction
IOPS allows to provide network service to Public Safety users even in the case the network has no or only limited
backhaul connectivity. One of the main issues in such cases is the missing backhaul to perform authentication. A
solution has been defined by using local HSSs which take over the responsibility for authentication in IOPS mode.
A problem identified for IOPS security when making use of local HSS is the higher probability of a compromise of a
local HSS. Therefore the security solution described in TS 33.401 uses a local HSS with different authentication
credentials than the standard HSS in normal operation. Additionally there might be several local HSSs and to further
reduce the impact of possible compromised local HSSs, each local HSS should use different authentication credentials.
The security solution described in 3GPP TS 33.401 [52] is based on a USIM application dedicated for IOPS and using
derived individual keys per local HSS.
3GPP TS 23.401 [69] Annex K specifies a PLMN identity dedicated for IOPS mode of operation. Additionally a USIM
dedicated for IOPS uses an Access Control Class of '11' or '15'.
- As specified in 3GPP TS 23.401 [69] Annex K, the Access Control Class in EFACC is set to either '11' or '15'. The
specific values for the Access Control Class prevent UEs with different Access Control Classes from trying to
attach to the IOPS network.
- The entry for the USIM dedicated for IOPS in EFDIR has a label starting with 'USIM-IOPS'.
In case multiple local HSSs are to be supported, The USIM should also support:
- The AMF (Authentication Management Field) mechanism as described in 3GPP TS 33.401 [52] Annex F.4.1 is
supported.
- An Operator specific mechanism to derive local HSS individual keys is supported (see 3GPP TS 33.401 [52]
Annex F.4).
NOTE: The mechanism to derive local HSS specific keys in the USIM dedicated for IOPS is specific to an
Operator and needs to be agreed for the local HSS and the USIM. One example mechanism is described
in 3GPP TS 33.401 [52] Annex F.4.2.
3GPP
Release 15 330 3GPP TS 31.102 V15.21.0 (2018-0610)
Annex N (informative):
Change history
The table below indicates all CRs that have been incorporated into the present document since it was initially approved.
3GPP
Release 15 331 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 332 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 333 3GPP TS 31.102 V15.21.0 (2018-0610)
CT-62 CP-130794 C6-130537 0567 B Fast higher priority PLMN search upon entering VPLMN 12.2.0
CT-63 CP-140161 C6-140077 0572 1 B Addition of POLL INTERVAL ENVELOPE command 12.3.0
CT-63 CP-140161 C6-140109 0571 4 B Presence detection due to active PDP context 12.3.0
CT-63 CP-140162 C6-140080 0569 1 B URI support for USIM Phonebook 12.3.0
CT-64 CP-140423 C6-140278 0568 3 B New UICC service in UST for URI support 12.4.0
CT-64 CP-140431 C6-140231 0581 F New UICC service in UST for URI support 12.4.0
CT-64 CP-140432 C6-140271 0573 1 F Addition of configuration parameter for EMM cause #15 12.4.0
extension
CT-64 CP-140441 C6-140280 0580 1 F Correction of length coding for EFPSEUDO 12.4.0
CT-65 CP-140699 C6-140472 0588 1 B Addition of DF for ProSe configuration 12.5.0
CT-65 CP-140699 C6-140477 0587 1 B Enablement of ProSe functionality for Public Safety 12.5.0
CT-65 CP-140699 C6-140482 0593 1 B Addition of EFs with monitoring and announcing information for 12.5.0
ProSe Direct Discovery
CT-65 CP-140699 C6-140491 0589 2 B Addition of a EF with IP address of the ProSe Function 12.5.0
CT-65 CP-140699 C6-140492 0590 2 B Addition of EF with radio parameters for public safety ProSe 12.5.0
direct communication in out of coverage scenario
CT-65 CP-140699 C6-140493 0591 2 B Addition of EF with policy parameters for public safety ProSe 12.5.0
direct services in out of coverage scenario
CT-65 CP-140699 C6-140494 0592 2 B Addition of EF with parameters for public safety ProSe direct 12.5.0
communication for PLMNs different from HPLMN
CT-65 CP-140700 C6-140495 0600 1 C Removal of USIM Service Table Service for Poll Interval 12.5.0
Negotiation
CT-65 CP-140701 C6-140504 0595 2 A 'Override NAS signalling low priority' and 'Override Extended 12.5.0
access barring' linkage
CT-65 CP-140703 C6-140505 0586 3 B Extension of URI support by USIM services 12.5.0
CT-65 CP-140708 C6-140502 0601 F Correction of change request implementation errors 12.5.0
CT-66 CP-140955 C6-140624 0602 D Removal of editor's notes for ProSe files 12.6.0
CT-66 CP-140955 C6-140710 0604 2 F Changes to ProSe Radio Parameters for Direct Communication 12.6.0
CT-66 CP-140955 C6-140711 0605 1 F Changes for ProSe Policy Parameters 12.6.0
CT-66 CP-140955 C6-140724 0603 2 F Removal of unnecessary items in ProSe parameters 12.6.0
CT-66 CP-140955 C6-140726 0611 3 B Addition of EF to store PTK ID and counter for ProSe direct 12.6.0
communication
CT-66 CP-140956 C6-140722 0609 1 C Extension of URI support by USIM BDN service 12.6.0
CT-66 CP-140956 C6-140723 0610 1 C Extension of URI support by USIM SDN service 12.6.0
CT-66 CP-140957 C6-140727 0597 6 B USAT Pairing whitelist file 12.6.0
CT-66 CP-140957 C6-140728 0598 6 B USAT Application Pairing: Pairing Status and IMEISV Files 12.6.0
CT-66 CP-140957 C6-140729 0596 3 B USAT Application Pairing for MTC device reference and 12.6.0
procedure
CT-67 CP-150154 C6-150077 0613 1 F Removal of circles geographical areas 12.7.0
CT-67 CP-150154 C6-150078 0614 1 C ProSe Service Table 12.7.0
CT-67 CP-150154 C6-150081 0616 1 B ProSe Direct Communication usage monitoring 12.7.0
CT-67 CP-150154 C6-150082 0615 1 B Addition of services for ProSe Direct Communication usage 12.7.0
information storage and reporting
CT-67 CP-150155 C6-150096 0617 3 B Addition of UE configuration parameters for SM Retry restriction 12.7.0
CT-67 CP-150156 C6-150100 0622 3 F Correction of Annex D list of tags 12.7.0
CT-67 CP-150180 0612 2 F Clarification of Direct Communication Radio Parameters 12.7.0
CT-68 CP-150382 C6-150203 0626 F Geographical Area in Direct Communication Radio Parameters 12.8.0
CT-68 CP-150383 C6-150205 0627 F Clarification of text for UE configuration parameters for SM Retry 12.8.0
restriction
CT-68 CP-150379 C6-150267 0635 1 A Correct file access conditions to activate/deactivate 12.8.0
CT-68 CP-150384 C6-150274 0625 1 F Correction for FDN and BDN usage in case of IMS 12.8.1
CT-68 CP-150381 C6-150290 0628 1 B URI support for SMS indicator in UST 13.0.0
CT-68 CP-150394 C6-150311 0629 2 B Support of Enhanced IMS Call Control by USIM 13.0.0
CT-69 CP-150563 C6-150423 0638 F Clarification to the applicability of the UE retry wait time value or 13.1.0
behaviour
CT-69 CP-150563 C6-150468 0639 1 C Replacement of EF LAUNCH SCWS with EF LAUNCH PAD 13.1.0
CT-69 CP-150563 C6-150464 0641 1 B UICC interface in Power Saving Mode (PSM) 13.1.0
CT-69 CP-150561 C6-150478 0648 A Alignment of EFs at the MF level with TS 31.101 13.1.0
CT-70 CP-150830 C6-150608 0659 A Alignment of the EFIPS record length 13.2.0
CT-70 CP-150829 C6-150618 0645 2 F Correction of EF NASconfig 13.2.0
CT-70 CP-150832 C6-150635 0637 4 B ePDG Configuration Information 13.2.0
CT-70 CP-150833 C6-150637 0651 1 B UICC interface during eDRX 13.2.0
CT-71 CP-160149 C6-160105 0688 1 B Addition of ACDC configuration parameters 13.3.0
CT-71 CP-160148 C6-160028 0666 F Update of ProSe ReportGroupParameters in EF-PROSE_UIRC 13.3.0
CT-71 CP-160148 C6-160029 0667 B Authorization for one-to-one direct communcation when not 13.3.0
served by E-UTRAN
CT-71 CP-160148 C6-160066 0664 1 B Addition of model for direct discovery for public safety. 13.3.0
CT-71 CP-160148 C6-160067 0665 1 B Addition of radio parameters for ProSe Direct Discovery 13.3.0
CT-71 CP-160148 C6-160068 0668 1 B Authorization for one-to-one direct communication 13.3.0
CT-71 CP-160148 C6-160069 0669 1 B Addition of Application Layer Group ID 13.3.0
CT-71 CP-160148 C6-160070 0675 1 B Addition of ProSe discovery parameters 13.3.0
CT-71 CP-160148 C6-160071 0676 1 B Addition of ProSe relay configuration 13.3.0
CT-71 CP-160147 C6-160103 0680 3 B USIM application dedicated for IOPS 13.3.0
3GPP
Release 15 334 3GPP TS 31.102 V15.21.0 (2018-0610)
3GPP
Release 15 335 3GPP TS 31.102 V15.21.0 (2018-0610)
CT6 CP-181155 C6-180275 0780 2 B Introduce an EF that contains 5G UAC Access Identity 15.1.0
Information
CT6 CP-181155 C6-180185 0781 - B Removing implementation of CR0768 15.1.0
CT6 CP-181155 C6-180285 0784 2 B 3GPP PS Data Off - update to services for roaming 15.1.0
CT6 CP-181155 C6-180291 0785 1 B Support of 5GS new steering of roaming procedures 15.1.0
CT6 CP-181155 C6-180261 0786 1 B USIM Service Table update for PDU session call control 15.1.0
support
CT6 CP-181158 C6-180237 0787 - F Clarification on interactions between eDRX cycle and on- 15.1.0
going BIP sessions
CT6 CP-181155 C6-180276 0788 - F Correction after implementation of a non accepted CR 15.1.0
after CT#75 plenary
CT6 CP-182185 C6-180371 0794 1 B Allow configuration of MCS (Access Identity 2) via USIM. 15.2.0
CT6 CP-182189 C6-180315 0795 - C Update EFHPPLMN description to clarify timer T 15.2.0
interpretation based on the RAT in use.
CT6 CP-182185 C6-180404 0797 3 B Modify structure of SUCI Calc EF and introduce Routing 15.2.0
Indicator
CT6 CP-182194 C6-180535 0798 3 C Remove the control plane based SoR related EF and use 15.2.0
only the EF-UST.
CT6 CP-182185 C6-180418 0799 1 C Corrections to the control plane based SoR related EF 15.2.0
CT6 CP-182185 C6-180419 0803 4 C Introduction of DF-5GS 15.2.0
CT6 CP-182185 C6-180393 0806 3 F Updates to USIM management procedures for 5GS 15.2.0
CT6 CP-182185 C6-180567 0809 2 F Clarification of GET IDENTITY 15.2.0
CT6 CP-182185 C6-180408 0810 1 F Correct Kseaf and Kausf length in EF5GAUTHKEYS to 15.2.0
align with SA3 specification
CT6 CP-182185 C6-180564 0814 2 F Correction of 5GS 3GPP Access NAS Security Context 15.2.0
CT6 CP-182185 C6-180553 0816 2 B Extend text in EF ACL clause to also include DNN 15.2.0
CT6 CP-182187 C6-180538 0808 2 B Mission Critical Services configuration data update to 15.2.0
USIM
3GPP