Enhanced UE parameter update (UPU) procedure

Abstract

Systems, methods, and software to perform UE parameter updates (UPUs) of a user equipment. In an embodiment, the AUSF receives, from the UDM, a UPU protection request message regarding a UE parameter update, where the UPU protection request message includes UPU information, the UPU information including UPU data and a UPU header. The AUSF determines whether the user equipment supports UPU header protection in the derivation of the message authentication code based on the UPU header protection indicator in the UPU protection request message. When the user equipment supports UPU header protection, the AUSF derives a message authentication code based on the UPU header, and transmits a UPU protection response message including the message authentication code to the UDM.

Description

Technical Field

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

[0002] Next generation networks, such as fifth generation (5G), represent the next major step in mobile telecommunication standards beyond fourth generation (4G) standards. Compared to 4G networks, next generation networks may feature enhancements in radio access and network architecture. Next generation networks are intended to utilize new areas of the radio spectrum for radio access networks (RANs), such as the millimeter wave band.

[0003] As mobile networks become more widely used across the country and around the world, communications may be subject to interception or other types of attacks. To ensure security and privacy, the Third Generation Partnership Project (3GPP) has developed security mechanisms for 5G mobile networks and security procedures to be performed within them. One of the security procedures between a user equipment (UE) and a 5G mobile network is 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 in subsequent security procedures between the UE and the serving network.

[0004] After primary authentication, the UE's configuration parameters may be updated at any time by the 5G mobile network using the UE Parameter Update (UPU) procedure. However, some of the protection mechanisms for the UE parameter update procedure may be inefficient or not fully defined, and may require identification improvements. Summary of the Invention

[0005] This document describes an enhanced UE parameter update (UPU) procedure. 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 regarding the use of the UPU header when deriving the MAC, which is also referred to as UPU-MAC-I in the 3GPP technical specification (TS). AUSF During the UE parameter update process, the Authentication Server Function (AUSF) derives the UPU-MAC-I AUSF , and UPU-MAC-I AUSF Together with the UPU data, it is passed to the UE for updating. The UE derives its own UPU-MAC-I AUSF version, and the derived UPU-MAC-I AUSF Version and UPU-MAC-I received from the network AUSF If they match, the UE verifies the UE parameter update. In order for the MAC verification to pass, the AUSF and UE need to derive the same UPU-MAC-IAUSF However, in the current UE parameter update process, it is not clear whether the UPU header is used to calculate the UPU-MAC-I AUSF , because the UPU header is an optional attribute.

[0006] In the embodiments described herein, an enhanced UE parameter update procedure is described, in which the following parameters are specified when deriving the UPU-MAC-I AUSF The UPU header is used when calculating the UPU-MAC-I. AUSF The UPU header is used when calculating the UPU-MAC-I or the UDM is notified whether to calculate the UPU-MAC-I AUSF At the same time, the UE is configured to use the UPU header when calculating the UPU-MAC-I AUSF When using the UPU header, or being notified by the 5G core network whether to calculate the UPU-MAC-I AUSF Therefore, between AUSF and UE, the UPU header is used to calculate UPU-MAC-I. AUSF The technical benefit is that the UE parameter update process and the protection mechanism during the UE parameter update process are improved.

[0007] In an embodiment, an AUSF element of a 5G core network includes at least one processor and at least one memory storing instructions, wherein when the instructions are executed by the at least one processor, the AUSF element at least: for a UE parameter update (UPU) of a user equipment, receives a UPU protection request message from a UDM regarding a UE parameter update for the user equipment, wherein the UPU protection request message includes UPU information, and the UPU information includes UPU data and a UPU header. The at least one processor also causes the AUSF element to at least: determine whether the user equipment supports UPU header protection in derivation of a message authentication code based on a UPU header protection indicator in the UPU protection request message; when the user equipment supports UPU header protection, derive the message authentication code based on the UPU header; and send a UPU protection response message including the message authentication code to the UDM.

[0008] In an embodiment, an AUSF element of a 5G core network includes at least one processor and at least one memory storing instructions, wherein when the instructions are executed by the at least one processor, the AUSF element at least: for a UE parameter update (UPU) of a user equipment, receives a UPU protection request message from a UDM regarding a UE parameter update for the user equipment, wherein the UPU protection request message includes UPU information, and the UPU information includes UPU data and a UPU header. The at least one processor also causes the AUSF element to at least: derive a first message authentication code based on the UPU data and excluding the UPU header; derive a second message authentication code based on the UPU header; and send a UPU protection response message to the UDM, wherein the UPU protection response message includes the first message authentication code and the second message authentication code.

[0009] Other embodiments may include computer-readable media, other systems, or other methods as described below. The various features of the different embodiments may be combined in various ways, with some features included and others excluded, to suit a variety of different applications.

[0010] The above summary provides a basic understanding of some aspects of this specification. This summary is not a comprehensive overview of this specification. It is not intended to identify key or important elements of this specification, nor is it intended to define any scope of the specific embodiments of this specification or any scope of the claims. Its sole purpose is to present some concepts of this specification in a simplified form as a prelude to the more detailed description that follows. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Some embodiments of the present invention will now be described by way of example only and with reference to the accompanying drawings.In all drawings, the same reference number represents the same element or the same type of element.

[0012] Figure 1 The diagram illustrates the high-level architecture of a 5G system.

[0013] Figure 2 The diagram illustrates the non-roaming architecture of the 5G system.

[0014] Figure 3 is a signaling diagram illustrating the initiation of primary authentication.

[0015] Figure 4 is a signaling diagram illustrating the authentication process.

[0016] Figure 5 is a signaling diagram illustrating the UE parameter update procedure.

[0017] Figure 6 is a block diagram of a UDM in an illustrative embodiment.

[0018] Figure 7is a block diagram of an AUSF in an illustrative embodiment.

[0019] Figure 8 is a block diagram of an AMF in an illustrative embodiment.

[0020] Figure 9 is a block diagram of a user equipment (UE) in an illustrative embodiment.

[0021] Figure 10A is a message diagram illustrating a UE parameter update procedure in an illustrative embodiment.

[0022] Figure 10B An extension to the Nausf_UPUProtection service in an illustrative embodiment is illustrated to include a UPU header protection indicator.

[0023] Figure 11-13 and Figures 14A-14B is a flow chart illustrating a method of performing a UE parameter update procedure in an illustrative embodiment.

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

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

[0026] Figure 17-18 is a block diagram illustrating the derivation of the AUSF MAC in an illustrative embodiment.

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

[0028] Figure 20 is a block diagram illustrating a UPU transparent container in an illustrative embodiment.

[0029] Figure 21 is a block diagram of a UPU header of a UPU transparent container in an illustrative embodiment.

[0030] Figure 22 is a block diagram illustrating a UPU transparent container in an illustrative embodiment.

[0031] Figure 23A is a message diagram illustrating a UE parameter update procedure in an illustrative embodiment.

[0032] Figure 23B FIGURE 1 illustrates an extension of the Nausf_UPUProtection service to include enhanced UPU-MAC-I in an illustrative embodiment.AUSF .

[0033] Figure 24-27 is a flow chart illustrating a method of performing a UE parameter update procedure in an illustrative embodiment.

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

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

[0036] Figure 30 is a block diagram illustrating the derivation of a conventional AUSF MAC in an illustrative embodiment.

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

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

[0039] Figure 33 is a block diagram illustrating a conventional UPU transparent container in an illustrative embodiment.

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

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

[0042] Figure 36 Illustrated is a modified “UpuSecurityInfo” data type for use with the Nausf_UPU protection service API in an illustrative embodiment.

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

[0044] Figure 38-Figure 39 In the illustrative embodiment, Figure 24-27 A flow chart of additional details of the method is provided.

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

[0046] Figure 41 Illustrated is a modified “UpuInfo” data type for the Nausf_UPU protection service API in an illustrative embodiment.

[0047] Figures 42A-42B Illustrated is an “enhancedUpuInfo” data type for use with the Nausf_UPU protection service API in an illustrative embodiment.

[0048] Figure 43 Another modified “UpuInfo” data type for the Nausf_UPU protection service API in an illustrative embodiment is illustrated. DETAILED DESCRIPTION

[0049] The accompanying drawings and the following description illustrate specific exemplary embodiments. Therefore, it should be understood that those skilled in the art will be able to design various arrangements that, although not explicitly described or shown herein, embody the principles of the embodiments and are included within the scope of the embodiments. In addition, any examples described herein are intended to aid in understanding the principles of the embodiments and should be interpreted as not being limited to such specifically enumerated examples and conditions. As a result, the present invention(s) are not limited to the specific embodiments or examples described below, but are limited by the claims and their equivalents.

[0050] Figure 1The 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 may include an NG-RAN, a non-3GPP access network, or another type of RAN connected to the 5GC 104. The access network 102 may 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. 5GC 104 includes a network function (NF) 110, which can be implemented as a network element on dedicated hardware, a software instance running on dedicated hardware, a virtualized function instantiated on an appropriate platform (e.g., cloud infrastructure), etc. The data network 108 can be a public or private data network external to the operator, or a data network internal to the operator (e.g., for IMS services). UE 106 (also referred to as a mobile terminal) is a device with 5G capabilities that is configured to register with 5GC 104 to access services. UE 106 can be an end-user device, such as a mobile phone (e.g., a smartphone), a tablet, a computer with a mobile broadband adapter, etc. UE 106 can be enabled for voice services, data services, machine-to-machine (M2M) or machine-type communication (MTC) services, and / or other services.

[0051] Figure 2 A non-roaming architecture 200 of a 5G system is illustrated. Figure 2The architecture 200 is a service-based representation, as further described in 3GPP TS 23.501 (v18.0.0), which is incorporated herein by reference as if fully incorporated herein. The architecture 200 includes 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 can access the control plane and the user plane of the core network 104 through the (R)AN 102.

