The following clauses describe the impact of the 5G system on the existing AUTHENTICATE command, as defined in TS 31.102.

Clause 6.1.1.3 of TS 33.501 describes the binding of the anchor key KSEAF to the serving network, to prevent one serving network from claiming to be a different serving network, and indicates that the anchor key provided to the serving network shall be specific to the authentication having taken place between the UE and a 5G core network. As per clause 6.1.1.1 of TS 33.501, there is also another key KAUSF, that is left on the AUSF based on the home operator's policy on using such key for authentication and key agreement procedures. As per clause 6.2.2.2 of TS 33.501, the ME shall generate the KAUSF from the CK, IK received from the USIM. The ME shall then generate the KSEAF from KAUSF. The ME shall then generate the KAMF. If the USIM supports 5G parameters storage, the KAUSF, KSEAF and KAMF shall be stored in the USIM. New EF(s) need to be defined in the USIM for the storage of the keys listed above. A bit also needs to be reserved in the USIM Service Table to indicate the support for 5G parameters storage. The USIM shall store the same long-term key K that is stored in the ARPF.

No new input parameters are needed for AUTHENTICATE command as the AKA procedures leverage authentication procedure as in 3G Security Context procedure. RES* calculation as part of 5G-AKA procedure is not performed on the USIM. SA3 has clarified with S3-180796 that RES* is computed in the ME.

No new output parameters are needed for AUTHENTICATE as the AKA procedures leverage authentication procedure as in 3G Security Context procedure. RES* calculation as part of 5G-AKA procedure is not performed on the USIM. SA3 has clarified with S3-180796 that RES* is computed in the ME.

As per TS 33.501 clause 6.3.4.1, the ME shall store two different 5G security contexts on the USIM if the USIM supports the 5G parameters storage. In order to implement this requirement, a new bit in the USIM Service Table and an EF for storing 5G NAS security context may be needed in the USIM.

The following clauses describe the impact of 5G system on existing EFs stored in the USIM application.

According to clause 5.2.2 of TR 24.890, the UE maintains a list of "forbidden areas" where the UE shall not send any signalling or user data. Anyway, according to the current text, this list is deleted when the UE is switched off or the USIM is removed. In order to properly implement the last requirement, such list cannot be stored in the USIM, and in general, there would not be any advantage in storing it inside the USIM application.

According to clause 13.2 of TR 24.890, a network slice is identified by an S-NSSAI, which is comprised of a slice/service type (SST) and an optional slice differentiator (SD). A set of S-NSSAI is called NSSAI and there are multiple types of NSSAI, that may be provided by the HPLMN to the UE per PLMN. Clause 13.2.2 further clarifies the details for the storage of the NSSAI, indicating that the configured NSSAI(s) and/or allowed NSSAI(s) shall be stored in a non-volatile memory in the ME together with the SUPI from the USIM per PLMN, and that the configured NSSAI(s) and/or allowed NSSAI(s) can only be used if the SUPI from the USIM matches the SUPI stored in the non-volatile memory of the ME; else the UE shall delete them.

TS 22.153 specifies the service requirements for Multimedia Priority Service (MPS). MPS allows certain subscribers priority access to system resources in situations such as during congestion, creating the ability to deliver or complete sessions of a high priority nature. According to clause 12.1.5.2 of TS 24.890, an MPS-subscribed UE is configured with at least one access class in the range 11-15 on the USIM. Since Access Control Classes 11-15 are already defined in TS 31.102, no new requirement is present for USIM for Multimedia Priority Services.

According to clause 5.9.1 of TS 23.501, each subscriber in the 5G system shall be allocated one 5G Subscription Permanent Identifier (SUPI). As per clause 5.3.2 of TS 24.501, the SUPI can be the IMSI or a Network Access Identifier (NAI). Though non-IMSI based SUPIs are possible by using NAI, the IMSI can be contained within the NAI for the SUPI. A new USIM service table bit may be needed to indicate if the USIM supports SUPI types other than IMSI. If the USIM supports SUPI types other than IMSI, CT6 needs to create a new EF for that. According to TR 33.899 [6] clause E.7.2.1.2, SA3 agreed that privacy for the 5G permanent subscription identifier is part of 5G system Phase 1. Furthermore, SA3 also agreed that subscription identifier privacy shall be based upon HN asymmetric key solution, as indicated in TR 33.899 [6] clause E.7.2.6.2. SA3 has also agreed in TS 33.501 clause 5.1.5 that the home network public key shall be stored on the tamper resistant secure hardware component. Anyway, SA3 has not concluded in which entities (e.g. ME, USIM) the calculation of SUCI is done. CT6 needs to expand the USIM capabilities depending on the SA3 decision about the calculation of SUCI:

• if the calculation is done on the USIMUICC, then a new mechanism to calculate the SUCI is required, either extending one of the existing commands or with the introduction of a new command. Moreover, CT6 may decide to create a new EF that is not accessible by the ME to store the home network public key, in order to allow a standardized way to manage it;
• if the calculation is performed in the ME, then CT6 needs to add a new EF for the storage of the home network public key.

In all previous access technologies, the temporary identities, in the form of TMSI, P-TMSI or GUTI, was stored in the USIM. Clause 5.9.4 of TS 23.501 defines a new 5G-GUTI, that is allocated by the AMF and is common to both 3GPP and non-3GPP access. As mentioned in TS 24.501 Annex C, 5G-GUTI shall be stored in the USIM, if the corresponding file is present on the USIM. So, a new USIM service table bit needs to be introduced for 5G mobility management parameters. A new EF also needs to be introduced to store the 5G mobility management parameters, including 5G-GUTI.

