WO2025040267A1

WO2025040267A1 - Methods and apparatus for privacy and network management in a dual proxy deployment network

Info

Publication number: WO2025040267A1
Application number: PCT/EP2023/076567
Authority: WO
Inventors: Marcus IHLAR; Maria Luisa Mas Rosique; Miguel Angel MUÑOZ DE LA TORRE ALONSO
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2023-08-23
Filing date: 2023-09-26
Publication date: 2025-02-27
Anticipated expiration: 2026-02-23

Abstract

A method for privacy management in dual proxy deployment communication networks. The method comprises receiving, by an Application Serve (AS) a trigger for requesting privacy enabling. The method further comprises transmitting, by the AS, an enabling privacy request to an Exposure Function (EF) and authorising, by the EF, the enabling privacy request. The method additionally comprises transmitting, by the EF, privacy instructions to a repository in the dual proxy deployment network.

Description

METHODS AND APPARATUS FOR PRIVACY AND NETWORK MANAGEMENT IN A DUAL PROXY DEPLOYMENT NETWORK

Technical Field

Embodiments of the present disclosure relate to methods and apparatus in communication networks, and particularly methods and apparatus for privacy management in dual proxy deployment communication networks.

Background

Fifth Generation (5G) and Fourth Generation (4G) New Radio (NR) cellular networks (for example 3^rd Generation Partnership Project (3GPP) networks) may use methods of traffic encryption in order to improve the security of the network. Over time, networks and traffic encryption mechanisms have increased in complexity. For example, many applications in 4G and 5G NR cellular networks are based on Hypertext Transfer Protocol Secure (HTTPS) cleartext using Transport Layer Security (TLS) encryption mechanisms. Additionally, traffic may be based on QUIC transport, which has a higher encryption level than TLS. In the future, it is anticipated that the percentage of applications based on QUIC transport will increase.

QUIC is a User Datagram Protocol (UDP) based stream-multiplexed and secure transport protocol with integrity protected headers and encrypted payloads. Unlike the traditional transport protocol stack with Transmission Control Protocol (TCP), which resides in the operating system kernel, QUIC is implemented in the application layer. This may improve flexibility in terms of transport protocol evolution with implementation of new features, congestion control, deploy ability and adoption. Further, compared to HTTPS, encryption in QUIC covers both the transport protocol headers as well as the payload, as opposed to TLS over TCP, e.g. HTTPS, which protects only the payload.

QUIC proxies may provide secure forwarding and performance enhancement services, for example congestion control support (both mobile and/or satellite), access policy enforcement, load balancing/mobility, and/or multi-hop chaining/onion routing. QUIC proxy may optionally also open a tunnel to server (if this is supported by the server). By using QUIC proxy mechanisms, the client and/or server may explicitly contact a proxy (e.g. a QUIC Proxy) in order to expose information between the Content Provider (Application Client and/or Server) and the Mobile Network Operator (e.g. QUIC Proxy at UPF). Figure 1 depicts an overview of a 5G reference architecture comprising a Policy and Charging Control (PCC) framework. The network 101 of Figure 1 includes a Unified Data Repository (UDR) 102. The UDR may store data grouped into distinct collections of subscription-related information. The subscription-related information may comprise: subscription data, policy data, structured data for exposure, and/or application data.

The network 101 of Figure 1 further includes a Network Exposure Function (NEF) 103. The NEF may support different functionalities, such as different Exposure Application Programming Interfaces (APIs). Example APIs include NEF APIs for Quality of Service (QoS) and sponsored data. In some examples, the NEF may be a Packed Flow Description Function (PFDF). The network 101 also may include a Network Data Analytics Function (NWDAF) 104 and an Application Function (AF) 105. The AF interacts with the wider network (e.g. 3GPP Core Network) and allows external parties to use Exposure APIs offered by the network operator.

The network 101 further includes a Policy Control Function (PCF) 106. The PCF may support a unified policy framework to govern the behaviour of the network. For example, the PCF may provide PCC rules to a Policy and Charging Enforcement Function (PCEF). In Figure 1 , the PCEF is implemented as part of the Session Management Function (SMF) 109 and the User Plane Function (UPF) 110. The SMF 109 may support different functionalities, for example by receiving PCC rules from the PCF and configuring the UPF 110 accordingly. The UPF may support the handling of user plane traffic, for example: packet inspection, packet routing and forwarding, traffic usage reporting, and/or QoS handling for the user plane (such as uplink (UL) and/or downlink (DL) rate enforcement). Further, the network 101 of Figure 1 includes a Charging Function (CHF) 107 and Access and Mobility Function (AMF) 108.

Network operators may employ differentiated privacy management across the network. Accordingly, network operators may require application and/or service awareness in order to apply differentiated privacy management actions (for example, the implementation different privacy levels for one or a plurality of UEs and/or applications, and the like). Network operations without such awareness may lack the necessary information to offer differentiated privacy management actions, for example by offering encryption methods such as dual proxy deployments on an optional basis.

Dual proxy deployments are employed by many Mobile Network Operators (MNOs) as a form of private relay. Private relays are a form of internet privacy service built into an internet browser, which ensures all traffic leaving a User Equipment (UE) is encrypted. All user requests are sent through two separate relays. The first relay assigns the user an anonymous Internet Protocol (IP) address, for example that maps to a region associated with the user but not the exact location of the user. The second relay decrypts the web address requested by the user and forwards the user to their requested destination. This separation of information protects the user’s privacy by ensuring no single entity can identify both the identity of the user and the identity of the requested destination. However, dual proxy deployments and other forms of private relay may negatively impact network operation by MNOs by preventing MNOs from accessing application and/or service information.

Accordingly, in order to access relevant application and/or service information and maintain network operation capabilities, MNOs may wish to offer and take part in enhanced privacy such as private relays and dual proxy deployments as part of privacy management. Privacy management may be important for MNOs; MNOs have often built their offerings on the network capability to apply service differentiated charging and policy. MNOs allow for Content Providers and/or users to request different traffic management actions (e.g. QoS and Sponsored data related) through different northbound APIs (Nnef APIs) and a further method in which MNOs may provide differentiated services is to offer varying levels of privacy and encryption of traffic. However, current systems do not provide a mechanism for MNOs to offer this type of enhanced privacy as a service (neither to offer this service to a user or to dynamically control and/or enforce such a service in their network). Accordingly, MNOs may require further mechanisms beyond that presently available in order to apply differentiated privacy management actions.

