WO2021028063A1

WO2021028063A1 - Predicting congestion levels in a communications network

Info

Publication number: WO2021028063A1
Application number: PCT/EP2019/076152
Authority: WO
Inventors: Robert Skog; Marcus IHLAR; Veronica SANCHEZ VEGA; Carlota VILLASANTE
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2019-08-12
Filing date: 2019-09-27
Publication date: 2021-02-18

Abstract

In a method in a communications network, data from a user plane function, UPF, is obtained, related to traffic through the UPF. The data from the UPF is provided as input to a first machine learning model and a prediction of a congestion level in the user plane, UP, is received from the first machine learning model based on the data from the user plane function.

Description

PREDICTING CONGESTION LEVELS IN A COMMUNICATIONS NETWORK

Technical Field

This disclosure relates to methods, nodes and systems in a communications network. More particularly but non-exclusively, the disclosure relates to training and using a machine learning model to predict a congestion level in a communications network.

Background

Generally, this disclosure relates to detecting and managing congestion in a communications network, such as a third generation (3G), fourth generation (4G) or fifth generation (5G) communications network. Fig. 1 shows a (prior art) configuration of a Third Generation Partnership Project (3GGP) 5G core (5GC) network architecture 100 that is relevant to some embodiments herein. The 5GC network reference architecture comprises a plurality of functions, e.g. functional building blocks with well-defined functional behaviors and external interfaces. The functions may be implemented in hardware but are increasingly implemented in software, for example in a service based architecture. Fig. 1 shows a User Plane Function (UPF) 102, a Session Management Function (SMF) 104, a Network Data Analytics Function (NWDAF) 106, a Unified Data Repository (UDR) 108, a Network Exposure Function (NEF) 110, an Application Function (AF) 112, a Policy Control Function (PCF) 114, an Online Charging System (OCS) 116, and an Access and Mobility Function (AMF) 118. The functionality of these network functions are described, for example, in the Third Generation Partnership Project 3GPP technical standard 3GPP TS 23.501. This disclosure is primarily related to Control Plane and User Plane Separation (CUPS) between the SMF (104) and UPF (102). This disclosure is also related to the NWDAF (106).

Control and user plane separation (CUPS) enables a flexible placement of the separated control plane and user plane functions for supporting diverse deployment scenarios (e.g. in the form of a centralised or distributed user plane function). In 4G and 5G Evolved Packet Core (EPC) CUPS refers to the Serving Gateway (SGW), Packet Data Network Gateway (PGW) or Traffic Detection Function (TDF) split between control planes. A common implementation is that the SGW User Plane (SGW-U) and the PGW User Plane (PGW-U) are collocated within the same physical or virtual network function. With CUPS SGW-U/PGW-U has a direct S1-U interface to the different evolved Node Bs (e Node Bs). In 5GC, CUPS refers to SMF and UPF network functions and to the N4 reference point between them (the N4 reference point comprises the bridge between the control plane (SMF) and the user plane (UPF) nodes). In 5GC it is possible to have a different anchor UPF for different service flows pertaining to a Packet Data Network (PDN) session, in this case there is a single UPF which interfaces with 5G New Radio Radio Access Network (NR RAN), which classifies the traffic and steers to the corresponding anchor UPFs according to N4 rules. Both the classifier and anchor UPFs can enforce different traffic policies.

The Network Data Analytics Function (NWDAF) 106 represents an operator managed network analytics logical function which provides network analytics insights to other Network Functions such as congestion experienced by a given subscriber at a given network location. The function is similar to the solution defined in 3GPP User Plane Congestion Management (UPCON) which is based on collecting RAN congestion Operations Administration and Management (OAM) data per location and identifying subscriber location.

In recent 3GPP contribution S2-1900656 for 3GPP rel16 it is been proposed that the NWDAF 106 provides actual or predicted user plane congestion to Network Functions (NFs) such as PCF 114 for a given location. In this proposal the PCF 114 seems to get subscriber location by means such as AMF 118 event exposure. The solution proposed for NWDAF to detect congestion is similar to the solution defined in EPC UPCON which is based on Operations Administration and Management (OAM) data. This is illustrated in the signaling diagram shown in Fig. 2 which shows the signals exchanged between a Network Function (NF) requiring congestion information, NWDAF 106 and OAM for one-time reporting (box 202) and continuous reporting (box 204) scenarios.

For one-time reporting, as shown in box 202, it is proposed that the NF signals 206 the NWDAF 106 with an Analytics Request (Nnwdaf_Analyticslnfo_Request). The NWDAF then signals 208 the OAM to request the user plane congestion at the location of interest. The OAM provides the response 210 and the NWDAF then processes 212 the response to derive the analytics requested by the NF in signal 206. Finally, the NWDAF sends a signal 214 to the NF comprising an Analytics Response (Nnwdaf_ANalyticslnfo_Request Response).

