Techniques to enable controlled traffic flow through proxy network node

Abstract

A method of enabling controlled flow of user data traffic between a user equipment (UE) and a server by the UE via at least one proxy network node of a plurality of proxy network nodes reachable by the RAN is disclosed. The method is performed by a UE, a first proxy network node of a plurality of proxy network nodes, and a core network node, respectively. A UE, a corresponding node, a computer program and a system are also disclosed.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to a method enabling a controlled flow of user data traffic between a User Equipment, UE, and a server through at least one of a plurality of proxy network nodes. A UE, a first proxy network node, a core network node, a system, a computer program and a carrier are also provided. BACKGROUND

[0002] User data traffic can be routed between a UE and a server through a proxy network node reachable by the UE via a Radio Access Network, RAN. Existing solutions rely on a predetermined association of the proxy network node with the UE for routing user data traffic from the UE to the server. In certain scenarios, this predetermined association can result in the proxy network node that is routing the user data traffic not having the desired capabilities in terms of e.g. Quality of Service, QoS.

[0003] Some solutions rely on providing a chain of proxy network nodes via which user data traffic is routed between the UE and the server. Such a chain typically comprises an ingress proxy network node and an egress proxy network node. Again, providing a predetermined and fixed association of the chain of proxy network nodes with the UE can be disadvantageous. For example, different applications that can be executed on the UE can have different latency requirements, and thus always using the same chain of proxy network nodes can not be optimal in terms of resource usage.

[0004] Finally, known solutions typically do not enable a Mobile Network Operator, MNO, to influence the traffic routing via proxy network nodes. SUMMARY

[0005] There is a need for a technique enabling a controlled flow of user data traffic between a UE and a server through at least one of a plurality of proxy network nodes reachable by the UE via a RAN. The technique can solve one or more of the above problems or other problems.

[0006] According to a first aspect, there is provided a method of enabling controlled flow of user data traffic between a UE and a server through at least one of a plurality of proxy network nodes reachable by the UE via a RAN. The method is performed by the UE and comprises: obtaining, from a core network node (e.g., a core network node connected to and / or associated with a core network of the RAN), at least one routing selection rule associating one or more of the plurality of proxy network nodes with at least one user data traffic parameter; and selecting, based on the obtained at least one routing selection rule, at least one of the plurality of proxy network nodes for routing the user data traffic between the UE and the server through the selected at least one proxy network node.

[0007] The user data traffic can be associated with or caused by an application executing on the UE. The UE can be configured to connect to the (e.g., selected) at least one of the plurality of proxy network nodes via the RAN. The core network node can implement one or more network functions of the core network. The selection can be further performed based on the user data traffic (e.g., the at least one user data traffic parameter of the user data traffic).

[0008] In one example, the selected at least one proxy network node is part of a chain of proxy network nodes via which the user data traffic is to be routed, the chain comprising a first proxy network node of the plurality of proxy network nodes and a second proxy network node of the plurality of proxy network nodes.

[0009] In one example, the selected at least one proxy network node is the first proxy network node or the second proxy network node.

[0010] In one example, the first proxy network node is an ingress proxy network node and the second proxy network node is an egress proxy network node, or wherein the first proxy network node is an egress proxy network node and the second proxy network node is an ingress proxy network node.

[0011] In one example, the first proxy network node is configured to implement a User Plane (UP) function.

[0012] In one example, the first proxy network node is configured as a User Plane Function (UPF) of a Core Network (CN), a Packet Gateway User Plane (PGW-U), or a Traffic Detection Function User Plane (TDF-U).

[0013] The method may further include: obtaining the identifier of the first proxy network node from the core network node; and directing user data traffic to the first proxy network node based on the obtained identifier.

[0014] In one example, at least one routing rule associates one or more second proxy network nodes with at least one user data traffic parameter.

[0015] The method may further include sending a Packet Data Unit (PDU) session establishment request message to the core network node, wherein the identifier of the first proxy network node is obtained in response to the PDU session establishment request message.

[0016] The method may further include: directing user data traffic to at least one selected proxy network node.

[0017] In one example, one or more routing rules include at least one User Equipment Route Selection Policy (URSP).

[0018] In one example, the user data traffic between the UE and the server is encrypted such that the payload of the user data traffic is hidden from at least one selected proxy network node, and optionally from each of a plurality of proxy network nodes.

[0019] In one example, user data traffic between the UE and the server is QUIC encrypted.

[0020] In one example, at least one of the selected proxy network nodes includes a Multiplexed Application Substrate over QUIC Encryption (MASQUE) proxy network node.

[0021] In one example, at least one user data traffic parameter is a Traffic Category (TC) and / or is associated with the application that causes the user data traffic, such as being associated with the application's identifier or type.

[0022] According to a second aspect, a UE is provided, configured to enable controlled flow of user data traffic between the UE and a server via at least one of a plurality of proxy network nodes reachable by the UE via a RAN. The UE includes at least one memory and at least one processor, the at least one memory storing instructions that, when executed by the at least one processor, cause the at least one processor to: obtain at least one routing rule from a core network node (e.g., a core network node connected to and / or associated with a core network of the RAN), the at least one routing rule associating one or more of the plurality of proxy network nodes with at least one user data traffic parameter; and, based on the obtained at least one routing rule, select at least one of the plurality of proxy network nodes for routing user data traffic between the UE and the server via the selected at least one proxy network node.

[0023] In one example, the at least one memory stores instructions that, when executed by at least one processor, cause at least one processor to perform the method according to the first aspect.

[0024] According to a third aspect, a computer program is provided. The computer program stores instructions that, when executed by at least one processor, cause at least one processor to perform the method according to the first aspect.

[0025] According to the fourth aspect, a carrier is provided. This carrier carries the computer program of the third aspect.

[0026] According to this disclosure, the carrier may be one of a data stream, an electronic signal, (e.g., a non-transitory) storage medium, or a memory.

[0027] According to a fifth aspect, a method is provided that enables controlled flow of user data traffic between a UE and a server via at least one of a plurality of proxy network nodes reachable by the UE via a RAN. The method is performed by a first proxy network node among the plurality of proxy network nodes and includes: sending a session establishment message to a core network node (e.g., a core network node connected to and / or associated with a core network of the RAN), the session establishment message including an identifier of the first proxy network node, which is indicated to the UE via the core network node, for configuring the UE to direct user data traffic to the first proxy network node based on the acquired identifier.

[0028] In one example, the session establishment message is a Packet Flow Control Protocol (PFCP) session establishment response message.

[0029] In one example, multiple proxy network nodes are configured to form multiple chains through which user data traffic can be routed, each chain including a first proxy network node and a second proxy network node among the multiple proxy network nodes.

[0030] In one example, the first proxy network node is an ingress proxy network node and the second proxy network node is an egress proxy network node, or the first proxy network node is an egress proxy network node and the second proxy network node is an ingress proxy network node.

[0031] The method may further include: obtaining one or more user plane (UP) rules from the core network node, wherein the one or more user plane (UP) rules assign the identifier of one or more second proxy network nodes from a plurality of proxy network nodes to one or more traffic management actions to be performed by the first proxy network node.

[0032] In one example, one or more UP rules are indicated by a PFCP session establishment request message.

[0033] The method may further include: performing header detection on the UE's user data traffic to obtain the identifier of one of the one or more second proxy network nodes; and performing a traffic management action assigned by one or more UP rules to the obtained identifier.

[0034] In one example, the user data traffic between the UE and the server is encrypted such that the payload of the user data traffic is hidden from at least the first proxy network node, and optionally from each of the multiple proxy network nodes.

[0035] In one example, user data traffic between the UE and the server is QUIC encrypted.

[0036] In one example, the first proxy network node is the MASQUE proxy network node.

[0037] In one example, the first agent network node is configured to implement the UP function.

[0038] In one example, the first proxy network node is configured as a CN UPF, PGW-U, or TDF-U.

[0039] According to a sixth aspect, a first proxy network node is provided, configured to enable controlled flow of user data traffic between a UE and a server via at least one of a plurality of proxy network nodes reachable by the UE via a RAN. The first proxy network node includes at least one memory and at least one processor, the at least one memory storing instructions that, when executed by the at least one processor, cause the at least one processor to: send a session establishment message to a core network node (e.g., a core network node connected to and / or associated with a core network of the RAN), the session establishment message including an identifier of the first proxy network node, which will be indicated to the UE via the core network node, for configuring the UE to direct user data traffic to the first proxy network node based on the acquired identifier.

[0040] In one example, at least one memory stores an instruction that, when executed by at least one processor, causes at least one processor to perform the method according to the fifth aspect.

[0041] According to a seventh aspect, a computer program is provided. The computer program stores instructions that, when executed by at least one processor, cause at least one processor to perform the method according to a fifth aspect.

[0042] According to the eighth aspect, a carrier is provided. This carrier carries the computer program of the seventh aspect.

[0043] According to a ninth aspect, a method is provided that enables controlled flow of user data traffic between a UE and a server via at least one of a plurality of proxy network nodes reachable by the UE via a RAN. The method is performed by a core network node (e.g., a core network node connected to the RAN and / or a core network associated with the RAN) and includes: providing the UE with at least one routing rule that associates one or more of the plurality of proxy network nodes with at least one user data traffic parameter to configure the UE to select at least one of the plurality of proxy network nodes based on the provided routing rule for routing user data traffic between the UE and the server via the selected at least one proxy network node.