Summary

It is an object of the present disclosure to facilitate privacy management in dual proxy deployment communication networks.

Embodiments of the disclosure aim to provide apparatuses and methods that alleviate some or all of the problems identified. In particular, embodiments of the disclosure aim to provide methods of privacy management in a dual proxy deployment network which comprise an enabling privacy request; the request may be sent to an AF or Application Server (AS) operated by an MNO, to allow the MNO greater control over the privacy options facilitated by the dual proxy deployment. Accordingly, embodiments of the disclosure aim to provide apparatuses and methods that allow users to request to MNO privacy management actions in dual proxy deployments in a simple and efficient way. Embodiments of the disclosure also aim to facilitate the ability of MNOs to offer subscribers a privacy enhancing feature, for example by hosting in ingress MASQUE Proxy at the MNO (and more specifically, in a UPF) in dual-proxy deployments and by provisioning a UE using network access signalling. The present disclosure provides a first method for privacy management in a dual proxy deployment network. The method comprises receiving, by an Application Server (AS) a trigger for requesting privacy enabling. The method further comprises transmitting, by the AS, an enabling privacy request to an Exposure Function (EF) and authorising, by the EF, the enabling privacy request. The method further comprises transmitting, by the EF, privacy instructions to a repository ingress proxy in the dual proxy deployment network.

The present disclosure further provides a second method for privacy management in a dual proxy deployment network. The method comprises transmitting, by a Network Function (NF), an NF profile update request to a NF Repository Function (NRF) and updating, by the NRF, an NF profile based on the NF profile update request. The NF profile update request comprises an ingress proxy contact information associated with the NF.

The present disclosure further provides a third method for privacy management in a dual proxy deployment network. The method comprises transmitting, by a Session Management Function, (SMF), a Network Function (NF) discovery request to a NF Repository Function (NRF) and authorising, by the NRF, a NF service discovery procedure based on the discovery request. The discovery request comprises an indicator regarding a condition of ingress proxy support.

The present disclosure further provides a first dual proxy deployment network. The network comprises an Application Server (AS), the AS comprising processing circuitry and a non- transitory machine-readable medium storing instructions. The network further comprises an Exposure Function (EF), the EF comprising processing circuitry and a non-transitory machine- readable medium storing instructions. The network further comprises a repository, the repository comprising processing circuitry and a non-transitory machine-readable medium storing instructions. The AS is configured to receive a trigger for requesting privacy enabling and transmit an enabling privacy request to the EF. The EF is configured to authorise the enabling privacy request and transmit privacy instructions to the repository.

The present disclosure further provides a second dual proxy deployment network. The network comprises a Network Function (NF), the NF comprising processing circuitry and a non- transitory machine-readable medium storing instructions. The network further comprises a NF Repository Function (NRF), the NRF comprising processing circuitry and a non-transitory machine-readable medium storing instructions. The NF is configured to transmit an NF profile update request to the NRF. The NRF is configured to update an NF profile based on the NF profile update request. The NF profile update request comprises an ingress proxy contact information associated with the NF.

The present disclosure further provides a third dual proxy deployment network. The dual proxy deployment network comprises a Session Management Function (SMF), the SMF comprising processing circuitry and a non-transitory machine-readable medium storing instructions. The network further comprises Network Function Repository Function (NRF), the NRF comprising processing circuitry and a non-transitory machine-readable medium storing instructions. The SMF is configured to transmit a Network Function (NF) discovery request to the NRF. The NRF is configured to authorise a NF service discovery procedure based on the discovery request.

The discovery request comprises an indicator regarding a condition of ingress proxy support.

Brief Description of Drawings

For a better understanding of the present disclosure, and to show how it may be put into effect, reference will now be made, by way of example only, to the accompanying drawings, in which:

Figure 1 is a diagram of a 5G reference architecture;

Figure 2 is a diagram of a dual proxy system in accordance with embodiments;

Figure 3 is a flowchart of a method of privacy management, in accordance with embodiments;

Figure 4 is a flowchart of a Network Function (NF) profile update procedure, in accordance with embodiments;

Figure 5 is a flowchart of a NF discovery procedure, in accordance with embodiments;

Figure 6 is a sequence diagram of a method of privacy management, in accordance with embodiments;

Figure 7 is a sequence diagram of a further method of privacy management, in accordance with embodiments;

Figure 8 is a sequence diagram of a NF profile update procedure, in accordance with embodiments;

Figure 9 is a sequence diagram of a NF discovery procedure, in accordance with embodiments; and

Figure 10A, Figure 10B, Figure 10C, and Figure 10D (collectively referred to as Figure 10) are a sequence diagram of a dual proxy deployment method, in accordance with embodiments. Detailed Description

The following sets forth specific details, such as particular embodiments for purposes of explanation and not limitation. It will be appreciated by one skilled in the art that other embodiments may be employed apart from these specific details. In some instances, detailed descriptions of well-known methods, nodes, interfaces, circuits, and devices are omitted so as to not obscure the description with unnecessary detail. Those skilled in the art will appreciate that the functions described may be implemented in one or more nodes using hardware circuitry (e.g., analog and/or discrete logic gates interconnected to perform a specialized function, ASICs, PLAs, etc.) and/or using software programs and data in conjunction with one or more digital microprocessors or general purpose computers that are specially adapted to carry out the processing disclosed herein, based on the execution of such programs. Nodes that communicate using the air interface also have suitable radio communications circuitry. Moreover, the technology can additionally be considered to be embodied entirely within any form of computer-readable memory, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.

Hardware implementation may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analog) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and/or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions. In terms of computer implementation, a computer is generally understood to comprise one or more processors, one or more processing modules or one or more controllers, and the terms computer, processor, processing module and controller may be employed interchangeably. When provided by a computer, processor, or controller, the functions may be provided by a single dedicated computer or processor or controller, by a single shared computer or processor or controller, or by a plurality of individual computers or processors or controllers, some of which may be shared or distributed. Moreover, the term “processor” or “controller” also refers to other hardware capable of performing such functions and/or executing software, such as the example hardware recited above.