For continuous reporting, as shown in box 204, the NF sends an Analytics Subscription Request (Nnwdaf_EventsSubscription_Subscribe Request) 216 to the NWDAF. The NWDAF then signals 218 the OAM 208 to request the user plane congestion at the location of interest. The OAM provides the response 220 and the NWDAF then processes 222 the response to derive the analytics requested by the NF in signal 216. The NWDAF then sends a signal 224 to the NF comprising an Nnwdaf_EventsSubscription_Subscribe Response. The OAM may periodically send the NWDAF new notifications of user plane congestion 226 which the NWDAF will process 228 and periodically update 230 the NF (by means of Nnwdaf_EventsSubscription_Subscribe Response) accordingly.

It is an object of the embodiments herein to provide methods, systems and nodes to improve upon this method of congestion reporting. Summary

As described above, current cellular congestion management solutions and 3GPP base congestion detection on OAM RAN data. As such, reporting and congestion management is performed at the control plane level. It takes time to detect and to apply the required enforcement in the packet Core user plane or SGi LAN and therefore there is currently no provision for real-time congestion reporting and management.

Furthermore, OAM RAN data does not cover specific RAN conditions for a specific user. For example, if the user is in a constrained RAN environment, they benefit from applying different traffic optimizations, even if the cell itself is not congested.

One potential solution to this problem is interface probing. However to retrieve the RAN congestion level and User Equipment (UE) location in real-time requires the deployment of passive probes to different RAN interfaces which may be overly costly and complex and may significantly increase an operator’s total cost of ownership. Other potential solutions such as activation of UE tracing for all subscribers, e.g. by means of 3GPP Minimization of Drive test (MDT), imply significant additional signal processing both in the RAN and User Equipments. Similar considerations apply to RAN cell traces. Another possible solution comprises activation of UE location detection in the Mobility Management Entity (MME), however doing this for all users would not really be feasible due to the excessive processing overhead in the MME.

In summary, there is a need for improved solutions to address real-time congestion reporting and management, particularly in 4G, 5G Evolved Packet Core (EPC) and 5GC networks.

Thus, according to a first aspect herein there is provided a method in a communications network. The method comprises obtaining data from a user plane function, UPF, related to traffic through the UPF. The method then comprises providing the data from the UPF as input to a first machine learning model and receiving from the first machine learning model a prediction of a congestion level in the user plane, UP, based on the data from the user plane function.

This allows the detection or prediction of User Plane congestion solely based on data collected from a User Plane Function using Machine Learning techniques and thus allows the prediction of congestion to be made in real-time. Subsequent congestion management processes may thus be performed more quickly and efficiently.

According to a second aspect there is a method of training a first machine learning model to predict a congestion level in a user plane, UP, of a communications network. The method comprises obtaining training data comprising (i) data from a user plane function, UPF, in the communications network, wherein the data from the UPF is related to traffic through the UPF, and (ii) corresponding ground truth congestion levels in the UP. The method further comprises training the first machine learning model to predict a congestion level in the UP, based on the training data.

According to a third aspect there is a network function in a communications network. The network function comprises processing circuitry configured to obtain data from a user plane function, UPF, related to traffic through the UPF, provide the data from the UPF as input to a first machine learning model, and receive from the first machine learning model a prediction of a congestion level in the user plane, UP, based on the data from the user plane function.

According to a fourth aspect there is a network function in a communications network. The network function comprises processing circuitry configured to obtain training data comprising (i) data from a user plane function, UPF, in the communications network, wherein the data from the UPF is related to traffic through the UPF, and (ii) corresponding ground truth congestion levels in the UP, and train the first machine learning model to predict a congestion level in the UP, based on the training data.

According to a fifth aspect there is a computer program product comprising computer readable medium the computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method of the first or second aspects.

Brief Description of the Drawings

For a better understanding and to show more clearly how embodiments herein may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings, in which:

Fig. 1 shows a prior art configuration of a core network that is relevant to some embodiments herein;

Fig. 2 shows a prior art signal diagram illustrating a known method of congestion reporting;

Fig. 3 shows an example method according to some embodiments herein;

Fig. 4 shows an example method according to some embodiments herein;

Fig. 5 shows an example system according to some embodiments herein;

Fig. 6 shows an example signaling diagram according to some embodiments herein;

Fig. 7 shows another example system according to some embodiments herein;

Fig. 8 shows an example network function according to some embodiments herein; and Fig. 9 shows another example network function according to some embodiments herein.

Detailed Description

As described above, cellular congestion management solutions that base congestion detection on OAM performance measurement metrics and/or manage congestion reporting at the control plane level are unable to provide real-time estimates of the congestion. Furthermore such methods may not be able to provide details of the conditions for individual users/subscribers. Is it an object of the disclosure herein to improve upon these known methods.

Fig. 3 shows a method in a communications network according to some embodiments herein. Briefly, in a first block 302 the method comprises obtaining data from a user plane function, UPF, related to traffic through the UPF. In a second block 304 the method comprises providing the data from the UPF as input to a first machine learning model. In a third block 306 the method comprises receiving from the first machine learning model a prediction of a congestion level in the user plane, UP, based on the data from the user plane function.

