Enhanced UE parameter update (UPU) procedure

Abstract

Systems, methods, and software to perform UE parameter updates (UPUs) of a user equipment. In one embodiment, a user equipment receives a first UPU container from a network, the first UPU container including UPU data for UE parameter updates and a first message authentication code protecting the UPU data, and performs verification of the first message authentication code. The user equipment generates a UPU acknowledgement indicating whether the verification is successful, derives a second message authentication code based on the UPU acknowledgement, and sends a second message to the network, the second message including a second UPU container including the second message authentication code, and an indicator indicating whether the user equipment supports UPU header protection.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the field of communication systems, and in particular to next generation networks. BACKGROUND

[0002] Next generation networks, such as the fifth generation (5G), represent the next major stage of mobile communication standards beyond the fourth generation (4G) standards. Next generation networks can be enhanced in terms of radio access and network architecture compared to 4G networks. Next generation networks intend to exploit new regions of the radio spectrum for the radio access network (RAN), such as the millimeter wave band.

[0003] As mobile networks are widely used across countries and around the world, communications can be intercepted or suffer from other types of attacks. To ensure security and privacy, the Third Generation Partnership Project (3GPP) has developed security mechanisms for 5G mobile networks, as well as security procedures performed within 5G mobile networks. One of the security procedures between a user equipment (UE) and a 5G mobile network is the primary authentication and key agreement. The primary authentication and key agreement procedure enables mutual authentication between the UE and the network, and provides key material that can be used between the UE and the serving network in subsequent security procedures.

[0004] After primary authentication, the 5G mobile network can update the configuration parameters of the UE at any time using a UE parameter update (UPU) procedure. However, some protection mechanisms for the UE parameter update procedure can be inefficient or not fully defined, and improvements can be needed to be identified. SUMMARY

[0005] An enhanced UE parameter update (UPU) procedure is described herein. More specifically, the protection mechanism or scheme for the UE parameter update procedure uses a message authentication code (MAC) to verify or authenticate the update at the UE. However, in the current UE parameter update procedure, there is confusion in the use of the UPU header when deriving the MAC, also referred to as UPU-MAC-I in 3GPP Technical Specification (TS). AUSF In the UE parameter update procedure, an authentication server function (AUSF) derives a UPU-MAC-I AUSF and passes the UPU-MAC-I AUSF to the UE along with the UPU data for the update. The UE derives its own version of the UPU-MAC-I AUSF and compares the derived version of the UPU-MAC-I AUSF to the UPU-MAC-I AUSF received from the network. If they match, the UE verifies the UE parameter update. To have the MAC verification pass, the AUSF and the UE need to derive the same UPU-MAC-I AUSFHowever, in the current UE parameter update procedure, it is not clear whether the UPU header is used for the calculation of the UPU-MAC-I AUSF as the UPU header is an optional attribute.

[0006] In the embodiments described herein, an enhanced UE parameter update procedure is set forth, in which the use of the UPU header is specified when deriving the UPU-MAC-I AUSF Generally, the UE is configured to report a UPU header protection indicator to the network to indicate whether the UE supports UPU header protection. Thus, there is coordination between the AUSF and the UE in terms of using the UPU header for the calculation of the UPU-MAC-I AUSF The technical benefit is the UE parameter update procedure, and the protection mechanism in the UE parameter update procedure is improved.

[0007] In one embodiment, a method of performing a UE parameter update (UPU) is described. The method includes receiving, at a user equipment, a first UPU container from a network, the first UPU container comprising UPU data for the UE parameter update and a first message authentication code protecting the UPU data. The method further includes performing a verification of the first message authentication code, generating a UPU acknowledgement indicating whether the verification was successful, deriving a second message authentication code based on the UPU acknowledgement, and sending, from the user equipment to the network, a second message, the second message comprising a second UPU container containing the second message authentication code and a first indicator indicating whether the user equipment supports UPU header protection.

[0008] In one embodiment, a user equipment (UE) is configured to receive a UE parameter update (UPU). The user equipment comprises at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the user equipment at least to receive, from a network, a first UPU container comprising UPU data for the UE parameter update and a first message authentication code protecting the UPU data; perform a verification of the first message authentication code; generate a UPU acknowledgement indicating whether the verification was successful; derive a second message authentication code based on the UPU acknowledgement; and send, to the network, a second message, the second message comprising a second UPU container containing the second message authentication code and a first indicator indicating whether the user equipment supports UPU header protection.

[0009] In one embodiment, a unified data management (UDM) element is configured to perform a UE parameter update (UPU) for a user equipment. The UDM element includes at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the UDM element to at least: receive a UPU container containing a first message authentication code derived by the user equipment based on a UPU confirmation for a UE parameter update, and a first indicator indicating whether the user equipment supports UPU header protection; extract the first message authentication code and the first indicator from the UPU container; perform a verification of the first message authentication code; and store the first indicator.

[0010] Other embodiments can include a computer-readable medium storing the instructions, other systems, or other methods as described below. The various features of the different embodiments can be combined in different ways, including some features and excluding others, to suit different application needs.

[0011] The above summary presents a basic understanding of some aspects of this specification. This summary is not a comprehensive overview of the specification. It is neither intended to identify key or critical elements of the specification nor to delineate any scope of the specification or any scope of the claims. Its sole purpose is to present some concepts of the specification in a simplified form as a prelude to the more detailed description that is to follow later. BRIEF DESCRIPTION OF DRAWINGS

[0012] Some embodiments of the application are now described, by way of example only, and with reference to the accompanying drawings. The same reference numbers in different drawings represent the same or similar elements or the same or similar types of elements.

[0013] Figure 1 A high level architecture of a 5G system is illustrated.

[0014] Figure 2 A non-roaming architecture of a 5G system is illustrated.

[0015] Figure 3 Is a message diagram illustrating initiation of primary authentication.

[0016] Figure 4 Is a message diagram illustrating an authentication procedure.

[0017] Figure 5 Is a message diagram illustrating a UE parameter update procedure.

[0018] Figure 6 Is a block diagram of a UDM in an illustrative embodiment.

[0019] Figure 7 Is a block diagram of an AUSF in an illustrative embodiment.

[0020] Figure 8is a block diagram of an AMF in the illustrative embodiments.

[0021] Figure 9 is a block diagram of a user equipment (UE) in the illustrative embodiments.

[0022] Figure 10A is a message diagram illustrating a UE parameter update procedure in the illustrative embodiments.

[0023] Figure 10B illustrates an extension to the Nausf_UPUProtection service in the illustrative embodiments to include a UPU header protection indicator.

[0024] Figures 11-13 and Figures 14A-14B is a flow diagram illustrating a method of performing a UE parameter update procedure in the illustrative embodiments.

[0025] Figure 15 is a block diagram of a UPU protection request message for a UPU protection service in the illustrative embodiments.

[0026] Figure 16 is a block diagram of a UPU protection response message for a UPU protection service in the illustrative embodiments.

[0027] Figures 17-18 is a block diagram of derivation of an AUSF MAC in the illustrative embodiments.

[0028] Figure 19 is a block diagram of a SDM notification message for a subscriber data management service in the illustrative embodiments.

[0029] Figure 20 is a block diagram of a UPU transparent container IE in the illustrative embodiments.

[0030] Figure 21 is a block diagram of a UPU header of a UPU transparent container IE in the illustrative embodiments.

[0031] Figure 22 is a block diagram of a UPU transparent container IE in the illustrative embodiments.

[0032] Figure 23A is a message diagram illustrating a UE parameter update procedure in the illustrative embodiments.

[0033] Figure 23B illustrates an extension to the Nausf_UPUProtection service in the illustrative embodiments to include an enhanced UPU-MAC-I AUSF .

[0034] Figures 24-27is a flow diagram illustrating a method of performing a UE parameter update procedure in an illustrative embodiment.

[0035] Figure 28 is a block diagram illustrating a UPU protection request message for a UPU protection service in an illustrative embodiment.

[0036] Figure 29 is a block diagram illustrating a UPU protection response message for a UPU protection service in an illustrative embodiment.

[0037] Figure 30 is a block diagram illustrating derivation of a regular AUSF MAC in an illustrative embodiment.

[0038] Figure 31 is a block diagram illustrating derivation of an enhanced AUSF MAC in an illustrative embodiment.

[0039] Figure 32 is a block diagram illustrating a SDM notification message for a subscriber data management service in an illustrative embodiment.

[0040] Figure 33 is a block diagram illustrating a regular UPU transparent container IE in an illustrative embodiment.

[0041] Figure 34 is a block diagram illustrating an enhanced UPU transparent container IE in an illustrative embodiment.

[0042] Figure 35 is a block diagram illustrating a UPU transparent container IE in an illustrative embodiment.

[0043] Figure 36 illustrates a modified “UpuSecuritylnfo” data type for the Nausf_UPUProtection service API in an illustrative embodiment.

[0044] Figure 37 illustrates a modified “UpuInfo” data type for the Nudm_SubscriberDataManagement service API in an illustrative embodiment.

[0045] Figures 38-39 is a flow diagram illustrating additional details of a method of Figures 24-27

[0046] Figure 40 is a block diagram illustrating a UPU protection request message for a UPU protection service in another illustrative embodiment.

[0047] Figure 41 ​Figure illustrates a modified “UpuInfo” data type for Nausf_UPU Protection service API in an illustrative embodiment.

[0048] Figures 42A-42B Figure illustrates an “enhancedUpuInfo” data type for Nausf_UPU Protection service API in an illustrative embodiment.

[0049] Figure 43 Figure illustrates another modified “UpuInfo” data type for Nausf_UPU Protection service API in an illustrative embodiment.

[0050] Figure 44 Figure is a message diagram illustrating a UE parameter update procedure in an illustrative embodiment.

[0051] Figure 45 Figure is a block diagram illustrating a UPU transparent container IE in an illustrative embodiment.

[0052] Figure 46 Figure is a block diagram of a UPU header of a UPU transparent container IE in an illustrative embodiment.

[0053] Figures 47A-47B , Figure 48 , Figure 49 and Figures 50A-50B Figure is a flow diagram illustrating a method of performing a UE parameter update procedure in an illustrative embodiment.

[0054] Figure 51 Figure is a block diagram illustrating a UPU protection request message for a UPU protection service in an illustrative embodiment.

[0055] Figure 52 Figure is a block diagram illustrating a UPU protection response message for a UPU protection service in an illustrative embodiment.

[0056] Figure 53 Figure is a block diagram illustrating a SDM notification message for a subscriber data management service in an illustrative embodiment.

[0057] Figure 54 Figure is a block diagram illustrating a UPU transparent container IE in an illustrative embodiment.

[0058] Figure 55 Figure is a block diagram illustrating derivation of a UE MAC in a UE in an illustrative embodiment.

[0059] Figures 56-58 Figure is a message diagram illustrating a UE parameter update procedure in an illustrative embodiment. DETAILED DESCRIPTION

[0060] The accompanying drawings and the following description illustrate specific exemplary embodiments. Thus, it will be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the embodiments and are included within its scope. Furthermore, any examples described herein are intended to help illustrate the principles of the embodiments and should not be construed as limiting to the specifically recited examples and conditions. As a result, the inventive concept(s) is / are not limited to the specific embodiments or examples described below.

[0061] Figure 1 A high-level architecture of a 5G system 100 is illustrated. The 5G system (5GS) 100 is a communication system (e.g., a 3GPP system) that includes a 5G access network ((R)AN) 102, a 5G core network (5GC) 104, and a 5G user equipment (UE) 106. The access network 102 provides radio or wireless connectivity to the UE 106 and connects the UE 106 to the 5GC 104. The access network 102 can include an NG-RAN, a non-3GPP access network, or another type of RAN connected to the 5GC 104. The access network 102 can support Evolved-UMTS Terrestrial Radio Access Network (E-UTRAN) access (e.g., through eNodeBs, gNodeBs, and / or ng-eNodeBs), Wireless Local Area Network (WLAN) access, fixed access, satellite radio access, new radio access technologies (RATs), etc. The 5GC 104 interconnects the access network 102 with a data network (DN) 108. The 5GC 104 is composed of network functions (NFs) 110, which can be implemented as network elements on dedicated hardware, software instances running on dedicated hardware, virtualized functions instantiated on an appropriate platform (e.g., a cloud infrastructure), etc. The data network 108 can be a public or private data network outside of an operator’s network or an intra-operator data network (e.g., for IMS services). The UE 106 (also referred to as a mobile terminal) is a 5G-enabled device configured to register with the 5GC 104 to access services. The UE 106 can be an end-user device such as a mobile phone (e.g., a smartphone), a tablet computer, a computer with a mobile broadband adapter, etc. The UE 106 can be enabled for voice services, data services, machine-to-machine (M2M) or machine-type communication (MTC) services, and / or other services.

[0062] Figure 2 A non-roaming architecture 200 of a 5G system is illustrated. Figure 2The architecture 200 in FIG. 1 is a service-based representation, as further described in 3GPP TS 23.501 (vl8.0.0), which is incorporated by reference herein as if fully included herein. The architecture 200 is composed of network functions (NFs) for the 5GC 104, and the NFs for the control plane (CP) are separated from the user plane (UP). The control plane of the 5GC 104 includes an authentication server function (AUSF) 210, an access and mobility management function (AMF) 212, a session management function (SMF) 214, a policy control function (PCF) 216, a unified data management (UDM) 218, a network slice selection function (NSSF) 220, and an application function (AF) 222. The control plane of the 5GC 104 also includes a network exposure function (NEF) 224, a NF repository function (NRF) 226, a service communication proxy (SCP) 228, a network slice admission control function (NSACF) 230, a network slice specific and SNPN authentication and authorization function (NSSAAF) 232, and an edge application server discovery function (EASDF) 234. The user plane of the 5GC 104 includes one or more user plane functions (UPFs) 240 that communicate with the data network 108. The UE 106 is able to access the control plane and the user plane of the core network 104 through the (R)AN 102.

[0063] There are a large number of subscribers that are able to access services from a carrier that implements a mobile network including the 5G system 100, such as Figures 1-2 Communications between a subscriber (i.e., through a UE) and a mobile network are protected by security mechanisms, such as security mechanisms standardized by 3GPP. The subscribers and the carrier expect security guarantees from the security mechanisms. One of the security mechanisms is a primary authentication procedure that provides mutual authentication between a UE and a network. The primary authentication is further explained below.

[0064] The purpose of the primary authentication and key agreement procedure is to enable mutual authentication between the UE 106 and the network, and to provide key material that can be used between the UE 106 and the serving network in subsequent security procedures. The key material generated by the primary authentication and key agreement procedure results in one anchor key, which is referred to as K SEAFA key, provided by the AUSF 210 of the home network to a security anchor function (SEAF) of the serving network. The SEAF provides authentication functions via an AMF 212 in the serving network and supports primary authentication using a subscription concealed identifier (SUCI) that contains a concealed subscription permanent identifier (SUPI). The SUPI is a globally unique 5G identifier assigned to each subscriber in the 5G system 100. The SUCI consists of a SUPI type, a home network identifier (HN-ID) that identifies the home network of the subscriber, a routing indicator (RID) that is assigned to the subscriber by the home network operator and provisioned in a universal subscriber identity module (USIM) of the UE, a protection scheme identifier, a home network public key identifier, and a scheme output. The anchor key K SEAF From the anchor key K AUSF An intermediate key derivation from the anchor key K AUSF The key is established between the UE 106 and the home network as a result of the primary authentication procedure.

[0065] Figure 3is a message diagram illustrating the initiation of primary authentication such as described in 3GPP TS 33.501 (v18.0.0), which is incorporated by reference herein as if fully included herein. UE 106 sends an N1 message 311 (i.e., an initial non-access stratum (NAS) message), such as a registration request, to a serving network (e.g., an AMF 212 of the serving network). UE 106 uses a SUCI or a 5G global unique temporary identifier (5G-GUTI) in the registration request. SEAF 302 of AMF 212 can initiate authentication with UE 106 during any procedure that establishes a signaling connection with UE 106. SEAF 302 invokes the Nausf_UEAuthentication service by sending an Nausf_UEAuthentication_Authenticate request message 312 to AUSF 210 to initiate authentication. Nausf_UEAuthentication_Authenticate request message 312 includes a SUCI or SUPI, and a serving network name (SN-Name). Upon receiving Nausf_UEAuthentication_Authenticate request message 312, AUSF 210 checks whether the requesting SEAF 302 is entitled to use the serving network name in Nausf_UEAuthentication_Authenticate request message 312 by comparing the serving network name with an expected serving network name in the serving network. When the serving network is authorized to use the serving network name, AUSF 210 sends an Nudm_UEAuthentication_Get request message 313 to UDM 218. Nudm_UEAuthentication_Get request message 313 includes a SUCI or SUPI, and a serving network name. Upon receiving Nudm_UEAuthentication_Get request message 313, UDM 218 identifies the SUPI (if received), or invokes a subscription identifier de-concealing function (SIDF) that de-conceals the SUPI (if received) from the SUCI. UDM 218 (or an authentication credential repository and processing function (ARPF) of UDM 218) selects or picks an authentication method for primary authentication based on the SUPI.

