TECHNICAL FIELD

[001] The present disclosure relates to resource usage and optimization in a network.

BACKGROUND

[002] Third Generation Partnership Project (3 GPP) Technical Specification (TS)

23.203 and TS 23.503 set out high level principles for policy control across domains and interaction with Application Functions (AFs), such as AFs in IP Multimedia Subsystem (IMS).

[003] GSM/UMTS/EPC/5GC networks such as the evolved packet core (EPC) and Fifth Generation Core Network (5GC), provide functions that implement policy control mechanisms to control QoS and/or charging for services provided to users/subscribers. Such services include real-time services provided by the IMS, streaming services, web services or the like. In order to support these policy mechanisms, the network performs real-time monitoring of resource usage to detect the relevant policy enforcement events.

[004] In Policy Control, a subscriber account, located in a Policy Control Function (PCRF in EPC or PCF in 5GC), is queried prior to granting permission to use a requested network resource(s). To further elaborate, Policy Control comprises a process where policy information for network resource usage is collected. However, authorization for the network resource usage must be obtained by the network prior to the actual resource usage to occur. This authorization is granted by the PCRF/PCF upon request from the network (e.g., EPC or 5GC). The PCRF/PCF is responsible for Policy Control of network/user sessions, e.g. IP CAN bearers, IP CAN sessions, or IMS sessions such as voice/video calls.

[005] For session-based policy control or dynamic policy, an“initial” event (e.g., session start) is transferred to the PCRF/PCF e.g. via the Gx or Sd reference point and the start of the user session is authorized after successfully performing policy control on the subscriber account. As there is no information available at this time concerning the overall evaluation of the session (e.g. complete duration or data volume of the session), session-based policy control is done based on static or pre-configured rules. The PCRF/PCF provides the allowed bandwidth and allowed access information to the Policy and Charging Enforcement Function (PCEF) or Session Management Function (SMF) in 5GC, The PCEF/SMF, in turn, uses the provided information to supervise the actual network resource consumption.

SUMMARY

[006] Generally, in this description, where embodiments are described with a 4G policy framework, such embodiments are also applicable to a 5G policy framework, and vice versa.

[007] For session-based policy control, the start of the user session is authorized by the PCRF after successfully performing policy control on the subscriber account. The allowed bandwidth and allowed access is statically defined in PCRF and might not provide the optimized policy control depending upon particular session-level details.

[008] For example, consider a user that is browsing an application store (e.g., App store). The user intends to download a specific application such as the“WhatsApp” installer. Let us say that WhatsApp application installer is 50 MB and suppose that the cell will probably become congested (or is already congested) during the download process. If this information (e.g., download size, congestion condition) is provided to the PCRF, then the PCRF can dynamically take preventive action like increasing the bandwidth or looking for another access type (such as non-3GPP, Wi-Fi), or changing radio frequency as per the dynamic network condition.

[009] To continue the example further, the congestion condition may get even more critical in case a subscriber is downloading or streaming a movie or watching some live event such as a football match. Download size in such cases will be more than 100MB and duration of the download session will be more than an hour.

[0010] Currently, the PCRF is not able to predict the congestion based on the download requirement of users at session level. Also, if there is predicted upcoming congestion in a cell based on historical data, the PCRF is not able to take any pre-emptive measures based on that prediction, due to non- visibility of user-plane information i.e. expected duration of sessions, especially for long sessions. [0011] In a co-owned application, WO2018/033777, a mechanism between UE and EPC is provided for exchanging user download information. In that application, it is proposed to dynamically change the reservation based on the intended data session duration/size (e.g. downloadable size for respective sessions) parameter. The UE provides an intended data session duration/size (downloadable size parameter) to the MME as a part of service request The MME then provides this parameter to the PCRF over a proprietary Smp interface for policy related evaluation.

[0012] Whenever a user initiates the download (such as downloading the“Whatsapp” Installer (e.g. 50 MB) or streaming a movie (e.g. 700MB)) the respective information on application installer size is communicated to the UE on the application layer and is available at the UE. Further, the UE provides the downloadable size information to the Mobility

Management Entity (MME) on the control plane. The MME provides this information to the PCRF over a proprietary Sx (Smp) interface for policy based decision. The PCRF then either forwards this information to the online charging system (OCS) for credit reservation directly or via the packet gateway (PGW). The OCS finally decides on credit reservation based on this information. If there are not sufficient funds available in the subscriber account, the OCS may either reject the request or prompt the subscriber to recharge in order to have a sufficient balance for the download. If the subscriber has sufficient funds, then the OCS allows the download and grants the credit reservation as per the download size to reduce the signaling between the PGW and OCS. This information is used to by the OCS to provide a dynamic credit quota based on downloadable size, to reduce the signaling between the OCS and PGW.