[0044] In one example, multiple proxy network nodes are configured to form multiple chains, through which user data traffic can be routed. Each chain includes a first proxy network node and multiple second proxy network nodes to be selected by the UE.

[0045] In one example, the first proxy network node is an ingress proxy network node and the second proxy network node is an egress proxy network node, or the first proxy network node is an egress proxy network node and the second proxy network node is an ingress proxy network node.

[0046] The method may further include: receiving address information of at least one second proxy network node, wherein at least one routing rule is based on the address information.

[0047] The method may further include: determining a binding between address information of at least one second proxy network node and at least one user data traffic parameter, wherein at least one routing rule is based on the binding.

[0048] The method may further include: storing the binding.

[0049] In one example, the binding is determined by either the Network Exposure Function (NEF) or the Service Capability Exposure Function (SCEF), which is implemented by the core network node. This binding can be stored in the User Data Repository (UDR) or the Subscriber Profile Repository (SPR).

[0050] The method may further include: determining at least one routing rule based on the binding.

[0051] In one example, at least one routing rule is determined by the Policy Control Function (PCF), which is implemented by the core network nodes.

[0052] The method may further include: receiving a session establishment message from a first proxy network node among a plurality of proxy network nodes, the session establishment message including an identifier of the first proxy network node; and indicating the identifier of the first proxy network node to the UE for configuring the UE to direct user data traffic to the first proxy network node.

[0053] The method may further include: receiving a PDU session establishment request message from the UE, wherein, in response to the PDU session establishment request message, the identifier of the first agent network node is indicated to the UE.

[0054] The method may further include: determining one or more policy and charging control (PCC) rules for at least one user data traffic parameter.

[0055] In one example, one or more PCC rules are determined by the PCF implemented by the core network nodes.

[0056] The method may further include: providing one or more UP rules to a first proxy network node, the one or more UP rules assigning the identifier of one or more second proxy network nodes from a plurality of proxy network nodes to one or more traffic management actions to be performed by the first proxy network node.

[0057] The method may further include: determining one or more UP rules based on one or more PCC rules.

[0058] In one example, one or more UP rules are determined based on one or more PCC rules and based on binding.

[0059] In one example, one or more UP rules are determined by the Session Management Function (SMF), Packet Gateway Control Plane (PGW-C), or Traffic Detection Function Control Plane (TDF-C) implemented by the core network node.

[0060] In one example, the user data traffic between the UE and the server is encrypted such that the payload of the user data traffic is hidden from at least the first proxy network node, and optionally from each of the multiple proxy network nodes.

[0061] In one example, user data traffic between the UE and the server is QUIC encrypted.

[0062] In one example, the first proxy network node and / or the second proxy network node are MASQUE proxy network nodes.

[0063] In one example, the first agent network node is configured to implement the UP function.

[0064] In one example, the first proxy network node is configured as a CN UPF, PGW-U, or TDF-U.

[0065] In one example, at least one user data traffic parameter is TC and / or is associated with the application that causes the user data traffic, such as being associated with the application's identifier or type.

[0066] According to a tenth aspect, a core network node is provided, configured to enable controlled flow of user data traffic between a UE and a server via at least one of a plurality of proxy network nodes reachable by the UE via a RAN. The core network node (e.g., a core network node connected to the RAN and / or a core network associated with the RAN) includes at least one memory and at least one processor. The at least one memory stores instructions that, when executed by the at least one processor, cause the at least one processor to: provide the UE with at least one routing rule that associates one or more of the plurality of proxy network nodes with at least one user data traffic parameter, configuring the UE to select at least one of the plurality of proxy network nodes based on the provided routing rule for routing user data traffic between the UE and the server via the selected at least one proxy network node.

[0067] In one example, the at least one memory stores instructions that, when executed by at least one processor, cause at least one processor to perform the method according to the ninth aspect.

[0068] According to the eleventh aspect, a computer program is provided. The computer program stores instructions that, when executed by at least one processor, cause at least one processor to perform the method according to the ninth aspect.

[0069] According to the twelfth aspect, a carrier is provided. This carrier carries the computer program of the eleventh aspect.

[0070] According to the thirteenth aspect, a system is provided. The system includes at least two of the following entities: a UE according to the second aspect; a first proxy network node according to the sixth aspect; and a core network node according to the tenth aspect.

[0071] Brief description of the attached figures

[0072] Figure 1 A system according to this disclosure is shown; Figure 2 The method performed by the UE according to this disclosure is shown; Figure 3 The method performed by a proxy network node according to this disclosure is shown; Figure 4 The method performed by a core network node according to this disclosure is shown; Figure 5 The network architecture according to this disclosure is shown; and Figures 6 to 10 The method steps according to this disclosure are shown. Detailed Implementation

[0073] Figure 1 A system 100 according to this disclosure is shown. System 100 includes a UE 200 and a group 300 of proxy network nodes 310-390. User data traffic can be routed between the UE 200 and multiple servers 400-420 via RAN 500 and group 300. Figure 1 The document also illustrates the core network node 600 of CN and the network node 700 of the provider of servers 400-420. When this disclosure refers to network nodes, it should be understood that such network nodes can be implemented as software entities (e.g., in a distributed computing environment) or hardware entities.

[0074] In the example shown, a communication connection is established between UE 200 and server 400 via RAN 500 and proxy network nodes 340 and 370. Each of the proxy network nodes 310-390 can act as both a server and a client, for example, creating or relaying requests on behalf of other entities. Requests can be served internally or by passing them (possibly with translation) to other entities.

[0075] In one example, proxy network nodes 310-390 are each configured as one of the following proxy types: - A "transparent proxy" is a proxy that does not modify the request or response (except for those required for proxy authentication and identification).

[0076] - A "non-transparent proxy" is a proxy that modifies requests or responses to provide additional services to the user agent, such as group annotation services, media type conversion, protocol simplification, or anonymization filtering.

[0077] - A "reverse proxy" is a proxy that pretends to be the actual server (in relation to any client or client proxy), but forwards requests to the actual server, which is usually behind another layer of firewall.

[0078] - "Performance Enhancement Proxy (PEP)" is used to improve the performance of protocols on network paths where native performance is compromised due to the characteristics of links or subnets along the path.

[0079] In the example shown, Proxy Network Nodes (PNNs) 340 and 370 form a PNN chain. PNN 340 acts as the ingress PNN, and PNN 370 acts as the egress PNN of the PNN chain. This arrangement of two PNNs can be referred to as a dual-proxy deployment. One set of PNNs 310-350 can be used as the first (e.g., ingress) PNN of the chain, and another set of PNNs 360-390 can be used as the second (e.g., egress) PNN of the chain.

[0080] The connection established between UE 200 and server 400 can be QUIC encrypted. This allows users to connect to server 400 in a more secure and private manner.

[0081] QUIC is a stream-multiplexed secure transport protocol based on the User Datagram Protocol (UDP), featuring an integrity-protected header and an encrypted payload. Unlike traditional transport protocol stacks like the Transmission Control Protocol (TCP), which resides in the operating system kernel, QUIC can be easily implemented in user space, i.e., at the application layer. This improves the flexibility of transport protocol evolution by enabling new features, congestion control, deployability, and adoption. QUIC is standardized by the Internet Engineering Task Force (IETF), for example in standards RFC 8999, RFC 9000, RFC 9001, and RFC 9002. Unlike Hypertext Transfer Protocol Secure (HTTPS), encryption in QUIC extends to both the transport protocol header and payload, whereas Transport Layer Security (TLS) over TCP (such as HTTPS) only protects the payload.

[0082] PNNs 340 and 370 can be configured as MASQUE PNNs to allow the configuration and concurrent operation of multiple agents for flow-based and datagram-based flows within an HTTPS connection. Through MASQUE, the UE 200 or application creates a secure connection to a network agent on the path (e.g., PNN 340), enabling the establishment of a secure end-to-end (E2E) connection to a server (e.g., 400) via this agent. UE and / or application data can thus be E2E protected and prevented from unauthorized use within the network. Content providers (e.g., providers of servers 400-420) and the MNO can each have secure channels to exchange information about applications and policies in real time.

[0083] UE 200 and / or application clients can explicitly open a QUIC tunnel connection to (e.g., an ingress) PNN and request forwarding. UE 200 and / or application clients can use HTTP-like CONNECT protocols or custom protocols to request or negotiate forwarding, authentication, and configuration.

[0084] A proxy that routes QUIC encrypted user data traffic (a QUIC proxy, such as PNN 340) can provide secure forwarding and performance enhancement services, such as congestion control support (e.g., for mobile or satellite). A QUIC proxy can provide one or more of the following: access policy enforcement, load balancing, load mobility, multi-hop links, and onion routing. If server 400 supports this, the QUIC proxy can also optionally open a tunnel to server 400.

[0085] In this way, the UE 200 or application client explicitly contacts agents 310-390 (e.g., configured as QUIC agents) to open information between the content provider (e.g., application client and / or server 400) and the mobile network operator (e.g., the operator providing the QUIC agent). Figure 1 The dashed arrow indicates the internal connection, which carries encrypted user data traffic between UE 200 and server 400. This user data is not visible to PNN 340 and 370. Figure 1 It also indicates external connections that can be used to open information between content providers (e.g., application clients and / or server 400) and mobile network operators (e.g., providers of QUIC agents).

