Technique enabling controlled traffic flow over proxy network nodes

Abstract

Disclosed are methods of enabling a controlled flow of user data traffic between a user equipment, UE, and a server over at least one of a plurality of proxy network nodes reachable by the UE via a Radio Access Network, RAN. The methods are performed by the UE, by a first proxy network node of the plurality of proxy network nodes and by a core network node, respectively. A UE, corresponding nodes, computer programs and a system are also disclosed.

Description

[0001] Technique enabling controlled traffic flow over proxy network nodes

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to methods enabling controlled flow of user data traffic between a user equipment (UE) and a server over at least one of a plurality of proxy network nodes. A UE, a first proxy network node, a core network node, a system, computer programs and carriers are also provided.

[0004] BACKGROUND

[0005] User data traffic may be routed between a UE and a server via a proxy network node reachable by the UE via a Radio Access Network (RAN). Current solutions rely on a predetermined association of the proxy network node to the UE for routing the user data traffic from the UE to the server. In certain scenarios, the predetermined association may lead to the proxy network node via which user data traffic is being routed not having a desired capability in terms of, for example, Quality of Service (QoS).

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

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

[0008] SUMMARY

[0009] There is a need for a technique enabling a controlled flow of user data traffic between a UE and a server over at least one of a plurality of proxy network nodes reachable by the UE via a RAN. The technique may solve one or more of the above or other problems. According to a first aspect, a method of enabling a controlled flow of user data traffic between a UE and a server over at least one of a plurality of proxy network nodes reachable by the UE via a RAN is provided. The method is performed by the UE and comprises: obtaining, from a core network node (e.g., of a Core Network connected to and / or associated with the RAN), at least one route 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 route selection rule, at least one of the plurality of proxy network nodes for routing the user data traffic between the UE and the server over the selected at least one proxy network node.

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

[0011] In an 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.

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

[0013] In an 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.

[0014] In an example, the first proxy network node is configured to implement a user plane (UP) function.

[0015] In an example, the first proxy network node is configured as a User Plane Function (UPF), a Packet Gateway User Plane (PGW-U) or a Traffic Detection Function User Plane (TDF- U) of a Core Network (CN). The method may further comprise: obtaining, from the core network node, an identifier of the first proxy network node; and directing user data traffic toward the first proxy network node based on the obtained identifier.

[0016] In an example, the at least one route selection rule associates one or more second proxy network nodes with at least one user data traffic parameter.

[0017] The method may further comprise: 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.

[0018] The method may further comprise: directing user data traffic toward the selected at least one proxy network node.

[0019] In an example, the one or more route selection rules comprise at least one UE Route Selection Policy (URSP).

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

[0021] In an example, the user data traffic between the UE and the server is QUIC- encrypted.

[0022] In an example, the selected at least one proxy network node comprises a Multiplexed Application Substrate over QUIC Encryption (MASQUE) proxy network node.

[0023] In an example, the at least one user data traffic parameter is a traffic category (TC) and / or is associated with an application causing the user data traffic, for example with an identity or type of the application.

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

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

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

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

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

[0029] According to a fifth aspect, a method of enabling a controlled flow of user data traffic between a UE and a server over at least one of a plurality of proxy network nodes reachable by the UE via a RAN is provided. The method is performed by a first proxy network node of the plurality of proxy network nodes and comprises: sending a session establishment message to a core network node (e.g., of a Core Network connected to and / or associated with the RAN), the session establishment message including an identifier of the first proxy network node to be indicated to the UE via the core network node for configuring the UE to direct user data traffic toward the first proxy network node based on the obtained identifier.

[0030] In an example, the session establishment message is a Packet Flow Control Protocol (PFCP) Session Establishment Response message.

[0031] In an example, the plurality of proxy network nodes are configured to form a plurality of chains via which the user data traffic can be routed, each chain comprising the first proxy network node and a second proxy network node of the plurality of proxy network nodes. In an 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.

[0032] The method may further comprise: obtaining, from the core network node, one or more User Plane, UP, rules assigning identifiers of one or more second proxy network nodes of the plurality of proxy network nodes to one or more traffic management actions to be performed by the first proxy network node.

[0033] In an example, the one or more UP Rules are indicated by a PFCP Session Establishment Request message.

[0034] The method may further comprise: performing a header inspection of user data traffic of the UE to obtain an identifier of one of the one or more second proxy network nodes; and performing the traffic management action(s) assigned to the obtained identifier by the one or more UP Rules.

[0035] In an example, the user data traffic between the UE and the server is encrypted such that a payload of the user data traffic is hidden at least for the first proxy network node, optionally for each of the plurality of proxy network nodes.

[0036] In an example, the user data traffic between the UE and the server is QUIC- encrypted.

[0037] In an example, the first proxy network node is a MASQUE proxy network node.

[0038] In an example, the first proxy network node is configured to implement a UP function.

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

[0040] According to a sixth aspect, a first proxy network node configured to enable a controlled flow of user data traffic between a UE and a server over at least one of a plurality of proxy network nodes reachable by the UE via a RAN is provided. The first proxy network node comprises at least one memory and at least one processor, the at least one memory storing instructions which, 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., of a Core Network connected to and / or associated with the RAN), the session establishment message including an identifier of the first proxy network node to be indicated to the LIE via the core network node for configuring the LIE to direct user data traffic toward the first proxy network node based on the obtained identifier.

[0041] In an example, the at least one memory stores instructions which, when executed by the at least one processor, cause the at least one processor to perform the method according to the fifth aspect.

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

[0043] According to an eight aspect, a carrier is provided. The carrier carries the computer program of the seventh aspect.

[0044] According to a ninth aspect, a method of enabling a controlled flow of user data traffic between a UE and a server over at least one of a plurality of proxy network nodes reachable by the UE via a RAN is provided. The method is performed by a core network node (e.g., of a Core Network connected to and / or associated with the RAN) and comprises: providing the UE with at least one route selection rule associating one or more of the plurality of proxy network nodes with at least one user data traffic parameter to configure the UE to select, based on the provided route selection rule(s), at least one of the plurality of proxy network nodes for routing the user data traffic between the UE and the server over the selected at least one proxy network node.

[0045] In an example, the plurality of proxy network nodes are configured to form a plurality of chains via which the user data traffic can be routed, each chain comprising a first proxy network node and a second proxy network node of the plurality of proxy network nodes that is to be selected by the UE.

[0046] In an 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. The method may further comprise: receiving address information of at least one of the second proxy network nodes, wherein the at least one route selection rule is based on the address information.

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

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

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

[0050] The method may further comprise: determining the at least one route selection rule based on the binding.

[0051] In an example, the at least one route selection rule is determined by a Policy Control Function (PCF) implemented by the core network node.

[0052] The method may further comprise: receiving a session establishment message from a first proxy network node of the 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 towards the first proxy network node.

[0053] The method may further comprise: receiving a PDU Session Establishment Request message from the UE, wherein the identifier of the first proxy network node is indicated to the UE in response to the PDU Session Establishment Request message.

[0054] The method may further comprise: determining one or more Policy and Charging Control (PCC) rules for at least one user data traffic parameter.

[0055] In an example, one or more PCC rules are determined by a PCF implemented by the core network node. The method may further comprise: providing the first proxy network node with one or more UP rules assigning identifiers of one or more second proxy network nodes of the plurality of proxy network nodes to one or more traffic management actions to be performed by the first proxy network node.

[0056] The method may further comprise: determining the one or more UP rules based on the one or more PCC rules.

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

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

[0059] In an example, the user data traffic between the UE and the server is encrypted such that a payload of the user data traffic is hidden at least for the first proxy network node, optionally for each of the plurality of proxy network nodes.

[0060] In an example, the user data traffic between the UE and the server is QUIC- encrypted.

[0061] In an example, the first proxy network node and / or the second proxy network node is a MASQUE proxy network node.

[0062] In an example, the first proxy network node is configured to implement a UP function.

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

