When looking at how a smartphone connects to a 5G network, attention usually goes to network elements such as the gNB, AMF, SMF, and UPF. The much smaller USIM is easy to overlook. In practice, however, the USIM also needs dedicated data structures to support functions ranging from 5G registration and mobility state storage to subscriber identity privacy, NAS security contexts, and access control.

With the introduction of 5G, the USIM file system was extended accordingly. This was not simply a matter of storing a few additional parameters in the existing SIM structure. New 5GS-specific directories, service indicators, and EF files were introduced within the USIM application so that the mobile equipment can determine which 5G capabilities are supported by the card, what data needs to be stored, and where the corresponding configuration should be read from.

Memorizing names such as EF5GS3GPPLOCI, EF5GAUTHKEYS, and EFSUCI_Calc_Info in isolation can quickly become confusing. A more practical approach is to group these files by the problems they address: mobility, security, subscriber identity privacy, access control, and operator information.

Why UICC and the File System Matter Before Looking at 5G USIM Files

SIM originated in the 2G era and can be understood as a subscriber identity module in which the hardware and application were closely integrated. The hardware component is the IC chip, while the software side includes the COS operating system, file system, and upper-layer applications or services.

With the introduction of 3G, the USIM (Universal Subscriber Identity Module) separated the application more clearly from the card platform on which it runs. The UICC is the underlying Universal Integrated Circuit Card platform, while the USIM operates as an application on that platform. In other words, what is commonly called a "USIM card" is, from a logical architecture perspective, more accurately described as a USIM application running on a UICC.

This distinction matters because 5G did not introduce a completely separate data system outside the USIM. Instead, 5G capabilities continue to use the existing USIM service and file management model.

A large amount of smart-card data is stored in file form. The logical structure mainly includes:

• MF (Master File): The top-level file in the card file system.

• DF (Dedicated File):A dedicated directory used to organize a particular application or group of data.

• EF (Elementary File): The basic files that actually store service data, status information, and configuration parameters.

For 5G, a dedicated DF5GS directory was added under the USIM application to organize 5GS-related EF files. The relevant USIM application specification defines nine 5G-related services and ten corresponding EF files for this group of capabilities.

What 5G Capabilities Are Added Under DF5GS?

The presence of an EF file alone does not automatically mean that a feature should be used. Another important file is EFUST (USIM Service Table).

EFUST indicates which services are supported by the USIM. The service table contains 131 services in total, while the 5G-related services discussed here are numbered 122 through 130. If a service is marked as unavailable, the ME will not select that service. The actual service configuration is defined by the operator.

This table is more useful than memorizing individual filenames because it shows the basic USIM design model: service capability indication plus the corresponding EF data.

For example, when service 122 is available, the USIM needs to provide the relevant files for 5GS mobility management. When service 123 is available, the 5G authentication key file is required. When service 129 is available, the USIM provides the 5GS operator PLMN list.

From an engineering perspective, EFUST answers the question, "What does this card support?" The individual EF files answer the next question, "What data does this capability require?" The ME uses both pieces of information to determine how the corresponding 5G function should be handled.

Why Are 5G Location and Security States Stored Separately for 3GPP and Non-3GPP Access?

One of the most straightforward groups of files under DF5GS is related to mobility management.

EF5GS3GPPLOCI stores 5GS location information for 3GPP access, including:

• 5G-GUTI;

• the last visited 5G-TAI;

• 5GS Update Status.

The corresponding EF5GSN3GPPLOCI stores the same type of information for non-3GPP access. The two files serve a similar purpose, but they apply to different access types.

This shows that the USIM does more than store a subscriber number in a 5GS mobility context. It also retains temporary identity information, recent location data, and update status that can be used during later procedures.

The same separation applies to NAS security contexts. EF5GS3GPPNSC stores the 5GS NAS Security Context for 3GPP access, while EF5GSN3GPPNSC stores the corresponding NAS security context for non-3GPP access.

Another dedicated security file is EF5GAUTHKEYS. When service 123 in EFUST is available, this file is required and stores 5G authentication-related keys, including KAUSF and KSEAF generated by the ME.

Looking at these files together reveals the design logic of the 5G USIM. The data is not simply grouped by protocol name. It is organized around the actual operating state of the UE: where it is registered, how it is accessing the network, which security context is currently valid, and which authentication information may be required later.

How Do SUCI, Access Control, and Operator Information Map to Specific EF Files?

In addition to mobility and security contexts, 5G introduces additional USIM-side data requirements for subscriber identity privacy and access control. SUCI-related capabilities are one of the clearest examples.