[0052] There are a large number of subscribers able to access services from carriers implementing mobile networks including the 5G system 100, such as Figure 1-Figure 2 Communications between a subscriber (i.e., via a UE) and a mobile network are protected by security mechanisms, such as those standardized by 3GPP. Subscribers and carriers expect security mechanisms to provide assurance. One of the security mechanisms is a primary authentication process that provides mutual authentication between the UE and the network. Primary authentication is also described below.

[0053] The purpose of the primary authentication and key agreement process is to enable mutual authentication between the UE 106 and the network and to provide key material that can be used in subsequent security procedures between the UE 106 and the serving network. The key material generated by the primary authentication and key agreement process is called K SEAFAnchor key for a key, which is provided by the AUSF 210 of the home network to the Security Anchor Function (SEAF) of the serving network. The SEAF provides authentication functionality via the AMF 212 in the serving network and supports primary authentication using a Subscription Hidden Identifier (SUCI) containing a Hidden Subscription Permanent Identifier (SUPI). SUPI is a globally unique 5G identifier assigned to each subscriber in the 5G system 100. The SUCI includes the following items: SUPI type, Home Network Identifier (HN-ID) that identifies the subscriber's home network, Routing Indicator (RID) assigned to the subscriber by the home network operator and provisioned in the Universal Subscriber Identity Module (USIM) of the UE, Protection Scheme Identifier, Home Network Public Key Identifier, and Scheme Output. Anchor key K SEAF From the so-called K AUSF The intermediate key of the key is used to derive K AUSF Keys are established between the UE 106 and the home network as a result of the primary authentication process.