Figure 2 depicts a private relay or dual proxy system 200 suitable for implementing methods in accordance with embodiments. The private relay of Figure 2 comprises a UE 201 , an ingress proxy 202, an egress proxy 203, and an Application Server (AS) 204. The ingress proxy 202 may assign the user an anonymous IP address (for example, which maps to their region but not their actual location) and thus may have visibility of the user IP address. The egress proxy 203 may decrypt the web address the user wants to visit and forward the user to their requested destination and thus may have visibility of the user traffic destination.

One type of dual proxy deployment is a Multiplexed Application Substrate over QIIIC Encryption (MASQUE) connection. MASQUE refers to a collection of mechanisms that allow configuring and concurrently running multiple proxied stream- and datagram-based flows inside a HTTPS connection. Through a MASQUE connection, an application may create a secure connection to an on-path network proxy and may establish a secure end-to-end connection to one or more server(s) via the proxy. Application data may then be secured end- to-end and protected from unauthorised use in the network. The content provider and/or Mobile Network Operator (MNO) may have a secure channel to exchange information regarding the application and any policies thereof in real time. For a MASQUE connection, the application client may explicitly open a QUIC tunnel connection to a proxy and request forwarding. For example, the client may use a HTTP CONNECT-like protocol and/or a custom protocol to request and/or negotiate forwarding, authentication, and/or configuration of the application/policies. Further details of such a method are provided below.

For a Multiplexed Application Substrate over QUIC Encryption (MASQUE) based dual-proxy deployment, the ingress proxy may be referred to as the first MASQUE proxy and the egress proxy may be referred to as the second MASQUE proxy. As detailed above, MASQUE mechanisms allow for the configuring and concurrently running multiple proxied stream- and datagram-based flows inside an HTTPS connection.

In general, a proxy is an intermediary program acting as both server and client, creating or simply relaying requests on behalf of other entities. Requests are serviced internally or by passing them on, with possible translation, to other servers. There are several types of proxies, including transparent proxies, non-transparent proxies, reverse proxies and Performance Enhancement Proxies (PEP).

A transparent proxy is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification. 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. A reverse proxy is a proxy that pretends to be the actual server as far as any client or client proxy is concerned, and additionally passes on the request to the actual server (that may, for example, sit behind another layer of firewalls). A 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 private relay or dual proxy system of Figure 2, the ingress proxy 202 may be any one of a transparent proxy, a non-transparent proxy, a reverse proxy, or a PEP. Further, the egress proxy 203 may be any one of a transparent proxy, a non-transparent proxy, a reverse proxy, or a PEP.

Figure 3 is a flowchart of a method S300 of privacy management in a dual proxy deployment communication network, in accordance with embodiments. As shown in Step S302 of Figure 3, the method may comprise receiving a trigger for requesting privacy enabling by an Application Server (AS). In order to undertake the steps of Figure 3, specific examples of the method may comprise further steps as shown in Figure 6 and Figure 7.

For example, as shown in Figure 6 and Figure 7, the method may comprise starting, by a UE, an application as shown in Step 1 of Figure 6 and Figure 7. Specific examples may further comprise transmitting, from the UE, the trigger for requesting privacy enabling to the AS as shown in Step 2 of Figure 6 and Figure 7. The application may, for example, be started by an end user or subscriber, and the application may be any of an MNO security application or a security application owned by an external company acting as a third party to the network. In accordance with the above, the trigger may be triggered at an application level, for example between the application client and the application server, in order to configure privacy as requested by the end user or subscriber. The trigger transmitted by the UE may comprise an enabling privacy request. In specific examples, the enabling privacy request may be an Enable Privacy Request message.

In specific examples, the trigger for requesting privacy enabling may comprise one or more of the following: a Subscription Permanent Identifier (SUPI) for a UE for which privacy enabling is requested; a list of Application Identifications (App-IDs) for one or more applications for which privacy enabling is requested; a Data Network Name (DNN) for a Protocol Data Unit, (PDU) Session to which the trigger applies; a Serving - Network Slice Selection Assistance Information (S-NSSAI) for a PDU Session to which the trigger applies; and/or a filter to indicate a PDU Session to which the trigger applies.

In further specific examples, the list of App-IDs may be set to “Any” in which case the target applications are considered to be all applications. That is, in the case that the list of App-IDs may be set to “Any” the target for the request is all the traffic in the target user PDU session. In such a specific example where the end user has indicated no specific preference for the application(s) for which the enhanced privacy applies, the list of App-IDs sent in the Enable Privacy Request message can be the one locally configured in the UE, or an indicator indicating no preference can be sent in the Enable Privacy Request message.

In specific examples, the method may comprise transmitting, by the AS, a response message to the UE indicating the trigger for requesting privacy enabling has been received. This is shown, for example, in Step 3 of Figure 6 and Figure 7.

The method may further comprise transmitting an enabling privacy request from the AS to an Exposure Function (EF), as shown in Step S304 of Figure 3. The EF may be one of: a Network Exposure Function (NEF) and a Business Support System (BSS). Figure 6 is a sequence diagram depicting a specific example of a method comprising an NEF, and Step 5 of Figure 6 depicts the step of transmitting an enabling privacy request from the AS to the NEF. Figure 7 is a sequence diagram depicting a specific example comprising a BSS, and Step 5 of Figure 7 depicts the step of transmitting an enabling privacy request from the AS to the BSS.

In specific embodiments, transmitting the enabling privacy request from the AS to the EF may further comprise transmitting the enabling privacy request via an Application Function, AF. This is shown, for example, in Step 4 of Figure 6 and Figure 7. In specific examples, transmitting the enabling privacy request from the AS to the EF further comprises: transmitting, by the AS, the trigger for requesting privacy enabling to AF; generating, by the AF, the enabling privacy request; and transmitting, by the AF, the enabling privacy request to the EF.