EFSUCI_Calc_Info stores the information required for SUCI calculation and protection. Whether this file is available to the ME depends on the combination of services 124 and 125 in EFUST.

If service 124 is available while service 125 is not available, SUCI calculation is performed by the ME. In this case, EFSUCI_Calc_Info must be present and available to the ME.

If both services 124 and 125 are available, SUCI calculation is performed by the USIM. In that case, EFSUCI_Calc_Info should not be available to the ME. If service 124 itself is not available, the file should likewise not be exposed to the ME.

Key data objects in the file include:

• Protection Scheme Identifier List: Contains protection scheme priorities and the Key Index.

• Home Network Public Key List: Contains the home-network public keys and related identifiers used for SUPI protection.

Another file used with SUCI is EFRouting_Indicator. It stores the Routing Indicator, which forms part of the SUCI and can be used for routing toward the home-network AUSF and UDM.

Beyond subscriber identity privacy, the USIM can also participate in Unified Access Control. EFUAC_AIC stores access-management configuration, including Access Identities associated with defined high-priority services. These values can be used together with the Access Category to support access control for specific services.

For operator display information, EFOPL5G stores associations between 5G-TAIs and PLMN Network Name Record Identifiers. When the UE registers with a PLMN, the ME can use these associations and then read the corresponding operator name information to display the service provider name or icon.

EFNSI, meanwhile, stores a SUPI of the Network Specific Identifier type. In this case, the SUPI uses the NAI format and should not be an IMSI.

What Role Does the USIM Really Play in a 5G Network?

If the USIM is viewed only as a subscriber identity card, it is difficult to explain why 5G requires so many additional services and EF files.

Taken together, these files show that the USIM provides a set of service-table-controlled storage functions for subscriber data, UE state, security information, and operator policy.

It stores much more than fixed identity information. The 5G-GUTI and last visited TAI represent mobility state. NAS Security Context and 5G authentication keys represent security state. SUCI-related files participate in subscriber identity privacy protection, while UAC, PLMN, and PDU Session Call Control show how operator policy can also influence UE behavior through the USIM.

Service 127 provides Control Plane-based Steering of UE in VPLMN and can be used in roaming-related PLMN selection. Service 128 provides Call Control on PDU Session by USIM. Before the relevant operation, the terminal can provide information such as the PDU session type, SSC mode, 5GSM capabilities, and serving cell information to the USIM, and then continue according to the instruction returned by the card.

This also has practical implications for troubleshooting. When investigating 5G terminal compatibility problems, registration failures, subscriber identity privacy issues, or specific access-control behavior, checking only the radio network and 5G Core may not be enough. Engineers may also need to verify whether the USIM correctly declares the corresponding service, whether the required EF exists, and whether the file contents match the operator configuration.

A practical troubleshooting sequence is: check EFUST first to confirm the supported capability, verify that the corresponding EF exists, and then inspect the EF contents. This is often more efficient than reading every 5G-related file individually.

For 5G device and core-network engineers, this is the real value of understanding the USIM file system. Many seemingly separate 5G functions ultimately come down to a very concrete question: before the UE performs a network procedure, what capability has the USIM declared, and what data has it stored for that function?

FAQ

What Is the Relationship Between DF5GS and ADFUSIM?

DF5GS is not a separate application outside the USIM. It is a dedicated directory within the USIM file structure used to organize 5GS-related data. ADFUSIM can be viewed as the main file space for the USIM application, while DF5GS provides a dedicated location for 5G-related EF files.

What Happens If EFUST Marks a 5G Service as Available but the Required EF File Is Missing?

For services where the specification requires the corresponding EF to be present when the service is available, this indicates an inconsistency between the service declaration and the card file configuration. Troubleshooting should first focus on USIM personalization data, EFUST configuration, and whether the required EF was created correctly rather than looking only at the network side.

Can a Smartphone Freely Modify 5G EF Files in the USIM?

Not necessarily. Different EF files have different access conditions. Reading or updating some files may require PIN authorization, while activation, deactivation, or certain configuration changes may require ADM privileges. Whether a file can be read, updated, activated, or deactivated therefore depends on the Access Conditions defined for that specific EF.

Why Do Some 5G Services Have an EFUST Service Number but No Dedicated EF File?

Not every USIM service requires a separate EF to store data. Some services are capability indicators, such as indicating that SUCI calculation is performed by the USIM, while others represent control behavior implemented by the USIM application itself. A service entry in EFUST therefore does not necessarily imply a one-to-one relationship with a dedicated EF file.