[0054] Figure 33GPP TS 33.501 (v18.0.0), which is incorporated herein by reference as if fully incorporated herein, is a signaling diagram illustrating the initiation of primary authentication. The UE 106 sends an N1 message 311 (i.e., an initial non-access stratum (NAS) message), such as a Registration Request, to the serving network (e.g., the serving network's AMF 212). The UE 106 uses the SUCI or 5G Globally Unique Temporary Identifier (5G-GUTI) in the Registration Request. The SEAF 302 of the AMF 212 can initiate authentication with the UE 106 during any process of establishing a signaling connection with the UE 106. The SEAF 302 invokes the Nausf_UEAuthentication service by sending a Nausf_UEAuthentication_Authenticate request message 312 to the AUSF 210 to initiate authentication. The Nausf_UEAuthentication_Authenticate request message 312 includes the SUCI or SUPI and the serving network name (SN name). After receiving the Nausf_UEAuthentication_Authenticate request message 312, the AUSF 210 checks whether the requesting SEAF 302 in the serving network is authorized to use the serving network name in the Nausf_UEAuthentication_Authenticate request message 312 by comparing the serving network name with the expected serving network name. If the serving network is authorized to use the serving network name, the AUSF 210 sends a Nudm_UEAuthentication_Get request message 313 to the UDM 218. The Nudm_UEAuthentication_Get request message 313 includes the SUCI or SUPI and the serving network name. After receiving the Nudm_UEAuthentication_Get request message 313, the UDM 218 identifies the SUPI (if received) or calls the Subscription Identifier Dehiding Function (SIDF), which dehides the SUPI (if received) from the SUCI. The UDM 218 (or the Authentication Credentials Repository and Processing Function (ARPF) of the UDM 218) selects or chooses an authentication method for primary authentication based on the SUPI.

[0055] Figure 4is a signaling diagram illustrating the main authentication process such as described in 3GPP TS 33.501. In this example, 5G Authentication and Key Agreement (AKA) is described, but similar concepts also 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 K AUSF The UDM 218 creates a key that includes the authentication token (AUTN), the expected response (XRES*), K AUSF The UDM 218 then sends a Nudm_UEAuthentication_Get response message 411 to the AUSF 210, which has the 5G HE AV to be used for authentication (e.g., Figure 4 In the case where SUCI is included in the Nudm_UEAuthentication_Get request, the UDM 218 includes the SUPI in the Nudm_UEAuthentication_Get response message 411 after dehiding the SUPI from the SUCI. If the subscriber has an Authentication and Key Management for Applications (AKMA) subscription, the UDM 218 includes an AKMA indication and a RID in the Nudm_UEAuthentication_Get response message 411.

[0056] In response to the Nudm_UEAuthentication_Get response message 411, the AUSF 210 temporarily stores the expected response (XRES*) and the received SUCI or SUPI. The AUSF 210 then generates a 5G authentication vector (5G AV) based on the 5G HE AV received from the UDM 218 by calculating a hashed expected response (HXRES*) based on the expected response (XRES*) and hashing the hashed expected response (HXRES*) based on the K AUSF Key calculation K SEAF Key, and replace XRES* with HXRES* in 5G HE AV and use K SEAF Key replacement K AUSF Key. AUSF 210 removes K SEAFThe AUSF 210 uses the key to generate a 5G Service Environment Authentication Vector (5G SE AV), which includes an authentication token (AUTN), a hashed expected response (HXRES*), and a random challenge (RAND). The AUSF 210 sends a Nausf_UEAuthentication_Authenticate response message 412 including the 5G SE AV to the SEAF 302. In response, the SEAF 302 sends the authentication token (AUTN) and random challenge (RAND) to the UE 106 in a NAS Message Authentication Request message 413.

[0057] although Figure 4 4. Not shown in the figure, but 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 value by checking whether the authentication token (AUTN) can be accepted. If so, the USIM calculates 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 calculates RES* from RES and calculates K from CK||IK AUSF key, and according to K AUSF Key to calculate K SEAF key.

[0058] UE 106 sends a NAS message authentication response message 414 including RES* to SEAF 302. In response, SEAF 302 calculates HRES* based on RES* and compares HRES* with HXRES*. If they match, SEAF 302 considers authentication successful from the perspective of the serving network. SEAF 302 sends the RES* received from UE 106 to AUSF 210 in a Nausf_UEAuthentication_Authenticate request message 415. When AUSF 210 receives the Nausf_UEAuthentication_Authenticate request message 415 including RES* as authentication confirmation, AUSF 210 stores K based on the policy of the home network operator. AUSFThe AUSF 210 receives the key and compares the received RES* with the stored XRES*. If RES* and XRES* are equal, the AUSF 210 considers the authentication successful from the perspective of the home network. The AUSF 210 notifies the UDM 218 of the authentication result (not shown). The AUSF 210 also sends a Nausf_UEAuthentication_Authenticate response message 416 to the SEAF 302, which indicates whether the authentication is successful from the perspective of the home network. If the authentication is successful, K SEAF The key is sent to the SEAF 302 in a Nausf_UEAuthentication_Authenticate response message 416. In case the AUSF 210 receives 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 is successful.

[0059] 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 may decide to perform a UE parameter update at any time after the UE 106 is successfully authenticated and registered with the 5G system 100, as described in Section 6.15.2 of 3GPP TS 33.501. Figure 5 is a signaling diagram illustrating a UE parameter update procedure. In the example, the UDM 218 decides to perform a UE parameter update (UPU) procedure using control plane procedures when the UE 106 is registered with the 5G system 100. If the ultimate consumer of any UE parameters to be updated (e.g., updated RID) is the USIM of the UE 106, the UDM 218 updates the parameters stored on the USIM using a secure packet mechanism to protect these parameters. The UDM 218 prepares UE parameter update data (UPU data) by including parameters protected by the secure packet (if any) and any UE parameters for which the ultimate consumer is the ME of the UE 106.

[0060] The AUSF 210 provides the UPU Protection service as described in 3GPP TS 29.509 (v18.0.0), which is incorporated herein by reference as if fully incorporated herein. The AUSF 210 acts as an NF service producer that provides the UPU Protection service to NF service consumers. The UPU Protection service provides the UPU-MAC-I to NF service consumers (e.g., UDM 218). AUSFand Counter UPU , to protect UPU data from being tampered with or removed. Optionally, the UPUProtection service also provides UPU-XMAC-I to NF service consumers (e.g., UDM 218). UE , which allows the NF service consumer to verify that the UPU data is correctly received by the UE 106. The UDM 218 invokes the Nausf_UPUProtection service by sending a 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 acknowledges a 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 511 to signal that it also requires the expected UPU-XMAC-I. UE .

[0061] AUSF 210 uses the UE-specific home key (K AUSF ) and the UPU data received from the UDM 218 to calculate or derive the UPU-MAC-I AUSF , and in the Nausf_UPUProtection response message 512, UPU-MAC-I AUSF and Counter UPU Delivered to UDM 218. If the ACK indication is present in the Nausf_UPUProtection request message 511, the AUSF 210 calculates or derives the UPU-XMAC-I UE , and returns the calculated UPU-XMAC-I in the Nausf_UPUProtection response message 512 UE Expected UPU-XMAC-I UE This allows the UDM 218 to verify that the UE 106 received the UPU data correctly.

[0062] The UDM 218 then calls the Nudm_SDM_Notification service operation and sends a Nudm_SDM_Notification message 513 to the AMF 212, which includes a UPU transparent container (if the AMF 212 supports UPU transparent container) or a separate information element (IE) including UPU data, UPU-MAC-I AUSFand Counter UPU If the UDM 218 requests confirmation, it temporarily stores the expected UPU-XMAC-I UE After receiving the Nudm_SDM_Notification message 513, the AMF 212 sends a downlink (DL) NAS transport message 514 to the UE 106. If a transparent container is received from the UDM 218, the AMF 212 includes the transparent container in the DL NAS transport message 514. Otherwise, if the UDM 218 provides a separate IE, the AMF 212 constructs a UPU transparent container.

[0063] Upon receiving the DL NAS transport message 514, the UE 106 calculates the received UPU data and the Counter UPU , calculate UPU-MAC-I in the same way as AUSF 210 AUSF and verifies that it matches the UPU-MAC-I received in the DL NAS transport message 514 (ie, in the transparent container). AUSF If the UPU-MAC-I AUSF If the authentication of UPU-MAC-I succeeds and the UPU data contains any parameters protected by the security packet, the ME of UE 106 forwards the security packet to the USIM. AUSF If the verification is successful and the UPU data contains any parameters that are not protected by a security packet, the ME of UE 106 updates its stored parameters with the parameters received in the UDM update data.

[0064] 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 uplink (UL) NAS transport message 515 to the serving AMF 212. The UE 106 generates a UPU-MAC-I UE , and the generated UPU-MAC-I UE The AMF 212 sends a UPU-MAC-I packet to the UDM 218. UE Nudm_SDM_Info message 516. If it has UPU-MAC-I UE If the transparent container is received in the UL NAS transport message 515, the AMF 212 sends a Nudm_SDM_Info message 516 with the transparent container to the UDM 218. If the UDM 218 indicates that the UE 106 will confirm the successful security check of the received UPU data, the UDM 218 sends the received UPU-MAC-IUE Expected UPU-XMAC-I with UDM 218 temporary storage UE The comparison is performed to verify that the UE 106 successfully received the UPU data.

[0065] For UPU operation, AUSF 210 and UE 106 use a 16-bit counter Counter UPU With K AUSF The key is associated and in K AUSF Maintain a Counter during the life of the key UPU When the newly derived K AUSF When the key is stored, UE 106 will Counter UPU Initialized to 0x00 0x00 and store Counter UPU If the USIM of UE 106 supports both 5G parameter storage and 5G parameter extension storage, then Counter UPU is stored in the USIM. Otherwise, Counter UPU Stored in the non-volatile memory of the ME.

[0066] To generate UPU-MAC-I AUSF , AUSF 210 uses Counter UPU For UPU-MAC-I AUSF For each new calculation, AUSF 210 increments Counter UPU . Counter UPU Used as UPU-MAC-I AUSF and UPU-MAC-I UE The freshness of the derived input is used to mitigate replay attacks. AUSF 210 will UPU The value (used to generate UPU-MAC-I AUSF ) and UPU-MAC-I AUSF UE 106 only accepts the value greater than the stored Counter. UPU Counter of value UPU If the received UPU-MAC-I AUSF If the verification is successful, UE 106 uses the received Counter UPU To update the stored Counter UPU UE 106 derives UPU-MAC-I for UPU confirmation UE Use the Counter received from UDM 218 UPU .

[0067] When the newly derived K AUSF When the counter is stored, the AUSF 210 supporting UE parameter update using control plane procedures UPU Initialized to 0x00 0x01. AUSF 210 calculates UPU-MAC-I in the first AUSF Then Counter UPU Set to 0x00 0x02, and for each additional calculated UPU-MAC-I AUSF Monotonically increasing Counter UPU If the K AUSF Associated Counter UPU If loopback is about to occur, the AUSF 210 suspends the UE parameter update protection service for the UE 106. When a fresh K is generated for the UE 106 AUSF When the Counter at AUSF 210 UPU is reset to 0x00 0x01, as described above, and the AUSF 210 resumes the UE parameter update protection service for the UE 106.

[0068] One problem with the current UE parameter update process is the derivation of UPU-MAC-I AUSF Typically, message authentication methods at the control plane use a message authentication code (MAC) to verify the authentication of a message. For example, a device receiving a message derives a MAC for the received message and compares the derived MAC with the MAC received in the message. If the MACs match, the message is authenticated. If the MACs do not match, the message is typically discarded and retransmission is requested. In order to pass MAC verification during the UE parameter update procedure, the AUSF 210 and the UE 106 need to derive the same MAC (UPU-MAC-I) from the same data. AUSF ). However, the data model for UPU protection service described in 3GPP TS29.509 provides an optional UPU header (see Section 6.3.6.2.2). Therefore, when requesting UPU-MAC-I AUSF and Counter UPU When the UDM 218 sends the UPU header, it may or may not send the UPU header to the AUSF 210. This leads to the question of whether the AUSF 210 is to derive the UPU-MAC-I based on the UPU header. AUSF confusion.

[0069] For example, if the AUSF 210 derives UPU-MAC-I based on the UPU data AUSF , then UPU data is subject to UPU-MAC-I AUSFIn other words, UE 106 can be based on UPU-MAC-I AUSF To authenticate the UPU data. However, it may be beneficial to protect the UPU header. To protect the UPU header in a similar manner to the UPU data, the AUSF 210 will derive the UPU-MAC-I based on the UPU header. AUSF .

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

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

[0072] Figure 6 is a block diagram of the UDM 218 in an illustrative embodiment. The UDM 218 is a network element or network function configured to manage network user data within the 5G core network 104. In this embodiment, the UDM 218 includes the following subsystems: a network interface component 602 operating on one or more platforms and a data management controller 604. The network interface component 602 may 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 may operate using various protocols or reference points. The data management controller 604 may include circuitry, logic, hardware, components, etc. configured to support the services, operations, processes, or functions of the UDM.

[0073] One or more subsystems of the UDM 218 may be implemented on a hardware platform that includes analog and / or digital circuitry. For example, the data management controller 604 may 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 may include a collection of one or more processors or may include multiple processor cores, depending on the particular implementation. The memory 632 is a non-transitory computer-readable storage medium for data, instructions, applications, etc., and is accessible by the processors 630. The memory 632 is a hardware storage device capable of temporarily and / or permanently storing information. The memory 632 may include random access memory or any other volatile or non-volatile storage device. One or more subsystems of the UDM 218 may be implemented on a cloud computing platform or another type of processing platform.

[0074] UDM 218 may include Figure 6 Various other components not specifically shown.

[0075] Figure 7 is a block diagram of the AUSF 210 in an illustrative embodiment. The AUSF 210 is a network element or network function configured to perform authentication with a UE. In this embodiment, the AUSF 210 includes the following subsystems: a network interface component 702 and an authentication controller 704 operating on one or more platforms. The network interface component 702 may 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 may operate using various protocols or reference points. The authentication controller 704 may include circuitry, logic, hardware, components, etc. configured to support the operations, processes, or functions of the AUSF.

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

[0077] AUSF 210 may include Figure 7 Various other components not specifically shown.

[0078] Figure 8is a block diagram of the AMF 212 in an illustrative embodiment. The AMF 212 is a network element or network function configured to provide registration management for UEs. In this embodiment, the AMF 212 includes the following subsystems: a network interface component 802 and an access and mobility controller 804 operating on one or more platforms. The network interface component 802 may 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 may operate using various protocols or reference points. The access and mobility controller 804 may include circuitry, logic, hardware, components, etc. configured to support the operations, processes, or functions of the AMF.

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

[0080] AMF 212 may include Figure 8 Various other components not specifically shown.

[0081] Figure 9is a block diagram of a UE 106 in an illustrative embodiment. From a functional perspective, the UE 106 includes 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, memory 906, and a user interface component 908. The UE 106 may 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 may 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 may be configured to execute instructions 940 for software loaded into the memory 906. The processor 904 may execute an operating system (OS) 934 for the UE 106, which manages hardware and software resources and one or more applications. The processor 904 may implement an update controller 936 configured to perform UE parameter updates. The user interface component 908 is a hardware component for interacting with a terminal user. For example, the user interface component 908 may include a display 950, a screen, a touch screen, etc. (e.g., a liquid crystal display (LCD), a light-emitting diode (LED) display, etc.). The user interface component 908 may include a keyboard or keypad 952, a tracking device (e.g., a trackball or trackpad), a speaker, a microphone, etc.

[0082] 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 the subscriber's subscription. The subscription profile may include various information, such as a subscription certificate (e.g., SUPI) used to uniquely identify the subscription and mutually authenticate the UE 106 and the network.

[0083] UE 106 may include Figure 9 Various other components not specifically shown.

[0084] Example 1

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

[0086] In an 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, for example, a unified data repository (UDR). The UDM 218 decides to perform a UE parameter update (UPU) using a control plane procedure when the UE 106 is registered with the 5G system 100. If the ultimate consumer of any UE parameters to be updated (e.g., an updated RID) is the USIM of the UE 106, the UDM 218 updates the parameters stored on the USIM using a secure packet mechanism to protect these parameters. The UDM 218 prepares UE parameter update data (UPU data) by including parameters protected by the secure packet (if any) and any UE parameters whose ultimate consumer is the ME of the UE 106.

[0087] The UDM 218 invokes the Nausf_UPUProtection service by sending a Nausf_UPUProtection request message 1011 to the AUSF 210 to obtain the UPU-MAC-I AUSF and Counter UPUThe 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 acknowledges a 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 1011 to signal that it also requires the expected 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 (ie, in the Nausf_UPUProtection request message 1011).

[0088] AUSF 210 uses the UE-specific home key (K AUSF ) Calculate or derive UPU-MAC-I AUSF , and in the Nausf_UPUProtection response message 1012, UPU-MAC-I AUSF and Counter UPU Delivered to the UDM 218. When the UPU header protection indicator 1003 is present and set to true (i.e., the UE 106 supports UPU header protection) in the Nausf_UPUProtection request message 1011, the AUSF 210 calculates or derives the UPU-MAC-I based at least in part on the UPU header. AUSF In UPU-MAC-I AUSF Including the UPU header in the calculation of the AUSF 210 allows the UE 106 to verify that the UPU header has not been tampered with by any intermediary. When the UPU header protection indicator 1003 is not present or is set to false (e.g., in the Nausf_UPUProtection request message 1011), the AUSF 210 calculates or derives the UPU-MAC-I based on the UPU data and excluding the UPU header. AUSF In UPU-MAC-I AUSF Including the UPU data in the calculation of MAC-I allows the UE 106 to verify that the UPU data has not been tampered with by any intermediary. If the ACK indication is present in the Nausf_UPUProtection request message 1011, the AUSF 210 calculates or derives UPU-XMAC-I UE , and returns the calculated UPU-XMAC-I in the Nausf_UPUProtection response message 1012 UE Expected UPU-XMAC-I UEThis allows the UDM 218 to verify that the UE 106 received the UPU data correctly.

[0089] The UDM 218 then calls the Nudm_SDM_Notification service operation and sends a Nudm_SDM_Notification message 1013 to the AMF 212, which includes a UPU transparent container (if the AMF 212 supports UPU transparent container) or a separate information element (IE) including UPU data, UPU-MAC-I AUSF and Counter UPU If the UDM 218 requests confirmation, it temporarily stores the expected UPU-XMAC-I UE After receiving the Nudm_SDM_Notification message 1013, the AMF 212 sends a DL NAS transport message 1014 to the UE 106. If a transparent container is 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 a separate IE, the AMF 212 constructs a UPU transparent container.

[0090] Upon receiving the DL NAS transport message 1014, the UE 106 calculates the received UPU data and the Counter UPU , calculate UPU-MAC-I in the same way as AUSF 210 AUSF and verifies that it matches the UPU-MAC-I received in the DL NAS transport message 1014 (ie, in the transparent container). AUSF If the UPU-MAC-I AUSF If the authentication of UPU-MAC-I succeeds and the UPU data contains any parameters protected by the security packet, the ME of UE 106 forwards the security packet to the USIM. AUSF If the verification is successful and the UPU data contains any parameters that are not protected by a security packet, the ME of UE 106 updates its stored parameters with the parameters received in the UDM update data.

[0091] 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 a UL NAS transport message 1015 to the serving AMF 212. The UE 106 generates a UPU-MAC-I UE , and the generated UPU-MAC-I UEThe AMF 212 sends a UPU-MAC-I packet to the UDM 218. UE Nudm_SDM_Info message 1016. If it has UPU-MAC-I UE If the transparent container is received in the UL NAS transport message 1015, the AMF 212 sends a Nudm_SDM_Info message 1016 with the transparent container to the UDM 218. If the UDM 218 instructs the UE 106 to confirm the successful security check of the received UPU data, the UDM 218 sends the received UPU-MAC-I UE Expected UPU-XMAC-I with UDM 218 temporary storage UE The comparison is performed to verify that the UE 106 successfully received the UPU data.

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

[0093] Figure 11-13 and Figures 14A-14B 1 is a flow chart illustrating a method 1100 for performing a UE parameter update procedure in an illustrative embodiment. Figure 6 UDM 218 describes Figure 11 The steps of method 1100 will be referred to as Figure 7AUSF 210 describes Figure 12 The steps of method 1100 will be referred to as Figure 8 AMF 212 in Figure 13 The steps of method 1100 and will refer to Figure 9 UE 106 in the description Figures 14A-14B Those skilled in the art will appreciate that method 1100 may be performed in other systems, devices, or network functions. The steps of the flowcharts described herein are not exhaustive and may include other steps not shown, and these steps may be performed in an alternative order.

[0094] exist Figure 11 In the embodiment of the present invention, the data management controller 604 of the UDM 218 triggers a UE parameter update (UPU) for the UE 106 (step 1102), such as for RID update, network slice selection assistance information (NSSAI) update, etc. In other words, when the UE 106 is registered with the 5G system 100, the data management controller 604 decides to use the control plane procedure to perform the UE parameter update. After triggering the UE parameter update, the data management controller 604 calls the UPU protection service (e.g., Nausf_UPU protection) to the AUSF 210 and generates a request AUSF MAC (i.e., UPU-MAC-I). AUSF ) and UPU counter (i.e., Counter UPU ) (e.g., Nausf_UPUProtection request message) (step 1104). The data management controller 604 of the UDM 218 is configured to include the SUPI for the UE 106, the UPU information for UE parameter update, and the UPU header protection indicator 1003 in the UPU protection request message.

