CN117545040A

CN117545040A - Method for routing data from an application client to an application server via a core network of a cellular network

Info

Publication number: CN117545040A
Application number: CN202310994997.6A
Authority: CN
Inventors: S·萨巴特; A·罗; A·弗鲁克图奥索; S·波索莱
Original assignee: Vodafone Group Services Ltd
Current assignee: Vodafone Group Services Ltd
Priority date: 2022-08-08
Filing date: 2023-08-08
Publication date: 2024-02-09
Also published as: US20240049103A1; EP4322616A1

Abstract

A method for routing data through a cellular network from an application client at a user equipment, UE, to an application server via a core network. The network operator platform receives an initial request from the UE to establish a communication session between the application client and the application server. The network operator platform then generates configuration information for configuring the application client to establish the communication session. The network operator platform further generates configuration information for configuring the core network to establish the communication session. Next, the application client is configured according to the application client configuration information and the core network is configured according to the core network configuration information such that the core network sends the generated urs to the UE for storage in a urs repository at the UE.

Description

Method for routing data from an application client to an application server via a core network of a cellular network

Technical Field

A method for routing data through a cellular network from an application client at a user equipment, UE, to an application server via a core network. The method makes use of enhanced routing options in 5G (fifth generation technical standard of broadband cellular networks). The method allows a network operator to identify the origin (including specific applications and UEs) and type of data traffic received at a core network via network slicing as part of a communication session.

Background

Different applications and services running at the user device may benefit from different network characteristics (e.g., service level requirements such as bandwidth and/or latency) to provide a better customer experience or to allow the application to function properly. For example, video streaming services may benefit from high bandwidth, but are less sensitive to latency, while online gaming applications may prioritize lower latency. Under 3G or 4G (third and fourth generation technical standards, respectively, for broadband cellular networks), different applications typically utilize the same data bearer to provide services, which provides a common set of network characteristics. However, an option to optimize data routing is provided in 5G (fifth generation technical standard of broadband cellular networks).

5G provides a network architecture that allows network slicing. Network slicing describes providing different channels (or "slices") between the user equipment and the core network, or outside the data network where the application server resides. The use of network slices provides a mechanism to multiplex virtual and independent channels on the same physical network infrastructure. Each network slice provides an end-to-end channel that may or may not be isolated from other slices. Each network slice may have different network characteristics that may be tailored to meet the requirements of a particular application. Thus, in principle, a particular network slice may be allocated by the network to provide network characteristics that are best suited to the type of data traffic generated by a particular application or for a particular service.

The network slices are allocated according to the type of data traffic to be carried on the network slices. For example, application a may generate data traffic in a first specialization class of service with low latency preferences. Application B may generate data traffic in a second specialization class of service with a preference for high bandwidth. Under 5G, application a may be routed through a first network slice (optimized for traffic from applications requiring variable bandwidth rates but low or ultra-low latency), while application B may be routed through a second network slice (optimized for applications with high bandwidth requirements). Routes sliced from the UE via the network are allocated at the UE by consulting a stored UE routing policy (urs) according to third generation partnership project (3 GPP) standards. Each urs associates a particular type (or particular specialized class of service) of data to a particular network slice and Data Network Name (DNN).

While proper selection of network slices for routing data traffic may improve user experience by customizing network characteristics for a given application, further improvements are possible by customizing routing at the core network edge to the network operator of the data network where the application server resides. However, such network operator customized routing is only beneficial if there is some knowledge of the content of the data traffic and its source. Many applications may generate data traffic of the same type and of the same specialized service class (and thus be routed via the same network slice). Thus, the network operator needs more information about the data traffic in order to more accurately distinguish the processing or routing of the data.

Although information about the origin and content of the data traffic is specified to be provided to the core network within the 5G standard, in practice, this information tends to be ambiguous from the core network due to privacy regulations imposed by the operating system at the user equipment (or UE). In particular, an application running at the UE may identify itself to the UE's operating system, but the operating system typically does not pass to the cellular network an identification of a particular type of network traffic, or a particular application from which the identification data originated. Losing this information at the core network prevents the network operator from providing an optimal path for data associated with a particular application through the cellular network. Furthermore, since the operating system at the user equipment is not aware of the current network conditions, the operating system at the UE itself is not able to instruct specific processing of data through the cellular network. Thus, some of the benefits provided by 5G may be lost.

