WO2024178028A1

WO2024178028A1 - User plane ipsec sa modification

Info

Publication number: WO2024178028A1
Application number: PCT/US2024/016586
Authority: WO
Inventors: Jj Huangfu; Po-Chun Lee
Original assignee: Google Llc
Priority date: 2023-02-20
Filing date: 2024-02-20
Publication date: 2024-08-29

Abstract

A user equipment (UE) establishes (602), with a network element, a user-plane (UP) Internet Protocol Security (IPsec) Security Association (SA); receives (604), from the network element, a request to modify the UP IPsec SA, the request including a Security Parameter Index (SPI) to identify the UP IPsec SA; and modifies (606) the UP IPsec SA according to the request.

Description

USER PLANE IPSEC SA MODIFICATION

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to and the benefit of the filing date of provisional U.S. Patent Application No. 63/447,036, titled “Enhancement of User Plane IPSec SA Modification Procedure,” filed on February 20, 2023. The entire contents of the provisional application are hereby expressly incorporated herein by reference.

FIELD OF THE DISCLOSURE

[0002] This disclosure relates generally to wireless communications and, more particularly, the user plane IPsec SA modification mechanism for non-3GPP access.

BACKGROUND

[0003] This background description is provided for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0004] A user equipment (UE) can access a fifth -generation (5G) network via a network that conforms to the standards developed by the 3rd Generation Partnership Project (3GPP), i.e., using 3GPP access. The UE also can access the 5G network using non-3GPP access, which can be trusted or non-trusted. For untrusted non-3GPP access, the UE accesses the 5G core network via a Non-3GPP InterWorking Function (N3IWF).

[0005] Generally speaking, a quality-of-service (QoS) flow represents the finest granularity for QoS forwarding treatment in a 5G System (5GS), which applies the same forwarding treatment (e.g. the scheduling policy, the queue management policy, the rate shaping policy, the radio link control (RLC) configuration) to all traffic mapped to the same QoS flow. To provide a different QoS forwarding treatment, the 5GS uses a different 5G QoS flow. For clarity, the generally accepted QoS model is illustrated in Fig. 7.

[0006] Network nodes classify the traffic from upper layers (e.g., applications) into QoS flows based on the QoS rules, each including one or more packet filters. The 3GPP or non-3GPP access network can bind QoS Flows to access network resources. For 3GPP access, these access network resources are Data Radio Bearers (DRB). The 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 flow 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 illustrated in Fig. 2B.

[0007] During the establishment of a user plane (UP) IPsec SA, the network may provide a differentiated services code point (DSCP) value for associating with the IPsec SA. When the network provides the DSCP value associated with the IPsec SA, the UE sets the DSCP value of the outer IP header to the DSCP value provided by the network. In this manner, the network and the UE can differentiate the QoS treatment among different IPsec SAs.

[0008] Further, the network can initiate an IPsec SA modification procedure to modify, for example, the QoS parameters of an established UP IPsec SA. The network can also initiate an IPsec SA deletion procedure to delete an existing UP IPsec SA.

[0009] However, it is not clear how the network and the UE can identify a particular UP IPsec SA during the IPsec SA modification procedure.

SUMMARY

[0010] An example embodiment of the techniques of this disclosure is a method implemented in a user equipment (UE). The method comprises establishing, with a network element, a user-plane (UP) Internet Protocol Security (IPsec) Security Association

(SA); receiving, from the network element, a request 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 according to the request.

[0011] Another example embodiment of these techniques is a implemented in a core network of a telecommunication system. The method comprises: establishing, with a user equipment (UE), a user-plane (UP) Internet Protocol Security (IPsec) Security Association (SA); transmitting, to the UE, a request to modify the UP IPsec SA, the request including a Security Parameter Index (SPI) to identify the UP IPsec SA; and receiving, from the UE, a response to the request.

[0012] Still another example embodiment of these techniques is a device comprising processing hardware. The device is configured to implement one of the methods above.

BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Fig. 1 is a block diagram of an example communication system in which a UE can access using 3 GPP access, untrusted non-3GPP access, or trusted non-3GPP access;

[0014] Fig. 2A is a block diagram of an example control plane (CP) protocol stack according to which a UE communicates with the Access and Mobility Management (AMF) of a 5GC;