TS 31.111 lists all possible access technologies communicated to the UICC in clause 8.62, which points to a clause of ETSI TS 102 223 [12]. The introduction of 5G system requires the addition of a new item in that list. Such addition needs to be done using one of the bits reserved by ETSI SCP for 3GPP for the definition of new access technologies.

The TLV containing the Location Information is defined in clause 8.19 of TS 31.111. This is used in several USAT messages sent from the ME to the UICC. The content of this object is populated by the terminal with the identification (MCC, MNC, LAC/TAC, Cell Identity) of the current serving cell of the UE, when the UE is on GERAN, UTRAN or E-UTRAN. The existing text defines the coding of the TAC and the Cell Identity with reference to E-UTRAN specifications, and a new definition of the coding for 5G System is required. The cell identity for NR is specified as 36 bits long in clause 9.3.1.7 of TS 38.413. This change would require an extension of the Location Information data object in TS 31.111, that is currently defined with only 32 bits for the Cell Identity value.

According to TS 31.111, the UICC can retrieve the Timing Advance (TA) information from the terminal. This information can be used by the UICC for a rough estimate of the location of the user. This mechanism is currently defined for GERAN and E-UTRAN. As per TS 38.321, the Timing Advance feature is applicable to NR as well. As per frame structure in clause 4.3 of TS 38.211, the definitions of Random Access Response TA and MAC-CE TA in clause 4.2 of TS 38.213 and the TA offset values defined in TS 38.133, the maximum value of Timing Advance (NTA) may be derived. That derived value will require 21 bits for NTA. clause 8.46 of TS 31.111 currently reserves 1 byte for Timing Advance. That needs to be expanded to 3 bytes to accommodate maximum Timing Advance value in 5GS.

According to TS 31.111, the UICC can request the Network Measurament Results (NMR) from the terminal. The UICC can request both intra-RAT and inter-RAT measuraments, that might be available for the terminal. The type of measurament requested by the UICC is specified in clause 8.73 of TS 31.111 that lists all possible requests. This list needs to be expanded to include new possible inter-RAT and intra-RAT measurament requests due to the new 5G RAT. The results of the requested measurament is returned by the terminal to the UICC using the Network Measurement Results object, defined in clause 8.22. The definition of this object needs to be expanded to include the new network measurement results related to 5G RAT.

According to clause 7.5.2.1 of TS 31.111, the ME informs the UICC about a network reject event when it receives an ATTACH REJECT message or TRACKING AREA UPDATE REJECT message in E-UTRAN and if the UICC has requested this information using the SET UP EVENT LIST proactive command. The event contains several items that can potentially be impacted by the 5G System:

• the Tracking Area indentification of the rejecting network (see also clause 8.2.2 above)
• the Access technology (see clause 8.2.1 above)
• the (Extended) Rejection Cause Code with the EMM Cause
• Update/Attach Type indicating the specific message that was rejected by the network

According to TS 31.111, the UICC can provide a Bearer description object, as specified in clause 8.52 of TS 31.111, when it opens a BIP channel using OPEN CHANNEL, in order to request a specific QoS. In case of E-UTRAN, this object includes the "EPS quality of service" information element and the resource type (GBR or non-GBR). The need for the QoS parameter in OPEN CHANNEL for BIP in 5GS is to be further evaluated in CT6, taking into consideration the adoption of the feature on the existing Radio Access Technologies.

When the UICC supports it, the ME passes the PDN Connectivity Request message to the UICC for all EPS PDN connection activations (including those resulting from a OPEN CHANNEL proactive UICC command) using the ENVELOPE (CALL CONTROL) command. The UICC can modify some of the fields in the message (Access Point Name and Protocol configuration options) before the terminal sends the request to the network, as specified in clause 7.3.1.6 of TS 31.111. The payload of the ENVELOPE (CALL CONTROL) needs to be expanded for the 5G System with a new data object called PDU connection establishment parameters. This new data object needs to be defined based on the PDU CONNECTION ESTABLISHMENT REQUEST message, defined in clause 9.6 of TS 24.890. A new sub-clause 7.3.1.x needs to be added in TS 31.111 with the procedure for call control for PDU connection establishment. The need for a new bit in the USIM service table in TS 31.102 for "call control on PDU connection for 5GS by USIM" is to be evaluated.

When the UICC has registered for the event, the ME notifies the UICC after each change in the data connection status, using the ENVELOPE (EVENT DOWNLOAD - Data Connection Status Change) command. The description of the Data connection status object in clause 8.137 of TS 31.111 and the Data connection type object in clause 8.138 of TS 31.111 needs to be expanded to include the 5GS PDU connection establishment procedure. The (E)SM cause data object in clause 8.129 of TS 31.111 needs to be expanded to include the 5GSM cause values as mentioned in clause 9.7.6 of TS 24.890. Annex T of TS 31.111 also needs to be updated to include PDU connection establishment scenarios related to 5GS as detailed in TS 24.890.

When the UICC sends the LAUNCH BROWSER proactive command, it can optionally include a Bearer object. This is specified in clause 8.49 of TS 31.111. The value '03' indicates GPRS/UTRAN packet service/E-UTRAN. It is recommended to add 5G system to the existing value '03' without further expanding the list.