One option to overcome this problem is for the network to examine data packets from a particular user to identify a particular type of network traffic and its origin. However, this is only possible if the data traffic itself is not encrypted. Furthermore, such checking may increase the latency of data transmission through the cellular network.

Accordingly, there is a need for a method for routing data through a cellular network from an application client at a User Equipment (UE) to an application server via a core network, which overcomes these drawbacks in order to provide the best possible experience for a user of an application provided via the application client.

Disclosure of Invention

In this context, a method according to claims 1 to 11 is provided for routing data through a cellular network from an application client at a User Equipment (UE) to an application server via a core network. A computer program according to claim 12, a UE according to claim 13, a network entity (or a system of network entities) according to claim 14 and a network operator platform according to claim 15 are also described.

Most generally, a method for routing data through a cellular network from an application client at a User Equipment (UE) to an application server via a core network is described. The network utilizes 5G capabilities, including network slicing. The method includes configuring an application client and a core network using a network operator platform. The application client is configured to address a request for a communication session between the application client and the application server to a token Data Network Name (DNN) in order to identify the application client and the UE to an operator of the core network. The core network is configured to route data addressed to the token DNN to the designated DNN (by the core network changing the token DNN of the designated DNN upon receipt of a request to establish a communication session addressed to the token DNN). By providing the network operator with information about the source and type of data traffic received from the UE (which may be specific to a given application session by signaling using the token DNN), the network operator may enable specific, customized processing and handling of the data traffic as it passes through the cellular network.

In a first aspect, there is a method for routing data through a cellular network from an application client at a User Equipment (UE) to an application server via a core network, the method comprising:

receiving, at the network operator platform, an initial request from the UE to establish a communication session between the application client and the application server, the communication session to be routed via a network slice for routing data belonging to a class of data traffic sent from the application client to the application server;

generating, by the network operator platform, configuration information for configuring the application client to establish the communication session, the application client configuration information comprising:

instructions that cause the application client to address a subsequent request to establish a communication session with the application server to the token data network name DNN;

generating, by the network operator platform, configuration information for configuring the core network to establish the communication session, the core network configuration information comprising:

instructions that cause the core network to change a token DNN specifying a DNN upon receiving a request to establish a communication session addressed to the token DNN;

instructions for causing the core network to generate a UE routing policy, urs, to be sent to the UE, the generated urs rules associating categories of data traffic sent from the application client to the application server with the tokens DNN and the network slices;

Configuring an application client according to the application client configuration information;

configuring the core network according to the core network configuration information such that the core network sends the generated urs to the UE for storage in a urs repository at the UE;

wherein after configuring the application client and the core network, a subsequent request for establishing a communication session between the application client and the application server is sent from the application client via the network slice, which indicates a class of data traffic and is addressed to the token DNN, the core network identifying information about the data in the communication session and the application client from which the data is routed by receiving the token DNN, in order to facilitate a specific handling or treatment of the communication session by the network operator.

In other words, a communication session is first established with the network operator platform before establishing a communication session with the application server. The network operator platform generates configuration information for reconfiguring the application client and the core network for data routing in subsequent communication sessions between the particular application client and the application server. One piece of configuration information generated by the network operator platform is the token DNN, which is generated taking into account the identities of the application client and the UE. During configuration, the token DNN is sent from the network operator platform to the application client for use in subsequent requests to establish a communication session with the application server. The token DNN is also sent to the core network to permit the core network to identify the source of data transmitted in a subsequent data session. The core network is further configured by the network platform such that upon receipt of a request to establish a subsequent communication session, the core network replaces the token DNN with a specified or predetermined "true" DNN of the data network on which the application server resides.

A request is received with a specific data type and addressed to a token DNN at the core network, information about the application client and the UE is signaled to the network operator, and the type of data to be routed through the communication session. By obtaining knowledge of the source and nature of data sent in subsequent communication sessions, the network operator can customize the processing of data through the cellular network. In particular, the process may be optimized for a given application. This in turn improves the overall experience of the end user utilizing that particular application.

Preferably, the cellular network has 5G (fifth generation technical standard for broadband cellular networks) capability. An application client will be understood as a software element at a UE (being a user equipment such as a mobile device or a computer). The application client transmits, processes and receives data from the application server in order to provide the functionality of the application to the end user of the UE.

