PRIORITIZING USERS BASED ON REVENUE DURING CONGESTION

Related Applications

[0001] This application claims the benefit of provisional patent application serial number 62/785,507, filed December 27, 2018, the disclosure of which is hereby incorporated herein by reference in its entirety.

Technical Field

[0002] The present disclosure relate to a cellular communications system and, in particular, to prioritization of users (e.g., subscribers) in a cellular communications system.

Background

[0003] In the present cellular communications networks, subscriber prioritization is done based on the static categorization. These categories, or classes, are defined based on the "package or "plan" bought by the subscriber. For example, a subscriber may buy a 40 US Dollar package, which provides the subscriber 15 Gigabytes (GB) of data with unlimited calling, while another subscriber may buy a 30 US Dollar package which provides this other subscriber with 10 GB of data with limited calling minutes. Once subscribers purchase their respective packages, all the differentiation (if any exist) is done based on these packages. This can equally apply to the billing plan.

[0004] Subscriber prioritization is implemented in the networks by provisioning different levels of access in User Data Repositories (UDRs). Once such implementation is done, subscriber prioritization is governed with different policies configured in the network.

Summary

[0005] Systems and methods are disclosed herein for prioritizing subscribers in a cellular communications network based on revenue generation and/or churn probability. In some embodiments, a method performed by a core network node in a core network of a cellular communications network comprises obtaining subscriber-specific

information for a particular subscriber, the subscriber-specific information comprising either or both of: (a) revenue-based priority information for the particular subscriber and (b) churn information for the particular subscriber. The method further comprises initiating one or more operational tasks in the core network based on the subscriber- specific information for the particular subscriber. By considering revenue generated by subscribers and or churn information for the subscribers, better subscriber

differentiation can be achieved.

[0006] In some embodiments, the subscriber-specific information comprises the revenue-based priority information for the particular subscriber. In some embodiments, the revenue-based priority information for the particular subscriber comprises a priority indication that is a function of an amount of revenue that is generated via a particular User Equipment (UE) associated with the particular subscriber, generated by two or more UEs associated with the particular subscriber sharing a common UE identity, generated by two or more UEs associated with the particular subscriber, or generated by a plurality of UEs, including a particular UE associated with the particular subscriber, where the plurality of UEs are associated with a same organization. In some

embodiments, the priority indication is an absolute priority value, an indication of a manner in which to adjust a priority of the particular subscriber, or a relative priority value. In some embodiments, the amount of revenue is a static amount, a dynamic amount, or a combination of both a static amount of revenue and a dynamic amount of revenue.

[0007] In some embodiments, obtaining the subscriber-specific information for the particular subscriber comprises receiving subscriber-specific revenue information for the particular subscriber from another network node. In some embodiments, obtaining the subscriber-specific information for the particular subscriber further comprises

determining the priority indication based on the received subscriber-specific revenue information. In some embodiments, the subscriber-specific revenue information comprises static revenue information for the particular subscriber and/or dynamic revenue information for the particular subscriber.

[0008] In some embodiments, obtaining the subscriber-specific information for the particular subscriber comprises receiving the subscriber-specific priority information comprising the priority indication from another network node.

[0009] In some embodiments, the subscriber-specific information comprises the churn information for the particular UE. In some embodiments, obtaining the

subscriber-specific information comprises obtaining the churn information, the churn information comprising either or both of: (a) an indication of a prediction of whether the particular subscriber will terminate the subscriber's relationship with a respective network operator of the cellular communications network and (b) an indication of a likelihood that the particular subscriber will terminate the subscriber's relationship with a respective network operator of the cellular communications network.

[0010] In some embodiments, obtaining the churn information comprises obtaining either or both of: (a) the indication of the prediction of whether the particular subscriber will terminate the subscriber's relationship with a respective network operator of the cellular communications network and (b) the indication of the likelihood that the particular subscriber will terminate the subscriber's relationship with the respective network operator of the cellular communications network, from another network node.

[0011] In some embodiments, obtaining the churn information comprises obtaining, from one or more other network nodes, churn related information associated with the particular subscriber and generating, based on the churn related information, either or both of: (a) the indication of the prediction of whether the particular subscriber will terminate the subscriber's relationship with a respective network operator of the cellular communications network and (b) the indication of the likelihood that the particular subscriber will terminate the subscriber's relationship with the respective network operator of the cellular communications network, from another network node. In some embodiments, the churn related information associated with the particular subscriber comprises churn related information for a particular UE associated with the particular subscriber, churn related information for two or more UEs associated with the particular subscriber sharing a common UE identity (e.g., Internal Mobile Subscriber Identity (IMSI)), churn related information for two or more UEs associated with the particular subscriber, or churn related information for a plurality of subscribers, including the particular subscriber, associated with a same organization.

[0012] In some embodiments, initiating the one or more operational tasks in the core network based on the subscriber-specific information for the particular subscriber comprises performing a congestion control mechanism based on the subscriber-specific information.

[0013] In some embodiments, initiating the one or more operational tasks in the core network based on the subscriber-specific information for the particular subscriber comprises selecting a network slice for a UE associated with the particular subscriber based on the subscriber-specific information. In some embodiments, initiating the one or more operational tasks in the core network based on the subscriber-specific information for the particular subscriber further comprises initiating use of the selected network slice by a UE associated with the particular subscriber.

[0014] In some embodiments, initiating the one or more operational tasks in the core network based on the subscriber-specific information for the particular subscriber comprises deciding whether to accept a request from a UE associated with the particular subscriber to access the cellular communications network or a particular network slice of the cellular communications network based on the subscriber-specific information for the particular subscriber.

[0015] In some embodiments, initiating the one or more operational tasks in the core network based on the subscriber-specific information for the particular subscriber comprises deciding whether to reallocate a UE associated with the particular subscriber from a first network slice of the cellular communications network to a second network slice of the cellular communications network based on the subscriber-specific

information for the particular subscriber.

[0016] In some embodiments, initiating the one or more operational tasks in the core network based on the subscriber-specific information for the particular subscriber comprises deciding whether to reallocate a UE associated with the particular subscriber from first time-frequency resources in a radio access network of the cellular

communications network to second time-frequency resources in the radio access network of the cellular communications network based on the subscriber-specific information for the particular subscriber.

[0017] In some embodiments, initiating the one or more operational tasks in the core network based on the subscriber-specific information for the particular subscriber comprises deciding whether to reallocate a UE associated with the particular subscriber from a Third Generation Partnership Project (3GPP) radio access network to a non-3GPP radio access network based on the subscriber-specific information for the particular subscriber.

[0018] In some embodiments, the cellular communications network is a Fifth

Generation (5G) cellular communications network, and the core network node is a Network Data Analytics Function (NWDAF) or a central NWDAF. [0019] Corresponding embodiments of a core network node for a core network of a cellular communications network are also disclosed. In some embodiments, the core network node is adapted to obtain subscriber-specific information for a particular subscriber, the subscriber-specific information comprising: revenue-based priority information for the particular subscriber; and/or churn information for the particular subscriber. The core network node is further adapted to initiate one or more

operational tasks in the core network based on the subscriber-specific information for the particular subscriber.

[0020] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.

[0021] Figure 1 illustrates one example of a cellular communications network in which embodiments of the present disclosure may be implemented;

[0022] Figure 2A illustrates an example of the cellular communications network of Figure 1 represented as a Fifth Generation (5G) network architecture composed of core Network Functions (NFs), where interaction between any two NFs is represented by a point-to-point reference point/interface;

[0023] Figure 2B illustrates an example of the cellular communications network of Figure 1 represented as a 5G network architecture using service-based interfaces between the NFs in the control plane, instead of the point-to-point reference

points/interfaces used in the 5G network architecture of Figure 2A;

[0024] Figure 3 is a reproduction of Figure 4.2-1 from Third Generation Partnership Project (3GPP) Technical Report (TR) 23.791 V16.0.0 that illustrates the general framework for 5G network automation;

[0025] Figure 4 is a flow chart that illustrates the operation of a core network node (e.g., a Network Data Analytics Function (NWDAF)) located in the core network (e.g., in the 5G core network of Figure 2A or 2B) in accordance with some embodiments of the present disclosure;

[0026] Figure 5 illustrates one example process whereby subscriber-specific revenue information is provided from a Business Support System (BSS) to the NWDAF in accordance with some embodiments of the present disclosure; [0027] Figure 6 illustrates one example process by which the NWDAF collects churn- related information from various network nodes in accordance with some embodiments of the present disclosure;

[0028] Figure 7 illustrates the operation of various Operations Support System (OSS) nodes giving inputs to the NWDAF in accordance with some embodiments of the present disclosure;

[0029] Figure 8 illustrates an example of provisioning of a network slice in the NWDAF;

[0030] Figure 9 illustrates one example of federated learning between Local Area Data Network (LADN) / network slice specific NWDAFs and a central NWDAF in accordance with some embodiments of the present disclosure;

[0031] Figures 10A and 10B illustrate a process for giving a high revenue generating subscriber priority to access a network slice during a congestion situation in accordance with some embodiments of the present disclosure;

[0032] Figures 11A and 11B illustrate a process for giving a high revenue generating subscriber priority to access a network slice during a congestion situation in accordance with some embodiments of the present disclosure;

[0033] Figures 12A and 12B illustrate a process for giving a high churn probability subscriber priority to access a network slice during a congestion situation in accordance with some embodiments of the present disclosure;

[0034] Figures 13A and 13B illustrate a process for giving a high churn probability subscriber priority to access a network slice during a congestion situation in accordance with some embodiments of the present disclosure; and

[0035] Figures 14 through 16 illustrate example embodiments of a network node.

[0036] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure. [0037] Radio Node: As used herein, a "radio node" is either a radio access node or a wireless device.