The method 300 thus enables predictions of user plane congestion experienced by a subscriber to be made, per location, using only UPF data. The method 300 also proposes a simpler and effective way to manage congestion in real time by enabling, for example, the UPF to be the node which detects such congestion per subscriber.

In more detail, the communications network may be any type of communications network, for example, the communications network may comprise and/or interface with any type of communication, telecommunication, data, cellular, and/or radio network or other similar type of system. In some embodiments, the communications network may be configured to operate according to specific standards or other types of predefined rules or procedures. Thus, in some embodiments, the communications network may implement communication standards, such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and/or other suitable 2G, 3G, 4G, or 5G standards; wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronic Engineers, IEEE, 802.11 standards; and/or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave and/or ZigBee standards.

The communications network may comprise or interface with one or more backhaul networks, core networks, internet protocol (IP) networks, public switched telephone networks (PSTNs), packet data networks, optical networks, wide-area networks (WANs), local area networks (LANs), wireless local area networks (WLANs), wired networks, wireless networks, metropolitan area networks, and other networks to enable communication between devices.

The functionality of parts of the communications network may be divided into functions, such as the functions briefly described in the background section and Fig. 1 above. Briefly, a function comprises a functional building block with well-defined functional behaviors and external interfaces. Functions may be implemented in hardware or software, for example in a service based architecture. Functions may further be implemented in a distributed or cloud-based manner.

Generally, the method 300 as shown in Fig. 3 may be performed by a function of the communications network. For example, in some embodiments the method 300 may be performed by a Network Data Analytics Function, NWDAF, 106. In some embodiments the method 300 may be performed by a User Plane Function, UPF, 102. It will be appreciated that generally a function may comprise (or be comprised on) any network node, processing circuitry, virtual machine or other software or computational arrangement suitable for performing the function. Furthermore, it will be appreciated that other functions may also perform the method 300 or parts of the method 300 thereof.

In more detail, in block 302 the method comprises obtaining data from a user plane function, UPF, related to traffic through the UPF. The data may, for example, relate to traffic flow through, or traversing the UPF. The data may relate to performance of traffic flow through the UPF. For example, in some embodiments, the data may comprise data related to transport protocol performance of information transfer over the UP. Generally however, the skilled person will appreciate that the data may comprise any data that is correlated in some way with congestion on the UP, e.g. such that it may be used by a machine learning model to predict a congestion level.

Specific examples of data that may be obtained from the UPF include but are not limited to: an indication of a transport layer 4 (L4) Key Performance Indicator (KPI), an indication of a Quality of Service (QOS) flow, and an indication of an Access Node, AN, identification (ID). Layer 4 KPIs include, but are not limited to, measures such as Round Trip delay Time (RTT) values and statistics, measures of the number of packets, the predominance direction of packets (Uplink or Downlink), measures of throughput, bitrate, and/or traffic flow statistics (var, mean, standard dev).

In block 304, the method comprises providing the data from the UPF as input to a first (trained) machine learning model. Herein a machine learning model may describe, for example, a model trained using a machine learning process. The first machine learning model may take as input the obtained data from the user plane function, UPF and use it to make a prediction (e.g. estimation) of a congestion level in the user plane. The first machine learning model may comprise any type of trained machine learning model suitable for this purpose. The first machine learning model may comprise a supervised machine learning model (e.g. the first machine learning model may have been trained in a supervised manner). For example, the first machine learning model may comprise a trained neural network, a trained random forest, or any other trained machine learning model.

The skilled person will be familiar with machine learning models, but in brief, supervised learning models as described herein are trained using example training data sets comprising example inputs to the machine learning model and corresponding “correct” outputs for each input. The “correct” outputs are referred to as “ground truths”. The machine learning model is trained to predict the ground truth values from the inputs. Machine learning models generally comprise a set of weights which are iteratively updated as the model processes the training examples, to optimise the output of the trained machine learning model to produce outputs as close as possible to the ground truth of the training data. Training data sets are typically large, comprising many hundreds or thousands of training examples. The accuracy of the machine learning model at predicting the correct output value for new input values increases the larger and more diverse the training set provided.

As will be described in more detail below, in some embodiments the machine learning model may have been trained to predict (e.g. estimate) the congestion level based on training data comprising examples of data from the UPF related to traffic through the UPF and corresponding ground truth congestion in the UP.

3GPP covers two congestion reporting user cases: (i) congestion levels are provided per location (e.g. cell) and (ii) congestion levels are provided on a subscriber level basis. Generally, congestion is specific to a cell location, for a given RAN node a cell might be congested whereas other cells are not.

For user case (i) the model may therefore determine the cell location in addition to the congestion.

For user case (ii) above, subscriber traffic data (such as L4 KPIs) may not be sufficient to determine if a subscriber is in a congested cell. Thus additional location data may be required.

In some embodiments, a cell location may be obtained and provided to the first machine learning model as an additional input. For example, in some embodiments, the method 300 may further comprise obtaining a cell location of a subscriber from an AMF 118.