[0095] Figure 15 FIG. 1 is a block diagram of 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 a UPU protection service. Figure 15In the example, UPU information 1500 includes the following attributes (also referred to as information elements (IEs)): 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 may define updates to multiple UE parameters, and therefore, the UPU data list 1502 may include a set or array of UPU data 1504. The UPU data 1504 is information that defines UE parameter updates for UE parameters. For example, the UPU data 1504 may 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 the UPU data 1504 includes update data for a separate UE parameter. The UPU acknowledgement indicator attribute 1532 includes the UPU acknowledgement indicator 1506. The UPU confirmation indicator 1506 (e.g., a Boolean value) indicates whether the UE 106 is to utilize the UE MAC (e.g., UPU-MAC-I UE ) in response to the UDM 218. The UPU header attribute 1533 is optional and may include the 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 may 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 acknowledgment of successful reception of the UPU data list), a UPU acknowledgement (ACK) indicator (e.g., a value of "0" when acknowledgment is not requested, and a value of "1" when acknowledgment 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), etc.

[0096] The UPU information 1500 may have a structured data type provided for the Nausf_UPU protection service application programming interface (API), as described in Section 6.3 of 3GPP TS29.509. The Nausf_UPU protection service API defines an "UpuInfo" data type, as described in Section 6.3.6.2.2 of 3GPP TS29.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 the "UPU Header" IE specified in Section 9.11.3.53A of 3GPP TS24.501 (v.18.1.0) (which is incorporated herein by reference as if fully incorporated herein).

[0097] The UPU protection request message 1501 also includes a UPU header protection indicator 1003, which is a value, flag, or indicator type indicating whether the UE supports UPU header protection. For example, the UPU header protection indicator 1003 may include a Boolean value such as "T" or "F", "1" or "0", etc. As described above, the UPU header protection indicator 1003 may be an optional input to the UPU protection service.

[0098] exist Figure 11In the embodiment of the present invention, when a UE parameter update is triggered, the data management controller 604 determines or identifies whether the UE 106 supports UPU header protection in the derivation of the MAC (step 1106). When it is determined that the UE 106 supports UPU header protection, the data management controller 604 of the UDM 218 sets (step 1108) the UPU header protection indicator 1003 in the UPU protection request message 1501 to indicate that the UE 106 supports UPU header protection (e.g., 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 it is determined that the UE 106 does not 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 may 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 instead of 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 can request the AUSF 210 to derive the AUSF MAC based on the UPU header protection indicator 1003, based on the UPU header 1508, or not based on the UPU header 1508.

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

[0100] exist Figure 12In the example embodiment, the authentication controller 704 of the AUSF 210 receives the UPU protection request message 1501 from the UDM 218 (step 1202). The authentication controller 704 processes the UPU protection request message 1501 and determines whether the UE 106 supports UPU header protection based on the UPU header protection indicator 1003 (step 1204). For example, the authentication controller 704 processes the UPU protection request message 1501 and determines whether the UPU protection request message 1501 includes the UPU header protection indicator 1003 set to "true" or some other value indicating that the UE 106 supports UPU header protection. When the UE 106 supports UPU header protection, the authentication controller 704 derives or generates the AUSF MAC based on the UPU header 1508 (step 1206). When the UE 106 does not support UPU header protection, the authentication controller 704 derives or generates the AUSF MAC based on the UPU data 1504 and excludes (i.e., does not consider) the UPU header 1508 (step 1208). One technical advantage is that the AUSF 210 is instructed whether to derive the AUSF MAC based on the UPU header 1508 based on the UPU header protection indicator 1003 provided by the UDM 218. When the AUSF MAC is derived based on the UPU header 1508, another technical advantage is that the UPU header 1508 is protected in the UE parameter update.

[0101] The authentication controller 704 of the AUSF 210 may also derive or generate an expected UE MAC (eg, UPU-MAC-I) based on the UPU confirmation indicator 1506. 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., a 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, a UPU counter, and may optionally include the expected UE MAC. Figure 1616 is a block diagram illustrating a UPU protection response message 1601 for a 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 includes material generated for protecting UE parameter updates and includes the following attributes: AUSF MAC attribute 1631, UPU counter attribute 1632, and expected UE MAC attribute 1633. The AUSF MAC attribute 1631 includes the AUSF MAC 1612. The UPU counter attribute 1632 includes the UPU counter 1616. If the UDM 218 requests confirmation from the UE 106, the expected UE MAC attribute 1633 includes the expected UE MAC 1618 (XUE MAC).

[0102] The UPU security information 1600 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. The Nausf_UPU protection service API defines an "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".

[0103] Figure 17-18 is a block diagram illustrating the derivation of the AUSF MAC in an illustrative embodiment. As further described in 3GPP TS 33.501 (Annex A.19), K AUSF The AUSF MAC 1612 is derived from the Key Derivation Function (KDF) 1700 using the key 1704 as input. In an embodiment, the AUSF MAC generation function 1701 may be extended to include Figure 17 The UPU header 1508 is shown. For the AUSF MAC generation function 1701, the input parameters of 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 between different instances of the algorithm. P0...Pn are n+1 input parameter codes, and L0...Ln are two octets representing the length of the corresponding input parameter codes P0...Pn. When based on Figure 17When deriving the AUSF MAC 1612 from the UPU header 1508 in the [AUSF MAC], the following input parameters may be used to form the string S that is input to the KDF 1700:

[0104] -fc=0x7b,

[0105] - P0 = UPU data (i.e., UPU data list),

[0106] -L0=the length of the UPU data,

[0107] -P1=UPU counter,

[0108] - L1 = length of the UPU counter,

[0109] - P2 = UPU header (if UPU header protection indication is set to true),

[0110] - L2 = length of the UPU header (if the UPU header protection indication is set to true).

[0111] AUSF MAC 1612 (e.g., UPU-MAC-I AUSF ) can be identified using the 128 least significant bits of the output of KDF 1700. Therefore, for Figure 12 In step 1206 of FIG. 1 , the authentication controller 704 of the AUSF 210 may input the UPU data 1504 and the UPU header 1508 into the KDF 1700 to derive the AUSF MAC 1612 (optional step 1214), as shown in FIG. Figure 17 As will be further described below, the update controller 936 of the UE 106 may similarly input the UPU data 1504 and the UPU header 1508 into the KDF 1700 to derive the AUSF MAC ( Figure 14A Optional step 1420).

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

[0113] exist Figure 11In the embodiment, the data management controller 604 of the UDM 218 receives the UPU protection response message 1601 (eg, Nausf_UPUProtection response message) from the AUSF 210 (step 1114), which includes the AUSF MAC 1612 (ie, UPU-MAC-I AUSF ) and 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 (eg, UPU-XMAC-I UE ). The data management controller 604 may then temporarily store the expected UE MAC 1618 (optional step 1116).

[0114] For the UPU process, the data management controller 604 invokes the 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 1118). The data management controller 604 includes UPU information for UE parameter update in the SDM notification message. The UPU information for the subscriber data management service (also referred to as the second UPU information) may be different from the UPU information 1500 for the UPU protection service. Figure 19 FIG1 is a block diagram illustrating an SDM notification message 1901 for a subscriber data management service in an illustrative embodiment. SDM notification message 1901 includes UPU information 1900. UPU information 1900 includes the following attributes (also referred to as IEs): a UPU data list attribute 1931, a UPU re-registration indicator attribute 1932, a UPU confirmation indicator attribute 1933, a UPU AUSF MAC attribute 1934, and a UPU counter attribute 1935. UPU data list attribute 1931 includes UPU data list 1502 (i.e., UPU data 1504). UPU information 1900 may define updates to multiple UE parameters, and therefore, UPU data list 1502 may include a set or array of UPU data 1504. UPU re-registration indicator attribute 1932 includes a UPU re-registration indicator 1912 indicating whether re-registration of UE 106 is requested. UPU confirmation indicator attribute 1933 includes a UPU confirmation indicator 1506. The UPUAUSF MAC attribute 1934 contains the AUSF MAC 1612 derived by the AUSF 210. The UPU counter attribute 1935 contains the UPU counter 1616.