The network operator platform is an entity of the cellular network that provides the functionality of exposing core network capabilities that may be used by the network operator itself or by third parties. A network operator platform is an entity that allows network operators, as well as third party developers and engineers, to monitor, adapt, and program aspects of network and data routing.

A communication session may describe any connection for routing data between two entities (here between an application client and an application server) through a cellular network. In 5G, the communication session may be a PDU session that provides an end-to-end connection between an element or application at the UE and a particular data network, such as the internet or a private network, via a User Plane Function (UPF) of the core network. The data network to be accessed is identified or addressed by a Data Network Name (DNN). In 5G, a given PDU session occurs on a single network slice and is connected to the DNN. The communication session request is sent by the UE and addressed to a given DNN, directed via a particular network slice according to a UE routing policy (urs). The urs are routing rules stored in a repository at the UE. The urs may be preconfigured in the UE and may be sent or updated from the core network (e.g., although not exclusively, when the UE registers or connects to the operator's network).

The method may further comprise the steps of:

at the core network, receiving a subsequent request to establish a communication session from the application client via the network slice and addressed to the token DNN according to the generated urs;

Changing a token DNN specifying the DNN at the core network;

a communication session is established between the application client and the application server via the specified DNN and the network slice, and has network assigned attributes.

In particular, at the UE, the request to establish the communication session utilizes the generated urs together with the token DNN and the application data type. The core network then exchanges the token DNN with the real, designated DNN, and in accordance with the previous configuration of the network operator platform. Thus, the network slice extends from the UE to the edge of the core network (which may be a multiple access edge computing (MEC) server or a peer-to-peer connection to an application server), and the data traffic may undergo specific processing or handling during routing through the network.

The configuration information for configuring the core network may further include one or more of the following:

instructions for the core network to associate a subsequent request to establish a communication session with a UE subscription using network slicing;

an instruction to alert the network operator platform of a change in the geographic location of the UE;

an instruction to alert the network operator platform whether the application is started or stopped;

alerting the network operator platform of network conditions that may affect the quality of service associated with the application client; and

Information related to a domain name system DNS server at the core network for resolving an IP address of the application server during communication session establishment.

In other words, the additional configuration information may be used to allow more accurate billing of the user, changing the routing of data traffic in the communication session when the UE moves or when application server conditions and/or network conditions are considered, or when an application associated with the application client is started or stopped. The configuration information may be further used to change further characteristics of the route through the core network to more generally improve quality of service metrics or quality of experience.

The configuration information for configuring the application client may further include:

instructions to address DNS servers using DNS for HTTPS over hypertext transfer protocol security; and/or

Information related to a domain name system DNS server at the core network for resolving an internet protocol IP address of the application server during communication session establishment.

DNS over HTTPS may be used to provide greater privacy for communication sessions. The information related to the DNS server may include an identification of the DNS server at the core network.

In view of the common identifier derived from the identifier of the UE and the identifier associated with the application client requesting access to the network slice, core network configuration information and/or application client configuration information may be generated through interaction of the network operator platform with network repositories and configuration nodes at the core network. In this way, the configuration information (including the token DNN) is subscribed to the application at the application client and UE, and may be time-limited or application-specific.

After the step of receiving an initial request for establishing a communication session between the application client and the application server, the method may further comprise:

obtaining, by the network operator platform, authorization from the application client to an end user of the application client to share information to identify to the core network an origin of data originating from the application client;

authorization for the application client to use the network slice is obtained from the core network by the network operator platform.

Authorization is obtained from the end user in order to alleviate privacy concerns associated with the transfer of information about the origin and type of data traffic from the application client to the core network. In particular, the end user is required to voluntarily select application services at the user equipment to be handled in a specific manner.

Obtaining authorization from an end user of the application client to share information, thereby identifying to the core network the origin of the data originating from the application client may further comprise receiving as authorization from the application client an application identifier associated with the application client requesting access to the network slice; and

obtaining authorization for the application client to use the network slice may further include receiving as authorization a UE identifier corresponding to a subscription of the UE to use the network slice;

Wherein generating the core network configuration information and/or the application client configuration information by interaction of the network operator platform with the network repository and the configuration node at the core network in view of the identifier of the UE and the identifier associated with the application client requesting access to the network slice may further comprise:

constructing a generic identifier from the UE identifier and the application identifier;

wherein the configuration information for configuring the application client and for configuring the core network is generated by the network operator platform using the common identifier interacting with a network repository and configuration nodes at the core network.

In other words, the configuration information is generated with knowledge of the application associated with the application client and knowledge of the UE. This allows tailoring the configuration information such that the routing of data traffic between the application client and the application server provides an optimal user experience. The configuration information (and thus the data routing) may be further customized to ensure regulatory requirements are met (such as retaining data within the european union in order to comply with GDPR regulations).

Once the universal identifier has been constructed, the core network configuration information generated by the network operator platform may further include instructions that cause the core network to store the universal identifier along with subscriber data associated with the network slice and the designated DNN. In other words, the core network associates the generic identifier with the subscriber, the network slice that the subscriber is allowed to use, and with both the token DNN and the designated DNN. This allows the network operator to know (via the core network) the source and nature of the data traffic in the subsequent communication session.

An initial request to establish a communication session between an application client and an application server may be routed between the application client and the network operator platform via a network slice and addressed to the network operator platform DNN. In a particular example, an initial request to establish a communication session between an application client and an application server may be routed from a UE according to an initial urs stored in a urs repository in the UE, the initial urs associating categories of data traffic sent from the application client in the particular UE with network operator platforms DNNs and network slices. For example, the application client generates data of a particular data type, which is routed to the network operator platform (addressed with the network operator platform DNN) via the network slice associated with the particular data type according to the initial urs.

The initial urs may be updated in or added to the urs repository at the UE at the initial registration of the UE with the core network or may be preconfigured in the urs repository at the UE by the network operator prior to the initial registration of the UE with the core network. The generated urs and the initial urs may have relative rule priority values that force evaluation of the generated urs prior to the initial urs.

In a second aspect, a computer program is described, comprising instructions for routing data through a cellular network from an application client at a user equipment, UE, to an application server via a core network, when operated by a processor of an entity or an entity system of the cellular network, a network operator platform or the core network, the instructions causing the processor to carry out the method described above.

In a third aspect, there is a user equipment, UE, in a cellular network and comprising an application client configured to operate according to the method described above.

In a fourth aspect, there is an entity or entity system of a core network of a cellular network configured to operate according to the method described above.

In a fifth aspect, there is a network operator platform configured to operate according to the method described above.

In a fifth aspect, there is a cellular network comprising a UE, a network operator platform and a core network entity, each configured to operate according to the method described above.

Drawings

The present disclosure may be put into practice in a variety of ways and preferred embodiments will now be described, by way of example only, with reference to the accompanying drawings, in which:

Fig. 1 shows a flow chart illustrating steps in an example of a method for routing data through a cellular network from an application client at a User Equipment (UE) to an application server via a core network;

FIG. 2 shows elements of a system to be configured during a configuration phase; and

fig. 3 shows elements of the same system during establishment of a communication session between an application client and an application server via a core network of a cellular network.

In the drawings, like parts are designated with like reference numerals. The figures are not drawn to scale.

Detailed Description

The user may subscribe to a specialized service provided by the network operator. For example, a user may subscribe to a network package to allow an improved user experience for streaming applications or gaming applications.

A method of routing data through a cellular network from an application client at a User Equipment (UE) to an application server via a core network is provided. The method aims at providing the best possible user experience, in particular with more adaptive network routing available in 5G. The method allows the core network to identify the source and nature of the data routed through it, without relying on the UE's operating system to provide specific information about the content or origin of the data packets.

In the described method, the routing of data from the UE to the edge of the core network occurs through network slices assigned to the specialized service class required by the application. Each network slice is provided with network characteristics optimized for the class of service. However, distinguishing data traffic by specialized service class is not particularly accurate, as many different applications may generate data that fits the same service class. Thus, the method of the present disclosure allows the core network to receive additional information about the origin and nature of data traffic routed through the cellular network (both UE and information of the application from which the data originated). This permits network operators with visibility of network conditions to route data in a dedicated or customized manner (especially through the core network) in order to provide improved conditions for operation of a particular application and thus better user experience.

The method utilizes a network operator platform to configure entities in the cellular network and at the UE that are involved in communication session establishment. In particular, during an initial configuration phase, the network operator platform reconfigures the application client and the core network in view of the identifiers of the UEs and the identifiers associated with the application client. More specifically, when a communication session is established with an application server, the network platform generates a token Data Network Name (DNN) to be addressed in the request of the application client. When received by the core network, the token DNN is considered as an identifier of the originating application and the UE. The core network exchanges the token DNN for a true DNN while knowledge of the origin of the data traffic can be used by the network operator to distribute more accurate or customized routing of data through the cellular network.

In some examples, knowledge of the source or nature of data traffic in a communication session allows data to be directed to a particular peer or server that may have been established by means of agreements between network operators and application providers. Additionally or alternatively, data traffic may be rerouted under control of the network operator (e.g., in view of user mobility or network congestion). In still further examples, knowledge of the source or nature of the data traffic permits the data traffic to be provided with special handling, e.g. using different radio types, or dividing the traffic into fixed and mobile access, or given a guaranteed bit rate that may have been agreed in a contract with the user or application provider. Finally, this knowledge may allow operators to monetize specific data traffic with greater accuracy or granularity.

The configuration and configuration information generated as part of the disclosed methods may be application session specific, time limited, or permanent. Configurations according to the method may persist across more than one application session.

As outlined herein, the method is described in more detail in four phases as follows:

A. registering a subscriber;

B. Establishing a communication session with a network operator platform;

C. configuration; and

D. and executing.

The steps of each stage are described in more detail below, although not all steps are necessary for the practice of the invention. A flow chart of the steps of the method is shown in fig. 1.

It will be appreciated that stage a (user registration) may form part of the initial registration of the UE with the core network. Phases B and C (establishing communication sessions and configurations with the network operator platform) relate to the configuration of the system according to the method, and phase D relates to establishing communication sessions within the configured system.

Stage A: subscriber registration

This stage registers User Equipment (UE) with the network operator in order to identify the user as a subscriber to the particular service(s) provided by the network operator.

The step of phase A is:

step 1: the registration request is sent from the UE 5 to the core network 50. The request may be sent from modem 30 or UE higher layer software, depending on the particular implementation. Typically, the registration request is sent from the modem layer, but the content of the registration request may be generated by other layers in the UE 5.

Step 2: subscriber details (with UDM (unified data management) in the core network 50) are checked to verify if the user subscribes to use one or more network slices, each for routing data traffic in a particular specialised service class.

Step 3: a registration accept message is sent by the core network 50 to the UE 5, which includes a list of network slices that the UE 5 is allowed to use. The list of network slices includes one or more particular network slices 100 to be used by the corresponding one or more specialized service categories. Each of the one or more specialized service classes may have a different set of network characteristics (such as different bandwidths, latencies, etc.). Each network slice may be identified by an S-nsai (single network slice selection assistance information), which may be associated with a particular specialized service class. For example, a first particular network slice, labeled S-NSSAI-a 110, is for use by a first specialized service class.

Step 4: optionally, the core network 50 returns one or more new urs (UE routing policies) to the UE 5. One or more new urs are stored in a urs repository 20 at the UE 5. Generally, each urs associates data traffic classified within a given one of one or more specialized service categories with a particular network slice and Data Network Name (DNN). Within the disclosed method, the one or more new urs include a first urs that associates data traffic in a first specialization class with a network slice S-nsai-a and with a network operator platform DNN op_plane_dnn.

Stage B: establishing a communication session with a network operator platform

At this stage, an initial communication session (PDU session) is established between the application client and the network operator platform. A network operator platform is an entity that allows a developer to interact with an operator's network and ultimately design an application or product that can select and define network requirements for use by the operator.

The step of the stage B is as follows:

step 5: the application client 10 requests that a communication session be established with the application server 70 for a particular application, data traffic from the application belonging to a first specialization class of service (first data type).

Step 6: the UE 5 (more specifically, the modem 30) consults the urs repository 20 to determine how to route the application client request. The modem 30 identifies the urs as being appropriate for a particular specialization class of service. In this example, the first urs (updated in the urs repository 20 in phase a) are identified as being appropriate for the first specialization class of service. The first urs associates an application client request with the network operator platform DNN (op_plane_dnn) and the network slice S-nsai-a, the application client request including an indicator of the first specialization class of service as a traffic descriptor.

Examples of the first urs are:

step 7: according to the first urs, a request to establish a communication session is sent from the UE 5 to the network operator platform 40 via the network slice S-nsai-a 110 and the op_plane_dnn is addressed.

Step 8: the initial communication session is established between the application client 10 at the UE 5 and the network operator platform 40.

Stage C: configuration of

Within the initial communication session established in phase B, in phase C, the network operator platform is used to authorize special handling of data traffic from applications and configure the application clients, UEs and core network to allow subsequent communication sessions to be established through the preferred network slice, while informing the network of the origin and nature of the data traffic (including identifying the originating UE and application). The entities during configuration phase C are depicted in fig. 2.

The step of the stage C is as follows:

step 9: the network operator platform 40 requests and receives authorization from the core network 50 for the application client 10 to use a particular network slice. For example, in this example, the network operator platform 40 requests authorization to use the network slice S-nsai-a 110 assigned to the first specialized service class.

Step 10: the network operator platform 40 requests authorization from the end user of the UE 5 via the application client 10 for special routing of data generated during the requested communication session and/or authorization of shared information allowing the source of data traffic from the application client 10 to be identified by the network operator.

Step 11: the application client 10 returns an identifier (here denoted client_id) of the application client 10 as authorization to the network operator platform 40, including an identification of the specialization class of service it intends to use.

Step 12: the network operator platform 10 constructs a generic identifier (denoted herein as a genericid) for applications and users to use during the lifecycle of the requested communication session. The universal identifier (genericid) is generated based on both the application client identifier (client ID) and the UE identifier (UE ID). The UE identifier may take various forms including a subscription permanent identifier SUPI (equivalent to the international mobile subscriber identity IMSI in 4G in 5G), or a mobile station international subscriber directory number MSISDN (which is the telephone number of the subscriber). In one example, the core network records the SUPI from the first connection of the user with the network operator in its repository, but this identifier may be passed directly to the network operator by the application client or UE during the authorization phase at step 10.

Step 13: the network operator platform 10 constructs a token_dnn (denoted herein as token_dnn). This may be considered as a pseudo-DNN or a virtual DNN, which is not a real network address. The predictive DNN is used to configure and alert (or signal) the core network 50 that the application is using a specialized service class, and also to identify the application client 10 and UE 5 to the network operator when a request addressed to the predictive DNN is received at the core network 50.

Step 14: using the universal identifier (genericid), the network operator platform 40 interacts with one or more network repositories 90 and/or network configuration nodes 80 to configure and prepare the core network 50 for communication sessions initiated by the application client 10 at the UE 5. The network repository 90 and the network configuration node 80 may comprise UDM (unified data management), UDR (unified data repository), NEF (network exposure function) and PCF (policy control function)). Information related to the UE subscription is retrieved and further configuration information for the configuration of the application client 10 and the core network 50 is generated.