[0064] In an example, the at least one user data traffic parameter is a TC and / or is associated with an application causing the user data traffic, for example with an identity or type of the application.

[0065] According to a tenth aspect, a core network node configured to enable a controlled flow of user data traffic between a UE and a server over at least one of a plurality of proxy network nodes reachable by the UE via a RAN is provided. The core network node (e.g., of a Core Network connected to and / or associated with the RAN) comprises at least one memory and at least one processor, the at least one memory storing instructions which, when executed by the at least one processor, cause the at least one processor to: provide the UE with at least one route selection rule associating one or more of the plurality of proxy network nodes with at least one user data traffic parameter, to configure the UE to select, based on the provided route selection rule(s), at least one of the plurality of proxy network nodes for routing the user data traffic between the UE and the server over the selected at least one proxy network node.

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

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

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

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

[0070] SHORT DESCRIPTION OF THE FIGURES

[0071] Fig. 1 illustrates a system in accordance with the present disclosure;

[0072] Fig. 2 illustrates a method, performed by a UE, in accordance with the present disclosure;

[0073] Fig. 3 illustrates a method, performed by a proxy network node, in accordance with the present disclosure; Fig. 4 illustrates a method, performed by a core network node, in accordance with the present disclosure;

[0074] Fig. 5 illustrates a network architecture in accordance with the present disclosure; and

[0075] Fig. 6-10 illustrate method steps in accordance with the present disclosure.

[0076] DETAILED DESCRIPTION

[0077] Fig. 1 illustrates a system 100 in accordance with the present disclosure. The system 100 comprises a LIE 200 and a group 300 of proxy network nodes 310-390. User data traffic may be routed between the UE 200 and a plurality of servers 400-420 via a RAN 500 and the group 300. Also shown in Fig. 1 are a core network node 600 of a CN and a network node 700 of a provider of the servers 400-420. When the present disclosure refers to network nodes, it is to be understood that such network nodes may be realized as software entities (e.g., in a distributed computing environment) or as hardware entities.

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

[0079] The proxy network nodes 310-390 in one example are each configured as one of the following proxy types:

[0080] - A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification.

[0081] - A "non-transparent proxy" is a proxy that modifies the request or response to provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction, or anonymity filtering.

[0082] - A "reverse proxy" is a proxy that pretends to be the actual server (as far as any client or client proxy is concerned), but it passes on the request to the actual server that is usually sitting behind another layer of firewalls.

[0083] - A "Performance Enhancement Proxy (PEP)" is used to improve the performance of protocols on network paths where native performance suffers due to characteristics of a link or subnetwork on the path. In the illustrated example, the proxy network nodes (PNNs) 340, 370 form a chain of PNNs. The PNN 340 acts as an ingress PNN and the PNN 370 acts as an egress PNN of the chain of PNNs. This arrangement of two PNNs can be referred to as dual-proxy deployment. A set of PNNs 310-350 may be used as first (e.g., ingress) PNNs of the chain and another set of PNNs 360-390 may be used as second (e.g., egress) PNNs of the chain.

[0084] The established connection between the LIE 200 and the server 400 may be QUIC- encrypted. This may allow users to connect to the server 400 in a more secure and private way.

[0085] QllIC is a User Datagram Protocol (UDP) based stream-multiplexed and secure transport protocol with integrity protected header and encrypted payload. Unlike the traditional transport protocol stack with Transmission Control Protocol (TCP), which resides in the operating system kernel, QUIC can easily be implemented in user space, i.e. in the application layer. As a consequence, this improves flexibility in terms of transport protocol evolution with implementation of new features, congestion control, deploy ability and adoption. QUIC is standardized by the Internet Engineering Taskforce (IETF), for example in standards RFC 8999, RFC 9000, RFC 9001 and RFC 9002. Compared to Hypertext Transfer Protocol Secure (HTTPS), encryption in QUIC covers both the transport protocol headers as well as the payload, as opposed to Transport Layer Security (TLS) over TCP, e.g. HTTPS, which protects only the payload.

[0086] The PNNs 340, 370 may be configured as MASQUE PNNs to allow configuring and concurrently running multiple proxied stream- and datagram-based flows inside an HTTPS connection. Through MASQUE, the UE 200 or an application creates a secure connection to an on-path network proxy (e.g., PNN 340), which enables establishing a secure end-to-end (E2E) connection to the server(s) (e.g., 400) via the proxy. UE and / or application data may thus be secured E2E and protected from unauthorized used in the network. A content provider (e.g., provider of the server(s) 400-420) and a MNO, may each have a secure channel to exchange information about application and policy real-time.

[0087] The UE 200 and / or application client may explicitly open a QUIC tunnel connection to the (e.g., ingress) PNN and request forwarding. The UE 200 and / or application client may use a HTTP CONNECT-like protocol or a custom protocol to request or negotiate forwarding, authentication, and configuration.

[0088] The proxy routing QUIC-encrypted user data traffic (QUIC proxy, e.g. PNN 340) may provide secure forwarding and performance enhancement services, such as (e.g., mobile or satellite) congestion control support. The QUIC proxy may provide one or more of access policy enforcement, load balancing, load mobility, multi-hop chaining, and onion routing. The QUIC proxy may optionally also open a tunnel to the server 400, if this is supported by the server 400.

[0089] In this manner, the UE 200 or application client explicitly contacts a proxy 310-390 (e.g., configured as a QUIC Proxy) in order to expose information between the Content Provider (e.g., an application Client and / or the server 400) and the Mobile Network Operator (e.g., providing the QUIC Proxy). Fig. 1 indicates an inner connection with dashed arrows, which carries encrypted user data traffic between the UE 200 and the server 400, which user data is not visible to the PNNs 340, 370. Fig. 1 also indicates an outer connection that can be used to expose information between the Content Provider (e.g., application client and / or server 400) and the Mobile Network Operator (e.g., provider of the QUIC proxy).

[0090] When browsing, it can be ensured that all traffic leaving the UE 200 is QUIC- encrypted, so no one between the UE 200 and the server 400 can access and read it. All the user's requests may then be sent through two separate internet relays, namely the first PNN 340 and the second PNN 370. The PNN 340 may assign the UE 200 an anonymous Internet Protocol (IP) address that maps to its region but not its actual location. The PNN 370 may decrypt a web address the UE 200 wants to visit and forwards the UE's request 200 to its destination server 400. This separation of information protects the user's privacy because no single entity can identify both the users or UE 200 and which sites or severs 400 they visit. Accordingly, such a solution uses two QUIC / MASQUE proxies acting as relays:

[0091] - Ingress proxy (Relay 1): The first PNN may assign the user an anonymous IP address (maps to their region but not their actual location). It may have visibility of the user IP address.

[0092] - Egress proxy (Relay 2): The second PNN may decrypt the web address they want to visit and forwards them to their destination. It may have visibility of the User traffic destination. The present disclosure provides for a technique enabling controlled flow of user data traffic between the UE 200 and the server 400 via at least one PNN, e.g., via two PNNs in case of a dual-proxy deployment.

[0093] Fig. 2 illustrates a method performed by the UE 200. To this end, the UE 200 comprises at least one processor 210 and at least one memory 220, the at least one memory 220 storing instructions which, when executed by the at least one processor 210, cause the at least one processor 210 to perform said method.

[0094] The method comprises, at 2002, obtaining, from the core network node 600, at least one route selection rule associating one or more of the plurality of PNNs 310-390 with at least one user data traffic parameter.

[0095] The one or more route selection rules may comprise at least one URSP. The at least one route selection rule may associate one or more second PNNs 360-390 with at least one user data traffic parameter. In an example, the at least one user data traffic parameter is a TC and / or is associated with an application causing the user data traffic, for example with an identity or type of the application.

[0096] The method further comprises, at 2004, selecting, based on the obtained at least one route selection rule, at least one (e.g., the PNN 340 and / or 370) of the plurality of PNNs 310-390 for routing the user data traffic between the UE 200 and the server 410 over the selected at least one PNN. The UE 200 may then direct user data traffic toward the selected at least one PNN.