As an improvement, in some embodiments, cell location of a subscriber may also be predicted or estimated. In such embodiments the location of the user and contextual data from other users in same location may be used to provide an accurate estimation of whether the UE is in a congested cell. In such embodiments, to estimate congestion the subscriber location (e.g. the subscriber cell location) may first need to be acquired. The subscriber cell location may be estimated, for example, by a second machine learning model, which may cluster the subscriber data served by a given RAN node (e.g. cell). The second machine learning model may be validated against the location provided, for example, by data from a MME.

Put another way, in some embodiments, the first machine learning model may have been further trained to predict a cell associated with a subscriber based on training data comprising examples of data from the UPF related to traffic through the UPF and corresponding ground truth location data of the UE. For example, a cell may be predicted from traffic data across the UP and N3 interface tunnel endpoints.

In other embodiments, the method may comprise using a second (trained) machine learning model to predict a cell associated with a subscriber. In such embodiments, the method may further comprise providing the predicted cell to the first machine learning model such that the first machine learning model may make the prediction of the congestion level in the user plane, UP, based on the data from the user plane function and the prediction of the predicted cell associated with the subscriber. The second machine learning model may comprise any of the machine learning models described with respect to the first machine learning model and the detail therein applies equally to the second machine learning model.

Using a predicted cell location in this way has the advantage of reducing the load on, for example the AMF 118 or MME as these no longer need to be signalled in order to obtain the subscriber cell information.

In block 306 the method comprises receiving from the first machine learning model a prediction of a congestion level in the user plane, UP, based on the data from the user plane function. As described above, in some embodiments the congestion level relates to congestion experienced on a cell in the communications network. In other embodiments the congestion level relates to congestion experienced by a subscriber (e.g. a user equipment, device or other user session).

Turning now to Fig. 4, in some embodiments there is a method 400 of training a first machine learning model to predict a congestion level in a user plane, UP, of a communications network. Briefly, the method 400 comprises in a first block 402 obtaining training data comprising (i) data from a user plane function, UPF, in the communications network, wherein the data from the UPF is related to traffic through the UPF, and (ii) corresponding ground truth congestion levels in the UP. In a second block 404 the method comprises training the first machine learning model to predict a congestion level in the UP, based on the training data. The method 400 may be performed by a function of the communications network. For example, in some embodiments the method 300 may be performed by a Network Data Analytics Function, NWDAF, 106 or by a User Plane Function, UPF, 102.

The method 400 may be performed in an on-line manner. For example, the method 400 may be performed in real-time on real time data in a semi-autonomous or fully autonomous way. For example, the block of obtaining 402 training data may comprise (for example the function performing the method 400) obtaining examples of data from the user plane function and corresponding ground truth congestion levels in the UP directly from the communications network. In such embodiments, the training data may be thus be obtained without human supervision.

Alternatively, the method 400 may be performed in an off-line manner, for example on a predefined or historical data set. It will be appreciated that the block of obtaining 402 training data may also comprise obtaining a combination of real-time and historical data.

In some embodiments, the first machine learning model may be trained to predict a cell congestion level. In such embodiments, the ground truth congestion levels in the obtained training data may comprise ground truth cell congestion levels.

In such embodiments training the first machine learning model to predict a congestion level in the UP comprises training the first machine learning model to predict a cell congestion level in the UP.

In some embodiments, cell congestion information may be obtained by requesting UP cell congestion information from a Network Manager which stores Operations Administration and Management, OAM data. The UP cell congestion information may thus be used as the ground truth congestion levels in the UP.

In other embodiments the ground truth congestion levels in the UP comprise ground truth subscriber congestion levels. In such embodiments training the first machine learning model to predict a congestion level in the UP thus comprises training the first machine learning model to predict a subscriber congestion level in the UP.

As described above with respect to method 300 to determine the subscriber congestion level, the subscriber location (e.g. associated cell) may be required.

As such, the method may further comprise obtaining cell location information and the step of training the first machine learning model to predict a congestion level in the UP, may be further based on the cell location information (e.g. in addition to the data from the user plane function).

Cell location information may be obtained, for example from an AMF 118, a Mobile Management Entity (MME) or a Radio Access Network, RAN, Operations Administration and Management, OAM. In some embodiments, cell location may be predicted, for example by a second machine learning model. Thus, in some embodiments, the method 400 may further comprise training a second machine learning model to predict a cell associated with a subscriber based on the data from the UPF and ground truth subscriber cell information. The ground truth subscriber cell information may comprise cell location information, for example obtained from AMF 118 or an MME as noted above. In some embodiments, the second machine learning model may learn by clustering UPF subscriber data served by different cells.

In some embodiments, the training data may therefore further comprise subscriber cell information and training the first machine learning model to predict a congestion level in the UP may thus be further based on the subscriber cell information.

Once the first and second machine learning models are trained in this manner, the output of the second machine learning model (e.g. the prediction of the associated subscriber cell location) may be input to the trained first machine learning model, along with the data from the UPF for the first machine learning model to predict the subscriber congestion level (as was described with respect to the method 300 above).