[0015] Fig. 2B is a block diagram of an example user plane (UP) protocol stack according to which a UE communicates with the User Plane Function (UPF) of a 5GC;

[0016] Fig 3 is a messaging diagram of a 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;

[0017] Fig 4A is a messaging diagram of an example scenario in which a UE and an N3IWF create and modify a UP IPSec SA, and use a 5G QOS INFO Notify payload extended to include a Security Parameter Index (SPI) to identify the UP IPSec SA during the modification procedure;

[0018] Fig 4B is a messaging diagram of an example scenario similar to that of Fig. 4A, but with the N3IWF using a “new” payload, or a payload in a format dedicated to the modification procedure, to identify the UP IPSec SA during the modification procedure;

[0019] Fig 4C is a messaging diagram of an example scenario similar to that of Fig. 4A, but with the N3IWF using the SA payload to identify the UP IPSec SA during the modification procedure; [0020] Figs. 5A-C are flow diagrams of example methods in a network element such as the N3IWF for determining which payload to include in a message to a UE, depending on whether the message pertains to a UP IPSec SA creation procedure or a UP IPSec SA modification procedure;

[0021] Fig. 6 is a flow diagram of an example method in a UE for processing a message related to a UP IPSec SA; and

[0022] Fig. 7 illustrates an example QoS model according to which the UE and the network of this disclosure can operate.

DETAILED DESCRIPTION OF THE DRAWINGS

[0023] 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 particularly, th enetwork element can include an SPI in a message to the UE to identify the UP IPsec SA.

[0024] Referring to Fig. 1, a system 100 includes a UE 102 that can access a 5GC 110 via multiple access resources, including 3 GPP access, untrusted non-3GPP access, and trusted non- 3 GPP access. For 3 GPP 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 as an anchor, with Evolved UMTS Terrestrial Radio Access (E-UTRA) extensions, (iii) standalone E- UTRA, or (iv) E-UTRA as the anchor, with NR extensions.

[0025] For untrusted non-3GPP access, the UE 102 accesses the 5GC 110 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, sequentially. For trusted non- 3GPP access, the UE 102 accesses the 5GC 110 via a Trusted Non-3GPP Access Point (TNAP) 108 and a Trusted Non-3GPP Gateway Function (TNGF) 109, sequentially. [0026] The 5GC 110 can include various components (most of which are not shown in Fig. 1 to avoid clutter) including am Access and Mobility Management Function (AMF) 164, a Session Management Function (SMF) 166, and a User Plane Function (UPF) 162.

[0027] The AMF 164 can provide such functionality as for example non-access-stratum (NAS) ciphering and integrity protection, registration management, connection management, reachability management, mobility management, lawful intercept (LI) (for AMF events and an interface to an LI system), and providing transport for SM messages between UE 102 and the SMF 166.