[0097] The selected at least one PNN may be part of a chain of PNNs as shown in Fig. 1, the chain comprising a first PNN 340 as ingress PNN and a second PNN 370 as egress PNN. In an example, the selected at least one proxy network node is the first PNN 340, acting as ingress PNN. In another example, the selected at least one proxy network node is the second PNN 370, acting as egress PNN. In an example, the selected at least one PNN comprises or is a MASQUE PNN.

[0098] It is to be noted that the first PNN and / or the second PNN may be implemented by a network function of the CN or may implement one or more network functions (NFs) of the CN. For example, the first PNN may be configured to implement a UP function. In an example, the first PNN is configured as a UPF, a PGW-U or A TDF-U of the CN. The method may further comprise sending a PDU Session Establishment Request message to the core network node. In response to sending said message, the method may comprise obtaining, from the core network node 600, an identifier of the first PNN 340, acting as ingress PNN. In this case, the selected at least one proxy network node may be the second PNN 370, acting as egress PNN. The LIE 200 may then direct user data traffic toward the first PNN based on the obtained identifier.

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

[0100] Fig. 3 illustrates a method performed by one of the PNNs of the group 300 (e.g., the PNN 340). To this end, the PNN 340 may comprise at least one processor 342 and at least one memory 344, the at least one memory 344 storing instructions which, when executed by the at least one processor 342, cause the at least one processor 342 to perform said method. The method may be performed in parallel with the method of Fig. 2.

[0101] The method comprises, at 3002, sending a session establishment message to the core network node 600 (e.g., of the CN connected to and / or associated with the RAN 500). The session establishment message may be a PFCP Session Establishment Response message.

[0102] The session establishment message includes an identifier of the first PNN 340 to be indicated to the UE via the core network node 600 for configuring the LIE to direct user data traffic toward the first PNN 340 based on the obtained identifier.

[0103] As in the method of Fig. 2 and the example of Fig. 1, the plurality of proxy network nodes may be configured to form a plurality of chains via which the user data traffic can be routed, each chain comprising the first proxy network node 310-350 and a second proxy network node 360-390 of the plurality of proxy network nodes. The first PNN 340 may be configured as (e.g., MASQUE and / or QUIC) ingress PNN and the second proxy network node as egress (e.g., MASQUE and / or QUIC) PNN or vice versa.

[0104] The method may comprise obtaining, from the core network node 600, one or more UP rules assigning identifiers of one or more second proxy network nodes (e.g., the PNN 370) of the plurality of proxy network nodes to one or more traffic management actions to be performed by the first proxy network node (e.g., the PNN 340). In an example, the one or more UP Rules are indicated by a PFCP Session Establishment Request message. The method may further comprise: performing a header inspection of user data traffic of the UE 200 to obtain an identifier of one of the one or more second proxy network nodes; and performing the traffic management action(s) assigned to the obtained identifier by the one or more UP Rules.

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

[0106] Fig. 4 illustrates a method performed by core network node 600. To this end, the core network node 600 may comprise at least one processor 610 and at least one memory 620, the at least one memory 610 storing instructions which, when executed by the at least one processor 620, cause the at least one processor 620 to perform said method. The method may be performed in parallel with the method of Fig. 2 and / or Fig. 3.

[0107] The method comprises, at 4002, providing the UE 200 with at least one route selection 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, based on the provided route selection rule(s), at least one of the plurality of proxy network nodes 310-390 for routing the user data traffic between the UE 200 and the server 400 over the selected at least one proxy network node (e.g., 340).

[0108] As in the methods of Fig. 2 and 3, and as in the example of Fig. 1, the plurality of proxy network nodes may be configured to form a plurality of chains via which the user data traffic can be routed, each chain comprising a first PNN 310-350 and a second PNN 360-390 of the plurality of proxy network nodes that is to be selected by the UE 200. Again, the first PNN may be an (e.g., MASQUE and / or QUIC-) ingress PNN and the second PNN may be an egress an (e.g., MASQUE and / or QUIC-) PNN or vice versa. The method may comprise receiving (e.g., from the network node 700 or an application provider) address information (e.g., an IP address) of at least one of the second PNNs. The method may further comprise determining a binding between the address information of the at least one second proxy network node and at least one user data traffic parameter, and, optionally, storing the binding. In an example, the binding is determined by a NEF or a SCEF (e.g., implemented by the core network node 600). The binding may be stored in a UDR or a SPR (e.g., implemented by the core network node 600). The method may further comprise determining at least one route selection rule based on the binding. In an example, the at least one route selection rule is determined by a PCF implemented by the core network node 600.

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

[0110] The method may further comprise receiving a PDU Session Establishment Request message from the UE 200, wherein the identifier of the first PNN is indicated to the UE in response to the PDU Session Establishment Request message.

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

[0112] As mentioned above, the user data traffic between the UE 200 and the server 400 may be (e.g., QUIC-) encrypted such that a payload of the user data traffic is hidden at least for the first PNN 340. Also in the method according to Fig. 4, the first PNN (e.g., 340) may be configured to implement a UP function. In an example, the first proxy network node is configured as a UPF, a PGW-U or a TDF-U of a Core Network, CN. Again, the at least one user data traffic parameter may be a TC and / or may be associated with an application causing the user data traffic, for example with an identity or type of the application.

[0113] Further details of the technique will now be explained with reference to Figs. 5 to 10. Fig. 5 illustrates a network architecture in accordance with the present disclosure. This architecture corresponds to the 5thgeneration (5G) network architecture. Among other network functions, the network architecture in particular provides an UDR 1010, a NEF 1020, a Network Data Analytics Function (NWDAF) 1030, an Application Function (AF) 1040, a PCF 1050, a Charging Function (CHF) 1060, an Access and Mobility Management Function (AMF) 1070, an SMF 1080 and a UPF 1090. The AF 1040 interacts with the 3GPP CN and allows external parties to use Exposure Application Programming Interfaces (APIs) offered by the operator of the network (e.g., the MNO). The NEF 1020 supports different Exposure APIs. The 5G System architecture allows the PCF 1050 and NEF 1020 to store data in the UDR 1010, e.g. subscription policy data to be used by the PCF 1050. The AMF 1070 may support different functionalities such as termination of Non-Access-Stratum (NAS) signaling, NAS ciphering and integrity protection, registration management, connection management, mobility management, access authentication and authorization, security context management. The AMF 1070 may be used to convey information from and / or to the UE 200 through NAS signaling, including policies provided by the PCF 1050. The PCF 1050 generally supports a unified policy framework to govern the network behaviour. The PCF 1050 may provide (e.g., UE) Policies and PCC rules to the SMF 1080. The SMF 1080 may receive PCC rules from the PCF 1050 and configure the UPF 1090 accordingly. The UPF 1090 generally supports handling of user plane traffic based on the rules received from the SMF 1080, e.g. packet inspection and different enforcement actions such as Sponsored Data or QoS handling. One or more of the network functions (e.g., NEF 10250, AMF 1070, PCF 1050 (e.g., including PCF-AM 1052 and PCF-SM 1054), and optionally also UPF 1090) may be implemented by the core network node 600. Put differently, the core network node 600 may be configured as the one or more of the network functions.

[0114] Figs. 6-10 illustrate an exemplary sequence of method steps in accordance with the present disclosure. The present disclosure is not limited to the methods discussed above with reference to Figs. 2-4. Rather, the present disclosure is to be understood as also providing for methods that comprise one or more of the steps described herein below (e.g., without the steps of the methods of Figs. 2-4). For example, a method comprising or consisting of one or more of the following steps described below for Figs. 6-10 may be provided: 2, 9, 11, 13, 22, 24, 26 and / or 28. FIRST SCENARIO