The configuration information generated by the network operator platform 40 for the configuration of the core network 50 includes:

i. instructions for causing the core network 50 to associate a generic identifier (genericid) with a UE subscription to a network slice (e.g., S-nsai-a 110) to be used for a specialized service class in which the application-generated data is classified.

ii instructions for the core network 50 to associate the predicted DNN with a UE subscription to a network slice (e.g., S-nsai-a 110) to be used for a specialized service class in which the application-generated data is classified.

instructions for causing the core network 50 to generate a further new urs (denoted herein as second urs) to be transmitted to the UE. The second urs associates Traffic Descriptors (TDs) of the specialization class in which data generated by the application is classified with network slices and predictive DNNs (token_dnns) of the specialization class. The routing descriptor in the second urs does not include any DNNs. The rule priority value of the second urs is given to a value relative to the first urs (generated as part of the registration accept message in step 4) in order to force the evaluation of the second urs at the UE before evaluating the first urs.

Examples of the second urs are:

instructions for causing the core network 50, in particular, comprising a repository of subscriber policies, to allow the predictive DNN (token_dnn) to be used for a particular subscriber and to exchange the predictive DNN for another specified or predefined DNN when a communication session request addressed to said predictive DNN (token_dnn) is received at the core network. The designated DNN is a real or genuine address for accessing the data network on which the application server resides. In some cases, the specified DNN may be selected by the core network in view of transient network conditions or in view of data network conditions that the network operator platform alerts.