[0086] During browsing, all traffic leaving UE 200 is QUIC encrypted, ensuring that no one between UE 200 and server 400 can access or read it. All user requests can then be sent via two independent internet relays (i.e., the first PNN 340 and the second PNN 370). PNN 340 can assign an anonymous Internet Protocol (IP) address to UE 200, mapped to its region rather than its actual location. PNN 370 can decrypt the URLs UE 200 wants to access and forward UE 200's requests to its destination server 400. This separation of information protects user privacy because no single entity can simultaneously identify the user or UE 200 and which websites or servers 400 they are visiting. Therefore, this type of solution uses two QUIC / MASQUE proxies acting as relays: - Entry Proxy (Relay 1): The first PNN can assign anonymous IP addresses to users (mapped to their region rather than their actual location). It can have visibility of the user's IP address.

[0087] - Export Proxy (Relay 2): A second PNN can decrypt the URLs they want to access and forward them to their destination. It can have visibility into the destination of user traffic.

[0088] This disclosure provides a technique that enables controlled flow of user data traffic between UE 200 and server 400 via at least one PNN, such as via two PNNs in a dual-proxy deployment.

[0089] Figure 2 A method executed by UE 200 is illustrated. For this purpose, UE 200 includes at least one processor 210 and at least one memory 220 storing instructions that, when executed by at least one processor 210, cause at least one processor 210 to execute the method.

[0090] The method includes: at 2002, obtaining at least one routing rule from core network node 600, the at least one routing rule associating one or more PNNs 310-390 with at least one user data traffic parameter.

[0091] One or more routing rules may include at least one URSP. At least one routing rule may associate one or more second PNNs 360-390 with at least one user data traffic parameter. In one example, at least one user data traffic parameter is a TC and / or is associated with the application that caused the user data traffic, such as with the application's identifier or type.

[0092] The method further includes: at point 2004, based on at least one obtained routing rule, selecting at least one PNN (e.g., PNN 340 and / or 370) from a plurality of PNNs 310-390 for routing user data traffic between UE 200 and server 410 via the selected at least one PNN. UE 200 can then direct user data traffic to the selected at least one PNN.

[0093] The selected at least one PNN can be as follows: Figure 1 The diagram shows a portion of a PNN chain, comprising a first PNN 340 as an entry PNN and a second PNN 370 as an exit PNN. In one example, the selected at least one proxy network node is the first PNN 340, which acts as an entry PNN. In another example, the selected at least one proxy network node is the second PNN 370, which acts as an exit PNN. In one example, the selected at least one PNN includes either a MASQUE PNN or a PNN with a different name.

[0094] It is important to note that the first PNN and / or the second PNN can be implemented by a network function of the CN, or can implement one or more network functions (NFs) of the CN. For example, the first PNN can be configured to implement the UP function. In one example, the first PNN is configured as the CN's UPF, PGW-U, or TDF-U.

[0095] The method may further include sending a PDU session establishment request message to the core network node. In response to sending the message, the method may include obtaining an identifier for a first PNN 340 that acts as an ingress PNN from the core network node 600. In this case, the selected at least one proxy network node may be a second PNN 370 that acts as an egress PNN. The UE 200 may then direct user data traffic to the first PNN based on the obtained identifier.

[0096] In one example, user data traffic between UE 200 and server 410 is encrypted (e.g., QUIC-) such that the payload of the user data traffic is hidden from at least one selected proxy network node 340 and / or 370, and optionally from each of a plurality of proxy network nodes 340, 370 or 310-390.

[0097] Figure 3A method executed by one of the PNNs in group 300 (e.g., PNN 340) is illustrated. For this purpose, PNN 340 may include at least one processor 342 and at least one memory 344 storing instructions that, when executed by at least one processor 342, cause at least one processor 342 to execute the method. This method can be used with... Figure 2 The methods are executed in parallel.

[0098] The method includes sending a session establishment message at point 3002 to core network node 600 (e.g., a core network node connected to RAN 500 and / or a CN associated with RAN 500). The session establishment message may be a PFCP session establishment response message.

[0099] The session establishment message includes an identifier for the first PNN 340, which is indicated to the UE via the core network node 600 to configure the UE to direct user data traffic to the first PNN 340 based on the acquired identifier.

[0100] like Figure 2 Methods and Figure 1 As in the example, multiple proxy network nodes can be configured to form multiple chains, through which user data traffic can be routed. Each chain includes first proxy network nodes 310-350 and second proxy network nodes 360-390 among the multiple proxy network nodes. The first PNN 340 can be configured as an ingress PNN (e.g., MASQUE and / or QUIC), and the second proxy network nodes can be configured as egress PNNs (e.g., MASQUE and / or QUIC), and vice versa.

[0101] The method may include obtaining one or more UP rules from core network node 600, which assign the identifier of one or more second proxy network nodes (e.g., PNN 370) from a plurality of proxy network nodes to one or more traffic management actions to be performed by a first proxy network node (e.g., PNN 340). In one example, the one or more UP rules are indicated by a PFCP session establishment request message. The method may further include: performing header inspection on user data traffic of UE 200 to obtain the identifier of one of the one or more second proxy network nodes; and performing a traffic management action assigned by the one or more UP rules to the obtained identifier.

[0102] As described above, user data traffic between UE 200 and server 400 can be encrypted (e.g., QUIC-) such that the payload of the user data traffic is hidden at least from the first proxy network node 340, and optionally from each of the plurality of proxy network nodes 310-390. The first PNN and / or the second PNN can be configured as a MASQUEPNN. In one example, the first PNN 340 is configured to implement UP functionality. In one example, the first proxy network node is configured as a UPF, PGW-U, or TDF-U of the Core Network (CN).

[0103] Figure 4 A method executed by a core network node 600 is illustrated. For this purpose, the core network node 600 may include at least one processor 610 and at least one memory 620, the at least one memory 610 storing instructions that, when executed by the at least one processor 620, cause the at least one processor 620 to execute the method. This method can be used with... Figure 2 and / or Figure 3 The methods are executed in parallel.

[0104] The method includes: at 4002, providing UE 200 with at least one routing rule that associates one or more proxy network nodes 310-390 among a plurality of proxy network nodes with at least one user data traffic parameter, for configuring UE 200 to select at least one proxy network node among the plurality of proxy network nodes 310-390 based on the provided routing rule, for routing user data traffic between UE 200 and server 400 through the selected at least one proxy network node (e.g., 340).

[0105] like Figure 2 and Figure 3 Methods and such Figure 1 As in the example, multiple proxy network nodes can be configured to form multiple chains, through which user data traffic can be routed. Each chain includes a first PNN 310-350 and a second PNN 360-390 from among the multiple proxy network nodes to be selected by the UE 200. Similarly, the first PNN can be an ingress PNN (e.g., MASQUE and / or QUIC-), and the second PNN can be an egress PNN (e.g., MASQUE and / or QUIC-), or vice versa.

[0106] The method may include receiving address information (e.g., IP address) of at least one second PNN (e.g., from network node 700 or an application provider). The method may further include determining a binding between the address information of at least one second proxy network node and at least one user data traffic parameter, and optionally, storing the binding. In one example, the binding is determined by a NEF or SCEF (e.g., implemented by core network node 600). The binding may be stored in a UDR or SPR (e.g., implemented by core network node 600). The method may further include determining at least one routing rule based on the binding. In one example, at least one routing rule is determined by a PCF implemented by core network node 600.

[0107] The method may further include receiving a session establishment message from a first PNN (e.g., PNN 340) among a plurality of PNNs, the session establishment message including an identifier of a first proxy network node. The method may include indicating the identifier of the first PNN to the UE 200 for configuring the UE 200 to direct user data traffic to the first PNN.

[0108] The method may further include receiving a PDU session establishment request message from the UE 200, wherein, in response to the PDU session establishment request message, an identifier of a first PNN is indicated to the UE.

[0109] The method may further include determining one or more PCC rules for at least one user data traffic parameter. In one example, the one or more PCC rules are determined by a PCF implemented by the core network node 600. The method may further include determining one or more UP rules based on the one or more PCC rules and optionally further based on binding, the one or more UP rules assigning identifiers of one or more second PNNs 350-390 from a plurality of proxy network nodes to one or more traffic management actions to be performed by the first PNN. In one example, the one or more UP rules are determined by an SMF, PGW-C, or TDF-C implemented by the core network node. The method may further include providing one or more UP rules to the first PNN (e.g., 340).

[0110] As described above, user data traffic between UE 200 and server 400 can be encrypted (e.g., QUIC-), making the payload of the user data traffic hidden from at least the first PNN 340. Similarly, according to... Figure 4In this method, the first PNN (e.g., 340) can be configured to implement the UP function. In one example, the first proxy network node is configured as a UPF, PGW-U, or TDF-U of the core network (CN). Similarly, at least one user data traffic parameter can be TC and / or associated with the application that causes the user data traffic, such as being associated with the application's identifier or type.