[0115] Figs. 6-10 apply to a first scenario in which, generally speaking, the MNO enforces policy rules for traffic management. To this end, the MNO may provide the ingress proxy (e.g., in the form of the UPF) and enforce policy rules for traffic management based on traffic destination (e.g. egress proxy). It may be beneficial in the first scenario if there exists a Service Level Agreement (SLA) between the different parties involved in the dual-proxy deployment, for example between a UE vendor, the MNO providing the ingress proxy in this dual-proxy deployment, and a third party (e.g., a Content Delivery Network (CDN) provider) providing the egress proxy in this dualproxy deployment.

[0116] EXPOSURE OF PROXY RELATED INFORMATION

[0117] Referring to Fig. 6, at 1, a third party (e.g., a CDN provider) that provides the egress proxies 360-390 for dual-proxy deployments provisions the egress proxy address information to the MNO. In other words, the core network node 600 may receive the address information from the MNO or the network node 700. A Nnef_Dual Proxy API may be defined in this context. The AF 1040 may transmit a request message (e.g., Nnef_DualProxy_Provision Request) to the NEF 1020. This message includes egress proxy address information, which may include Fully Qualified Domain Names (FQDNs) and / or IP addresses of the egress proxies 360-390. The message may further include an Egress Proxy Provider-ID, which identifies the provider of the Egress Proxies in this dual-proxy deployment.

[0118] Optionally (e.g., for the second scenario mentioned below), the message may include Egress Proxy Type information. The Egress Proxy Type information identifies the policies the egress proxy 360-390 is preconfigured to enforce. The allowed Egress Proxy and corresponding policies may be part of SLA. This parameter is optional and may only be needed when the enforcement is delegated to the egress proxy as in the second scenario.