Optionally, an instruction to alert the network operator platform 40 when the geographic location of the UE 5 changes. This may trigger a reconfiguration of the network operator platform, for example by repeating some steps of the described method.

Optionally, an instruction to alert the network operator platform 40 whether the application is started or stopped. This may trigger timing actions related to the (re-) configuration of the application client and the core network.

Optionally charging information and quality of service (QoS) information related to a specific application in the UE 5.

In some cases, a particular DNS server 60 in the core network 50 to be used in a subsequent communication session may be identified.

The information retrieved by the network operator platform 40 from the UDR (unified data repository) via the UDM at the core network 50 comprises subscription information related to the use of the multiple access edge computing (MEC) service of the UE 5. This may be used to configure the application client 10 with information related to the use of edge computation features.

The configuration information for configuring the application client 10, which is collated or generated by the network operator platform 40, includes:

a) A predictive DNN (token_dnn) for use in subsequent requests for a communication session between the application client 10 and the application server 70.

b) Optionally, in case the subscriber has subscribed to an edge computing service provided by the network operator itself or agreed with the application provider, instructions of the network operator to resolve the application server address via DNS server 60 at core network 50 using Domain Name Server (DNS) over hypertext transfer protocol security (HTTPS) (DoHH). A particular DNS server 60 in the core network 50 to be used may be identified.