The AF may accordingly be configured to trigger a request to an MNO (for example, through an NEF or BSS) to fulfil the request sent by the UE. This request can then be approved, giving the MNO the ability to offer enhanced privacy settings and improving MNO control over the privacy settings offered to users.

The AS and/or AF may define a new Nnef API or service, EnablePrivacy, in order to facilitate the above transmissions. Accordingly, the enabling privacy request or Enable Privacy Request message may comprise a Nnef_EnablePrivacy request message. The AF or AS may accordingly transmit and/or generate a Nnef_EnablePrivacy request message in accordance with the discussion above.

The enabling privacy request or Enable Privacy Request message may comprise one or more of the following: an identifier for the AS; an identifier for the AF; a SUPI for a UE for which privacy enabling is requested; a list of App-IDs for one or more applications for which privacy enabling is requested; a DNN for a PDU Session to which the trigger applies; and/or a S- NSSAI for a PDU Session to which the trigger applies. In a specific example, the list of App- IDs may be set to “Any” in which case the target applications are considered to be all applications. That is, in the case that the list of App-IDs may be set to “Any” the target for the request is all the traffic in the target user session. In such a specific example where the end user has indicated no specific preference for the application(s) for which the enhanced privacy applies, the list of App-IDs sent in the Enable Privacy Request message can be the one locally configured in the UE, or an indicator indicating no preference can be included in the Enable Privacy Request message.

As shown in Figure 3, the method S300 may further comprise authorising the enabling privacy request by the EF as shown in Step S306. As shown in Step 6 of Figure 6, the EF may be an NEF and the method may comprise authorising the enabling privacy request by the NEF. Alternatively, as shown in Step 6 of Figure 7, the EF may be a BSS and the method may comprise authorising the enabling privacy request by the BSS.

In a specific example where the user has indicated no preference for the applications to which the request applies (e.g. list of App-IDs is set to “Any”) , the EF may use a list of applications locally configured by the MNO in order to authorise the request. Alternatively or additionally, the EF may override the list of applications provided by the UE, for example if the list of applications includes applications that are not managed by the EF or for which enhanced privacy is not available.

In specific examples, the method may further comprise transmitting, from the EF, a response message to the AS indicating the enabling privacy request has been authorised. This is shown, for example in Step 7 of Figure 6 and Figure 7.

The method may additionally comprise transmitting privacy instructions to a repository by the EF, as shown in Step S308 of Figure 3. The method may further comprise storing, by the repository, the privacy instructions as subscription data. A specific example of this step is shown in Step 8 and Step 10 of Figure 6 and Figure 7. Step 8 of Figure 6 and Figure 7 shows the EF (for example, NEF or BSS) storing the request received from the AS/AF, for example detailing the authorisation of the enabling privacy request. The EF may then transmit a request to the repository (e.g. Nudr_DM Request), to request that the repository stores the privacy instructions as subscription data, as shown in Step 9 of Figure 6 and Figure 7. The repository may then store the EF request, as shown in Step 10 of Figure 6 and Figure 7. Optionally, the method may further comprise transmitting, from the repository, a response message to the EF indicating the privacy instructions have been received as shown in Step 11 of Figure 6 and Figure 7.

In specific examples, the subscription data may comprise one or more of the following: a SlIPI for a UE for which privacy enabling is requested; a list of App-IDs for one or more applications for which privacy enabling is requested; a DNN for a PDU Session to which the trigger applies; a S-NSSAI for a PDU Session to which the trigger applies; and/or an indication to enable enhanced privacy and/or dual proxy deployment. In a further specific example, where the list of App-IDs is set to “Any”, the subscription data may refer to the whole traffic in the user session.

For the avoidance of doubt, Figure 6 and Figure 7 are sequence diagrams depicting the same mechanism for facilitating configurable enhanced privacy settings in a dual proxy deployment network. The systems of Figure 6 and Figure 7 include a UE, a repository, and a AS. The repository may be a Unified Data Repository (UDR) as shown in Figure 6 and Figure 7. Figure 6 additionally comprises an AF. A difference between Figure 6 and Figure 7 is that in the network of Figure 6 the AF and/or AS (which may be operated by an MNO and may further operate as the MNO’s user portal) communicates with an NEF to provision the information in the above requests. In contrast, in the network of Figure 7 the AF/AS (which is specifically depicted as being operated by an MNO) communicates with a BSS to provision the information in the above requests.

In additional examples, the method may comprise initiating, by an ingress proxy and an egress proxy, dual proxy deployment based on the privacy instructions. Further details of how such a dual proxy deployment may be initiated are provided below with reference to Figure 10.

Figure 4 is a flowchart of a method S400 of NF profile update procedure, in accordance with embodiments. As shown in Step S402 of Figure 4, the method may comprise transmitting, by a NF, an NF profile update request to a NF Repository Function (NRF). The method may further comprise, as shown in Step S404 of Figure 4, updating an NF profile based on the NF profile update request by the NRF. The NF profile update request may comprise an ingress proxy contact information associated with the NF. The NF may be a User Plane Function (UPF).

A specific example of an NF profile update procedure in accordance with embodiments is shown in Figure 8. As shown in Figure 8, the NF may be a NF Service Consumer. The NF Service Consumer may transmit a Nnrf_NFManagement_NFRegister_request and/or Nnrf_NFManagement_NFUpdate_request transmission to the NRF, as shown in Step 1 of Figure 8. The transmitted request may comprise UPF information (UPFInfo), and the UPFInfo may further comprise ingress proxy contact information. As shown in Step 2 of Figure 8, the NRF may then store and/or update the NF profile at the NRF. The NRF may then transmit a Nnrf_NFManagement_NFRegister_response transmission and/or a

Nnrf_NFManagement_NFUpdate_response transmission to the NF Service Consumer, in order to confirm that the NF profile has been registered/updated.

Figure 5 is a flowchart of a NF discovery procedure S500, in accordance with embodiments. As shown in Step S502 of Figure 5, the method may comprise transmitting, by a Session Management Function (SMF) a NF discovery request to a NRF. As shown in Step S504 of Figure 5, the method may further comprise authorising, by the NRF, a NF service discovery procedure based on the discovery request. The discovery request may comprise an indicator regarding a condition of ingress proxy support. The NF discovery request may be a User Plane Function (UPF) discovery request.