[0013] As described in WO2018/033777, this information (intended downloadable size) is available with the PCRF. Currently, the OCS is using this information for better credit reservation. Embodiments herein describe other applications for this data. For example, “downloadable size” can be used by the EPC (especially the PCRF) to solve problems related to core network signaling and radio access congestion. The PCRF manages policies for the user session but currently is not using session details to provide the network with situation specific policies. These policies can be used to predict congestion, to manage congestion in better way, to improve user experience and to collate data for network-level improvements. [0014] Embodiments provide ways to exploit the usage of this type of information (e.g. intended downloadable size for a respective user session and/or estimated session duration information) which is already available with the PCRF for further network-level optimization. Currently this information is used primarily in the charging domain, but it is not leveraged for other useful optimizations. As noted above, downloadable size information may be provided by the UE to the MME, and by the MME to the PCRF. Alternatively, downloadable size information can be provided by the application distribution server (ADS) or by the Application Function (AF) to the PCRF, e.g. via a network exposure function (NEF). Embodiments are not limited to a particular network standard, and are applicable for example to at least 4G or 5G networks. Similarly, while downloading content is discussed at times, streaming such content is also within the scope of provided embodiments.

[0015] One example of this optimization is data session optimization that may be provided with this information. Typically, a data session to websites such as YouTube, Netflix, Apple App store, or Google Play, publish the intended size/duration of the expected download or streaming session, which means that a third-party product (3PP) application function publishes such information. For a live event, such as a football match, for example, an expected duration may be known.

[0016] Such data size/duration information for ongoing or new sessions to the PCRF may be communicated to the PCRF in a number of ways. For example, the UE may communicate the information to the MME on a modified control plane, and the MME may further communicate this information to the PCRF. Also, data size/duration information for the session may be provided by the application function (AF) to the PCRF (e.g. via an NEF or service capability exposure function (SCEF)). As noted above, 5G nodes may also be used, in which case for example the data size/duration information may be communicated to the policy and control function (PCF) e.g. via the access and mobility management function (AMF).

[0017] The PCRF (or PCF or other node) can exploit this information for various use cases. Three examples include: (1) Avoiding radio access network (RAN) or cell-level congestion for ongoing user sessions. For instance, the user session bandwidth could be adapted (e.g. increased) so that a download can be completed prior to an expected congestion occurs. Or a user session could be offloaded from the 3 GPP access to a non-3GPP access (such as Wi-Fi) in order to manage the cell congestion (e.g. via access network discovery and selection function (ANDSF) functionality). (2) Avoiding RAN or cell-level congestion for new user sessions. For instance, radio frequency (e.g. RAT/Frequency Selection Priority (RFSP)) may be modified for new user sessions to manage congestion. (3) Avoiding network level congestion. For instance, predictive congestion data may be provided to the network data analytics function (NWDAF) for analysis and congestion related actions at a network level.

[0018] Embodiments will provide many advantages, such as improving congestion.

The PCRF (or PCF or other node) may use the user session information with historic congestion information to better manage the expected radio congestion. The PCRF (or PCF or other node) may use and aggregate the information (e.g. as provided by the UE(s), AF(s) or otherwise) to predict the potential radio congestion and take real-time remedial measures. The PCRF (or PCF or other node) may also provide the predicted congestion data to network analytics and network exposure functions, such as the NWDAF, so that those functions can inform other appropriate functions such as the policy charging function or network slice selection function (NSSF) function of probable network congestion, e.g. congestion expected in respective network slices, and therefore direct such functions to perform appropriate dynamic decision making based on such congestion information.

[0019] According to a first aspect, a method, performed by a network node (e.g. a network data analytics function (NWDAF)) is provided. The method includes receiving first congestion prediction information from a first node (e.g. a policy control function (PCF)) for a first location (e.g., cell and/or tracking area). The first congestion prediction information includes an expected data size or duration for a content to be downloaded /streamed and/or is derived from the expected data size or duration for the content to be downloaded/streamed. The method further includes determining that a congestion condition exists for one or more locations (e.g., cells and/or tracking areas) based at least in part on the first congestion prediction information. The method further includes, in response to determining that the congestion condition exists for one or more locations (e.g., cells and/or tracking areas), modifying available network resources based on the congestion condition.

[0020] In embodiments, modifying available network resources based on the congestion condition comprises modifying network slice dimensioning (e.g. ramping up/down resources for network slices such as compute, storage, radio perspective, etc.). In embodiments, modifying available network resources based on the congestion condition comprises providing a cache for content that is expected to be accessed by multiple users in a given location. In embodiments, modifying available network resources based on the congestion condition comprises determining that an edge server should be deployed at a given location to ease the congestion condition.

[0021] In embodiments, the method further includes receiving second congestion prediction information from a second node (e.g. a PCF) for a second location (e.g. cell and/or tracking area). Determining that a congestion condition exists for one or more locations (e.g., cells and/or tracking areas) is further based at least in part on the second congestion prediction information. In embodiments, the method further includes aggregating congestion prediction information (e.g., first and second congestion prediction information). Determining that a congestion condition exists for one or more locations (e.g. cells and/or tracking areas) is further based at least in part on the aggregating congestion prediction information.

[0022] In embodiments, the method further includes correlating the aggregated congestion prediction information with historical congestion information (e.g., at what time various tracking areas and/or locations typically are congested, typical level of congestion, typical type of call (e.g., voice / data)). Determining that a congestion condition exists for one or more locations (e.g., cells and/or tracking areas) is further based at least in part on the correlating the aggregated congestion prediction information with historical congestion information. In embodiments, the first congestion prediction information includes a total download/streaming requirement for the cell.