[0038] Radio Access Node: As used herein, a "radio access node" or "radio network node" is any node in a Radio Access Network (RAN) of a cellular

communications network that operates to wirelessly transmit and/or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low- power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), and a relay node.

[0039] Core Network Node: As used herein, a "core network node" is any type of node in a core network or any node that implements a core network function. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing an Access and Mobility Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.

[0040] Wireless Device: As used herein, a "wireless device" is any type of device that has access to (i.e., is served by) a cellular communications network by wirelessly transmitting and/or receiving signals to a radio access node(s). Some examples of a wireless device include, but are not limited to, a User Equipment (UE) in a 3GPP network and a Machine Type Communication (MTC) device.

[0041] Network Node: As used herein, a "network node" is any node that is either part of the RAN or the core network of a cellular communications network/system.

[0042] Subscriber: As used herein, a "subscriber" is a user or customer of a cellular communications network of a particular network operator. The subscriber may be, e.g., a pre-paid subscriber or a post-paid subscriber. Further, a subscriber may be associated with one or more wireless devices (e.g., the subscriber may pay for services for one or more wireless devices such as, e.g., a phone, a tablet, a smart watch, a secondary phone, etc.).

[0043] Note that the description given herein focuses on a 3GPP cellular

communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.

[0044] Note that, in the description herein, reference may be made to the term "cell;" however, particularly with respect to 5G NR concepts, beams may be used instead of cells and, as such, it is important to note that the concepts described herein are equally applicable to both cells and beams.

[0045] There currently exist certain challenge(s) with respect to subscriber

prioritization in a cellular communications system. Currently, subscriber priority is based on "static" UE pack subscription (or billing plan). Importantly, current subscriber prioritization does not take into account the actual revenue generated by the subscriber.

[0046] In present networks such as 3GPP 5G NR networks, there is a large amount of information related to the subscribers that is available and can be used to make better decisions about subscriber priority. Using this information, other factors, such as generated revenue, can be considered in deciding the subscriber priority to thereby improve the profitability of the network. For example, in case of network congestion, the network is unable to provide required resources for all subscribers. So, the network needs to prioritize access for the subscribers. With "static" package or billing plan based priority, the network may not achieve the best result in terms of improving the profitability of the network.

[0047] To illustrate this point, consider a scenario in which a first subscriber has a low priority "Silver" package and a second subscriber has a high priority "Platinum" package. During congestion, the first subscriber with the low priority "Silver" package may not be allowed to access the network while the second subscriber with the high priority "Platinum" package is able to access full services of the network. However, the first subscriber with the low priority "Silver" package may be generating more revenue (e.g., by purchasing additional services) than the second subscriber with the high priority "Platinum" package. In this scenario, subscriber prioritization based on the "static" package information causes an adverse effect. Based on revenue-generation data from the Business Support System (BSS), it can be seen that the first subscriber is getting lower quality network services as compared to the second subscriber which is of higher priority ("Platinum" package) but is generating less revenue. When considering profitability, this is not the desired effect. Rather, the desired effect would be to treat the first subscriber that is generating high revenue as having higher priority than the second subscriber even though the first subscriber has the "Silver" package and the second subscriber has the "Platinum" package. In other words, the high revenue generating subscriber should be treated as high priority irrespective of the package or subscription of the subscriber and irrespective of whether the subscriber is a prepaid or postpaid subscriber.

[0048] Another challenge faced by a network operator (or communication service provider) is high subscriber churn rate, which affects profitability adversely. Therefore, there is a need to reduce churn rate, thereby increasing the profitability of the network operator.

[0049] Certain aspects of the present disclosure and their embodiments may provide solutions to the aforementioned or other challenges. The issues described above with respect to subscriber differentiation can be resolved by including revenue factors into consideration. By considering revenue (e.g., real-time revenue and/or static (or monthly) revenue) generated by a subscriber, better subscriber differentiation can be achieved. This subscriber differentiation can be in terms of priority when accessing the network during congestion, in terms of network slice selection, or the like, based on revenue generated by the respective subscribers to the network operator in general (i.e., static revenue) or in recent use cases (i.e., dynamic revenue). In this manner, superior experience can be provided to high revenue subscribers. This will also help in managing network selection based on the network profitability rather than the just resource availability.