A specific example of a NF discovery procedure in accordance with embodiments is shown in Figure 9. As shown in Figure 9, the NF may be a NF Service Consumer. The NF Service Consumer may transmit a Nnrf_NFDiscovery_Request to the NRF, as shown in Step 1 of Figure 9. The Nnrf_NFDiscovery_Request may include UPFInfo, and the UPFInfo may further include ingress proxy support and/or an indicator regarding a condition of ingress proxy support. The NRF may then authorise a NF Service Discovery procedure, as shown in Step 2 of Figure 9. As shown in Step 3 of Figure 9, the NRF may transmit a Nnrf_NFDiscovery_Request response to the NF Service Consumer, in order to confirm that the NF Service Discovery procedure has been authorised.

Accordingly, present methods may be implemented in a system comprising an SMF, NRF, and UPF. For deployments where the SMF selects the UPF using an NRF, the UPF profile in the NRF may be extended such that when the UPF supports MASQUE ingress proxy it includes in the UPF profile the ingress MASQUE proxy contact information. For example, the UPF profile may be extended to include an ingress MASQUE proxy IP address. Alternatively or additionally, ingress MASQUE proxy support may be set as a condition in the UPF discovery procedure and/or may be considered by the SMF in UPF selection.

Figure 10 is a sequence diagram for a method of implementing a dual proxy deployment in accordance with present examples. As detailed above, the method may comprise initiating, by an ingress proxy and an egress proxy, dual proxy deployment based on the privacy instructions. In order to undertake this step, the method may comprise further steps as shown in Figure 10.

As part of the method of Figure 10, a user request for enhanced privacy features has been provisioned through an EF (for example, an NEF or BSS) as described above. For example, a user request for enhanced privacy features has been provisioned through an EF using a method as shown in any of Figures 3, Figure 6, and/or Figure 7. Accordingly, a Service-Level Agreement (SLA) may be present between the parties involved in the dual-proxy deployment/private relay deployment. The parties may include a UE Operating System (OS) vendor, and/or a MNO providing the ingress MASQUE proxy in the dual-proxy deployment. Optionally, and as shown in Figure 10, the OS vendor may have an agreement with an egress MASQUE proxy provider and may additionally have settings and corresponding contact information. Alternatively, the OS vendor may operate the egress MASQUE proxy themselves. Further, at the vendor’s network, an enhanced privacy feature may be enabled on a persubscribed basis as detailed above with reference to Figure 3, Figure 6, and Figure 7.

The method of Figure 10 is implemented on a system comprising: a UE, an AMF, a first function acting as an ingress MASQUE proxy, a second function, a Policy Function (PF), a repository, an egress proxy, and an AS. In specific embodiments, the first function may be a UPF and/or the second function may be an SMF. Alternatively or additionally, the repository may be a UDR and/or the PF may be a Policy Control Function (PCF). However, the method of Figure 10 may be implemented in any suitable dual-proxy deployment system as discussed for example with reference to Figure 1 and Figure 2.

In embodiments, the method may comprise performing a Packet Flow Control Protocol (PFCP) association setup procedure. In order to do this, as shown in Step 1 of Figure 10, the UPF may report its capability to act as an ingress MASQUE proxy for dual-proxy deployment to the SMF. This report may comprise MASQUE proxy contact information, for example contact information associated with the UPF. The SMF may transmit a response message to the UPF, as shown in Step 2 of Figure 10, to indicate that the contact information has been successfully received.

The method may further comprise triggering by a UE a Protocol Data Unit (PDU) Session Establishment procedure. It will be appreciated by one skilled in the art that messages beyond what are described herein may be included in the method, and that only the messages relevant to the specific purpose of traffic management in the communication network will be described in detail. In a more specific embodiment, the method may comprise transmitting by the UE a PDU Session Establishment request to an Access and Mobility Function (AMF), as shown in Step 3 of Figure 10. The UE may indicate in the request support for using MNO provided MASQUE proxies.

The method may further comprise transmitting by the AMF a first request message to the second function, as shown in Step 4 of Figure 10. As shown in the example of Figure 4, the first request message may be a Nsmf PDU Session Create message or more specifically a Nsmf_PDUSession_CreateSMContext Request message and the second function may be a Session Management Function (SMF).

The method may further comprise transmitting by the second function a second request message to the PF, as shown in Step 5 of Figure 10. As shown in the example of Figure 10, the second request message may be a Npcf_SMPolicyControl_Create request message, the second function may be a SMF and the PF may be a Policy Control Function (PCF).

The method may further comprise transmitting by the AMF a third request message to a Policy Function (PF), as shown in Step 6 of Figure 10. As shown in the example of Figure 10, the third request message may be a Npcf_AMPolicyControl_Create Request message and the PF may be a Policy Control Function (PCF). Accordingly, the third request message may create an AM policy association for the user PDU session. The third request message may include a SUPI, DNN, and/or S-NSSAI for the user PDU session.

The method may further comprise transmitting by the PF or PCF a query message or Nudr_Query request message to the repository, as shown in Step 7 of Figure 10. The repository may be a UDR. The query message may be to retrieve the policy data for the PDU session associated with the user. The policy data may include subscriber policy data such as a SUPI, DNN, and/or S-NSSAI associated with the PDU session. The repository or UDR may then send a query response message to the PF, as shown in Step 8 of Figure 10. The query response message may include the subscriber policy data associated with the PDU session. Additionally or alternatively, the query response message may comprise one or more of: an indication to enable enhanced privacy, and a list of App-IDs which indicates the list of applications to which enhanced privacy applies.

The method may additionally comprise PCC rules generating by the PF using the dual proxy rules (as shown in Step 9 of Figure 10), and transmitting the PCC rules to a second function by the PF (as shown in Step 10 of Figure 10). As shown in the example of Figure 10, the second function may be a SMF and the PF may be a PCF. Accordingly, as shown in Figure 10, embodiments may include steps in which a PCF generates PCC rules including dual proxy rules, for example based on the subscriber policy data. As shown in Figure 10, the PCF may generate the corresponding PCC rule(s) based on subscriber policy data by triggering a Npcf_SMPolicyControl_Create Response towards the SMF. The response may include one or more of the following information: an indication to enable enhanced privacy, and/or a list of App-IDs which indicates the list of applications to which enhanced privacy applies.