Step 15: the network operator platform 40 provides core network configuration information to the core network 50 and the core network configuration information is used to configure the core network 50.

Step 16: core network reconfiguration the UE 5 is triggered with a configuration update message using non-access stratum signaling according to the standard procedure depicted in 3gpp TS 23.502. The configuration update message includes the second urs generated by the network operator platform 40 at step 14 (configuration information iii of step 14).

Step 17: after receiving the configuration update message, the urs repository 20 at the UE 5 is updated with the second urs.

Step 18: the network operator platform 40 provides the application client 10 with application client configuration information, and the application client configuration information is used to configure the application client 10.

Stage D: execution of

At this stage, the application client initiates a new communication session between the application client and the application server via the core network. A communication session is established according to the configuration imposed in phase C. The entities during the execution phase D are depicted in fig. 3.

The step of stage D comprises:

step 19: the application client 10 sends a request for a new communication session between the application client 10 and the application server 70. The request from the application client 10 to the UE 5 modem layer 30 includes an identification of the predicted DNN (token_dnn) and the specialization class of service (here the first specialization class of service) by the application service descriptor (TD). The request from the application client 10 may include a request to obtain a DNS server address for further resolving the application server address via the DNS server 60 at the core network 50. This may be done if the application client has not been configured with DNS settings during the configuration phase.

