Patent Description:
Examples of mobile or wireless telecommunication systems may include the Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN), Long Term Evolution (LTE) Evolved UTRAN (E-UTRAN), LTE-Advanced (LTE-A), MulteFire, LTE-A Pro, and/or fifth generation (<NUM>) radio access technology or new radio (NR) access technology. <NUM> wireless systems refer to the next generation (NG) of radio systems and network architecture. <NUM> is mostly built on a new radio (NR), but a <NUM> (or NG) network can also build on E-UTRA radio. It is estimated that NR may provide bitrates on the order of <NUM>-<NUM> Gbit/s or higher, and may support at least enhanced mobile broadband (eMBB) and ultra-reliable low-latency-communication (URLLC) as well as massive machine type communication (mMTC). NR is expected to deliver extreme broadband and ultra-robust, low latency connectivity and massive networking to support the Internet of Things (IoT). With IoT and machine-to-machine (M2M) communication becoming more widespread, there will be a growing need for networks that meet the needs of lower power, low data rate, and long battery life. It is noted that, in <NUM>, the nodes that can provide radio access functionality to a user equipment (i.e., similar to Node B in UTRAN or eNB in LTE) may be named gNB when built on NR radio and may be named NG-eNB when built on E-UTRA radio.

Further cited prior art documents are: <CIT> showing a system and method for group based handover parameter optimization for wireless radio access network load balancing, <CIT> showing load balancing in wireless networks for improved user equipment throughput, and <CIT> showing network architecture, methods, and devices for a wireless communications network.

The present invention is disclosed according to the appended claims.

It will be readily understood that the components of certain example embodiments, as generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of some example embodiments of systems, methods, apparatuses, and computer program products for service-centric mobility-based traffic steering, is not intended to limit the scope of certain embodiments but is representative of selected example embodiments.

The features, structures, or characteristics of example embodiments described throughout this specification may be combined in any suitable manner in one or more example embodiments, as defined by the claims.

Additionally, if desired, the different functions or operations discussed below may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the described functions or operations may be optional or may be combined. As such, the following description should be considered as merely illustrative of the principles and teachings of certain example embodiments, and not in limitation thereof.

Cognitive autonomous networks (CANs) may be used in <NUM> (radio access) networks and/or other future generations of wireless/mobile networks. As a paradigm for intelligent autonomy in networks, CANs may ensure that an operations, administration, and management (OAM) function may be able to <NUM>) take higher-level goals and derive the appropriate performance targets, <NUM>) learn from its environment and its individual and/or shared experiences therein, <NUM>) learn to contextualize its operating conditions and/or, <NUM>) learn its optimal behavior fitting to specific environments and/or contexts.

<NUM> may support multiple services with differentiated service characteristics, the most widely considered service classes being extreme mobile broadband communications (eMBB), ultra reliable low latency communications (URLLC), and massive machine-type/Internet of things (IoT) communications.

One challenge in the management of a radio access network (RAN) may be the optimization of traffic handled by different cells. A number of procedures have been proposed for this as self-organizing network (SON) use cases, among which may be mobility robustness optimization (MRO) for optimizing handover trigger points, load balancing (LB) for distributing load among cells, and traffic steering (TS) for distributing load among different frequency layers. Corresponding cognitive approaches have been proposed for these use case. All of these, however, may still consider the default system where all services are treated the same as far as the optimization of radio resource management procedures. In the case of <NUM>, however, the different services may have to be dealt with differently (e.g., handover (HO) triggering for MRO, LB or TS may have to consider the services that may be executed, as may be provided for by certain embodiments described herein).