[0111] Now refer to Figures 5 to 10 Further details about the technology will be explained. Figure 5A network architecture according to this disclosure is shown. This architecture corresponds to a fifth-generation (5G) network architecture. Among other network functions, this network architecture specifically provides UDR 1010, NEF 1020, Network Data Analytics Function (NWDAF) 1030, Application Function (AF) 1040, PCF 1050, Charging Function (CHF) 1060, Access and Mobility Management Function (AMF) 1070, SMF 1080, and UPF 1090. AF 1040 interacts with 3GPP CN and allows external parties to use open application programming interfaces (APIs) provided by network operators (e.g., MNOs). NEF 1020 supports different open APIs. The 5G system architecture allows PCF 1050 and NEF 1020 to store data in UDR 1010, such as subscription policy data used by PCF 1050. The AMF 1070 can support various functions, such as termination of Non-Access-Stratum (NAS) signaling, NAS encryption and integrity protection, registration management, connection management, mobility management, access authentication and authorization, and security context management. The AMF 1070 can be used to communicate information from and / or to the UE 200 via NAS signaling, including policies provided by the PCF 1050. The PCF 1050 typically supports a unified policy framework to manage network behavior. The PCF 1050 can provide (e.g., UE) policies and PCC rules to the SMF 1080. The SMF 1080 can receive PCC rules from the PCF 1050 and configure the UPF 1090 accordingly. The UPF 1090 typically supports processing user plane traffic based on rules received from the SMF 1080, such as packet detection and various enforcement actions, such as sponsored data or QoS processing. One or more network functions (e.g., NEF 10250, AMF 1070, PCF 1050 (e.g., including PCF-AM 1052 and PCF-SM1054), and optionally UPF 1090) may be implemented by the core network node 600. In other words, the core network node 600 may be configured as one or more network functions.

[0112] Figures 6 to 10 An exemplary sequence of method steps according to this disclosure is shown. This disclosure is not limited to the above references. Figures 2 to 4The methods discussed. Rather, this disclosure should be understood as also providing methods that include one or more of the steps described below (e.g., without). Figures 2 to 4 (The steps of the method). For example, a method may be provided that includes or consists of the following for... Figures 6 to 10 The method consisting of one or more of the steps described: 2, 9, 11, 13, 22, 24, 26 and / or 28.

[0113] Scene 1

[0114] Figures 6 to 10 For the first scenario, the MNO typically enforces traffic management policy rules. To this end, the MNO can provide an ingress proxy (e.g., in the form of a UPF) and enforce traffic management policy rules based on the traffic destination (e.g., an egress proxy). In the first scenario, it may be beneficial if a Service Level Agreement (SLA) exists between the parties involved in the dual-proxy deployment, such as between the UE vendor, the MNO providing the ingress proxy in the dual-proxy deployment, and a third party providing the egress proxy in the dual-proxy deployment (e.g., a Content Delivery Network (CDN) provider).

[0115] Openness of agent-related information

[0116] refer to Figure 6 At point 1, a third party (e.g., a CDN provider) that provides exit proxies 360-390 for the dual-proxy deployment provides exit proxy address information to the MNO. In other words, core network node 600 can receive address information from either the MNO or network node 700. In this context, the Nnef_DualProxy API can be defined. AF 1040 can send a request message (e.g., an Nnef_DualProxy_Provision request) to NEF 1020. This message includes exit proxy address information, which may include the fully qualified domain name (FQDN) and / or IP address of exit proxies 360-390. The message may further include an exit proxy provider ID, which identifies the provider of the exit proxies in this dual-proxy deployment.

[0117] Optionally (for example, in the second scenario mentioned below), the message may include export agent type information. The export agent type information identifies the policy that export agents 360-390 are pre-configured to enforce. Allowed export agents and corresponding policies may be part of an SLA. This parameter is optional and may only be needed if enforcement is delegated to an export agent (as in the second scenario).

