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 order to avoid unlinked data to introduce fragmentation of the files containing phone book data the following procedures shall be followed when creating a new entry in the phone book. The data related to
EFADN is first stored in the relevant record. As the record number is used as a pointer the reference pointer is now defined for the entry. The rule for storing additional information for an entry is that the reference pointer shall be created before the actual data is written to the location.
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
EFADN is the last to be deleted.
If a phone book entry is marked as hidden by means of
EFPBC the ME first prompts the user to enter the 'Hidden Key'. The key presented by the user is compared against the value that is stored in the corresponding
EFHiddenkey. Only if the presented and stored hidden key are identical the ME displays the data stored in this phone book entry. Otherwise the content of this phone book entry is not displayed by the ME.
Even if the terminal does not support the Hidden Key Procedures, a hidden phone book entry shall not be displayed by the terminal.
Request:
The ME performs the reading procedure with
EFHiddenkey.
Update:
The ME performs the updating procedure with
EFHiddenkey.
Requirements:
-
Service No. 1 "available" for ADN located under the local phonebook;
-
Presence of EFADN in EFPBR for ADN located under the global phonebook;
-
Presence of EFANR in EFPBR for ANR;
-
Service No. 2 "available" for FDN;
-
Service No. 21 "available" for MSISDN;
-
Service No. 4 "available" for SDN;
-
Service No. 6 "available" for BDN;
-
Service No. 8 "available" for EFOCI;
-
Service No. 9 "available" for EFICI.
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.
As an example, the following procedures are described as applied to ADN.
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):
-
The ME identifies the Alpha-tagging, Capability/Configuration1 Record Identifier and Extension1 Record Identifier.
-
The dialling number/SSC string shall be analysed and allocated to the bytes of the EF as follows:
-
if a "+" is found, the TON identifier is set to "International";
-
if 20 or less "digits" remain, they shall form the dialling number/SSC string;
-
if more than 20 "digits" remain, the procedure shall be as follows:
-
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.
-
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 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 for coding):
-
The ME seeks for two free records in EFEXT1. If no such two records are found, the ME runs the Purge procedure. If two Extension1 records are still unavailable, the procedure is aborted.
-
The ME stores the called party subaddress in the two Extension1 records. The identifier field in the Extension1 record containing the first part of the subaddress data is coded with the associated EFEXT1 record number containing the second part of the subaddress data. Both Extension1 record types are set to "called party subaddress".
Once i), ii), and iii) have been considered the ME performs the updating procedure with
EFADN. If the 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.
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
No. 2 (FDN).
-
FDN capability request. The ME shall check the state of service No. 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. 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 No. 2 is disabled.
-
FDN enabling is done by activating the FDN service in EFEST.
-
FDN disabling is done by deactivating the FDN service in EFEST.
The following three procedures are only applicable to service
No. 6 (BDN).
-
BDN capability request. The ME shall check the state of service No. 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".
-
BDN enabling is done by activating the BDN service in EFEST.
-
BDN disabling is done by deactivating the BDN service in EFEST.
Requirement:
The USIM seeks for the identified short message. If this message is found, the ME performs the reading procedure with
EFSMS.
If service
No. 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.
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.
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
No. 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.
Requirement:
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.
Accumulated Call Meter Maximum Value.
Request:
The ME performs the reading procedure with
EFACMmax.
Initialisation:
The ME performs the updating procedure with
EFACMmax using the new initial maximum value.
Price per Unit and Currency Table (PUCT).
Request:
The ME performs the reading procedure with
EFPUCT.
Update:
The ME performs the updating procedure with
EFPUCT.
Requirement:
Request:
The ME performs the reading procedure with
EFCCP2.
Update:
The ME performs the updating procedure with
EFCCP2.
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".
Requirement:
Request:
The ME performs the reading procedure with
EFPLMNwAcT.
Update:
The ME performs the updating procedure with
EFPLMNwAcT.
Requirement:
Request:
The ME performs the reading procedure with
EFCBMI.
Update:
The ME performs the updating procedure with
EFCBMI.
Requirement:
Request:
The ME performs the reading procedure with
EFGID1.
Requirement:
Request:
The ME performs the reading procedure with
EFGID2.
Requirement:
Request:
The ME performs the reading procedure with
EFSPN.
Requirement:
Request:
The ME performs the reading procedure with
EFeMLPP.
Requirement:
Request:
The ME performs the reading procedure with
EFCBMIR.
Update:
The ME performs the updating procedure with
EFCBMIR.
Requirement:
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
EFSMSR for the same record number it used for the short message in
EFSMS. If such a record identifier is found in
EFSMSR, it is used for storage. If such a record identifier is not found, then the ME seeks for a free entry in
EFSMSR for storage. If no free entry is found the ME runs the Purge procedure with
EFSMSR. If there is still no free entry, the status report is not stored.
If the ME found an appropriate record in
EFSMSR for storage, it updates the record with the status report setting the record identifier in
EFSMSR to the appropriate record number of the short message in
EFSMS.
The status in
EFSMS is updated accordingly 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.
Requirement:
Request:
The ME performs the reading procedure with
EFACL.
Update:
The ME performs the updating procedure with
EFACL.
Enabling:
The ME activates service
No. 3 in
EFEST (bit 3 set to
"1").
Disabling:
The ME deactivates service
No. 3 in
EFEST (bit 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
EFACL, 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.
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.
Requirement:
Request:
The ME performs the reading procedure with
EFDCK.
Requirement:
Request:
The ME performs the reading procedure with
EFCNL.
Requirement:
Request:
The ME performs the reading procedure with
EFCPBCCH.
Update:
The ME performs the updating procedure with
EFCPBCCH.
Requirement:
Request:
The ME performs the reading procedure with
EFInvScan.
Requirement:
Request:
The ME performs the reading procedure with
EFEST.
Update:
The ME performs the updating procedure with
EFEST.
Requirement:
Request:
The ME performs the reading procedure with
EFAAeM.
Update:
The ME performs the updating procedure with
EFAAeM.
Request:
The ME performs the reading procedure with
EFNETPAR.
Update:
The ME performs the updating procedure with
EFNETPAR.
Requirement:
Request:
The ME performs the reading procedure with
EFPNN.
Requirement:
Request:
The ME performs the reading procedure with
EFOPL
Requirement:
Request:
The ME performs the reading procedure with
EFMWIS.
Update:
The ME performs the updating procedure with
EFMWIS.
Requirement:
Request:
The ME performs the reading procedure with
EFCFIS.
Update:
The ME performs the updating procedure with
EFCFIS.
Requirement:
Request:
The ME performs the reading procedure with
EFSPDI.
Update:
The ME performs the updating procedure with
EFSPDI.
Requirement:
Request:
The ME sends the identification of the information to be read, then the ME performs the reading procedure with
EFMMSN. If Service
No. 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:
-
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 EFMMSN. 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.
The ME is only allowed to store extension data in unused records of
EFEXT8
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
No. 53 is available all associated records in
EFEXT8 are then marked by the ME as
"free" by setting them to
'FF'.
Requirement:
Request:
the ME performs the reading procedure with
EFMMSICP.
Update:
The ME performs the updating procedure with
EFMMSICP.
Requirement:
Request:
the ME performs the reading procedure with
EFMMSUP.
Update:
The ME performs the updating procedure with
EFMMSUP.
Requirement:
Request:
the ME performs the reading procedure with
EFMMSUCP.
Update:
The ME performs the updating procedure with
EFMMSUCP.
Requirement:
Request:
The ME performs the reading procedure with
EFNIA.
If the terminal supports Multimedia Message Storage on the USIM, then the following procedures apply.
As defined in
TS 23.140 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
EFMML where each data object identifies one Multimedia Message stored in
EFMMDF.
Prerequisite:
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
EFMMDF 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.
Requirement:
Request:
The ME performs the reading procedure with
EFEHPLMNPI.
Requirement:
Request:
The ME performs the reading procedure with
EFNAFKCA.
Requirement:
Request:
The ME performs the reading procedure with
EFSPN and
EFSPNI.
Requirement:
Request:
The ME performs the reading procedure with
EFPNN and
EFPNNI.
The ICE information shall be accessible even when the security features of the UE or UICC have been enabled. The ICE access procedure is described in
TS 22.030. The terminal shall discover that the ICE feature is supported by the ability to select one of the ICE files i.e.
EFICE_DN,
EFICE_FF or
EFICE_graphics.
Request:
Update:
Disable ICE display:
Enable ICE display:
The content of the
EFICE_DN,
EFICE_FF and
EFICE_graphics shall be preserved when enabling and disabling the ICE display.
The eCall feature on the USIM provides two numbers or URIs, a test number or URI and a reconfiguration number or URI, to the terminal to be used with the eCall. eCall support on the USIM is indicated in the service table when Service
No. 89 or Service
No. 112 is
"available".
Depending on the type of eCall support and the domain,
EFFDN or
EFSDN or
EFFDNURI or
EFSDNURI is used to provide the eCall functionality.
Requirement:
Request:
the ME performs the reading procedure with
EFPSISMSC.
Update:
The ME performs the updating procedure with
EFPSISMSC.
Requirement:
Service
No. 95 is
"available" and the ISIM application defined in
TS 31.103 is not present on the UICC.
Request:
The terminal performs the reading procedure with
EFUICCIARI.
The procedures and command for
"UICC access to IMS" are defined in
TS 31.111. An ME supporting UICC access to IMS shall perform the reading procedure with
EFUICCIARI prior to sending a registration to the IMS.
Requirement:
Request:
The ME performs the reading procedure with
EFTVCONFIG.
Requirement:
service
No. 117 is
"available" in the USIM Service Table.
Request:
If the ME supports 3GPP PS Data Off the ME shall perform the reading procedure with
EF3GPPPSDataOff.
Requirement:
service
No. 118 is
"available" in the USIM Service Table.
Request:
Requirement:
"SUCI calculation is to be performed by the ME" (i.e. Service
No. 124 is
"available"and Service
No. 125 is not
"available").
Request:
As part of the SUCI calculation performed by the ME, the ME performs the reading procedure with
EFSUCI_Calc_Info.
Requirement:
"SUCI calculation is performed by the USIM" (i.e. Service
No. 124 and Service
No. 125 are
"available").
Request:
The ME uses the GET IDENTITY command in SUCI context to retrieve the SUCI calculated by the USIM.
Following procedures apply for 5G NSWO authentication as per
clause 6.3a of TS 24.502.
-
If "5G NSWO support" is activated (i.e. Service No. 142 is "available"), the ME shall use the GET IDENTITY command in the SUCI 5G NSWO context to retrieve the SUCI calculated by the USIM.
-
if USIM service 142 is not available and if the SUPI type is IMSI, the ME shall use the GET IDENTITY command in the SUCI context to retrieve the SUCI calculated by the USIM and contruct the SUCI in the NAI format as below.
-
The ME shall construct the realm part of the SUCI using the Home Network Identifier in the SUCI retrieved from the USIM as specified in TS 23.003.
-
The ME shall construct the username part of the SUCI using the complete SUCI excluding the Home Network Identifier received from the USIM.
If service
No. 127 is
"available" in the USIM Service Table, the Registration Accept shall contain control plane based Steering of Roaming information during the initial registration procedure in a VPLMN.
The control plane-based Steering of Roaming procedure and the related information from the HPLMN are specified in
TS 23.122.
Requirement:
Request:
The ME performs the reading procedure with
EFOPL5G.
Requirement:
Request:
As part of the SUCI calculation performed by the ME, the ME performs the reading procedure with
EFRouting_Indicator.
Requirement:
Request:
The ME performs the reading procedure with
EF5GSEDRX.
Requirement:
Request:
If Non-seamless WLAN offload (NSWO) is supported by the ME, it shall perform the reading procedure with
EF5GNSWO_CONF and it shall follow the authentication procedure in 5G NSWO as defined in
TS 33.501 Annex S.