[0050] In some embodiments, systems and methods are disclosed herein for prioritizing subscribers based on revenue generation and/or churn probability. In other words, subscribers are prioritized based on revenue generation and/or churn probability, rather than only based on static aspects such as subscription, congestion, first-come- first serve policy, static policy, etc. More specifically, embodiments are disclosed for deciding subscriber priority based on subscriber-specific revenue information and/or subscriber-specific churn information (e.g., a respective satisfaction index or

dissatisfaction index or other information that indicates a likelihood that the subscriber is going to terminate the subscriber's relationship with the network operator, e.g., and establish a relationship with a different network operator).

[0051] To describe the subscriber priority implementation, a use case of network slice selection during congestion is considered as an example. Note that the same mechanism of priority determination can be used for other use cases as well.

[0052] Prioritize the High Revenue Subscriber: In some embodiments, subscribers are prioritized based on respective revenue information. For a particular subscriber, the subscriber-specific revenue information may be information that is indicative of:

• revenue generated via a particular UE of the subscriber,

• revenue generated via two or more particular UEs of the subscriber sharing the same UE identity (e.g., Internal Mobile Subscriber Identity (IMSI)),

• revenue generated via two or more particular UEs associated with the subscriber (potentially having different UE identities), or

• revenue generated by two or more UEs associated with an organization

associated with the subscriber (e.g., a company in which the subscriber is an owner or employee).

The subscriber-specific revenue information for a particular subscriber may include static revenue information (e.g., a fixed monthly, weekly, or daily revenue from the service package or billing plan of the subscriber) and/or dynamic revenue information (e.g., dynamic revenue from one or more add-on services such as, e.g., a pay-per-use or pay-per-minute service of the network operator or dynamic revenue from one or more partner services such as, e.g., one or more social networking services that have partnered with the network operator in such a manner that use of the service by the subscriber results in revenue to the network operator). In some embodiments, converged charging is used where both pre-paid and post-paid revenue information is available at a BSS in real-time. This information can be used (e.g., by the BSS or some other network node such as, e.g., a Network Data Analytics Function (NWDAF)) to analyze and decide a priority or priority adjustment for the subscriber. This priority or priority information is used to initiate one or more operations in the network such as, e.g., tuning of traffic shaping policies in a network node (e.g., a gateway such as a Packet Data Gateway (PDG), a core network node such as, e.g., a SMF or UPF, or the like) or automatic re-mapping of Quality of Service (QoS) packet values of the subscriber in the network, especially when there is scarcity of resources in a situation like congestion.

[0053] This subscriber-specific revenue information can be collected from the BSS, which has real-time information on charging and subscribed services. In some embodiments, the subscriber-specific revenue information is collected at the BSS and used by the BSS to generate subscriber-specific revenue-based priority information for the subscriber, which can then be provided to another network node(s) (e.g., a

NWDAF) and used to, e.g., initiate one or more network operations (e.g., core network operations) related to the subscriber. In some other embodiments, the subscriber- specific revenue information is provided from the BSS to another network node (e.g., a NWDAF) that then uses the subscriber-specific revenue information, e.g., to generate subscriber-specific revenue-based priority information for the subscriber and, based on this information, initiate one or more network operations.

[0054] Prioritize the Highly Dissatisfied Users (Expected to Churn): In some embodiments, subscribers expected to be churned (leave the network for competitor networks) can be prioritized even if they are not the most high revenue generators.

This ensures that probable churn cases are identified based on, e.g., proactive learning or predictive modelling and their services are prioritized, at least for a limited duration. For example, a subscriber who has contacted the network operator's call center "n" times in the last four weeks to raise complaints about connectivity issues, lower data speed than subscribed, etc. can be identified and prioritized, e.g., during times of congestion.

[0055] For a particular subscriber, the subscriber-specific churn information may include:

• information that is indicative of a prediction (e.g., yes or no) or likelihood (e.g., X% chance) that the subscriber will churn (i.e., leave the network for a competitor network); and/or

• churn-related information for the subscriber, which can be any type of

information that can be used (e.g., by a proactive leaning scheme or predictive modeling scheme) to determine whether the subscriber is predicted to churn (e.g., yes or no) and, in some embodiments, a likelihood (e.g., degree of confidence) that the subscriber will churn or not churn (e.g., X% chance of churn). [0056] The subscriber-specific churn information can be collected from different sources like Customer Relationship Management (CRM), Operations Support System (OSS), and BSS. Analysis of this information may provide the prediction and likelihood of the churn. In some embodiments, the subscriber-specific churn information is collected at the NWDAF.

[0057] Based on either or both of the two above-described types of information (i.e., based on the subscriber-specific revenue information and/or the subscriber-specific churn information), the subscriber can be prioritized (e.g., given high priority when revenue generated is high and/or when likelihood of churn is high). To elaborate on the subscriber differentiation, the use-case of congestion, or overload in the network will now be considered. For simplicity, two options for subscriber differentiation are considered:

1. Deprioritizing low priority subscribers when the network or the

network slice is congested.

In case the network is reaching overload situation, e.g., with resource utilization more than 70% but is not overloaded yet, the network can prioritize the subscriber requests so that higher priority subscribers are allowed in the network slice. Requests for lower priority subscribers are rejected. Priority is calculated here based on profitability and revenue generated by subscriber.

2. Selecting a "fallback" default network slice for low priority subscribers when the network or the network slice is congested.

As an example, in case of network slice congestion or overload, new subscriber requests received from low priority subscribers for a particular network slice may be moved to another low priority "fallback" network slice, assuming that there are two or more network slices with similar capabilities. As a particular example, if there is an overload\congestion situation in an Enterprise Network Slice, then a Fallback Network Slice can be selected for any new requests coming from a low priority subscriber of the Enterprise Network Slice. This will ensure continuity of the session and avoids service interruption, but this subscriber may not be ensured the same quality of experience as the high priority subscriber.

[0058] Note that congestion information can be gathered by the NWDAF in real-time from the OSS or various Network Functions (NFs) (e.g., core network functions, e.g., in a 5G core network). Also, the NWDAF may also predict the overload or congestion based on the previous overload or congestion situation(s), e.g. if there is network congestion at peak hours 8 PM to 9 PM every weekday, then the NWDAF can identify this pattern from historical data and may take proactive action near this peak hour time.

[0059] Congestion may happen in two different layers, namely the network layer or the application layer, this without a direct one to one mapping to each other. Resource congestion would happen, e.g., in case of buffer overflow in the nodes, or that data packets are delayed and delivered outside required time constraints resulting in that the packet is lost. The other type of "congestion" is on the application layer if the

application does not perform as expected. Different applications will have quite different types of congestion behavior. For example, a typical behavior for Transmission Control Protocol (TCP) / Internet Protocol (IP) traffic is to drive the network to resource congestion, this without seeing any congestion on application layer. In the case of file download application the congestion could be measured in download time. Another example is if we have adaptive chunk-based video streaming with buffering in the terminal, in this case several network resource congestion periods may happen during the streaming session without any disturbances on the application layer, as those congestion periods are smoothed out by the pre-buffering in the UE client buffer.

[0060] The NWDAF may consider both resource congestion and "application congestion" information. The application congestion information could be received from different sources. Some examples are as follows.

• Application congestion information could be received from the BSS Service

assurance function, in which case the application congestion information may be service level assurance information. If the application is provided by the operator, this service level assurance information is then provided from the BSS to the NWDAF.

• Application congestion information may be received from an Over the Top (OTT) application (not provided by the operator). In this case, the application perceived congestion information could be sent to the NWDAF using the NEF.

• Another solution is that the gateway (P-GW, SMF/UPF) has a smart programmed Machine Learning (ML) fingerprint of traffic profiles that identifies threshold levels when application traffic is good or bad. Using such ML fingerprint of traffic profiles, the gateway can determine whether congestion occurs and can report this to the NWDAF. [0061] Some of the description provided herein uses network slice selection as one example where BSS-NWDAF revenue optimization can be done. However, the present disclosure is not limited thereto. The present disclosure is equally applicable to scenarios other than network or network slice congestion. Another example is that BSS- NWDAF revenue optimization is used in real-time to tune the traffic shaping policies in the gateway (PDG, SMF/UPF) to set the max bit rate for a subscriber, or automatic re ^¬ mapping of QoS value in the user data packet flow depending on subscription with higher or low revenue values.

[0062] Network Slicing is new functionality considered for 5G networks.

Embodiments of the present disclosure provide methods and procedures to select the network slice as per network slice load condition together with the subscriber real-time revenue and/or probability of churn.

[0063] In some embodiments, BSS real-time information is delivered to the NWDAF that produces insights on optimal revenue traffic management actions such as network slice selection, QoS packet marking, and traffic management policies covering throttling of traffic by adjusting max bit rates of data flow.

[0064] Certain embodiments may provide one or more of the following technical advantage(s). For example, embodiments of the proposed solution come with their share of advantages for the network operator such as, e.g., prioritizing the subscriber having higher revenue based on dynamic spending rather than static configuration, prioritizing the subscriber based on the likelihood to churn, and making network related decision, e.g. Slice Selection based on the subscriber revenue and/or prediction or likelihood of churn.

[0065] Figure 1 illustrates one example of a cellular communications network 100 in which embodiments of the present disclosure may be implemented. In the

embodiments described herein, the cellular communications network 100 is a 5G NR network. In this example, the cellular communications network 100 includes base stations 102-1 and 102-2, which in 5G NR are referred to as gNBs, controlling

corresponding macro cells 104-1 and 104-2. The base stations 102-1 and 102-2 are generally referred to herein collectively as base stations 102 and individually as base station 102. Likewise, the macro cells 104-1 and 104-2 are generally referred to herein collectively as macro cells 104 and individually as macro cell 104. The cellular communications network 100 may also include a number of low power nodes 106-1 through 106-4 controlling corresponding small cells 108-1 through 108-4. The low power nodes 106-1 through 106-4 can be small base stations (such as pico or femto base stations) or Remote Radio Heads (RRHs), or the like. Notably, while not illustrated, one or more of the small cells 108-1 through 108-4 may alternatively be provided by the base stations 102. The low power nodes 106-1 through 106-4 are generally referred to herein collectively as low power nodes 106 and individually as low power node 106. Likewise, the small cells 108-1 through 108-4 are generally referred to herein collectively as small cells 108 and individually as small cell 108. The base stations 102 (and optionally the low power nodes 106) are connected to a core network 110.

[0066] The base stations 102 and the low power nodes 106 provide service to wireless devices 112-1 through 112-5 in the corresponding cells 104 and 108. The wireless devices 112-1 through 112-5 are generally referred to herein collectively as wireless devices 112 and individually as wireless device 112. The wireless devices 112 are also sometimes referred to herein as UEs.

[0067] Figure 2A illustrates a wireless communication system represented as a 5G network architecture composed of core NFs, where interaction between any two NFs is represented by a point-to-point reference point/interface. Figure 2A can be viewed as one particular implementation of the system 100 of Figure 1.

[0068] Seen from the access side the 5G network architecture, Figure 2A comprises a plurality of UEs connected to either a RAN or an Access Network (AN) as well as an AMF. Typically, the R(AN) comprises base stations, e.g., such as eNBs or gNBs or similar. Seen from the core network side, the 5G core NFs shown in Figure 2A include a NSSF, an AUSF, a UDM, an AMF, a SMF, a PCF, and an Application Function (AF).

[0069] Reference point representations of the 5G network architecture are used to develop detailed call flows in the normative standardization. The N1 reference point is defined to carry signaling between the UE and AMF. The reference points for connecting between the AN and AMF and between the AN and UPF are defined as N2 and N3, respectively. There is a reference point, Nil, between the AMF and SMF, which implies that the SMF is at least partly controlled by the AMF. N4 is used by the SMF and UPF so that the UPF can be set using the control signal generated by the SMF, and the UPF can report its state to the SMF. N9 is the reference point for the

connection between different UPFs, and N14 is the reference point connecting between different AMFs, respectively. N15 and N7 are defined since the PCF applies policy to the AMF and SMF, respectively. N12 is required for the AMF to perform authentication of the UE. N8 and N10 are defined because the subscription data of the UE is required for the AMF and SMF.

[0070] The 5G core network aims at separating user plane and control plane. The user plane carries user traffic while the control plane carries signaling in the network.

In Figure 2A, the UPF is in the user plane and all other NFs, i.e., the AMF, SMF, PCF, AF, AUSF, and UDM, are in the control plane. Separating the user and control planes guarantees each plane resource to be scaled independently. It also allows UPFs to be deployed separately from control plane functions in a distributed fashion. In this architecture, UPFs may be deployed very close to UEs to shorten the Round Trip Time (RTT) between UEs and data network for some applications requiring low latency.

[0071] The core 5G network architecture is composed of modularized functions. For example, the AMF and SMF are independent functions in the control plane. Separated AMF and SMF allow independent evolution and scaling. Other control plane functions like the PCF and AUSF can be separated as shown in Figure 2A. Modularized function design enables the 5G core network to support various services flexibly.

[0072] Each NF interacts with another NF directly. It is possible to use intermediate functions to route messages from one NF to another NF. In the control plane, a set of interactions between two NFs is defined as service so that its reuse is possible. This service enables support for modularity. The user plane supports interactions such as forwarding operations between different UPFs.

[0073] Figure 2B illustrates a 5G network architecture using service-based interfaces between the NFs in the control plane, instead of the point-to-point reference

points/interfaces used in the 5G network architecture of Figure 2A. Flowever, the NFs described above with reference to Figure 2A correspond to the NFs shown in Figure 2B. The service(s) etc. that a NF provides to other authorized NFs can be exposed to the authorized NFs through the service-based interface. In Figure 2B the service based interfaces are indicated by the letter "N" followed by the name of the NF, e.g., Namf for the service based interface of the AMF and Nsmf for the service based interface of the SMF etc. The NEF and the NRF in Figure 2B are not shown in Figure 2A discussed above. Flowever, it should be clarified that all NFs depicted in Figure 2A can interact with the NEF and the NRF of Figure 2B as necessary, though not explicitly indicated in Figure 2A.

[0074] Some properties of the NFs shown in Figures 2A and 2B may be described in the following manner. The AMF provides UE-based authentication, authorization, mobility management, etc. A UE even using multiple access technologies is basically connected to a single AMF because the AMF is independent of the access technologies. The SMF is responsible for session management and allocates IP addresses to UEs. It also selects and controls the UPF for data transfer. If a UE has multiple sessions, different SMFs may be allocated to each session to manage them individually and possibly provide different functionalities per session. The AF provides information on the packet flow to the PCF responsible for policy control in order to support QoS. Based on the information, the PCF determines policies about mobility and session management to make the AMF and SMF operate properly. The AUSF supports authentication function for UEs or similar and thus stores data for authentication of UEs or similar while the UDM stores subscription data of the UE. The Data Network (DN), not part of the 5G core network, provides Internet access or operator services and similar.

[0075] An NF may be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., a cloud infrastructure.

[0076] Now, the description turns to a more detailed description of some

embodiments of the present disclosure. Currently, subscriber revenue and prediction or likelihood of churn of a particular subscriber are not considered for subscriber

differentiation. Subscriber differentiation is currently controlled only on basis of subscription or package and, as such, the same priority is provided to subscribers with same "static" profile. This does not ensure the best experience for the subscribers that are generating high revenue for the network operator or that are predicted or likely to churn.

[0077] Figure 3 is a reproduction of Figure 4.2-1 from 3GPP Technical Report (TR) 23.791 V16.0.0 that illustrates the general framework for 5G network automation. As illustrated, a core network function, which is referred to as a NWDAF 300, operates to provide data collection and data analytics in a centralized manner. In particular, the NWDAF 300 uses existing service based interfaces to communicate with other 5G core network functions and Operations and Management (OAM). The NWDAF 300 collects data and analyzes the collected data. Results of the data analytics are exposed to any consumer network function utilizing a service based interface.

[0078] Embodiments of the present disclosure provide solutions that take into account subscriber-specific revenue information and/or subscriber-specific churn information when prioritizing a UE(s) associated with the subscriber. In addition, other factors may be considered such as network condition, historical data (e.g., proactive planning based on historical data), etc., e.g., in order to avoid degradation and enhance, or at least maintain, user experience for high revenue subscribers and/or for subscribers that are predicted to or are likely to churn.

[0079] Figure 4 is a flow chart that illustrates the operation of a core network node (e.g., the NWDAF 300) located in the core network (e.g., in the 5G core network of Figure 2A or 2B) in accordance with some embodiments of the present disclosure. As illustrated, the core network node (e.g., NWDAF 300) obtains subscriber-specific information for a particular subscriber (step S400). The subscriber-specific information comprises:

• revenue-based priority information for the particular subscriber; and/or

• churn information for the particular subscriber.

As described below in detail, the subscriber-specific information comprises revenue- based priority information for the particular subscriber. Further, in some embodiments, the revenue-based priority information for the particular subscriber comprises a priority indication that is a function of an amount of revenue that is:

• generated via a particular UE associated with the particular subscriber;

• generated by two or more UEs associated with the particular subscriber sharing a common UE identity (e.g., IMSI);

• generated by two or more UEs associated with the particular subscriber; or

• generated by a plurality UEs, including a particular UE associated with the

particular subscriber, where the plurality of UEs are associated with a same organization.

Further, in some embodiments, the priority indication is an absolute priority value, an indication of a manner in which to adjust a priority of the particular subscriber (e.g., increase, decrease, or keep the same), or a relative priority value (e.g., an indication to adjust a priority of the particular subscriber by a value p, where p is an integer value). In some embodiments, the amount of revenue is a static amount, a dynamic amount, or a combination of both a static amount of revenue and a dynamic amount of revenue.

[0080] In some embodiments, the core network node (e.g., NWDAF 300) obtains the revenue-based priority information by determining (e.g., calculating) the revenue-based priority indication based on subscriber-specific revenue information received from another network node (e.g., a BSS of the network operator). The subscriber-specific revenue information for the particular subscriber may include static revenue information for the subscriber and/or dynamic (e.g., real-time) revenue information for the subscriber. The core network node may then generate the priority indication for the subscriber based on the revenue information received for the subscriber (e.g., high priority subscriber if the subscriber generates high revenue).

[0081] In some other embodiments, another network node (e.g., BSS) has access to the subscriber-specific revenue information for the subscriber and generates the revenue-based priority indication for the subscriber based on this information. This other network node then provides the revenue-based priority indication for the subscriber to the core network node (e.g., NWDAF 300). In addition to providing the revenue-based priority indication for the subscriber to the core network node, the other network node may also provide the subscriber-specific revenue information (or some portion thereof) of the subscriber to the core network node (e.g., NWDAF 300), where this information can be stored and subsequently used by the NWDAF for subscriber prioritization or differentiation.

[0082] In some embodiments, in addition to or as an alternative to the revenue- based priority information for the subscriber, the core network node (e.g., NWDAF 300) obtains subscriber-specific churn information for the subscriber from one or more other network nodes (e.g., OSS, CRM, etc.). This churn information is any type of information that is indicative of whether the subscriber may churn (leave the network operator for another network operator). Examples of different types of churn information are described herein. In some embodiments, the network node (e.g., NWDAF 300) uses the churn information for the subscriber to generate a prediction of whether the subscriber will churn and/or a likelihood that the subscriber will churn (also referred to herein as a churn probability for the subscriber). In some other embodiments, the churn information obtained from the other network node(s) includes the churn prediction and/or churn probability. [0083] The core network node (e.g., the NWDAF 300) initiates one or more operational tasks in the core network based on the subscriber-specific information for the particular subscriber (e.g., based on the subscriber-specific revenue-based priority information and/or the churn information for the subscriber) (step S402). In some embodiments, the one or more operational tasks include one or more operational tasks related to congestion control, network or network slice selection, network or network slice reallocation, time-frequency resource allocation or re-allocation, reallocation to a non-3GPP access type, or the like.

[0084] The present disclosure elaborates solutions for prioritizing the user experience for superior subscribers (e.g., high revenue generating subscribers and/or subscribers that are predicted to or likely to churn). In some embodiments, a network or network slice selection use-case is considered to explain the subscriber priority.

[0085] Network slicing helps in optimizing the use of logical networks which are separated from each other and are created for specific business cases or customers, which in turn can provide specific services for the subscribers. Different subscribers are mapped to different network slices based on the subscription. Different network slices may provide different levels of quality of experience based on, e.g., throughput, delay, and/or services.

[0086] Currently, a UE is attached to a network slice when the UE has a specific subscription that identifies the network slice based on Network Slice Selection

Assistance Information (NSSAI). Example: There can be a network slice for ensuring low latency communication which provides enhanced gaming experience. It may have co-located application functions for popular OTT applications, e.g. Netflix. Currently, the selection of a network slice for the UE is made based on subscription of the UE, which is based on static configuration and does not include the dynamic condition of the subscriber and network for optimized decision making.

[0087] To simplify the following description, the description is broken into two parts:

• Pre-Collection Phase: Populating the relevant information from different NFs towards the NWDAF 300 to have super set information available for

implementing intelligence and automation (key aspect of 3GPP Release 16). This is described in Section 1 below. • Post-Collection Phase: Using the information available/derived at the NWDAF 300 for optimized decision making, e.g. selection/deselection/prioritization needed for users/slice selection. This is described in Section 2 below.

1 Pre-Collection Phase

1.1 Populating the relevant information from different NFs towards the

NWDAF

[0088] Currently, there are many relevant types of information available in the NFs individually (i.e., scattered across various NFs in the network) that are not shared with any central node for a more informed and correlated decision. In this section, a description of the specific information available at different network nodes (e.g., AF,

BSS, etc.) is provided along with a description of some example mechanisms that can be used to collate this information at the NWDAF 300. Please note that the NWDAF 300 is an analytics node introduced in 5G which will support automation and analytics needed for the 5G architecture to be agile and dynamic in terms of scale out / scale in based on dynamic network conditions. More specifically, the following is described below:

• BSS system sharing subscriber-specific revenue information (e.g., monthly,

weekly, and/or yearly trend, top up services to which the subscriber is

subscribed, etc.).

• CRM + BSS system + OSS systems sharing subscriber-specific information for making a churn prediction for the subscriber and/or calculating churn probability (also referred to as likelihood of churn) (e.g., X% chance of churn) for the subscriber.

• OSS system sharing the network congestion information (e.g., dynamic

information related to the network or network slice congestion). Subscriber priority can be used for differentiation in cases where network\slice congestion makes it impossible to provide enough resources for all the subscribers.

Congestion and load related information can be gathered from the OSS.

• If there is more than one NWDAF 300 (e.g., slice specific NWDAF, Local Area Data Network (LADN) specific) in the network, a federated learning mechanism can be used to ensure that Public Land Mobile Network (PLMN) level information is available, at least in one NWDAF 300. 1.1.1 BSS System Sharing Subscriber-Specific Revenue Information

[0089] All the services provided by the network operator (also referred to as communication service provider) needs to be monetized, which is managed by BSS systems. Additionally, the network operator, or communication service provider, should consider making decisions regarding the prioritization among the subscribers based on the revenue generated by the particular subscribers and not only based on the specific static configurations of the subscribers. Now, network operators are moving toward converged charging, where all the charging information for pre-paid as well as post-paid subscribers is available at the BSS in real-time. So, this information can be utilized to calculate the actual revenue generated by each subscriber by taking into account all the network usage and purchases made by a single UE associated with the subscriber, two or more UEs associated with the subscriber (e.g., two or more UEs sharing the same IMSI), or UEs by multiple subscribers (including the subscriber) that are part of the same organization (e.g., owner and/or employees of a particular company).

[0090] In some embodiments, this subscriber-specific revenue information is provided from a BSS 500 to the NWDAF 300. This information will also be stored at the NWDAF 300, e.g., so that NF specific information covered in Section 1.1.2 below and BSS information can be correlated at one NF (NWDAF 300) to have end to end view needed for prioritization decision.

[0091] Figure 5 illustrates one example process whereby subscriber-specific revenue information is provided from the BSS 500 to the NWDAF 300 in accordance with some embodiments of the present disclosure. As illustrated, the BSS 500 (or associated data warehouse node) provides subscriber-specific revenue information to the NWDAF 300 (step S500). In some embodiments, the subscriber-specific revenue information includes static subscriber-specific revenue information for a particular subscriber (e.g., static revenue information such as, e.g., monthly usage and recharge information) and/or dynamic subscriber-specific revenue information (e.g., real-time revenue and usage data specific to the real-time usage by the subscriber).

[0092] Table 1 below illustrates some examples of subscriber-specific revenue information for three example subscribers.

Table 1: Different ways to Prioritize subscribers

[0093] As shown in Table 1, specific services bought from or via a network operator (e.g., Music or TV subscriptions) can be indicated in the subscriber-specific revenue information. For example, in India, Airtel subscribers can buy subscription to Wynk (Music) or AirtelTV applications. These applications are owned by Airtel and can be paid for as part of the subscriber's bill (post-paid) or from the recharge amount (pre-paid). These services provide additional revenue and can be subscribed/unsubscribed dynamically by the subscriber. A subscriber may have a lower data subscription, e.g. "Silver" class, but by making purchases on these services the subscriber may be generating more revenue than a higher data subscription ("Platinum" class).

[0094] Note that the subscriber-specific revenue information for a particular subscriber may include:

• Revenue-based priority information for the particular subscriber generated at the BSS 500 based on revenue related information for the subscriber available at the BSS 500. This revenue-based priority information may be an absolute priority (e.g., a priority of 7 in a scale of 1 to 10 where 10 is the highest revenue-based priority), and/or

• Static and/or dynamic subscriber-specific revenue related information such as, e.g., static profile (e.g., billing plan or package), real-time revenue, and/or information that indicates whether the subscriber has subscribed to one or more services that result in revenue to the network operator (e.g., a music service of the network operator or the like). This information may then be used by the NWDAF 300 to calculate a priority for the subscriber or to otherwise prioritize the subscriber relative to other subscribers. 1.1.2 CRM + BSS system + OSS systems Sharing the Subscriber-Specific Information for Making Churn Prediction and/or Calculating Churn Probability

[0095] Similar to subscriber priority based on revenue, the NWDAF 300 can also obtain (e.g., make or calculate) a subscriber-specific churn prediction or churn probability, e.g., based on churn related information for that subscriber (e.g., historical data related to the churn of that subscriber). The churn related information for a subscriber may include various types of information such as, e.g., number of complaints raised by the subscriber towards CRM (e.g., bad connectivity), call failure, information indicative of exceptionally low usage of service by the subscriber, etc. In some embodiments, the churn related information for a subscriber is provided to the NWDAF 300 and used by the NWDAF 300 to generate a churn prediction (e.g., yes or no) for the subscriber and/or to generate a churn probability for the subscriber. For example, the NWDAF 300 can calculate the probability of this particular subscriber moving to another network operator. So, if the churn probability for a particular subscriber is high (e.g., above a predefined threshold), this subscriber can be assigned high priority so that her quality of experience is ensured. This will help in reducing the churn. There are multiple factors which can be considered for such cases, but a few examples are:

• Call failure details for particular subscriber. This information can be received from a (OSS) system in terms of performance management counters and failure causes.

• Multiple complaints to call center, Mobile Number Portability (MNP) request raised in past/present (code generated). This information can be received from the CRM system. This information represents the dissatisfaction over existing services and high probability/willingness of the subscriber to change to another operator.

• Abruptly low usage of the services for last few weeks. Change in the usage

pattern can indicate the subscriber churn probability.

Table 2: Different factors for churn probability

[0096] Above mentioned factors do not indicate the churn probability on their own, e.g. weekly usage may reduce due to roaming scenario. But these factors when considered together can help in indicating the churn probability. Also, the factors given above are only examples and it should be understood that additional and/or alternative factors may be considered.

[0097] Figure 6 illustrates one example process by which the NWDAF 300 collects churn-related information from various network nodes in accordance with some embodiments of the present disclosure. As illustrated, the NWDAF 300 receives a service notify message from a BSS 600, an OSS 602, and a CRM 604, in this example (steps S600 - S604). In step S600, subscriber-specific revenue information and usage information is provided from the BSS 600 to the NWDAF 300. In steps S602 and S604, subscriber-specific churn related information is provided to the NWDAF 300 from the OSS 602 and the CRM 604. The NWDAF 300 can then use the collected information to calculate a priority for the subscriber.

1.1.3 OSS system sharing the network congestion information

[0098] The following information is useful to elaborate the use case of network or network slice selection.

[0099] Network or network slice selection is based on whether NFs in a network slice are congested (i.e., overloaded) or not. There can be multiple reasons that a network slice is congested/overloaded. It can be due to individual nodes (e.g., SMF, UPF, and/or PCF etc.) or it can be due to congestion in the RAN or transmission network or there can be problems with switches, virtual switches, and/or other infrastructure elements.

If it is congested/overloaded (for example), it should be a better idea to not connect new UEs (even if they have respective NSSAI) to the network slice.

[0100] These congestion/overload factors can be considered by the NWDAF 300 with appropriate information from the OSS. Different elements of the network (i.e., elements of the transport network or RAN) provide the Key Performance Indicator (KPI) information to the centralized OSS, which can relay this information to the NWDAF 300 for analysis and decision making.

[0101] Therefore, whenever the network slice is expecting overload or reaches the overloaded situation, which is a very practical situation, the revenue specific information can also be used for decision making. This information will also be stored at the

NWDAF 300 so that subscriber-specific revenue information covered in Section 1.1.1 and the congestion information can be correlated at one network function (NWDAF 300) to have end to end view needed for prioritization decision.

[0102] In this regard, Figure 7 illustrates the operation of various OSS nodes giving inputs to the NWDAF 300 in accordance with some embodiments of the present disclosure. In particular, using in this example respective Service Notify messages, various network elements (e.g., an eNB 102, nodes in an IP transport network 700, a Network Functions Virtualization Infrastructure (NFVI) 702, and a Virtualized Network Function (VNF) 704 in this example) provide respective performance and event notification information to an OSS 706, and the OSS 706 then provides respective performance status information to the NWDAF 300 for each of the various network nodes (steps S700 - S714).

[0103] More specifically, the different network elements provide performance related data to the OSS 706 via the respective Service Notify messages. The OSS 706 updates the NWDAF 300 with relevant performance information, which is used by the NWDAF 300 to decide which network elements may be experiencing overload or congestion or contributing to the overall network/network slice congestion.

[0104] Table 3 below illustrates some example load or congestion data from some example NFs.

Table 3: Load\Congestion data from NFs

[0105] The NWDAF 300 stores the NF overload status information received from the OSS 706. The NWDAF 300 also includes network slice related information to know which NF belongs to which network slice. The NWDAF 300 uses this information to inform the AMF about the status of the NF when the AMF queries the NWDAF 300 about the network slice information. The same is explained below.

[0106] Figure 8 illustrates an example of provisioning of a network slice in the NWDAF 300. As illustrated, a provisioning node sends a service notify message to the NWDAF 300 (step S800). The service notify message includes, for a particular network slice (Slice-x), information that identifies a number of core network functions (SMF1, SMF2, UPF1, in this example) for that network slice.

1.1.4 NWDAF Federated learning in case of Slice/LADN Specific NWDAF

[0107] The NWDAF is a PLMN level function, as per 3GPP. So, it is expected that only one NWDAF will be available in the network. But in different cases, it might be useful to have separate NWDAFs (slice specific NWDAFs, LADN specific NWDAFs, etc.) for different use cases.

[0108] For example, in case of LADN, separate NFs including the NWDAF can be considered for each LADN to further reduce the latency for a critical latency specific application. Similarly, a separate NWDAF for each network slice may keep the network slice specific information. In this case, there will be one "central" NWDAF, which maintains the PLMN level view to influence network level policies.

[0109] In case separate NWDAFs are deployed for each network slice, then there is communication between the different NWDAFs and the central NWDAF. All the updates related to NF status are made to the NWDAF for that network slice. This information is shared by the slice specific NWDAF to the central NWDAF so that the central NWDAF can make better decisions at the network level. [0110] In this regard, Figure 9 illustrates one example of federated learning between LADN/slice specific NWDAFs 900/902 and a central NWDAF 904 in accordance with some embodiments of the present disclosure. As illustrated, information related to a network slice (e.g., NF, slice Identifier (ID), performance data, etc.) are shared between the slice-specific NWDAFs 902 and the central NWDAF 904 (step S900). Likewise, for LADN specific NWDAFs 900, information related to the LADN (e.g., AF, LADN-ID, performance data, etc.) are shared between the LADN specific NWDAFs 900 and the central NWDAF 904 (step S902).

2 Post Collection phase

[0111] In the post collection phase, the collected data is analyzed and used to make policy decisions. In the present disclosure, these decisions are relevant for prioritizing the subscribers and/or selecting of the appropriate network slice. Note that network slice selection can also be said to be a form of prioritizing subscribers.

[0112] As highlighted earlier, the NWDAF 300 (or the central NWDAF 904) has collected relevant information including, but not limited to, subscriber-specific revenue information, subscriber-specific churn information, and congestion information (e.g., load status of different network elements). If the use case of congestion/overload in the network is considered, this information can be used to make optimal decisions. For example, whenever the AMF would apply the policy for selecting a network slice, two alternatives can be considered for optimally selecting the network slice, namely:

1. The AMF connects to the NSSF for each case, the NSSF will further check with the NWDAF 300 (or central NWDAF 904) for further input/feedback on network slice level. Note that the NWDAF may also be deployed in a distributed manner that has a "coverage" of several network slices in that specific area. In this area, the distributed NWDAF would be the central NWDAF for all network slices in that area.

2. Currently, the procedure of the AMF connecting with the NSSF is optional. The AMF can make a decision on its own based on the available information. In this case, the proposed solution will be implemented by ensuring the AMF checks with the NWDAF 300 before selection of the network slice.

[0113] These use cases are covered where the NWDAF 300 will be contacted before making a decision by the control plane to attach to a respective network slice. For simplicity, only the first alternative is shown, but the same procedure can be applied for communication between the AMF and the NWDAF 300. This additional communication between the AMF/NSSF and the NWDAF 300 provides ways to prioritize the subscriber based on:

a. prioritizing the high revenue subscribers

b. prioritizing the highly dissatisfied subscribers (expected to churn).

[0114] Based on the above two criteria, a subscriber can be provided higher priority. To elaborate the subscriber differentiation, the use case of congestion/overload in the network will be considered. For simplicity, two options for subscriber differentiation are considered:

a. Deprioritizing the low priority subscribers when the network/network slice is

congested.

b. Selecting a "fallback" default network slice for low priority subscribers when the network/network slice is congested.

[0115] Prediction based on Historical Congestion/Overload Data: Note that, if the above overload situation is taking place regularly, a historical data repository can be used to predict such situations. This means that the NWDAF 300 will have historical information on typically when NF(s) in history have been overloaded, e.g., in terms of time/day of the year, new pack launch, and failure in RAN nodes etc. In that case, the NWDAF 300 can do the predictive analysis even before the congestion happened so that low priority subscribers are not connected to high priority network slice(s) even when the network is not congested (but probable to have congestion in the future).

2.1 Prioritize the High Revenue Subscriber

[0116] In some embodiments, the network operator can choose various parameters based on when the NWDAF 300 can provide a recommendation for subscriber priority. The BSS system populates the subscriber-specific revenue information in the NWDAF 300, as discussed above.

[0117] Currently, subscriber priority can be defined in a static way based on the IMSI or DN Name (DNN) details in the User Data Function (UDF) and AMF. These

subscribers are treated the same way in the network irrespective of revenue generated. [0118] In contrast, in some embodiments of the present disclosure, subscriber priority is based on subscriber-specific revenue information. In this regard, some example ways to prioritize subscribers are illustrated in Table 4 below.

Table 4: Different ways to Prioritize subscribers

[0119] Based on the above criteria, a subscriber can be provided higher priority when the subscriber generates high revenue. To elaborate the subscriber differentiation, the use case of congestion/overload in the network is used. For simplicity, two options for subscriber differentiation are considered: a. Deprioritizing the low priority customers, when the network/ network slice is congested

[0120] In case the network slice is reaching overload situation, e.g., with resource utilization more than 70% but is not overloaded yet, the network (e.g., NWDAF 300) can prioritize subscriber requests so that subscribers that generate higher revenue are given higher priority and therefore are allowed in the network slice. Requests for lower priority subscribers are rejected. Priority is calculated here based on revenue generated by the subscriber.

[0121] In this regard, Figures 10A and 10B illustrate a process for giving a high revenue generating subscriber priority to access a network slice during a congestion situation in accordance with some embodiments of the present disclosure. The process is as follows:

• Step S1000: Subscribers with different initial priorities try to connect to the

network. In particular, in step SIOOO, UE1 associated with a first subscriber having "Silver" priority tries to access the network. As discussed below, in step S1022, UE2 associated with a second subscriber having "Platinum" priority tries to connect to the network. In this example, the subscriber associated with UE1 generates more revenue than the subscriber associated with UE2. Note that the revenue of the subscriber associated with UE1 may be the revenue generated by the subscriber via UE1, revenue generated by the subscriber via two or more UEs including UE1 that are associated with the subscriber (e.g., two or more UEs sharing the same UE identity (e.g., same IMSI)), or revenue generated by multiple subscribers including the subscriber associated with UE1 that are associated with the same organization (e.g., company). Likewise, the revenue of the subscriber associated with UE2 may be the revenue generated by the subscriber via UE2, revenue generated by the subscriber via two or more UEs including UE2 that are associated with the subscriber (e.g., two or more UEs sharing the same UE identity (e.g., same IMSI)), or revenue generated by multiple subscribers including the subscriber associated with UE2 that are associated with the same organization (e.g., company). UE1 sends the

Registration Request with a NSSAI value which points to a specific network slice, e.g., Common (fallback) Slice.

• Step S1002: The RAN (e.g., base station 102) sends the received Registration Request from UE1 to the AMF.

• Steps S1004 and S1006: The AMF checks with the subscribed values for the

NSSAI, which will determine if UE1 is eligible to connect to the requested network slice. The subscribed data includes subscribed Single NSSAI (S-NSSAI).

• Steps S1008 and S1010: Once the AMF confirms the UE subscription, the AMF checks with the NSSF (optionally) for available network slices for UE1. The message includes the requested NSSAI, the subscribed S-NSSAI, and UE location.

• Step S1012: The AMF checks with the NWDAF 300 for Slice Selection criteria.

• Step S1014: The NWDAF 300 predicts a congestion or overload condition for the network slice (e.g., by analyzing congestion information obtained as described above). The NWDAF 300 uses subscriber-specific revenue information from the BSS system (Section 1.1.1) to make a decision about whether to allow UE1 to access the network slice. For instance, the NWDAF 300 determines a priority of the subscriber associated with UE1 (which is also referred to herein as the priority of UE1) based on the subscriber-specific revenue information for the subscriber and decides whether to allow UE1 to access the network slice based on the predicted congestion or overload condition and the determined priority.

In this example, the subscriber is a high revenue subscriber, and the NWDAF 300 makes a decision to allow the subscriber to access the network slice (enhanced Mobile Broadband (eMBB) slice).

• Step S1016: The NWDAF 300 notifies the AMF to choose the eMBB slice for UE1 as the subscriber is a high priority subscriber and the quality of experience of the subscriber can be ensured by choosing the eMBB slice.

• Steps S1018 and S1020: The AMF decides that UE1 should connect to the eMBB slice. The AMF then forwards it to the SMF in the eMBB slice. The SMF connects to the eMBB UPF for call processing as per normal procedures.

• Step S1022: UE2 associated with the second subscriber having "Platinum"

priority tries to connect to the network. In this example, the subscriber associated with UE2 generates less revenue than the subscriber associated with UE1. UE2 sends the Registration Request with a NSSAI value which points to a specific network slice, e.g. Common (fallback) Slice.

• Step S1024: The RAN (e.g., base station 102) sends the received Registration Request from UE2 to the AMF.

• Steps S1026 and S1028: The AMF checks with the subscribed values for the

NSSAI, which will determine if UE2 is eligible to connect to the requested network slice. The subscribed data includes subscribed S-NSSAI.

• Steps S1030 and S1032: Once the AMF confirms the UE subscription, the AMF checks with the NSSF (optionally) for available network slices for UE2. The message includes the requested NSSAI, the subscribed S-NSSAI, and UE location.

• Step S1034: The AMF checks with the NWDAF 300 for Slice Selection criteria.

• Step S1036: The NWDAF 300 predicts a congestion or overload condition for the network slice (e.g., by analyzing congestion information obtained as described above). The NWDAF 300 uses subscriber-specific revenue information from the BSS system (Section 1.1.1) to make a decision about whether to allow UE2 to access the network slice. For instance, the NWDAF 300 determines a priority of the subscriber associated with UE2 (which is also referred to herein as the priority of UE2) based on the subscriber-specific revenue information for the subscriber and decides whether to allow UE2 to access the network slice based on the predicted congestion or overload condition and the determined priority.

In this example, the subscriber is a low revenue subscriber, and the NWDAF 300 makes a decision to not allow the subscriber to access the network slice (eMBB slice).

• Step S1038: The NWDAF 300 notifies the AMF to not choose the eMBB slice for UE2 session as the eMBB slice is nearing overload and the subscriber associated with UE2 is a low priority subscriber based on the associated subscriber-specific revenue information.

• Step S1040: The AMF decides that UE2 should not connect to the eMBB slice. In this example, there is no other available slice for the UE2. So, the AMF rejects the request from UE2. b. Selecting a "fallback" default slice, when network/ network slice is

congested

[0122] In case of network slice overload, new subscriber requests may be moved to another low priority "fallback" slice. For example, if there is an overload/congestion situation in the eMBB slice, then the fallback slice can be selected for any new requests coming from the low priority subscriber (based on lower revenue) of the eMBB slice. It will ensure continuity of the session and avoids service interruption but this subscriber may not ensure the same quality of experience as the high priority subscriber.

[0123] In this regard, Figures 11A and 11B illustrate a process for giving a high revenue generating subscriber priority to access a network slice during a congestion situation in accordance with some embodiments of the present disclosure. The process is as follows:

• Steps S1100-S1120 for UE1 are the same as described above with respect to steps S1000-S1020 and, as such, the details are not repeated here.

• Step S1122: UE2 associated with the second subscriber having "Platinum"

priority tries to connect to the network. In this example, the subscriber associated with UE2 generates less revenue than the subscriber associated with UE1. UE2 sends the Registration Request with the NSSAI value which points to a specific network slice, e.g. Common (fallback) Slice. • Step S1124: The RAN (e.g., base station 102) sends the received Registration Request from UE2 to the AMF.

• Steps S1126 and S1128: The AMF checks with the subscribed values for the

NSSAI, which will determine if UE2 is eligible to connect to the requested network slice. The subscribed data includes the subscribed S-NSSAI.

• Steps SI 130 and SI 132: Once the AMF confirms the UE subscription, the AMF checks with the NSSF (optionally) for available network slices for UE2. The message includes the requested NSSAI, the subscribed S-NSSAI, and UE location.

• Step S1134: The AMF checks with the NWDAF 300 for slice selection criteria.

• Step SI 136: The NWDAF 300 predicts a congestion or overload condition for the network slice (e.g., by analyzing congestion information obtained as described above). The NWDAF 300 uses subscriber-specific revenue information from the BSS system (Section 1.1.1) to make a decision about whether to allow UE2 to access the network slice. For instance, the NWDAF 300 determines a priority of the subscriber associated with UE2 (which is also referred to herein as the priority of UE2) based on the subscriber-specific revenue information for the subscriber and decides whether to allow UE2 to access the network slice based on the predicted congestion or overload condition and the determined priority.

In this example, the subscriber is a low revenue subscriber, and the NWDAF 300 makes a decision to not allow the subscriber to access the network slice (eMBB slice). Flowever, in this example, there is a fallback slice, and the NWDAF 300 makes a decision to allow the subscriber to access the fallback slice.

• Step SI 138: The NWDAF 300 notifies the AMF to choose the fallback slice,

rather than the eMBB slice, for UE2 session as the eMBB slice is nearing overload and the subscriber associated with UE2 is a low priority subscriber based on the associated subscriber-specific revenue information.

• Steps SI 140 and SI 142: The AMF decides that UE2 should connect to the

fallback slice. The AMF then forwards it to the SMF in the fallback slice. The SMF connects to the fallback UPF for call processing as per normal procedures.

2.2 Churn Probability based priority

[0124] Similar to customer priority based on revenue, the NWDAF 300 can

additionally or alternatively take subscriber-specific churn information (e.g., the churn probability of the subscriber, e.g., based on historical data) into account when differentiating subscribers (e.g., when prioritizing subscribers or when performing network slice selection in the event of network slice congestion). The subscriber- specific churn information can take into account multiple factors, e.g. duration of subscription, age group, calls to the other operator's service center, calls to own operator's service-center, recent complaints, etc. Based on these criteria, the NWDAF 300 can calculate if this subscriber has a high probability to move to another operator. So, this subscriber can be assigned high priority so that the subscriber's quality of experience is ensured. This will help in reducing the churn. Table 5 below gives an example of some of parameters that can be used for such an evaluation.

[0125] Based on the above criteria, the subscriber can be provided higher priority. To elaborate the subscriber differentiation, the use case of congestion/overload in the network is considered. For simplicity, two options for subscriber differentiation are considered: a. Deprioritizing the low priority customers, when the network/ network slice is congested

[0126] In case a network slice is reaching overload situation, e.g., with resource utilization more than 70% but is not overloaded yet, the network can prioritize the subscriber requests so that higher priority subscribers (based on churn probability) are allowed to access the network slice. Requests for lower priority subscribers are rejected. Priority is calculated here based on the churn probability of the subscriber. [0127] In this regard, Figures 12A and 12B illustrate a process for giving a high churn probability subscriber priority to access a network slice during a congestion situation in accordance with some embodiments of the present disclosure. The process is as follows:

• Step S1200: Subscribers with different initial priorities try to connect to the

network. In particular, in step S1000, UE1 associated with a first subscriber having "Silver" priority tries to access the network. As discussed below, in step S1222, UE2 associated with a second subscriber having "Platinum" priority tries to connect to the network. In this example, the subscriber associated with UE1 has a higher churn probability than the subscriber associated with UE2. UE1 sends the Registration Request with the NSSAI value which points to a specific network slice, e.g. Common (fallback) Slice.

• Step S1202: The RAN (e.g., base station 102) sends the received Registration Request from UE1 to the AMF.

• Steps S1204 and S1206: The AMF checks with the subscribed values for the

NSSAI, which will determine if UE1 is eligible to connect to the requested network slice. The subscribed data includes the subscribed S-NSSAI.

• Steps S1208 and S1210: Once the AMF confirms the UE subscription, the AMF checks with the NSSF (optionally) for available network slices for UE1. The message includes the requested NSSAI, the subscribed S-NSSAI, and UE location.

• Step S1212: The AMF checks with the NWDAF 300 for slice selection criteria.

Note, however, there may be alternative implementations where the NSSF does the check with the NWDAF 300 before sending the reply to the AMF.

• Step S1214: The NWDAF 300 predicts a congestion or overload condition for the network slice (e.g., by analyzing congestion information obtained as described above). The NWDAF 300 uses subscriber-specific churn information (Section 1.1.2) to make a decision about whether to allow UE1 to access the network slice. For instance, the NWDAF 300 determines a priority of the subscriber associated with UE1 (which is also referred to herein as the priority of UE1) based on the subscriber-specific churn information for the subscriber and decides whether to allow UE1 to access the network slice based on the predicted congestion or overload condition and the determined priority. In this example, the subscriber has a high churn probability (e.g., a churn probability that is greater than a predefined threshold), and the NWDAF 300 makes a decision to allow the subscriber to access the network slice (eMBB slice).

• Step S1216: The NWDAF 300 notifies the AMF to choose the eMBB slice for UE1 as the subscriber is a high priority subscriber and the quality of experience of the subscriber can be ensured by choosing the eMBB slice.

• Steps S1218 and S1220: The AMF decides that UE1 should connect to the eMBB slice. The AMF then forwards it to the SMF in the eMBB slice. The SMF connects to the eMBB UPF for call processing as per normal procedures.

• Step S1222: UE2 associated with the second subscriber having "Platinum"

priority tries to connect to the network. In this example, the subscriber associated with UE2 has a lower churn probability than the subscriber associated with UE1. UE2 sends the Registration Request with the NSSAI value which points to a specific network slice, e.g. Common (fallback) Slice.

• Step S1224: The RAN (e.g., base station 102) sends the received Registration Request from UE2 to the AMF.

• Steps S1226 and S1228: The AMF checks with the subscribed values for the

NSSAI, which will determine if UE2 is eligible to connect to the requested network slice. The subscribed data includes the subscribed S-NSSAI.

• Steps S1230 and S1232: Once the AMF confirms the UE subscription, the AMF checks with the NSSF (optionally) for available network slices for UE2. The message includes the requested NSSAI, the subscribed S-NSSAI, and UE location.

• Step S1234: The AMF checks with the NWDAF 300 for slice selection criteria.

Note, however, there may be alternative implementations where the NSSF does the check with the NWDAF 300 before sending the reply to the AMF.

• Step S1236: The NWDAF 300 predicts a congestion or overload condition for the network slice (e.g., by analyzing congestion information obtained as described above). The NWDAF 300 uses subscriber-specific churn information (Section 1.1.2) to make a decision about whether to allow UE2 to access the network slice. For instance, the NWDAF 300 determines a priority of the subscriber associated with UE2 (which is also referred to herein as the priority of UE2) based on the subscriber-specific churn information for the subscriber and decides whether to allow UE2 to access the network slice based on the predicted congestion or overload condition and the determined priority. In this example, the subscriber has a low churn probability, and the NWDAF 300 makes a decision to not allow the subscriber to access the network slice (eMBB slice).

• Step S1238: The NWDAF 300 notifies the AMF to not choose the eMBB slice for UE2 session as the eMBB slice is nearing overload and the subscriber associated with UE2 has a low churn probability.

• Step S1240: The AMF decides that UE2 should not connect to the eMBB slice. In this example, there is no other available slice for the UE2. So, the AMF rejects the request from UE2. b. Selecting a "fallback" default slice, when the network/ network slice is congested

[0128] In case of Network Slice overload, new subscriber requests may be moved to another low priority "fallback" slice. For example, if there is an overload/congestion situation in the eMBB slice then a fallback slice can be selected for any new requests coming from the low priority subscriber (based on churn probability) of the eMBB slice.

It will ensure continuity of the session and avoids service interruption but this subscriber may not ensure same quality of experience as the high priority subscriber.

[0129] In this regard, Figures 13A and 13B illustrate a process for giving a high churn probability subscriber priority to access a network slice during a congestion situation in accordance with some embodiments of the present disclosure. The process is as follows:

• Steps S1300-S1320 for UE1 are the same as described above with respect to steps S1200-S1220 and, as such, the details are not repeated here.

• Step S1322: UE2 associated with the second subscriber having "Platinum"

priority tries to connect to the network. In this example, the subscriber associated with UE2 has a lower churn probability than the subscriber associated with UE1. UE2 sends the Registration Request with a NSSAI value which points to a specific network slice, e.g. Common (fallback) Slice.

• Step S1324: The RAN sends the received Registration Request from UE2 to the AMF.

• Steps S1326 and S1328: The AMF checks with the subscribed values for the

NSSAI, which will determine if UE2 is eligible to connect to the requested network slice. The subscribed data includes the subscribed S-NSSAI. • Steps S1330 and S1332: Once the AMF confirms the UE subscription, the AMF checks with the NSSF (optionally) for available network slices for UE2. The message includes the requested NSSAI, the subscribed S-NSSAI, and UE location.

• Step S1334: The AMF checks with the NWDAF 300 for slice selection criteria.

• Step S1336: The NWDAF 300 predicts a congestion or overload condition for the network slice (e.g., by analyzing congestion information obtained as described above). The NWDAF 300 uses subscriber-specific churn information (Section 1.1.2) to make a decision about whether to allow UE2 to access the network slice. For instance, the NWDAF 300 determines a priority of the subscriber associated with UE2 (which is also referred to herein as the priority of UE2) based on the subscriber-specific churn information for the subscriber and decides whether to allow UE2 to access the network slice based on the predicted congestion or overload condition and the determined priority. In this example, the subscriber has a low churn probability, and the NWDAF 300 makes a decision to not allow the subscriber to access the network slice (eMBB slice). Flowever, in this example, the NWDAF 300 makes a decision to allow the subscriber associated with UE2 to access the fallback slice.

• Step S1338: The NWDAF 300 notifies the AMF to choose the fallback slice,

rather than the eMBB slice, for UE2 session as the eMBB slice is nearing overload and the subscriber associated with UE2 has a low churn probability.

• Steps S1340 and S1342: The AMF decides that UE2 should connect to the

fallback slice. The AMF then forwards it to the SMF in the fallback slice. The SMF connects to the fallback UPF for call processing as per normal procedures.

[0130] Figure 14 is a schematic block diagram of a network node 1400 according to some embodiments of the present disclosure. The network node 1400 may be, for example, a core network node (e.g., a node implementing the NWDAF

300/900/902/904, functionality of a BSS, functionality of an OSS, functionality of a CRM, or any other node described herein). As illustrated, the network node 1400 includes one or more processors 1402 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory 1404, and a network interface 1406. The one or more processors 1402 are also referred to herein as processing circuitry. The one or more processors 1402 operate to provide one or more functions of a network node 1400 as described herein (e.g., with respect to Figure 6). In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 1404 and executed by the one or more processors 1402.

[0131] Figure 15 is a schematic block diagram that illustrates a virtualized

embodiment of the network node 1400 according to some embodiments of the present disclosure. This discussion is equally applicable to other types of network nodes.

Further, other types of network nodes may have similar virtualized architectures.

[0132] As used herein, a "virtualized" network node is an implementation of the network node 1400 in which at least a portion of the functionality of the network node 1400 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the network node 1400 includes one or more processing nodes 1500 coupled to or included as part of a network(s) 1502. Each processing node 1500 includes one or more processors 1504 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 1506, and a network interface 1508. In this example, functions 1510 of the network node 1400 described herein are implemented at the one or more processing nodes 1500 or distributed across the two or more processing nodes 1500 in any desired manner. In some particular embodiments, some or all of the functions 1510 of the network node 1400 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 1500.

[0133] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of network node 1400 or a node (e.g., a processing node 1500) implementing one or more of the functions 1510 of network node 1400 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0134] Figure 16 is a schematic block diagram of the network node 1400 according to some other embodiments of the present disclosure. The network node 1400 includes one or more modules 1600, each of which is implemented in software. The module(s) 1600 provide the functionality of the network node 1400 described herein. This discussion is equally applicable to the processing node 1500 of Figure 15 where the modules 1600 may be implemented at one of the processing nodes 1500 or distributed across multiple processing nodes 1500.

