User plane IPSEC SA modification
By transmitting an information request message containing a Security Parameter Index (SPI) between the network and the user equipment, the identification problem in the IPsec SA modification process in the prior art is solved, ensuring the successful completion of the modification process.
Patent Information
- Application Number
- CN202480013934.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-02-20
- Filing Date
- 2024-02-20
- Publication Date
- 2025-11-25
AI Technical Summary
In existing technologies, networks and user equipment cannot effectively identify a specific UP IPsec SA during the IPsec SA modification process, causing the modification process to fail.
The successful completion of the user plane IPsec SA modification process is ensured by transmitting an information request message containing the Security Parameter Index (SPI) between the network and the user equipment.
This enables accurate identification of specific UP IPsec SAs during the IPsec SA modification process, ensuring that the network and user equipment can successfully complete the modification process.
Smart Images

Figure CN121014187A_ABST
Abstract
Description
[0001] Cross-reference to related applications
[0002] This application claims priority and benefit to Provisional U.S. Patent Application No. 63 / 447,036, filed February 20, 2023, entitled “Enhancement of User Plane IPSec SA Modification Procedure,” the entire contents of which are hereby expressly incorporated by reference. Technical Field
[0003] This disclosure relates generally to wireless communications, and more specifically to a mechanism for modifying IPsec SA for user plane access in non-3GPP access. Background Technology
[0004] This background description is provided for the purpose of presenting the overall context of this disclosure. The work of the currently attributed inventors (to the extent described in this background section) and aspects of the specification that might not have been considered prior art at the time of filing are neither expressly nor implicitly acknowledged as prior art to this disclosure.
[0005] User equipment (UE) can access fifth-generation (5G) networks via networks conforming to standards defined by the 3rd Generation Partnership Project (3GPP) (i.e., using 3GPP access). UEs can also access 5G networks using non-3GPP access, which can be trusted or untrusted. For untrusted non-3GPP access, the UE accesses the 5G core network via Non-3GPP Interoperability Function (N3IWF).
[0006] Generally speaking, a Quality of Service (QoS) flow represents the finest-grained QoS forwarding process in a 5G system (5GS), where the same forwarding processes (e.g., scheduling policies, queue management policies, rate shaping policies, radio link control (RLC) configurations) are applied to all services mapped to the same QoS flow. To provide different QoS forwarding processes, 5GS uses different 5G QoS flows. For clarity, Figure 7 Examples of commonly accepted QoS models are provided.
[0007] A network node classifies traffic from an upper layer (e.g., an application) into QoS flows based on QoS rules, each QoS rule including one or more packet filters. A 3GPP or non-3GPP access network can bind a QoS flow to access network resources. For 3GPP access, these access network resources are data radio bearers (DRBs). An access network can bind multiple QoS flows to a single DRB. For non-3GPP access (e.g., untrusted non-3GPP access), each of the QoS flows can be encapsulated in a generic routing encapsulation (GRE) tunnel, and multiple GRE tunnels (i.e., QoS flows) can be mapped to one internet protocol security (IPsec) security association (SA), as shown in Figure 2B
[0008] During establishment of a user plane (UP) IPsec SA, a network can provide a differentiated services code point (DSCP) value for association with the IPsec SA. When the network provides a DSCP value for association with the IPsec SA, the UE sets the DSCP value of an outer IP header to the DSCP value provided by the network. In this way, the network and the UE can differentiate QoS handling among different IPsec SAs.
[0009] Further, the network can initiate an IPsec SA modification procedure to modify QoS parameters of, for example, an established UP IPsec SA. The network can also initiate an IPsec SA deletion procedure to delete an existing UP IPsec SA.
[0010] However, it is unclear how the network and the UE can identify a particular UP IPsec SA during an IPsec SA modification procedure. SUMMARY
[0011] An example embodiment of the techniques of this disclosure is a method implemented in a user equipment (UE). The method includes establishing a user plane (UP) internet protocol security (IPsec) security association (SA) with a network element, receiving a request from the network element to modify the UP IPsec SA, the request including a security parameter index (SPI) to identify the UP IPsec SA, and modifying the UP IPsec SA in accordance with the request.
[0012] Another example embodiment of the techniques is a method implemented in a core network of a telecommunication system. The method comprises: establishing a user plane (UP) Internet Protocol security (IPsec) security association (SA) with a user equipment (UE); transmitting, to the UE, a request to modify the UP IPsec SA, the request comprising a security parameter index (SPI) to identify the UP IPsec SA; and receiving, from the UE, a response to the request.
[0013] Still another example embodiment of the techniques is an apparatus comprising processing hardware. The apparatus is configured to implement one of the above methods. BRIEF DESCRIPTION OF DRAWINGS
[0014] Figure 1 is a block diagram of an example communication system in which a UE can access using a 3GPP access, an untrusted non-3GPP access, or a trusted non-3GPP access;
[0015] Figure 2A is a block diagram of an example control plane (CP) protocol stack according to which a UE communicates with an access and mobility management function (AMF) of a 5GC;
[0016] Figure 2B is a block diagram of an example user plane (UP) protocol stack according to which a UE communicates with a user plane function (UPF) of a 5GC;
[0017] Figure 3 is a message passing diagram of an example scenario in which a UE and a non-3GPP interworking function (N3IWF) create and modify a UP IPsec SA without identifying the UP IPsec SA during the modification procedure;
[0018] Figure 4A is a message passing diagram of an example scenario in which a UE and a N3IWF create and modify a UP IPsec SA and use a 5G QOS INFO notification payload that is extended to include a security parameter index (SPI) to identify the UP IPsec SA during the modification procedure;
[0019] Figure 4B is similar to the example scenario of Figure 4A but the N3IWF uses a “new” payload or a payload in a format specific to the modification procedure to identify the UP IPsec SA during the modification procedure;
[0020] Figure 4C is similar to the example scenario of Figure 4A but the N3IWF uses a SA payload to identify the UP IPsec SA during the modification procedure;
[0021] Figures 5A to 5C is a flow diagram of an example method in a network element (such as an N3IWF) for determining which payload to include in a message to a UE depending on whether the message is about a UP IPsec SA creation procedure or a UP IPsec SA modification procedure;
[0022] Figure 6 is a flow diagram of an example method in a UE for processing messages related to a UP IPsec SA; and
[0023] Figure 7 An example QoS model according to which UEs and networks of the present disclosure can operate is illustrated. DETAILED DESCRIPTION
[0024] A network element (such as an N3IWF) initiates a UP IPsec SA modification procedure and implements one or more of the techniques discussed below to identify the UP IPsec SA. More specifically, the network element can include a SPI in a message to a UE to identify the UP IPsec SA.
[0025] Reference Figure 1 , the system 100 includes a UE 102 that can access a 5GC 110 via multiple access resources, including 3GPP access, untrusted non-3GPP access, and trusted non-3GPP access. For 3GPP access, the UE 102 accesses the 5GC 110 via a radio access network (RAN) 105 that can include one or more base stations. The RAN 105 can support one or more of the following radio access technologies (RATs): (i) standalone New Radio (NR); (ii) NR with Evolved-UMTS Terrestrial Radio Access (E-UTRA) extension as an anchor; (iii) standalone E-UTRA; or (iv) E-UTRA with NR extension as an anchor.
[0026] For untrusted non-3GPP access, the UE 102 accesses the 5GC 110 in sequence via an untrusted non-3GPP access component 106 (which can be, for example, an access point (AP) of a public local area network (LAN) such as WiFi™) and an N3IWF 107. For trusted non-3GPP access, the UE 102 accesses the 5GC 110 in sequence via a trusted non-3GPP access point (TNAP) 108 and a trusted non-3GPP gateway function (TNGF) 109.
[0027] The 5GC 110 can include various components (most of which are not shown Figure 1(To avoid clutter), including Access and Mobility Management Functions (AMF) 164, Session Management Functions (SMF) 166, and User Plane Functions (UPF) 162.
[0028] AMF 164 can provide functionalities such as: non-access stratum (NAS) encryption and integrity protection, registration management, connection management, reachability management, mobility management, lawful interception (LI) (for AMF events and interfaces to LI systems), and delivery of SM messages between UE 102 and SMF 166.
[0029] SMF 162 can provide functionalities such as: session management (e.g., session establishment, modification and release, tunnel maintenance between UPF 162 and access network (AN) nodes, UE IP address allocation and management, Dynamic Host Configuration Protocol version 4 DHCPv4 (server and client) and DHCPv6 (server and client) functions, selection and control of UP functions, and configuration of service bootstrapping at UPF 162 to route services to appropriate destinations.
[0030] UPF 162 can provide functionalities such as: providing anchor support for intra / inter-RAT mobility, assigning UE IP addresses / prefixes in response to SMF requests, providing external PDU session points for interconnection with data networks, packet routing and forwarding, packet inspection, providing the UP portion of policy rule enforcement, lawful interception, service usage reporting, and QoS handling for the UP (e.g., uplink (UL) / downlink (DL) rate enforcement and reflective QoS marking in the DL).
[0031] Continue to refer to Figure 1 UE 102 is equipped with processing hardware 170, which may include one or more general-purpose processors (e.g., CPUs) and non-transitory computer-readable storage of instructions executed by the one or more general-purpose processors. Additionally or alternatively, processing hardware 130 may include dedicated processing units. Processing hardware 130 may implement an IPsec SA modification controller 172, which is partially configured to process reference... Figures 4A to 4C The information request message is in the format discussed. The N3IWF 107 is also equipped with processing hardware 180, which may include one or more general-purpose processors (e.g., CPUs) and non-transitory computer-readable storage of instructions executed by the one or more general-purpose processors. Additionally or alternatively, processing hardware 180 may include dedicated processing units. Processing hardware 180 may implement an IPsec SA modification controller 182, which is partially configured to generate reference-formatted information request messages. Figures 4A to 4CThe format of the information request message is discussed.
[0032] then, Figure 2A This is a block diagram of the example control plane (CP) protocol stack 200A for UE 102's communication with AMF 164. Generally, UE 102 establishes an IPsec tunnel for NAS signaling when registering with 5GC 110 (e.g., as specified in subclause 4.12.2 of TS23.502). NAS messages are traveled to N3IWF 107 via Transmission Control Protocol (TCP) and the IPsec tunnel, and then forwarded to AMF 103 via N3IWF 107 or TNGF 109.
[0033] Figure 2B This is a block diagram of the example user plane (UP) protocol stack 200B for UE 102 communicating with UPF 162. At the user plane, the network and / or UE 102 map each QoS flow to a GRE tunnel and multiple GRE tunnels to IPsec tunnels.
[0034] For reference Figure 3 Example scenario 300 includes the UP IPsec SA creation process and the UP IPsec SA modification process. In scenarios 300 and 400A-400C, N3IWF 107 refers to a network, and the terms "N3IWF" and "network" are used interchangeably in the discussion of these scenarios.
[0035] To access 5G CN using non-3GPP access, UE 102 first establishes a 303 Internet Key Exchange IKE Security Association (SA) with the network (e.g., an untrusted non-3GPP access N3IWF 107) by exchanging a 301 IKE_INIT message. Then, UE 102 and the network exchange a 305 IKE_AUTH message and establish a 307 First IPsec SubSA for signaling.
[0036] UE 102 and network 107 execute the 311 UP IPsec SA creation procedure. Network 107 can initiate the UP IPsec SA creation procedure via an upper-layer request (e.g., a NAS procedure) or a request to establish a new UP IPsec SA. According to one such NAS procedure, UE 102 chooses to establish a new PDU session by initiating the 313 (NAS) PDU SESSION ESTABLISHMENT procedure. According to another procedure, UE 102 or network 107 chooses to add one or more new QoS flows to an existing PDU session by initiating the 313 (NAS) PDU SESSION MODIFICATION procedure.
[0037] To perform the 311 UP IPsec SA creation procedure, network 107 sends a 315 CREATE_CHILD_SA message to UE 102. The message for event 315 may include (i) an SPI (represented as SPI) indicating the inbound ESP packet of the user plane IPsec SA. n The Security Association (SA) payload and the 5G_QOS_INFO notification payload indicating the PDU Session ID (PSI).
[0038] In response to receiving a 315 CREATE_CHILD_SA request message, and if UE 102 accepts the proposal, UE 102 sends a 317 CREATE_CHILD_SA response message to network 107. The response 317 to the event may include an SPI (denoted as SPI) indicating an inbound ESP packet for a user plane IPsec SA. u The SA payload of ) is then established. Then, UE 102 and network 107 establish UP subSA 319. When the NAS procedure triggers UP IPsec SA creation procedure 311 and UP IPsec SA modification procedure 331, UE 102 and network 107 perform NAS procedure message exchange 321 and 323.
[0039] like Figure 3 As illustrated, network 107 can initiate a UP IPsec SA modification procedure 331 by requesting from an upper layer (e.g., a NAS procedure) or by requesting to modify an existing UP IPsec SA. The NAS procedure can be a PDU SESSION MODIFICATION procedure, in which UE 102 sends a 333 PDU SESSION MODIFICATION request message to network 107.
[0040] The UP IPsec SA modification process involves network 107 exchanging INFORMATIONAL messages 335 and 337. Specifically, network 107 sends an INFORMATIONAL request to UE 102, which includes a 5G_QOS_INFO notification payload indicating that the PDU Session ID (PSI) is indicated, but excluding the SPI. Because network 107 does not identify the UP IPsec SA to be modified, UE 102 cannot correctly make the corresponding changes. For example, when message 335 includes a 5G_QOS_INFO notification payload, network 107 sets the Security Parameter Index (SPI) length to 0, thereby omitting the SPI from the 5G_QOS_INFO notification payload.
[0041] Therefore, in this situation, UE 102 is unable to send the 337 INFORMATIONAL response message to the network and cannot complete the 339 UP subSA modification. Then, UE 102 and network 107 are unable to perform the 341 and 343 NAS procedure exchanges.
[0042] On the other hand, UE 102 and network 107 can use Figures 4A to 4C The technology was used to successfully complete the UP IPsec SA modification process. Figure 3 and Figure 4A In the diagram, similar events are labeled using similar reference numerals (e.g., event 301 and...). Figures 4A to 4C Similar to event 401, event 305 is similar. Figures 4A to 4C Similar to event 405, event 313 is similar. Figures 4A to 4C (Similar to event 413 in the text, etc.). For this reason, these similar events will not be discussed further, and only relevant differences will be considered below.
[0043] refer to Figure 4A During the execution of the 432A IPsec SA modification procedure, network 107 sends an INFORMATIONAL request message 436A containing the SPI (denoted as SPIn) of the inbound ESP packet of the user plane IPsec SA in the 5G_QOS_INFO notification payload. The 5G_QOS_INFO notification payload is extended to include SPIn.
[0044] refer to Figure 4BDuring the 432B IPsec SA modification process, network 107 sends an INFORMATIONAL request message for the inbound ESP packet of the user plane IPsec SA with a 436B “new” payload (i.e., a payload in a format specifically for UP IPsec SA modification) (e.g., a 5G_QOS_INFO_MOD notification payload).
[0045] refer to Figure 4C During the execution of the 432C IPsec SA modification process, network 107 sends an INFORMATIONAL request message 436B for the inbound ESP packet of the user plane IPsec SA with the SA payload containing the SPI (denoted as SPIn).
[0046] Refer to Figure 4 to Figure 4C In some implementations, network 107 may indicate the SPI (referred to as SPIn) of the inbound ESP packet of the user plane IPsec SA, or the SPI of the outbound ESP packet of the UPIPsec SA (i.e., the inbound ESP packet of the UP IPsec SA on the UE side) (referred to as SPIU), or both, in the INFORMATIONAL request message of events 436A, 436B, or 436C.
[0047] Upon receiving an INFORMATIONAL request message (436A, 436B, or 436C), UE 102 can use the SPI to identify the UP IPsec SA. After performing the required modifications on the corresponding UP IPsec SA, UE 102 sends a 437 INFORMATIONAL response message to the network and completes the 439 UP sub-SA modification. If the NAS procedure triggers the UP IPsec SA modification procedure (432A, 432B, or 432C), then NAS procedure exchanges (441 or 443) occur as part of the UP IPsec SA modification procedure (432A, 432B, or 432C).
[0048] then, Figures 5A to 5C Example networks can implement example methods 500A-500C to perform the UP IPsec SA modification process. At block 501, the network (e.g., network 107) determines that the UP IPsec SA modification / creation is triggered or initiated, where the SPI is associated with the UP IPsec SA.
[0049] At box 503, the sending entity (e.g., network 107) determines whether the triggered process is an UP IPsec SA modification process or an UP IPsec SA creation process. If the process is an UP IPsec SA creation process, the network includes a 5G_QOS_INFO notification payload without an SPI value in the request message (e.g., a CREATE_CHILD_SA request message) at box 505. However, if the process is an UP IPsec SA modification process, the network includes a 5G_QOS_INFO notification payload expanded to indicate the SPI value in the INFORMATIONAL request message. Figure 5A Box 507A), and payloads dedicated to the modification process (e.g., the 5G_QOS_INFO_MOD notification payload used to indicate SPI values). Figure 5B (frame 507B), or SA payload used to indicate SPI value ( Figure 5C (Frame 507C).
[0050] In some implementations, the sending entity (such as network 107) may indicate the SPI of the inbound ESP packet of the user plane IPsec SA, or the SPI of the outbound ESP packet of the UP IPsec SA, or both, in the INFORMATIONAL request message.
[0051] Figure 6 This is a flowchart of an example method 600 for processing messages related to a UP IPSec SA in UE 102 or another example suitable UE. Method 600 begins at box 602, where the UE establishes a UP IPSec SA with a network element (e.g., N3IWF 107). Figures 4A to 4C (Process 411). At box 604, the UE receives a request from a network element to modify the UP IPsec SA, which includes an SPI (e.g., to identify the UP IPsec SA). Figures 4A to 4C Events 436A, 436B, or 436C). At box 606, the UE modifies the UP IPsec SA upon request (e.g., ...). Figures 4A to 4C Event 439).
[0052] at last, Figure 7 Example QoS model 700 is shown. According to this QoS model, UE 102 and network 107 can apply QoS rules, map packets to QoS flows, apply QoS tags, map QoS flows to AN resources, classify packets, etc.
[0053] The following descriptions can be applied to the descriptions above.
[0054] Generally, a description of one of the above figures can be applied to another of the above figures. The events or boxes mentioned above may be optional or omitted. For example, the events or boxes with dashed lines in the attached figures may be optional. In some implementations, "message" is used and can be replaced with "information element (IE)" and vice versa. In some implementations, "IE" is used and can be replaced with "field" and vice versa. In some implementations, "configuration(s)" or "configuration parameters" can be used to replace "configuration(s)" and vice versa. In some implementations, "PDSCH transmission" or "transmission on PDSCH" can be used to replace "PDSCH".
[0055] User devices (e.g., UE 102) that can implement the technologies disclosed herein can be any suitable device capable of wireless communication, such as smartphones, tablet computers, laptop computers, mobile game consoles, point-of-sale (POS) terminals, health monitoring devices, drones, cameras, media streaming dongles or other personal media devices, wearable devices such as smartwatches, wireless hotspots, femtocells, or broadband routers. Furthermore, in some cases, the user device can be embedded in electronic systems such as a vehicle's head unit or an advanced driver assistance system (ADAS). Even further, the user device can operate as an Internet of Things (IoT) device or a mobile internet device (MID). Depending on the type, the user device may include one or more general-purpose processors, computer-readable storage, a user interface, one or more network interfaces, one or more sensors, etc.
[0056] Some embodiments described in this disclosure include logic or multiple components or modules. A module can be a software module (e.g., code stored on a non-transitory machine-readable medium) or a hardware module. A hardware module is a tangible unit capable of performing certain operations and can be configured or arranged in a particular manner. A hardware module may include a dedicated circuit system or logic permanently configured to perform certain operations (e.g., configured as a dedicated processor, such as a field-programmable gate array (FPGA) or application-specific integrated circuit (ASIC)). A hardware module may also include programmable logic or circuit systems temporarily configured by software to perform certain operations (e.g., as included within a general-purpose processor or other programmable processor). The decision to implement a hardware module in a dedicated and permanently configured circuit system or in a temporarily configured circuit system (e.g., a software-configured circuit system) can be driven by cost and time considerations.
[0057] When implemented in software, the technology can be provided as part of an operating system, a library used by multiple applications, a specific software application, etc. The software can be executed by one or more general-purpose processors or one or more dedicated processors.
[0058] As used herein, the term “or” should be interpreted inclusively, or as referring to any one or any combination thereof, unless otherwise expressly indicated, mutually exclusive, or indicated by the context. Thus, in this document, the expression “A or B” means “A, B, or both A and B”.
[0059] Upon reading this disclosure, those skilled in the art will understand additional alternative structures and functional designs for managing multi-cell PDSCH transmission using the principles disclosed herein. Therefore, while specific embodiments and applications have been illustrated and described, it should be understood that the disclosed embodiments are not limited to the precise constructions and components disclosed herein. Various modifications, alterations, and variations that will be apparent to those skilled in the art may be made to the arrangement, operation, and details of the methods and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims.
Claims
1. A method implemented in a user equipment (UE), the method comprising: Establish user plane Internet Protocol Security (IPsec) security associations (SAs) with network elements; Receive a request from the network element to modify the UP IPsec SA, the request including a Security Parameter Index (SPI) for identifying the UP IPsec SA; as well as Modify the UP IPsec SA according to the request.
2. The method of claim 1, wherein the SPI corresponds to the inbound encapsulated security payload (ESP) packet of the UP IPsec SA.
3. The method of claim 1 or 2, wherein the SPI is included in the information payload of the request to modify the UP IPsec SA.
4. The method of claim 3, wherein the payload is a type of modification specifically for the UP IPsec SA.
5. The method as described in any one of the preceding claims, further comprising: In response to the request, an information response is sent to the network.
6. The method as described in any of the preceding claims, wherein the network element is implemented in a non-3GPP interoperability function N3IWF.
7. The method as described in any of the preceding claims, wherein: The request to modify the UP IPsec SA includes a request to modify the Quality of Service (QoS) parameters associated with the UP IPsec SA.
8. The method as described in any of the preceding claims, wherein: The UP IPsec SA is associated with multiple QoS flows.
9. A method implemented in the core network of a telecommunications system, the method comprising: Establish a user plane Internet Protocol Security (IPsec) security association (SA) with the user equipment (UE); Send a request to the UE to modify the UP IPsec SA, the request including a Security Parameter Index (SPI) for identifying the UP IPsec SA; as well as Receive a response to the request from the UE.
10. The method of claim 9, further comprising: During the establishment process, a first type of payload is included in the message to the UE; as well as The request to modify the UP IPsec SA includes a second type of payload.
11. The method of claim 9 or 10, wherein the SPI corresponds to the inbound encapsulated security payload (ESP) packet of the UP IPsec SA.
12. The method of claim 9, wherein the SPI is included in the information payload of the request to modify the UP IPsec SA.
13. The method according to any one of claims 9 to 12, wherein: The request to modify the UP IPsec SA includes a request to modify the Quality of Service (QoS) parameters associated with the UP IPsec SA.
14. The method according to any one of claims 9 to 13, wherein: The UP IPsec SA is associated with multiple QoS flows.
15. An apparatus comprising processing hardware and configured to implement the method as described in any of the preceding claims.