[0118] At point 2, the NEF 1020 binds the egress proxy address to the application and / or TC (e.g., egress proxy address #1 to App-ID=example.com). In other words, (e.g., implemented by core network node 600) the NEF 1020 determines the binding (e.g., as above for...). Figure 4 (As stated above). In this way, the MNO provided for NEF 1020 can influence the choice of export agent depending on the application, application category, and / or TC.

[0119] Traffic categories (TCs) can be defined in 3GPP technical reports or standards. For example, traffic categories may include one or more categories mentioned in 3GPP Technical Report 23.700-85, "Study on Enhanced 5G UE Policies." Exemplary traffic categories include the following: - IMS traffic categories (e.g., voice, video and short message services (SMS) based on the IP Multimedia Subsystem (IMS), as well as Rich Communications Service (RCS) can be included in this traffic category); - Internet traffic categories; - Internet of Things (IoT) and machine-to-machine traffic; - On-demand downstream streaming; - On-demand streaming media; - Vehicle communication; - Real-time interactive traffic; - Unified communications traffic (e.g., instant messaging, voice-over-IP, and video collaboration can be included in this category); - Background traffic (e.g., including the process of firmware and / or software updates via over-the-air download); - Location-based traffic; and - Critical communications.

[0120] To retrieve relevant application information using NEF 1020, one of two mechanisms can be used: - Static: Local configuration based on NEF 1020. This conforms to... Figure 6 The sequence shown is an example of a sequence.

[0121] - Dynamic: All relevant application information is retrieved from UDR 1010 based on NEF 1020. Subscription data plans are typically stored in UDR 1010. For example, PCF 150 can retrieve this information (e.g., as a subscription policy for application data from UDR 110) to generate PCC rules. In this case, NEF 1020 can retrieve such data for binding.

[0122] In one implementation, the process considers the full MNO provision. The NEF 1020 can bind an egress proxy to an application and / or TC that shares traffic management policies across all data plans. This egress proxy may not be associated with other applications and / or TCs that may require different traffic management processing. For example, if the MNO has data plans that include game subscriptions (e.g., with specific billing and / or QoS, such as low latency), the NEF 120 provided by the MNO can bind a specific egress proxy to a specific traffic category (e.g., games). In this way, for a UE 200 PDU session, all game application traffic will pass through this egress proxy, and based on this, the MNO can differentiate (e.g., based on the destination address, i.e., the destination address of the egress proxy instance) and apply specific billing and / or QoS, such as low latency.

[0123] Optionally, at locations 3 to 5, the NEF 1020 stores some or all of the aforementioned information in the UDR 1010 (e.g., in a data structure related to the dual-agent deployment). The UDR 1010 can therefore store the information at location 4 and respond at location 5 to indicate successful storage. At location 6, the NEF 1020 can respond with an AF to indicate successful operation.

[0124] Registration and PDU Session Establishment

[0125] Now for reference Figure 7 . Figures 7 to 9 The sequence diagrams in this document do not include all signaling messages that may be involved in the registration and PDU session establishment process. Instead, the portions relevant to the implementation of the techniques disclosed herein are shown.

[0126] At point 7, UE 200 initiates the registration process by sending a registration request message to AMF 1070. AMF 1070 can be implemented by core network node 600.

[0127] At point 8, the AMF 1070 sends a request message (e.g., an Npcf_AMPolicyControl_Create request) to the PCF-AM 1052. In this way, the AMF 1070 can create AM policy associations.

[0128] At points 9 and 10, PCF-AM 1052 contacts NEF 1020 to retrieve egress proxy address and application and / or traffic category binding information. In other words, PCF-AM 1052 requests at least egress proxy address information and bindings from NEF 1020, as well as optionally bound user data traffic parameters. PCF-AM 1052 can request this information from NEF 1020 by sending a corresponding request message (e.g., an Nnef_DualProxy_Get request).

[0129] At positions 11 and 12, the NEF 1020 searches for the requested information. This information may be stored locally in the NEF 1020, or as... Figure 6 The information is stored in the UDR. The NEF 1020 then returns the requested information, such as the egress proxy address and the bound application and / or traffic category. The requested information can be returned by sending a response message from the NEF 1020 to the PCF-AM that includes the requested information. The response message can be an Nnef_DualProxy_Get response message. Specifically, the NEF 1020 can send the PCF-AM 1052 a list of (egress proxy addresses, App-ID (example.com), and / or TC), and optionally a default egress proxy. Such a default egress proxy can be used for rules with traffic descriptors that do not provide specific binding information.

[0130] At point 13, based on the received information, PCF-AM 1052 determines at least one routing rule. This at least one routing rule associates one or more of a plurality of (e.g., second) PNNs 350-390 with at least one user data traffic parameter. The at least one routing rule in the illustrated example corresponds to at least one URSP rule. Such URSP rules may instruct the UE 200 to route application (e.g., example.com) or TC traffic to which egress agent(s), for the application / traffic category associated with the subscription. One or more URSP rules may include traffic descriptors (e.g., application descriptors and / or connectivity capabilities, which will be used to carry traffic categories). Traffic descriptors may include IP address filtering parameters and / or application identifiers. In the illustrated example, the traffic descriptor corresponds to a URL, specifically “example.com”. One or more URSP rules may include routing descriptors (e.g., egress agent address or ingress agent address). The routing descriptor may correspond to the routing descriptor defined in 3GPP Technical Specification 24.526, extended as follows, where the extended portion is highlighted in parentheses: Route Selection Descriptor Component Type Identifier Bit 8 7 6 5 4 3 2 1 0 0 0 0 0 0 0 1 SSC mode type 0 0 0 0 0 0 1 0 S-NSSAI type 0 0 0 0 0 1 0 0 DNN type 0 0 0 0 1 0 0 0 PDU Session Type 0 0 0 1 0 0 0 0 Preferred Access Type 0 0 0 1 0 0 0 1 Multiple access preference types 0 0 1 0 0 0 0 0 Non-seamless non-3GPP offload indication type 0 1 0 0 0 0 0 0 Location Standard Type 1 0 0 0 0 0 0 0 Time window type 1 0 0 0 0 0 0 1 5G ProSe Layer 3 UE to Network Relay Offload Indication Type 1 0 0 0 0 0 1 0 PDU Session Pair Identifier Type 1 0 0 0 0 0 1 1 RSN type {1 0 0 0 0 1 0 0 Entry Proxy Type} {1 0 0 0 0 1 0 1 Export Agent Type} All other values ​​are reserved. If received, they should be interpreted as unknown.

[0131] For the "Ingress Proxy Type," the route descriptor component value field should be encoded as a sequence of an octet ingress proxy length field and a variable-size proxy value field. The proxy value can be an FQDN or an IP address.

[0132] For the "Exit Agent Type," the route descriptor component value field should be encoded as a sequence of an octet of exit agent length and a variable-size agent value field. The agent value can be an FQDN or an IP address.

[0133] Note 1: For “OS Identifier + OS Application Identifier Type”, the traffic descriptor component value field does not specify the operating system (OS) version number or the application version number.

[0134] Note 2: The PCF does not include both the "Preferred Access Type Type" and "Multiple Access Preference Type" routing descriptor components in a single routing descriptor. If both the "Preferred Access Type Type" and "Multiple Access Preference Type" routing descriptor components exist in a single routing descriptor, the UE ignores the "Preferred Access Type Type" routing descriptor component.

[0135] Note 3: W-AGF acting on behalf of FN-RG should be interpreted as unknown.

[0136] Note 4: The traffic descriptor of a URSP rule cannot contain more than one instance of this traffic component type.

[0137] Note 5: Redundant PDU sessions are not applicable to non-3GPP access. The UE ignores any routing descriptor that includes a "PDU session pair identifier type" routing descriptor component or an "RSN type" routing descriptor component, and also includes a "preferred access type" routing descriptor component or a "multiple access preference type" routing descriptor component set to "non-3GPP access".

[0138] Note 6: The traffic descriptor of a URSP rule should not contain both a "single remote port type" traffic descriptor component and a "remote port range type" traffic descriptor component. If the traffic descriptor of a URSP rule contains both a "single remote port type" traffic descriptor component and a "remote port range type" traffic descriptor component, the receiving entity should ignore the URSP rule.

[0139] Note 7: The traffic descriptor of a URSP rule should not contain both the "Destination MAC Address Type" traffic descriptor component and the "Destination MAC Address Range Type" traffic descriptor component. If the traffic descriptor of a URSP rule contains both the "Destination MAC Address Type" and "Destination MAC Address Range Type" traffic descriptor components, the receiving entity should ignore the URSP rule.

[0140] {Note 8: The traffic descriptor of a URSP rule cannot include both "ingress proxy type" and "exgress proxy type" simultaneously.}

[0141] PCF-AM 1052 can send at least one routing rule to UE 200 via AMF 1070. At 14, based on the determined at least one routing rule (e.g., URSP rule), PCF-AM 1052 provides (e.g., extended) URSP rules to UE 200 by sending a Namf_Communication_N1N2MessageTransfer message to AMF 1070. PCF-AM 1052 can invoke a UE configuration update procedure (e.g., as defined in Section 4.2.4.3 of 3GPP 23.502) to provide (e.g., extended) URSP rules to UE 200 via AMF 1070. The Namf_Communication_N1N2MessageTransfer message in the example shown includes the URSP rule (traffic descriptor = example.com, routing descriptor = egress agent address).

[0142] At point 15, AMF 1070 (e.g., transparently) forwards the message received from PCF-AM 1052 to UE 200. That is, UE 200 obtains at least one routing rule from AMF 1070. This corresponds to step 2002 described above. From the CN's perspective, this corresponds to step 4002 described above.

[0143] At position 16, UE 200 stores at least one routing rule (e.g., URSP rule).

[0144] At point 17, the PCF-AM 1052 sends an Npcf_AMPolicyControl_Create response to the AMF.

[0145] At point 18, AMF 1070 sends a registration acceptance message to UE 200.

[0146] PDU Session Establishment

[0147] refer to Figure 8 At point 19, UE 200 triggers PDU session establishment by sending a corresponding request message to core network node 600. Specifically, UE 200 sends a PDU session establishment request to AMF 1070.

[0148] At position 20, AMF 1070 sends a request message to SMF 1080, requesting the creation of a PDU session. Specifically, AMF 1070 sends an Nsmf PDU session creation request to SMF 1080.

[0149] At point 21, SMF 1080 triggers PCF-SM 1054 to determine one or more PCC rules. At point 21, SMF 1080 may send an Npcf_SMPolicyControl_Create request message to PCF-SM 1054.

[0150] At point 22, PCF-SM 1054 defines one or more PCC rules. These PCC rules may be associated with at least one user data traffic parameter, such as an application's (e.g., identifier or type). The PCC rules may be determined by PCF-SM 1054 based on local configuration and / or subscription. The PCC rules may be determined for an App-ID (e.g., "example.com") and / or traffic category. At least one of the PCC rules may be a dynamic PCC rule. At least one of the PCC rules (e.g., a dynamic PCC rule) may be associated with a traffic descriptor and at least one traffic management action associated with the corresponding traffic descriptor.

[0151] At position 23, PCF-SM 1054 indicates to SMF 1080 one or more PCC rules determined at position 22. To do this, PCF-SM 1054 may send an Npcf_SMPolicyControl_Create response message to SMF 1080. PCF-SM 1054 may provide SMF 1080 with a list of one or more PCC rules.

[0152] For dynamic PCC rules, each PCC rule determined and / or provided by PCF-SM 1054 may include: - Traffic descriptors, such as those including application identifiers (e.g., "App-ID = example.com"); and - Traffic management actions (e.g., zero-rate or QoS) for user data traffic that match the traffic descriptor.

[0153] For static PCC rules, the PCF-SM 1054 can indicate the PCC rule identifier to the SMF 1080. In this case, the identified PCC rule can be configured by the SMF 1080.

[0154] At positions 24 and 25, SMF 1080 contacts NEF 1020 to retrieve (e.g., at...). Figure 6The binding is determined at point 2. SMF 1080 can contact NEF 1020 to retrieve information about the binding between the egress proxy address and the application and / or traffic category. To do this, SMF 1080 can send a corresponding request message to NEF 1020 (e.g., an Nnef_DualProxy_Get request message). At point 25, SMF 1080 can indicate one or more application identifiers and / or traffic categories (e.g., associated with the PDU session to be established) to NEF 1020. Specifically, the request message sent from SMF 1080 to PCF-SM 1054 may include a list of App-IDs (e.g., “example.com”) and / or TCs. This allows requests to specify which particular App-ID (example.com) and / or TC are interested in for this particular PDU session.

[0155] At points 26 and 27, the NEF 1020 provides a binding to the SMF 1080. This binding may be stored locally in the NEF 1020 or in the UDR as described above. The NEF 1020 may indicate to the SMF 1080 only the portion of the binding associated with the application identifier and / or TC indicated by the SMF 1080 to the NEF 1020 at point 25. The NEF 1020 may return the binding information between the egress proxy address and the application and / or traffic category by sending a corresponding response message (e.g., an Nnef_DualProxy_Get response message) to the SMF 1080. The response message may include a list of egress proxy addresses, App-IDs (example.com), and / or TCs, and optionally a default egress proxy. The default egress proxy may be used for applications and / or traffic categories for which no specific binding has been provided.

[0156] At position 28, the SMF 1080 maps PCC rules to the PDR of the egress agent. In other words, the SMF 1080 determines one or more UP rules (PDR, FAR, etc.). One or more UP rules can assign the identifiers of one or more second (e.g., egress) agent network nodes 360-390 from multiple agent network nodes 310-390 to one or more traffic management actions to be performed by the first (e.g., ingress) agent network node 360 ​​(e.g., configured as UPF 1090). These UP rules are configured to correspond to the PCC rules of the active PDU session. For example, the SMF 1080 can replace the application identifier in the PDR (Packet Descriptor Information) used for traffic filtering, where the IP destination address is set to the bound egress agent IP address. As a default rule, the SMF 1080 can use the default egress agent.

[0157] At point 29, SMF 1080 triggers PFCP session establishment. To this end, SMF 1080 sends a PFCP session establishment request message to UPF 1090. This message may indicate the UP rule determined at point 28. For example, the message sent to UPF 1090 may include one or more PDRs, FARs, QERs, and / or URRs (e.g., determined and / or mapped to PCC rules at point 28). Such PDRs / FARs / QERs / URRs may include: (i) a PDR with a PDI (e.g., uplink or downlink) for detecting traffic via the egress proxy address associated with the application (e.g., “example.com”) in the corresponding PCC rule; and (ii) associated traffic management actions (e.g., associated FARs, QERs, and / or URRs to indicate the traffic management action requested in the corresponding PCC rule).

[0158] exist Figure 9 In the sequence diagram example shown, it is assumed that the ingress proxy is within UPF 1090. In other words, UPF 1090 acts as the ingress proxy. In this case, ingress proxy network node 340 can be configured as UPF 1090. In this example, as part of the PFCP session creation in UPF 1090, UPF 1090 assigns the address of the ingress proxy, and UPF 1090 responds to SMF 1080 at point 30, indicating a successful operation. Specifically, at point 30, UPF 1090 (e.g., at network node 340) indicates the identifier and / or address of ingress proxy network node 340 to SMF 1080 (e.g., at core network node 600) (e.g., in the response message, particularly the PFCP session establishment response message). This corresponds to step 3002 described above.

[0159] After step 30, both the ingress agent (e.g., UPF 1090) and SMF 1080 know the identifier and / or address of the ingress agent for the PDU session. The UE 200 can then be notified accordingly, for example, via the core network. To this end, at step 31, SMF 1080 indicates the ingress agent's identifier and / or address to AMF 1070 (e.g., by indicating the same in a response message, such as an Nsfm PDU session creation response message, for example, by appropriately expanding the ePCO field of that message). At step 32, AMF 1070 indicates the ingress agent's identifier and / or address to UE 200 (e.g., by indicating the same in a response message, such as a PDU session establishment response message, for example, by appropriately expanding the ePCO field of that message). At step 33, the UE stores the obtained ingress agent's identifier and / or address.

[0160] UE 200 can then use the ingress agent's identifier and / or address, along with at least one routing rule (e.g., the URSP rule stored at location 16), to route application data traffic to a specific agent, as will now be referenced. Figure 10 As illustrated in the example explanation.

[0161] Traffic processing

[0162] refer to Figure 10 At point 34, a user opens an application (e.g., “example.com”) on UE 200. UE 200 can then enable “User Privacy Mode” using a dual-agent deployment. To do this, UE 200 executes at least one routing rule (e.g., a stored URSP rule). UE 200 can then route (e.g., forward) the application traffic (also known as user data traffic) to a selected ingress and / or egress agent. This selection may correspond to step 2004 described above. UE 200 may route the traffic to another ingress / egress agent based on the agent's identifier (e.g., indicated by the ePCO). In a general example, the application executed by UE 200 may provide traffic categories to the operating system (OS) of UE 200, and the OS may route the application traffic (also known as user data traffic) into a PDU session based on the URSP provided by the MNO. All traffic in the PDU session receives the same (e.g., QoS) processing over the network.

[0163] At position 35, UE 200 sends a connection request to the ingress agent (e.g., UPF 1090). This message can be an HTTPCONNECT message. The connection request message may indicate the following information: :protocol=connect-udp :scheme=https :path= / egressproxyinstance.com / 443 / streamId=0 At position 36, the ingress agent (UPF 1090 in the example shown) detects traffic passing through ingress and / or egress agents. The egress agent's (e.g., identifier and / or address) can be derived by the ingress agent from the header of the user data traffic (e.g., the :path header). The ingress agent can apply one or more appropriate traffic management actions (e.g., zero-rate or QoS) based on the traffic and / or the derived egress agent information. One or more traffic management actions can be associated with or instructed by the UP rule previously obtained at position 29.

[0164] At position 37, UPF 1090 responds to UE 200 with a response message to indicate successful operation. The response message can be an HTTP response (e.g., :status=200).

[0165] At point 38, via an ingress proxy connection (e.g., a tunnel), UE 200 sends a connection request message to an egress proxy (e.g., an HTTPCONNECT request). The connection request message may include the following information: :protocol=connect-udp :scheme=https :path= / example.com / 443 / :authority=egressproxyinstance.com streamId=0. Figure 10 The sequence diagram shown is only one example. This technique can be used with other HTTP methods, such as connect-ip or regular HTTP connect.

[0166] At point 39, the ingress proxy (e.g., UPF 1090) forwards the connection request message to the egress proxy. The destination domain (e.g., "example.com") is not visible to the ingress proxy, thus ensuring respect for user privacy.

[0167] At point 40, the export agent (e.g., 370) responds indicating successful operation.

[0168] At position 41, UE 200 sends an HTTP / 3 datagram to the application server (e.g., 400). End-to-end data can be relayed via the ingress proxy to the egress proxy and then to the target server 400. The MNO may not be aware of the target application; conversely, the egress proxy provider and the target server may not know the subscriber's address, thus ensuring respect for user privacy.

[0169] At position 42, the ingress agent (e.g., UPF 1090) detects traffic routed (e.g., via tunnels) through ingress and egress agents (e.g., 340, 370) and applies appropriate traffic management actions (e.g., zero rate and / or QoS).

[0170] Variations of the first scenario

[0171] In a variant of the first scenario, the ingress agent (e.g., 340) is not integrated into the UPF 1090, but rather deployed behind it. For example, the ingress agent is provided in the N6-LAN and / or not bound to a PDU session. For example, the ingress agent is not provided by the MNO (e.g., in a private trunk deployment where the ingress agent is hosted by a third party). In this variant of the first scenario, the UPF 1090 (e.g., provided by the MNO) can enforce traffic management policy rules based on the traffic destination (e.g., the ingress agent's identifier and / or address).

[0172] In this variant, refer to Figures 6 to 10 The described solution can be modified as follows: At least one routing rule (e.g., URSP) allows the selection of an ingress proxy instead of an egress proxy. If a third party provides the ingress proxy, this can be applied. Figure 6 The sequence is the same, but "exit agent" needs to be replaced with "entry agent". If the MNO provides an entry agent, then... Figure 6 The sequence may still be applicable, or this information may be configured by the operator via OAM. In any case, the NEF 1020 and / or UDR in this variant of the first scenario may store bindings (e.g., binding of the ingress agent address to the application and / or traffic category).

[0173] In a variant of the first scenario, the PCF-AM 1052 can retrieve bindings related to the ingress agent (but not the egress agent) at positions 9 to 12. Using the retrieved information, the PCF-AM 1052 can add agent type information to at least one routing rule (e.g., URSP) and send them to the UE 200 at positions 14 to 15. In this case, the agent type information can indicate the ingress agent.

[0174] In a variant of the first scenario, the SMF 1080 can retrieve the binding corresponding to the ingress proxy (but not the egress proxy) in this case at positions 24 to 27. At position 28, the SMF 1080 can do so in a similar manner by including the corresponding ingress proxy address from the PCC rule and / or traffic category as the destination IP address in the PDR Packet Detection Information (PDI). At positions 30 to 33, the ingress proxy address may not be provided by the UPF 1090 to the SMF 1080 or the UE 200 (e.g., not even in the ePCO).

[0175] Second Scene

[0176] In the second scenario, the MNO can delegate policy rule enforcement to a third party. In this scenario, the MNO may or may not provide an ingress proxy. Traffic management actions can be performed at an egress proxy owned by a third party (e.g., an egress proxy not part of the MNO network). This can be advantageous if the egress proxy address is insufficient to perform traffic management actions (e.g., parental controls may require the actual traffic destination to be available and assessable). Traffic may need to be routed to an egress proxy configured with applicable traffic management actions.

[0177] For example, a third-party egress proxy can be responsible for parental controls. At least one egress proxy (e.g., 370) can be configured to gate traffic according to predefined filtering rules (e.g., adult content: allowed or not allowed; violence: allowed or not allowed). User data traffic can be sent to an egress proxy with a configuration that matches the subscription settings for parental controls.

[0178] The details of the first scenario described above are applicable, but some changes are required (e.g., UPF 1090 does not need to be configured with rules to perform delegated actions).

[0179] The disclosure of information related to agents is applicable to... Figure 6 The same sequence applies. In this context, the exit agent type can be associated with the action the exit agent is configured to perform. The result of this sequence is NEF 1020 and / or UDR storage bindings (e.g., bindings of application and / or traffic categories to exit agents), but an application and / or traffic category can be bound to more than one exit agent (e.g., each exit agent is associated with an exit agent type). The exit agent type can also be stored as part of a binding.

[0180] In the second scenario, at positions 9 through 12, PCF-AF can retrieve bindings (e.g., associated with an exit agent). If multiple exit agent options exist, PCF-AF can determine which one to include in at least one routing rule (e.g., URSP), based on subscription information (e.g., parental control permissions in the subscription).

[0181] In the second scenario, at points 21 to 23, the SMF 1080 may not receive PCC rule instructions for actions that have been delegated to an export agent.

[0182] If the MNO provides an ingress proxy (e.g., 340), such as if the UPF 1090 integrates an ingress proxy, then sequences 30 through 33 may be applied to provide an ingress proxy address to the UE 200. If the ingress proxy is provided by the MNO but not implemented as the UPF 1090, the SMF 1080 may indicate an ingress proxy identifier and / or address to the UE 200 (e.g., in the ePCO), for example, based on a local (e.g., predefined) configuration of the SMF 1080.

[0183] In a single-agent deployment, some actions can be delegated to the egress agent while others are not. For example, billing may not be delegated to the egress agent (e.g., it may be performed by the ingress agent), while parental controls may be delegated to the egress agent. The mechanisms described above can be combined to achieve such results.

[0184] The technologies disclosed in this article are applicable not only to 5G network architectures but also to other network architectures, such as 4G. In the context of 4G network architectures, the terminology used in this article can be replaced as follows: - Replace NEF with SCEF; - Replace PCF with PCRF; - Replace UDR with SPR; - Replace AMF with MME; - Replace SMF with PGW-C or TDF-C; - Replace UPF with PGW-U or TDF-U.

[0185] In summary, network operators may need to apply and / or service awareness to perform differentiated traffic management actions (such as billing, QoS, etc.) based on operator policies and subscription terms. In current solutions, it may be impossible to apply differentiated traffic management actions in a dual-proxy deployment, especially if they protect user privacy to the point that no single entity can simultaneously identify the user (and therefore subscribe) and the websites accessed. The egress proxy may have been deployed by a third party and may be under the complete control of a third party with an SLA signed with the MNO.

[0186] One aspect of this technology is based on an extension of URSP rules, which allows the MNO to influence the UE 200 to select specific (e.g., ingress and / or egress) proxies to route application traffic based on subscriptions, depending on, for example, the application and / or application category.

[0187] By influencing the selection of ingress / egress proxies for specific traffic, traffic management can be implemented through one of the following, based on the applicable traffic management policies for subscriptions and applications or application categories: - Scenario 1: The mobile network executes traffic management policy rules based on traffic destination (e.g., ingress and / or egress proxies); - Second scenario: The selected ingress / egress proxy is pre-configured with applicable traffic management policy rules, and the MNO delegates policy enforcement to the proxy.

[0188] Both scenarios allow MNOs to apply differentiated traffic management actions in dual-proxy deployments. User privacy is protected while carrier policies and subscription terms can be enforced.

[0189] If this document refers to a message, data, or parameter as "including" some information, this information is explicitly indicated in the first variant and implicitly (e.g., indirectly) indicated in the second variant. Regarding references to the flow of traffic between the first and second entities, in the first variant, it consists of a unidirectional flow from the first entity (e.g., UE 200) to the second entity (e.g., server 400); in the second variant, it consists of a unidirectional flow from the second entity to the first entity; and in the third variant, it consists of a bidirectional flow from the first entity to the second entity and from the second entity to the first entity. Various modifications to the techniques disclosed herein are possible. For example, refer to... Figures 6 to 10 Some of the methods and steps discussed may be omitted, substituted, or combined. In view of this disclosure, further advantages and modifications may become apparent to those skilled in the art.

[0190] Abbreviations

[0191] Application Function (AF)

[0192] AMF (Access and Mobility Function)

[0193] API (Application Programming Interface)

[0194] AS Application Server

[0195] CHLO Client Hello

[0196] CP (Control Plane)

[0197] CUPS Control Plane User Plane Separation

[0198] DL Downlink

[0199] DNS (Domain Name System)

[0200] DoH (DoH) is DNS over HTTPS.

[0201] DoT DNS over TLS

[0202] DPI (Deep Packet Inspection)

[0203] ECH Encrypted Client Hello

[0204] ePCO Extended Protocol Configuration Options

[0205] ESNI is an encrypted SNI.

[0206] FAR Forwarding Action Rule

[0207] FQDN (Fully Qualified Domain Name)

[0208] HTTP (Hypertext Transfer Protocol)

[0209] HTTPS (Hypertext Transfer Security Protocol)

[0210] Internet Explorer Information Element

[0211] MASQUE is a multiplexed application substrate over QUIC encryption.

[0212] MME (Mobility Management Engine)

[0213] MNO (Mobile Network Operator)

[0214] NAS (Non-Access Stratum)

[0215] NEF Network Exposure Function

[0216] OTT (Over the Top)

[0217] PCF Policy Control Function

[0218] PCO Protocol Configuration Options

[0219] PCRF Policy and Charging Rule Function

[0220] PDN (Packet Data Network)

[0221] PDR (Packet Detection Rule)

[0222] PFCP (Packet Flow Control Protocol)

[0223] PFD (Packet Flow Description)

[0224] PGW (Packet Gateway)

[0225] PGW-C Packet Gateway Control Plane

[0226] PGW-U Packet Gateway User Plane

[0227] PUI Public User Identity

[0228] QNAME is the query name.

[0229] QoS (Quality of Service)

[0230] RAN (Radio Access Network)

[0231] SCEF Service Capability Exposure Function

[0232] SDF Service Data Flow

[0233] SMF Session Management Function

[0234] SNI Server Name Indication

[0235] NSSAI Network Slice Selection Assistance Information

[0236] SPR Subscriber Profile Repository

[0237] SUPI Subscription Permanent Identifier

[0238] TC Traffic Category

[0239] TD Traffic Descriptor

[0240] TDF (Traffic Detection Function)

[0241] TDF-C Traffic Detection Function Control Plane

[0242] TDF-U Traffic Detection Function User Plane

[0243] TLS (Transport Layer Security)

[0244] TTL (Time To Live)

[0245] UDR User Data Repository

[0246] UE (User Equipment)

[0247] UL Uplink

[0248] UP User Plane

[0249] UPF User Plane Function

[0250] URR Usage Reporting Rule

[0251] URSP User Equipment Route Selection Policy

Claims

1. A method for enabling controlled flow of user data traffic between a user equipment (UE) (200) and a server (400) via at least one of a plurality of proxy network nodes (310-390) reachable by the UE via a radio access network (RAN) (500), the method being performed by the UE (200) and comprising: At least one routing rule is obtained from the core network node (600), the at least one routing rule associating one or more of the plurality of proxy network nodes (310-390) with at least one user data traffic parameter; as well as Based on at least one obtained routing rule, at least one proxy network node among the plurality of proxy network nodes (310-390) is selected for routing the user data traffic between the UE (200) and the server (400) through the selected at least one proxy network node.

2. The method according to claim 1, wherein, The selected at least one proxy network node is part of a chain of proxy network nodes through which the user data traffic is routed, the chain including a first proxy network node and a second proxy network node among the plurality of proxy network nodes.

3. The method according to claim 2, wherein, The selected at least one proxy network node is either the first proxy network node or the second proxy network node.

4. The method according to claim 2 or 3, wherein, The first proxy network node is an ingress proxy network node and the second proxy network node is an egress proxy network node, or wherein... The first proxy network node is an exit proxy network node and the second proxy network node is an ingress proxy network node.

5. The method according to any one of claims 2 to 4, wherein, The first proxy network node is configured to implement the user plane UP function.

6. The method according to claim 5, wherein, The first proxy network node is configured as a user plane function UPF of the core network CN, a packet gateway user plane PGW-U, or a traffic detection function user plane TDF-U.

7. The method according to any one of claims 2 to 6, further comprising: Obtain the identifier of the first proxy network node from the core network node; as well as Based on the acquired identifier, user data traffic is directed to the first proxy network node.

8. The method according to claim 7, wherein, The at least one routing rule associates one or more second proxy network nodes with at least one user data traffic parameter.

9. The method according to claim 7 or 8, further comprising: Send a Packet Data Unit (PDU) session establishment request message to the core network node, wherein the identifier of the first proxy network node is obtained in response to the PDU session establishment request message.

10. The method according to any one of claims 1 to 9, further comprising: Direct user data traffic to the selected at least one proxy network node.

11. The method according to any one of claims 1 to 10, wherein, The one or more routing rules include at least one User Equipment Routing Policy (URSP).

12. The method according to any one of claims 1 to 11, wherein, The user data traffic between the UE and the server is encrypted such that the payload of the user data traffic is hidden from at least one selected proxy network node, and optionally hidden from each of the plurality of proxy network nodes.

13. The method according to any one of claims 1 to 12, wherein, The user data traffic between the UE and the server is QUIC encrypted.

14. The method according to any one of claims 1 to 13, wherein, At least one of the selected proxy network nodes includes a MASQUE proxy network node, which is the underlying layer of multiplexed applications based on QUIC encryption.

15. The method according to any one of claims 1 to 14, wherein, The at least one user data traffic parameter is a traffic category (TC) and / or is associated with the application that caused the user data traffic, such as being associated with the application's identifier or type.

16. A user equipment (UE) (200) configured to enable controlled flow of user data traffic between the UE (200) and a server (400) via at least one of a plurality of proxy network nodes (310-390) reachable by the UE (200) via a radio access network (RAN) (500), the UE (200) including at least one memory (220) and at least one processor (210), the at least one memory (220) storing instructions that, when executed by the at least one processor (210), cause the at least one processor (210) to: At least one routing rule is obtained from the core network node (600), the at least one routing rule associating one or more of the plurality of proxy network nodes (310-390) with at least one user data traffic parameter; and Based on at least one obtained routing rule, at least one proxy network node among the plurality of proxy network nodes (310-390) is selected for routing the user data traffic between the UE (200) and the server (400) through the selected at least one proxy network node.

17. The UE according to claim 16, wherein, The at least one memory stores instructions that, when executed by the at least one processor, cause the at least one processor to perform the method according to any one of claims 1 to 15.

18. A computer program that stores instructions that, when executed by the at least one processor, cause the at least one processor to perform the method according to any one of claims 1 to 15.

19. A carrier carrying a computer program according to claim 18.

20. A method for enabling controlled flow of user data traffic between a user equipment (UE) (200) and a server (400) via at least one of a plurality of proxy network nodes (310-390) reachable by the UE (200) via a radio access network (RAN) (500), the method being performed by a first proxy network node (340) of the plurality of proxy network nodes (310-390) and comprising: A session establishment message is sent to the core network node (600), the session establishment message including the identifier of the first proxy network node (340), the identifier being indicated to the UE (200) via the core network node (600) for configuring the UE (200) to direct user data traffic to the first proxy network node (340) based on the acquired identifier.

21. The method according to claim 20, wherein, The session establishment message is a Packet Flow Control Protocol (PFCP) session establishment response message.

22. The method according to claim 20 or 21, wherein, The plurality of proxy network nodes are configured to form a plurality of chains, through which user data traffic can be routed, each chain including the first proxy network node and a second proxy network node among the plurality of proxy network nodes.

23. The method according to claim 22, wherein, The first proxy network node is an ingress proxy network node and the second proxy network node is an egress proxy network node, or wherein... The first proxy network node is an exit proxy network node and the second proxy network node is an ingress proxy network node.

24. The method according to any one of claims 20 to 23, further comprising: One or more user plane UP rules are obtained from the core network node, and the one or more user plane UP rules assign the identifier of one or more second proxy network nodes from the plurality of proxy network nodes to one or more traffic management actions to be performed by the first proxy network node.

25. The method according to claim 24, wherein, The one or more UP rules are indicated by a Packet Flow Control Protocol (PFCP) Session Establishment Request message.

26. The method according to claim 24 or 25, further comprising: Header detection is performed on the user data traffic of the UE to obtain the identifier of one of the one or more second proxy network nodes; as well as Perform traffic management actions assigned to the acquired identifier by the one or more UP rules.

27. The method according to any one of claims 20 to 26, wherein, The user data traffic between the UE and the server is encrypted, such that the payload of the user data traffic is hidden from at least the first proxy network node, and optionally from each of the plurality of proxy network nodes.

28. The method according to any one of claims 20 to 27, wherein, The user data traffic between the UE and the server is QUIC encrypted.

29. The method according to any one of claims 20 to 28, wherein, The first proxy network node is a MASQUE proxy network node based on QUIC-encrypted multiplexing application underlying layer.

30. The method according to any one of claims 20 to 29, wherein, The first proxy network node is configured to implement the user plane UP function.

31. The method according to claim 30, wherein, The first proxy network node is configured as a user plane function UPF of the core network CN, a packet gateway user plane PGW-U, or a traffic detection function user plane TDF-U.

32. A first proxy network node (340) configured to enable controlled flow of user data traffic between a user equipment (UE) (200) and a server (400) via at least one of a plurality of proxy network nodes (310-390) reachable by the UE (200) via a radio access network (RAN) (500), the first proxy network node (340) comprising at least one memory (344) and at least one processor (342), the at least one memory (344) storing instructions that, when executed by the at least one processor (342), cause the at least one processor (342) to: A session establishment message is sent to the core network node (600), the session establishment message including the identifier of the first proxy network node (340), the identifier being indicated to the UE (200) via the core network node (600) for configuring the UE (200) to direct user data traffic to the first proxy network node (340) based on the acquired identifier.

33. The first proxy network node according to claim 32, wherein, The at least one memory stores instructions that, when executed by the at least one processor, cause the at least one processor to perform the method according to any one of claims 20 to 31.

34. A computer program that stores instructions, which, when executed by the at least one processor, cause the at least one processor to perform the method according to any one of claims 20 to 31.

35. A carrier carrying the computer program according to claim 34.

36. A method for enabling controlled flow of user data traffic between a user equipment (UE) (200) and a server (400) via at least one of a plurality of proxy network nodes (310-390) reachable by the UE (200) via a radio access network (RAN) (500), the method being performed by a core network node (600) and comprising: At least one routing rule is provided to the UE (200), the at least one routing rule associating one or more of the plurality of proxy network nodes (310-390) with at least one user data traffic parameter, to configure the UE (200) to select at least one of the plurality of proxy network nodes (310-390) based on the provided routing rule, for routing the user data traffic between the UE (200) and the server (400) through the selected at least one proxy network node.

37. The method of claim 36, wherein, The plurality of proxy network nodes are configured to form a plurality of chains through which user data traffic can be routed, each chain including a first proxy network node and a second proxy network node of the plurality of proxy network nodes to be selected by the UE.

38. The method according to claim 37, wherein, The first proxy network node is an ingress proxy network node and the second proxy network node is an egress proxy network node, or wherein... The first proxy network node is an exit proxy network node and the second proxy network node is an ingress proxy network node.

39. The method according to claim 37 or 38, further comprising: Receive the address information of the at least one second proxy network node. The at least one routing rule is based on the address information.

40. The method of claim 39, further comprising: Determine the binding between the address information of the at least one second proxy network node and at least one user data traffic parameter. The at least one routing rule is based on the binding.

41. The method of claim 40, further comprising: Store the binding.

42. The method according to claim 41, wherein, The binding is determined by the Network Open Function (NEF) or Service Capability Open Function (SCEF) implemented by the core network node, and the binding is stored in the User Data Repository (UDR) or Subscriber Profile Repository (SPR).

43. The method according to any one of claims 40 to 42, further comprising: The at least one routing rule is determined based on the binding.

44. The method according to claim 43, wherein, The at least one routing rule is determined by the Policy Control Function (PCF) implemented by the core network node.

45. The method according to any one of claims 36 to 44, further comprising: Receive a session establishment message from a first proxy network node among the plurality of proxy network nodes, the session establishment message including the identifier of the first proxy network node; as well as The identifier of the first proxy network node is indicated to the UE to configure the UE to direct user data traffic to the first proxy network node.

46. ​​The method of claim 45, further comprising: The UE receives a PDU session establishment request message, wherein, in response to the PDU session establishment request message, the identifier of the first proxy network node is indicated to the UE.

47. The method according to any one of claims 36 to 46, further comprising: For at least one user data traffic parameter, determine one or more policies and billing control (PCC) rules.

48. The method according to claim 47, wherein, The one or more PCC rules are determined by the Policy Control Function (PCF) implemented by the core network node.

49. The method according to any one of claims 37 to 48, further comprising: One or more user plane UP rules are provided to the first proxy network node, wherein the one or more user plane UP rules assign the identifier of one or more second proxy network nodes from the plurality of proxy network nodes to one or more traffic management actions to be performed by the first proxy network node.

50. The method according to claim 49 and any one of claims 47 and 48, further comprising: The one or more UP rules are determined based on the one or more PCC rules.

51. The method according to claim 50 and at least subordinate to claim 40, wherein, The one or more UP rules are determined based on the one or more PCC rules and based on the binding.

52. The method according to claim 50 or 51, wherein, The one or more UP rules are determined by the Session Management Function (SMF), Packet Gateway Control Plane (PGW-C), or Traffic Detection Function Control Plane (TDF-C) implemented by the core network node.

53. The method according to any one of claims 36 to 52, wherein, The user data traffic between the UE and the server is encrypted, so that the payload of the user data traffic is hidden from at least the first proxy network node, and optionally from each of the plurality of proxy network nodes.

54. The method according to any one of claims 36 to 53, wherein, The user data traffic between the UE and the server is encrypted using QUIC.

55. The method according to at least claim 37, wherein, The first proxy network node and / or the second proxy network node are MASQUE proxy network nodes based on QUIC-encrypted multiplexing application underlying layers.

56. The method according to at least claim 37, wherein, The first proxy network node is configured to implement the user plane UP function.

57. The method according to claim 56, wherein, The first proxy network node is configured as a user plane function UPF of the core network CN, a packet gateway user plane PGW-U, or a traffic detection function user plane TDF-U.

58. The method according to any one of claims 36 to 57, wherein, The at least one user data traffic parameter is a traffic category (TC) and / or is associated with the application that caused the user data traffic, such as being associated with the application's identifier or type.

59. A core network node (600) configured to enable controlled flow of user data traffic between a user equipment (UE) (200) and a server (400) via at least one of a plurality of proxy network nodes (310-390) reachable by the UE (200) via a radio access network (RAN) (500), the core network node (600) comprising at least one memory (620) and at least one processor (610), the at least one memory (620) storing instructions that, when executed by the at least one processor (610), cause the at least one processor (610) to: At least one routing rule is provided to the UE (200), the at least one routing rule associating one or more of the plurality of proxy network nodes (310-390) with at least one user data traffic parameter, to configure the UE (200) to select at least one of the plurality of proxy network nodes (310-390) based on the provided routing rule, for routing the user data traffic between the UE (200) and the server (400) through the selected at least one proxy network node.

60. The core network node according to claim 59, wherein, The at least one memory stores instructions that, when executed by the at least one processor, cause the at least one processor to perform the method according to any one of claims 36 to 58.

61. A computer program that stores instructions, which, when executed by the at least one processor, cause the at least one processor to perform the method according to any one of claims 36 to 58.

62. A carrier carrying the computer program according to claim 61.

63. A system (100) comprising at least two of the following entities: UE (200) according to claim 16 or 17; The first proxy network node (340) according to claim 32 or 33; The core network node (600) according to claim 59 or 60.

Images