[0115] The UPU information 1900 may 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 an "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."

[0116] exist Figure 11 In the example, the data management controller 604 then sends an SDM notification message 1901 to the AMF 212 (step 1120). Figure 13 In the embodiment of the present invention, 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 based on the UPU information 1900 in the SDM notification message 1901 (step 1304). The access and mobility controller 804 is configured to construct a UPU transparent container as described in Section 9.11.3.53A of 3GPP TS 24.501. Figure 20 1 is a block diagram illustrating a UPU transparent container 2000 in an illustrative embodiment. In a message from the network to the UE 106, the UPU transparent container 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 Notify message 1901.

[0117] When constructing the UPU transparent container 2000, the access and mobility controller 804 also generates a UPU header 1508 of the UPU transparent container 2000 based on the UPU information 1900 provided in the SDM notification message 1901. Although the SDM notification message 1901 does not transmit the UPU header 1508 as described above, the access and mobility controller 804 can format the UPU header 1508 of the UPU transparent container 2000 using the data transmitted in the SDM notification message 1901. Figure 211 is a block diagram of a UPU header 1508 of a UPU transparent container 2000 in an illustrative embodiment. The UPU header 1508 includes a UPU re-registration (REG) indicator 1912, a UPU acknowledgement (ACK) indicator 1506, and a UPU data type 2112. 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 2000 is sent from the network to the UE 106 or from the UE 106 to the network. For example, when the UPU transparent container 2000 carries the UPU data list 1502 from the network to the UE 106, the access and mobility controller 804 may set the UPU data type 2112 to a value of "0", and when the UPU transparent container 2000 carries a confirmation of successful receipt of the UPU data list 1502 from the UE 106 to the network, the access and mobility controller may set the UPU data type to a value of "1".

[0118] exist Figure 13 In the example, the access and mobility controller 804 then sends a DL NAS transport message with the UPU transparent container 2000 to the UE 106 (step 1306), such as the DL NAS transport message with the DL NAS transport message 1014. Figure 10A As shown. Figure 14A In the embodiment, the ME 900 of the UE 106 receives a DL NAS transport message including the UPU transparent container 2000 from the AMF 212 (step 1402). After receiving the DL NAS transport message, the update controller 936 of the UE 106 derives or calculates the AUSF MAC (e.g., UPU-MAC-I) in the same manner as the AUSF 210. AUSF When the UE 106 supports UPU header protection, the update controller 936 derives or generates an AUSF MAC (also referred to as a derived AUSF MAC) based on the UPU header 1508 (step 1404), such as 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 excluding (i.e., not considering) the UPU header 1508 (step 1406), such as Figure 18 One technical advantage is that the UE 106 derives the AUSF MAC in the same manner as the AUSF 210.

[0119] The update controller 936 then compares the derived AUSF MAC with the received AUSF MAC 1612 received in the UPU transparent container 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 verifies the UE parameter update (step 1412). When the verification of the AUSF MAC 1612 is successful, the update controller 936 updates one or more configuration parameters of the ME 900 and / or USIM 960 based on the UPU data 1504 (step 1414). If the UPU data 1504 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 verification of the AUSF MAC 1612 succeeds and the UPU data 1504 contains configuration parameters that are not protected by the security packet, the ME 900 of the UE 106 updates its stored parameters with the parameters received in the UPU update data.

[0120] If the UDM 218 has requested confirmation from the UE 106, and the UE 106 has successfully verified 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) based on the UPU confirmation indicator 1506 in the same manner as the AUSF 210 derives the expected UE MAC 1618. UE ) (optional step 1416). The UE 106 then sends a UL NAS transfer message to the AMF 212 (optional step 1418), such as Figure 10A UL NAS transport message 1016 is shown. 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 2200 in an illustrative embodiment. In a message from the UE 106 to the network, the UPU transparent container 2200 includes a UPU transparent container IEI 2202, a container length 2204, a UPU header 1508, and a UE MAC 2208 generated by the UE 106.

[0121] exist Figure 13, 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 confirmation from the UE 106 to the UDM 218 regarding the successful delivery of the UPU data 1504. The access and mobility controller 804 sends an SDM information message (e.g., as shown in FIG. 1308 ) with the UE MAC 2208 to the UDM 218. Figure 10A Nudm_SDM_Info message 1014) (optional step 1310).

[0122] exist Figure 11 In the embodiment of the present invention, 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 instructs the UE 106 to confirm a successful security check on 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).

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

[0124] One technical advantage of the UE parameter update procedure as described above for method 1100 is that the current data structure 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 can 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. Therefore, 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.

[0125] Example 2

[0126] Figure 23A is a message diagram illustrating a UE parameter update procedure in an illustrative embodiment. Figure 23A The UE parameter update procedure described in 3GPP TS 33.501 may be an extension to Section 6.15.2.1 of 3GPP TS 33.501. As a general overview, the AUSF 210 may additionally derive an enhanced AUSF MAC (i.e., enhanced UPU-MAC-I) based on the UPU header. AUSF In this embodiment, the AUSF MAC derived by excluding the UPU header is referred to as a conventional AUSF MAC (i.e., UPU-MAC-I). AUSF), and the AUSF MAC derived based on the UPU header is called the enhanced AUSF MAC. The regular AUSF MAC and the enhanced AUSF MAC may 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 may exclude the UPU header to derive the regular AUSF MAC for verification. If the UE 106 supports UPU header protection, the UE 106 may derive the enhanced AUSF MAC based on the UPU header for verification. One technical advantage is that the UPU header may be protected in UE parameter updates, as well as any other UPU information (e.g., UPU data) used to derive the enhanced AUSF MAC. If the UE 106 does not support UPU header protection, the UE 106 may derive the regular AUSF MAC for verification. Therefore, existing UEs may still perform UE parameter updates based on UPU data without breaking backward compatibility, so that both existing UEs and new UEs may work when this feature is deployed.

[0127] In an embodiment, the UDM 218 decides to perform a UE parameter update (UPU) using a control plane procedure when the UE 106 is registered with the 5G system 100. If the ultimate consumer of any UE parameter to be updated (e.g., updated RID) is the USIM of the UE 106, the UDM 218 updates the parameters stored on the USIM using a security packet mechanism to protect these parameters. The UDM 218 prepares the UPU data by including the parameters protected by the security packet (if any) and any UE parameters for which the ultimate consumer is the ME of the UE 106.

[0128] The UDM 218 invokes the Nausf_UPUProtection service by sending a Nausf_UPUProtection request message 2311 to the AUSF 210 to obtain the UPU-MAC-I AUSF and Counter UPU The UDM 218 includes the SUPI, UPU data, and UPU header in the Nausf_UPUProtection request message 2311. If the UDM 218 decides that the UE 106 will acknowledge a 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 requires the expected UPU-XMAC-I. UE .

[0129] AUSF 210 uses the UE-specific home key (K AUSF) Calculate or derive UPU-MAC-I AUSF , and in the Nausf_UPUProtection response message 2312, UPU-MAC-I AUSF and Counter UPU Delivered to UDM 218. In UPU-MAC-I AUSF Including the UPU data in the calculation of the UPU allows the UE 106 to verify that the UPU data has not been tampered with by any intermediary. In an embodiment, the AUSF 210 also calculates or derives the enhanced UPU-MAC-I based at least in part on the UPU header. AUSF 2303, and returns the enhanced UPU-MAC-I in the Nausf_UPUProtection response message 2312 AUSF 2303. In Enhanced UPU-MAC-I AUSF Including the UPU header in the calculation of 2303 allows the UE 106 to verify that the UPU header has not been tampered with by any intermediary. If the ACK indication is present in the Nausf_UPUProtection request message 2311, the AUSF 210 calculates or derives the UPU-XMAC-I UE , and returns the calculated UPU-XMAC-I in the Nausf_UPUProtection response message 2312 UE Expected UPU-XMAC-I UE This allows the UDM 218 to verify that the UE 106 received the UPU data correctly.

[0130] The UDM 218 then calls the Nudm_SDM_Notification service operation and sends a Nudm_SDM_Notification message 2313 to the AMF 212, which includes a UPU transparent container (if the AMF 212 supports UPU transparent container) or a separate information element (IE) including UPU data, UPU-MAC-I AUSF , Enhanced UPU-MAC-I AUSF 2303 and Counter UPU If the UDM 218 requests confirmation, it temporarily stores the expected UPU-XMAC-I UE After receiving the Nudm_SDM_Notification message 2313, the AMF 212 sends a DL NAS transport message 2314 to the UE 106. If a transparent container is 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 a separate IE, the AMF 212 constructs a UPU container.