As shown in Step 11 of Figure 10, the second function (which may be an SMF) may select an ingress MASQUE proxy. For example, the second function may select a NF (and in more specific embodiments a UPF) that can act as an ingress MASQUE proxy in dual-proxy deployment. This selection may be performed as described with reference to Figures 5 and 9 above. Accordingly, when performing the selection process the second function may perform a consideration as to whether the NF can act as an ingress MASQUE proxy in dual-proxy deployment. Alternatively or additionally, the second function may select the NF or UPF based on the information received during the PFCP association setup (Step 1 and Step 2 of Figure 10).

As shown in Step 12 of Figure 10, the method may comprise transmitting by the second function a Packet Flow Control Protocol (PFCP) Session Establishment procedure trigger to the first function. As shown in Figure 10, the first function may be a User Plane Function (UPF) and may more specifically be a MASQUE ingress proxy. The second function may be a SMF. Accordingly, as shown in Figure 4, embodiments may include steps in which the network SMF triggers a PFCP Session Establishment procedure towards the network UPF. Specifically, the SMF may trigger a PFCP Session Establishment Request message to the UPF, with the message comprising an indication to enable the MNO ingress MASQUE proxy. The PFCP Session Establishment Request message may alternatively or additionally comprise the subscriber policy data. Accordingly, the message may indicate to the first function or UPF (which is acting as an ingress proxy in the dual-proxy deployment) to enable the ingress MASQUE proxy for the PFCP session. The method may further comprise the first function or UPF enabling MNO Proxy (that is, the first function/UPF enabling the function of acting as an ingress MASQUE proxy in the dual-proxy deployment) for the PDU session as shown in Step 13 of Figure 10.

Additionally, the method may include transmitting by the first function a PFCP Session Establishment Response to the second function (as shown in Step 14 of Figure 10). As shown in Figure 10, the first function may be a UPF and/or be a MASQUE ingress proxy. The second function may be a SMF. Accordingly, the first function may acknowledge the request received from the second function by triggering a PFCP Session Establishment Response towards the second function. The response message may include ingress MASQUE proxy contact information, for example a MASQUE proxy IP address. Alternatively or additionally, the ingress MASQUE proxy contact information may be provided as part of the PFCP Association procedure, as this parameter may not be PDU session specific.

As shown in Step 15 of Figure 10, the second function may transmit subscriber policy data to the UE. The second function may be an SMF. The subscriber policy data may comprise one or more of the following: an indication to enable privacy, ingress MASQUE proxy contact information, and/or a list of App-ID(s). The ingress MASQUE proxy contact information may comprise an ingress MASQUE proxy address. The list of App-ID(s) may instruct the UE as to how to differentiate the traffic going over the MASQUE connection from the remaining traffic. The App-IDs may be provided in terms understood by the OS of the UE (for example, different identifiers may be used for a UE OS using Android or a UE OS using iOS).

As shown in Figure 10, the second function may transmit subscriber policy data to the UE via the AMF. That is, as shown in Step 16 of Figure 10, the second function may send a Nsmf PDU Session Create Response message to the AMF, the message comprising the subscriber policy data. The AMF m ay then send a PDU Session Establishment Response message to the UE comprising the subscriber policy data, as shown in Step 17 of Figure 10. Any of the messages of Step 15, Step 16, and/or Step 17 of Figure 10 may be transmitted using Non- Access Stratum (NAS) signalling, by extending the Extended Protocol Configuration Option (ePCO) field. The UE may then store the received subscriber policy data, as shown in Step 18 of Figure 10.

In specific embodiments, the method may comprise opening an application at the UE through dual-proxy deployment (as shown in Step 19 of Figure 10). The application may be included in the list of App-IDs forming a part of the subscriber policy data, as detailed above. Accordingly, where the subscriber policy data indicates that dual-proxy deployment has been enabled for the application that has been opened, the UE may further enable dual-proxy deployment for the application traffic.

By way of example, in response to the UE opening the application the UE may send a HTTP CONNECT message to the first function (or UPF, as detailed above) as shown in Step 20 of Figure 10. The HTTP CONNECT message may include the one or more of the following information:

• protocol=connect-udp

• :scheme=https

• :path=/egressproxyinstance.com/443/

• stream I d=0

The first function (or more specifically, UPF) acting as the MNO ingress MASQUE proxy may then authorise the request received from the UE, as shown in Step 21 of Figure 10. For example, the first function may check for an indication to enable enhanced privacy associated with the specific UE and/or application (for example, a locally stored indication in accordance with stored subscriber policy data) and authorise the request if such an indication is found. The first function may then transmit a confirmation or response to the UE, as shown in Step 22 of Figure 10 indicating the request has been authorised (for example, by including :status=200).

As shown in Step 23 of Figure 10, the method may further comprise the UE triggering a REGISTER DATAGRAM message towards the first function acting as the ingress MASQUE proxy (and more specifically acting as the MNO ingress MASQUE proxy). The REGISTER DATAGRAM message may indicate the stream identification (stream-id); for the specific example of Figure 10, this is shown as streamlD=0.

The UE may then further perform a CONNECT request to the egress proxy through the tunnel of the ingress MASQUE proxy connection, as shown in Step 24 and Step 25 of Figure 10. That is, as shown in Step 24 of Figure 10, the UE may send a CONNECT request to the ingress MASQUE proxy or first function. The ingress MASQUE proxy/first function may then forward the CONNECT request to the egress proxy, as shown in Step 25 of Figure 10. The CONNECT request may be a HTTP CONNECT message. Additionally or alternatively, the CONNECT message may include one or more of the following information: :protocol=connect-udp; :scheme=https; :path=/example.com/443/ (which may service to indicate the target host or Application Server); :authority=examplecdn.com (which may serve to indicate the domain of the second proxy); and/or streamld=0. Accordingly, in Step 25 of Figure 10 the egress MASQUE proxy may receive the CONNECT message and resolve the domain in the path header to identify the target AS. The egress MASQUE proxy may then return a status 200 to the UE, as depicted in Step 26 of Figure 10.