In some embodiments, the method 400 may further comprise validating the first and/or second machine learning models. The skilled person will be familiar with validation methods that may be used to confirm (or determine) the accuracy of trained machine learning models. For example a “test” or validation set of data comprising unseen training data (e.g. further examples of data in the same format as the training data but that were not used to train the machine learning model) may be provided to the machine learning model. The predictions of the machine learning model may be compared to the ground truth values of each piece of data in the validation set and the comparisons may be used to provide an accuracy score or profile for the machine learning model. For example, further training examples may be obtained and the method 400 may be repeated until the accuracy of the first machine learning model rises above a predetermined threshold. As described above, the validation and further training may be performed in an autonomous (or semi-autonomous manner) based on real-time data.

Turning now to more specific examples, in an example embodiment, where the communication network comprises a 3GGP network, because of the Radio Access Network (RAN) congestion aware scheduler, there is a direct correlation between RAN congestion level and the (a) packet round trip, due to the Radio Link Control (RLC) buffering and (2) downlink (DL) throughput variation due to the MAC priority scheduler for the different QOS traffic profiles. In this example, obtaining data may comprise obtaining traffic key performance indicators (KPI metrics) collected by the UPF which can report them to the NWDAF together with the associated international mobile subscriber identity (IMSI), QOS Class Identifier (QCI) and node B IP address (Extracted from N3 GTP-U (General Packet Radio Services (GPRS) Tunneling Protocol) tunnel header). These metrics can be processed by a machine learning model which can infer the cell within which each IMSI roams and the associated congestion level.

Another example embodiment is illustrated in Fig. 5. In this embodiment, the methods 300 and/or 400 are performed by a NWDAF 106. It will be appreciated that the NWDAF may perform solely method 300, solely method 400, or both methods 300 and 400, as described below. The NWDAF forms part of a 5GC communications network. A Radio Access Network (New Radio Access Network, NR) is shown in Fig. 5 by reference numeral 501.

The NWDAF may train a first machine learning model according to method 400. Training may be coordinated by a training module 510. Generally, the NWDAF may obtain 402 training data comprising (i) data from a user plane function, UPF, in the communications network, wherein the data from the UPF is related to traffic through the UPF, and (ii) corresponding ground truth congestion levels in the UP.

In this embodiment, obtaining 402 training data may comprise the NWDAF 106 requesting data from the user plane function 102 and receiving 502 the requested data from the UPF 102. The NWDAF may request and receive, for example, transport L4 KPIs, QOS flow measures and AN node ID information per UE from UPF 102.

Obtaining 404 training data may further comprise the NWDAF 106 requesting 504 subscriber (e.g. user equipment, UE) location information from an AMF 118. This information may be used to bind, in real-time a subscriber to a cell and may be used as ground truth subscriber location data. AMF load can be reduced or optimised by training the first machine learning model to map a subscriber to a cell.

Obtaining 404 training data may further comprise the NWDAF 106 requesting 506 data to be collected from a Network Manager 506a which stores Operations Administration and Management, OAM data regarding UP congestion. This may be used as ground truth location data. This information can be used to train the first machine learning model which detects UP congestion based on UPF data collected metrics.

In this embodiment, training 404 the first machine learning model (labelled 512 in Fig. 5) to predict a congestion level in the UP, based on the training data may comprise training a second machine learning model to predict a cell associated with a subscriber based on the data from the UPF and ground truth subscriber cell information. The second machine learning model (labelled 514 in Fig. 5) may be trained to predict a subscriber location from the UPF data collected. Since various cells have distinct capacity and radio characteristics, such model may cluster all subscriber flows within a NB (available through UP data “NB IP address”) with similar L4 KPIs into cells. The second machine learning model may be trained in an online (e.g. autonomous) manner by the NWDAF 106 using the network function data collected at 502, 504 and 506 above.

Training 404 the first machine learning model to predict a congestion level in the UP, based on the training data may further comprise providing the predicted cell to the first machine learning model to train the first machine learning model to predict a subscriber congestion level from the data from the UPF and the predicted cell associated with the subscriber.

In summary, from the data collected in stages 402 and 404, the NWDAF may train two machine learning models. A “second” machine learning model may be trained to predict a cell associated with a subscriber from UPF data and a “first” machine learning model may take the predicted cell and the UPF data as input and determine a congestion level for the subscriber.

Turning to the use of the trained models now, the NWDAF may further (additionally or alternatively) perform the method 300 described above.

Generally, the network function (NF), e.g. Policy Control Function (PCF) 114 interested on the actual congestion status for a specific UE, may request Congestion analytics information from the NWDAF using an existing 3GPP procedure. This is illustrated in the signalling diagram shown in Fig. 6 by the NF 602 signalling the NWDAF 106 with an analytics request 604. In the example shown in Fig. 6, the NF 602 is shown requesting one time reporting, however the skilled person will appreciate that the teachings herein apply equally to periodic reporting of congestion information analytics from the NWDAF. The proposed solution could also be used in cases where the NF requests user data congestion in a geographical area as will be described briefly below.