[0023] In embodiments, the first congestion prediction information includes one or more of the following: (i) AF location information; (ii) download/streaming data information (e.g., size/duration/application details); (iii) user location information (e.g., cell and/or tracking area); (iv) network slice information and attached network functions (NFs) information (e.g., access management function (AMF) / session management function (SMF)); and (v) predictive cell congestion and duration information (e.g. 5000 users with 10 minute long session expected). [0024] According to a second aspect, a method, performed by a network node serving a cell (e.g. a policy control function (PCF)) is provided. The method includes receiving user session information including an expected data size or duration for a content to be

downloaded/streamed; and sending congestion prediction information to a node (e.g. a network data analytics function (NWDAF)), the congestion prediction information being based on the user session information.

[0025] In embodiments, the user session information is received from a session management function (SMF) based on data provided by a user equipment (UE). In

embodiments, the user session information is received from an application function (AF). In embodiments, the method further includes aggregating further user session information including further expected data size or duration for further content to be downloaded/streamed. In embodiments, the method further includes calculating a total download/streaming requirement for the cell.

[0026] In embodiments, the method further includes receiving historical congestion information from a radio congestion aware function (RCAF); and correlating the user session information with historical congestion information. The congestion prediction information is based at least in part on the results of such correlating.

[0027] In embodiments, the congestion prediction information includes one or more of the following: (i) AF location information; (ii) download/streaming data information (e.g., size/duration/application details); (iii) user location information (e.g., cell and/or tracking area); (iv) network slice information and attached network functions (NFs) information (e.g., access management function (AMF) / session management function (SMF)); and (v) predictive cell congestion and duration information (e.g. 5000 users with 10 minute long session expected).

[0028] According to a third aspect, a network node (e.g., a network analytics function (NWDAF)) adapted to perform any one of the embodiments of the first aspect is provided..

[0029] According to a fourth aspect, a network node (e.g., a policy control function (PCF)) adapted to perform any one of the embodiments of the second aspect is provided.

[0030] According to a fifth aspect, a network node (e.g., a network analytics function (NWDAF)) is provided. The network node includes a receiving unit configured to receive first congestion prediction information from a first node (e.g. a policy control function (PCF)) for a first location (e.g., cell and/or tracking area). The first congestion prediction information includes an expected data size or duration for a content to be downloaded /streamed and/or is derived from the expected data size or duration for the content to be downloaded/streamed.

The network node further includes a determining unit configured to determine that a congestion condition exists for one or more locations (e.g., cells and/or tracking areas) based at least in part on the first congestion prediction information; and a modifying unit configured to, in response to determining that the congestion condition exists for one or more locations (e.g., cells and/or tracking areas), modify available network resources based on the congestion condition.

[0031] According to a sixth aspect, a network node (e.g., a policy control function (PCF)) is provided. The network node includes a receiving unit configured to receive user session information including an expected data size or duration for a content to be

downloaded/streamed; and a sending unit configured to send congestion prediction information to a node (e.g. a network data analytics function (NWDAF)), the congestion prediction information being based on the user session information.

[0032] According to a seventh aspect, a computer program comprising instructions which when executed by processing circuity of a node causes the node to perform the method of any one of the first or second aspects is provided.

[0033] According to an eighth aspect, a carrier containing the computer program of any embodiment of the seventh aspect is provided, where the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium.

BRIEF DESCRIPTION OF THE DRAWINGS

[0034] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments.

[0035] FIG. 1 illustrates a message diagram according to an embodiment