Mobility triggering may have to account for the services that are being handled. For a given user, the performance of a given cell may be acceptable if evaluated according to radio link characteristics like radio link failures (RLFs), handover ping pongs (PPs), or handover successes. However, the performance may be unacceptable when evaluated in terms of service characteristics, like end-to-end latency, throughput, packet loss, etc. For example, a cell A, with a very long latency, may be unusable for URLLC services, which have an upper bound on the end-to-end latency. Legacy LB and TS may account for throughput constraints, but from the perspective of the network (e.g., to redistribute the load among cells and layers but not to allow a user equipment (UE) to be served by the cell that maximizes the UE's service expectations). In this case, for example, another cell, B, with low latency may be preferred to cell A, even if cell B has a higher probability of RLFs when compared to cell A. This may be the case because as far as URLLC services are concerned, long latency may have as negative of an impact as a RLF. For example, even if the true count of RLFs is low, if each long latency event is counted as a RLF, the cell with few long-latency events may become preferable.

Service-specific optimization may also imply that, for a given service, the optimization may be done in a consistent way across the network (e.g., to consider network-wide events like packet loss or end-to-end latency). Consequently, there may be a need for a mechanism to coordinate the optimization among different cells.

Legacy MRO use cases may only consider radio link performance to optimize the HO trigger points. An MRO function may evaluate instantaneous, or historical, count or distribution of events like radio link failure, and may decide how to change the values of the HO trigger parameters that include the hysteresis (Hys) value, the time-to-trigger (TTT), and the cell-specific offset (CIO). The underlying HO triggering in the network node may include that the handover trigger points can be set differently for each user. The legacy MRO optimization function, however, does not differentiate among the different services that may be carried through a network node.

Some LB and TS use cases may consider the cell load to redistribute the load among cells with the intention to maximize an achieved user throughput. The LB/TS operations may evaluate the load in the cells to adjust the cells' CIO values with the intention to maximize the users' satisfaction in achieving the expected throughput. As with MRO, the legacy LB/TS operations do not differentiate among the services served by the users and, as such, do not consider the performance related to the other service-related metrics.

Some embodiments described herein provide a solution that accounts for different services in the handover optimization decisions. For example, some embodiments may provide a service-centric traffic steering (SCTS) entity that receives and processes quality of service (QoS) or quality of experience (QoE) data (QoS and QoE data may be referred to collectively as QoS/E data) and optionally link performance data, and determines optimal HO points for different kinds of services for a set of users (e.g., UEs). In addition, some embodiments may utilize a machine learning engine to account for different contexts in different cells and/or for different services, and/or may select handover settings for a UE under different cell and/or service contexts (e.g., a context may include a mobility profile, a packet size, and/or the like for a service or service class). This may allow for coordination of optimization among different cells, while considering the performance related to the other service-related metrics, thereby improving operations of a network with respect to handover optimization.

<FIG> illustrates an example of service-centric mobility robustness optimization (MRO), according to some embodiments. <FIG> illustrates a user equipment <NUM>, a network node <NUM>, and a SCTS entity <NUM> (that may include a link KPIs handler <NUM>, a QoS/E handler <NUM>, and a machine learning (ML) decision engine <NUM>).

The network node <NUM> may provide, and the SCTS entity <NUM> may receive data. As illustrated at <NUM>, the network node <NUM> provides QoS/E data (e.g., that identifies QoS/E attributes, such as latency, throughput, and/or the like) for the UE <NUM>. As illustrated at <NUM>, the network node102 may provide link performance data (e.g., that is related to RLFs, handover failures (HOFs), handover successes (HOSs), handover ping pongs (PPs), and/or the like. The link KPIs handler <NUM> may process the link performance data. For example, the link KPIs handler <NUM> may aggregate link performance data associated with radio links between multiple UEs <NUM>. The QoS/E handler <NUM> may process the QoS/E data. For example, the QoS/E handler may process the QoS/E data to aggregate QoS/E data associated with multiple UEs.

The SCTS entity <NUM> determines a handover trigger point (e.g., a value) for different kinds of services associated with the UE <NUM>. For example, as illustrated at <NUM>, the link KPIs handler <NUM> and the QoS/E handler <NUM> may provide the QoS/E data and optionally the link performance data to the ML decision engine <NUM>, and the ML decision engine <NUM> may process the data to determine the handover trigger point. Utilizing the ML decision engine <NUM> may improve optimization of handovers, may result in faster handover trigger determinations, and/or the like, which may improve an efficiency of use of network resources, such as bandwidth and/or network node processing resources. As illustrated at <NUM>, the SCTS entity <NUM> provides, and the network node <NUM> may receive, handover trigger points for one or more trigger parameters. For example, the one or more trigger parameters may include a hysteresis value, a time-to-trigger (TTT), or a cell-specific offset (CIO).

In this way, some embodiments described herein provide for SCTS via an SCTS entity <NUM>. Besides optionally taking in radio link performance data, the SCTS <NUM> takes in QoS/E data from the different users to decide the optimal HO trigger points for different kinds of services that are carried by the users, which may improve operations of a network with respect to handover optimization. As described above, such QoS/E data may include the user's achieved throughput, radio-specific or end-to-end latency, packet losses, and/or any other service-related performance indicators. Additionally, or alternatively, the SCTS entity <NUM> may consider insights from a Mobility Pattern Prediction (MPP) service that provides predictions on the user mobility and/or the service they are expected to use.

Since SCTS may consider network-wide effects, but the observations on the radio interface may significantly vary when considered across multiple cells, the SCTS entity <NUM> may apply a machine learning operation (e.g., via the ML decision engine <NUM>). For example, the machine learning operation may be capable of capturing insight from the different observations in order to derive the cell-specific, but network appropriate, configurations. In other words, the machine learning operations may account for different contexts in different cells and/or for different services, such as to derive a model that selects an appropriate (the most appropriate, in some embodiments) handover settings for each UE under these different cell and/or service contexts. Candidate solutions for such a machine learning operation may use supervised learning, reinforcement learning, and/or the like.

There may be multiple options for implementing certain embodiments described herein. For example, certain embodiments may be implemented as an extension of legacy MRO/LB or TS operations of a network (as illustrated in, and described with respect to, <FIG> below), or as standalone functions alongside legacy operations (as illustrated in, and described with respect to, <FIG> below), and/or the like. Thus, certain embodiments described herein may allow for operation with legacy networks, which may improve the operations of the legacy networks with respect to handover optimization.

As described above, <FIG> is provided as an example. Other examples are possible, according to some embodiments.

<FIG> illustrates an example of SCTS as an inner loop optimization after MRO, LB, and/or TS, according to some embodiments. For example, <FIG> illustrates an example implementation of certain embodiments as an extension of legacy MRO/LB or TS operations of a network (e.g., where the SCTS entity <NUM> may operate as an inner loop optimization after MRO, LB or TS). <FIG> illustrates a UE <NUM>, a network node <NUM>, and a SCTS entity <NUM> (e.g., that includes a link KPIs handler <NUM>, a QoS/E handler <NUM>, and a ML decision engine <NUM>), similar to that described above with respect to <FIG>. In addition, <FIG> illustrates a legacy MRO/LB/TS module <NUM> (e.g., that performs legacy MRO, LB, TS, and/or the like operations).

As illustrated at <NUM>, the network node <NUM> may provide, and the SCTS entity <NUM> receives, QoS/E data that is similar to that described above. As illustrated at <NUM>, the network node <NUM> may provide, and the legacy MRO/LB/TS module <NUM> may receive, link performance data that is similar to that described above. The legacy MRO/LB/TS module <NUM> may process the link performance data to perform MRO, LB, TS, and/or the like operations.

As illustrated at <NUM>, the legacy MRO/LB/TS module <NUM> may provide, and the SCTS entity <NUM> may receive, one or more trigger parameters that are similar to that described above. As shown at <NUM>, the link KPIs handler <NUM> and/or the QoS/E handler <NUM> may provide the one or more trigger parameters, the QoS/E data, and/or output of processing the one or more trigger parameters and/or the QoS/E data to the ML decision engine <NUM>. The ML decision engine <NUM> may update the one or more trigger parameters from the legacy MRO/LB/TS module <NUM> using machine learning operations. As shown at <NUM>, the SCTS may provide configurations for the one or more trigger parameters to the legacy MRO/LB/TS module <NUM> (e.g., to update the legacy MRO/LB/TS module <NUM>'s operations with respect to determining the one or more trigger parameters). As illustrated at <NUM>, the SCTS entity <NUM> may provide updated values for the one or more trigger parameters to the network node <NUM>.

In this way, the SCTS entity <NUM> extends the legacy MRO/LB/TS module <NUM> with a QoS/E handling module (e.g., the QoS/E handler <NUM>) that may evaluate the appropriateness of the QoS/E data, and may characterize the degree to which the QoS/E performance expectations may be met by the serving cell or whether a target cell may offer a better chance of fulfilling those targets. This may improve operations of a legacy network with respect to handover optimization, which may result in improved handover triggers, reduced latency with respect to determining handover triggers, and/or the like, which may conserve network resources with respect to handovers and/or handover optimization. The values of attributes that may be submitted to the SCTS entity <NUM> may be aggregated within the SCTS entity <NUM> (e.g., by the QoS/E handler <NUM>) or may be aggregated outside the SCTS entity <NUM>, so that the QoS/E handler <NUM> focusses on the optimization task.

Other examples are possible, according to some embodiments.

<FIG> illustrates an example deep Q-learning neural network (DQN) of the ML decision engine, according to some embodiments. <FIG> illustrates a network node <NUM> and a ML decision engine <NUM> (e.g., implemented as a DQN decision engine), similar to that described elsewhere herein. <FIG> further illustrates that the DQN decision engine <NUM> may include an online Q-network <NUM> (e.g., to process service attributes, link performance data, and/or QoS/E performance metrics), a target Q-network <NUM> (e.g., that provides added stability by separating action selection by the online Q-network <NUM> from policy evaluation by the target Q-network <NUM>), a replay memory <NUM> (e.g., that stores transitions so that a set is randomly selected to make a batch used to train one or more of the Q-networks <NUM>, <NUM>, and that ensures that the transitions in the batch are de-correlates), and a DQN loss module <NUM> (e.g., that computes the loss for a given batch).

The SCTS entity <NUM> may have to consider each UE's supported service(s) in each cell and the effects that different mobility settings may have on that UE's service (or service mix). This may result in a diverse input parameter space, which may be complex to manage using rule-based operations. This diversity of observations may, however, be adequately handled by an ML-based decision engine (e.g., the ML decision engine <NUM>).

The ML decision engine <NUM> may be a reinforcement learning module whose different input states include QoS/E data and may include the link performance, expected service QoS/E characteristics, historical performance of related services in the different cells, and/or the like. The ML decision engine <NUM> may learn how to choose the right combination of handover parameters for the specific service over the multiple observations it makes in multiple cells at different time instances. This may provide improved handover optimization relative to legacy handover optimization.

An example implementation of the ML decision engine <NUM>, illustrated in <FIG>, may be a DQN decision engine that takes QoS/E data and may take the link performance data as input and may learn the appropriate neural network weights that may result in output HO settings that maximize a reward. For example, the reward may be a combination of low failure rates (e.g., RLF, HOF, etc.) and/or high service metrics (e.g., throughput, low latency, etc.).

The input may be the feature vector φ(s, a) that is a sample in observation space. The DQN, with a matrix of weights/parameters θ, may implement the ML operations of policy evaluation and/or policy improvement, as described below. At a given time t, given an instantaneous reward rt following action a, in state st, the policy evaluation operation may include computing a temporal difference δ as in (<NUM>) below where there is a discount factor that balances between immediate and future rewards. The corresponding squared loss may be given by (<NUM>), below. <MAT> <MAT>.

The loss function may be minimized by computing the gradients ∇θJ(θ). For the DQN, a target network may be maintained with parameters θ' that may be similar to the online network parameter θ, but sampled every N operations. Correspondingly, the temporal difference may be given by (<NUM>), below, while loss gradient may be computed using stochastic gradient descent with the samples drawn from set a D in the replay memory. The gradients ∇θJ(θ) may be computed using (<NUM>) below, which may then be used to update neural network parameters θ in (<NUM>). <MAT> <MAT>.

Policy improvement may include the neural network parameters θ being updated as θ ← θ - α∇θJ(θ), which may translate into (<NUM>), below. The Q-learning operation may then be completed by deriving policy π(s) as in (<NUM>), below. <MAT> <MAT>.

In certain embodiments, the ML decision engine <NUM> may comprise a supervised learning module that may be trained on service-related performance data for different users in different cells. The ML decision engine <NUM>, in this case, may choose the appropriate output parameters at any time during the operations based on a trained model.

<FIG> illustrates an example flow diagram of a method, according to some embodiments. For example, <FIG> shows example operations of a SCTS entity (e.g., similar to, or of, apparatus <NUM> of <FIG>). For example, <FIG> may illustrate example operations of a SCTS entity <NUM> described elsewhere herein. Some of the operations illustrated in <FIG> may be similar to some operations shown in, and described with respect to, <FIG>.

In an embodiment, the method may include, at <NUM>, receiving data that comprises quality of service or quality of experience (QoS/E) data and may comprise radio link performance data. For example, the SCTS entity <NUM> may receive the data from a network node (e.g., network node <NUM>). The radio link performance data may be associated with at least one radio link between at least one network node and at least one user equipment (UE). The quality of service or quality of experience (QoS/E) data are associated with the at least one user equipment (UE).

In an embodiment, the method includes, at <NUM>, determining at least one handover (HO) trigger point for at least one handover trigger parameter for at least one kind of service associated with the at least one user equipment (UE). For example, the SCTS <NUM> determines the at least one handover (HO) trigger point after receiving the data. In an embodiment, the method includes, at <NUM>, providing, e.g. to the network node, the at least one handover trigger point for the at least one handover trigger parameter. For example, the SCTS entity <NUM> provides the at least one handover (HO) trigger point to the network node after determining the at least one handover (HO) trigger point.

In some embodiments, the at least one handover (HO) trigger parameter may include at least one of a hysteresis value, a time-to-trigger (TTT), or a cell-specific offset (CIO). In some embodiments, the quality of service or quality of experience (QoS/E) data may comprise data related to at least one of an achieved throughput for the user equipment (UE), a radio-specific or end-to-end latency for the user equipment (UE), or a packet loss associated with user equipment (UE). In some embodiments, the data may further comprise mobility pattern prediction (MPP) data.

In some embodiments, determining the at least one handover (HO) trigger point may comprise utilizing at least one machine learning decision engine to determine the at least one handover (HO) trigger point. In some embodiments, the at least one machine learning decision engine may consider at least one context in at least one cell for at least one service. In some embodiments, the SCTS entity may operate in conjunction with at least one legacy mobility robustness optimization (MRO)/load balancing (LB)/traffic steering (TS) module. In some embodiments, the method may further comprise aggregating the data for the at least one user equipment (UE). In some embodiments, the data may be received in an aggregated form.

As described above, <FIG> is provided as an example. Other examples are possible according to some embodiments.

<FIG> illustrates an example of an apparatus <NUM>. The apparatus <NUM> may comprise a network node (e.g., a network node <NUM>), as described elsewhere herein. The apparatus <NUM> may comprise a node, host, or server in a communications network or serving such a network. For example, apparatus <NUM> may comprise a network node, satellite, base station, a Node B, an evolved Node B (eNB), <NUM> Node B or access point, next generation Node B (NG-NB or gNB), and/or a WLAN access point, associated with a radio access network, such as a LTE network, <NUM> or NR.

For instance, where apparatus <NUM> represents a gNB, it may be configured in a central unit (CU) and distributed unit (DU) architecture that divides the gNB functionality.

The apparatus <NUM> may further include or be coupled to (internal or external) a drive or port that is configured to accept and read an external computer readable storage medium, such as an optical disc, USB drive, flash drive, or any other storage medium.

The apparatus <NUM> may also include or be coupled to one or more antennas <NUM> for transmitting and receiving signals and/or data to and from apparatus <NUM>. Apparatus <NUM> may further include or be coupled to a transceiver <NUM> configured to transmit and receive information. The transceiver <NUM> may include, for example, a plurality of radio interfaces that may be coupled to the antenna(s) <NUM>. The radio interfaces may correspond to a plurality of radio access technologies including one or more of GSM, NB-IoT, LTE, <NUM>, WLAN, Bluetooth, BT-LE, NFC, radio frequency identifier (RFID), ultrawideband (UWB), MulteFire, and the like. The radio interface may include components, such as filters, converters (for example, digital-to-analog converters and the like), mappers, a Fast Fourier Transform (FFT) module, and the like, to generate symbols for a transmission via one or more downlinks and to receive symbols (for example, via an uplink).

Transceiver <NUM> may be capable of transmitting and receiving signals or data directly. Additionally or alternatively, Apparatus <NUM> may include an input and/or output device (I/O device).

Memory <NUM> may store software modules that provide functionality when executed by processor <NUM>.

Processor <NUM> and memory <NUM> may be included in or may form a part of processing circuitry or control circuitry. In addition, transceiver <NUM> may be included in or may form a part of transceiver circuitry.

As introduced above, apparatus <NUM> may be a network node or RAN node, such as a base station, access point, Node B, eNB, gNB, WLAN access point, or the like.

According to certain embodiments, apparatus <NUM> may be controlled by memory <NUM> and processor <NUM> to perform the functions associated with any of the embodiments described herein, such as some operations of <FIG>.

For instance, apparatus <NUM> may be controlled by memory <NUM> and processor <NUM> to provide data to one or more other network entities. The data may include link performance data or QoS/E data. Apparatus <NUM> may be controlled by memory <NUM> and processor <NUM> to receive one or more handover trigger points for one or more handover parameters.

<FIG> illustrates an example of an apparatus <NUM> according to another embodiment. In some embodiments, apparatus <NUM> may comprise a SCTS entity (e.g., a SCTS entity <NUM>), as described elsewhere herein. In some embodiments, apparatus <NUM> may comprise a node, host, or server in a communications network or serving such a network. For example, apparatus <NUM> may comprise a server in a data center, a computing node in a network, and/or the like. In some embodiments, the SCTS entity may be implemented as a computing node of apparatus <NUM> described above.

In some example embodiments, apparatus <NUM> may include one or more processors, one or more computer-readable storage medium (for example, memory, storage, or the like), and/or one or more radio access components (for example, a modem, a transceiver, or the like).

Processor <NUM> performs functions associated with the operation of apparatus <NUM> including, as some examples, one or more operations described with respect to <FIG>.

In some embodiments, apparatus <NUM> may also include or be coupled to one or more antennas <NUM> for receiving a signal and for transmitting from apparatus <NUM>.

As discussed above, according to some embodiments, apparatus <NUM> may comprise a server, a computing node, and/or the like, for example. According to certain embodiments, apparatus <NUM> is controlled by memory <NUM> and processor <NUM> to perform the functions associated with example embodiments described herein. For example, in some embodiments, apparatus <NUM> is configured to perform one or more of the processes depicted in, or described with respect to, any of <FIG>.

For instance, in an embodiment, apparatus <NUM> is controlled by memory <NUM> and processor <NUM> to receive data that comprises quality of service or quality of experience (QoS/E) data and optionally radio link performance data. The radio link performance data are associated with at least one radio link between at least one network node and at least one user equipment (UE). The quality of service or quality of experience (QoS/E) data are associated with the at least one user equipment (UE). In an embodiment, apparatus <NUM> is controlled by memory <NUM> and processor <NUM> to determine at least one handover (HO) trigger point for at least one handover (HO) trigger parameter for at least one kind of service associated with the at least one user equipment (UE). In an embodiment, apparatus <NUM> is controlled by memory <NUM> and processor <NUM> to provide the at least one handover (HO) trigger point for the at least one handover (HO) trigger parameter.

Therefore, certain example embodiments provide several technological improvements, enhancements, and/or advantages over existing technological processes. For example, one benefit of some example embodiments is an ability to account for different services in handover optimization decisions. Accordingly, the use of some example embodiments results in improved functioning of communications networks and their nodes and, therefore constitute an improvement at least to the technological field of handover optimization, among others.

In some example embodiments, the functionality of any of the methods, processes, signaling diagrams, algorithms or flow charts described herein may be implemented by software and/or computer program code or portions of code stored in memory or other computer readable or tangible media, and executed by a processor.

In some example embodiments, an apparatus may be included or be associated with at least one software application, module, unit or entity configured as arithmetic operation(s), or as a program or portions of it (including an added or updated software routine), executed by at least one operation processor. Programs, also called program products or computer programs, including software routines, applets and macros, may be stored in any apparatus-readable data storage medium and may include program instructions to perform particular tasks.

A computer program product may include one or more computer-executable components which, when the program is run, are configured to carry out some example embodiments. The one or more computer-executable components may be at least one software code or portions of code. Modifications and configurations required for implementing functionality of an example embodiment may be performed as routine(s), which may be implemented as added or updated software routine(s). In one example, software routine(s) may be downloaded into the apparatus.

As an example, software or a computer program code or portions of code may be in a source code form, object code form, or in some intermediate form, and it may be stored in some sort of carrier, distribution medium, or computer readable medium, which may be any entity or device capable of carrying the program. Such carriers may include a record medium, computer memory, read-only memory, photoelectrical and/or electrical carrier signal, telecommunications signal, and/or software distribution package, for example. The computer readable medium or computer readable storage medium may be a non-transitory medium.

In other example embodiments, the functionality may be performed by hardware or circuitry included in an apparatus (e.g., apparatus <NUM> or apparatus <NUM>), for example through the use of an application specific integrated circuit (ASIC), a programmable gate array (PGA), a field programmable gate array (FPGA), or any other combination of hardware and software. In yet another example embodiment, the functionality may be implemented as a signal, such as a non-tangible means that can be carried by an electromagnetic signal downloaded from the Internet or other network.

Example embodiments described herein apply equally to both singular and plural implementations, regardless of whether singular or plural language is used in connection with describing certain embodiments. For example, an embodiment that describes operations of a single network node equally applies to embodiments that include multiple instances of the network node, and vice versa.

Claim 1:
A method for service-centric mobility-based traffic steering, characterized by comprising:
receiving (<NUM>), by a service-centric traffic steering, SCTS, entity, data that comprises quality of service, QoS, or quality of experience, QoE, QoS/E, data,
wherein the quality of service, QoS, or quality of experience, QoE, QoS/E, data is associated with at least one user equipment, UE and wherein the data further comprises mobility pattern prediction data;
determining (<NUM>), by the service-centric traffic steering, SCTS, entity, at least one handover, HO, trigger point for at least one handover, HO, trigger parameter for at least one kind of service associated with the at least one user equipment, UE, based on the quality of service, QoS, or quality of experience, QoE, QoS/E, data; and
providing (<NUM>), by the service-centric traffic steering, SCTS, entity, the at least one handover, HO, trigger point for the at least one handover, HO, trigger parameter wherein determining the at least one handover trigger point comprises utilizing at least one machine learning decision engine to determine the at least one handover trigger point, and wherein the at least one machine learning decision engine considers at least one context in at least one cell for at least one service, wherein the machine learning engine is configured to account for different contexts in different cells and/or for different services, and may select handover settings for a UE under different cell and/or service contexts, where a context includes a mobility profile and a packet size.