In specific embodiments, the UE may then transmit or trigger a REGISTER DATAGRAM message towards the egress MASQUE proxy indicating the stream-ID (for example, streamlD=O) as shown in Step 27 of Figure 10. The UE may additionally transmit a HTTP3 DATAGRAM to the AS, such that end-to-end data is relayed via the ingress MASQUE proxy (hosted by the first function) to the egress MASQUE proxy and onwards to the target AS. Accordingly, the MNO operating the network may not be able to access information regarding the target application, and the provider of the egress MASQUE proxy and target AS may not be able to access information regarding the subscriber/UE address.

For completeness, the above specific examples present the list of App-ID(s) being transmitted from UE to MNO and back to UE. However, the list of App-ID(s) may be specifically transmitted from the UE application layer (e.g. a security related app or MNO- operated app) to the MNO (e.g. from EF to repository to PF to second function to AMF, as detailed above, that is, using exposure APIs on the left side and using network access signalling on the right side) and then transmitted back to the UE modem or OS layer, where the MASQUE client resides.

Further, in the examples presented above the MNO may not alter the list of App-IDs. However, in alternative examples the MNO may alter the list of App-IDs, for example based on MNO local policies. For example, in Step 8 of the method presented in Figure 10, the UDR may respond to the PCF with a list of applications which is based on a MNO local configuration, rather than that provisioned by the UE during the a user request for enhanced privacy features being provisioned through an EF (as detailed for example in Figure 3, Figure 6, and Figure 7).

The examples discussed above aim to provide a mechanism which is based on a collaborative solution for improving privacy in a network between MNOs and OS vendors (for example, in a network where there is an egress MASQUE proxy provider under agreement with an OS vendor or the MNO). Furthermore, present examples facilitates MNOs offering a privacy enhancing feature which is fully controlled by the subscriber through network exposure APIs. This privacy enhancing feature is executed by OS, based on information provided by MNO using network access signaling, and by the network which is hosting the Ingress MASQUE Proxy at MNO (for example, through a UPF) as part of dual-proxy deployments.

Accordingly, examples presented herein allow network operators (e.g. MNOs) to create a new subscription type with enhanced privacy (which may be fully controlled by the subscriber or partially controlled by the subscriber and partially controlled by the MNO). This MNO to obtain a new potential revenue stream and protect network operation. Accordingly, because MASQUE enhanced privacy may impact performance negatively, present examples provide improved control to the user by providing a mechanism for the user to decide whether they opt for performance or privacy for specific traffic. The user may then decide which traffic undergoes enhanced privacy and which traffic does not. It should additionally be noted that present examples are fully compliant with Net Neutrality.

It will be understood that the detailed examples outlined above are merely examples. According to embodiments herein, the steps may be presented in a different order to that described herein. Furthermore, additional steps may be incorporated in the method that are not explicitly recited above. For the avoidance of doubt, the scope of protection is defined by the claims.

Claims

1 . A method (S300) for privacy management in a dual proxy deployment network, the method comprising: receiving (S302), by an Application Server, AS, a trigger for requesting privacy enabling; transmitting (S304), by the AS, an enabling privacy request to an Exposure Function, EF; authorising (S306), by the EF, the enabling privacy request; and transmitting (S308), by the EF, privacy instructions to a repository.

2. The method (S300) of Claim 1 , wherein the method further comprises: initiating, by an ingress proxy and an egress proxy, dual proxy deployment based on the privacy instructions.

3. The method (S300) of any preceding claim, wherein the method further comprises: starting, by a user equipment, UE, an application, and transmitting, from the UE, the trigger for requesting privacy enabling to the AS.

4. The method (S300) of any preceding claim, wherein the method further comprises: transmitting, by the AS, a response message to the UE indicating the trigger for requesting privacy enabling has been received.

5. The method (S300) of any preceding claim, wherein the trigger for requesting privacy enabling comprises one or more of: a Subscription Permanent Identifier, SUPI, for a UE for which privacy enabling is requested; a list of Application Identifications, App-IDs, for one or more applications for which privacy enabling is requested; a Data Network Name, DNN, for a Protocol Data Unit, PDU, Session to which the trigger applies; a Serving - Network Slice Selection Assistance Information, S-NSSAI, for a PDU Session to which the trigger applies; and/or a filter to indicate a PDU Session to which the trigger applies.

6. The method (S300) as claimed in any preceding claim, wherein the method further comprises: transmitting, from the EF, a response message to the AS indicating the enabling privacy request has been authorised.

7. The method (S300) as claimed in any preceding claim, wherein the method further comprises: storing, by the repository, the privacy instructions as subscription data.

8. The method (S300) of Claim 7, wherein the subscription data comprises one or more of: a SUPI for a UE for which privacy enabling is requested; a list of App-IDs for one or more applications for which privacy enabling is requested; a DNN for a PDU Session to which the trigger applies; a S-NSSAI for a PDU Session to which the trigger applies; and/or an indication to enable dual proxy deployment.

9. The method (S300) as claimed in any preceding claim, wherein the method further comprises: transmitting, from the repository, a response message to the EF indicating the privacy instructions have been received.

10. The method (S300) as claimed in any preceding claim, wherein the method further comprises: transmitting, by the AS, the trigger for requesting privacy enabling to an Application Function, AF; generating, by the AF, the enabling privacy request; and transmitting, by the AF, the enabling privacy request to the EF.

11. The method (S300) as claimed in any preceding claim, wherein the enabling privacy request comprises one or more of: an identifier for the AS; an identifier for the AF; a SUPI for a UE for which privacy enabling is requested; a list of App-IDs for one or more applications for which privacy enabling is requested; a DNN for a PDU Session to which the trigger applies; and/or a S-NSSAI for a PDU Session to which the trigger applies.

12. The method (S300) as claimed in any preceding claim, wherein repository is a Unified Data Repository, UDR, and the EF is one of: a Network Exposure Function, NEF, and a Business Support System, BSS.