Step 20: the UE 5 (specifically, the modem layer 30) consults the urs repository 20 and identifies the second urs (as previously provided at step 14), associates the predictive DNN (token_dnn) and the first specialization class with the first network slice (S-nsai-a 110).

Step 21: a request to establish a new communication session is sent by the UE 5 to the core network 50, in particular to an access and mobility management function (AMF) in the control plane of the core network 50. The request predicts a DNN (token_DNN) via network slice addressing for the first class of specialized services (S-NSSAI-a 110).

Step 22: the core network 50 changes (e.g. at the control plane level) the predicted DNN (token_dnn) of the specified DNN (as specified in the configuration information iv of step 14). A request for a communication session is sent to a designated DNN.

Step 23: if configured to use a network DNS server, a DNS query is signaled from the application client 10 towards a DNS server 60 located in the operator network, using the DoH, if configured in the application client, to obtain the application server address with which the application client 10 intends to communicate.

Step 24: the communication session is connected between the application client 10 and the application server 70 through the network slices S-nsai-a 110 allocated by the network and according to the specific handling or disposition of the network operator.

The network operator specific handling or treatment may be allocated by the network operator because the network operator knows the origin and nature of the data traffic (including the identity of the specific application and UE) within the communication session. The network operator assigned attributes for data processing may allow data traffic in a communication session to be directed to a particular peer or server that has been established by means of an agreement between the network operator and the application provider. Additionally or alternatively, data traffic may be rerouted under control of the network operator (e.g., in view of UE mobility, network congestion, or other transient network conditions). In still further examples, knowledge of the origin of the data traffic permits special treatments to be provided to the data traffic, e.g. using different radio types or frequency bands, or dividing the traffic into fixed and mobile access, or being given a guaranteed bit rate that may have been agreed in a contract with the user or application provider. Finally, knowledge of the origin of the data traffic by the network operator may allow the operator to monetize specific data traffic with greater accuracy or granularity.