[0119] At 2, the NEF 1020 binds the Egress Proxy addresses into applications and / or TCs (e.g. Egress Proxy address #1 to App-ID=example.com). In other words, the NEF 1020 (e.g., implemented by the core network node 600) determines the binding (e.g., as described above for Fig. 4). In this manner, the MNO providing the NEF 1020 can influence the selection of the egress proxy depending on the application, the application category and / or the TC.

[0120] The TCs may be defined in a 3GPP technical report or standard. For example, the Traffic Categories may comprise one or more of the categories mentioned in 3GPP TR 23.700-85 "Study on enhancement of 5G UE policy". Exemplary Traffic Categories include the following:

[0121] - IMS traffic category (e.g., voice, video and short message service (SMS) over IP Multimedia Subsystem (IMS), as well as Rich Communications Services (RCS), may be included in this traffic category);

[0122] - Internet traffic category;

[0123] - Internet of Things (loT) and machine to machine type of traffic;

[0124] - On demand downlink streaming;

[0125] - On demand uplink streaming;

[0126] - Vehicular communications;

[0127] - Real time interactive traffic;

[0128] - Unified communications traffic (e.g., instant messaging, voice-over-IP (VoIP) and video collaboration may be included in this category);

[0129] - Background traffic (e.g., comprising processes for firmware and / or software updates over the air);

[0130] - Location-based traffic; and

[0131] - Critical Communications.

[0132] For the NEF 1020 to retrieve the relevant application information, one of two mechanisms may be used:

[0133] - Static: based on local configuration of the NEF 1020. This complies with the sequence shown in the exemplary sequence of Figure 6.

[0134] - Dynamic: based on the NEF 1020 getting all relevant application information from the UDR 1010. Subscribed data plans are usually stored in UDR 1010. For example, the PCF 150 may retrieve this information (e.g., as subscription policies from Application Data in UDR 110) in order to generate PCC rules. In this case, the NEF 1020 may retrieve such data to do the binding.

[0135] In one implementation the procedure takes the complete MNO offering into account. The NEF 1020 may bind an egress proxy to applications and / or TCs that share traffic management policy in all data plans. That egress proxy may not be associated to other applications and / or TCs that may require different traffic management treatment. For example, if the MNO has a data plan including a Gaming subscription (e.g., with specific Charging and / or QoS, like low latency), the NEF 120 provided by the MNO might bind a certain egress proxy into a certain traffic category (e.g., Gaming). In this manner, for a PDll session of the UE 200, all gaming application traffic will go through that egress proxy, and based on that, the MNO can differentiate (e.g., based on the destination address, that of an egress proxy instance) and apply specific Charging and / or QoS, like low latency.

[0136] At 3 to 5, optionally, the NEF 1020 stores some or all of the above information in the UDR 1010 (e.g., in a data structure relative to dual-proxy deployment). The LIDR 1010 may thus store the information at 4 and answer at 5 to indicate successful storage. At 6, the NEF 1020 may answer the AF to indicate successful operation.

[0137] REGISTRATION AND PDU SESSION ESTABLISHMENT

[0138] It is now referred to Fig. 7. The sequence diagram in Figs. 7-9 does not include all signaling messages that may be involved in the Registration and PDU Session Establishment procedure. Rather, the relevant parts to enable the technique disclosed herein are shown.

[0139] At 7, the UE 200 initiates a registration procedure by transmitting a Registration Request message to the AMF 1070. The AMF 1070 may be implemented by the core network node 600.

[0140] At 8, the AMF 1070 transmits a request message (e.g., Npcf_AMPolicyControl_Create Request) to the PCF-AM 1052. In this manner, the AMF 1070 may create an AM policy association.

[0141] At 9 and 10, the PCF-AM 1052 contacts the NEF 1020 to retrieve the Egress Proxy addresses and applications and / or Traffic Categories binding information. In other words, the PCF-AM 1052 requests at least the egress proxy address information and the binding, and optionally also the user data traffic parameter of the binding, from the NEF 1020. The PCT-AM 1052 may request this information from the NEF 1020 by transmitting a corresponding request message to the NEF 1020 (e.g., a Nnef_DualProxy_Get Request).

[0142] At 11 and 12, the NEF 1020 looks for the requested information. This information may be locally stored in the NEF 1020 or stored in the UDR as described for Fig. 6. The NEF 1020 then returns the requested information, e.g., Egress Proxy addresses and bound applications and / or Traffic Categories. The requested information may be returned by transmitting a response message from the NEF 1020 to the PCF-AM, the response message including the requested information. The response message may be a Nnef_DualProxy_Get Response message. In particular, the NEF 1020 may transmit, to the PCF-AM 1052, a list of (Egress Proxy address, App-ID (example.com) and / or TC), and, optionally, a default Egress Proxy. Such a default Egress Proxy may be used for rules with traffic descriptors for which no specific binding information is provided.

[0143] At 13, based on the received information, the PCF-AM 1052 determines at least one route selection rule. This at least one route selection rule associates one or more of the plurality of (e.g., second) PNNs 350-390 with at least one user data traffic parameter. The at least one route selection rule in the illustrated example corresponds to at least one URSP rule. Such URSP rules may indicate to the UE 200 towards which Egress proxy / ies to route the application (e.g., example.com) or TC traffic to for applications / Traffic Categories relevant for the subscription. One or more of the URSP rules may include a traffic descriptor (e.g., an application descriptor and / or Connection Capabilities, which will be used to carry the Traffic Category). The traffic descriptor may comprise an IP address filter parameter and / or an application identifier. In the illustrated example, the traffic descriptor corresponds to a URL, in particular "example.com". One or more of the URSP rules may include a route selection descriptor (e.g., an egress proxy address or an ingress proxy address). The route selection descriptor may correspond to the Route selection descriptor as defined in 3GPP TS 24.526, extended as follows, wherein the extended portions are highlighted with brackets:

[0144] Route selection descriptor component type identifier Bits 87654321 00000001 SSC mode type

[0145] 00 000 010 S-NSSAI type

[0146] 00 000 100 DNN type

[0147] 00001000 PDU session type type

[0148] 00010000 Preferred access type type

[0149] 00010001 Multi-access preference type

[0150] 00100000 Non-seamless non-3GPP offload indication type

[0151] 01000000 Location criteria type 1 0 0 0 0 0 0 0 Time window type

[0152] 1 0 0 0 0 0 0 1 5G ProSe layer-3 UE-to-network relay offload indication type

[0153] 1 0 0 0 0 0 1 0 PDll session pair ID type

[0154] 1 0 0 0 0 0 1 1 RSN type

[0155] {1 0 0 0 0 1 0 0 Ingress Proxy type}

[0156] {1 0 0 0 0 1 0 1 Egress Proxy type}

[0157] All other values are spare. If received, they shall be interpreted as unknown.

[0158] {For "Ingress Proxy type", the route selection descriptor component value field shall be encoded as a sequence of a one octet Ingress Proxy length field, and a Proxy value field of a variable size. The Proxy value can either be a FQDN or IP address.}

[0159] {For "Egress Proxy type", the route selection descriptor component value field shall be encoded as a sequence of a one octet Egress Proxy length field, and a Proxy value field of a variable size. The Proxy value can either be a FQDN or IP address.}

[0160] NOTE 1: For "OS Id + OS App Id type", the traffic descriptor component value field does not specify the OS version number or the version number of the application.

[0161] NOTE 2: The PCF does not include both the "preferred access type type" and the "multi-access preference type" route selection descriptor components in a single route selection descriptor. If there are both "preferred access type type" and "multi-access preference type" route selection descriptor components in a single route selection descriptor, the UE ignores the "preferred access type type" route selection descriptor component.

[0162] NOTE 3: The W-AGF acting on behalf of the FN-RG shall interpret the value as unknown.

[0163] NOTE 4: The traffic descriptor of a URSP rule cannot include more than one instance of this traffic component type.

[0164] NOTE 5: Redundant PDU session is not applicable over non-3GPP access. The UE ignores any route selection descriptor which includes "PDU session pair ID type" or "RSN type" route selection descriptor component and also includes a "preferred access type type" route selection descriptor component set to "non-3GPP access" or a "multi-access preference type" route selection descriptor component. NOTE 6: The traffic descriptor of a URSP rule shall not contain both the "Single remote port type" and the "Remote port range type" traffic descriptor components. If the traffic descriptor of a URSP rule contains both the "Single remote port type" and the "Remote port range type" traffic descriptor components, the receiving entity shall ignore the URSP rule.

[0165] NOTE 7: The traffic descriptor of a URSP rule shall not contain both the "Destination MAC address type" and the "Destination MAC address range type" traffic descriptor components. If the traffic descriptor of a URSP rule contains both the "Destination MAC address type" and the "Destination MAC address range type" traffic descriptor components, the receiving entity shall ignore the URSP rule.

[0166] {NOTE 8: The traffic descriptor of a URSP rule cannot include both "Ingress Proxy Type" and "Egress Proxy Type".}

[0167] The PCF-AM 1052 may transmit, to the UE 200, via the AMF 1070, the at least one route selection rule. At 14, based on the determined at least one route selection rule (e.g., the URSP rules), the PCF-AM 1052 provides the (e.g., extended) URSP rules to the UE 200 by transmitting a Namf_Communication_NlN2MessageTransfer message to the AMF 1070. The PCF-AM 1052 may invoke the procedure for UE Configuration Update (e.g., as defined in 3GPP 23.502 section 4.2.4.3) to provide the (e.g., extended) URSP rules to the UE 200 via the AMF 1070. The Namf_Communication_NlN2MessageTransfer message in the illustrated example includes a URSP rule (traffic descriptor=example.com, route selection descriptor Egress Proxy address).

[0168] At 15, the AMF 1070 (e.g., transparently) forwards the message received from the PCF-AM 1052 to the UE 200. That is, the UE 200 obtains the at least one route selection rule from the AMF 1070. This may correspond to the step 2002 described above. From the perspective of the CN, this may correspond to the step 4002 described above.

[0169] At 16, the UE 200 stores the at least one route selection rule (e.g., the URSP rule).

[0170] At 17, the PCF-AM 1052 transmits to the AMF a Npcf_AMPolicyControl_Create Response.

[0171] At 18, the AMF 1070 transmits to the UE 200 a Registration Accept message. PDU SESSION ESTABLISHMENT

[0172] Referring to Fig. 8, at 19, the UE 200 triggers a PDU session establishment by transmitting a corresponding request message to the core network node 600. In particular, the UE 200 transmits a PDU Session Establishment Request to the AMF 1070.

[0173] At 20, the AMF 1070 sends a request message to the SMF 1080 requesting creation of a PDU Session. That is, the AMF 1070 transmits a Nsmf PDU Session Create Request to the SMF 1080.

[0174] At 21, the SMF 1080 triggers the PCF-SM 1054 to determine one or more PCC rules. At 21, the SMF 1080 may transmit a Npcf_SMPolicyControl_Create Request message to the PCF-SM 1054.

[0175] At 22, the PCF-SM 1054 determines one or more PCC rules. The one or more PCC rules may be associated with at least one user data traffic parameter, for example with an (e.g., identifier or type of) an application. The one or more PCC rules may be determined by the PCF-SM 1054 based on a local configuration and / or a subscription. The one or more PCC rules may be determiend for App-ID(s) (e.g., "example.com") and / or Traffic Categories. At least one of the one or more PCC rules may be a dynamic PCC rule. At least one of the one or more PCC rules (e.g., the dynamic PCC rule) may be associated with a traffic descriptor and at least one traffic management action associated with said respective traffic descriptor.

[0176] At 23, the PCF-SM 1054 indicates the one or more PCC rules, determined at 22, to the SMF 1080. To this end, the PCF-SM 1054 may transmit a Npcf_SMPolicyControl_Create Response message to the SMF 1080. The PCF-SM 1054 may provide the SMF 1080 with a list of the one or more PCC Rules.

[0177] For dynamic PCC rules, each PCC rule determined and / or provided by the PCF-SM 1054 may include:

[0178] - a traffic descriptor, for example including an application identifier (e.g., "App-ID = example.com"); and

[0179] - a traffic management action (e.g., zero rating or QoS) for the user data traffic matching said traffic descriptor. For static PCC Rules, the PCF-SM 1054 may indicate a PCC Rule identifier to the SMF 1080. In this case, the identified PCC Rule may be configured by the SMF 1080.

[0180] At 24 and 25, the SMF 1080 contacts the NEF 1020 to retrieve the binding (e.g., determined at 2 of Fig. 6). The SMF 1080 may contact the NEF 1020 to retrieve the information of the binding between Egress Proxy addresses and applications and / or Traffic Categories. To this end, the SMF 1080 may transmit a corresponding request message (e.g., Nnef_DualProxy_Get Request message) to the NEF 1020. The SMF 1080 may, at 25, indicate, to the NEF 1020, one or more application identifiers and / or traffic categories (e.g., associated with the PDU session to be established). In particular, the request message transmitted form the SMF 1080 to the PCF-SM 1054 may include a list of App-IDs (e.g., "example.com") and / or TCs. This may allow requesting which specific App-IDs (example.com) and / or TCs are of interest for this PDU particular session.

[0181] At 26 and 27, the NEF 1020 provides the binding to the SMF 1080. The binding, may be locally stored in NEF 1020 or stored in UDR as described above. The NEF 1020 may indicate, to the SMF 1080, only parts of the binding that are associated with the application identifiers and / or TCs indicated by the SMF 1080 to the NEF 1020 at 25. The NEF 1020 may return the information of binding between Egress Proxy addresses and applications and / or Traffic Categories by transmitting, to the SMF 1080, a corresponding response message (e.g., Nnef_DualProxy_Get Response message). The response message may include a list of Egress Proxy address, App-ID (example.com) and / or TC, and, optionally, the default Egress Proxy. The default Egress Proxy may be used for applications and / or traffic categories for which no specific binding is provided.

[0182] At 28, the SMF 1080 maps the PCC rules into PDRs for egress proxies. In other words, the SMF 1080 determines one or more UP Rules (PDRs, FARs, etc.). The one or more UP Rules may assign identifiers of one or more second (e.g., egress) proxy network nodes 360-390 of the plurality of proxy network nodes 310-390 to one or more traffic management actions to be performed by the first (e.g., ingress) proxy network node 360 (e.g., configured as the UPF 1090). These UP Rules are to be provisioned corresponding to the active PDU Session PCC rules. For example, the SMF 1080 may replace an application identifier in PDR Packet Descriptor Information (PDI) for traffic filters where an IP destination address is set to the bound egress proxy IP address. As a default rule, the SMF 1080 might use the default Egress Proxy. At 29, the SMF 1080 triggers a PFCP Session Establishment. To this end, the SMF 1080 transmits a PFCP Session Establishment Request message to the UPF 1090. This message may indicate the UP Rule(s) determined at 28. For example, the message transmitted to the UPF 1090 may include one or more PDRs, FARs, QERs and / or URRs (e.g., determined at 28 and / or mapped to the PCC rules). Such a PDR / FAR / QER / URR may include: (i) an (e.g., uplink or downlink) PDR with PDI to detect traffic through the Egress Proxy address associated with the application (e.g., "example.com") in the corresponding PCC rule; and (ii) an associated traffic management action (e.g., an associated FAR, QER and / or URR to indicate the requested traffic management actions in the corresponding PCC rule).

[0183] In the sequence diagram example shown in Fig. 9, the Ingress proxy is assumed to be within the UPF 1090. In other words, the UPF 1090 acts as the Ingress proxy. In this case, the ingress proxy network node 340 may be configured as the UPF 1090. In this example, as part of the PFCP session creation in the UPF 1090, the UPF 1090 assigns the address of the Ingress Proxy, and the UPF 1090 answers the SMF 1080 at 30 indicating successful operation. In particular, at 30, the UPF 1090 (e.g., at the network node 340) indicates, to the SMF 1080 (e.g., at the core network node 600) an identifier and / or address of the ingress proxy network node 340 (e.g., in a response message, in particular a PFCP Session Establishment Response message). This may correspond to the step 3002 described above.

[0184] After 30, both the ingress proxy (e.g., UPF 1090) and the SMF 1080 know the identifier and / or address of the ingress proxy for the PDU session. The UE 200 may then be informed accordingly, for example via the core network. To this end, at 31, the SMF 1080 indicates the identifier and / or address of the ingress proxy to the AMF 1070 (e.g., by indicating same in a response message such as a Nsfm PDU Session Create Response message, for example by extending the ePCO field of said message accordingly). At 32, the AMF 1070 indicates the identifier and / or address of the ingress proxy to the UE 200 (e.g., by indicating same in a response message such as a PDU Session Establishment Response message, for example by extending the ePCO field of said message accordingly). At 33, the UE stores the obtained identifier and / or address of the ingress proxy.

[0185] The UE 200 may then use this identifier and / or address of the ingress proxy and the at least one route selection rule (e.g., URSP rule stored at 16) to route application data traffic toward particular proxies, as will now be exemplarily explained with reference to Fig. 10.

[0186] TRAFFIC HANDLING

[0187] Referring to Fig. 10, at 34, a user opens an application (e.g. „exa mple.com") on the UE 200. The LIE 200 may then enable a „user privacy mode" by using a dual-proxy deployment. To this end, the UE 200 executes the at least one route selection rule (e.g., a stored URSP rule). The UE 200 may then route (e.g., forward) the application traffic, also referable to as user data traffic, of the application towards the selected Ingress and / or Egress Proxy. This selection may correspond to the step 2004 described above. The UE 200 may route the traffic to the other one of the Ingress / Egress Proxy based on the identifier of proxy (e.g., indicated by the ePCO). In a general example, an application executed by the UE 200 may provide a Traffic category to an operating system (OS) of the UE 200, and the OS may steer the application traffic, also referable to as user data traffic, into a PDU Session based on MNO provided URSPs. All traffic in a PDU session may receive a same (e.g., QoS) treatment by the network.

[0188] At 35, the UE 200 transmits a connection request to the Ingress Proxy (e.g., the UPF 1090). This message may be a HTTP CONNECT message. The connection request message may indicate the following information: : protocol =connect-udp :scheme=https :path= / egressproxyinstance.com / 443 / streamId=0

[0189] At 36, the Ingress Proxy (in the illustrated example the UPF 1090) detects traffic through the Ingress and / or Egress Proxy. The (e.g., identifier and / or address of the) Egress Proxy may be derived by the Ingress Proxy from a header of the user data traffic (e.g., :path header). The Ingress Proxy may apply one or more corresponding traffic management actions (e.g. zero rating or QoS) based on the traffic and / or the derived Egress Proxy information. The one or more traffic management actions may be associated with or indicated by the UP rule(s) previously obtained at 29.

[0190] At 37, the UPF 1090 answers the UE 200 with a response message to indicate successful operation. The response message may be a HTTP Response (e.g., :status=200). At 38, through (e.g., the tunnel of) the Ingress Proxy connection, the UE 200 transmits a connection request message to the Egress Proxy (e.g., a HTTP CONNECT request). The connection request message may including the following information: : protocol =connect-udp :scheme=https :path= / example.com / 443 / :authority=egressproxyinstance.com streamId=0.

[0191] The sequence diagram shown in Figure 10 is just an example. The technique may employ other HTTP methods, such as connect-ip or regular HTTP connect.

[0192] At 39, the Ingress Proxy (e.g., UPF 1090) forwards the connection request message to the Egress Proxy. The target domain (e.g., "example.com") may not be visible to the Ingress Proxy, thereby ensuring that the user privacy is respected.

[0193] At 40, the Egress Proxy (e.g., 370) answers indicating successful operation.

[0194] At 41, the UE 200 sends HTTP3 datagrams towards the Application Server (e.g., 400). End-to-end data may be relayed via the Ingress Proxy to the Egress Proxy and onwards to the target server 400. The MNO may be unaware of the target application, the provider of the Egress Proxy and target server on the other hand may be unaware of the subscriber address, thereby ensuring that user privacy is respected.

[0195] At 42, the Ingress Proxy (e.g., UPF 1090) detects traffic routed (e.g., through the tunnel) via the Ingress and Egress Proxies (e.g., 340, 370) and applies the corresponding traffic management actions (e.g., zero rating and / or QoS).

[0196] VARIANT OF FIRST SCENARIO

[0197] In one variant of the first scenario, the ingress proxy (e.g., 340) is not integrated in the UPF 1090 but deployed after UPF 1090. For example, the ingress proxy is provided in N6-LAN and / or no bound to the PDU session. For example, the ingress proxy is not provided by the MNO (e.g., in a Private Relay deployment where a 3rd party is hosting the Ingress Proxy). In this variant of the first scenario, the UPF 1090 (e.g., provided by the MNO) may enforce policy rules for traffic management based on traffic destination (e.g., the identifier and / or the address of the Ingress proxy).

[0198] In this variant, the solution described with referende to Figs. 6-10 may be modified as follows:

[0199] The at least one route selection rule (e.g., URSP(s)) may allow selecting an ingress proxy instead of an egress proxy. If a 3rdparty provides the ingress proxy, the same sequence as in Fig. 6 may apply, but with replacing "Egress proxy" by "Ingress proxy". If the MNO provides the ingress proxy, the sequence of Fig. 6 can still be applied, or this information may be configured by the operator via an OAM. In any case, the NEF 1020 and / or UDR in this variant of the first scenario may store the binding (e.g., of Ingress Proxy addresses to applications and / or Traffic Categories).

[0200] In the variant of the first scenario, the PCF-AM 1052 may retrieve the binding related to the Ingress Proxy instead of the Egress Proxy at 9 to 12. With the information retrieved, the PCF-AM 1052 may add proxy type information to the at least one route selection rule (e.g., URSP(s)) and they are sent to the UE 200 at 14 to 15. In this case, the proxy type information may indicate an ingress proxy.

[0201] In the variant of the first scenario, the SMF 1080 may, at 24 to 27, retrieve the binding that in this case is corresponding to the ingress proxy instead of the egress proxy. At 28, the SMF 1080 may proceed in a similar manner by including in the PDRs packet detection information (PDI) as Destination IP address the corresponding ingress proxy address of Application ID and / or Traffic category from the PCC Rule. At 30 to 33, the ingress proxy address may be neither provided by the LIPF 1090 to the SMF 1080 nor to the UE 200 (e.g., not even in ePCO).

[0202] SECOND SCENARIO

[0203] In a second scenario, the MNO may delegate the policy rule enforcement on a 3rdparty. In the second scenario, the MNO may or may not provide the ingress proxy. The traffic management actions may be performed at an Egress proxy owned by a 3rdparty (e.g., an Egress Proxy that is not part of a netowkr of the MNO). This may be advantageous if an egress proxy address is not enough to perform the traffic management action (e.g., parental control may require that the actual traffic destination is available and can be assessed). The traffic may need to be routed to an egress proxy configured with applicable traffic management actions. For example, a 3rdparty egress proxy may be in charge of parental control. At least one egress proxy (e.g., 370) may be configured to gate traffic depending on predefined filtering rules (e.g., adult content: allowed or not_allowed; violence: allowed or not_allowed). The user data traffic may be sent to the egress proxy with a configuration that matches the subscription setting for parental control.

[0204] Details of the first scenario described above may apply with some changes (e.g., the UPF 1090 does not need to be provisioned with rules to perform the delegated actions).

[0205] With regards to exposure of proxy related information, the same sequence as in Fig. 6 may apply. The egress proxy type in this context may relate to the actions the egress proxy is configured to enforce. The outcome of this sequence is that the NEF 1020 and / or UDR stores the binding (e.g., binding of applications and / or Traffic Categories to egress proxy), but one application and / or Traffic category may be bound to more than one egress proxy (e.g., each being associated with an egress proxy type). The egress proxy type may also be stored as part of the binding.

[0206] In the second scenario, at 9 to 12, the PCF-AF may retrieve the binding (e.g., associated with the egress proxy). Where several egress proxy options exist, the PCF-AF may decide which one to include in the at least one route selection rule (e.g., URSP), for example based on subscription information (e.g., parental control permissions in the subscription).

[0207] In the second scenario, at 21 to 23, the SMF 1080 may not receive PCC rule instructions for actions that have been delegated to the egress proxy.

[0208] If the MNO provides the ingress proxy (e.g., 340), for example if the UPF 1090 integrates the ingress proxy, the sequence at 30 to 33 may apply as such so that UE 200 is provided the ingress proxy address. If the ingress proxy is provided by the MNO but not implemented as the UPF 1090, the SMF 1080 may indicate the ingress proxy identifier and / or address to the UE 200 (e.g., in ePCO), for example based on a local (e.g., predefined) configuration of the SMF 1080.

[0209] It is possible that in a single proxy deployment, some actions are delegated to the egress proxy and some others are not. For example, charging may not be delegated to the egress proxy (e.g., rather performed by the ingress proxy), whereas parental control may be delegated to the egress proxy. The mechanisms described above can be combined to achieve such results.

[0210] The technique disclosed herein does not only apply to the 5G network architecture, but also to other network architectures such as 4G. In case of a 4G network architecture, the terms used herein may be replaced as follows:

[0211] - NEF by SCEF;

[0212] - PCF by PCRF;

[0213] - UDR by SPR;

[0214] - AMF by MME;

[0215] - SMF by PGW-C or TDF-C;

[0216] UPF by PGW-U or TDF-U.

[0217] To recap, network operators may require application and / or service awareness in order to apply differentiated traffic management actions (e.g. Charging, QoS, etc.), according to operator policies and subscription terms. In current solutions, it may not be possible to apply differentiated traffic management actions in dual-proxy deployments, especially if they protect the user's privacy so that no single entity can identify both users (and so subscriptions) and which sites are visited. Egress proxies may have been deployed by and may be under full control of a 3rdparty with a SLA with the MNO.

[0218] One aspect of the present technique is based on an extension of the URSP rules such that the MNO can, based on the subscription, influence the LIE 200 to select certain (e.g., ingress and / or egress) proxies to route the application traffic to depending on, e.g., the application and / or the application category.

[0219] By influencing the selection of an ingress / egress proxy for specific traffic, the applicable traffic management policies according to the subscription and application or application category can be enforced with one of the following:

[0220] - First scenario: Mobile Network enforces policy rules for traffic management that can be based on traffic destination (e.g., ingress and / or egress proxy);

[0221] - Second Scenario: The ingress / egress proxy selected is pre-configured with the applicable policy rules for traffic management, and the MNO delegates the policy enforcement to that proxy.

[0222] Both scenarios may allow the MNO to apply differentiated traffic management actions in dual-proxy deployments. User privacy may be preserved while operator policies and subscription terms can still be enforced. In case it is referred to a message, data or a parameter "including" some information herein, this information in a first variant is explicitly indicated and in a second variant is implicitly (e.g., indirectly) indicated. As far as it is referred to a flow of traffic between a first entity and a second entity, in a first variant, this consists of a unidirectional flow from the first entity (e.g., the UE 200) to the second entity (e.g., the server 400), in a second variant, this consists of a unidirectional flow from the second entity to the first entity, in a third variant, this consists of a bidirectional flow from the first entity to the second entity and from the second entity to the first entity. Various modifications of the technique disclosed herein are possible. For instance, some of the method steps discussed with reference to Figs. 6-10 may be omitted, replaced or combined. Further advantages and modifications may be apparent to those skilled in the art in view of the present disclosure.

[0223] ABBREVIATIONS

[0224] AF Application Function

[0225] AMF Access and Mobility Function

[0226] API Application Programming Interface

[0227] AS Application Server

[0228] CHLO Client Hello

[0229] CP Control Plane

[0230] CUPS Control Plane User Plane Separation

[0231] DL Downlink

[0232] DNS Domain Name System

[0233] DoH DNS over HTTPS

[0234] DoT DNS over TLS

[0235] DPI Deep Packet Inspection

[0236] ECH Encrypted Client Hello ePCO Extended Protocol Configuration Options

[0237] ESNI Encrypted SNI

[0238] FAR Forwarding Action Rule

[0239] FQDN Fully Qualified Domain Name

[0240] HTTP HyperText Transfer Protocol

[0241] HTTPS HTTP Secure

[0242] IE Information Element

[0243] MASQUE Multiplexed Application Substrate over QUIC Encryption

[0244] MME Mobility Management Engine

[0245] MNO Mobile Network Operator NAS Non Access Stratum

[0246] NEF Network Exposure Function

[0247] OTT Over the Top

[0248] PCF Policy Control Function

[0249] PCO Protocol Configuration Options

[0250] PCRF Policy and Charging Rule Function

[0251] PDN Packet Data Network

[0252] PDR Packet Detection Rule

[0253] PFCP Packet Flow Control Protocol

[0254] PFD Packet Flow Description

[0255] PGW Packet Gateway

[0256] PGW-C Packet Gateway Control Plane

[0257] PGW-U Packet Gateway User Plane

[0258] PUI Public User Identity

[0259] QNAME Query Name

[0260] QoS Quality of Service

[0261] RAN Radio Access Network

[0262] SCEF Service Capability Exposure Function

[0263] SDF Service Data Flow

[0264] SMF Session Management Function

[0265] SNI Server Name Indication

[0266] NSSAI Network Slice Selection Assistance Information

[0267] SPR Subscriber Profile Repository

[0268] SUPI Subscription Permanent Identifier

[0269] TC Traffic Category

[0270] TD Traffic Descriptor

[0271] TDF Traffic Detection Function

[0272] TDF-C Traffic Detection Function Control Plane

[0273] TDF-U Traffic Detection Function User Plane

[0274] TLS Transport Layer Security

[0275] TTL Time To Live

[0276] UDR User Data Repository

[0277] UE User Equipment

[0278] UL Uplink

[0279] UP User Plane

[0280] UPF User Plane Function

[0281] URR Usage Reporting Rule

[0282] URSP UE Route Selection Policy

Claims

CLAIMS1. A method of enabling a controlled flow of user data traffic between a user equipment, UE (200), and a server (400) over 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: obtaining, from a core network node (600), at least one route selection rule associating one or more of the plurality of proxy network nodes (310-390) with at least one user data traffic parameter; and selecting, based on the obtained at least one route selection rule, at least one of the plurality of proxy network nodes (310-390) for routing the user data traffic between the UE (200) and the server (400) over the selected at least one proxy network node.

2. The method of claim 1, wherein 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.

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

4. The method of 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 egress proxy network node and the second proxy network node is an ingress proxy network node.

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

6. The method of claim 5, wherein the first proxy network node is configured as a User Plane Function, UPF, a Packet Gateway User Plane, PGW-U, or a Traffic Detection Function User Plane, TDF-U, of a Core Network, CN.

7. The method of any one of claims 2 to 6, further comprising: obtaining, from the core network node, an identifier of the first proxy network node, anddirecting user data traffic toward the first proxy network node based on the obtained identifier.

8. The method of claim 7, wherein the at least one route selection rule associates one or more second proxy network nodes with at least one user data traffic parameter.

9. The method of claim 7 or 8, further comprising: 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.

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

11. The method of any one of claims 1 to 10, wherein the one or more route selection rules comprise at least one UE Route Selection Policy, URSP.

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

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

14. The method of any one of claims 1 to 13, wherein the selected at least one proxy network node comprises a Multiplexed Application Substrate over QUIC Encryption, MASQUE, proxy network node.

15. The method of 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 an application causing the user data traffic, for example with an identity or type of the application.

16. A user equipment, UE (200), configured to enable a controlled flow of user data traffic between the UE (200) and a server (400) over at least one of a plurality of proxy network nodes (310-390) reachable by the UE (200) via a Radio AccessNetwork, RAN (500), the UE (200) comprising at least one memory (220) and at least one processor (210), the at least one memory (220) storing instructions which, when executed by the at least one processor (210), cause the at least one processor (210) to: obtain, from a core network node (600), at least one route selection rule associating one or more of the plurality of proxy network nodes (310-390) with at least one user data traffic parameter; and select, based on the obtained at least one route selection rule, at least one of the plurality of proxy network nodes (310-390) for routing the user data traffic between the UE (200) and the server (400) over the selected at least one proxy network node.

17. The UE of claim 16, wherein the at least one memory 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 1 to 15.

18. A computer program storing 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 1 to 15.

19. A carrier carrying the computer program of claim 18.

20. A method of enabling a controlled flow of user data traffic between a user equipment, UE (200), and a server (400) over 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: sending a session establishment message to a core network node (600), the session establishment message including an identifier of the first proxy network node (340) to be indicated to the UE (200) via the core network node (600) for configuring the UE (200) to direct user data traffic toward the first proxy network node (340) based on the obtained identifier.

21. The method of claim 20, wherein the session establishment message is a Packet Flow Control Protocol, PFCP, Session Establishment Response message.

22. The method of claim 20 or 21, wherein the plurality of proxy network nodes are configured to form a plurality of chains via which the user data traffic can berouted, each chain comprising the first proxy network node and a second proxy network node of the plurality of proxy network nodes.

23. The method of 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 egress proxy network node and the second proxy network node is an ingress proxy network node.

24. The method of any one of claims 20 to 23, further comprising: obtaining, from the core network node, one or more User Plane, UP, rules assigning identifiers of one or more second proxy network nodes of 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 of 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 of claim 24 or 25, further comprising: performing a header inspection of user data traffic of the UE to obtain an identifier of one of the one or more second proxy network nodes; and performing the traffic management action(s) assigned to the obtained identifier by the one or more UP Rules.

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

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

29. The method of any one of claims 20 to 28, wherein the first proxy network node is a Multiplexed Application Substrate over QUIC Encryption, MASQUE, proxy network node.

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

31. The method of claim 30, wherein the first proxy network node is configured as a User Plane Function, UPF, a Packet Gateway User Plane, PGW-U or a Traffic Detection Function User Plane, TDF-U of a Core Network, CN.

32. A first proxy network node (340) configured to enable a controlled flow of user data traffic between a user equipment, UE (200), and a server (400) over 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 which, when executed by the at least one processor (342), cause the at least one processor (342) to: send a session establishment message to a core network node (600), the session establishment message including an identifier of the first proxy network node (340) to be indicated to the UE (200) via the core network node (600) for configuring the UE (200) to direct user data traffic toward the first proxy network node (340) based on the obtained identifier.

33. The first proxy network node of claim 32, wherein the at least one memory 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.

34. A computer program storing 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 of claim 34.

36. A method of enabling a controlled flow of user data traffic between a user equipment, UE (200), and a server (400) over 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: providing the UE (200) with at least one route selection 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, based on the provided route selection rule(s), at least one of the plurality of proxy network nodes (310-390) for routing the user data traffic between the UE (200) and the server (400) over 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 via which the user data traffic can be routed, each chain comprising a first proxy network node and a second proxy network node of the plurality of proxy network nodes that is to be selected by the LIE.

38. The method of 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 egress proxy network node and the second proxy network node is an ingress proxy network node.

39. The method of claims 37 or 38, further comprising: receiving address information of at least one of the second proxy network nodes, wherein the at least one route selection rule is based on the address information.

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

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

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

43. The method of any one of claims 40 to 42, further comprising: determining the at least one route selection rule based on the binding.

44. The method of claim 43, wherein the at least one route selection rule is determined by a Policy Control Function, PCF, implemented by the core network node.

45. The method of any one of claims 36 to 44, further comprising:receiving a session establishment message from a first proxy network node of the 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 towards the first proxy network node.

46. The method of claim 45, further comprising: receiving a PDU Session Establishment Request message from the UE, wherein the identifier of the first proxy network node is indicated to the UE in response to the PDU Session Establishment Request message.

47. The method of any one of claims 36 to 46, further comprising: determining one or more Policy and Charging Control, PCC, rules for at least one user data traffic parameter.

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

49. The method of any one of claims 37 to 48, further comprising: providing the first proxy network node with one or more User Plane, UP, rules assigning identifiers of one or more second proxy network nodes of 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 of claim 49 and one of claims 47 and 48, further comprising: determining the one or more UP rules based on the one or more PCC rules.

51. The method of claim 50 depending on at least 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 of claim 50 or 51, wherein the one or more UP rules are determined by a Session Management Function, SMF, a Packet Gateway Control Plane, PGW-C, or a Traffic Detection Function Control Plane, TDF-C, implemented by the core network node.

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

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

55. The method of at least claim 37, wherein the first proxy network node and / or the second proxy network node is a Multiplexed Application Substrate over QUIC Encryption, MASQUE, proxy network node.

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

57. The method of claim 56, wherein the first proxy network node is configured as a User Plane Function, UPF, a Packet Gateway User Plane, PGW-U or a Traffic Detection Function User Plane, TDF-U of a Core Network, CN.

58. The method of 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 an application causing the user data traffic, for example with an identity or type of the application.

59. A core network node (600) configured to enable a controlled flow of user data traffic between a user equipment, UE (200), and a server (400) over 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 which, when executed by the at least one processor (610), cause the at least one processor (610) to: provide the UE (200) with at least one route selection 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, based on the provided route selection rule(s), at least one of the plurality of proxy network nodes (310-390) for routing the user data traffic between the UE (200) and the server (400) over the selected at least one proxy network node.

60. The core network node of claim 59, wherein the at least one memory 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.

61. A computer program storing 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 of claim 61.

63. A system (100) comprising at least two of the following entities: the LIE (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