The NWDAF 106 receives the request from the NF 602. The NWDAF sends a signal 606 to the UPF 102 to trigger the UPF to send a signal 608 to the NWDAF comprising data from the UPF that is related to traffic through the UPF. As described above, this data may comprise performance measurements that are related to the transport protocol performance of information transfer over the user plane.

The NWDAF may further send a signal 610 to the AMF 118 to obtain the subscriber cell location. The AMF may send the requested information in signal 612.

In some embodiments, the subscriber cell location may be used to verify the result (e.g. a predicted location).

At 614 the NWDAF collects 614 the obtained data and provides it to the trained first machine learning model 512 to predict the congestion experienced by the subscriber. The NWDAF thus derives the requested analytics 616 and sends a signal 618 comprising the predicted congestion to the NF 602. In this manner, the NWDAF is therefore able to determine in real time the user plane congestion associated with a location and the user plane congestion of a subscriber using the new trained machine learning model 512 based on the collected UPF data collected and the subscriber location. Since cell congestion level correlates with L4 KPI for different QOS flows served by the cell, such machine learning models can infer the congestion level per location.

Note that if the network function (NF) 602 had requested user data congestion in a geographical area, the NWDAF 106 would just need to aggregate the congestion status for UEs in that geographical area; in such case UE reporting from the AMF 118 is optional, as the NWDAF can derive UE location from AMF, from UPF and N3 marking or from NB IP address reported by UPF.

Note that to report the congestion level per subscriber the NWDAF does not need to map the cell identifier to the Mobile Network Operator (MNO) administrative cell id. In case consumer NF needs cell id location an SMF implementation could encode the admin evolved NodeB id in the N3 GTP-U tunnel ID so NWDAF could infer the administrative cell id which is usually encoded based on the administrative eNodeB.

Further note that it can be that the NF wants to restrict congestion reporting based on location e.g. service area interface (SAI), in this case NWDAF could maintain a mapping of eNB Ip address to SAI configuration and detect congestion based on this filter.

Another embodiment is illustrated in Fig. 7. In this embodiment, the method 300 and/or the method 400 are performed on a User Plane Function (UPF) 102. It will be appreciated that the UPF 102 may perform solely method 300, solely method 400, or both methods 300 and 400, as described below. The UPF 102 forms part of a 5GC communications network.

In embodiments where cell id is not available to the UPF 102 (which may be the case unless RAN proprietary implementations which can e.g. convey cell id in GTP header) the UPF may determine (e.g in real-time) the cell associated with a subscriber (e.g. UE) using a trained machine learning model 706 (trained according to method 400 as described above) that maps cell location from collected UPF data. Since various cells have distinct capacity and radio characteristics, such model could cluster all subscriber flows within a NB with similar L4 KPIs.

Machine learning model 706 may be trained online at NWDAF 106 using Network Function collected data (as described above with respect to Fig. 5). Alternatively, machine learning model 706 may be trained offline and then provided to the UPF 102.

The UPF 102 determines in real time the user plane congestion associated with a location and a subscriber using trained machine learning model 708 (trained according to method 400) based on UPF data collected and subscriber location. Since cell congestion level correlates with L4 KPI for different QOS flows served by the cell, machine learning model 708 can infer congestion level per location. Machine learning model 708 can be trained online at NWDAF using OAM collected data as described above with respect to Fig.

5.

Service network 702 and Server 704 may be consumers of the predicted congestion levels in the user plane. For example, the UPF 102 may signal the congestion levels to service network 702 or server 704. The service network 702 may comprise, for example, a Transmission Control Protocol (TCP) optimizer in the service network; the server 704 may comprise an internet video server. It will be appreciated that these are merely examples however and that service network 702 and server 704 may comprise other service networks and/or other servers.

In the case that UPF 102 is an anchor (e.g. a reference for the traffic flow, where the mobile session terminates) it can apply local enforcements for the subscriber flows experiencing user plane congestion, e.g. it can shape or optimize those flows based on predefined policies. In addition, to provide end to end congestion management, UPF 102 can expose the congestion information to the SGi LAN nodes or end server node using well known packet marking methods.

In the case of local breakout, if the UPF is able to predict the congestion (e.g. if the UPF acts as classifier) it can mark congestion information in the N9 interface, e.g. using Explicit Congestion Notification (ECN), Differentiated services (Diffserv) or GPRS Tunnelling Protocol (e.g. GTP-U) info marking (e.g. QFI reserved bits). Thus if the UPF can predict congestion according to the methods herein, the UPF can send this information and forward the traffic to the next node.

Turning now to other embodiments, fig. 8 illustrates a Network Function (NF) 800 for predicting a congestion level in the user plane. The NF comprises processing circuitry (or logic) 802. It will be appreciated that the NF 800 may comprise one or more virtual machines running different software and/or processes. The NF 800 may therefore comprise one or more servers, switches and/or storage devices and/or may comprise cloud computing infrastructure that runs the software and/or processes. The NF 800 may comprise a UPF 102 or a NWDAF 106 as described above.

The processing circuitry 802 controls the operation of the NF 800 and can implement the method described herein in relation to an NF 800. The processing circuitry 802 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the NF 800 in the manner described herein. In particular implementations, the processing circuitry 802 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method 300 as described herein.