[0131] If the UE 106 does not support UPU header protection, and upon receiving the DL NAS transport message 2314, the UE 106 receives the UPU data and the Counter UPU , calculate UPU-MAC-I in the same way as AUSF 210 AUSF and verify that it matches the UPU-MAC-I received in the DL NAS transport message 2314. AUSF If the UE 106 supports UPU header protection, and upon receiving the DL NAS transport message 2314, the UE 106 generates a counter value based on the received UPU data, Counter value, and the received UPU header protection. UPU and UPU header, and calculates the enhanced UPU-MAC-I in the same way as the AUSF 210 AUSF and verify that it matches the enhanced UPU-MAC-I received in the DL NAS transport message 2314. AUSF If the UPU-MAC-I AUSF or enhanced UPU-MAC-I AUSF If the authentication of UPU-MAC-I succeeds and the UPU data contains any parameters protected by the security packet, the ME of UE 106 forwards the security packet to the USIM. AUSF or enhanced UPU-MAC-I AUSF If the verification is successful and the UPU data contains any parameters that are not protected by a security packet, the ME of UE 106 updates its stored parameters with the parameters received in the UDM update data.

[0132] 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 a UL NAS transport message 2315 to the serving AMF 212. The UE 106 generates a UPU-MAC-I UE , and the generated UPU-MAC-I UE The AMF 212 sends a UPU-MAC-I message to the UDM 218. UE Nudm_SDM_Info message 2316. If it has UPU-MAC-I UEIf the transparent container is received in the UL NAS transport message 2315, the AMF 212 sends a Nudm_SDM_Info message 2316 with the transparent container to the UDM 218. If the UDM 218 instructs the UE 106 to confirm the successful security check of the received UPU data, the UDM 218 sends the received UPU-MAC-I UE The expected UPU-XMAC-I temporarily stored with the UDM 218 UE The comparison is performed to verify that the UE 106 successfully received the UPU data.

[0133] In order to enhance the UPU-MAC-I AUSF 2303 is provided from the AUSF 210 to the UDM 218, and the UPU protection service (eg, Nausf_UPUProtection service) may be extended. Figure 23B An extension 2350 to the Nausf_UPUProtection service to include enhanced UPU-MAC-I in an illustrative embodiment is shown. AUSF 2303. As described in Section 14.1.4 of 3GPP TS 33.501, the Nausf_UPUProtection service specifies the following as required outputs: UPU-MAC-I AUSF and Counter UPU In an embodiment, the extension 2350 to the Nausf_UPUProtection service provides an enhanced UPU-MAC-I AUSF 2303 as the required output 2352. A technical advantage is that the AUSF 210 can report the enhanced UPU-MAC-I to the UDM 218. AUSF 2303.

[0134] Figure 24-27 2400 is a flow chart illustrating a method 2400 for performing a UE parameter update procedure in an illustrative embodiment. Figure 6 UDM 218 describes Figure 24 The steps of method 2400 will be referred to as Figure 7 AUSF210 in the description Figure 25 The steps of method 2400 will be referred to as Figure 8 AMF 212 in Figure 26 The steps of method 2400 and will refer to Figure 9 UE 106 in the description Figure 27 Those skilled in the art will appreciate that method 2400 may be performed in other systems, devices, or network functions.

[0135] exist Figure 24 In the embodiment of the present invention, 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 is registered with the 5G system 100, the data management controller 604 decides to use a control plane procedure to perform the UE parameter update. After triggering the UE parameter update procedure, the data management controller 604 invokes a UPU protection service (e.g., Nausf_UPU protection) 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 the SUPI for the UE 106 and UPU information (also referred to as first UPU information) for the UE parameter update (e.g., UPU data and UPU header) in the UPU protection request message. Figure 28 FIG. 2 is a block diagram of a UPU protection request message 2801 for a UPU protection service in an illustrative embodiment. The UPU protection request message 2801 includes UPU information 2800 (also referred to as first UPU information) for a UPU protection service. Figure 28 In the UPU information 2800, the UPU information 2800 includes the following attributes (also referred to as information elements (IEs)): UPU data list attribute 2831, UPU confirmation indicator attribute 2832, and UPU header attribute 2833. The UPU data list attribute 2831 contains the UPU data list 2802 (i.e., UPU data 2804). The UPU confirmation indicator attribute 2832 contains the UPU confirmation indicator 2806. The UPU header attribute 2833 contains the UPU header 2808. Figure 24 In step 2406, the data management controller 604 sends a UPU protection request message 2801 to the AUSF 210.

[0136] exist Figure 25, the authentication controller 704 of the AUSF 210 receives a 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 and excluding the UPU header 2808 (step 2504). In an 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 may 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 may receive some type of indicator or instruction from the UDM 218 on when to derive the enhanced AUSF MAC 2303. The authentication controller 704 may also derive or generate the expected UE MAC (e.g., UPU-MAC-I) based on the UPU confirmation indicator 2806. UE )(Optional step 2508).

[0137] 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 UPU security information in the UPU protection response message. The UPU security information includes the regular AUSF MAC and enhanced AUSF MAC 2303 generated by the AUSF 210, a UPU counter, and may optionally include the expected UE MAC. Figure 29 2 is a block diagram of a UPU protection response message 2901 for a UPU protection service in an illustrative embodiment. The UPU protection response message 2901 includes UPU security information 2900 for the UPU protection service. The UPU security information 2900 includes material generated for protecting UE parameter updates 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 includes the regular AUSF MAC 2912. The enhanced AUSF MAC attribute 2932 includes the enhanced AUSF MAC 2303. The UPU counter attribute 2933 includes the UPU counter 2916. If the UDM 218 requests confirmation from the UE 106, the expected UE MAC attribute 2934 includes the expected UE MAC 2918 (XUE MAC). 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 can verify the UE parameter update.

[0138] exist Figure 25 In step 2504, the authentication controller 704 derives the regular AUSF MAC 2912 based on the UPU data 2804 and excluding the UPU header 2808. Figure 30 is a block diagram illustrating the derivation of a conventional AUSF MAC 2912 in an illustrative embodiment. In the AUSF MAC generation function 3001, K AUSF Key 3004 is used as input key to derive the normal AUSF MAC 2912 from KDF 3000. Figure 30 When deriving a conventional AUSF MAC 2912 from the UPU data 2804 in

[0055] , the following input parameters may be used to form the string S that is input into the KDF 3000:

[0139] -fc=0x7b,

[0140] -P0=UPU data,

[0141] -L0=the length of the UPU data,

[0142] -P1=UPU counter,

[0143] - L1 = length of the UPU counter.

[0144] exist Figure 25 In step 2506 , the authentication controller 704 derives the enhanced AUSF MAC 2303 based on the UPU header 2808 . Figure 31 2303 in an illustrative embodiment. In an 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 deriving the enhanced AUSF MAC 2303 from the UPU header 2808 in the MAC address field, the following input parameters may be used to form the string S that is input to the KDF 3000:

[0145] -fc=0x7b,

[0146] - P0 = UPU data (i.e., UPU data list),

[0147] -L0=the length of the UPU data,

[0148] -P1=UPU counter,

[0149] - L1 = length of the UPU counter,

[0150] -P2=UPU header,

[0151] - L2 = length of the UPU header.

[0152] Enhanced AUSF MAC 2303 (e.g., enhanced UPU-MAC-I AUSF ) can be identified using the 128 least significant bits of the output of KDF 3000.

[0153] for Figure 25 At step 2506 of FIG. 25, the authentication controller 704 of the AUSF 210 may input the UPU data 2804 and the UPU header 2808 (and the UPU counter 2916) as input parameters into 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 may input the UPU data 2804 and the UPU header 2808 as input parameters into the KDF 3000 to derive the enhanced AUSF MAC ( Figure 27 Optional step 2730).

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

[0155] For the UPU process, the data management controller 604 invokes the 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 UPU information for UE parameter update (also referred to as second UPU information) in the SDM notification message. In an embodiment, the UPU information is enhanced with enhanced UPU information in the subscriber data management service. Figure 323 is a block diagram of 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 a UPU re-registration indicator 3212 indicating whether re-registration of the UE 106 is requested. The UPU confirmation indicator attribute 3233 contains a UPU confirmation indicator 2806. The AUSF MAC attribute 3234 contains the conventional 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.

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

[0157] exist Figure 26 In the embodiment of the present invention, the access and mobility controller 804 of the AMF 212 receives an 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 (step 2604), which includes at least UPU data 2804, UPU header 2808, and regular AUSF MAC 2912. The "regular" UPU transparent container is constructed as described in Section 9.11.3.53A of 3GPP TS 24.501. Figure 333300 in an illustrative embodiment. In a message from the network to the UE 106, the conventional UPU transparent container 3300 includes a UPU transparent container IEI 3302, a container length 3304, a UPU header 2808, a conventional AUSF MAC 2912, a UPU counter 2916, and a UPU data list 2802. The access and mobility controller 804 populates the conventional AUSF MAC 2912, the UPU counter 2916, and the UPU data list 2802 from the UPU information 3200 in the SDM notification message 3201.

[0158] exist Figure 26 In step 2606 , 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 , which includes at least the enhanced AUSF MAC 2303 . Figure 34 FIG is a block diagram of an enhanced UPU transparent container 3400 in an illustrative embodiment. In an embodiment, the enhanced UPU transparent container 3400 may have Figure 33 The enhanced UPU transparent container 3400 has the same format as the conventional UPU transparent container 3300 in the message from the network to the UE 106. In the message from the network to the UE 106, the enhanced UPU transparent container 3400 includes the enhanced UPU transparent container IEI 3402, the container length 3404, the UPU header 2808, the enhanced AUSF MAC 2303, the UPU counter 2916 and the UPU data list 2802. Figure 26 In step 2608, the access and mobility controller 804 sends a DL NAS transport message with the regular UPU transparency container 3300 and the enhanced UPU transparency container 3400 to the UE 106 (step 2608).