It will be appreciated that the features disclosed herein may be combined in any manner and are not limited to the specific implementations described above. Each feature disclosed in this specification may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

As used herein, including in the claims, the singular forms of terms herein should be interpreted to include the plural forms, and vice versa, unless the context indicates otherwise. For example, reference in the singular, such as "a" or "an" means "one or more" included in the claims unless the context indicates otherwise. Throughout the specification and claims of this disclosure, the words "comprise," "include," "have" and "contain" and variations of the words, such as "comprising" and "include" or similar means "including but not limited to," and are not intended to (and do not) exclude other components.

The use of any and all examples, or exemplary language ("e.g.," such as, "such as," and the like) provided herein, is intended merely to better illuminate the invention and does not pose a limitation on the scope of the invention unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention.

Any steps described in this specification may be performed in any order or simultaneously unless otherwise indicated herein or otherwise clearly contradicted by context. All aspects and/or features disclosed in this specification may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive. In particular, the preferred features of the invention are applicable to all aspects of the invention and may be used in any combination. Also, features described in optional combinations may be used alone (in non-combinations).

Claims

1. A method for routing data through a cellular network from an application client at a user equipment, UE, to an application server via a core network, the method comprising:

receiving, at a network operator platform, an initial request from a UE for establishing a communication session between an application client and an application server, the communication session to be routed via a network slice for routing data belonging to a class of data traffic sent from the application client to the application server;

instructions for causing the core network to change a token DNN specifying a DNN upon receiving a request to establish a communication session addressed to the token DNN;

2. The method of claim 1, wherein the token DNN is a virtual DNN that is not a real network address, and wherein the token DNN signals information about application clients and UEs and data types to be routed through the communication session to a network operator platform.

3. The method of claim 1 or claim 2, further comprising:

changing, at the core network, a token DNN specifying the DNN;

4. A method according to any one of claims 1 to 3, wherein the configuration information for configuring the core network further comprises one or more of:

5. The method of any preceding claim, wherein the configuration information for configuring the application client further comprises:

6. The method of any preceding claim, wherein the core network configuration information and/or the application client configuration information is generated by interaction of the network operator platform with network repositories and configuration nodes at the core network in view of an identifier of the UE and an identifier associated with an application client requesting access to the network slice.

7. The method of claim 6, further comprising, after the step of receiving an initial request to establish a communication session between the application client and the application server:

Obtaining, by the network operator platform, authorization from the application client to an end user of the application client to share information to identify to the core network an origin of data originating from the application client; and/or

8. The method of claim 7, wherein obtaining authorization from an end user of the application client to share information, thereby identifying to the core network an origin of data originating from the application client further comprises receiving from the application client an application identifier associated with the application client requesting access to the network slice as authorization; and/or

Obtaining authorization for the application client to use the network slice further includes receiving as authorization a UE identifier corresponding to a subscription of the UE to use the network slice;

wherein generating the core network configuration information and/or the application client configuration information by interaction of the network operator platform with the network repository and the configuration node at the core network in view of the identifier of the UE and the identifier associated with the application client requesting access to the network slice comprises:

9. The method of claim 8, wherein the core network configuration information further comprises:

instructions that cause the core network to store the generic identifier along with subscriber data associated with the network slice and both the token DNN and the designated DNN.

10. The method of any preceding claim, wherein an initial request to establish a communication session between an application client and an application server is routed between the application client and a network operator platform via a network slice and addressed to the network operator platform DNN.

11. The method of claim 10, wherein the initial request to establish the communication session between the application client and the application server is routed from the UE according to an initial urs stored in a urs repository in the UE, the initial urs associating categories of data traffic sent from the application client with network operator platforms DNNs and network slices.

12. The method of claim 11, wherein the initial urs are updated in or added to a urs repository at the UE at the time of initial registration of the UE with the core network, or are preconfigured in the urs repository at the UE by a network operator before initial registration of the UE with the core network.

13. The method of claim 11 or claim 12, wherein the generated urs and initial urs have relative rule priority values that force evaluating the generated urs before the initial urs.

14. A user equipment, UE, in a cellular network and comprising an application client configured to operate in accordance with the method of any one of claims 1 to 13.

15. An entity or entity system of a core network of a cellular network configured to operate in accordance with the method of any one of claims 1 to 13.

16. A network operator platform configured to operate in accordance with the method of any one of claims 1 to 13.