[0036] FIG. 2 illustrates a message diagram according to an embodiment [003h FIG. 3 illustrates a message diagram according to an embodiment

[0038] FIG. 4 illustrates a message diagram according to an embodiment

[0039] FIG. 5 illustrates a message diagram according to an embodiment

[0040] FIG. 6 is a flow chart illustrating a process according to an embodiment.

[0041] FIG. 7 is a flow chart illustrating a process according to an embodiment.

[0042] FIG. 8 is a diagram showing functional units of a node according to an embodiment.

[0043] FIG. 9 is a diagram showing functional units of a node according to an embodiment.

[0044] FIG. 10 is a block diagram of a UE and/or network node according to an embodiment.

DETAILED DESCRIPTION

[0045] FIG. 1 shows a message diagram according to an embodiment. FIG. 1 illustrates user session information being provided to the PCRF by either the UE or the ADS via the NEF/SCEF. While 4G nodes such as the MME are described with respect to FIG. 1 (or other figures), other network standards may be applicable, for example 5G nodes such as the AMF could also be used. The following is a brief description of the steps in the call flow:

[0046] 110. The UE initiates a normal attach procedure to an access point (AP), with the Internet AP name (APN) being the default APN.

[0047] 112. The UE makes a selection of an application to download/stream. The UE fetches the application size, if this is permissible or possible to do. In this case this is possible to do. The UE identifies ADS information (e.g. the Application Server IP address, from where the application is downloaded), and also identifies the downloadable size (DS) of the application, as well as other optional information such as a rating for the application and the UE OS. While this example focusses on downloading an application (e.g., the“WhatsApp” installer previously described), the UE may choose to download or stream any content. Also, while DS of the application is included here, the UE may alternatively, or in addition, determine an estimated duration of the user session. Further, in this example the UE determines this user session information and informs the PCRF, however the PCRF may also acquire this information from another node in the network.

[0048] 113. The UE then initiates a service request (e.g., a non-access stratum (NAS) service request) for a download. The request includes the tuples to be enforced by the PGW, and the actual size of the application to be downloaded.

[0049] 114. The MME issues a request to the PCRF including the information received from the UE. Instead of the MME sending the download size information to the PCRF, the PCRF may receive such information from the ADS via the NEF/SCEF. This is reflected in an alternative call path 115 described below.

[0050] 115. The ADS identifies that there is a large session based on size or time. The ADS provides the relevant information (e.g. App size, ADS details) to the network, here providing the information to the NEF/SCEF. The NEF/SCEF checks that this session is managed by a particular PCRF and then provides this information to that particular PCRF.

[0051] Once the PCRF receives this information, whether from the UE/MME or the NEF/SCEF/ADS, the PCRF may receive additional congestion information including current and historical congestion information. This includes information internal to the PCRF, or stored in an internal database, as well as external information such as congestion data from the operations support system (OSS) and/or RAN congestion awareness function (RCAF). The PCRF then checks the user session information and congestion information it has received and takes appropriate action to ensure optimal user experience, such as by managing congestion as described below. Three principal examples of managing congestion are described: (1) Avoiding radio access network (RAN) or cell-level congestion for ongoing user sessions. (2) Avoiding RAN or cell-level congestion for new user sessions. (3) Avoiding network level congestion. For simplicity, in the message call diagrams that follow, the user session information (e.g. downloadable/streaming size and/or duration information) is provided by the UE, but in each use-case described such information can be provided by other mechanisms such as being provided by the ADS.

[0052] (1) Avoiding radio access network (RAN) or cell-level congestion for ongoing user sessions.

[0053] In this embodiment, the PCRF (or PCF or other node) uses user session information (e.g., downloadable/streaming size and/or duration information) and the existing congestion information to avert the congestion situation. Existing congestion situation is available to the PCRF through other network nodes such as the OSS or RACF. This data includes the average historic congestion time for each cell. For example, in certain

geographical areas there are many subscribers using data services at certain peak times, causing heavy congestion. Examples may include 9AM or 5PM for some office environments, or 3PM for some cafeterias. This historic information of congestion in certain cells at certain times can be used to better manage the congestion situation.

[0054] As an example, consider a user browsing an App store. The user intends to download a specific application. Assume that the installer is of 300 MB size and that this information is provided to the PCRF. (Alternatively, or in addition, the user may intend to download or stream other content like a movie or a real-time event.) The PCRF can check the congestion data for the cell; suppose that the PCRF determines that currently the cell is uncongested but historically congestion starts at 5:00 PM The user initiates the request at 04:50 PM. With the user’s subscribed bandwidth of e.g. 32 kbps, this download will continue after the expected cell congestion begins. After the congestion starts, the user may not even get the subscribed bandwidth due to the congestion. This will worsen the user’s experience. Also, other users will also have worse experiences due to the congestion situation.

[0055] There are two options suggested to improve this situation: modify the user’s bandwidth to cause the download to be completed sooner than otherwise, or offload the user’s session to another access such as Wi-Fi.

[0056] The first option addressed here is that the bandwidth of the subscriber may be increased so as to allow the subscriber to finish the download before congestion begins. That is, to improve this situation, the PCRF (or PCF or other node) may temporarily increase the user’s bandwidth to a higher rate (e.g. 1Mbps) even if the subscriber is not entitled to this bandwidth in the existing base station system (BSS) package. This may allow the user to complete or substantially complete the download before start of the congestion, thereby improving the user experience for the downloading user. This will also improve the user experience of other users due to reduced congestion, e.g. because of a lower data requirement in the cell across ongoing sessions. In this scenario, bandwidth is increased based on the expected congestion situation. This option is most appropriate for users that are performing a download action, such as downloading an application from an App store. If a user is streaming a movie for real-time playback or watching a live sporting event, then it may be more appropriate to offload the user’s session to another access such as Wi-Fi, which is described further below.

[0057J FIG. 2 shows a message diagram according to an embodiment. FIG. 2 illustrates when the bandwidth is increased for the user based on downloadable size. The following is a brief description of the steps in the call flow:

[0058] 110-114. These messages are described above with respect to FIG. 1.

[0059] The PCRF checks the historic congestion information for the cell. This can be checked from an internal database and/or external database. This could be checked with traditional nodes in operators such as nodes like the RCAF or OSS, having details of congestions at eNodeB, cells, etc. The PCRF calculates the expected time to be completed based on the subscribed bandwidth. If the subscriber’s download will progress beyond the start of the congestion time, the PCRF decides to increase the bandwidth of the session so as to complete the download before the start of the congestion.

[0060] 115*. This information is provided in a re-authorization request (RAR) message over the Gx interface along with the rules including the tuples associated with the application and the actual size. If there is congestion in the current cell already then that information will be provided by the RCAF in real time. In absence of such a trigger it is assumed that there is no congestion in the network. If this trigger is received that means that congestion has already started in the cell and further action on subscriber bandwidth is not taken.

[0061] 116. Optionally, the PGW can send another credit control request (CCR) after receiving the RAR message to get the same information in a credit control answer (CCA). The PGW initiates a request to the OCS with the received size.

[0062] 117. The OCS may secure credit reservation in accordance with the download size.

[0063] 118. The PGW receives a response acknowledging that the credit is available.

[0064] 119. A reauthorization answer (RAA) message is then sent back to the PCRF.

[0065] 120, 121. The PCRF forwards a reservation authorization response back to the MME which then sends a service response back to the UE.

[0066] 122-124. Downloading can then start. The PCRF allows the user to download the data from the PGW at a higher bandwidth.

[0067] 125-128. Download is complete or substantially complete before the start of the congestion time. A download complete notification is provided to the network by UE.

[0068] The second option addressed here is that the user session may be offloaded from 3GPP access to non-3GPP access (such as Wi-Fi) in order to manage the cell congestion via ANDSF functionality. That is, to improve the congestion situation, the PCRF may offload such subscribers to a non-3GPP access such as Wi-Fi wherever such options are available. By offloading to Wi-Fi access, the congestion situation for the users may be averted. This will reduce the congestion due to the users for which upcoming usage data is available with downloadable size information. Traffic can be offloaded to other accesses based on the ANDSF. With this approach, the PCRF can trigger the UE offload request to the ANDSF, which can co-ordinate with the UE for access reselection. The PCRF can trigger the MME over a proprietary Smp interface. In this scenario, the PCRF notifies the ANDSF about the congestion situation and the ANDSF notifies the UE to move to Wi-Fi access.

[0069] FIG. 3 shows a message diagram according to an embodiment. FIG. 3 illustrates when a user is offloaded to non-3GPP access based on downloadable size. The following is a brief description of the steps in the call flow:

[0070] 110-114. These messages are described above with respect to FIG. 1.

[0071] The PCRF checks congestion information for the cell, as already described. The PCRF calculates the expected time to be completed based on the subscribed bandwidth. If the subscriber download will progress beyond the start of congestion time, the PCRF decides to offload the session to Wi-Fi access so as to complete the download without RAN congestion. To do this, the PCRF provides the relevant subscriber and congestion information to the ANDSF. This can be done by sending a trigger message to the ANDSF or by updating the information in a common database (not shown). The ANDSF, based on internal logic, can access that database to check the congestion situation and UE information. If there is congestion in the current cell already then that information will be provided by the RCAF in real time. In the absence of such a trigger it is assumed that there is no congestion in the network. If this trigger is received that means that congestion has already started in the cell and offloading to WiFi access is continued.

[0072J The PGW initiates a request to the OCS with the received size (not shown).

[0073] The ANDSF changes the policies in the UE based on the si 4 interface, e.g. as specified in 3GPPS TS 23.402 & 3 GPP TS 24.312. The ANDSF stores the congestion information for future policy evaluation. The UE changes to Wi-Fi access for this session and data is downloaded over Wi-Fi access using Wi-Fi gateway (GW).

[0074] 124. Downloading can then start. A download complete notification may be provided to the network by the UE.

[0075] Note that information exchange between the PCRF and the ANDSF is not standardized.

[0076] (2) Avoiding RAN or cell-level congestion for new user sessions.

[0077] In this embodiment, the PCRF (or PCF or other node) may aggregate the user session information (e.g. downloadable/streaming size and/or duration information) for some or all of the UEs in the network. This information may be used to predict which cells will be having many subscribers downloading or streaming large amounts of data in a current or future time period, e.g. during the next few minutes. This will indicate the upcoming congestion state (e.g. congested or not congested, or some finer granularity of congestion). The PCRF (or PCF or other node) can correlate this information with the historic congestion data for the area (e.g., tracking area and/or cell) and take corrective measures based on this.

[0078] Based on the above prediction, the PCRF can request the MME to change the frequency selection of new connections to avoid the congestion situation. For some or all all of the new connections in that cell, the PCRF can change the service profile identifier

(SPID)/RFSP-Index wherever available to a less congested radio frequency (RF). This may be achieved over a proprietary Smp interface between the PCRF and the MME. In this scenario, the PCRF aggregates the information it receives from multiple users and predicts the congestion based on that. Likewise, the PCF in a 5G network may communicate with the AMF to change a user session to a less congested RF for new user sessions.

[0079] FIG. 4 shows a message diagram according to an embodiment. FIG. 4 illustrates when a frequency selection policy is changed for a new user session based on congestion information. The following is a brief description of the steps in the call flow:

[0080] 110-114. These messages are described above with respect to FIG. 1.

[0081] The PCRF checks congestion information for the cell, as already described. In this case, it is assumed that the PCRF does not increase the bandwidth of the subscriber to avoid the congestion situation. Alternatively, if the PCRF does increase the bandwidth of the subscriber, it may determine that even when doing so congestion will still occur such that new user sessions should be modified.

[0082] 115'-123. These messages are described above with respect to FIG. 2.

[0083] The PCRF aggregates some or all such reservation authorization requests with user session information (e.g. downloadable/streaming size and/or duration information) and calculates a total download requirement in the cell. For example, the PCRF may calculate a total download requirement in the cell and then determine that a congestion situation for the current frequency band that is used will occur for a given time window. The PCRF is able to calculate the duration of the congestion from the subscribed bandwidth and user session information. The PCRF correlates this information with historical data and information e.g. from the RCAF. Based on the above inputs, the PCRF may decide that for the duration of this predicted congestion all new users should use another radio access technology (RAT) or another radio frequency to connect to the core network, if such an option is available. This information is passed for new session requests to the SGSN-MME over a proprietary Smp interface with the RFSP parameter. That is, new users are moved to a less congested RAT or RFSP as per the available options. [0084] (3) Avoiding network level congestion

[0085] The PCRF (or PCF or other node) may aggregate the user session information (e.g., downloadable/streaming size and/or duration information) from all the UEs in the network. This information is used to predict which cells will be having many subscribers downloading large amounts of data in a current or future time period, e.g. the next few minutes. This will indicate the upcoming congestion state. The PCRF can correlate this with the historic congestion data for the area (e.g. tracking area and/or cell) managed by other nodes (e.g., RCAF, OSS Nodes) and take corrective measures based on this. Based on the above prediction, the PCRF (or PCF or other node) can provide the information to the NWDAF. The NWDAF node is standardized in release 15 and the same scenario and message flow can be used to report the congestion situation from the PCRF (or PCF or other node) to the NWDAF. The PCRF (or PCF or other node) can provide the following information:

Application function address (IP Add & Port, 5 tuples)

Download data information (Size/duration/content details)

User location (tracking area and/or cell)

Slice information & attached NFs (AMF/SMF)

Predictive cell congestion & duration (e.g. 5000 Users with 10-minute session durations expected)

[0086] Since the NWDAF node is responsible for non-user-specific information like network slice and respective congestion, additional information related to network slice and related congestion is saved. Then the NWDAF can aggregate the network and slice level information to support the decision made at the network level and not just one cell at a time as is done by the PCRF. For example, if a similar situation persists in multiple cells in the network then the NWDAF can be used to analyze that and make network level decisions. Several network level decisions based on this information are described below.

[0087] The NWDAF can determine that a change in network slice dimensioning is needed. This may involve communication with the network slice life-cycle management (LCM) node. [0088] The NWDAF can determine that a caching solution would help improve the congestion situation. For example, the NWDAF will have information like network slice, congestion level including access management function (AMF), Application Server (IP Address), etc. Therefore, the NWDAF can determine that e.g. a particular video is of a YouTube realtime event that is being accessed by multiple users in a given location, and therefore that providing a geographically close cache of that video would improve network performance.

[0089] The NWDAF can determine that an edge server deployment would help improve the congestion situation. For example, the NWDAF has AF-related coordinates like 5-tuples, so the NWDAF can also suggest deploying separate PGW-U at Edge to enhance customer experience and avoid any network level congestion in the network. This situation may arise e.g. where many users are watching a live event at Tata Sky Mobile APP (India), therefore optimizing future sessions on the same AF with Edge deployment (LADN).

[0090] FIG. 5 shows a message diagram according to an embodiment. FIG. 5 illustrates when network slice dimensioning is modified based on an expected or predicted congestion situation. The following is a brief description of the steps in the call flow:

[0091] 110-114. These messages are described above with respect to FIG. 1.

[0092] 115'-123. These messages are described above with respect to FIG. 2.

[0093] Note that the nodes in FIG. 5 (e.g. AMF, SMF, PCF) are presented as nodes in 5G. Although the names for these nodes in 4G are different (e.g., MME, SGW/PGW, PCRF), the basics of a service request are substantially similar such that the previous description of the above messages is applicable here. As already indicated, embodiments disclosed herein are not limited to a particular network standard, and are applicable at least to 4G and 5G networks.

[0094] The PCR aggregates all such reservation authorization requests with user session information (e.g., downloadable/streaming size and/or duration information) and calculates the total download requirement in the cell. The PCF is able to calculate the duration of the congestion from the subscribed bandwidth and downloadable size. The PCF correlates this information with historical data and information from the RCAF. The PCF provides this information of predicted cell congestion to the NWDAF along with expected download size and duration and other information.

[0095] The NWDAF may use this information to support network level decisions. For example, the NWDAF may have two sets of information available, including historical data and dynamic information about current conditions. Historical data includes information regarding at what time which locations (e.g. tracking area and/or cell) gets congested, the level of congestion, the type of call (e.g., voice/data). Such historical data may be populated as part of the PCF sending data about current conditions, which data may be stored and persisted e.g. for 3 months for future predictability, or may be otherwise acquired. Dynamic information about current conditions may be based on current network congestion issues. The NWDAF may further provide this information to the LCM/Orchestrator for network slice level decisions. The decision making further includes ramping up or ramping down the available resources for the respective network slices, the resources including compute, storage, radio perspective, and other such resources.

[0096] FIG. 6 is a flow chart according to some embodiments.

[0097] Process 600 is a method, performed by a network node (e.g. a network data analytics function (NWDAF)). The method includes receiving first congestion prediction information from a first node (e.g. a policy control function (PCF)) for a first location (e.g., cell and/or tracking area) (step 602). The first congestion prediction information includes an expected data size or duration for a content to be downloaded /streamed and/or is derived from the expected data size or duration for the content to be downloaded/streamed. The method further includes determining that a congestion condition exists for one or more locations (e.g., cells and/or tracking areas) based at least in part on the first congestion prediction information (step 604). The method further includes, in response to determining that the congestion condition exists for one or more locations (e.g., cells and/or tracking areas), modifying available network resources based on the congestion condition (step 606).

[0098] In embodiments, modifying available network resources based on the congestion condition comprises modifying network slice dimensioning (e.g. ramping up/down resources for network slices such as compute, storage, radio perspective, etc.). In

embodiments, modifying available network resources based on the congestion condition comprises providing a cache for content that is expected to be accessed by multiple users in a given location. In embodiments, modifying available network resources based on the congestion condition comprises determining that an edge server should be deployed at a given location to ease the congestion condition.

[0099] In embodiments, the method further includes receiving second congestion prediction information from a second node (e.g. a PCF) for a second location (e.g. cell and/or tracking area). Determining that a congestion condition exists for one or more locations (e.g., cells and/or tracking areas) is further based at least in part on the second congestion prediction information. In embodiments, the method further includes aggregating congestion prediction information (e.g., first and second congestion prediction information). Determining that a congestion condition exists for one or more locations (e.g. cells and/or tracking areas) is further based at least in part on the aggregating congestion prediction information.

[00100] In embodiments, the method further includes correlating the aggregated congestion prediction information with historical congestion information (e.g., at what time various tracking areas and/or locations typically are congested, typical level of congestion, typical type of call (e.g., voice / data)). Determining that a congestion condition exists for one or more locations (e.g., cells and/or tracking areas) is further based at least in part on the correlating the aggregated congestion prediction information with historical congestion information. In embodiments, the first congestion prediction information includes a total download/streaming requirement for the cell.

[00101] In embodiments, the first congestion prediction information includes one or more of the following: (i) AF location information; (ii) download/streaming data information (e.g., size/duration/application details); (iii) user location information (e.g., cell and/or tracking area); (iv) network slice information and attached network functions (NFs) information (e.g., access management function (AMF) / session management function (SMF)); and (v) predictive cell congestion and duration information (e.g. 5000 users with 10 minute long session expected).

[00102] FIG. 7 is a flow chart according to some embodiments.

[00103] Process 700 is a method, performed by a network node serving a cell (e.g. a policy control function (PCF)). The method includes receiving user session information including an expected data size or duration for a content to be downloaded/streamed (step 702); and sending congestion prediction information to a node (e.g. a network data analytics function (NWDAF)), the congestion prediction information being based on the user session information (step 704).

[00104] In embodiments, the user session information is received from a session management function (SMF) based on data provided by a user equipment (UE). In

embodiments, the user session information is received from an application function (AF). In embodiments, the method further includes aggregating further user session information including further expected data size or duration for further content to be downloaded/streamed. In embodiments, the method further includes calculating a total download/streaming requirement for the cell.

[00105] In embodiments, the method further includes receiving historical congestion information from a radio congestion aware function (RCAF); and correlating the user session information with historical congestion information. The congestion prediction information is based at least in part on the results of such correlating.

[00106] In embodiments, the congestion prediction information includes one or more of the following: (i) AF location information; (ii) download/streaming data information (e.g., size/ duration/application details); (iii) user location information (e.g., cell and/or tracking area); (iv) network slice information and attached network functions (NFs) information (e.g., access management function (AMF) / session management function (SMF)); and (v) predictive cell congestion and duration information (e.g. 5000 users with 10 minute long session expected).

[00107] According to further embodiments, a method, performed by a network node (e.g. a policy control function (PCF)). The method includes receiving a user session information indicating expected usage information for a user equipment (UE) in an established user session in a location (e.g., cell and/or tracking area); determining that a congestion condition exists for the location the user session is in; and in response to determining that the congestion condition exists for the location the user session is in, modifying the established user session based on the congestion condition.

[00108] In embodiments, modifying the established user session based on the congestion condition comprises increasing a bandwidth for the established user session based on the congestion condition and the expected usage information. In embodiments, the expected usage information includes an expected data size for a content to be downloaded and the congestion condition indicates that congestion will begin at a first time, and wherein increasing a bandwidth for the established user session comprises increasing the bandwidth so as to allow the UE to download the content by a second time prior to the first time. In embodiments, modifying the established user session based on the congestion condition comprises triggering an offload request for the user session to offload the UE onto another access (e.g., a WiFi access) so as to alleviate the congestion condition.

[00109] In embodiments, determining that a congestion condition exists comprises determining that a congestion level exceeds a threshold and/or is predicted to exceed the threshold at a third time. In embodiments, determining that a congestion condition exists further comprises analyzing historical congestion data. In embodiments, determining that a congestion condition exists further comprises receiving congestion data from one or more network nodes (e.g., Operation and Support System (OSS) and/or Radio Congestion Aware Function (RCAF) nodes). In embodiments, determining that a congestion condition exists further comprises receiving aggregate congestion data from a network node (e.g., Network Data Analytics Function (NWDAF)).

[00110] According to further embodiments, a method, performed by a network node (e.g. a Policy Control & Charging Rule Function (PCRF)) is provided. The method includes determining that a congestion condition exists for a location (e.g., cell and/or tracking area); and in response to determining that the congestion condition exists for the location the user session is in, modifying a connection parameter for a new user session based on the congestion condition.

[00111] In embodiments, the method further includes receiving a first user session information indicating first expected usage information for a first user equipment (UE) in an first established user session in a location (e.g., cell and/or tracking area). In embodiments, the method further includes receiving a second user session information indicating second expected usage information for a second UE in an established user session in the location (e.g., cell and/or tracking area). In embodiments, the method further includes aggregating expected usage information (e.g. first and second expected usage information), and wherein determining that a congestion condition exists for a location (e.g., cell and/or tracking area) is based on such aggregating.

[00112] In embodiments, determining that a congestion condition exists for a location (e.g., cell and/or tracking area) further comprises correlating the aggregated expected usage information with historical congestion information. In embodiments, the method further includes sending to another network node (e.g. a Network Data Analytics Function (NWDAF)) congestion prediction information (e.g. aggregated expected usage information and/or correlation of the aggregated expected usage information with historical congestion

information). In embodiments, modifying a connection parameter for a new user session based on the congestion condition comprises requesting a control node (e.g. a Mobility Management Entity (MME)) change a frequency selection (e.g. a subscriber profile id (SPID) and/or radio access technology (RAT)/frequency selection priority (RFSP) index) based on the congestion condition.

[00113] According to further embodiments, a method, performed by a network node (e.g. a policy control function (PCF)) is provided. The method includes sending to a first node (e.g. a Network Data Analytics Function (NWDAF)) congestion prediction information for a cell. In embodiments, the method further includes receiving from a second node (e.g., an application distribution server (ADS)) user session information indicating expected usage information for a user equipment (UE) in an established user session in a cell.

[00114] FIG. 8 is a diagram showing functional units of node 802 (e.g., a network data analytics function (NWDAF)), according to an embodiment. Node 802 includes one or more of a receiving unit 804, a determining unit 806, and a modifying unit 808. Receiving unit 804 is configured to receive first congestion prediction information from a first node (e.g. a policy control function (PCF)) for a first location (e.g., cell and/or tracking area). The first congestion prediction information includes an expected data size or duration for a content to be downloaded /streamed and/or is derived from the expected data size or duration for the content to be downloaded/streamed. Determining unit 806 is configured to determine that a congestion condition exists for one or more locations (e.g., cells and/or tracking areas) based at least in part on the first congestion prediction information. Modifying unit 808 is configured to, in response to determining that the congestion condition exists for one or more locations (e.g., cells and/or tracking areas), modify available network resources based on the congestion condition.

[00115] FIG. 9 is a diagram showing functional units of node 902 (e.g., a policy control function (PCF)), according to an embodiment Node 902 includes one or more of a receiving unit 904 and a sending unit 906. Receiving unit 904 is configured to receive user session information including an expected data size or duration for a content to be

downloaded/streamed. Sending unit 906 is configured to send congestion prediction information to a node (e.g. a network data analytics function (NWDAF)), the congestion prediction information being based on the user session information.

[00116] FIG. 10 is a block diagram of a node 802 and/or 902, according to some embodiments. As shown in FIG. 10, node 802 and/or 902 may comprise: processing circuitry (PC) 1002, which may include one or more processors (P) 1055 (e.g., a general purpose microprocessor and/or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like); a network interface 1048 comprising a transmitter (Tx) 1045 and a receiver (Rx) 1047 for enabling node 802 and/or 902 to transmit data to and receive data from other nodes connected to a network 1010 (e.g., an Internet Protocol (IP) network) to which network interface 1048 is connected; and a local storage unit (a.k.a.,“data storage system”) 1008, which may include one or more non-volatile storage devices and/or one or more volatile storage devices. In embodiments where PC 1002 includes a programmable processor, a computer program product (CPP) 1041 may be provided. CPP 1041 includes a computer readable medium (CRM) 1042 storing a computer program (CP) 1043 comprising computer readable instructions (CRI) 1044. CRM 1042 may be a non-transitory computer readable medium, such as, magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory, flash memory), and the like. In some embodiments, the CRI 1044 of computer program 1043 is configured such that when executed by PC 1002, the CRI causes node 802 and/or 902 to perform steps described herein (e.g., steps described herein with reference to the flow charts). In other embodiments, node 802 and/or 902 may be configured to perform steps described herein without the need for code. That is, for example, PC 1002 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and/or software.

[00117] While various embodiments of the present disclosure are described herein, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present disclosure should not be limited by any of the above- described exemplary embodiments. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context

[00118] Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, and some steps may be performed in parallel.