[0135] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processor (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

[0136] While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

[0137] Some example embodiments of the present disclosure are as follows.

[0138] Embodiment 1 : A method performed by a core network node in a core network of a cellular communications network, comprising:

• obtaining subscriber-specific information for a particular subscriber, the

subscriber-specific information comprising:

o revenue-based priority information for the particular subscriber; and/or o churn information for the particular subscriber; and

• initiating one or more operational tasks in the core network based on the

subscriber-specific information for the particular subscriber. [0139] Embodiment 2: The method of embodiment 1 wherein the subscriber-specific information comprises the revenue-based priority information for the particular subscriber.

[0140] Embodiment 3: The method of embodiment 2 wherein the revenue-based priority information for the particular subscriber comprises a priority indication that is a function of an amount of revenue that is: generated via a particular User Equipment,

UE, associated with the particular subscriber; generated by two or more UEs associated with the particular subscriber sharing a common UE identity (e.g., Internal Mobile Subscriber Identity, IMSI); generated by two or more UEs associated with the particular subscriber; or generated by a plurality UEs, including a particular UE associated with the particular subscriber, where the plurality of UEs are associated with a same

organization.

[0141] Embodiments The method of embodiment 3 wherein the priority indication is an absolute priority value, an indication of an manner in which to adjust a priority of the particular subscriber (e.g., increase, decrease, or keep the same), or a relative priority value (e.g., an indication to adjust a priority of the particular subscriber by a value p, where p is an integer value).

[0142] Embodiment 5: The method of embodiment 3 or 4 wherein the amount of revenue is a static amount, a dynamic amount, or a combination of both a static amount of revenue and a dynamic amount of revenue.

[0143] Embodiment 6: The method of any one of embodiments 1 - 5 wherein the subscriber-specific information comprises the churn information for the particular UE.

[0144] Embodiment 7: The method of embodiment 6 wherein obtaining the subscriber-specific information comprises obtaining the churn information, and obtaining the churn information comprises obtaining: an indication of a prediction of whether the particular subscriber will terminate the subscriber's relationship with a respective network operator of the cellular communications network; and/or an indication of a likelihood that the particular subscriber will terminate the subscriber's relationship with a respective network operator of the cellular communications network.

[0145] Embodiment 8: The method of embodiment 7 wherein obtaining the churn information comprises obtaining: the indication of the prediction of whether the particular subscriber will terminate the subscriber's relationship with a respective network operator of the cellular communications network; and/or the indication of the likelihood that the particular subscriber will terminate the subscriber's relationship with the respective network operator of the cellular communications network, from another network node.

[0146] Embodiment 9: The method of embodiment 7 wherein obtaining the churn information comprises:

• obtaining, from one or more other network nodes, churn related information associated with the particular subscriber; and

• generating, based on the churn related information:

o the indication of the prediction of whether the particular subscriber will terminate the subscriber's relationship with a respective network operator of the cellular communications network; and/or

o the indication of the likelihood that the particular subscriber will terminate the subscriber's relationship with the respective network operator of the cellular communications network from another network node.

[0147] Embodiment 10: The method of embodiment 9 wherein the churn related information associated with the particular subscriber comprises: churn related

information for a particular UE associated with the particular subscriber; churn related information for two or more UEs associated with the particular subscriber sharing a common UE identity (e.g., IMSI); churn related information for two or more UEs associated with the particular subscriber; or churn related information for a plurality of subscribers, including the particular subscriber, associated with a same organization.

[0148] Embodiment 11: The method of any one of embodiments 1 to 10 wherein initiating the one or more operational tasks in the core network based on the

subscriber-specific information for the particular subscriber comprises performing a congestion control mechanism based on the subscriber-specific information.

[0149] Embodiment 12: The method of any one of embodiments 1 to 10 wherein initiating the one or more operational tasks in the core network based on the

subscriber-specific information for the particular subscriber comprises selecting a network slice for a UE associated with the particular subscriber based on the subscriber- specific information.

[0150] Embodiment 13: The method of embodiment 12 wherein initiating the one or more operational tasks in the core network based on the subscriber-specific information for the particular subscriber further comprises initiating use of the selected network slice by a UE associated with the particular subscriber.

[0151] Embodiment 14: The method of any one of embodiments 1 to 10 wherein initiating the one or more operational tasks in the core network based on the

subscriber-specific information for the particular subscriber comprises deciding whether to accept a request from a UE associated with the particular subscriber to access the cellular communications network or a particular network slice of the cellular

communications network based on the subscriber-specific information for the particular subscriber.

[0152] Embodiment 15: The method of any one of embodiments 1 to 10 wherein initiating the one or more operational tasks in the core network based on the

subscriber-specific information for the particular subscriber comprises deciding whether to reallocate a UE associated with the particular subscriber from a first network slice of the cellular communications network to a second network slice of the cellular

communications network based on the subscriber-specific information for the particular subscriber.

[0153] Embodiment 16: The method of any one of embodiments 1 to 10 wherein initiating the one or more operational tasks in the core network based on the

subscriber-specific information for the particular subscriber comprises deciding whether to reallocate a UE associated with the particular subscriber from first time-frequency resources in a radio access network of the cellular communications network to second time-frequency resources in the radio access network of the cellular communications network based on the subscriber-specific information for the particular subscriber.

[0154] Embodiment 17: The method of any one of embodiments 1 to 10 wherein initiating the one or more operational tasks in the core network based on the

subscriber-specific information for the particular subscriber comprises deciding whether to reallocate a UE associated with the particular subscriber from a Third Generation Partnership Project, 3GPP, radio access network to a non-3GPP radio access network based on the subscriber-specific information for the particular subscriber.

[0155] Embodiment 18: The method of any one of embodiments 1 to 17 wherein the cellular communications network is a Fifth Generation, 5G, cellular communications network, and the network node is a Network Data Analytics Function, NWDAF, or a central NWDAF. [0156] Embodiment 19: A core network node for a core network of a cellular communications network, the core network node adapted to:

• obtain subscriber-specific information for a particular subscriber, the subscriber- specific information comprising:

o revenue-based priority information for the particular subscriber; and/or o churn information for the particular subscriber; and

• initiate one or more operational tasks in the core network based on the

subscriber-specific information for the particular subscriber.

[0157] Embodiment 20: The core network node of embodiment 19 wherein the core network node is further adapted to perform the method of any one of embodiments 2 to 18.

[0158] At least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, preference should be given to how it is used above. If listed multiple times below, the first listing should be preferred over any subsequent listing(s).

• 3GPP Third Generation Partnership Project

• 5G Fifth Generation

• AF Application Function

• AMF Access and Mobility Function

• AN Access Network

• ASIC Application Specific Integrated Circuit

• AUSF Authentication Server Function

• BSS Business Support System

• CPU Central Processing Unit

• CRM Customer Relationship Management

• DN Data Network

• DNN Data Network Name

• DSP Digital Signal Processor

• eMBB Enhanced Mobile Broadband

• eNB Enhanced or Evolved Node B

• FPGA Field Programmable Gate Array

• GB Gigabyte

• gNB New Radio Base Station • HSS Home Subscriber Service

• ID Identifier

• IMSI Internal Mobile Subscriber Identity

• IP Internet Protocol

• KPI Key Performance Indicator

• LADN Local Area Data Network

• LTE Long Term Evolution

• ML Machine Learning

• MME Mobility Management Entity

• MNP Mobile Number Portability

• MTC Machine Type Communication

• NEF Network Exposure Function

• NF Network Function

• NFVI Network Functions Virtualization Infrastructure

• NR New Radio

• NRF Network Repository Function

• NSSAI Network Slice Selection Assistance Information

• NSSF Network Slice Selection Function

• NWDAF Network Data Analytics Function

• OAM Operations and Management

• OSS Operations Support System

• OTT Over the Top

• PCF Policy Control Function

• PDG Packet Data Gateway

• P-GW Packet Data Network Gateway

• PLMN Public Land Mobile Network

• QoS Quality of Service

• RAM Random Access Memory

• RAN Radio Access Network

• ROM Read Only Memory

• RRH Remote Radio Head

• RTT Round Trip Time

• SCEF Service Capability Exposure Function SMF Session Management Function

S-NSSAI Single Network Slice Selection Assistance Information

TCP Transmission Control Protocol

TR Technical Report

UDF User Data Function

UDM Unified Data Management

UDR User Data Repository

UE User Equipment

UPF User Plane Function

VNF Virtualized Network Function

[0159] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.