[0066] Figure 4is a message diagram illustrating a main authentication procedure such as described in 3GPP TS 33.501. In this example, 5G Authentication and Key Agreement (AKA) is described, but similar concepts apply to Extensible Authentication Protocol AKA (EAP-AKA'). For the Nudm_UEAuthentication_Get request, the UDM 218 creates a 5G Home Environment Authentication Vector (5G HE AV) for the selected authentication method. The UDM 218 derives the K AUSF key and computes an expected response to the challenge (XRES ). The UDM 218 creates the 5G HE AV including an authentication token (AUTN), the expected response (XRES ), the K AUSF key, and a random challenge (RAND). The UDM 218 then sends the Nudm_UEAuthentication_Get response message 411 to the AUSF 210, where the 5G HE AV is to be used for authentication (e.g., 5G AKA in Figure 4 ). In case the SUCI is included in the Nudm_UEAuthentication_Get request, the UDM 218 includes the SUPI in the Nudm_UEAuthentication_Get response message 411 after hiding the SUPI from the SUCI. If the subscriber has an Authentication and Key Management for Applications (AKMA) subscription, the UDM 218 includes the AKMA indication and the RID in the Nudm_UEAuthentication_Get response message 411.

[0067] In response to the Nudm_UEAuthentication_Get response message 411, the AUSF 210 stores the expected response (XRES ) temporarily with the received SUCI or SUPI. Then, the AUSF 210 generates a 5G Authentication Vector (5G AV) from the 5G HE AV received from the UDM 218 by: computing a hashed expected response (HXRES ) from the expected response (XRES ) and computing the K AUSF key from the K SEAF key, and replacing XRES with HXRES and replacing the K SEAF key with the K AUSF key in the 5G HE AV. The AUSF 210 deletes the K SEAFThe key is used to generate a 5G service environment authentication vector (5G SE AV) that includes an authentication token (AUTN), a hashed expected response (HXRES ), and a random challenge (RAND). The AUSF 210 sends an Nausf_UEAuthentication_Authenticate response message 412 to the SEAF 302 that includes the 5G SE AV. In response, the SEAF 302 sends the authentication token (AUTN) and the random challenge (RAND) to the UE 106 in a NAS message authentication request message 413.

[0068] Although Figure 4 not shown in FIG. 2, the UE 106 includes a mobile equipment (ME) and a USIM. The ME receives the authentication token (AUTN) and the random challenge (RAND) in the NAS message authentication request message 413 and forwards the authentication token (AUTN) and the random challenge (RAND) to the USIM. The USIM of the UE 106 verifies the freshness of the received values by checking whether the authentication token (AUTN) can be accepted. If so, the USIM computes a response (RES), a cipher key (CK), and an integrity key (IK) based on the random challenge (RAND) and returns the response (RES), the CK key, and the IK key to the ME. The ME of the UE 106 computes RES from the RES AUSF , and computes K AUSF from the CK || IK SEAF key.

[0069] The UE 106 sends a NAS message authentication response message 414 to the SEAF 302 that includes the RES . In response, the SEAF 302 computes HRES from the RES , and compares HRES to HXRES . If they are identical, the SEAF 302 considers the authentication to be successful from the perspective of the serving network. The SEAF 302 sends an Nausf_UEAuthentication_Authenticate request message 415 to the AUSF 210 that includes the RES received from the UE 106. When the AUSF 210 receives the Nausf_UEAuthentication_Authenticate request message 415 that includes the RES as an authentication confirmation, the AUSF 210 stores the K AUSF key based on the policies of the home network operator and the received RES with the stored XRES If the RES and XRES are equal, the AUSF 210 considers the authentication successful from the home network perspective. The AUSF 210 informs the UDM 218 of the authentication result (not shown). The AUSF 210 also sends the Nausf_UEAuthentication_Authenticate response message 416 to the SEAF 302 to indicate whether the authentication was successful from the home network perspective. If the authentication was successful, the K SEAF key is sent to the SEAF 302 in the Nausf_UEAuthentication_Authenticate response message 416. In case the AUSF 210 received a SUCI from the SEAF 302 in the authentication request, the AUSF 210 includes the SUPI in the Nausf_UEAuthentication_Authenticate response message 416 if the authentication was successful.

[0070] UE Parameter Update (UPU) is a procedure between a UE and a home network in 5G. The UE Parameter Update procedure enables the home network to update one or more configuration parameters (i.e., UE parameters) in the UE and / or USIM using control plane signaling. For example, the UDM 218 can decide to perform a UE Parameter Update at any time after the UE 106 has been successfully authenticated and registered to the 5G system 100, as described in Section 6.15.2 of 3GPP TS 33.501. Figure 5 is a message diagram illustrating the UE Parameter Update procedure. In one example, the UDM 218 decides to perform a UE Parameter Update (UPU) procedure using a control plane procedure at the time of registration of the UE 106 to the 5G system 100. If the end consumer of any UE parameter to be updated (e.g., an updated RID) is the USIM of the UE 106, the UDM 218 uses a secure grouping mechanism to update the parameters stored on the USIM to protect these parameters. The UDM 218 prepares UE Parameter Update Data (UPU data) by including the securely grouped parameters (if any), as well as any UE parameters for which the end consumer is the ME of the UE 106.

[0071] The AUSF 210 provides the UPUProtection service as described in 3GPP TS 29.509 (vl8.0.0), which is incorporated by reference herein as if fully included herein. The AUSF 210 acts as an NF service producer providing the UPUProtection service to NF service consumers. The UPUProtection service provides the NF service consumers (e.g., UDM 218) with a UPU-MAC-I AUSF and Counter UPU to protect the UPU data from being tampered or deleted. Optionally, the UPUProtection service also provides the NF service consumers (e.g., UDM 218) with a UPU-XMAC-I UE that allows the NF service consumer to verify whether the UE 106 correctly received the UPU data. The UDM 218 invokes the Nausf_UPUProtection service by sending the Nausf_UPUProtection Request message 511 to the AUSF 210 to obtain the UPU-MAC-I AUSF and Counter UPU . The UDM 218 includes the SUPI and the UPU data in the Nausf_UPUProtection Request message 511. If the UDM 218 decides that the UE 106 confirms the successful security check of the received UPU data, the UDM 218 sets a corresponding indication in the UPU data and includes an ACK indication in the Nausf_UPUProtection Request message 511 to signal that it also needs to expect the UPU-XMAC-I UE .

[0072] The AUSF 210 uses the UE-specific home key (K AUSF ) and the UPU data received from the UDM 218 to compute or derive the UPU-MAC-I AUSF and delivers the UPU-MAC-I AUSF and Counter UPU to the UDM 218 in the Nausf_UPUProtection Response message 512. If the ACK indication is present in the Nausf_UPUProtection Request message 511, the AUSF 210 computes or derives the UPU-XMAC-I UE and returns the computed UPU-XMAC-I UE in the Nausf_UPUProtection Response message 512. The UPU-XMAC-I UE allows the UDM 218 to verify whether the UE 106 correctly received the UPU data.

[0073] The UDM 218 then invokes the Nudm_SDM_Notification service operation and sends the Nudm_SDM_Notification message 513 to the AMF 212, which includes the UPU transparent container if the AMF 212 supports the UPU transparent container, or includes an individual information element (IE) that includes the UPU data, the UPU-MAC-I AUSF and the Counter UPU . If the UDM 218 requests an acknowledgement, it temporarily stores the expected UPU-XMAC-I UE . Upon receiving the Nudm_SDM_Notification message 513, the AMF 212 sends a downlink (DL) NAS transport message 514 to the UE 106. If received from the UDM 218, the AMF 212 includes the transparent container in the DL NAS transport message 514. Otherwise, if the UDM 218 provided an individual IE, the AMF 212 constructs the UPU transparent container.

[0074] Upon receiving the DL NAS transport message 514, the UE 106 computes the UPU-MAC-I UPU based on the received UPU data and the Counter AUSF in the same way as the AUSF 210, and verifies whether it matches the UPU-MAC-I AUSF value received in the DL NAS transport message 514 (i.e., within the transparent container). If the verification of the UPU-MAC-I AUSF is successful and the UPU data contains any parameters protected by a security package, the ME of the UE 106 forwards the security package to the USIM. If the verification of the UPU-MAC-I AUSF is successful and the UPU data contains any parameters not protected by a security package, the ME of the UE 106 updates its stored parameters using the received parameters in the UPU data.

[0075] If the UDM 218 has requested an acknowledgement to the UE 106 and the UE 106 has successfully verified and updated the UPU data provided by the UDM 218, the UE 106 sends an uplink (UL) NAS transport message 515 to the serving AMF 212. The UE 106 generates the UPU-MAC-I UE and includes the generated UPU-MAC-I UE in a transparent container in the UL NAS transport message 515. The AMF 212 sends the Nudm_SDM_Notification Ack message 516 to the UDM 218 with the UPU-MAC-I UENudm_SDM_Info message 516 with the transparent container. If the UPU-MAC-I UE is received in the UL NAS transport message 515, the AMF 212 sends the Nudm_SDM_Info message 516 with the transparent container to the UDM 218. If the UDM 218 indicates that the UE 106 confirms successful security check of the received UPU data, the UDM 218 compares the received UPU-MAC-I UE with the expected UPU-XMAC-I UE temporarily stored by the UDM 218 to verify that the UE 106 successfully received the UPU data.

[0076] For UPU operations, the AUSF 210 and the UE 106 associate a 16-bit counter Counter UPU with the K AUSF key and maintain Counter AUSF for the lifetime of the K UPU key. When a new derived K AUSF key is stored, the UE 106 initializes Counter UPU to 0x00 0x00 and stores Counter UPU . If the USIM of the UE 106 supports both 5G parameter storage and 5G parameter extended storage, Counter UPU is stored in the USIM. Otherwise, Counter UPU is stored in the non-volatile memory of the ME.

[0077] To generate the UPU-MAC-I AUSF , the AUSF 210 uses Counter UPU . For each new computation of the UPU-MAC-I AUSF , Counter UPU is incremented by the AUSF 210. Counter UPU is used as a freshness input for the derivation of the UPU-MAC-I AUSF and the UPU-MAC-I UE to mitigate replay attacks. The AUSF 210 sends the value of Counter UPU to the UE 106 (used for generation of the UPU-MAC-I AUSF ) along with the UPU-MAC-I AUSF . The UE 106 only accepts Counter UPU values that are greater than the stored Counter UPU value. If the received UPU-MAC-I AUSFauthentication is successful, the UE 106 utilizes the received Counter UPU updates the stored Counter UPU . When deriving the UPU-MAC-I UE for UPU confirmation, the UE 106 uses the Counter UPU received from the UDM 218.

[0078] When a new K AUSF is derived, the AUSF 210 supporting UE parameter update using control plane procedures initializes the Counter UPU to 0x00 0x01. The AUSF 210 sets the Counter AUSF to 0x00 0x02 after the first computation of the UPU-MAC-I UPU and monotonically increments the Counter AUSF for each additional computation of the UPU-MAC-I UPU . If the Counter AUSF associated with the K UPU of the UE 106 is about to end, the AUSF 210 suspends the UE parameter update protection service for the UE 106. When a new K AUSF is generated for the UE 106, the Counter UPU at the AUSF 210 is reset to 0x00 0x01 and the AUSF 210 resumes the UE parameter update protection service for the UE 106.

[0079] One issue with the current UE parameter update procedure is the obfuscation used for the UPU header when deriving the UPU-MAC-I AUSF . Typically, message authentication methods at the control plane use a message authentication code (MAC) to authenticate the message. For example, a device receiving a message derives a MAC for the received message and compares the derived MAC with a MAC received in the message. If the MACs agree, the message is authenticated. If the MACs do not agree, the message is typically discarded and a retransmission is requested. In order to be authenticated by the MAC during the UE parameter update procedure, the AUSF 210 and the UE 106 need to derive the same MAC (UPU-MAC-I AUSF ) from the same data. However, the data model for the UPU protection service described in 3GPP TS 29.509 provides an optional UPU header (see section 6.3.6.2.2). Thus, when requesting the UPU-MAC-I AUSF and the Counter UPUThe UDM 218 can or can not send the UPU header to the AUSF 210 at this time. This leads to confusion about whether the AUSF 210 is to derive a UPU-MAC-I AUSF based on the UPU header.

[0080] For example, if the AUSF 210 derives a UPU-MAC-I AUSF based on the UPU data, the UPU data is protected by the UPU-MAC-I AUSF or in the UPU-MAC-I AUSF . In other words, the UE 106 can verify the UPU data based on the UPU-MAC-I AUSF . However, it can be beneficial to protect the UPU header. To protect the UPU header in a similar manner to the UPU data, the AUSF 210 is to derive a UPU-MAC-I AUSF based on the UPU header.

[0081] In the embodiments described herein, an enhanced UE parameter update procedure is set forth between the 5G system 100 and the UE 106 in generating a MAC. As described herein, the MAC generated by the AUSF 210 and verified by the UE 106 can be referred to as an AUSF MAC (e.g., UPU-MAC-I AUSF ), a first MAC, a first UPU MAC, etc. The MAC generated by the UE 106 and verified by the UDM 218 can be referred to as a UE MAC (e.g., UPU-MAC-I UE ), a second MAC, a second UPU MAC, etc.

[0082] Generally, the network functions for the UE parameter update procedure include the UDM 218, the AUSF 210, and the AMF 212. Figures 6-8 A block diagram of these network functions is provided in FIG. 6. Figure 9 A block diagram of the UE 106 is provided in FIG. 7.

[0083] Figure 6 is a block diagram of the UDM 218 in illustrative embodiments. The UDM 218 is a network element or network function configured to manage network subscriber data within the 5G core network 104. In this embodiment, the UDM 218 includes the following subsystems: a network interface component 602 and a data management controller 604 running on one or more platforms. The network interface component 602 can include circuitry, logic, hardware, components, etc. configured to exchange control plane messages or signaling with other network elements and / or UEs. The network interface component 602 can operate using various protocols or reference points. The data management controller 604 can include circuitry, logic, hardware, components, etc. configured to support the services, operations, procedures, or functions of the UDM.

[0084] One or more subsystems of the UDM 218 can be implemented on a hardware platform composed of analog and / or digital circuitry. For example, the data management controller 604 can be implemented on one or more processors 630 that execute instructions 634 (i.e., computer-readable code) for software loaded into memory 632. The processors 630 include integrated hardware circuitry configured to execute the instructions 634 to provide the functionality of the UDM 218. The processors 630 can include a set of one or more processors or can include a multi-processor core, depending on the particular implementation. The memory 632 is a non-transitory computer-readable storage medium for data, instructions, applications, etc., and is accessible to the processors 630. The memory 632 is a hardware storage device capable of temporarily and / or permanently storing information. The memory 632 can include random access memory or any other volatile or non-volatile storage device. One or more subsystems of the UDM 218 can be implemented on a cloud computing platform or another type of processing platform.

[0085] The UDM 218 can include various other components not specifically shown in the figures. Figure 6 The UDM 218 can include various other components not specifically shown in the figures.

[0086] Figure 7 is a block diagram of the AUSF 210 in the illustrative embodiments. The AUSF 210 is a network element or network function configured to perform authentication with UEs. In this embodiment, the AUSF 210 includes the following subsystems: a network interface component 702, and an authentication controller 704 running on one or more platforms. The network interface component 702 can include circuitry, logic, hardware, components, etc. configured to exchange control plane messages or signaling with other network elements and / or UEs. The network interface component 702 can operate using various protocols or reference points. The authentication controller 704 can include circuitry, logic, hardware, components, etc. configured to support the operations, processes, or functionality of the AUSF.

[0087] One or more subsystems of the AUSF 210 can be implemented on a hardware platform composed of analog and / or digital circuitry. One or more subsystems of the AUSF 210 can be implemented on one or more processors 730 that execute instructions 734 (i.e., computer-readable code) for software loaded into memory 732. One or more subsystems of the AUSF 210 can be implemented on a cloud computing platform or another type of processing platform.

[0088] The AUSF 210 can include various other components not specifically shown in the figures. Figure 7 The AUSF 210 can include various other components not specifically shown in the figures.

[0089] Figure 8is a block diagram of an AMF 212 in the illustrative embodiments. The AMF 212 is a network element or network function configured to provide registration management of UEs. In this embodiment, the AMF 212 includes the following subsystems: a network interface component 802, and an access and mobility controller 804 running on one or more platforms. The network interface component 802 can include circuitry, logic, hardware, components, etc. configured to exchange control plane messages or signaling with other network elements and / or UEs. The network interface component 802 can operate using various protocols or reference points. The access and mobility controller 804 can include circuitry, logic, hardware, components, etc. configured to support the operations, procedures, or functions of the AMF.

[0090] One or more subsystems of the AMF 212 can be implemented on a hardware platform composed of analog and / or digital circuitry. One or more subsystems of the AMF 212 can be implemented on one or more processors 830 executing instructions 834 (i.e., computer-readable code) for software loaded into memory 832. One or more subsystems of the AMF 212 can be implemented on a cloud computing platform or another type of processing platform.

[0091] The AMF 212 can include various other components not specifically shown in FIG. 8. Figure 8

[0092] Figure 9 ​is a block diagram of a UE 106 in illustrative embodiments. From a functional perspective, the UE 106 is comprised of at least two parts: a mobile equipment (ME) 900 and a universal subscriber identity module (USIM) 960. The ME 900 includes a radio interface component 902, one or more processors 904, a memory 906, a user interface component 908. The UE 106 can also include a battery 910. The radio interface component 902 is a hardware component that represents the local radio resources of the UE 106, such as an RF unit 920 (e.g., one or more radio transceivers) and one or more antennas 922. The radio interface component 902 can be configured for WiFi, Bluetooth, 5G NR, LTE, etc. The processor 904 represents the internal circuitry, logic, hardware, components, etc. that provide the functionality of the UE 106. The processor 904 can be configured to execute instructions 940 for software loaded into the memory 906. The processor 904 can execute an operating system (OS) 934 for the UE 106, as well as one or more applications, which OS manages hardware and software resources. The processor 904 can implement an update controller 936 configured to perform UE parameter updates. The user interface component 908 is a hardware component for interacting with an end user. For example, the user interface component 908 can include a display 950, screen, touchscreen, etc. (e.g., liquid crystal display (LCD), light emitting diode (LED) display, etc.). The user interface component 908 can include a keyboard or keypad 952, track device (e.g., trackball or trackpad), speaker, microphone, etc.

[0093] The USIM 960 is an integrated circuit that provides security and integrity functions for the UE 106. The USIM 960 includes or is provisioned with a subscription profile associated with a subscription of a subscriber. The subscription profile can include various information, such as subscription credentials (e.g., SUPI) for uniquely identifying the subscription and mutually authenticating the UE 106 and a network.

[0094] The UE 106 can include various other components not specifically shown in FIG. 9. Figure 9 The UE 106 can include various other components not specifically shown in FIG. 9.

[0095] The following embodiments describe an enhanced UE parameter update procedure. Although described separately, the concepts described below with respect to the various embodiments can be combined as desired. Example 1

[0096] Figure 10A is a message diagram illustrating a UE parameter update procedure in illustrative embodiments. Figure 10AThe UE parameter update procedure described in the middle can be an extension to section 6.15.2.1 of 3GPP TS 33.501. As an overall summary, the UPU header can be protected in the UE parameter update and used for derivation of the AUSF MAC according to the capabilities of the UE 106. If the UE 106 supports UPU header protection, the AUSF 210 and the UE 106 can derive the AUSF MAC based on the UPU header. UPU header protection is a protection scheme, mechanism, method, or procedure in which the AUSF MAC is derived based at least in part on the UPU header. One technical advantage is that the UPU header, and any other UPU information (e.g., UPU data) used to derive the AUSF MAC, can be protected in the UE parameter update. If the UE 106 does not support UPU header protection, the AUSF 210 and the UE 106 can derive the AUSF MAC that is not based on the UPU header. One technical advantage is that existing UEs can still perform the UE parameter update based on the UPU data.

[0097] In one embodiment, during NAS registration of the UE 106, the UE 106 provides a UPU header protection indicator to the AMF 212. The AMF 212 includes the UPU header protection indicator in an authentication or registration message and provides the UPU header protection indicator to the UDM 218. The UDM 218 stores the UPU header protection indicator in, such as, a unified data repository (UDR). The UDM 218 decides to perform the UE parameter update (UPU) using a control plane procedure at the time of registration of the UE 106 to the 5G system 100. If the end consumer of any UE parameter to be updated (e.g., updated RID) is the USIM of the UE 106, the UDM 218 uses a secure grouping mechanism to update the parameters stored on the USIM to protect the parameters. The UDM 218 prepares the UE parameter update data (UPU data) by including the parameters protected by secure grouping, if any, and any UE parameter for which the end consumer is the ME of the UE 106.

[0098] The UDM 218 obtains the UPU-MAC-I and Counter from the AUSF 210 by sending a Nausf_UPUProtection request message 1011 to the AUSF 210 AUSF and Counter UPUto invoke the Nausf_UPUProtection service. The UDM 218 includes the SUPI and the UPU data in the Nausf_UPUProtection request message 1011. If the UDM 218 decides that the UE 106 confirms successful security check of the received UPU data, the UDM 218 sets a corresponding indication in the UPU data and includes an ACK indication in the Nausf_UPUProtection request message 1011 to signal that it also needs to expect the UPU-XMAC-I UE . For example, if the stored UPU header protection indicator 1003 for the UE 106 is set to true, the UDM 218 also includes the UPU header protection indicator 1003 in the Nausf_UPUProtection service operation, i.e., in the Nausf_UPUProtection request message 1011.

[0099] The AUSF 210 computes or derives the UPU-MAC-I AUSF using the UE-specific home key (K AUSF ) and delivers the UPU-MAC-I AUSF and Counter UPU to the UDM 218 in the Nausf_UPUProtection response message 1012. When the UPU header protection indicator 1003 is present in the Nausf_UPUProtection request message 1011 and set to true (i.e., the UE 106 supports UPU header protection), the AUSF 210 computes or derives the UPU-MAC-I AUSF based at least in part on the UPU header. Including the UPU header when computing the UPU-MAC-I AUSF integrity can protect the UPU header and allow the UE 106 to verify that the UPU header has not been tampered with by any intermediaries. When the UPU header protection indicator 1003 is not present or set to false, e.g., in the Nausf_UPUProtection request message 1011, the AUSF 210 computes or derives the UPU-MAC-I AUSF based on the UPU data, not the UPU header. Including the UPU data when computing the UPU-MAC-I AUSF integrity can protect the UPU data and allow the UE 106 to verify that the UPU data has not been tampered with by any intermediaries. If the ACK indication is present in the Nausf_UPUProtection request message 1011, the AUSF 210 computes or derives the UPU-XMAC-I UEand returns the computed UPU-XMAC-I in the Nausf_UPUProtection response message 1012 UE The UPU-XMAC-I UE is expected to be verified by the UDM 218 to confirm that the UE 106 received the UPU data correctly.

[0100] The UDM 218 then invokes the Nudm_SDM_Notification service operation and sends the Nudm_SDM_Notification message 1013 to the AMF 212, which includes the UPU transparent container if the AMF 212 supports UPU transparent container, or includes an individual information element (IE) that includes the UPU data, the UPU-MAC-I AUSF and the Counter UPU If the UDM 218 requests an acknowledgement, it temporarily stores the expected UPU-XMAC-I UE Upon receiving the Nudm_SDM_Notification message 1013, the AMF 212 sends a DL NAS transport message 1014 to the UE 106. If received from the UDM 218, the AMF 212 includes the transparent container in the DL NAS transport message 1014. Otherwise, if the UDM 218 provided an individual IE, the AMF 212 constructs the UPU transparent container.

[0101] Upon receiving the DL NAS transport message 1014, the UE 106 computes the UPU-MAC-I UPU in the same way as the AUSF 210, based on the received UPU data and the Counter AUSF and verifies whether it matches the UPU-MAC-I AUSF value received in the DL NAS transport message 1014 (i.e., within the transparent container). If the verification of the UPU-MAC-I AUSF is successful and the UPU data contains any parameters protected by a security package, the ME of the UE 106 forwards the security package to the USIM. If the verification of the UPU-MAC-I AUSF is successful and the UPU data contains any parameters not protected by a security package, the ME of the UE 106 updates its stored parameters using the received parameters in the UPU data.

[0102] If the UDM 218 has requested an acknowledgement from the UE 106 and the UE 106 has successfully verified and updated the UPU data provided by the UDM 218, the UE 106 sends an UL NAS transport message 1015 to the serving AMF 212. The UE 106 generates the UPU-MAC-IUE and the generated UPU-MAC-I UE is included in a transparent container in the UL NAS transport message 1015. The AMF 212 sends a Nudm_SDM_Info message 1016 to the UDM 218 with the UPU-MAC-I UE . If the transparent container with the UPU-MAC-I UE is received in the UL NAS transport message 1015, the AMF 212 sends a Nudm_SDM_Info message 1016 to the UDM 218 with the transparent container. If the UDM 218 indicates that the UE 106 confirms successful security check of the received UPU data, the UDM 218 compares the received UPU-MAC-I UE with the expected UPU-XMAC-I UE temporarily stored by the UDM 218 to verify that the UE 106 successfully received the UPU data.

[0103] To provide the UPU header protection indicator 1003 to the AUSF 210, the UPU protection service (e.g., the Nausf_UPUProtection service) can be extended. Figure 10B An extension 1050 of the Nausf_UPUProtection service in an illustrative embodiment to include the UPU header protection indicator 1003 is illustrated. As described in 3GPP TS 33.501 section 14.1.4, the Nausf_UPUProtection service specifies the following as required inputs: Requester ID, SUPI, Service Name, UPU Data. The Nausf_UPUProtection service specifies an ACK indicator as an optional input. In one embodiment, the UPU header protection indicator 1003 is included as an optional input 1052 of the Nausf_UPUProtection service. For example, when the UE 106 supports UPU header protection, the UPU header protection indicator 1003 can be set to “True” or “1”. When the UE 106 does not support UPU header protection, the UPU header protection indicator 1003 can be set to “False” or “0”, or can be omitted. One technical advantage is that the UDM 218 is able to inform the AUSF 210 whether to derive the UPU-MAC-I AUSF based on the UPU header according to the UPU header protection indicator 1003.

[0104] Figures 11-13 and Figures 14A-14B is a flowchart illustrating a method 1100 of performing a UE parameter update procedure in an illustrative embodiment. More specifically, the method 1100 will be described with reference to the UDM 218 in Figure 6 .Figure 11 the steps of the method 1100 in FIG. 11 will be described with reference to Figure 7 the AUSF 210 in FIG. 21 Figure 12 the method 1100 in FIG. 11 will be described with reference to Figure 8 the AMF 212 in FIG. 22 Figure 13 the steps of the method 1100 in FIG. 11 will be described with reference to Figure 9 the UE 106 in FIG. 10 Figures 14A-14B the steps of the method 1100 in FIG. 11 will be described with reference to. Those skilled in the art will understand that the method 1100 can be performed in other systems, devices, or network functions. The steps of the flowcharts described herein are not all-inclusive, but can include other steps not shown, and the steps can be performed in alternative orders.

[0105] In Figure 11 , the data management controller 604 of the UDM 218 triggers a UE parameter update (UPU) for the UE 106 (step 1102), such as for a RID update, a network slice selection assistance information (NSSAI) update, and the like. In other words, when the UE 106 registers to the 5G system 100, the data management controller 604 decides to perform a UE parameter update using a control plane procedure. Upon triggering the UE parameter update, the data management controller 604 invokes a UPU protection service (e.g., Nausf_UPUProtection) to the AUSF 210 and generates a UPU protection request message (e.g., Nausf_UPUProtection Request message) that requests an AUSF MAC (i.e., UPU-MAC-I AUSF ) and a UPU counter (i.e., Counter UPU ). The data management controller 604 of the UDM 218 is configured to include, in the UPU protection request message, the SUPI for the UE 106, the UPU information for the UE parameter update, and the UPU header protection indicator 1003.

[0106] Figure 15 is a block diagram illustrating a UPU protection request message 1501 for a UPU protection service in an illustrative embodiment. The UPU protection request message 1501 includes UPU information 1500 (also referred to as first UPU information) for the UPU protection service. In Figure 15In particular embodiments, the UPU information 1500 includes the following attributes (also referred to as information elements (IE)): a UPU data list attribute 1531, a UPU acknowledgement indicator attribute 1532, and a UPU header attribute 1533. The UPU data list attribute 1531 includes the UPU data list 1502. The UPU information 1500 can define updates to multiple UE parameters, and thus the UPU data list 1502 can comprise a collection or array of UPU data 1504. The UPU data 1504 is information defining a UE parameter update for a UE parameter. For example, the UPU data 1504 can include routing indicator update data with a RID to be updated at the UE 106, default NSSAI update data with a default configuration NSSAI to be updated at the UE 106, and the like. Each data set of UPU data 1504 includes update data for an individual UE parameter. The UPU acknowledgement indicator attribute 1532 includes a UPU acknowledgement indicator 1506. The UPU acknowledgement indicator 1506 (e.g., a Boolean value) indicates whether the UE 106 is to respond to the UDM 218 with a UE MAC (e.g., a UPU-MAC-I UE ) or not. The UPU header attribute 1533 is optional and can include a UPU header 1508. The UPU header 1508 includes information about the UE parameter update (separate or distinct from the UPU data 1504). For example, the UPU header 1508 can include a UPU data type indicator (e.g., a value of “0” when the UE parameter update transparent container carries a UPU data list, and a value of “1” when the UE parameter update transparent container carries an acknowledgement of successful receipt of a UPU data table), a UPU acknowledgement (ACK) indicator (e.g., a value of “zero” when an acknowledgement is not requested, and a value of “1” when an acknowledgement is requested), a re-registration (REG) indicator (e.g., a value of “0” when re-registration is not requested, and a value of “1” when re-registration is requested), and the like.

[0107] The UPU information 1500 can have a structured data type provided for the Nausf_UPU Protection service Application Programming Interface (API) as described in Section 6.3 of 3GPP TS 29.509. The Nausf_UPU Protection service API defines a “UpuInfo” data type as described in Section 6.3.6.2.2 of 3GPP TS 29.509. The “UpuInfo” data type includes the following attributes: “upuDataList,” “upuHeader,” “upuAckInd,” “supportedFeatures,” and “upuTransparentInfo.” In the “UpuInfo” data type, the “upuHeader” attribute is optional (i.e., “O”). The “upuHeader” attribute contains a “UPU Header” IE specified in Section 9.11.3.53A of 3GPP TS 24.501 (v.18.1.0), which is incorporated by reference herein as if fully included herein.

[0108] The UPU protection request message 1501 also includes a UPU header protection indicator 1003, which is a value, flag, or indicator type that indicates whether the UE supports UPU header protection. For example, the UPU header protection indicator 1003 can include a Boolean value such as “T” or “F,” “1” or “0,” and the like. As noted above, the UPU header protection indicator 1003 can be an optional input to the UPU protection service.

[0109] In Figure 11When the UE parameter update is triggered, the data management controller 604 determines or identifies whether the UE 106 supports UPU header protection at the time of derivation of the MAC (step 1106). When the UE 106 is determined to support UPU header protection, the data management controller 604 of the UDM 218 sets the UPU header protection indicator 1003 in the UPU protection request message 1501 (step 1108) to indicate that the UE 106 supports UPU header protection (e.g., set to “true”). Setting the UPU header protection indicator 1003 in this manner requests the AUSF 210 to derive the AUSF MAC based on the UPU header 1508. When the UE 106 is determined not to support UPU header protection, the data management controller 604 of the UDM 218 does not set the UPU header protection indicator 1003 in the UPU protection request message 1501 to indicate that the UE 106 supports UPU header protection (step 1110). For example, the data management controller 604 can set the UPU header protection indicator 1003 to “false” or omit the UPU header protection indicator 1003 from the UPU protection request message 1501. This requests the AUSF 210 to derive the AUSF MAC based on the UPU data 1504 and not the UPU header 1508. The data management controller 604 then sends the UPU protection request message 1501 to the AUSF 210 (step 1112). One technical advantage is that the UDM 218 is able to request the AUSF 210 to derive the AUSF MAC based on the UPU header 1508 or not based on the UPU header 1508 depending on the UPU header protection indicator 1003.

[0110] For step 1106, the data management controller 604 can determine whether the UE 106 supports UPU header protection in various ways. For example, the data management controller 604 can query a unified data repository (UDR), a home subscriber server (HSS), or another network function for subscription information or capability information about the UE 106. In one embodiment, the data management controller 604 can receive the UPU header protection indicator 1003 prior to initiating the UE parameter update, such as during primary authentication (and / or reauthentication) of the UE 106 (optional step 1130). For example, the UE 106 can send a registration request to a serving network (e.g., AMF 212 of the serving network) during primary authentication (see also N1 message 311 sent by the UE 106 in Figure 3 For example, the UE 106 can include the UPU header protection indicator 1003 in the registration request, which indicates whether the UE 106 supports UPU header protection. The AMF 212 then delivers the UPU header protection indicator 1003 to the UDM 218 in an authentication or registration message. As Figure 3As shown, SEAF 302 of AMF 212 invokes the Nausf_UEAuthentication service by sending a Nausf_UEAuthentication_Authenticate request message 312 to AUSF 210 to initiate authentication. SEAF 302 can include the UPU header protection indicator 1003 in the Nausf_UEAuthentication_Authenticate request message 312. AUSF 210 in turn sends a Nudm_UEAuthentication_Get request message 313 to UDM 218. AUSF 210 can include the UPU header protection indicator 1003 in the Nudm_UEAuthentication_Get request message 313. Data management controller 604 of UDM 218 receives the UPU header protection indicator 1003, such as in the Nudm_UEAuthentication_Get request message 313, and stores the UPU header protection indicator 1003. Thus, when a UE parameter update is triggered, data management controller 604 can determine whether the UPU header protection indicator 1003 for UE 106 was received or stored. One technical advantage is that UDM 218 receives the capabilities of UE 106, such as during primary authentication.

[0111] In Figure 12 AUSF 210, authentication controller 704 receives a UPU protection request message 1501 from UDM 218 (step 1202). Authentication controller 704 processes the UPU protection request message 1501 and determines whether UE 106 supports UPU header protection based on the UPU header protection indicator 1003 (step 1204). For example, authentication controller 704 processes the UPU protection request message 1501 to determine whether the UPU protection request message 1501 includes the UPU header protection indicator 1003 set to “true” or some other value indicating that UE 106 supports UPU header protection. When UE 106 supports UPU header protection, authentication controller 704 derives or generates an AUSF MAC based on the UPU header 1508 (step 1206). When UE 106 does not support UPU header protection, authentication controller 704 derives or generates an AUSF MAC based on the UPU data 1504 and not (i.e., without regard to) the UPU header 1508 (step 1208). One technical advantage is that AUSF 210 is instructed whether to derive an AUSF MAC based on the UPU header 1508 depending on the UPU header protection indicator 1003 provided by UDM 218. Another technical advantage is that the UPU header 1508 is protected in a UE parameter update when the AUSF MAC is derived based on the UPU header 1508.

[0112] The authentication controller 704 of the AUSF 210 can also derive or generate an expected UE MAC (e.g., UPU-MAC-I UE )(optional step 1210), as further described in 3GPP TS 33.501 (Annex A.20). The authentication controller 704 then sends a UPU protection response message (e.g., Nausf_UPUProtection response message) to the UDM 218 (step 1212). The authentication controller 704 includes UPU security information in the UPU protection response message. The UPU security information includes the AUSF MAC generated by the AUSF 210, the UPU counter, and can optionally include the expected UE MAC. Figure 16 is a block diagram illustrating a UPU protection response message 1601 for the UPU protection service in an illustrative embodiment. The UPU protection response message 1601 includes UPU security information 1600 for the UPU protection service. The UPU security information 1600 contains material generated for protection of the UE parameter update, and includes the following attributes: an AUSF MAC attribute 1631, a UPU counter attribute 1632, and an expected UE MAC attribute 1633. The AUSF MAC attribute 1631 contains the AUSF MAC 1612. The UPU counter attribute 1632 contains the UPU counter 1616. The expected UE MAC attribute 1633 contains the expected UE MAC 1618 (XUE MAC) if the UDM 218 requests confirmation to the UE 106.

[0113] The UPU security information 1600 can have a structured data type provided for the Nausf_UPUProtection service API, as described in Section 6.3 of 3GPP TS 29.509. The Nausf_UPUProtection service API defines a “UpuSecurityInfo” data type, as described in Section 6.3.6.2.3 of 3GPP TS 29.509. The “UpuSecurityInfo” data type includes the following attributes: “upuMacIausf,” “counterUpu,” and “upuXmacIue.”

[0114] Figures 17-18 is a block diagram illustrating derivation of the AUSF MAC in an illustrative embodiment. The AUSF MAC is derived using K AUSFThe key 1704 is input to a key derivation function (KDF) 1700 to derive the AUSF MAC 1612. In one embodiment, the AUSF MAC generation function 1701 can be extended to include the UPU header 1508, as shown in Figure 17 For the AUSF MAC generation function 1701, the input parameters to the KDF 1700 are the UPU data 1504 (i.e., the UPU data list 1502), the UPU header 1508, and the UPU counter 1616. More specifically, the input parameters and their lengths are concatenated into a string S, as follows: S = FC || P0 || L0 || P1 || L1 || P2 || L2 || P3 || L3 ||... || Pn || Ln. FC is used to distinguish different instances of the algorithm. P0...Pn are n+1 input parameter encodings, and L0...Ln are two octet representations of the lengths of the corresponding input parameter encodings P0. When deriving the AUSF MAC 1612 based on the UPU header 1508 in Figure 17 The following input parameters can be used to form the string S input to the KDF 1700 when deriving the AUSF MAC 1612 based on the UPU header 1508 in - FC = 0x7B, - P0 = UPU data (i.e., the UPU data list), - L0 = length of the UPU data, - P1 = UPU counter, - L1 = length of the UPU counter, - P2 = UPU header (if the UPU header protection indication is set to true), - L2 = length of the UPU header (if the UPU header protection indication is set to true).

[0115] The AUSF MAC 1612 (e.g., UPU-MAC-I AUSF ) can be identified with the 128 least significant bits of the output of the KDF 1700. Thus, for step 1206 in Figure 12 The authentication controller 704 of the AUSF 210 can input the UPU data 1504 and the UPU header 1508 to the KDF 1700 to derive the AUSF MAC 1612 (optional step 1214) for step 1206 in Figure 17 As will be further described below, the update controller 936 of the UE 106 can input the UPU data 1504 and the UPU header 1508 to the KDF 1700 in a similar manner to derive the AUSF MAC (optional step 1420 of Figure 14A Thus, both the UPU data and the UPU header are integrity protected by the AUSF MAC generation function 1701.

[0116] For step 1208 in Figure 12 , the authentication controller 704 of the AUSF 210 can input the UPU data 1504 (without the UPU header 1508) to the KDF 1700 to derive the AUSF MAC 1612, as shown in Figure 18 . As will be further described below, in a similar manner, the update controller 936 of the UE 106 can input the UPU data 1504 (without the UPU header 1508) to the KDF 1700 to derive the AUSF MAC.

[0117] In Figure 11 , the data management controller 604 of the UDM 218 receives the UPU protection response message 1601 (e.g., a Nausf_UPUProtection response message) from the AUSF 210 (step 1114), which includes the AUSF MAC 1612 (i.e., UPU-MAC-I AUSF ) and the UPU counter 1616 (i.e., Counter UPU ). If the UPU confirmation indication 1506 is present in the UPU protection request message 1501, the UPU protection response message 1601 also includes the expected UE MAC 1618 (e.g., UPU-XMAC-I UE ). The data management controller 604 can then temporarily store the expected UE MAC 1618 (optional step 1116).

[0118] For the UPU procedure, the data management controller 604 invokes a subscriber data management (SDM) service (e.g., a Nudm_SDM_Notification service) of the UDM 218 and generates an SDM notification message (e.g., a Nudm_SDM_Notification message) (step 1118). The data management controller 604 includes the UPU information for the UE parameter update in the SDM notification message. The UPU information for the subscriber data management service (also referred to as second UPU information) can be different from the UPU information 1500 for the UPU protection service. Figure 19is a block diagram illustrating an SDM notification message 1901 for a subscriber data management service in the illustrative embodiments. The SDM notification message 1901 includes UPU information 1900. The UPU information 1900 contains the following attributes (also referred to as IEs): a UPU data list attribute 1931, a UPU re-registration indicator attribute 1932, a UPU acknowledgement indicator attribute 1933, a UPU AUSF MAC attribute 1934, and a UPU counter attribute 1935. The UPU data list attribute 1931 contains the UPU data list 1502 (i.e., the UPU data 1504). The UPU information 1900 can define updates to multiple UE parameters, and thus, the UPU data list 1502 can include a set or array of UPU data 1504. The UPU re-registration indicator attribute 1932 contains the UPU re-registration indicator 1912 indicating whether re-registration of the UE 106 is requested. The UPU acknowledgement indicator attribute 1933 contains the UPU acknowledgement indicator 1506. The UPU AUSF MAC attribute 1934 contains the AUSF MAC 1612 derived by the AUSF 210. The UPU counter attribute 1935 contains the UPU counter 1616.

[0119] The UPU information 1900 can have a structured data type provided for the Nudm_SubscriberDataManagement service API as described in Section 6.1 of 3GPP TS 29.503. The Nudm_SubscriberDataManagement service API defines a “UpuInfo” data type as described in Section 6.1.6.2.33 of 3GPP TS 29.503. The “UpuInfo” data type includes the following attributes: “upuDataList,” “upuRegInd,” “upuAckInd,” “upuMacIausf,” “counterUpu,” “provisioningTime,” and “upuTransparentContainer.”

[0120] In Figure 11 , the data management controller 604 then sends the SDM notification message 1901 to the AMF 212 (step 1120). In Figure 13In this regard, the access and mobility controller 804 of the AMF 212 receives the SDM notification message 1901 from the UDM 218 (step 1302). The access and mobility controller 804 formats or constructs a UPU transparent container (also referred to as a transparent container or UPU container) based on the UPU information 1900 in the SDM notification message 1901 (step 1304). The access and mobility controller 804 is configured to construct the UPU transparent container as described in Section 9.11.3.53A of 3GPP TS 24.501. Figure 20 is a block diagram illustrating the UPU transparent container IE 2000 in the illustrative embodiments. In a message from the network to the UE 106, the UPU transparent container IE 2000 includes a UPU transparent container IE identifier (IEI) 2002, a container length 2004, a UPU header 1508, an AUSF MAC 1612, a UPU counter 1616, and a UPU data list 1502. The access and mobility controller 804 populates the AUSF MAC 1612, the UPU counter 1616, and the UPU data list 1502 from the UPU information 1900 in the SDM notification message 1901.

[0121] In constructing the UPU transparent container IE 2000, the access and mobility controller 804 also generates the UPU header 1508 of the UPU transparent container IE 2000 according to the UPU information 1900 provided in the SDM notification message 1901. Although the SDM notification message 1901 does not convey the UPU header 1508 as described above, the access and mobility controller 804 is able to use the data conveyed in the SDM notification message 1901 to format the UPU header 1508 of the UPU transparent container IE 2000. Figure 21 is a block diagram of the UPU header 1508 of the UPU transparent container IE 2000 in the illustrative embodiments. Figure 21The format of the UPU header 1508 in the UPU transparent container IE 2000 is used to carry a transparent container of a UE parameter update list (i.e., data type "0"). The UPU header 1508 includes a UPU re- registration (REG) indicator 1912 (in bit 2 of octet 4), a UPU acknowledgement (ACK) indicator 1506 (in bit 2 of octet 4), and a UPU data type 2112 (in bit 1 of octet 4). The access and mobility controller 804 populates the UPU re-registration indicator 1912 and the UPU acknowledgement indicator 1506 from the UPU information 1900 in the SDM notification message 1901. The access and mobility controller 804 sets the UPU data type 2112 based on whether the UPU transparent container IE 2000 is sent from the network to the UE 106 or from the UE 106 to the network. For example, the access and mobility controller 804 can set the UPU data type 2112 to a value of "0" when the UPU transparent container IE 2000 carries a UPU data list 1502 from the network to the UE 106, and the access and mobility controller 804 can set the UPU data type 2112 to a value of "1" when the UPU transparent container IE 2000 carries an acknowledgement of successful receipt of the UPU data list 1502 from the UE 106 to the network.

[0122] In Figure 13 , the access and mobility controller 804 then sends a DL NAS transport message to the UE 106 with the UPU transparent container IE 2000 (step 1306), as shown in Figure 10A . In Figure 14A , the ME 900 of the UE 106 receives the DL NAS transport message from the AMF 212, which includes the UPU transparent container IE 2000 (step 1402). Upon receiving the DL NAS transport message, the update controller 936 of the UE 106 derives or computes the AUSF MAC (e.g., UPU-MAC-I AUSF ) in the same manner as the AUSF 210. When the UE 106 supports UPU header protection, the update controller 936 derives or generates the AUSF MAC (also referred to as the derived AUSF MAC) based on the UPU header 1508 (step 1404), as shown in Figure 17 . When the UE 106 does not support UPU header protection, the update controller 936 derives or generates the AUSF MAC based on the UPU data 1504 and not (i.e., without regard to) the UPU header 1508 (step 1406), as shown in Figure 18 . One technical advantage is that the UE 106 derives the AUSF MAC in the same manner as the AUSF 210.

[0123] The update controller 936 then compares the derived AUSF MAC to the received AUSF MAC 1612 received in the UPU transparent container IE 2000 to determine whether they match (step 1408). When the derived AUSF MAC and the received AUSF MAC 1612 do not match, the update controller 936 rejects the UE parameter update (step 1410). When the derived AUSF MAC and the received AUSF MAC 1612 match, the update controller 936 validates the UE parameter update (step 1412). As described herein, the UE 106 performs the validation of the “UE parameter update” by comparing the derived AUSF MAC to the received AUSF MAC. However, it should be appreciated that this comparison provides validation of the data that is MAC integrity protected (i.e., the data used in generating the MAC, such as the UPU data). When the validation of the AUSF MAC 1612 is successful, the update controller 936 updates one or more configuration parameters of the ME 900 and / or the USIM 960 based on the UPU data 1504 (step 1414). If the UPU data 1504 contains configuration parameters that are secured packet protected, the ME 900 of the UE 106 forwards the secured packet to the USIM 960. When the validation of the AUSF MAC 1612 is successful and the UPU data 1504 contains configuration parameters that are not secured packet protected, the ME 900 of the UE 106 updates its stored parameters with the received parameters in the UPU data.

[0124] If the UDM 218 has requested confirmation from the UE 106, and the UE 106 has successfully validated and updated the UPU data 1504 provided by the UDM 218, the update controller 936 derives or generates a UE MAC (e.g., UPU-MAC-I UE )(optional step 1416) based on the UPU confirmation indicator 1506 in the same manner that the AUSF 210 derives the expected UE MAC 1618. The UE 106 then sends an UL NAS transport message (optional step 1418) to the AMF 212, such as the UL NAS transport message 1016 shown in Figure 10A The UE 106 includes the UE MAC in a transparent container in the UL NAS transport message. Figure 22 is a block diagram illustrating a UPU transparent container IE 2200 in an illustrative embodiment. In a message from the UE 106 to the network, the UPU transparent container IE 2200 includes a UPU transparent container IEI 2202 generated by the UE 106, a container length 2204, the UPU header 1508, and the UE MAC 2208.

[0125] In Figure 13In some embodiments, the access and mobility controller 804 of the AMF 212 receives the UL NAS transport message from the UE 106 (optional step 1308). The access and mobility controller 804 invokes the subscriber data management service (i.e., Nudm_SDM_Info service) of the UDM 218 to provide the UDM 218 with confirmation from the UE 106 of successful delivery of the UPU data 1504. The access and mobility controller 804 sends the SDM information message to the UDM 218 with the UE MAC 2208 (e.g., as Figure 10A the Nudm_SDM_Info message 1014 in

[0126] In Figure 11 some embodiments, the data management controller 604 of the UDM 218 receives the SDM information message from the AMF 212 (optional step 1122). If the UDM 218 indicates that the UE 106 is to confirm successful security check of the received UPU data 1504, the UDM 218 compares the received UE MAC 2208 derived by the UE 106 with the expected UE MAC 1618 temporarily stored by the UDM 218. If the received UE MAC 2208 and the expected UE MAC 1618 match, the data management controller 604 verifies the success of the UE parameter update (optional step 1124).

[0127] As described above, the UE 106 can provide the network with the UPU header protection indicator 1003 indicating whether the UE 106 supports UPU header protection prior to the network initiating the UE parameter update. Figure 14B is a flow diagram illustrating additional details of the method 1100 in the illustrative embodiments. As described above, the UE 106 supports UPU header protection when the UE 106 is configured to derive the AUSF MAC 1612 based at least in part on the UPU header 1508 (e.g., UPU-MAC-I AUSF ). For example, the UE 106 can be configured to derive the AUSF MAC 1612 as shown in Figure 17 In one embodiment, the update controller 936 of the UE 106 signals to the network that it supports UPU header protection with the UPU header protection indicator 1003. Accordingly, the update controller 936 inserts the UPU header protection indicator 1003 into a control plane message directed to the 5GC 104 (optional step 1422). The update controller 936 then sends the control plane message to the AMF 212 (optional step 1424). In one embodiment, the UE 106 can insert the UPU header protection indicator 1003 into an initial NAS message to a serving network (e.g., the AMF 212 of the serving network) (optional step 1426), asFigure 3 The N1 message 311 illustrated. One example of the N1 message 311 is a registration request provided during primary authentication of the UE 106, and the UE 106 can insert the UPU header protection indicator 1003 (optional step 1428) in the registration request. One technical advantage is that the UE 106 is able to signal to the network that it supports UPU header protection, such as during primary authentication. However, the UE 106 can signal to the network that it supports UPU header protection in other ways.

[0128] One technical advantage of the UE parameter update procedure as described above for the method 1100 is that current data structures defined by 3GPP can be used for the UE parameter update procedure, but the use of the UPU header 1508 is defined. The UDM 218 is able to request the AUSF 210 to derive the AUSF MAC based on the UPU header 1508 using the UPU header protection indicator 1003 in the UPU protection request message. Thus, when the UE 106 is configured to support UPU header protection, the AUSF 210 derives the AUSF MAC based on the UPU header 1508, and the UE 106 performs a similar derivation. When the UE 106 does not support UPU header protection, the AUSF 210 derives the AUSF MAC based on the UPU data 1504 instead of the UPU header 1508, and the UE 106 performs a similar derivation. Thus, even though the UPU header 1508 is optional, the AUSF 210 and the UE 106 will derive the AUSF MAC in a similar manner so that the UE parameter update can be verified. Example 2

[0129] Figure 23A is a message diagram illustrating the UE parameter update procedure in the illustrative embodiment. Figure 23A The UE parameter update procedure described in the foregoing can be an extension to section 6.15.2.1 of 3GPP TS 33.501. As a general overview, the AUSF 210 can additionally derive an enhanced AUSF MAC (i.e., enhanced UPU-MAC-I AUSF ) based on the UPU header. In the present embodiment, the AUSF MAC that is not derived based on the UPU header is referred to as a regular AUSF MAC (i.e., UPU-MAC-I AUSF), and the AUSF MAC derived based on the UPU header is referred to as an enhanced AUSF MAC. The regular AUSF MAC and the enhanced AUSF MAC can then be passed to the UE 106 along with the UPU data. If the UE 106 does not support UPU header protection, the UE 106 can not derive the regular AUSF MAC based on the UPU header for verification. If the UE 106 supports UPU header protection, the UE 106 can derive the enhanced AUSF MAC based on the UPU header for verification. One technical advantage is that the UPU header, and any other UPU information (e.g., UPU data) used to derive the enhanced AUSF MAC, can be protected in the UE parameter update. If the UE 106 does not support UPU header protection, the UE 106 can derive the regular AUSF MAC for verification. Thus, existing UEs can still perform the UE parameter update based on the UPU data without breaking backward compatibility, so that both existing UEs and new UEs can work when this feature is deployed.

[0130] In one embodiment, the UDM 218 decides to perform a UE parameter update (UPU) using a control plane procedure at the time of UE 106 registration to the 5G system 100. If the end consumer of any UE parameter to be updated (e.g., updated RID) is the USIM 960 of the UE 106, the UDM 218 uses a secure grouping mechanism to update the parameters stored on the USIM 960 to protect these parameters. The UDM 218 prepares the UPU data by including the parameters protected by secure grouping, if any, and any UE parameter for which the end consumer is the ME 900 of the UE 106.

[0131] The UDM 218 invokes the Nausf_UPUProtection service by sending a Nausf_UPUProtection request message 2311 to the AUSF 210 to obtain a UPU-MAC-I AUSF and Counter UPU The UDM 218 includes the SUPI, the UPU data, and the UPU header in the Nausf_UPUProtection request message 2311. If the UDM 218 decides that the UE 106 acknowledges successful security check on the received UPU data, the UDM 218 sets a corresponding indication in the UPU data and includes an ACK indication in the Nausf_UPUProtection request message 2311 to signal that it also needs to expect a UPU-XMAC-I UE .

[0132] The AUSF 210 uses a UE specific home key (KAUSF ) computing or deriving a UPU-MAC-I AUSF and delivering the UPU-MAC-I AUSF and Counter UPU to the UDM 218. Including the UPU data in the computation of the UPU-MAC-I AUSF integrity can protect the UPU data and allow the UE 106 to verify that the UPU data has not been tampered with by any intermediary. In one embodiment, the AUSF 210 also computes or derives an enhanced UPU-MAC-I AUSF 2303 based at least in part on the UPU header, and returns the enhanced UPU-MAC-I AUSF 2303 in the Nausf_UPUProtection response message 2312. Including the UPU header in the computation of the enhanced UPU-MAC-I AUSF 2303 can protect the UPU header and allow the UE 106 to verify that the UPU header has not been tampered with by any intermediary. If an ACK indication is present in the Nausf_UPUProtection request message 2311, the AUSF 210 computes or derives a UPU-XMAC-I UE and returns the computed UPU-XMAC-I UE in the Nausf_UPUProtection response message 2312. The UPU-XMAC-I UE allows the UDM 218 to verify that the UE 106 correctly received the UPU data.

[0133] The UDM 218 then invokes the Nudm_SDM_Notification service operation and sends the Nudm_SDM_Notification message 2313 to the AMF 212, which includes the UPU transparent container if the AMF 212 supports the UPU transparent container, or includes individual information elements (IEs) that include the UPU data, the UPU-MAC-I AUSF , the enhanced UPU-MAC-I AUSF 2303, and the Counter UPU . If the UDM 218 requests an acknowledgement, it temporarily stores the expected UPU-XMAC-I UEOn receiving the Nudm_SDM_Notification message 2313, the AMF 212 sends a DL NAS transport message 2314 to the UE 106. If received from the UDM 218, the AMF 212 includes the transparent container in the DL NAS transport message 1014. Otherwise, if the UDM 218 provides individual IEs, the AMF 212 constructs the UPU container.

[0134] If the UE 106 does not support UPU header protection, and on receiving the DL NAS transport message 2314, the UE 106 computes the UPU-MAC-I UPU in the same way as the AUSF 210 AUSF and verifies whether it matches the UPU-MAC-I AUSF value received in the DL NAS transport message 2314. If the UE 106 supports UPU header protection, and on receiving the DL NAS transport message 2314, the UE 106 computes the enhanced UPU-MAC-I UPU in the same way as the AUSF 210 AUSF based on the received UPU data, Counter AUSF and UPU header, and verifies whether it matches the enhanced UPU-MAC-I AUSF value received in the DL NAS transport message 2314. If the verification of the UPU-MAC-I AUSF or enhanced UPU-MAC-I AUSF is successful, and the UPU data contains any parameters protected by a security packet, the ME 900 of the UE 106 forwards the security packet to the USIM 960. If the verification of the UPU-MAC-I AUSF or enhanced UPU-MAC-I UE is successful, and the UPU data contains any parameters not protected by a security packet, the ME 900 of the UE 106 updates its stored parameters with the received parameters in the UPU data.

[0135] If the UDM 218 has requested confirmation from the UE 106, and the UE 106 has successfully verified and updated the UPU data provided by the UDM 218, the UE 106 sends an UL NAS transport message 2315 to the serving AMF 212. The UE 106 generates the UPU-MAC-I UE and includes the generated UPU-MAC-I UENudm_SDM_Info message 2316. If it has UPU-MAC-I UE If the transparent container is received in UL NAS transmission message 2315, then AMF 212 sends Nudm_SDM_Info message 2316 with the transparent container to UDM 218. If UDM 218 instructs UE 106 to confirm the successful security check of the received UPU data, then UDM 218 will send the received UPU-MAC-I UE Expected UPU-XMAC-I with UDM 218 temporary storage UE A comparison was made to verify that UE106 successfully received UPU data.

[0136] In order to enhance the UPU-MAC-I AUSF 2303 is provided from AUSF 210 to UDM 218 and can extend UPU protection services (e.g., Nausf_UPUProtection service). Figure 23B The illustration depicts an extension 2350 to the Nausf_UPUProtection service in an illustrative embodiment to include enhanced UPU-MAC-I. AUSF 2303. As described in Section 14.1.4 of 3GPP TS 33.501, the Nausf_UPUProtection service specifies the following as required output: UPU-MAC-I AUSF and Counter UPU Or an error. In one embodiment, the extension 2350 of the Nausf_UPUProtection service provides enhanced UPU-MAC-I. AUSF 2303 serves as the required output 2352. One technical advantage is that the AUSF 210 is able to report the enhanced UPU-MAC-I to the UDM 218. AUSF 2303.

[0137] Figures 24-27 This is a flowchart illustrating a method 2400 for performing a UE parameter update process in an illustrative embodiment. More specifically, reference will be made to... Figure 6 UDM 218 in the description Figure 24 The steps in method 2400 will be referenced. Figure 7 AUS F210 is used to describe Figure 25 The steps in method 2400 will be referenced. Figure 8 AMF 212 in the description Figure 26 The steps of method 2400 in the document will be referenced. Figure 9 UE 106 is used to describe Figure 27the steps of the method 24000 in FIG. 24. Those skilled in the art will understand that the method 2400 can be performed in other systems, devices, or network functions.

[0138] In Figure 24 In the method 2400, the data management controller 604 of the UDM 218 triggers a UE parameter update (UPU) procedure for the UE 106 (step 2402), such as for RID update, NSSAI update, etc. In other words, when the UE 106 registers to the 5G system 100, the data management controller 604 decides to perform the UE parameter update using a control plane procedure. Upon triggering the UE parameter update procedure, the data management controller 604 invokes a UPU protection service (e.g., Nausf_UPUProtection) to the AUSF 210 and generates a UPU protection request message (e.g., Nausf_UPUProtection Request message) (step 2404). The data management controller 604 of the UDM 218 is configured to include, in the UPU protection request message (e.g., UPU data and UPU header), the SUPI for the UE 106 and the UPU information (also referred to as first UPU information) for the UE parameter update. Figure 28 FIG. 28 is a block diagram illustrating a UPU protection request message 2801 for the UPU protection service in the illustrative embodiments. The UPU protection request message 2801 includes UPU information 2800 (also referred to as first UPU information) for the UPU protection service. In Figure 28 In the method 2400, the data management controller 604 of the UDM 218 triggers a UE parameter update (UPU) procedure for the UE 106 (step 2402), such as for RID update, NSSAI update, etc. In other words, when the UE 106 registers to the 5G system 100, the data management controller 604 decides to perform the UE parameter update using a control plane procedure. Upon triggering the UE parameter update procedure, the data management controller 604 invokes a UPU protection service (e.g., Nausf_UPUProtection) to the AUSF 210 and generates a UPU protection request message (e.g., Nausf_UPUProtection Request message) (step 2404). The data management controller 604 of the UDM 218 is configured to include, in the UPU protection request message (e.g., UPU data and UPU header), the SUPI for the UE 106 and the UPU information (also referred to as first UPU information) for the UE parameter update. Figure 24 In the method 2400, the data management controller 604 of the UDM 218 triggers a UE parameter update (UPU) procedure for the UE 106 (step 2402), such as for RID update, NSSAI update, etc. In other words, when the UE 106 registers to the 5G system 100, the data management controller 604 decides to perform the UE parameter update using a control plane procedure. Upon triggering the UE parameter update procedure, the data management controller 604 invokes a UPU protection service (e.g., Nausf_UPUProtection) to the AUSF 210 and generates a UPU protection request message (e.g., Nausf_UPUProtection Request message) (step 2404). The data management controller 604 of the UDM 218 is configured to include, in the UPU protection request message (e.g., UPU data and UPU header), the SUPI for the UE 106 and the UPU information (also referred to as first UPU information) for the UE parameter update.

[0139] In Figure 25In this case, the authentication controller 704 of the AUSF 210 receives the UPU protection request message 2801 from the UDM 218 (step 2502). The authentication controller 704 derives or generates a regular AUSF MAC (also referred to as a first MAC) based on the UPU data 2804 but not the UPU header 2808 (step 2504). In one embodiment, the authentication controller 704 also derives or generates an enhanced AUSF MAC 2303 (also referred to as a second MAC) based on the UPU header 2808 (step 2506). For example, the authentication controller 704 can decide to derive the enhanced AUSF MAC 2303 as well as the regular AUSF MAC based on operator policy. In another example, the authentication controller 704 can receive some type of indicator or instruction from the UDM 218 on when to derive the enhanced AUSF MAC 2303. The authentication controller 704 can also derive or generate an expected UE MAC (e.g., UPU-XMAC-I UE )(optional step 2508).

[0140] The authentication controller 704 then sends a UPU protection response message (e.g., Nausf_UPUProtection response message) to the UDM 218 (step 2510). The authentication controller 704 includes the UPU security information in the UPU protection response message. The UPU security information includes the regular AUSF MAC and the enhanced AUSF MAC 2303 generated by the AUSF 210, UPU counter, and can optionally include the expected UE MAC. Figure 29 FIG. 29 is a block diagram illustrating a UPU protection response message 2901 for the UPU protection service in the illustrative embodiments. The UPU protection response message 2901 includes UPU security information 2900 for the UPU protection service. The UPU security information 2900 contains material generated for protection of the UE parameter update, and includes the following attributes: AUSF MAC attribute 2931, enhanced AUSF MAC attribute 2932, UPU counter attribute 2933, and expected UE MAC attribute 2934. The AUSF MAC attribute 2931 contains the regular AUSF MAC 2912. The enhanced AUSF MAC attribute 2932 contains the enhanced AUSF MAC 2303. The UPU counter attribute 2933 contains the UPU counter 2916. The expected UE MAC attribute 2934 contains the expected UE MAC 2918 (XUE MAC) if the UDM 218 requests confirmation from the UE 106. One technical advantage of deriving these two MACs is that a UE 106 that supports UPU header protection or a UE 106 that does not support UPU header protection is able to verify the UE parameter update.

[0141] InFigure 25 In step 2504, the authentication controller 704 derives the regular AUSF MAC 2912 based on the UPU data 2804 instead of the UPU header 2808. Figure 30 This is a block diagram illustrating the derivation of the conventional AUSF MAC 2912 in an illustrative embodiment. In the AUSF MAC generation function 3001, K is used... AUSF Key 3004 is used as the input key to derive a standard AUSFMAC 2912 from the KDF 3000. When based on... Figure 30 When exporting UPU data 2804 to a regular AUSF MAC 2912, the following input parameters can be used to form the string S input to the KDF 3000: - FC=0x7B, - P0=UPU data, - L0 = the length of the UPU data. - P1 = UPU counter, - L1 = the length of the UPU counter.

[0142] Therefore, UPU data is protected for integrity using the AUSF MAC generation function 3001.

[0143] exist Figure 25 In step 2506, the authentication controller 704 derives the enhanced AUSF MAC 2303 based on the UPU header 2808. Figure 31 This is a block diagram illustrating the derivation of the enhanced AUSF MAC 2303 in an illustrative embodiment. In one embodiment, an enhanced AUSF MAC generation function 3101 is described, which includes a UPU header 2808. The enhanced AUSF MAC generation function 3101 may be an extension to 3GPP TS 33.501 (e.g., Annex A.19a). When based on Figure 31 When exporting the enhanced AUSF MAC 2303 using the UPU header 2808 in the KDF 3000, the following input parameters can be used to form the string S input to the KDF 3000: - FC=0x7B, - P0 = UPU data (i.e., a list of UPU data). - L0 = the length of the UPU data. - P1 = UPU counter, - L1 = the length of the UPU counter, - P2=UPU header, - L2 = Length of the UPU header.

[0144] The enhanced AUSF MAC 2303 (e.g., enhanced UPU-MAC-I AUSF ) can be identified using the 128 least significant bits of the output of the KDF 3000. Thus, both the UPU data and the UPU header are integrity protected by the AUSF MAC generation function 3101.

[0145] For step 2506 in Figure 25 , the authentication controller 704 of the AUSF 210 can input the UPU data 2804 and the UPU header 2808 (and the UPU counter 2916) as input parameters to the KDF 3000 to derive the enhanced AUSF MAC 2303 (optional step 2530). As will be further described below, in a similar manner, the update controller 936 of the UE 106 can input the UPU data 2804 and the UPU header 2808 as input parameters to the KDF 3000 to derive the enhanced AUSF MAC (optional step 2730) of Figure 27 ).

[0146] In Figure 24 , the data management controller 604 of the UDM 218 receives the UPU protection response message 2901 (e.g., Nausf_UPUProtection response message) from the AUSF 210 (step 2408), which includes the regular AUSF MAC 2912, the enhanced AUSF MAC 2303, and the UPU counter 2916. If the UPU confirmation indicator 2806 was present in the UPU protection request message 2801, the UPU protection response message 2901 also includes the expected UE MAC 2918. The data management controller 604 can then temporarily store the expected UE MAC 2918 (optional step 2410).

[0147] For the UPU procedure, the data management controller 604 invokes a subscriber data management (SDM) service (e.g., Nudm_SDM_Notification service) of the UDM 218 and generates an SDM notification message (e.g., Nudm_SDM_Notification message) (step 2412). The data management controller 604 of the UDM 218 is configured to include the UPU information (also referred to as second UPU information) for the UE parameter update in the SDM notification message. In one embodiment, the UPU information is enhanced with the enhanced UPU information in the subscriber data management service. Figure 32is a block diagram illustrating an SDM notification message 3201 for a subscriber data management service in an illustrative embodiment. The SDM notification message 3201 includes UPU information 3200. The UPU information 3200 includes the following attributes: a UPU data list attribute 3231, a UPU re-registration indicator attribute 3232, a UPU confirmation indicator attribute 3233, an AUSF MAC attribute 3234, a UPU counter attribute 3235, and an enhanced UPU information attribute 3236. The UPU data list attribute 3231 contains the UPU data list 2802 (i.e., the UPU data 2804). The UPU re-registration indicator attribute 3232 contains the UPU re-registration indicator 3212 indicating whether re-registration of the UE 106 is requested. The UPU confirmation indicator attribute 3233 contains the UPU confirmation indicator 2806. The AUSF MAC attribute 3234 contains the regular AUSF MAC 2912 derived by the AUSF 210. The UPU counter attribute 3235 contains the UPU counter 2916. The enhanced UPU information attribute 3236 contains the enhanced AUSF MAC 2303 derived by the AUSF 210.

[0148] In Figure 24 , the data management controller 604 of the UDM 218 includes the regular AUSF MAC 2912 and the enhanced AUSF MAC 2303 in the SDM notification message 3201 (step 2414). The data management controller 604 then sends the SDM notification message 3201 to the AMF 212 (step 2416).

[0149] In Figure 26 , the access and mobility controller 804 of the AMF 212 receives the SDM notification message 3201 (e.g., Nudm_SDM_Notification message) from the UDM 218 (step 2602). In response to the SDM notification message, the access and mobility controller 804 formats or constructs a regular UPU transparent container (also referred to as a first UPU transparent container) based on the UPU information 3200 that includes at least the UPU data 2804, the UPU header 2808, and the regular AUSF MAC 2912 (step 2604). The “regular” UPU transparent container construction is as described in 3GPP TS 24.501 Section 9.11.3.53A. Figure 33is a block diagram illustrating a regular UPU transparent container IE 3300 in the illustrative embodiments. In a message from the network to the UE 106, the regular UPU transparent container IE 3300 includes a UPU transparent container IEI 3302, a container length 3304, a UPU header 2808, a regular AUSF MAC 2912, a UPU counter 2916, and a UPU data list 2802. The access and mobility controller 804 populates the regular AUSF MAC 2912, the UPU counter 2916, and the UPU data list 2802 from the UPU information 3200 in the SDM notification message 3201.

[0150] In Figure 26 the access and mobility controller 804 formats or constructs an enhanced UPU transparent container (also referred to as a second UPU transparent container) based on the UPU information 3200 including at least the enhanced AUSF MAC 2303 (step 2606). Figure 34 is a block diagram illustrating an enhanced UPU transparent container IE 3400 in the illustrative embodiments. In one embodiment, the enhanced UPU transparent container IE 3400 can have the same format as the regular UPU transparent container IE 3300 in Figure 33 In a message from the network to the UE 106, the enhanced UPU transparent container IE 3400 includes an enhanced UPU transparent container IEI 3402, a container length 3404, a UPU header 2808, an enhanced AUSF MAC 2303, a UPU counter 2916, and a UPU data list 2802. In Figure 26 In

[0151] In Figure 27 the ME 900 of the UE 106 receives the DL NAS transport message from the AMF 212 (step 2702). Upon receiving the DL NAS transport message, the update controller 936 derives or computes the AUSF MAC or the enhanced AUSF MAC in the same manner as the AUSF 210. When the UE 106 supports UPU header protection, the update controller 936 derives or computes the enhanced AUSF MAC (also referred to as the derived enhanced AUSF MAC or third MAC) based on the UPU header 2808 (step 2704). For example, the update controller 936 can input the UPU data 2804 and the UPU header 2808 as input parameters into the KDF 3000 to generate the enhanced AUSF MAC (optional step 2730), as illustrated in Figure 31The derived enhanced AUSF MAC is then compared by the update controller 936 to the received enhanced AUSF MAC 2303 received in the enhanced UPU transparent container IE 3400 (step 2706).

[0152] When the UE 106 does not support UPU header protection, the update controller 936 derives or generates a regular AUSF MAC (also referred to as the derived regular AUSF MAC or fourth MAC) based on the UPU data 2804 and not (i.e., without regard to) the UPU header 2808 (step 2708). For example, the update controller 936 can derive or generate the regular AUSF MAC based on the UPU data 2804 and not the UPU header 2808 as shown in FIG. 27B. Figure 30 The derived regular AUSF MAC is then compared by the update controller 936 to the received regular AUSF MAC 2912 received in the regular UPU transparent container IE 3300 to determine whether they match (step 2710).

[0153] When the derived MAC and the received MAC do not match, the update controller 936 rejects the UE parameter update (step 2712). When the derived MAC and the received MAC match, the update controller 936 validates the UE parameter update (step 2714). When the validation is successful, the update controller 936 updates one or more configuration parameters of the ME 900 and / or the USIM 960 based on the UPU data 2804 (step 2716), such as provided in the regular UPU transparent container IE 3300. If the UPU data 2804 contains configuration parameters protected by a security packet, the ME 900 of the UE 106 forwards the security packet to the USIM 960. When the validation is successful and the UPU data 2804 contains configuration parameters not protected by a security packet, the ME 900 of the UE 106 updates its stored parameters with the received parameters in the UPU data.

[0154] If the UDM 218 has requested confirmation from the UE 106 and the UE 106 has successfully validated and updated the UPU data 2804 provided by the UDM 218, the update controller 936 derives or generates a UE MAC (e.g., UPU-MAC-I UE ) based on the UPU confirmation indicator 2806 in the same manner as the AUSF 210 derives the expected UE MAC 2918 (optional step 2718). The UE 106 then sends an UL NAS transport message to the AMF 212 (optional step 2720). The UE 106 includes the UE MAC in a transparent container in the UL NAS transport message. Figure 35is a block diagram illustrating a UPU transparent container IE 3500 in the illustrative embodiments. In a message from the UE 106 to the network, the UPU transparent container IE 3500 includes a UPU transparent container IEI 3502 generated by the UE 106, a container length 3504, a UPU header 2808, and a UE MAC 3508.

[0155] In Figure 26 , the access and mobility controller 804 of the AMF 212 receives the UL NAS transport message from the UE 106 (optional step 2610). The access and mobility controller 804 invokes the subscriber data management service (e.g., Nudm_SDM_Info service) of the UDM 218 to provide the UDM 218 with confirmation from the UE 106 regarding successful delivery of the UPU data 2804. The access and mobility controller 804 sends an SDM information message (e.g., Nudm_SDM_Info message) to the UDM 218 with the UE MAC 3508 (optional step 2612).

[0156] In Figure 24 , the data management controller 604 of the UDM 218 receives the SDM information message from the AMF 212 (optional step 2418). If the UDM 218 indicates that the UE 106 is to confirm successful security check of the received UPU data 2804, the UDM 218 compares the received UE MAC 3508 derived by the UE 106 with the expected UE MAC 2918 temporarily stored by the UDM 218. If the received UE MAC 3508 and the expected UE MAC 2918 match, the data management controller 604 verifies the success of the UE parameter update (optional step 2420).

[0157] One technical advantage of the UE parameter update procedure of the method 2400 as described above is that the use of the UPU header is defined for derivation of an enhanced AUSF MAC (e.g., enhanced UPU-MAC-I AUSF ). For example, the AUSF 210 derives an enhanced AUSF MAC and a regular AUSF MAC based on the UPU header. Both the enhanced AUSF MAC and the regular AUSF MAC are provided to the UE 106. Thus, the AUSF 210 and the UE 106 can derive or compute the regular AUSF MAC or the enhanced AUSF MAC in the same way, such that the UE parameter update can be verified.

[0158] In Figure 29In this document, UPU security information 2900 may have a structured data type provided for the Nausf_UPU Protection Service API, as described in Section 6.3 of 3GPP TS 29.509. In one embodiment, the enhanced AUSF MAC attribute 2932 is an extension of the structured data type of UPU security information 2900. In one embodiment, a revision or extension of the “UpuSecurityInfo” data type in Section 6.3.6.2.3 of 3GPP TS 29.509 is provided herein. Figure 36 The illustration shows the "UpuSecurityInfo" data type 3600 for modifications to the Nausf_UPU Protection Service API in an illustrative embodiment. As described in 6.3.6.2.3 of 3GPP TS 29.509, the modified "UpuSecurityInfo" data type 3600 for the Nausf_UPU Protection Service API includes the following attributes: "upuMacIausf", "counterUpu", and "upuXmacIue". Furthermore, the modified "UpuSecurityInfo" data type 3600 also includes the "enhancedUpuMacIausf" attribute 3602, as an extension of the "UpuSecurityInfo" data type in section 6.3.6.2.3 of 3GPP TS 29.509. The "enhancedUpuMacIausf" attribute 3602 is of type "UpuMac" and is... Figure 29 An example of the enhanced AUSF MAC attribute 2932 described in [the document / reference].

[0159] exist Figure 32 In this document, UPU information 3200 may have a structured data type provided for the Nudm_SubscriberDataManagement service API, as described in Section 6.1 of 3GPP TS 29.503. In one embodiment, enhanced UPU information attribute 3236 is an extension of the structured data type of UPU information 3200. In one embodiment, a revision or extension of the “UpuInfo” data type in Section 6.1.6.2.33 of 3GPP TS 29.503 is provided herein. Figure 37A modified "UpuInfo" data type 3700 for the Nudm_SubscriberDataManagement service API in the illustrative embodiments is illustrated. As described in 3GPP TS 29.503 section 6.1.6.2.33, the modified "UpuInfo" data type 3700 for the Nudm_SubscriberDataManagement service API includes the following attributes: "upuDataList", "upuRegInd", "upuAckInd", "upuMacIausf", "counterUpu", "provisioningTime", and "upuTransparentContainer". In addition, the modified "UpuInfo" data type 3700 also includes an "enhancedUpuMacIausf" attribute 3702 as an extension of the "UpuInfo" data type in 3GPP TS 29.503 section 6.1.6.2.33. The "enhancedUpuMacIausf" attribute 3702 is of type "UpuMac" and is Figure 32 An example of the enhanced UPU information attribute 3236 described in the middle.

[0160] In one embodiment, the UDM 218 can signal to the AUSF 210 when to derive the enhanced AUSF MAC 2303 in addition to the regular AUSF MAC 2912. Figures 38-39 is a flow diagram illustrating additional details of the method 2400 in the illustrative embodiments. In Figure 38In this process, the data management controller 604 of the UDM 218 determines whether or not to implement UPU header protection (step 3822). When UPU header protection is implemented, the data management controller 604 of the UDM 218 includes or inserts a UPU header protection indication in the UPU protection request message 2801 (step 3824). Including the UPU header protection indication in this way requests the AUSF 210 to derive an enhanced AUSF MAC 2303. For example, the data management controller 604 may insert or include enhanced UPU information in the UPU protection request message 2801 (optional step 3828). In another example, the data management controller 604 may insert or include an enhanced UPU indicator in the UPU protection request message 2801 (optional step 3830). When UPU header protection is not implemented, the data management controller 604 of the UDM 218 may omit or exclude the UPU header protection indication from the UPU protection request message 2801 (step 3826). Then, the data management controller 604 sends a UPU protection request message 2801 to the AUSF 210 (step 2406), and method 2400 as follows: Figure 24 Continuing as shown. One technical advantage is that the UDM 218 can request the AUSF 210 to derive the enhanced AUSF MAC 2303 according to the UPU header protection instruction.

[0161] exist Figure 39 In, such as Figure 25 As shown, the authentication controller 704 of AUSF 210 receives a UPU protection request message 2801 from UDM 218 (step 2502), and derives or generates a regular AUSF MAC 2912 based on the UPU data 2804 instead of the UPU header 2808 (step 2504). The authentication controller 704 determines whether the UPU protection request message 2801 includes a UPU header protection indication (step 3912). Figure 40 This is a block diagram illustrating a UPU protection request message 2801 for a UPU protection service in another illustrative embodiment. The UPU protection request message 2801 includes UPU information 4000 for the UPU protection service. Figure 40 In the UPU information 4000, the following attributes are included: UPU data list attribute 4031, UPU acknowledgment indicator attribute 4032, UPU header attribute 4033, and UPU header protection indicator attribute 4034. The UPU header protection indicator attribute 4034 includes a UPU header protection indicator 4006. In one embodiment, the UPU header protection indicator 4006 may include enhanced UPU information 4010. In another embodiment, the UPU header protection indicator 4006 may include an enhanced UPU indicator 4012.

[0162] exist Figure 39When the UPU protection request message 2801 includes the UPU header protection indication 4006, the authentication controller 704 derives or generates the enhanced AUSF MAC 2303 based on the UPU header 2808 (step 2506). When the UPU protection request message 2801 does not include the UPU header protection indication 4006, the authentication controller 704 skips deriving the enhanced AUSF MAC 2303. The method 2400 can then continue as described in Figure 25

[0163] In Figure 40 In one embodiment, the UPU information 4000 can have a structured data type provided for the Nausf_UPUProtection service API, as described in Section 6.3 of 3GPP TS 29.509. In one embodiment, the UPU header protection indication attribute 4034 is an extension to the structured data type of the UPU information 4000. In one embodiment, a revision or extension to the “UpuInfo” data type in Section 6.3.6.2.2 of 3GPP TS 29.509 is provided herein. Figure 41 A modified “UpuInfo” data type 4100 for the Nausf_UPUProtection service API in an illustrative embodiment is shown. As described in 6.3.6.2.2 of 3GPP TS 29.509, the modified “UpuInfo” data type 4100 for the Nausf_UPUProtection service API includes the following attributes: “upuDataList”, “upuHeader”, “upuAckInd”, “supportedFeatures”, and “upuTransparentInfo”. In addition, the modified “UpuInfo” data type 4100 further includes an “enhancedUpuInfo” attribute 4102 as an extension to the “UpuInfo” data type in Section 6.3.6.2.2 of 3GPP TS 29.509. The “enhancedUpuInfo” attribute 4102 is of type “enhancedUpuInfo” and can include any UPU information as needed.

[0164] Figure 42A A “enhancedUpuInfo” data type 4200 for the Nausf_UPUProtection service API in an illustrative embodiment is shown. As described in 6.3.6.2.2 of 3GPP TS 29.509, the “enhancedUpuInfo” data type 4200 includes the following attributes: “upuDataList”, “upuHeader”, “upuAckInd”, “supportedFeatures”, and “upuTransparentInfo”. In addition, the “enhancedUpuInfo” data type 4200 further includes an “upuHeaderProtectionInd” attribute 4202 as an extension to the “UpuInfo” data type in Section 6.3.6.2.2 of 3GPP TS 29.509. The “upuHeaderProtectionInd” attribute 4202 is of type “UPUHeaderProtectionInd” and can include any UPU header protection indication as needed. Figure 42A ​In this embodiment, the "enhancedUpInfo" data type 4200 includes the following attributes: "upuDataList" 4202 and "upuHeader" 4204. The "upuDataList" attribute 4202 includes an array of "UpuData" as specified in 3GPP TS 29.509 section 6.3.6.2.4. The "upuHeader" attribute 4204 is mandatory in this embodiment and contains the "UPU Header" IE as specified in 3GPP TS 24.501 section 9.11.3.53A. Figure 42B Figure 2 illustrates the "enhancedUpuInfo" data type 4200 for the Nausf_UPU Protection service API in an illustrative embodiment. In this embodiment, the "enhancedUpuInfo" data type 4200 includes the following attributes: "upuDataList" 4202 and "upuHeader" 4204. The "upuDataList" attribute 4202 includes an array of "UpuData" as specified in 3GPP TS 29.509 section 6.3.6.2.4. The "upuHeader" attribute 4204 is mandatory in this embodiment and contains the "UPU Header" IE as specified in 3GPP TS 24.501 section 9.11.3.53A. Figure 42B In this embodiment, the "enhancedUpuInfo" data type 4200 includes the following attribute: "upuHeader" 4204. The "upuHeader" attribute 4204 is mandatory in this embodiment and contains the "UPU Header" IE as specified in 3GPP TS 24.501 section 9.11.3.53A. As discussed above, the "enhancedUpuInfo" data type 4200 can be added to 3GPP TS 29.509 section 6.3.6.2.2. In addition, the "enhancedUpuInfo" data type 4200 can replicate the "UpuInfo" data format in 3GPP TS 29.509 section 6.3.6.2.2, unless the "upuHeader" attribute 4204 is mandatory. Figure 42A and / or Figure 42B The "enhancedUpuInfo" data type 4200 as shown can be added to 3GPP TS 29.509 section 6.3. In addition, the "enhancedUpuInfo" data type 4200 can replicate the "UpuInfo" data format in 3GPP TS 29.509 section 6.3.6.2.2, unless the "upuHeader" attribute 4204 is mandatory.

[0165] Figure 43Figure illustrates another modification of the "UpuInfo" data type 4300 for the Nausf_UPU Protection service API in the illustrative embodiments. As described in 3GPP TS 29.509 section 6.3.6.2.2, the modified "UpuInfo" data type 4300 for the Nausf_UPU Protection service API includes the following attributes: "upuDataList", "upuHeader", "upuAckInd", "supportedFeatures", and "upuTransparentInfo". In addition, the modified "UpuInfo" data type 4300 also includes an "enhancedUpuIndicator" attribute 4302 as an extension of the "UpuInfo" data type in 3GPP TS 29.509 section 6.3.6.2.2. The "enhancedUpuIndicator" attribute 4302 is of type "enhancedUpuIndicator" and indicates whether UPU header protection is implemented. Example 3

[0166] Figure 44 is a message diagram illustrating a UE parameter update procedure in the illustrative embodiments. Figure 44 The UE parameter update procedure described in Figure can be an extension to 3GPP TS 33.501 section 6.15.2.1. In one example, the UDM 218 decides to perform a UE parameter update (UPU) using a control plane procedure at the time of UE 106 registration to the 5G system 100. If the end consumer of any UE parameter to be updated (e.g., an updated RID) is the USIM 960 of the UE 106, the UDM 218 uses a secure grouping mechanism to update the parameters stored on the USIM 960 to protect these parameters. The UDM 218 prepares the UE parameter update data (UPU data) by including the parameters protected by the secure grouping, if any, as well as any UE parameter for which the end consumer is the ME 900 of the UE 106.

[0167] The UDM 218 obtains a UPU-MAC-I AUSF and Counter UPUThe UDM 218 invokes the Nausf_UPUProtection service. The Nausf_UPUProtection request message 4411 includes SUPI and UPU data. If the UDM 218 determines that the UE 106 confirms a successful security check on the received UPU data, the UDM 218 sets the corresponding indication in the UPU data and includes an ACK indication in the Nausf_UPUProtection request message 4411 to signal that it also expects UPU-XMAC-I. UE If UDM 218 does not store an indication that UE 106 supports UPU header protection, then UDM 218 excludes the UPU header from the Nausf_UPUProtection request message 4411 and includes an ACK indication in the Nausf_UPUProtection request message 4411. If UDM 218 has a stored indication that UE 106 supports UPU header protection, then UDM 218 includes the UPU header in the Nausf_UPUProtection request message 4411.

[0168] AUSF 210 uses a UE-specific home key (K AUSF ) Calculate or export UPU-MAC-I AUSF And in Nausf_UPUProtection response message 4412, UPU-MAC-I AUSF and Counter UPU Delivered to UDM 218. In one embodiment, when UDM 218 does not include a UPU header in Nausf_UPUProtection request message 4411, AUSF 210 calculates or derives UPU-MAC-I based on the UPU data instead of the UPU header. AUSF When UDM 218 includes a UPU header in Nausf_UPUProtection request message 4411, AUSF 210 calculates or derives the UPU-MAC-I based on the UPU data and the UPU header. AUSF If the ACK indication exists in Nausf_UPUProtection request message 4411, then AUSF 210 calculates or derives UPU-XMAC-I. UE And in Naus_UPU protection response message 4412, it returns UPU-XMAC-I. UE UPU-XMAC-I UE Allow UDM 218 to verify whether UE 106 is correctly receiving UPU data.

[0169] The UDM 218 then invokes the Nudm_SDM_Notification service operation and sends the Nudm_SDM_Notification message 4413 to the AMF 212, which includes the UPU transparent container if the AMF 212 supports the UPU transparent container, or includes individual information elements (IEs) that include the UPU data, the UPU-MAC-I AUSF and Counter UPU If the UDM 218 requests an acknowledgement, it temporarily stores the expected UPU-XMAC-I UE .

[0170] If the UDM 218 includes the UPU header in the Nausf_UPUProtection service operation, the UDM 218 can indicate that the UPU header is protected. In one embodiment, the UDM 218 can include a UE header protection indicator 4403 in the Nudm_SDM_Notification message 4413. The UPU header protection indicator 4403 is a value, flag, or indicator type that indicates whether the UPU header is protected in the AUSF MAC (i.e., the UPU-MAC-I AUSF ). For example, the UPU header protection indicator 4403 can include a Boolean value such as “T” or “F,” “1” or “0,” etc. The UPU header protection indicator 4403 can be an optional input to the UDM 218’s SDM service (e.g., the Nudm_SDM_Notification service).

[0171] Upon receiving the Nudm_SDM_Notification message 4413, the AMF 212 sends a DL NAS transport message 4414 to the UE 106. If received from the UDM 218, the AMF 212 includes the transparent container in the DL NAS transport message 4414. Otherwise, if the UDM 218 provided individual IEs, the AMF 212 constructs the UPU transparent container. In one embodiment, the UDM 218 or the AMF 212 can include the UPU header protection indicator 4403 in the transparent container for the UE 106. For example, the UPU transparent container IE can be extended to additionally include the UPU header protection indicator 4403, such as in a spare bit of the UPU header.

[0172] Upon receiving the DL NAS transport message 4414, the UE 106 computes the UPU-MAC-I AUSF in the same manner as the AUSF 210 and verifies whether it matches the UPU-MAC-I AUSFValue match. In one embodiment, if the UE 106 receives an indication that the UPU header is protected (i.e., receives a UPU header protection indicator 4403 from the network indicating that the UPU header is protected), the UE 106 can treat the UPU header as input for the calculation of the UPU-MAC-I AUSF . If the UE 106 receives an indication that the UPU header is not protected (i.e., does not receive a UPU header protection indicator 4403 from the network, or the UPU header protection indicator 4403 indicates that the UPU header is not protected), the UE 106 can ignore or exclude the UPU header from the calculation of the UPU-MAC-I AUSF .

[0173] If the verification of the UPU-MAC-I AUSF is successful, and the UPU data contains any parameters that are protected by a security packet, the ME 900 of the UE 106 forwards the security packet to the USIM 960. If the verification of the UPU-MAC-I AUSF is successful, and the UPU data contains any parameters that are not protected by a security packet, the ME 900 of the UE 106 updates its stored parameters with the received parameters in the UPU data.

[0174] If the UDM 218 has requested confirmation from the UE 106, the UE 106 sends an UL NAS transport message 4415 to the serving AMF 212. The UE 106 generates a UPU confirmation, and derives or generates a UPU-MAC-I UE based on the UPU confirmation. The UE 106 includes the generated UPU-MAC-I UE in a transparent container of the UL NAS transport message 4415. In one embodiment, the UE 106 can include a UPU header protection indicator 4404 in the transparent container. The UPU header protection indicator 4404 is a value, flag, or indicator type that indicates whether the UE supports UPU header protection. For example, the UPU header protection indicator 4404 can include a Boolean value, such as “T” or “F,” “1” or “0,” etc.

[0175] Upon receiving the UL NAS transport message 4415, the AMF 212 sends a Nudm_SDM_Info message 4416 to the UDM 218 with the UPU-MAC-I UE and the UPU header protection indicator 4404, if included. If a transparent container with the UPU-MAC-I UE is received in the UL NAS transport message 4415, the AMF 212 sends a Nudm_SDM_Info message 4416 to the UDM 218 with the transparent container.

[0176] If the UDM 218 indicates that the UE 106 is to confirm successful security check of the received UPU data, the UDM 218 includes the received UPU-MAC-I UE with the expected UPU-XMAC-I UE temporarily stored by the UDM 218. If the UDM 218 receives an indication that the UE 106 supports UPU header protection, the UDM 218 stores the indication (i.e., stores the UPU header protection indicator 4404).

[0177] Figure 45 is a block diagram illustrating a UPU transparent container IE 4500 in an illustrative embodiment. In a message from the UE 106 to the network (i.e., in an acknowledgement of a UPU procedure to the network), the UPU transparent container IE 4500 includes a UPU transparent container IEI 4502 generated by the UE 106, a container length 4504, a UPU header 4508 (for data type “1”) and a UE MAC 4510 (i.e., a UPU-MAC-I UE ). Figure 46 is a block diagram of the UPU header 4508 of the UPU transparent container IE 4500 in an illustrative embodiment. Figure 46 The format of the UPU header 4508 in the UPU transparent container IE 4500 is used to carry a transparent container of a UPU acknowledgement (i.e., data type “1”). The UPU header 4508 includes a UPU data type 4612 (in bit 1 of the 4th octet). The UPU data type 4612 has a value of “1” to indicate that the UE parameter update transparent container carries a UPU acknowledgement. In this embodiment, the UPU header 4508 also includes a UPU header protection indicator 4404 (e.g., in bit 2 of the 4th octet) that indicates whether the UE supports UPU header protection when generating an AUSF MAC (i.e., a UPU-MAC-I AUSF ). The UE 106 populates the UPU data type 4612 and the UPU header protection indicator 4404 in the UPU header 4508 of the UPU transparent container IE 4500. For example, the UE 106 can set the UPU header protection indicator 4404 to a value of “0” when the UE 106 does not support UPU header protection for AUSF MAC generation, and the UE 106 can set the UPU header protection indicator 4404 to a value of “1” when the UE 106 supports UPU header protection for AUSF MAC generation. As shown in the configuration or format of the UPU header 4508, the UPU header protection indicator 4404 can be included in the UPU header 4508 in place of the UPU header protection indicator 4404 in the UPU header 4508 shown in FIG. 4B. Figure 46 The configuration or format of the UPU header 4508 as shown can include a modification or revision of the UE parameter update header for a UE parameter update data type with a value of “1” as described in Section 9.11.3.53A of 3GPP TS 24.501 and Figure 9As shown in .11.3.53A.7.

[0178] Figures 47A-47B , Figure 48 , Figure 49 and Figures 50A-50B This is a flowchart illustrating a method 4700 for performing a UE parameter update process in an illustrative embodiment. More specifically, Figures 47A-47B The steps in method 4700 will be referred to Figure 6 The description is based on UDM 218. Figure 48 The steps in method 4700 will be referred to Figure 7 The description is based on AUSF 210. Figure 49 The steps in method 4700 will be referred to Figure 8 The AMF 212 in the text is described, and Figures 50A-50B The steps in method 4700 will be referred to Figure 9 The method is described in UE 106. Those skilled in the art will understand that method 4700 can be performed in other systems, devices, or network functions. The steps in the flowcharts described herein are not exhaustive and may include other steps not shown, and these steps may be performed in an alternative order.

[0179] exist Figure 47A In this process, the data management controller 604 of UDM 218 triggers a UE parameter update (UPU) for UE 106 (step 4702), such as for RID update, NSSAI update, etc. In other words, when UE 106 registers with 5G system 100, the data management controller 604 decides to use a control plane procedure to perform the UE parameter update. When triggering the UE parameter update, the data management controller 604 calls the UPU protection service (e.g., Nausf_UPU protection) to AUSF 210 and generates a request AUSF MAC (i.e., UPU-MAC-I). AUSF ) and UPU counter (i.e., Counter UPU The UPU protection request message (e.g., Nausf_UPUProtection request message) is received (step 4704). The data management controller 604 of the UDM 218 is configured to include SUPI for UE 106 and UPU information for UE parameter updates.

[0180] Figure 51 This is a block diagram illustrating a UPU protection request message 5101 for UPU protection services in an illustrative embodiment. The UPU protection request message 5101 includes UPU information 5100 for UPU protection services. Figure 51In particular embodiments, the UPU information 5100 includes the following attributes (also referred to as information elements (IE)): a UPU data list attribute 5131, a UPU confirmation indicator attribute 5132, and a UPU header attribute 5133. The UPU data list attribute 5131 includes the UPU data list 5102. The UPU information 5100 can define updates to multiple UE parameters, and thus the UPU data list 5102 can comprise a collection or array of UPU data 5104. The UPU data 5104 is information defining a UE parameter update for a UE parameter. Each data set of UPU data 5104 includes update data for an individual UE parameter. The UPU confirmation indicator attribute 5132 includes the UPU confirmation indicator 5106. The UPU confirmation indicator 5106 (e.g., a Boolean value) indicates whether the UE 106 is to respond with a UE MAC (e.g., a UPU-MAC-I UE ) to the UDM 218. The UPU header attribute 5133 is optional and can include the UPU header 5108. As described above, the UPU information 5100 can have a structured data type provided for the Nausf_UPU Protect Service API, as described in Section 6.3 of 3GPP TS 29.509.

[0181] When a UE parameter update is triggered, the data management controller 604 determines or identifies whether the UE 106 supports UPU header protection in derivation of the MAC (step 4706). The data management controller 604 can determine whether the UE 106 supports UPU header protection in a variety of ways. For example, the data management controller 604 can process a UPU header protection indicator 4404 received from the UE 106, such as during a previous UE parameter update (optional step 4740). In another example, the data management controller 604 can query a UDR, HSS, or another network function for subscription information or capability information about the UE 106.

[0182] When it is determined that the UE 106 supports UPU header protection, the data management controller 604 of the UDM 218 includes the UPU header 5108 in the UPU protection request message 5101 (step 4708). Including the UPU header 5108 in this manner requests the AUSF 210 to derive an AUSF MAC based on the UPU header 5108. When it is determined that the UE 106 does not support UPU header protection (or when the UDM 218 is unable to determine that the UE 106 supports UPU header protection), the data management controller 604 of the UDM 218 excludes the UPU header 5108 from the UPU protection request message 5101 (step 4710). This requests the AUSF 210 to derive an AUSF MAC based on the UPU data 5104 and not the UPU header 5108. The data management controller 604 then sends the UPU protection request message 5101 to the AUSF 210 (step 4712). One technical advantage is that the UDM 218 is able to request the AUSF 210 to derive an AUSF MAC based on the UPU header 5108 or not based on the UPU header 5108 depending on whether the UPU header 5108 is included in the UPU protection request message 5101.

[0183] In Figure 48 The authentication controller 704 of the AUSF 210 receives the UPU protection request message 5101 from the UDM 218 (step 4802). The authentication controller 704 processes the UPU protection request message 5101 to determine whether the UPU protection request message 5101 includes the UPU header 5108 (step 4804). When the UPU protection request message includes the UPU header 5108, the authentication controller 704 derives or generates an AUSF MAC based on the UPU header 5108 (step 4806). As described above, deriving an AUSF MAC based on the UPU header 5108 can include deriving an AUSF MAC based on the UPU data 5104 and the UPU header 5108 depending on the derivation function used. When the UPU protection request message 5101 does not include the UPU header 5108, the authentication controller 704 derives or generates an AUSF MAC based on the UPU data 5104 and not (i.e., without regard to) the UPU header 5108 (step 4808). One technical advantage is that the AUSF 210 is instructed on how to derive an AUSF MAC based on inclusion / exclusion of the UPU header 5108 in the UPU protection request message 5101.

[0184] The authentication controller 704 of the AUSF 210 can also derive or generate an expected UE MAC (e.g., UPU-MAC-I UE)(optional step 4810), as further described in 3GPP TS 33.501 (Annex A.20). The authentication controller 704 then sends a UPU protection response message (e.g., Nausf_UPUProtection response message) to the UDM 218 (step 4812). Figure 52 is a block diagram illustrating a UPU protection response message 5201 for the UPU protection service in the illustrative embodiments. The UPU protection response message 5201 includes UPU security information 5200 for the UPU protection service. The UPU security information 5200 contains material generated for protection of the UE parameter update and includes the following attributes: an AUSF MAC attribute 5231, a UPU counter attribute 5232, and an expected UE MAC attribute 5233. The AUSF MAC attribute 5231 contains the AUSF MAC 5212 derived by the AUSF 210. The UPU counter attribute 5232 contains the UPU counter 5216. The expected UE MAC attribute 5233 contains the expected UE MAC 5218 (XUE MAC) derived by the AUSF 210 if the UDM 218 requests confirmation to the UE 106. As described above, the UPU security information 5200 can have a structured data type provided for the Nausf_UPUProtection service API, as described in Section 6.3 of 3GPP TS 29.509.

[0185] In Figure 47A , the data management controller 604 of the UDM 218 receives the UPU protection response message 5201 (e.g., Nausf_UPUProtection response message) from the AUSF 210 (step 4714) that includes the AUSF MAC 5212 (i.e., UPU-MAC-I AUSF ) and the UPU counter 5216 (i.e., Counter UPU ). If the UPU confirmation indication 5106 is present in the UPU protection request message 5101, the UPU protection response message 5201 also includes the expected UE MAC 5218 (e.g., UPU-XMAC-I UE ). The data management controller 604 can then temporarily store the expected UE MAC 5218 (optional step 4716).

[0186] For the UPU procedure, the data management controller 604 invokes the subscriber data management (SDM) service of the UDM 218 (e.g., the Nudm_SDM_Notification service) and generates an SDM notification message (e.g., the Nudm_SDM_Notification message) (step 4718). The data management controller 604 includes UPU information for UE parameter updates in the SDM notification message. Figure 53 This is a block diagram of an SDM notification message 5301 for a subscriber data management service in an illustrative embodiment. The SDM notification message 5301 includes UPU information 5300. The UPU information 5300 includes the following attributes (also referred to as IEs): UPU data list attribute 5331, UPU re-registration indicator attribute 5332, UPU confirmation indicator attribute 5333, UPU AUSF MAC attribute 5334, and UPU counter attribute 5335. The UPU data list attribute 5331 contains a UPU data list 5102 (i.e., UPU data 5104). The UPU information 5300 can define updates to multiple UE parameters, and therefore, the UPU data list 5102 can include a collection or array of UPU data 5104. The UPU re-registration indicator attribute 5332 contains a UPU re-registration indicator 5312 indicating whether re-registration of UE 106 has been requested. The UPU confirmation indicator attribute 5333 contains a UPU confirmation indicator 5106. The UPUAUSF MAC attribute 5334 contains the AUSF MAC 5212 derived from AUSF 210. The UPU counter attribute 5335 contains the UPU counter 5216. As mentioned above, the UPU information 5300 may have a structured data type provided for the Nudm_SubscriberDataManagement service API, as described in Section 6.1 of 3GPP TS 29.503.

[0187] In one embodiment, the data management controller 604 may include a UE header protection indicator 4403 in the SDM notification message 5301. Figure 47A (Optional step 4742). Therefore, the subscriber data management service can be extended to include the UPU header protection indicator 4403. For example, the SDM notification message 5301 or UPU information 5300 can be extended to include the UPU header protection indicator 4403. One technical advantage is that the UDM 218 can signal to the UE 106 whether the UPU header 5108 is protected in the AUSFMAC 5212.

[0188] As described above, UPU information 5300 allows a conditional UPU acknowledgment indicator 5106, which indicates whether UE 106 wants to use UE MAC 4510 (e.g., UPU-MAC-I).UE ) in response to the UDM 218. In one embodiment, the UPU acknowledgement can be mandatory for initial or first UE parameter update from the UDM 218 for the UE 106. Accordingly, the data management controller 604 can set or include the UPU acknowledgement indicator 5106 in the SDM notification message 5301 for the initial or first UE parameter update (e.g., the first UE parameter update from the UDM 218 for the UE 106). Figure 47A optional step 4744).

[0189] The data management controller 604 then sends the SDM notification message 5301 to the AMF 212 (step 4720). In Figure 49 , the access and mobility controller 804 of the AMF 212 receives the SDM notification message 5301 from the UDM 218 (step 4902). The access and mobility controller 804 formats or constructs the UPU transparent container based on the UPU information 5300 in the SDM notification message 5301 (step 4904). Figure 54 is a block diagram illustrating the UPU transparent container IE 5400 in the illustrative embodiments. In messages from the network to the UE 106, the UPU transparent container IE 5400 includes a UPU transparent container IE identifier (IEI) 5402, a container length 5404, the UPU header 5108, the AUSF MAC 5212, the UPU counter 5216, and the UPU data list 5102. The access and mobility controller 804 populates the AUSF MAC 5212, the UPU counter 5216, and the UPU data list 5102 from the UPU information 5300 in the SDM notification message 5301. In one embodiment, the access and mobility controller 804 can include or insert the UPU header protection indicator 4403 in the transparent container. Accordingly, the format of the UPU transparent container IE 5400 can be extended to include the UPU header protection indicator 4403. One technical advantage is that the network is able to signal to the UE 106 whether the UPU header 5108 is protected in the AUSF MAC 5212.

[0190] In Figure 49 , the access and mobility controller 804 sends a DL NAS transport message to the UE 106 with the UPU transparent container (step 1306), such as Figure 44 illustrated, with the DL NAS transport message 4414. Accordingly, the AMF 212 can provide the UPU data 5104, the AUSF MAC 5212, the UPU header 5108, and the UPU header protection indicator 4403 to the UE 106.

[0191] In Figure 50AIn particular embodiments, the ME 900 of the UE 106 receives the DL NAS transport message from the AMF 212 (step 5002). Upon receiving the DL NAS transport message, the update controller 936 of the UE 106 derives or computes the AUSF MAC (step 5004). In one embodiment, the update controller 936 of the UE 106 can derive the AUSF MAC based on its local configuration or policy. For example, when the UE 106 supports UPU header protection, the update controller 936 can derive the AUSF MAC based on the UPU data 5104 and the UPU header 5108. When the UE 106 does not support UPU header protection, the update controller 936 can derive the AUSF MAC based on the UPU data 5104 but not (i.e., without regard to) the UPU header 5108. In one embodiment, the update controller 936 of the UE 106 can determine whether the UPU header 5108 is protected in the AUSF MAC 5212 received from the network (optional step 5030). For example, the update controller 936 can process the UPU header protection indicator 4403 (if provided) to determine whether the UPU header 5108 is protected. In response to determining that the UPU header 5108 is protected, the update controller 936 derives the AUSF MAC based on the UPU data 5104 and the UPU header 5108 (optional step 5032). In response to determining that the UPU header 5108 is not protected, the update controller 936 derives the AUSF MAC based on the UPU data 5104 but not (i.e., without regard to) the UPU header 5108 (optional step 5034).

[0192] The update controller 936 then performs verification of the update by comparing the derived AUSF MAC with the received AUSF MAC 5212 received in the DL NAS transport message (i.e., AUSF MAC 5212 and UPU data 5104) (step 5006). When the derived AUSF MAC and the received AUSF MAC 5212 do not match, the update controller 936 rejects the UE parameter update (step 5008). In other words, the verification of the update at the UE 106 fails. When the derived AUSF MAC and the received AUSF MAC 5212 match, the update controller 936 verifies the UE parameter update (step 5010). In other words, the verification of the update at the UE 106 succeeds. When the verification succeeds, the update controller 936 updates one or more configuration parameters of the ME 900 and / or the USIM 960 based on the UPU data 5104 (step 5012). If the UPU data 5104 contains configuration parameters that are protected by a security package, the ME 900 of the UE 106 forwards the security package to the USIM 960. When the verification succeeds and the UPU data contains configuration parameters that are not protected by a security package, the ME 900 of the UE 106 updates its stored parameters with the received parameters in the UPU data 5104.

[0193] When the UDM 218 has requested confirmation from the UE 106, the update controller 936 generates a UPU confirmation indicating whether the verification was successful (step 5013), and derives or generates a UE MAC 4510 (e.g., UPU-MAC-I UE ) (step 5014). Figure 55 is a block diagram illustrating derivation of the UE MAC 4510 in the UE 106 in the illustrative embodiments. The UE MAC 4510 is derived from a key derivation function (KDF) 5500 using the K AUSF key 5504 as an input key. Conventionally, as described in Annex a.20 of 3GPP TS 33.501, the UE MAC is generated upon successful verification of the UE parameter update (i.e., UPU data). In one embodiment, the UE MAC generation function 5501 can be extended to indicate successful or unsuccessful (failed) verification of the UE parameter update. For the UE MAC generation function 5501, the input parameters to the KDF 5500 are the UPU confirmation 5514 and the UPU counter 5216. The UPU confirmation 5514 is a variable parameter that indicates whether the verification of the UE parameter update at the UE 106 was successful (i.e., the received AUSF MAC 5212 was verified at the UE 106). The following input parameters can be used to form a string S input to the KDF 5500 when deriving the UE MAC 4510: - FC=0x7C, - P0=UPU confirmed, - L0 = the length confirmed by UPU, - P1 = UPU counter, - L1 = the length of the UPU counter.

[0194] UE MAC 4510 (e.g., UPU-MAC-I) UE This can be identified using the 128 least significant bits of the KDF 5500 output. Therefore, the UPU confirms that the 5514 performs integrity protection through the UE MAC generation function 5501.

[0195] In this embodiment, the UPU ACK 5514 is a variable parameter set by the UE 106 based on the success / failure of the UE parameter update verification. For example, when the UE parameter update is successfully verified at the UE, the UE 106 can set the UPU ACK 5514 to a first value (e.g., "0x01"), while when the UE parameter update is unsuccessfully verified at the UE, the UE 106 can set the UPU ACK 5514 to a second value (e.g., "0x00"), although other values ​​may be defined in other embodiments. Figure 55 The UE MAC generation function 5501 specified in the document, UE MAC 4510 depends on the value input by UE 106 for UPU confirmation 5514. The UE MAC generation function 5501 of UE 106 as described above may include modifications or additions to Annex a.20 (e.g., Annex a.20a) in 3GPP TS 33.501. Note that AUSF 210 may continue to use the UPU-MAC-I described in Annex A.20 of 3GPP TS 33.501. UE A generation function is used to generate the expected UE MAC 5218, where the UPU acknowledgment is set to "0x01". One technical advantage is that UE 106 can indicate to the network via the generation of UE MAC 4510 whether the UE parameter update was successfully verified at UE 106.

[0196] exist Figure 50AIn step 5036, when the update controller 936 of UE 106 determines that the exported AUSF MAC and the received AUSF MAC 5212 match, and the UE parameter update is successfully verified (as shown in step 5010), the update controller 936 sets the UPU acknowledgment 5514 to a first value (e.g., "0x01") when exporting UE MAC 4510 (step 5036). Therefore, the update controller 936 can input the UPU acknowledgment 5514 set to the first value into KDF 5500 to export UE MAC 4510. When the update controller 936 of UE 106 determines that the exported AUSF MAC and the received AUSF MAC 5212 do not match, and the UE parameter update verification fails (as shown in step 5008), the update controller 936 sets the UPU acknowledgment 5514 to a second value (e.g., "0x00") when exporting UE MAC 4510 (step 5038). Therefore, the update controller 936 can input the UPU acknowledgment 5514 set to the second value into the KDF 5500 to export the UE MAC 4510.

[0197] exist Figure 50B In step 5016, the update controller 936 formats or constructs the UPU transparent container. The update controller 936 sets the UPU header protection indicator 4404 (in the second bit of the fourth octet) in the UPU header 4508 (data type "1") of the UPU transparent container IE 4500 to indicate whether the UE 106 supports UPU header protection when generating the AMF MAC (step 5018). For example, when the UE 106 supports UPU header protection, the update controller 936 can set the UPU header protection indicator 4404 to a first value (e.g., "1") (step 5020). When the UE 106 does not support UPU header protection, the update controller 936 can set the UPU header protection indicator 4404 to a second value (e.g., "0") (step 5022). The UE 106 then uses the UPU transparent container to send a UL NAS transmission message to the AMF 212 (step 5024). One technical advantage is that UE 106 can indicate to the network whether it supports UPU header protection based on UPU header protection indicator 4404. The network (such as UDM 218) can determine whether to implement UPU header protection for UE parameter updates of UE 106 based on UPU header protection indicator 4404 provided by UE 106.

[0198] exist Figure 49In this process, the Access and Mobility Controller 804 of AMF 212 receives a UL NAS transmission message from UE 106 (optional step 4908). Access and Mobility Controller 804 invokes the Subscriber Data Management Service (i.e., Nudm_SDM_Info service) of UDM 218 to provide acknowledgment from UE 106 to UDM 218. Access and Mobility Controller 804 sends an SDM Information message with UE MAC 4510 to UDM 218 (e.g., such as...). Figure 44 Nudm_SDM_Info message 4414 (optional step 4910).

[0199] exist Figure 47B In step 4722, the data management controller 604 of UDM 218 receives an SDM information message including the UPU transparent container from AMF 212. The data management controller 604 extracts the UE MAC 4510 and the UPU header protection indicator 4404 from the UPU transparent container (step 4724). For example, the data management controller 604 can extract the UPU header protection indicator 4404 from the second bit of the fourth octet of the UPU transparent container IE 4500 (see...). Figure 45 Then, the data management controller 604 stores the UPU header protection indicator 4404 (step 4726).

[0200] Data management controller 604 compares the received UE MAC 4510 derived by UE 106 with the expected UE MAC 5218 temporarily stored by UDM 218 (i.e., UPU-XMAC-I generated by AUSF 210). UE The UDM 218 compares the received UE MAC 4510 with the expected UE MAC 5218, performing verification of UPU confirmation 5514 (step 4728). If the received UE MAC 4510 matches the expected UE MAC 5218, the UDM 218 verifies the success of the UE parameter update (step 4730). Therefore, the current UPU procedure is complete. The UDM 218 can then trigger a subsequent UPU procedure to UE 106 and can control AUSF 210 to derive AUSF MAC 5212 based on the capabilities of UE 106 reported via UPU header protection indicator 4404.

[0201] If the received UE MAC 4510 and the expected UE MAC 5218 do not match, the UDM 218 identifies a failure of the UE parameter update (step 4732). In response to the verification of the UPU confirmation 5514 being unsuccessful (i.e., the UE parameter update failed), the data management controller 604 can then retry, redo, or repeat the UPU procedure based on the capabilities of the UE 106 reported via the UPU header protection indicator 4404 (step 4734). For example, if the UPU header protection indicator 4404 indicates that the UE 106 supports UPU header protection, the UDM 218 can retry the UPU procedure with the AUSF MAC 5212 derived by the AUSF 210 based on the UPU data 5104 and the UPU header 5108. If the UPU header protection indicator 4404 indicates that the UE 106 does not support UPU header protection, the UDM 218 can retry the UPU procedure with the AUSF MAC 5212 derived by the AUSF 210 based on the UPU data 5104 but not the UPU header 5108. One technical advantage is that the UPU procedure is more likely to succeed when the AUSF MAC 5212 is derived by the network based on the capabilities of the UE 106.

[0202] Further details of the UPU procedure are provided below.

[0203] Figure 56 is a message diagram illustrating a UE parameter update procedure in the illustrative embodiments. Figure 56 The UE parameter update procedure described in the foregoing can be an extension to section 6.15.2.1 of 3GPP TS 33.501. In one example, the UDM 218 decides to perform the UE parameter update (UPU) using a control plane procedure at the time the UE 106 registers to the 5G system 100.

[0204] The UDM 218 obtains the AUSF MAC 5212 (i.e., UPU-MAC-I AUSF ) and Counter UPUto invoke the Nausf_UPUProtection service. The UDM 218 includes the SUPI and the UPU data 5104 in the Nausf_UPUProtection request message 5611. If the UDM 218 has a stored indication that the UE 106 supports UPU header protection, the UDM 218 includes the UPU header 5108 in the Nausf_UPUProtection request message 5611 and can include an ACK indication in the Nausf_UPUProtection request message 5611. If the UDM 218 does not have a stored indication that the UE 106 supports UPU header protection, the UDM 218 does not include the UPU header 5108 in the Nausf_UPUProtection request message 5611 and includes an ACK indication in the Nausf_UPUProtection request message 5611. In this embodiment, the UDM 218 either does not know whether the UE 106 supports UPU header protection or has a stored indication that the UE 106 does not support UPU header protection, so the UDM 218 does not include the UPU header 5108 in the Nausf_UPUProtection request message 5611.

[0205] The AUSF 210 computes or derives an AUSF MAC 5212 (i.e., UPU-MAC-I AUSF ) using the UE-specific home key (K AUSF ) and delivers the UPU-MAC-I AUSF and Counter UPU to the UDM 218 in the Nausf_UPUProtection response message 5612. When the AUSF 210 receives the UPU header 5108 from the UDM 218, the AUSF 210 derives the AUSF MAC 5212 based on the UPU header 5108. When the AUSF 210 does not receive the UPU header 5108 from the UDM 218, the AUSF 210 derives the AUSF MAC 5212 based on the UPU data 5104 instead of the UPU header 5108. In this embodiment, the AUSF 210 derives the AUSF MAC 5212 based on the UPU data 5104 instead of the UPU header 5108. If the ACK indication is present in the Nausf_UPUProtection request message 5611, the AUSF 210 computes or derives an expected UE MAC 5218 (i.e., UPU-XMAC-I UE), and returns the expected UE MAC 5218 in the Nausf_UPUProtection response message 5612. The expected UE MAC 5218 (i.e., UPU-XMAC-I UE ) allows the UDM 218 to verify whether the UE 106 correctly received the UPU data 5104.

[0206] The UDM 218 then invokes the Nudm_SDM_Notification service operation and sends the Nudm_SDM_Notification message 5613 to the AMF 212, which includes the UPU transparent container if the AMF 212 supports the UPU transparent container, or includes an individual information element (IE) that includes the UPU data 5104, the UPU-MAC-I AUSF , and the Counter UPU . If the UDM 218 requests confirmation, it temporarily stores the expected UPU-XMAC-I UE . If the UDM 218 included the UPU header 5108 in the Nausf_UPUProtection service operation, the UDM 218 indicates that the UPU header 5108 is protected, such as by including the UPU header protection indicator 4403 in the Nudm_SDM_Notification message 5613.

[0207] Upon receiving the Nudm_SDM_Notification message 5613, the AMF 212 sends a DL NAS transport message 5614 to the UE 106. If received from the UDM 218, the AMF 212 includes the transparent container in the DL NAS transport message 5614. Otherwise, if the UDM 218 provided an individual IE, the AMF 212 constructs the UPU transparent container. The transparent container can also convey the UPU header protection indicator 4403 to the UE 106.

[0208] Upon receiving the DL NAS transport message 5614, the UE 106 computes the UPU-MAC-I AUSF in the same way as the AUSF 210 and verifies whether it matches the UPU-MAC-I AUSFValue match. In this embodiment, the UE 106 supports UPU header protection and is configured to generate the AUSF MAC based on both the UPU header 5108 (and the UPU data 5104), and based on the UPU data 5104 but not the UPU header 5108. Thus, the UE 106 can determine whether the UPU header 5108 is protected in the AUSF MAC 5212 based on an indication provided by the network (e.g., the UPU header protection indicator 4403) and derive the AUSF MAC accordingly.

[0209] If the verification of the UPU-MAC-I AUSF is successful, and the UPU data 5104 contains any parameters that are protected by a security packet, the ME 900 of the UE 106 forwards the security packet to the USIM 960. If the verification of the UPU-MAC-I AUSF is successful, and the UPU data 5104 contains any parameters that are not protected by a security packet, the ME 900 of the UE 106 updates its stored parameters with the parameters received in the UPU data 5104.

[0210] If the UDM 218 has requested confirmation from the UE 106, the UE 106 sends an UL NAS transport message 5615 to the serving AMF 212. The UE 106 formats or constructs a UPU transparent container, such as the UPU transparent container IE 4500 shown in Figure 45 . The UE 106 derives or generates the UE MAC 4510 (i.e., the UPU-MAC-I UE ) and includes the generated UE MAC 4510 in the transparent container of the UL NAS transport message 5615.

[0211] In this embodiment, the verification of the UPU-MAC-I AUSF at the UE 106 is successful. Thus, as shown in Figure 55 , the UE 106 derives the UE MAC 4510 by inputting the UPU confirmation 5514 set to a first value (e.g., “0x01”) into the KDF 5500. The value of the UE MAC 4510 indicates that the verification of the UPU-MAC-I AUSF at the UE 106 is successful.

[0212] Further, the UE 106 includes the UPU header protection indicator 4404 in the transparent container. In other words, the UE 106 sets the UPU header protection indicator 4404 (i.e., in the 2nd bit of the 4th octet) in the UPU header 4508 of the UPU transparent container IE 4500 to indicate whether the UE 106 supports UPU header protection when generating the AUSF MAC. In this embodiment, the UE 106 supports UPU header protection, so the UE 106 sets the UPU header protection indicator 4404 to a first value (e.g., “1”). The UE 106 sends the UL NAS transport message 5615 to the serving AMF 212 with the transparent container formatted as described above.

[0213] Upon receiving the UL NAS transport message 5615, the AMF 212 sends a Nudm_SDM_Info message 5616 to the UDM 218 with the UE MAC 4510 (i.e., UPU-MAC-I UE ) and the UPU header protection indicator 4404. If the transparent container with the UPU-MAC-I UE is received in the UL NAS transport message 5615, the AMF 212 sends the Nudm_SDM_Info message 5616 to the UDM 218 with the transparent container.

[0214] The UDM 218 receives the Nudm_SDM_Info message 4816 including the UPU transparent container from the AMF 212. The UDM 218 extracts the UE MAC 4510 and the UPU header protection indicator 4404 from the UPU transparent container. For example, the UDM 218 extracts the UPU header protection indicator 4404 from the 2nd bit of the 4th octet in the UPU header 4508 (see Figure 45 ). The UDM 218 stores the UPU header protection indicator 4404, such as in the UDR.

[0215] The UDM 218 verifies the received UE MAC 4510 derived by the UE 106 against the expected UE MAC 5218 (i.e., UPU-XMAC-I UE) are compared, and the verification of the UPU confirmation 5514 is performed. If the received UE MAC 4510 and the expected UE MAC 5218 match, the UDM 218 verifies the success of the UE parameter update. If the received UE MAC 4510 and the expected UE MAC 5218 do not match, the UDM 218 identifies the failure of the UE parameter update. In this embodiment, the received UE MAC 4510 and the expected UE MAC 5218 match, and the UDM 218 will verify the success of the UE parameter update. Thus, the present UE parameter update procedure is complete.

[0216] In this embodiment, the UE 106 supports UPU header protection, and the UPU header protection indicator 4404 is set to a first value (e.g., “1”). Based on the UPU header protection indicator 4404 stored for the UE 106, the UDM 218 performs one or more subsequent UPU procedures with the AUSF MAC 5212 derived at the AUSF 210 based on the UPU data 5104 and the UPU header 5108. One technical advantage is that the network learns the UE’s capabilities in a previous UPU procedure, and when informed that the UE 106 supports UPU header protection, can switch to UPU header protection for subsequent UPU procedures. Thus, when the UPU header 5108 is integrity protected together with the UPU data 5104, the subsequent UPU procedures can be more secure.

[0217] Figure 57 is a message diagram illustrating a UE parameter update procedure in an illustrative embodiment. Figure 57 The UE parameter update procedure described in the foregoing can be an extension to Section 6.15.2.1 of 3GPP TS 33.501. In one example, the UDM 218 decides to perform a UE parameter update (UPU) using a control plane procedure at the time the UE 106 registers to the 5G system 100. The UDM 218 obtains an AUSF MAC 5212 (i.e., UPU-MAC-I AUSF ) and Counter UPUto invoke the Nausf_UPUProtection service. The UDM 218 includes the SUPI and the UPU data 5104 in the Nausf_UPUProtection request message 5711. If the UDM 218 has a stored indication that the UE 106 supports UPU header protection, the UDM 218 includes the UPU header 5108 in the Nausf_UPUProtection request message 5711 and can include an ACK indication in the Nausf_UPUProtection request message 5711. If the UDM 218 does not have a stored indication that the UE 106 supports UPU header protection, the UDM 218 does not include the UPU header 5108 in the Nausf_UPUProtection request message 5711 and includes an ACK indication in the Nausf_UPUProtection request message 5711. In this embodiment, the UDM 218 stores an indication that the UE 106 supports UPU header protection or otherwise erroneously determines that the UE 106 supports UPU header protection, so the UDM 218 includes the UPU header 5108 in the Nausf_UPUProtection request message 5711.

[0218] The AUSF 210 computes or derives an AUSF MAC 5212 (i.e., UPU-MAC-I AUSF ) using the UE-specific home key (K AUSF ) and delivers the UPU-MAC-I AUSF and Counter UPU to the UDM 218 in the Nausf_UPUProtection response message 5712. When the AUSF 210 receives the UPU header 5108 from the UDM 218, the AUSF 210 derives the AUSF MAC 5212 based on the UPU header 5108. When the AUSF 210 does not receive the UPU header 5108 from the UDM 218, the AUSF 210 derives the AUSF MAC 5212 based on the UPU data 5104 instead of the UPU header 5108. In this embodiment, the AUSF 210 derives the UPU-MAC-I AUSF from the UPU data 5104 and the UPU header 5108. If the ACK indication is present in the Nausf_UPUProtection request message 5711, the AUSF 210 computes or derives an expected UE MAC 5218 (i.e., UPU-XMAC-I UE), and returns the expected UE MAC 5218 in the Nausf_UPUProtection response message 5712. The expected UE MAC 5218 (i.e., UPU-XMAC-I UE ) allows the UDM 218 to verify whether the UE 106 correctly received the UPU data 5104.

[0219] The UDM 218 then invokes the Nudm_SDM_Notification service operation and sends the Nudm_SDM_Notification message 5713 to the AMF 212, which includes the UPU transparent container if the AMF 212 supports the UPU transparent container, or includes a single information element (IE) that includes the UPU data 5104, the UPU-MAC-I AUSF , and the Counter UPU . If the UDM 218 requests confirmation, it temporarily stores the expected UPU-XMAC-I UE . If the UDM 218 included the UPU header 5108 in the Nausf_UPUProtection service operation, the UDM 218 indicates that the UPU header 5108 is protected, such as by including the UPU header protection indicator 4403 in the Nudm_SDM_Notification message 5713.

[0220] Upon receiving the Nudm_SDM_Notification message 5713, the AMF 212 sends a DL NAS transport message 5714 to the UE 106. If received from the UDM 218, the AMF 212 includes the transparent container in the DL NAS transport message 5714. Otherwise, if the UDM 218 provided individual IEs, the AMF 212 constructs the UPU transparent container. The transparent container can also convey the UPU header protection indicator 4403 to the UE 106.

[0221] Upon receiving the DL NAS transport message 5714, the UE 106 computes the UPU-MAC-I AUSF in the same way as the AUSF 210 and verifies whether it matches the UPU-MAC-I AUSF value received in the DL NAS transport message 5714 (i.e., within the transparent container). In this embodiment, the UE 106 does not support UPU header protection and is only able to derive the AUSF MAC based on the UPU data 5104, but not the UPU header 5108. However, the AUSF 210 derives the UPU-MAC-I AUSF based on the UPU data 5104 and the UPU header 5108. Thus, the UPU-MAC-IAUSF The verification is unsuccessful.

[0222] If the UDM 218 has requested confirmation from the UE 106, the UE 106 sends an UL NAS transport message 5715 to the serving AMF 212. The UE 106 formats or constructs a UPU transparent container, such as the UPU transparent container IE 4500 shown. Figure 45 The UE 106 derives or generates a UE MAC 4510 (i.e., UPU-MAC-I UE ), and includes the generated UE MAC 4510 in the transparent container of the UL NAS transport message 5715. In this embodiment, the UPU-MAC-I AUSF is different than the UPU-XMAC-I UE derived by the AUSF 210. Thus, as shown, the UE 106 derives the UE MAC 4510 by inputting the UPU confirmation 5514 set to the second value (e.g., “0x00”) into the KDF 5500. Accordingly, the value of the UE MAC 4510 will be different than the UPU-XMAC-I UE .

[0223] Further, the UE 106 includes the UPU header protection indicator 4404 in the transparent container. In other words, the UE 106 sets the UPU header protection indicator 4404 (in the 2nd bit of the 4th octet) in the UPU header 4508 of the UPU transparent container IE 4500 to indicate whether the UE 106 supports UPU header protection when generating the AUSF MAC. In this embodiment, the UE 106 does not support UPU header protection, and thus the UE 106 sets the UPU header protection indicator 4404 to the second value (e.g., “0”). The UE 106 sends the UL NAS transport message 5715 to the serving AMF 212 with the transparent container formatted as described above.

[0224] Upon receiving the UL NAS transport message 5715, the AMF 212 sends a Nudm_SDM_Info message 5716 to the UDM 218 with the UE MAC 4510 (i.e., UPU-MAC-I UE ) and the UPU header protection indicator 4404. If the transparent container with the UPU-MAC-I UE is received in the UL NAS transport message 5715, the AMF 212 sends the Nudm_SDM_Info message 5716 to the UDM 218 with the transparent container.

[0225] The UDM 218 receives the Nudm_SDM_Info message 5716 including the UPU transparent container from the AMF 212. The UDM 218 extracts the UE MAC 4510 and the UPU header protection indicator 4404 from the UPU transparent container and stores the UPU header protection indicator 4404, such as in the UDR.

[0226] The UDM 218 performs verification of the UPU confirmation 5514 by comparing the received UE MAC 4510 derived by the UE 106 with the expected UE MAC 5218 (i.e., the UPU-XMAC-I generated by the AUSF 210) temporarily stored by the UDM 218. The UDM 218 can perform the verification of the UPU confirmation 5514 by comparing the received UE MAC 4510 with the expected UE MAC 5218 using a hash function, such as SHA-256. UE If the received UE MAC 4510 and the expected UE MAC 5218 match, the UDM 218 successfully verifies the UPU confirmation 5514 and the success of the UE parameter update. If the received UE MAC 4510 and the expected UE MAC 5218 do not match, the UDM 218 does not successfully verify the UPU confirmation 5514 and identifies the failure of the UE parameter update. In this embodiment, the UE 106 derives the UE MAC 4510 by setting the UPU confirmation 5514 to a second value (e.g., “0x00”) and the UDM 218 will determine that the received UE MAC 4510 and the expected UE MAC 5218 do not match and the verification fails. In response to the verification of the UPU confirmation 5514 being unsuccessful (i.e., the UE parameter update failed), the UDM 218 processes the UPU header protection indicator 4404 stored for the UE 106 to determine that the UE 106 does not support UPU header protection. The UDM 218 can then retry, redo, or repeat the UPU procedure with the AUSF MAC 5212 derived by the AUSF 210 based on the UPU data 5104 instead of the UPU header 5108.

[0227] One technical advantage is that the network can be compliant with UEs that do not support UPU header protection. The UDM 218 stores the UPU header protection indicator 4404 provided by the UE 106. When the UE parameter update fails due to the UE 106 not supporting UPU header protection, the UDM 218 can retry the update with the AUSF MAC 5212 derived based on the UPU data 5104 instead of the UPU header 5108.

[0228] Figure 58 is a message diagram illustrating a UE parameter update procedure in an illustrative embodiment. Figure 58The UE parameter update procedure described in the middle can be an extension to section 6.15.2.1 of 3GPP TS 33.501. In one example, the UDM 218 decides to perform a UE parameter update (UPU) using a control plane procedure at the time of UE 106 registration to the 5G system 100. The UDM 218 invokes the Nausf_UPUProtection service by sending a Nausf_UPUProtection request message 5811 to the AUSF 210 to obtain an AUSF MAC 5212 (i.e., UPU-MAC-I AUSF ) and Counter UPU . The UDM 218 includes the SUPI and UPU data 5104 in the Nausf_UPUProtection request message 5811. If the UDM 218 has a stored indication that the UE 106 supports UPU header protection, the UDM 218 includes the UPU header 5108 in the Nausf_UPUProtection request message 5811 and can include an ACK indication in the Nausf_UPUProtection request message 5811. If the UDM 218 does not have a stored indication that the UE 106 supports UPU header protection, the UDM 218 does not include the UPU header 5108 in the Nausf_UPUProtection request message 5811 and includes an ACK indication in the Nausf_UPUProtection request message 5811. In this embodiment, the UDM 218 either does not know whether the UE 106 supports UPU header protection or otherwise incorrectly determines that the UE 106 does not support UPU header protection, so the UDM 218 does not include the UPU header 5108 in the Nausf_UPUProtection request message 5811.

[0229] The AUSF 210 computes or derives the AUSF MAC 5212 (i.e., UPU-MAC-I AUSF ) using a UE-specific home key (K AUSF ) and includes the UPU-MAC-I AUSF and Counter UPUto the UDM 218. When the AUSF 210 receives the UPU header 5108 from the UDM 218, the AUSF 210 derives the AUSF MAC 5212 based on the UPU header 5108. When the AUSF 210 does not receive the UPU header 5108 from the UDM 218, the AUSF 210 derives the AUSF MAC 5212 based on the UPU data 5104 instead of the UPU header 5108. In this embodiment, the AUSF 210 derives the AUSF MAC 5212 based on the UPU data 5104 instead of the UPU header 5108. If an ACK indication is present in the Nausf_UPUProtection request message 5811, the AUSF 210 computes or derives the expected UE MAC 5218 (i.e., UPU-XMAC-I UE ) and returns the expected UE MAC 5218 in the Nausf_UPUProtection response message 5812. The expected UE MAC 5218 (i.e., UPU-XMAC-I UE ) allows the UDM 218 to verify whether the UE 106 correctly received the UPU data 5104.

[0230] The UDM 218 then invokes the Nudm_SDM_Notification service operation and sends the Nudm_SDM_Notification message 5813 to the AMF 212, which includes the UPU transparent container if the AMF 212 supports the UPU transparent container, or includes an individual information element (IE) that includes the UPU data 5104, the UPU-MAC-I AUSF , and the Counter UPU . If the UDM 218 requests an acknowledgement, it temporarily stores the expected UPU-XMAC-I UE . If the UDM 218 included the UPU header 5108 in the Nausf_UPUProtection service operation, the UDM 218 indicates that the UPU header 5108 is protected, such as by including the UPU header protection indicator 4403 in the Nudm_SDM_Notification message 5813.

[0231] Upon receiving Nudm_SDM_Notification message 5813, AMF 212 sends DL NAS transmission message 5814 to UE 106. If received from UDM 218, AMF 212 includes a transparent container in the DL NAS transmission message 5814. Otherwise, if UDM 218 provides an individual IE, AMF 212 constructs a UPU transparent container. The transparent container can also pass the UPU header protection indicator 4403 to UE 106.

[0232] Upon receiving DL NAS transmission message 5814, UE 106 calculates UPU-MAC-I in the same manner as AUSF 210. AUSF And verify whether it matches the UPU-MAC-I received in DL NAS transmission message 5714. AUSF Value matching (i.e., within a transparent container). In this embodiment, UE 106 supports UPU header protection and can only derive the AUSF MAC based on UPU data 5104 and UPU header 5108. However, AUSF 210 derives the UPU-MAC-I based on UPU data 5104 instead of UPU header 5108. AUSF Therefore, UPU-MAC-I at UE 106 AUSF Verification failed.

[0233] If UDM 218 has requested acknowledgment from UE 106, then UE 106 sends UL NAS transport message 5815 to serving AMF 212. UE 106 formats or constructs the UPU transparent container, such as... Figure 45 The UPU transparent container IE 4500 is shown. UE 106 exports or generates UE MAC 4510 (i.e., UPU-MAC-I). UE The generated UE MAC 4510 is included in the transparent container of UL NAS transmission message 5815. In this embodiment, the UPU-MAC-I at UE 106 AUSF Verification failed. Therefore, as Figure 55 As shown, UE 106 derives UE MAC 4510 by inputting UPU acknowledgment 5514, set to a second value (e.g., "0x00"), into KDF 5500. Therefore, the value of UE MAC 4510 will differ from the UPU-XMAC-I derived by AUSF 210. UE .

[0234] Further, the UE 106 includes the UPU header protection indicator 4404 in the transparent container. In other words, the UE 106 sets the UPU header protection indicator 4404 (in the 2nd bit of the 4th octet) in the UPU header 4508 of the UPU transparent container IE 4500 to indicate whether the UE 106 supports UPU header protection when generating the AUSF MAC. In this embodiment, the UE 106 supports UPU header protection, so the UE 106 sets the UPU header protection indicator 4404 to a first value (e.g., “1”). The UE 106 sends the UL NAS transport message 5815 to the serving AMF 212 with the transparent container formatted as described above.

[0235] Upon receiving the UL NAS transport message 5815, the AMF 212 sends a Nudm_SDM_Info message 5816 to the UDM 218 with the UE MAC 4510 (i.e., UPU-MAC-I UE ) and the UPU header protection indicator 4404. If the transparent container with the UPU-MAC-I UE is received in the UL NAS transport message 5815, the AMF 212 sends the Nudm_SDM_Info message 5816 to the UDM 218 with the transparent container.

[0236] The UDM 218 receives the Nudm_SDM_Info message 5816 including the UPU transparent container from the AMF 212. The UDM 218 extracts the UE MAC 4510 and the UPU header protection indicator 4404 from the UPU transparent container and stores the UPU header protection indicator 4404, such as in the UDR.

[0237] The UDM 218 verifies the received UE MAC 4510 derived by the UE 106 against the expected UE MAC 5218 (i.e., UPU-XMAC-I UEThe UPU confirmation 5514 is compared, and the verification of the UPU confirmation 5514 is performed. If the received UE MAC 4510 and the expected UE MAC 5218 match, the UDM 218 successfully verifies the UPU confirmation 5514 and the success of the UE parameter update. If the received UE MAC 4510 and the expected UE MAC 5218 do not match, the UDM 218 does not successfully verify the UPU confirmation 5514 and identifies the failure of the UE parameter update. In this embodiment, the UE 106 derives the UE MAC 4510 by setting the UPU confirmation 5514 to a second value (e.g., “0x00”), and the UDM 218 will determine that the received UE MAC 4510 and the expected UE MAC 5218 do not match and the verification fails. In response to the verification of the UPU confirmation 5514 being unsuccessful (i.e., the UE parameter update failed), the UDM 218 processes the UPU header protection indicator 4404 stored for the UE 106 to determine that the UE 106 supports UPU header protection. The UDM 218 can then retry, redo, or repeat the UPU procedure with the AUSF MAC 5212 derived by the AUSF 210 based on the UPU data 5104 and the UPU header 5108.

[0238] One technical advantage is that the network can be compliant with UEs that support UPU header protection. The UDM 218 stores the UPU header protection indicator 4404 provided by the UE 106. When the UE parameter update fails due to the UE 106 supporting UPU header protection, the UDM 218 can retry the update with the AUSF MAC 5212 derived based on the UPU data 5104 and the UPU header 5108.

[0239] Any of the various elements or modules shown in the figures or described herein can be implemented as hardware, software, firmware, or some combination. For example, an element can be implemented as dedicated hardware. A dedicated hardware element can be referred to as a “processor,” “controller,” or some similar terminology. When provided by a processor, the functions can be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which can be shared. Moreover, explicit use of the term “processor” or “controller” should not be construed to refer exclusively to hardware capable of executing software, and can implicitly include, without limitation, digital signal processor (DSP) hardware, network processor, application specific integrated circuit (ASIC), or other circuitry, field programmable gate array (FPGA), read only memory (ROM) for storing software, random access memory (RAM), nonvolatile storage, logic or some other physical hardware component or module.

[0240] Furthermore, an element can be implemented as instructions executable by a processor or a computer to perform the functions of the element. Some examples of instructions are software, programs, code, and firmware. The instructions are operational when executed by the processor to direct the processor to perform the functions of the element. The instructions can be stored in a storage device, which is readable by the processor. Some examples of storage devices are digital or solid-state memories, magnetic storage media such as a magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media.

[0241] The term "circuitry" as used in this application can refer to one or more or all of the following: (a) hardware-only circuit implementations (such as implementations in only analog and / or digital circuitry) and (b) combinations of hardware circuits and software, such as (as applicable): (i) a combination of analog and / or digital hardware circuit(s) with software / firmware and (ii) any portions of hardware processor(s) with software (including digital signal processors) that work together to (c) hardware circuit(s) themselves, as well as any portions of hardware processor(s) with software (including digital signal processors), software, and memory(ies) that work together to

[0242] This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation that has a processor (or multiple processors) that can execute software that, when executed, transforms the processor into an apparatus for practicing the implementation. For example, a processor can receive software or firmware that transforms the processor into an apparatus for practicing an implementation. Any of the embodiments of this application (including any claims) can be implemented as software that, when executed, transforms a processor or computer into an apparatus for practicing the implementation. As a further example, as used in this application, the term circuitry also covers (a) combinations of hardware circuits and software, such as (as applicable): (i) combinations of analog and / or digital hardware circuit(s) with software / firmware and (ii) portions of hardware processor(s) with software (including digital signal processors), software, and memory(ies) that work together to

[0243] Although specific embodiments were described herein, the scope of the disclosure is not limited to these specific embodiments. The scope of the disclosure is defined by the following claims and any equivalents thereof.

Claims

1. A method of performing a UE parameter update (UPU) for a user equipment (UE), the method comprising: receiving, at the user equipment, a first UPU container from a network, the first UPU container comprising UPU data for the UE parameter update, and a first message authentication code that protects the UPU data; performing, at the user equipment, a verification of the first message authentication code; generating, at the user equipment, a UPU acknowledgement that indicates whether the verification was successful; deriving, at the user equipment, a second message authentication code based on the UPU acknowledgement; and sending, from the user equipment to the network, a second message that comprises a second UPU container that contains the second message authentication code, and a first indicator that indicates whether the user equipment supports UPU header protection.

2. The method of claim 1, wherein: the UPU acknowledgement comprises a variable parameter that indicates whether the verification at the user equipment was successful.

3. The method of claim 2, wherein deriving the second message authentication code comprises: inputting, at the user equipment, the UPU acknowledgement to a key derivation function; wherein the UPU acknowledgement is set to a first value when the verification at the user equipment is successful; wherein the UPU acknowledgement is set to a second value when the verification at the user equipment is not successful.

4. The method of claim 1, further comprising: setting, at the user equipment, the first indicator to a first value when the user equipment supports UPU header protection; and setting, at the user equipment, the first indicator to a second value when the user equipment does not support UPU header protection.

5. The method of claim 1, wherein: the second UPU container contains the first indicator in bit 2 of octet 4 of the second UPU container.

6. The method of claim 1, further comprising: receiving, at the user equipment, a second indicator from the network that indicates whether a UPU header is protected in the first message authentication code.

7. The method of claim 6, further comprising: performing, at the user equipment, the verification of the first message authentication code based on the UPU header when the second indicator indicates that the UPU header is protected in the first message authentication code; and performing, at the user equipment, the verification of the first message authentication code excluding the UPU header when the second indicator indicates that the UPU header is not protected in the first message authentication code.

8. The method of claim 1, further comprising: receiving, at a unified data management (UDM) of the network, the second UPU container; extracting, at the UDM, the second message authentication code and the first indicator from the second UPU container; performing, at the UDM, a verification of the second message authentication code; and storing the first indicator.

9. The method of claim 8, further comprising: triggering, at the UDM, the UE parameter update; ​ ​ ​ determining, at the UDM, whether the user equipment supports UP header protection; when the user equipment supports UP header protection, including a UP header in a request to an authentication server function (AUSF) to derive the first message authentication code; and when the user equipment does not support UP header protection, excluding the UP header from the request to the AUSF.

10. The method of claim 9, further comprising: when the first indicator indicates that the user equipment supports UP header protection, performing, at the UDM, a subsequent UP procedure with the first message authentication code derived based on the UP data and a UP header.

11. The method of claim 9, further comprising: when the verification of the second message authentication code is unsuccessful, retrying, at the UDM, the UE parameter update with the first message authentication code derived based on capabilities of the user equipment indicated by the first indicator.

12. A user equipment configured to receive a UE parameter update (UPU), the user equipment comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the user equipment to at least: receive, from a network, a first UP container comprising UP data for the UE parameter update and a first message authentication code protecting the UP data; perform a verification of the first message authentication code; generate a UP confirmation indicating whether the verification is successful; derive a second message authentication code based on the UP confirmation; and send, to the network, a second message comprising a second UP container containing the second message authentication code and a first indicator indicating whether the user equipment supports UP header protection.

13. The user equipment of claim 12, wherein the UP confirmation comprises a variable parameter indicating whether the verification at the user equipment is successful.

14. The user equipment of claim 13, wherein the instructions, when executed by the at least one processor, further cause the user equipment to at least: input the UP confirmation to a key derivation function to derive the second message authentication code; wherein the UP confirmation is set to a first value when the verification at the user equipment is successful; wherein the UP confirmation is set to a second value when the verification at the user equipment is unsuccessful.

15. The user equipment of claim 12, wherein the instructions, when executed by the at least one processor, further cause the user equipment to at least: set the first indicator to a first value when the user equipment supports UP header protection; and set the first indicator to a second value when the user equipment does not support UP header protection.

16. The user equipment of claim 12, wherein ​ The second message includes a second UPU container that contains the first indicator in bit 2 of octet 4 of the second UPU container.

17. The user equipment of claim 12, wherein the instructions, when executed by the at least one processor, further cause the user equipment to at least: receive, from the network, a second indicator that indicates whether a UPU header is protected in the first message authentication code.

18. The user equipment of claim 17, wherein the instructions, when executed by the at least one processor, further cause the user equipment to at least: perform the verification of the first message authentication code based on the UPU header when the second indicator indicates that the UPU header is protected in the first message authentication code; and perform the verification of the first message authentication code excluding the UPU header when the second indicator indicates that the UPU header is not protected in the first message authentication code.

19. A unified data management (UDM) element configured to perform a user equipment (UE) parameter update (UPU) for a user equipment, the UDM element comprising: at least one processor; and at least one memory that stores instructions, which when executed by the at least one processor, cause the UDM element to at least: receive a UPU container that contains a first message authentication code derived by the user equipment based on a UPU confirmation regarding the UE parameter update and a first indicator that indicates whether the user equipment supports UPU header protection; extract the first message authentication code and the first indicator from the UPU container; perform a verification of the first message authentication code; and store the first indicator.

20. The UDM element of claim 19, wherein the instructions, when executed by the at least one processor, further cause the UDM element to at least: trigger the UE parameter update; determine whether the user equipment supports UPU header protection; include a UPU header in a request to an authentication server function (AUSF) to derive a second message authentication code when the user equipment supports UPU header protection; and exclude the UPU header from the request to the AUSF when the user equipment does not support UPU header protection.

21. The UDM element of claim 20, wherein the instructions, when executed by the at least one processor, further cause the UDM element to at least: process the first indicator to determine whether the user equipment supports UPU header protection.

22. The UDM element of claim 20, wherein the instructions, when executed by the at least one processor, further cause the UDM element to at least: send, to the user equipment via one or more network functions, a second indicator that indicates whether the UPU header is protected in the second message authentication code. ​ 23. The UDM element of claim 20, wherein the instructions, when executed by the at least one processor, further cause the UDM element to at least: when the first indicator indicates that the user equipment supports UPU header protection, perform a subsequent UPU procedure with the second message authentication code derived based on the UPU data and the UPU header.

24. The UDM element of claim 20, wherein the instructions, when executed by the at least one processor, further cause the UDM element to at least: when the verification of the first message authentication code is unsuccessful, retry the UE parameter update with the second message authentication code derived based on capabilities of the user equipment indicated by the first indicator.

Images