[0159] exist Figure 27 , the ME 900 of the UE 106 receives a DL NAS transport message from the AMF 212 (step 2702). After receiving the DL NAS transport message, the update controller 936 derives or calculates the AUSF MAC or 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 calculates the enhanced AUSF MAC (also referred to as the derived enhanced AUSF MAC or the third MAC) based on the UPU header 2808 (step 2704). For example, the update controller 936 may 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), such as Figure 31Then, the update controller 936 compares the derived enhanced AUSF MAC with the received enhanced AUSF MAC 2303 received in the enhanced UPU transparent container 3400 (step 2706).

[0160] 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 a derived regular AUSF MAC or a fourth MAC) based on the UPU data 2804 and excluding (i.e., not considering) the UPU header 2808 (step 2708). For example, the update controller 936 may derive or generate a regular AUSF MAC based on the UPU data 2804 and excluding (i.e., not considering) the UPU header 2808, such as Figure 30 The update controller 936 then compares the derived regular AUSF MAC with the received regular AUFF MAC 2912 received in the regular UPU transparent container 3300 to determine if they match (step 2710).

[0161] 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 do match, the update controller 936 verifies the UE parameter update (step 2714). When the verification is successful, the update controller 936 updates one or more configuration parameters of the ME 900 and / or USIM 960 based on the UPU data 2804, such as provided in the conventional UPU transparent container 3300 (step 2716). If the UPU data 2804 includes configuration parameters protected by a security packet, the ME 900 of the UE 106 forwards the security packet to the USIM 960. When the verification is successful and the UPU data 2804 includes configuration parameters not protected by a security packet, the ME 900 of the UE 106 updates its stored parameters with the parameters received in the UPU update data.

[0162] If the UDM 218 has requested confirmation from the UE 106, and the UE 106 has successfully verified 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) based on the UPU confirmation indicator 2806 in the same manner as the AUSF 210 derives the expected UE MAC 2918. UE ) (optional step 2718). The UE 106 then sends a UL NAS transfer message to the AMF 212 (optional step 2720). The UE 106 includes the UE MAC in a transparent container in the UL NAS transfer message. Figure 35is a block diagram illustrating a UPU transparent container 3500 in an illustrative embodiment. In a message from the UE 106 to the network, the UPU transparent container 3500 includes a UPU transparent container IEI 3502, a container length 3504, a UPU header 2808, and a UE MAC 3508 generated by the UE 106.

[0163] exist 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 a subscriber data management service (e.g., Nudm_SDM_Info service) of the UDM 218 to provide confirmation from the UE 106 to the UDM 218 regarding the successful delivery of the UPU data 2804. The access and mobility controller 804 sends an SDM information message (e.g., Nudm_SDM_Info message) with the UE MAC 3508 to the UDM 218 (optional step 2612).

[0164] exist Figure 24 In the embodiment of the present invention, 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 a successful security check on 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).

[0165] One technical advantage of the UE parameter update procedure for method 2400 as described above is that it defines a method for using the UPU header to derive the enhanced AUSF MAC (e.g., enhanced UPU-MAC-I). AUSF For example, the AUSF 210 derives the enhanced AUSF MAC and the regular AUSF MAC based on the UPU header. Both the enhanced AUSF MAC and the regular AUSF MAC are provided to the UE 106. Therefore, the AUSF 210 and the UE 106 can derive or calculate the regular AUSF MAC or the enhanced AUSF MAC in the same manner, so that the UE parameter update can be verified.

[0166] exist Figure 29In the UPU security information 2900, the 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 an embodiment, the enhanced AUSF MAC attribute 2932 is an extension of the structured data type of the UPU security information 2900. In an 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 A modified "UpuSecurityInfo" data type 3600 for the Nausf_UPU protection service API in an illustrative embodiment is illustrated. 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". In addition, the modified "UpuSecurityInfo" data type 3600 also includes an "enhancedUpuMacIausf" attribute 3602 as an extension to 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 .

[0167] exist Figure 32 In the UPU information 3200, the 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 an embodiment, the enhanced UPU information attribute 3236 is an extension of the structured data type of the UPU information 3200. In an 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 an illustrative embodiment is illustrated. As described in Section 6.1.6.2.33 of 3GPP TS 29.503, 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 to the "UpuInfo" data type in Section 6.1.6.2.33 of 3GPP TS 29.503. The "enhancedUpuMacIausf" attribute 3702 is of type "UpuMac" and is Figure 32 An example of the enhanced UPU information attribute 3236 described in .

[0168] In an embodiment, the UDM 218 may signal the AUSF 210 when to derive the enhanced AUSF MAC 2303 in addition to the regular AUSF MAC 2912 . Figure 38-Figure 39 is a flow chart illustrating additional details of method 2400 in an illustrative embodiment. Figure 38In step 3822, the data management controller 604 of the UDM 218 decides or determines whether to implement UPU header protection. 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 manner requests the AUSF 210 to derive the 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 not include the UPU header protection indication from the UPU protection request message 2801 (step 3826). The data management controller 604 then sends a UPU protection request message 2801 to the AUSF 210 (step 2406), and the method 2400 proceeds as follows. Figure 24 One technical advantage is that the UDM 218 can request the AUSF 210 to derive the enhanced AUSF MAC 2303 based on the UPU header protection indication.

[0169] exist Figure 39 In, such as Figure 25 As shown, the authentication controller 704 of the AUSF 210 receives the UPU protection request message 2801 from the UDM 218 (step 2502) and derives or generates a conventional AUSF MAC (step 2504) based on the UPU data 2804 and excluding the UPU header 2808. The authentication controller 704 determines whether the UPU protection request message 2801 includes a UPU header protection indication (step 3912). Figure 40 FIG. 2 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 a UPU protection service. Figure 40 In the embodiment, UPU information 4000 includes the following attributes: UPU data list attribute 4031, UPU confirmation indicator attribute 4032, UPU header attribute 4033, and UPU header protection indication attribute 4034. UPU header protection indication attribute 4034 includes UPU header protection indication 4006. In an embodiment, UPU header protection indication 4006 may include enhanced UPU information 4010. In an embodiment, UPU header protection indication 4006 may include enhanced UPU indicator 4012.

[0170] exist Figure 39 In the embodiment of the present invention, when 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. Then, the method 2400 may be as follows: Figure 25 Continue as shown.

[0171] exist Figure 40 In the UPU information 4000, the UPU information 4000 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 an embodiment, the UPU header protection indication attribute 4034 is an extension of the structured data type of the UPU information 4000. In an embodiment, a revision or extension of 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_UPU protection service API in an illustrative embodiment is illustrated. As described in 3GPP TS 29.509, section 6.3.6.2.2, the modified "UpuInfo" data type 4100 for the Nausf_UPU protection service API includes the following attributes: "upuDataList," "upuHeader," "upuAckInd," "supportedFeatures," and "upuTransparentInfo." Furthermore, the modified "UpuInfo" data type 4100 includes an "enhancedUpuInfo" attribute 4102, which is an extension of 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.

[0172] Figure 42A The "enhancedUpuInfo" data type 4200 for the Nausf_UPU protection service API in an illustrative embodiment is illustrated. Figure 42AIn the embodiment, the "enhancedUpuInfo" data type 4200 includes the following attributes: "upuDataList" 4202 and "upuHeader" 4204. The "upuDataList" attribute 4202 includes the "UpuData" array in Section 6.3.6.2.4 of 3GPP TS 29.509. The "upuHeader" attribute 4204 is mandatory in this embodiment and contains the "UPU Header" IE specified in Section 9.11.3.53A of 3GPP TS 24.501. Figure 42B The "enhancedUpuInfo" data type 4200 for the Nausf_UPU protection service API in an illustrative embodiment is illustrated. Figure 42B In the 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 specified in Section 9.11.3.53A of 3GPP TS24.501. Figure 42A and / or Figure 42B The "enhancedUpuInfo" data type 4200 in 3GPP TS 29.509 may be added to section 6.3 of 3GPP TS 29.509. In addition, the "enhancedUpuInfo" data type 4200 may replicate the "UpuInfo" data type in section 6.3.6.2.2 of 3GPP TS 29.509, except that the "upuHeader" attribute 4204 is mandatory.

[0173] Figure 43Another modified "UpuInfo" data type 4300 for the Nausf_UPU protection service API in an illustrative embodiment is illustrated. As described in 6.3.6.2.2 of 3GPP TS 29.509, the modified "UpuInfo" data type 4300 for the Nausf_UPU protection service API includes the following attributes: "upuDataList," "upuHeader," "upuAckInd," "supportedFeatures," and "upuTransparentInfo." Furthermore, the modified "UpuInfo" data type 4300 also includes an "enhancedUpuIndicator" attribute 4302, which is an extension of the "UpuInfo" data type in section 6.3.6.2.2 of 3GPP TS 29.509. The "enhancedUpuIndicator" attribute 4302 is of type "enhancedUpuIndicator" and indicates whether UPU header protection is implemented.

[0174] Any element or module in the various elements or modules shown in the figure or described herein can be implemented as hardware, software, firmware or some combination thereof.For example, an element can be implemented as dedicated hardware. The dedicated hardware element can be referred to as a "processor", "controller" or some similar term. When provided by a processor, the function can be provided by a single dedicated processor, provided by a single shared processor, or provided by multiple separate processors, some of which can be shared. In addition, the clear use of the term "processor" or "controller" should not be interpreted as referring only to hardware capable of executing software, and can implicitly include but is not limited to digital signal processor (DSP) hardware, network processor, application specific integrated circuit (ASIC) or other circuit system, field programmable gate array (FPGA), read-only memory (ROM), random access memory (RAM), non-volatile memory, logic or some other physical hardware component or module for storing software.