13. A method (S400) for privacy management in a dual proxy deployment network, the method comprising: transmitting (S402), by a Network Function, NF, an NF profile update request to a NF Repository Function, NRF; and updating (S404), by the NRF, an NF profile based on the NF profile update request; wherein the NF profile update request comprises an ingress proxy contact information associated with the NF.

14. The method (S400) of Claim 13, wherein the NF is a User Plane Function, UPF.

15. A method (S500) for privacy management in a dual proxy deployment network, the method comprising: transmitting (S502), by a Session Management Function, SMF, a Network Function, NF, discovery request to a NF Repository Function, NRF; and authorising (S504), by the NRF, a NF service discovery procedure based on the discovery request; wherein the discovery request comprises an indicator regarding a condition of ingress proxy support.

16. The method (S500) of Claim 15, wherein the NF discovery request is a User Plane Function, UPF, discovery request.

17. A method for privacy management in a dual proxy deployment network, the method comprising at least one of: the steps of any of claims 1 to 12 (S300); the steps of any of claims 13 and 14 (S400); and the steps of any of claims 15 and 16 (S500).

18. A dual proxy deployment network (200), the network comprising: an Application Server (204), AS, the AS comprising processing circuitry and a non-transitory machine-readable medium storing instructions; an Exposure Function, EF, the EF comprising processing circuitry and a non-transitory machine-readable medium storing instructions; and a repository, the repository comprising processing circuitry and a non-transitory machine-readable medium storing instructions; wherein the AS is configured to receive a trigger for requesting privacy enabling (S302) and transmit an enabling privacy request to the EF (S304); and wherein the EF is configured to authorise the enabling privacy request (S306) and transmit privacy instructions to the repository (S308).

19. The dual proxy deployment network (200) of Claim 18, wherein the network further comprises: an ingress proxy (202) comprising processing circuitry and a non-transitory machine-readable medium storing instructions; and an egress proxy (204) comprising processing circuitry and a non-transitory machine-readable medium storing instructions; and wherein the ingress proxy and the egress proxy are configured to implement dual proxy deployment based on the privacy instructions

20. The dual proxy deployment network (200) of any of Claims 18 or 19, wherein the network further comprises a User Equipment (201), UE, and wherein the UE is configured to: start an application, and transmit the trigger for requesting privacy enabling to the AS.

21. The dual proxy deployment network (200) of any of Claims 18 to 20, wherein the AS is further configured to transmit a response message to the UE indicating the trigger for requesting privacy enabling has been received.

22. The dual proxy deployment network (200) of any of Claims 18 to 21 , wherein the trigger for requesting privacy enabling comprises one or more of: a Subscription Permanent Identifier, SUPI, for a UE for which privacy enabling is requested; a list of Application Identifications, App-IDs, for one or more applications for which privacy enabling is requested; a Data Network Name, DNN, for a Protocol Data Unit, PDU, Session to which the trigger applies; a Serving - Network Slice Selection Assistance Information, S-NSSAI, for a PDU Session to which the trigger applies; and/or a filter to indicate a PDU Session to which the trigger applies.

23. The dual proxy deployment network (200) of any of Claims 18 to 22, wherein the EF is further configured to transmit a response message to the AS indicating the enabling privacy request has been authorised.

24. The dual proxy deployment network (200) of any of Claims 18 to 23, wherein the repository is configured to store the privacy instructions as subscription data.

25. The dual proxy deployment network (200) of Claim 24, wherein the subscription data comprises one or more of: a SUPI for a UE for which privacy enabling is requested; a list of App-IDs for one or more applications for which privacy enabling is requested; a DNN for a PDU Session to which the trigger applies; a S-NSSAI for a PDU Session to which the trigger applies; and/or an indication to enable dual proxy deployment.

26. The dual proxy deployment network (200) of any of Claims 18 to 25, wherein the repository is configured to transmit a response message to the EF indicating the privacy instructions have been received.

27. The dual proxy deployment network (200) of any of Claims 18 to 26, wherein the network further comprises an Application Function, AF, wherein the AS is further configured to transmit the trigger for requesting privacy enabling to the AF; and wherein the AF is configured to generate the enabling privacy request, and transmit the enabling privacy request to the EF.

28. The dual proxy deployment network (200) of any of Claims 18 to 27, wherein the enabling privacy request comprises one or more of: an identifier for the AS; an identifier for the AF; a SUPI for a UE for which privacy enabling is requested; a list of App-IDs for one or more applications for which privacy enabling is requested; a DNN for a PDU Session to which the trigger applies; and/or a S-NSSAI for a PDU Session to which the trigger applies.

29. The dual proxy deployment network (200) of any of Claims 18 to 28, wherein the repository is a Unified Data Repository, UDR, and the EF is one of: a Network Exposure Function, NEF, and a Business Support System, BSS.

30. A dual proxy deployment network (200), the network comprising: a Network Function, NF, the NF comprising processing circuitry and a non-transitory machine-readable medium storing instructions; and a NF Repository Function, NRF, the NRF comprising processing circuitry and a non-transitory machine-readable medium storing instructions; wherein the NF is configured to transmit an NF profile update request to the NRF (S402); and wherein the NRF is configured to update an NF profile based on the NF profile update request (S404); wherein the NF profile update request comprises an ingress proxy contact information associated with the NF.

31. The dual proxy deployment network (200) of Claim 30, wherein the NF is a User Plane Function, UPF.

32. A dual proxy deployment network (200), the network comprising: a Session Management Function, SMF, the SMF comprising processing circuitry and a non-transitory machine- readable medium storing instructions; and a Network Function Repository Function, NRF, the NRF comprising processing circuitry and a non-transitory machine-readable medium storing instructions; wherein the SMF is configured to transmit a Network Function, NF, discovery request to the NRF (S502); and wherein the NRF is configured to authorise a NF service discovery procedure based on the discovery request (S504); wherein the discovery request comprises an indicator regarding a condition of ingress proxy support.

33. The dual proxy deployment network (200) of Claim 32, wherein the NF discovery request is a User Plane Function, UPF, discovery request.

34. A dual proxy deployment network (200), the network comprising at least one of: the network apparatus of any of claims 18 to 29; the network apparatus of any of claims 30 and 31 ; and the network apparatus of any of claims 32 and 33.