The present document discusses and describes the CT6 aspects of the 5G System phase 1. One objective of the document is to describe the impact of decisions taken in other 3GPP groups on the existing specifications maintained by CT6.
The present document is intended as a placeholder for CT6 material until it stabilises sufficiently to be moved to appropriate 3GPP technical specifications.
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 specific reference, subsequent revisions do not apply.
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.
For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.
For the purposes of the present document, the abbreviations given in TR 21.905, in TS 31.102 and the following apply.
An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.
The UICC platform defined by ETSI SCP in TS 102 221  was adopted by 3GPP in TS 31.101 and has been used to host the 3GPP applications, including the USIM and the ISIM, for many years, starting from Rel.99.
It is evident that the platform could be improved in many aspects, as described in the TR 31.801. Anyway, it remains a valid and appropriate solution to host the 3GPP applications also in a UE capable of registering on a 5G system.
The continued usage of the UICC platform helps avoiding issues for users when upgrading their device to a 5G capable one.
In the latest available version of TS 33.899 , SA3 has approved a requirement for the storage and processing of the subscription credentials in a 5G system, adding more flexibility in addition to the existing UICC platform, already in use within the 3GPP eco-system. This is reflected in the interim agreement described in clause E.126.96.36.199, indicating that solutions for the credential storage and processing in Phase 1 shall be the UICC and the new SSP (Smart Secure Platform) under discussion in ETSI SCP.
TS 33.501, clause 188.8.131.52 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 TS 33.501, clause 184.108.40.206, 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 TS 33.501, clause 220.127.116.11, 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 18.104.22.168, 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.
According to TR 24.890, clause 5.2.2, the same procedures for PLMN selection applicable for the GSM, UTRAN and E-UTRAN access technologies as described in TS 22.011 and TS 23.122 also apply for 5G-RAN, with only few exceptions.
According to the text in TS 31.102, clause 4.2.6, the EFHPPLMN contains the interval of time between searches for a higher priority PLMN. The coding of this EF varies depending on the device that reads it. In particular for those MEs that only support NB-IoT, GERAN EC-GSM-IoT and Category M1 of E-UTRAN enhanced-MTC, or a combination of those, the values calculated from the EFHPPLMN are much longer.
Based on existing text in TR 24.890, no changes are anticipated due to the introduction of 5G.
According to the text in TS 31.102, clause 4.2.5, the EFPLMNwAcT contains the list of PLMNs and access technologies controlled by the user to be used during PLMN selection procedure. This access technology of each PLMN is coded as a bitmask.
5G system needs to be added to the coding of the access technology, using one of the exising RFU bits. Based on the response from SA1 in S1-173550, the UE does not need to differentiate between NR connected to 5GC and E-UTRA connected to 5GC. The UE however does need to differentiate between E-UTRA connected to 5GC and E-UTRA connected to EPC. Hence, the existing E-UTRAN bits in TS 31.102, clause 4.2.5 correspond to E-UTRAN over EPC. A new coding is required for EUTRAN/NR over 5GC.
The file EF OPLMNwACT specified in TS 31.102, clause 4.2.53 is coded in the same way as the EF PLMNwAcT described in clause 22.214.171.124 of this document. For this reason, the same conclusions and coding apply to this EF as well.
The file EF HPLMNwACT specified in TS 31.102, clause 4.2.54 is coded in the same way as the EF PLMNwAcT described in clause 126.96.36.199 of this document. For this reason, the same conclusions and coding apply to this EF as well.
According to TR 24.890, clause 5.2.2, 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 TR 24.890, clause 13.2, 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.
Section 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 TS 24.890, clause 188.8.131.52, 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 TS 23.501, clause 5.9.1, each subscriber in the 5G system shall be allocated one 5G Subscription Permanent Identifier (SUPI). As per TS 24.501, clause 5.3.2, 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  clause E.184.108.40.206, 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  clause E.220.127.116.11. 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. TS 23.501, clause 5.9.4 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.
According to TS 24.890, clause 12.1.1, 5G PWS will have the same functionality as E-UTRAN PWS for 4G. It is expected that the same technology framework is used for the realization of PWS in 5GS and for this reason no additional impact is expected on the USIM.
TS 31.102, clause 5.3.40 describes the usage of EFFDN, EFFDNURI, EFSDN and EFSDNURI to store the eCall test number/URI and the eCall reconfiguration number/URI to be used in case of eCall over IMS Emergency Services using the PS domain in E-UTRAN.
Based on the text in TS 23.501, clause 18.104.22.168, eCall over IMS Emergency Services needs to be supported also on 5GS.
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 . 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 TS 31.111, clause 8.19. 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 TS 38.413, clause 22.214.171.124. 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 TS 38.211, clause 4.3, the definitions of Random Access Response TA and MAC-CE TA in TS 38.213, clause 4.2 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. TS 31.111, clause 8.46 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 TS 31.111, clause 8.73 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 TS 31.111, clause 126.96.36.199, 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)
According to TS 31.111, the UICC can provide a Bearer description object, as specified in TS 31.111, clause 8.52, 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 TS 31.111, clause 188.8.131.52.
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 TS 24.890, clause 9.6.
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 TS 31.111, clause 8.137 and the Data connection type object in TS 31.111, clause 8.138 needs to be expanded to include the 5GS PDU connection establishment procedure.
The (E)SM cause data object in TS 31.111, clause 8.129 needs to be expanded to include the 5GSM cause values as mentioned in TS 24.890, clause 9.7.6.
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 TS 31.111, clause 8.49. 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.
It is expected that the UE might be able to access the 5G system with the existing UICC cards already in the market. For this reason, it is possible that the UE camps on a 5G system, while the card is not capable of recognizing it.
In order to handle this scenario, a new bit in the USIM Service Table is required to indicate support of 5G System, so that terminal can adjust its behaviour to what the UICC supports. Similarly, a new bit in the TERMINAL PROFILE is required, so that the ME can inform the card of the 5G support.
In order to provide a smooth transition, CT6 needs to study which fields defined in TS 31.111 are impacted by the transition and if there is a possibility of conversion of 5G specific values into corresponding values that are already defined and that can be interpreted by an existing card. Such study needs to be performed on each of the fields listed in clause 8.2 and appropriate text needs to be added in TS 31.111 as needed.