Briefly, the processing circuitry 802 of the NF 800 is configured to: obtain data from a user plane function, UPF, related to traffic through the UPF; provide the data from the UPF as input to a first machine learning model, and receive from the first machine learning model a prediction of a congestion level in the user plane, UP, based on the data from the user plane function.

Obtaining data from a UPF, providing the data to a first machine learning model and receiving from the first machine learning model a prediction of a congestion level, were all described above with respect to the method 300 and the details therein will be understood to apply equally to the operation of the NF 800.

In some embodiments, the NF 800 may optionally comprise a communications interface 804. The communications interface 804 of the NF 800 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 804 of the NF 800 can be configured to transmit to and/or receive from other nodes or network functions requests, resources, information, data, signals, or similar. The processing circuitry 802 of NF 800 may be configured to control the communications interface 804 of the NF 800 to transmit to and/or receive from other nodes or network functions requests, resources, information, data, signals, or similar.

Optionally, the NF 800 may comprise a memory 806. In some embodiments, the memory 806 of the NF 800 can be configured to store program code that can be executed by the processing circuitry 802 of the NF 800 to perform the method 300 described herein. Alternatively or in addition, the memory 806 of the NF 800, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 802 of the NF 800 may be configured to control the memory 806 of the NF 800 to store any requests, resources, information, data, signals, or similar that are described herein.

Fig. 9 illustrates a further Network Function (NF) 900 comprising processing circuitry (or logic) 902. The NF 900 is for training a first machine learning model to predict a congestion level in a user plane, UP, of a communications network. It will be appreciated that the NF 900 may also comprise one or more virtual machines running different software and/or processes. The NF 900 may therefore comprise one or more servers, switches and/or storage devices and/or may comprise cloud computing infrastructure that runs the software and/or processes. The NF 900 may comprise a UPF 102 or a NWDAF 106 as described above.

The processing circuitry 902 controls the operation of the NF 900 and can implement the method described herein in relation to an NF 900. The processing circuitry 902 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the NF 900 in the manner described herein. In particular implementations, the processing circuitry 902 can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method 400 as described herein.

Briefly, the processing circuitry 902 of the NF 900 is configured to obtain training data comprising (i) data from a user plane function, UPF, in the communications network, wherein the data from the UPF is related to traffic through the UPF, and (ii) corresponding ground truth congestion levels in the UP. The processing circuitry 902 is further configured to train the first machine learning model to predict a congestion level in the UP, based on the training data.

Obtain training data and training a first machine learning model were all described above with respect to the method 400 and the details therein will be understood to apply equally to the operation of the NF 900.

In some embodiments, the NF 900 may optionally comprise a communications interface 904. The communications interface 904 of the NF 900 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 904 of the NF 900 can be configured to transmit to and/or receive from other nodes or network functions requests, resources, information, data, signals, or similar. The processing circuitry 902 of NF 900 may be configured to control the communications interface 904 of the NF 900 to transmit to and/or receive from other nodes or network functions requests, resources, information, data, signals, or similar.

Optionally, the NF 900 may comprise a memory 906. In some embodiments, the memory 906 of the NF 900 can be configured to store program code that can be executed by the processing circuitry 902 of the NF 900 to perform the method 400 described herein. Alternatively or in addition, the memory 906 of the NF 900, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry 902 of the NF 900 may be configured to control the memory 906 of the NF 900 to store any requests, resources, information, data, signals, or similar that are described herein.

Turning now to another embodiment, there is also a computer program product comprising computer readable medium the computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform any of the embodiments of the method 300 or the method 400 as described above.

Thus, it will be appreciated that the disclosure also applies to computer programs, particularly computer programs on or in a carrier, adapted to put embodiments into practice. The program may be in the form of a source code, an object code, a code intermediate source and an object code such as in a partially compiled form, or in any other form suitable for use in the implementation of the method according to the embodiments described herein. It will also be appreciated that such a program may have many different architectural designs. For example, a program code implementing the functionality of the method or system may be sub-divided into one or more sub-routines. Many different ways of distributing the functionality among these sub-routines will be apparent to the skilled person. The sub-routines may be stored together in one executable file to form a self-contained program. Such an executable file may comprise computer-executable instructions, for example, processor instructions and/or interpreter instructions (e.g. Java interpreter instructions). Alternatively, one or more or all of the sub-routines may be stored in at least one external library file and linked with a main program either statically or dynamically, e.g. at run time. The main program contains at least one call to at least one of the sub-routines. The sub routines may also comprise function calls to each other.

The carrier of a computer program may be any entity or device capable of carrying the program. For example, the carrier may include a data storage, such as a ROM, for example, a CD ROM or a semiconductor ROM, or a magnetic recording medium, for example, a hard disk. Furthermore, the carrier may be a transmissible carrier such as an electric or optical signal, which may be conveyed via electric or optical cable or by radio or other means. When the program is embodied in such a signal, the carrier may be constituted by such a cable or other device or means. Alternatively, the carrier may be an integrated circuit in which the program is embedded, the integrated circuit being adapted to perform, or used in the performance of, the relevant method.

Variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. A single processor or other unit may fulfil the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. A computer program may be stored/distributed on a suitable medium, such as an optical storage medium or a solid-state medium supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems. Any reference signs in the claims should not be construed as limiting the scope.

Claims

1. A method in a communications network, wherein the method comprises: obtaining data from a user plane function, UPF, related to traffic through the

UPF; providing the data from the UPF as input to a first machine learning model; and receiving from the first machine learning model a prediction of a congestion level in the user plane, UP, based on the data from the user plane function.

2. A method as in claim 1 wherein the prediction of a congestion level in the UP comprises a prediction of Radio Access Network, RAN, congestion.

3. A method as in claim 1 or 2 wherein the congestion level relates to congestion experienced by a subscriber.

4. A method as in claim 1 or 2 wherein the congestion level relates to congestion experienced on a cell in the communications network.

5. A method as in any one of claims 1 to 4 wherein the first machine learning model has been trained to predict the congestion level based on training data comprising examples of data from the UPF related to traffic through the UPF and corresponding ground truth congestion in the UP.

6. A method as in any one of claims 1 to 5 wherein the first machine learning model has been further trained to predict a cell associated with a subscriber based on training data comprising examples of data from the UPF related to traffic through the UPF and corresponding ground truth location data of the UE.

7. A method as in any one of claims 1 to 5 further comprising: providing the data from the UPF as input to a second machine learning model; receiving from the second machine learning model a prediction of a cell associated with a subscriber, based on the data from the user plane function; and providing the predicted cell as a further input to the first machine learning model such that the first machine learning model may further make the prediction of the congestion level in the user plan based on the predicted cell.

8. A method as in any one of claims 1 to 7 wherein the method is performed by one of: a Network Data Analytics Function, NWDAF; or the UPF.

9. A method as in any one of claims 1 to 8 wherein the data from the UPF relates to transport protocol performance of information transfer over the UP.

10. A method as in any one of claims 1 to 9 wherein the data from the UPF comprises one or more of the following: an indication of a transport layer 4 Key Performance Indicator, KPI; an indication of a Quality of Service, QOS flow; and an indication of an Access Node, AN, ID.

11 . A method of training a first machine learning model to predict a congestion level in a user plane, UP, of a communications network, the method comprising: obtaining training data comprising (i) data from a user plane function, UPF, in the communications network, wherein the data from the UPF is related to traffic through the UPF, and (ii) corresponding ground truth congestion levels in the UP; and training the first machine learning model to predict a congestion level in the UP, based on the training data.

12. A method as in claim 11 wherein the ground truth congestion levels in the UP comprise ground truth cell congestion levels; and training the first machine learning model to predict a congestion level in the UP comprises training the first machine learning model to predict a cell congestion level in the UP.

13. A method as in claim 11 wherein the ground truth congestion levels in the UP comprise ground truth subscriber congestion levels; and training the first machine learning model to predict a congestion level in the UP comprises training the first machine learning model to predict a subscriber congestion level in the UP.

14. A method as in claim 13 further comprising: training a second machine learning model to predict a cell associated with a subscriber based on the data from the UPF and ground truth subscriber cell information.

15. A method as in claim 14 wherein the second machine learning model learns by clustering UPF subscriber data served by different cells.

16. A method as in any one of claims 11 to 15 wherein the training data further comprises: subscriber cell information and wherein training the first machine learning model to predict a congestion level in the UP is further based on the subscriber cell information.

17. A method as in claim 16 further comprising: requesting subscriber cell information from one of: an Access and Mobility Management Function, AMF; a Mobile Management Entity; and a RAN OAM.

18. A method as in any one of claims 11 to 17 wherein the step of obtaining training data comprises: requesting UP cell congestion information from a Network Manager which stores Operations Administration and Management, OAM data; and using the UP cell congestion information as the ground truth congestion levels in the UP.

19. A method as in any one of claims 11 to 18 wherein the step of obtaining training data comprises: requesting one or more of: an indication of a transport layer 4 Key Performance Indicator, KPI; an indication of a Quality of Service, QOS flow; and an indication of an Access Node, AN, ID; from the UPF.

20. A method as in any one of claims 11 to 19 wherein the method is performed by one of: a Network Data Analytics Function, NWDAF; and the UPF.

21 . A network function in a communications network, the network function comprising processing circuitry configured to: obtain data from a user plane function, UPF, related to traffic through the UPF; provide the data from the UPF as input to a first machine learning model; and receive from the first machine learning model a prediction of a congestion level in the user plane, UP, based on the data from the user plane function.

22. A network function in a communications network, the network function comprising processing circuitry configured to: obtain training data comprising (i) data from a user plane function, UPF, in the communications network, wherein the data from the UPF is related to traffic through the UPF, and (ii) corresponding ground truth congestion levels in the UP; and train the first machine learning model to predict a congestion level in the UP, based on the training data.

23. A computer program product comprising computer readable medium the computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method as claimed in any one of claims 1 to 20.