[0175] Furthermore, an element may be implemented as instructions that can be executed by a processor or computer to perform the function of the element. Some examples of instructions are software, program code, and firmware. When the instructions are executed by a processor, the instructions are operable to direct the processor to perform the function of the element. The instructions may be stored on a storage device readable by the processor. Some examples of storage devices are digital or solid-state memory, magnetic storage media such as disks and tapes, hard drives, or optically readable digital data storage media.

[0176] As used in this application, the term "circuitry" may refer to one or more or all of the following:

[0177] (a) hardware circuit implementation only (such as implementation in analog and / or digital circuitry only);

[0178] (b) a combination of hardware circuitry and software such as (where applicable):

[0179] (i) a combination of analog and / or digital hardware circuits and software / firmware;

[0180] as well as

[0181] (ii) any portion of a hardware processor(s) with software (including digital signal processor(s), software and memory(s) that work together to enable a device such as a mobile phone or server to perform various functions);

[0182] as well as

[0183] (c) Hardware circuit(s) and / or processor(s), such as microprocessor(s) or portion(s) of microprocessor(s), that require software (e.g., firmware) to operate, but in which case the software may not be present when not required for operation.

[0184] This definition of "circuitry" applies to all uses of the term in this application, including in any claims. As a further example, as used in this application, the term "circuitry" also covers an implementation of merely a hardware circuit or processor (or multiple processors) or a portion of a hardware circuit or processor and its accompanying software and / or firmware. For example, if applicable to a particular claim element, the term "circuitry" also covers a baseband integrated circuit or processor integrated circuit for a mobile device, or a similar integrated circuit in a server, cellular network device, or other computing or networking device.

[0185] Although specific embodiments are described herein, the scope of the present disclosure is not limited to those specific embodiments.The scope of the present disclosure is defined by the following claims and any equivalents thereof.

Claims

1. A method for performing a UE parameter update (UPU) on a user equipment, the method comprising: receiving, at an authentication server function (AUSF) of a 5G core network, a UPU protection request message regarding the UE parameter update for the user equipment from a unified data management (UDM), wherein the UPU protection request message includes first UPU information, the first UPU information including UPU data and a UPU header; determining, at the AUSF, whether the user equipment supports UPU header protection in derivation of a message authentication code based on a UPU header protection indicator in the UPU protection request message; When the user equipment supports UPU header protection, deriving, at the AUSF, a first message authentication code based on the UPU header; as well as A UPU protection response message including the first message authentication code is sent from the AUSF to the UDM.

2. The method according to claim 1, further comprising: When the user equipment does not support UPU header protection, the first message authentication code is derived at the AUSF based on the UPU data and excluding the UPU header.

3. The method according to claim 2, further comprising: receiving, at the UDM, from the AUSF, the UPU protection response message including the first message authentication code; At the UDM, generating a subscriber data management notification message, the subscriber data management notification message including: second UPU information including the UPU data, and the first message authentication code; as well as The subscriber data management notification message is sent from the UDM to an access and mobility management function (AMF).

4. The method according to claim 3, further comprising: receiving, at the AMF, the subscriber data management notification message from the UDM; At the AMF, construct a UPU transparent container, where the UPU transparent container includes the UPU data, the UPU header, and the first message authentication code; as well as A downlink transmission message with the UPU transparent container is sent from the AMF to the user equipment.

5. The method according to claim 4, further comprising: receiving, at the user equipment, the downlink transmission message from the AMF; as well as When the user equipment supports UPU header protection, at the user equipment, a second message authentication code is derived based on the UPU header: At the user equipment, comparing the second message authentication code with the first message authentication code; as well as When the second message authentication code matches the first message authentication code, the UE parameter update is verified at the user equipment.

6. The method according to claim 5, further comprising: When the user equipment does not support UPU header protection, the second message authentication code is derived at the user equipment based on the UPU data and excluding the UPU header.

7. The method of claim 5, wherein deriving the second message authentication code comprises: At the user equipment, the UPU data and the UPU header are input to a key derivation function.

8. The method according to claim 5, further comprising: Before the UE parameters are updated: At the user equipment, inserting the UPU header protection indicator into a control plane message directed to the 5G core network; as well as sending the control plane message from the user equipment to the AMF.

9. The method of claim 8, wherein inserting the UPU header protection indicator in the control plane message comprises: The UPU header protection indicator is inserted into an initial non-access stratum message.

10. The method of claim 8, wherein inserting the UPU header protection indicator in the control plane message comprises: The UPU header protection indicator is inserted in a registration request provided during primary authentication of the user equipment.

11. The method of claim 1 , wherein deriving the first message authentication code comprises: At the AUSF, the UPU data and the UPU header are input to a key derivation function.

12. The method according to claim 1, further comprising: At the UDM, triggering an update of the UE parameters for the user equipment; At the UDM, generating a UPU protection request message; At the UDM, determining whether the user equipment supports UPU header protection; When the user equipment supports UPU header protection, setting the UPU header protection indicator in the UPU protection request message to a first value, the first value indicating that the user equipment supports UPU header protection, When the user equipment does not support UPU header protection, setting the UPU header protection indicator in the UPU protection request message to a second value, or omitting the UPU header protection indicator, to indicate that the user equipment does not support UPU header protection; and The UPU protection request message is sent from the UDM to the AUSF.

13. The method according to claim 12, wherein determining whether the user equipment supports UPU header protection comprises: The UPU header protection indicator is received at the UDM during primary authentication of the user equipment.

14. The method of claim 1, wherein: The UPU protection request message includes: a Nausf_UPUProtection request message of a Nausf_UPUProtection service; and The extension of the Nausf_UPUProtection service provides the UPU header protection indicator as an optional input.

15. An authentication server function (AUSF) element of a 5G core network, comprising: at least one processor; as well as at least one memory storing instructions that, when executed by the at least one processor, cause the AUSF element to at least: For a UE parameter update (UPU) of a user equipment, receiving a UPU protection request message regarding the UE parameter update for the user equipment from a unified data management (UDM), wherein the UPU protection request message includes UPU information, the UPU information including UPU data and a UPU header; determining, based on the UPU header protection indicator in the UPU protection request message, whether the user equipment supports UPU header protection in derivation of a message authentication code; When the user equipment supports UPU header protection, deriving a message authentication code based on the UPU header; as well as Sending a UPU protection response message including the message authentication code to the UDM.

16. The AUSF element of claim 15, wherein the instructions, when executed by the at least one processor, further cause the AUSF element to at least: When the user equipment does not support UPU header protection, a message authentication code is derived based on the UPU data and excluding the UPU header.

17. The AUSF element of claim 15, wherein the instructions, when executed by the at least one processor, further cause the AUSF element to at least: When the user equipment supports UPU header protection, the UPU data and the UPU header are input to a key derivation function to derive the message authentication code.

18. A unified data management (UDM) element of a 5G core network, comprising: at least one processor; as well as at least one memory storing instructions that, when executed by the at least one processor, cause the UDM element to at least: Triggering a UE parameter update (UPU) for the user equipment; generating a UPU protection request message including first UPU information, wherein the first UPU information includes UPU data and a UPU header; determining whether the user equipment supports UPU header protection in derivation of a message authentication code; When the user equipment supports UPU header protection, setting a UPU header protection indicator in the UPU protection request message to a first value, where the first value indicates that the user equipment supports UPU header protection; When the user equipment does not support UPU header protection, setting the UPU header protection indicator in the UPU protection request message to a second value, or omitting the UPU header protection indicator, to indicate that the user equipment does not support UPU header protection; and The UPU protection request message is sent to an authentication server function (AUSF).

19. The UDM component of claim 18, wherein the instructions, when executed by the at least one processor, further cause the UDM component to at least: The UPU header protection indicator is received during primary authentication of the user equipment.

20. The UDM component of claim 18, wherein the instructions, when executed by the at least one processor, further cause the UDM component to at least: receiving a UPU protection response message including a message authentication code from the AUSF; Wherein, when the user equipment supports UPU header protection, the message authentication code is derived by the AUSF based on the UPU header; Wherein, when the user equipment does not support UPU header protection, the message authentication code is derived by the AUSF based on the UPU data and excluding the UPU header; generating a subscriber data management notification message including second UPU information, wherein the second UPU information includes the message authentication code and the UPU data; and The subscriber data management notification message is sent to an access and mobility management function (AMF).

21. A user equipment comprising: at least one processor; as well as At least one memory storing instructions, which, when executed by the at least one processor, cause the user equipment to at least: receiving a downlink transmission message of a UE parameter update (UPU) for the user equipment from an access and mobility management function (AMF) of the 5G core network, wherein The downlink transmission message includes a UPU transparent container, the UPU transparent container including UPU data, a UPU header, and a first message authentication code generated by an authentication server function (AUSF); When the user equipment supports UPU header protection in derivation of a message authentication code, deriving a second message authentication code based on the UPU header; comparing the second message authentication code with the first message authentication code; as well as When the second message authentication code matches the first message authentication code, the UE parameter update is verified.

22. The user equipment of claim 21 , wherein the instructions, when executed by the at least one processor, further cause the user equipment to at least: When the user equipment does not support UPU header protection, the second message authentication code is derived based on the UPU data and excluding the UPU header.

23. The user equipment of claim 21 , wherein the instructions, when executed by the at least one processor, further cause the user equipment to at least: When the user equipment supports UPU header protection, the UPU data and the UPU header are input to a key derivation function to derive the second message authentication code.

24. The user equipment of claim 21 , wherein the instructions, when executed by the at least one processor, further cause the user equipment to at least: Before the UE parameters are updated: inserting a UPU header protection indicator into a control plane message directed to the 5G core network, wherein the UPU header protection indicator indicates whether the user equipment supports UPU header protection; and Send the control plane message to the AMF.

25. The user equipment of claim 24, wherein the instructions, when executed by the at least one processor, further cause the user equipment to at least: The UPU header protection indicator is inserted into an initial non-access stratum message.

26. The user equipment of claim 24, wherein the instructions, when executed by the at least one processor, further cause the user equipment to at least: The UPU header protection indicator is inserted in a registration request provided during primary authentication of the user equipment.

Images