[0028] The SMF 162 can provide such functionality as for example session management (e.g. session establishment, modification and release, tunnel maintenance between the UPF 162 and access network (AN) node, UE IP address allocation & management, Dynamic Host Configuration Protocol version 4 DHCPv4 (server and client) and DHCPv6 (server and client) functions, selection and control of UP functions, configuration of traffic steering at the UPF 162 to route traffic to the proper destination.

[0029] The UPF 162 can provide such functionality as for example providing an anchor point support for Intra-/Inter-RAT mobility, allocation of UE IP address/prefix in response to an SMF request, providing an external PDU session point of interconnect to a data network, packet routing & forwarding, packet inspection, providing a UP part of policy rule enforcement, lawful intercept, traffic usage reporting, and QoS handling for UP, e.g., uplink (UL)/downlink (DL) rate enforcement and reflective QoS marking in DL.

[0030] With continued reference to Fig. 1, the UE 102 is equipped with processing hardware 170 that can include one or more general-purpose processors (e.g., CPUs) and a non-transitory computer-readable memory storing instructions that the one or more general-purpose processors execute. Additionally or alternatively, the processing hardware 130 can include special-purpose processing units. The processing hardware 130 can implement an IPsec SA modification controller 172 configured, in part, to process an information request message in a format discussed with reference to Figs. 4A-C. The N3IWF 107 also is equipped with processing hardware 180 that can include one or more general-purpose processors (e.g., CPUs) and a non- transitory computer-readable memory storing instructions that the one or more general-purpose processors execute. Additionally or alternatively, the processing hardware 180 can include special-purpose processing units. The processing hardware 180 can implement an IPsec SA modification controller 182 configured, in part, to generate an information request message in a format discussed with reference to Figs. 4A-C.

[0031] Next, Fig. 2A is a block diagram of an example control plane (CP) protocol stack 200A according to which the UE 102 communicates with the AMF 164. Generally speaking, the UE 102 establishes an IPsec tunnel for NAS signaling when registering w the 5GC 110 (e.g., as specified in TS 23.502, sub-clause 4.12.2). A NAS message travels over the Transmission Control Protocol (TCP) and the IPsec tunnel to the N3IWF 107, and then the NAS message travels to the AMF 103 via the N3IWF 107 or TNGF 109.

[0032] Fig. 2B is a block diagram of an example user plane (UP) protocol stack 200B according to which the UE 102 communicates with the UPF 162. At the user plane, the network and/or the UE 102 map each QoS flow to a GRE tunnel, and map multiple GRE tunnels to an IPsec tunnel.

[0033] Now referring to Fig. 3, an example scenario 300 includes an UP IPsec SA creation procedure as well as a UP IPsec SA modification procedure. In the scenario 300 as well as scenarios 400A-C, the N3IWF 107 represents the network, and the terms “N3IWF” and the “network” can be used interchangeably in the discussion of these scenarios.

[0034] To access the 5G CN using non-3GPP access, the UE 102 first establishes 303 an Internet Key Exchange IKE Security Association (SA) with the network (e.g., the N3IWF 107 for untrusted non-3GPP access) by exchanging 301 IKE INIT messages. The UE 102 and the network then exchange 305 IKE AUTH messages and establish 307 the first IPsec child SA for signaling.

[0035] The UE 102 and the network 107 perform 311 an UP IPsec SA creation procedure. The network 107 can initiate the UP IPsec SA creation procedure by upper layer requests (e.g., NAS procedures) or requirements to establish a new UP IPsec SA. According to one such NAS procedures, the UE 102 chooses to establish a new PDU session by initiating 313 a (NAS) PDU SESSION ESTABLISHMENT procedure. According to another procedures, the UE 102 or the network 107 chooses to add one or more new QoS flows in an existing PDU session by initiating 313 a (NAS) PDU SESSION MODIFICATION procedure.

[0036] To perform 311 UP IPsec SA creation procedure, the network 107 transmits 315 a CREATE CHILD SA message the UE 102. The message of the event 315 can include (i) the Security Association (SA) payload indicating the SPI of the inbound ESP packets of the user plane IPsec SA, denoted as SPIn, and the 5G QOS INFO Notify payload indicating PDU session ID (PSI).

[0037] In response to receiving 315 the CREATE CHILD SA Request message, and if the UE 102 accepts the proposal, the UE 102 transmits 317 a CREATE CHILD SA Response message to the network 107. The response to the event 317 can include the SA payload indicating the SPI of the inbound ESP packets of the user plane IPsec SA, denoted as SPIu. The UE 102 and the network 107 then establish 319 the UP child SA. When a NAS procedure triggers the UP IPsec SA creation procedure 311 and UP IPsec SA modification procedure 331, the UE 102 and the network 107 perform 321, 323 a NAS procedure message exchange.

[0038] As illustrated in Fig. 3, the network 107 may initiate the UP IPsec SA modification procedure 331 by upper-layer requests (e.g., NAS procedures) or the requirement to modify an existing UP IPsec SA. The NAS procedure may be the PDU SESSION MODIFICATION procedure, in which the UE 102 transmits 333 a PDU SESSION MODIFICATION request message to the network 107.

[0039] The UP IPsec SA modification procedure includes the network 107 exchanging 335, 337 INFORMATIONAL messages. In particular, the network 107 transmits, to the UE 102, an INFORMATIONAL request that includes a 5G QOS INFO Notify payload, which indicates the PDU session ID (PSI) is indicated but does not include an SPI. Because the network 107 does not identify the UP IPsec SA to be modified, the UE 102 cannot make the corresponding change correctly. For example, when the message of the event 335 includes the 5G_QOS_INFO Notify payload, the network 107 sets the Security Parameter Index (SPI) length to 0, and thus omit the SPI in the 5G QOS INFO Notify payload. [0040] Thus, the UE 102 in this case cannot transmit 337 an INFORMATIONAL Response message to the network and cannot complete 339 the UP child SA modification. The UE 102 and the network 107 then cannot perform 341, 343 a NAS procedure exchange.

[0041] On the other hand, the UE 102 and the network 107 can successfully complete the UP IPsec SA modification procedure using the techniques of Figs. 4A-C. In Figs. 3 and 4A, events that are similar are labeled with similar reference numbers (e.g., event 301 is similar to event 401 in Figs. 4A-C, event 305 is similar to event 405 in Figs. 4A-C, event 313 is similar to event 413 in Fig. 4A-C, etc.). For this reason, these similar are events are not discussed again, and only relevant differences are considered below.

[0042] Referring to Fig. 4A, when performing 432A an IPsec SA modification procedure, the network 107 transmits 436A an INFORMATIONAL Request message with the SPI of the inbound ESP packets of the user plane IPsec SA, denoted as SPIn, in the 5G QOS INFO Notify payload. The 5G QOS INFO Notify payload is extended to include the SPIn.

[0043] Referring to Fig. 4B, when performing 432B an IPsec SA modification procedure, the network 107 transmits 436B an INFORMATIONAL Request message with the SPI of the inbound ESP packets of the user plane IPsec SA, denoted as SPIn, in a “new” the payload (i.e., a payload in a format dedicated to modification of the UP IPsec SA), e.g., 5G QOS INFO MOD Notify payload.

[0044] Referring to Fig. 4C, when performing 432C an IPsec SA modification procedure, the network 107 transmits 436B an INFORMATIONAL Request message with the SPI of the inbound ESP packets of the user plane IPsec SA, denoted as SPIn, in the SA payload.

[0045] Referring to Figs. 4-C, in some implementations, the network 107 can indicate either the SPI of the inbound ESP packets of the user plane IPsec SA, denoted as SPIn, or the SPI of the outbound ESP packets of the UP IPsec SA (i.e., the inbound ESP packets of the UP IPsec SA in the UE side), denoted as SPIu., or both in the INFORMATIONAL Request message of event 436A, 436B, or 436C. [0046] Upon receiving 436A, 436B, or 436C the INFORMATIONAL Request message, the UE 102 can identify the UP IPsec SA using the SPI. After performing the required modification on the corresponding UP IPsec SA, the UE 102 transmits 437 an INFORMATIONAL Response message to the network and completes 439 the UP child SA modification. If a NAS procedure triggers the UP IPsec SA modification procedure 432A, 432B, or 432C, the NAS procedure exchange 441, 443 occurs as a part of the UP IPsec SA modification procedure 432A, 432B, or 432C.

[0047] Next, Figs. 5A-C illustrate example methods 500A-C which a network can implement to perform a UP IPsec SA modification procedure. At block 501, the network (e.g., the network 107) determines that an UP IPsec SA modification/creation is triggered or initiated, where an SPI is associated with the UP IPsec SA.

[0048] At block 503, the sending entity (e.g., the network 107) determines whether the triggered procedure is a UP IPsec SA modification procedure or a UP IPsec SA creation procedure. If the procedure is UP IPsec SA creation procedure, the network includes the 5G QOS INFO Notify payload without an SPI value in the request message (e.g., CREATE CHILD SA Request message), at block 505. However, if the procedure is a UP IPsec SA modification procedure, the network includes the 5G QOS INFO Notify payload extended to indicate the SPI value (block 507A of Fig. 5 A), a payload dedicated to the modification procedure, e.g., 5G_QOS_TNFO_MOD Notify payload to indicate the SPI value (block 507B of Fig. 5B), or the SA payload to indicate the SPI value (block 507C of Fig. 5C), in the INFORMATIONAL Request message.

[0049] In some implementations, the sending entity such as the network 107 can indicate either the SPI of the inbound ESP packets of the user plane IPsec SA, or the SPI of the outbound ESP packets of the UP IPsec SA, or both in the INFORMATIONAL Request message.

[0050] Fig. 6 is a flow diagram of an example method 600 in a UE 102 or another example suitable UE, for processing a message related to a UP IPSec SA. The method 600 begins at block 602, where the UE establishes, with a network element (e.g., the N3IWF 107), a UP IPsec SA (e.g., procedure 411 of Figs. 4A-C). At block 604, the UE receives, from the network element, a request to modify the UP IPsec SA, the request including an SPI to identify the UP IPsec SA (e.g., event 436A, 436B, or 436C of Figs. 4A-C). At block 606, the UE modifies the UP IPsec SA according to the request (e.g., event 439 of Figs. 4A-C).

[0051] Finally, Fig. 7 illustrates an example QoS model 700 according to which the UE 102 and the network 107 can apply QoS rules, map packets to QoS flows, apply QoS marking, map QoS flows to AN resources, classify packets, etc.

[0052] The following description may be applied to the description above.

[0053] Generally speaking, description for one of the above figures can apply to another of the above figures. An event or block described above can be optional or omitted. For example, an event or block with dashed lines in the figures can be optional. In some implementations, “message” is used and can be replaced by “information element (IE)”, and vice versa. In some implementations, “IE” is used and can be replaced by “field”, and vice versa. In some implementations, “configuration” can be replaced by “configuration(s)” or “configuration parameter(s)”, and vice versa. In some implementations, “PDSCH” can be replaced by “PDSCH transmission” or “a transmission on a PDSCH”.

[0054] A user device in which the techniques of this disclosure can be implemented (e.g., the UE 102) can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media-streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an intemet-of-things (loT) device or a mobile-internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0055] Certain embodiments are described in this disclosure as including logic or a number of components or modules. Modules may can be software modules (e.g., code stored on non- transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

[0056] When implemented in software, the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. The software can be executed by one or more general -purpose processors or one or more special-purpose processors.

[0057] The term “or” as used herein is to be interpreted as an inclusive or meaning any one or any combination, unless expressly indicated otherwise, mutually exclusive, or indicated otherwise by context. Therefore, herein, the expression “A or B” means “A, B, or both A and B.”

[0058] Upon reading this disclosure, those of skill in the art will appreciate still additional alternative structural and functional designs for managing multi -cell PDSCH transmissions through the disclosed principles herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those of ordinary skill in the art, may be made in the arrangement, operation and details of the method and apparatus disclosed herein without departing from the spirit and scope defined in the appended claims.

Claims

What is claimed is:

1. A method implemented in a user equipment (UE), the method comprising: establishing, with a network element, a user-plane Internet Protocol Security (IPsec) Security Association (SA); receiving, from the network element, a request 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 according to the request.

2. The method of claim 1, wherein the SPI corresponds to inbound Encapsulating Security Payload (ESP) packets of the UP IPsec SA.

3. The method of claim 1 or 2, wherein the SPI is included in an information payload of the request to modify the UP IPsec SA.

4. The method of claim 3, wherein the payload is of a type dedicated to modification of the UP IPsec SA.

5. The method of any of the preceding claims, further comprising: transmitting, to the network and in response to the request, an informational response.

6. The method of any of the preceding claims, wherein the network element is implemented in a Non-3GPP InterWorking Function (N3IWF).

7. The method of any of the preceding claims, wherein: the request to modify the UP IPsec SA includes a request to modify quality-of-service (QoS) parameters associated with the UP IPsec SA.

8. The method of any of the preceding claims, wherein: the UP IPsec SA is associated with a plurality of QoS flows.

9. A method implemented in a core network of a telecommunication system, the method comprising: establishing, with a user equipment (UE), a user-plane Internet Protocol Security (IPsec) Security Association (SA); transmitting, to the UE, a request to modify the UP IPsec SA, the request including a Security Parameter Index (SPI) to identify the UP IPsec SA; and receiving, from the UE, a response to the request.

10. The method of claim 9, further comprising: including a first type of a payload in a message to the UE during the establishing; and including a second type of a payload in the request to modify the UP IPsec SA.

11. The method of claim 9 or 10, wherein the SPI corresponds to inbound Encapsulating Security Payload (ESP) packets of the UP IPsec SA.

12. The method of claim 9, wherein the SPI is included in an information payload of the request to modify the UP IPsec SA.

13. The method of any of claims 9-12, wherein: the request to modify the UP IPsec SA includes a request to modify quality-of-service (QoS) parameters associated with the UP IPsec SA.

14. The method of any of claims 9-13, wherein: the UP IPsec SA is associated with a plurality of QoS flows.

15. A device comprising processing hardware and configured to implement a method of any of the preceding claims.