WO2016101972A1

WO2016101972A1 - Srvcc handover decision based on statistical data on terminal behavior

Info

Publication number: WO2016101972A1
Application number: PCT/EP2014/078988
Authority: WO
Inventors: Benedek Kovács; Gábor MAGYAR; András RÁCZ; Norbert REIDER; Peter Vaderna
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2014-12-22
Filing date: 2014-12-22
Publication date: 2016-06-30

Abstract

A technique for optimizing, based on information from an analytics engine, a decision concerning an SRVCC handover of a UE is disclosed. In a first method aspect, the method is performed in an IMS core and comprises the steps of inquiring, from the analytics engine, a recommendation on whether the PS domain or the CS domain is to be the access domain for an originating side for the UE, receiving the recommendation comprising a probability per UE that an SRVCC handover will occur after initiation of a voice call in VoLTE, and selecting, based on the probability, one of the PS domain and CS domain as the access domain for the originating side for the UE. In a second method aspect, the analytics engine has stored, per UE, a probability that an SRVCC handover will occur after initiation of a UE voice call in VoLTE. The engine transmits the recommendation comprising the probability per UE.

Description

SRVCC HANDOVER DECISION BASED ON STATISTICAL DATA ON TERMINAL

BEHAVIOR

Technical Field

The present disclosure generally relates to optimizing a decision concerning a handover of a User Equipment (UE), in particular to optimizing, based on information from an analytics engine, a decision concerning a Single Radio Voice Call Continuity (SRVCC) handover of a UE. The techniques of the present disclosure may be embodied in methods and/or apparatuses.

Background

Long Term Evolution (LTE) and voice over LTE (VoLTE) service is being deployed in the world today in a stepwise manner (i.e., gradually) so that it will co-exist with Wireless Code Division Multiple Access (WCDMA) and/or Global System for Mobile Communications (GSM) over a comparatively long period of time. LTE coverage is thus typically spotty, starting with covering big cities and crowded areas in an island^¬ like fashion. To support voice services over areas with such spotty LTE coverage with WCDMA/GSM as fallback technology, two mechanisms have been developed and standardized for switching between LTE and Circuit Switched (CS) voice services, that is Circuit-switched fallback (CSFB) on the one hand, and SRVCC on the other.

The main difference between the two mechanisms resides in that CSFB can switch the UE to the CS domain at the beginning of a call, while SRVCC can switch from VoLTE to CS domain during an ongoing call.

In case of CSFB and the UE trying to initiate a CS call while being connected to LTE (or camping on LTE in idle mode), the UE first needs to initiate a Service Request toward the core network indicating its request to switch to the CS domain. In response to this request, the network assists the handover of the UE to another technology (e.g., 2^nd Generation/3^rd Generation (2G/3G)), where CS domain services are available. Accordingly, in a similar fashion, when an incoming CS call for the UE arrives at the core network while the UE is connected to LTE, the core network initiates Paging toward the UE indicating the reason of the Paging as 'incoming CS call arrived'. In response to that Paging, the UE initiates a same Service Request with 'CS domain switch needed' as in the UE-originated call case.

It is commonplace for the CSFB mechanism to decide the switch to the CS domain at the beginning of the call, and then the call remains on the CS domain until the call is completed.

In case of the SRVCC handover, the call can be initiated in the Packet Switched (PS) domain, i.e., using VoLTE service and is switched to CS domain only when needed, i.e., when the UE is liable to leave LTE network coverage. The SRVCC handover mechanism is fully network-controlled, and as such, the call remains under control of the Internet Protocol (IP) Multimedia Subsystem (IMS) core network, which

maintains access to subscribed services implemented in the IMS/Multimedia

Telephony (MMTel) service engine before, during and after the handover. To complete this type of handover, the following two steps need to be combined:

- 1) the traditional Inter-Radio Access Technology (IRAT) handover, which hands the terminal from LTE radio access over to WCDMA/GSM radio access.

- 2) A new mechanism to move access control and voice media anchoring from the Evolved Packet Core (EPC) to the mobile Softswitch (MSS).

The combination of these two steps has raised concerns in the telecom industry regarding the ability of the technology to meet the required performance levels.

There is a risk here for call drop which must be kept at a very low level. On the other hand, from a signaling load perspective, the SRVCC handover is - in comparison to other options - very costly.

There have been certain problems with existing solutions not hitherto realized, as will be detailed below.

The voice handover from LTE to legacy CS in WCDMA/GSM, as it is solved today through the SRVCC handover, is definitely costly from signaling point of view and can be risky from a performance point of view.

Therefore, there is a need for a network management solution that manages these voice handovers in LTE so that both performance and cost is taken into

consideration. Further, the whole process is to be optimized from a global network operation point of view, such that the risks and costs of SRVCC handovers are minimized. In existing solutions, a voice call is:

- either initiated always over CS domain (CSFB solution), which has the drawback that PS domain voice services (VoLTE) will not be used, but has the benefit that costly PS-CS handovers can be avoided, or

- the call is always initiated over PS domain (SRVCC solution), which has the benefit of taking advantage of the full potential of PS voice, but has the drawback that the system needs to be dimensioned for a high number of costly SRVCC handovers.

To sum up, there is no solution today that could combine the benefits of the two approaches and that could also optimize the trade-off of using PS voice calls as much as possible and avoiding costly SRVCC handovers as much as possible.

Summary

Accordingly, there is a need for an implementation of a scheme that avoids one or more of the problems discussed above, or other related problems.

In a first aspect, there is provided a method for optimizing, based on information from an analytics engine, a decision concerning a Single Radio Voice Call Continuity, SRVCC, handover of a User Equipment, UE, the method being performed in an Internet Protocol Multimedia Subsystem, IMS, core, and comprising the steps of inquiring, from the analytics engine, a recommendation on whether the Packet Switched, PS, domain or the Circuit Switched, CS, domain is to be the access domain for an originating side for the UE; receiving the recommendation comprising a probability per UE that an SRVCC handover will occur after initiation of a voice call in Voice over Long Term Evolution, VoLTE; and selecting, based on the probability, one of the PS domain and CS domain as the access domain for the originating side for the UE. In this way, the imminent SRVCC handover occurrence is estimated and avoided wherever possible, whereas the PS voice calls are used wherever possible.

In a first refinement of the first aspect, if the selected access domain for the originating side is the CS domain while the UE is currently in the PS domain, the method may further comprise transmitting a negative reply to the UE. If so, the negative reply may be one of a Session Initiation Protocol BYE, SIP_BYE, message and a SIP_Cancel message. Still further, the method may further comprise triggering the UE to fall back to the CS domain using Circuit Switched Fallback, CSFB, wherein the triggering is directed to the Originating Access Domain Selection, O-ADS, function in the UE. Accordingly, this first scenario for the UE can be managed using basically standard messages.

In a second refinement of the first aspect, if the selected access domain for the originating side is the PS domain and the IMS core comprises a Serving Call Session Control Function, S-CSCF, and a Service Centralization and Continuity Application Server, SCC-AS, the method may further comprise signalling, from the S-CSCF to the SCC-AS, to attain access domain selection for a terminating side. In this case, the IMS core may be connected to an Operating Support System/Business Support System, OSS/BSS, system comprising the analytics engine, and the method may further comprise interrogating the analytics engine for the recommendation. In the latter case, the selection step may be performed by the SCC-AS. Thus, this second scenario for the UE ascertains maintenance of the PS domain for the UE as long as possible.

In a third refinement of the first aspect, if the selected access domain is the CS domain for a terminating side while a terminating UE is currently in the PS domain, the IMS core may comprise a Serving Call Session Control Function, S-CSCF, and a Service Centralization and Continuity Application Server, SCC-AS, and the method may further comprise initiating, by the SCC-AS and via a Multimedia Management Entity, MME, a Circuit-switched Fallback, CSFB, procedure towards the terminating UE. Hence, this third scenario for the UE can be handled while avoiding costly PS-CS handovers wherever possible.

In a second aspect, there is provided a method for optimizing, based on information from an analytics engine, a decision concerning a Single Radio Voice Call Continuity, SRVCC, handover of a User Equipment, UE, the analytics engine having stored, per UE, a probability that an SRVCC handover will occur after initiation of a UE voice call in Voice over Long Term Evolution, VoLTE, the method being performed in the analytics engine and comprising the steps of receiving, from an Internet Protocol Multimedia Subsystem, IMS, core, a request for a recommendation on whether the Packet Switched, PS, domain or the Circuit Switched, CS, domain is to be an access domain for an originating side for the UE, and transmitting the recommendation comprising the probability per UE. In this way, as for the first aspect, the imminent SRVCC handover occurrence is estimated and avoided wherever possible, whereas the PS voice calls are used wherever possible. In a first refinement of the second aspect, the method may further comprise maintaining a mobility profile model per UE based on activity data of the UE enabling prediction of the probability that the SRVCC handover will occur. If so, the method may further comprise assigning the probability to a VoLTE call setup based on a given set of input parameters. In addition or alternatively, the method may further comprise learning the mobility profile model on a per UE, per cell basis. In this way, the analytics engine may make an informed decision on which recommendation to give to the P-CSCF/S-CSCF.

In a second refinement (comprising the first refinement) of the second aspect, the mobility profile model may comprise the following entries per UE: time of day, user identifier, ID, and a mobility descriptor. In this case, the mobility descriptor may comprise the following entries: a direction of movement inwards or outwards an LTE coverage area, an average estimated speed of movement, a variance of the speed, and a number of samples yielding the direction, the speed and the variance. In addition or alternatively, the mobility profile model may additionally comprise at least one of the following entries: UE terminal type, applications used on the UE, and statistics on the length of the UE voice call. In this way, the informed decision made by the analytics engine takes into account typical behavior of each user in terms of mobility patterns, thus increasing accuracy of the recommendation made.

In a third refinement of the second aspect, the probability may be based on a second probability of the UE leaving an LTE coverage area. If so, the second probability may be calculated for each UE, each cell and each time of day for a fixed timeframe. Alternatively, the second probability may be calculated as a weighted sum of the probabilities per timeframe multiplied by a call duration histogram entry per the timeframe. As a further alternative, the second probability may be calculated, per UE called, based on different histograms pertaining to the respective calling UEs, so that the sum of the probabilities for the different timeframes is weighted by the histogram related to the particular calling UE. In this way, the informed decision made by the analytics engine takes into account typical behavior of each user in terms of call behavior, thus equally increasing accuracy of the recommendation made.

In a third aspect, there is provided a computer program product comprising program code portions for performing the method of the first and second aspects when the computer program product is executed on one or more computing devices. The computer program product may be stored on a computer readable recording medium.

In a fourth aspect, there is provided an Internet Protocol Multimedia Subsystem, IMS, core for optimizing, based on information from an analytics engine, a decision concerning a Single Radio Voice Call Continuity, SRVCC, handover of a User

Equipment, UE, the IMS core comprising a component configured to inquire, from the analytics engine, a recommendation on whether the Packet Switched, PS, domain or the Circuit Switched, CS, domain is to be an access domain for an originating side for the UE, a component configured to receive the recommendation comprising a probability per UE that an SRVCC handover will occur after initiation of a voice call in Voice over Long Term Evolution, VoLTE, and a component configured to select, based on the probability, one of the PS domain and CS domain as the access domain for the originating side for the UE.

In a fifth aspect, there is provided an analytics engine for optimizing, based on information from the analytics engine, a decision concerning a Single Radio Voice Call Continuity, SRVCC, handover of a User Equipment, UE, the analytics engine having stored, per UE, a probability that an SRVCC handover will occur after initiation of a UE voice call in Voice over Long Term Evolution, VoLTE, the analytics engine comprising a component configured to receive, from an Internet Protocol Multimedia Subsystem, IMS, core, a request for a recommendation on whether the Packet Switched, PS, domain or the Circuit Switched, CS, domain is to be an access domain for an originating side for the UE, and a component configured to transmit the recommendation comprising the probability per UE.

Still further, it is to be noted that the method aspects may also be embodied on the apparatus of the fourth and fifth aspects comprising at least one processor and/or appropriate means for carrying out any one of the method steps.

In a sixth aspect, there is provided a system comprising the IMS core according to the fourth aspect, wherein the IMS core is connected to an Operating Support System/Business Support System, OSS/BSS, system comprising an analytics engine according to the fifth aspect.

In a first refinement of the sixth aspect, the analytics engine may comprise a

Subscriber Mobility Profiler. In addition or alternatively, the IMS node may comprise one of a Proxy Call Session Control Function, P-CSCF, and a Serving Call Session Control Function, S-CSCF, wherein the one of the P-CSCF and the S-CSCF may be configured to - be extended with an access selection logic, - communicate with the analytics engine, and - execute access selection towards the UE by rejecting UE Session Initiation Protocol, SIP, signalling. Alternatively, the IMS node may comprise a Service Centralization and Continuity Application Server, SCC-AS, wherein the SCC- AS may be configured to - extend an existing Terminating Access Domain Selection, T-ADS, function to communicate with the analytics engine, and - consider the information obtained from the analytics engine in the selection decision. In this way, the present disclosure can be implemented using existing components as far as possible.

Brief Description of the Drawings

The embodiments of the technique presented herein are described herein below with reference to the accompanying drawings, in which:

Fig. 1 shows a principle of communications network and components involved in which embodiments of the present disclosure can be performed;

Fig. 2 shows components comprised in an exemplary device embodiment realized in the form of an apparatus (which may reside e.g. in an IMS core and an analytics engine);

Fig. 3A shows a first portion of a method embodiment pertaining to the originating side which also reflects the interaction between the components of the apparatus embodiment;

Fig. 3B shows a second portion of the method embodiment pertaining to the

terminating side which also reflects the interaction between the

components of the apparatus embodiment;

Fig. 4A shows a call duration histogram pertaining to refinement of the method embodiment; and

Fig. 4B shows a diagram plotting call duration vs. probability of leaving an LTE

coverage area pertaining to another refinement of the method embodiment. Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth (such as particular signalling steps) in order to provide a thorough understanding of the technique presented herein. It will be apparent to one skilled in the art that the present technique may be practiced in other embodiments that depart from these specific details. For example, the embodiments will primarily be described in the context of 3^rd generation (3G) or 4^th generation/long term evolution (4G/LTE); however, this does not rule out the use of the present technique in connection with (future) technologies consistent with 3G or 4G/LTE, be it a wirebound communications network or a wireless communications network. On the other hand, as far as legacy communication networks are involved, the present technique is also backward-compatible to a degree described herein below.

Moreover, those skilled in the art will appreciate that the services, functions and steps explained herein may be implemented using software functioning in

conjunction with a programmed microprocessor, or using an Application Specific Integrated Circuit (ASIC), a Digital Signal Processor (DSP), a field programmable gate array (FPGA) or general purpose computer. It will also be appreciated that while the following embodiments are described in the context of methods and devices, the technique presented herein may also be embodied in a computer program product as well as in a system comprising a computer processor and a memory coupled to the processor, wherein the memory is encoded with one or more programs that execute the services, functions and steps disclosed herein.

Without loss of generality, a solution is proposed, in which a trade-off of initiating the call over PS vs. CS is evaluated at each call setup based on information from an analytics engine such that an optimized decision is made considering the cost and the probability of an SRVCC handover. This is because, for those LTE initiated voice calls that are very likely to be handled under SRVCC handover due to the movement of the subscriber out of LTE coverage, it is proposed to start the call in WCDMA/GSM CS network instead of LTE. The proposed solution includes an analytics function that can learn the mobility profile of a subscriber or set of subscribers in a specific cell based on a rich set of collected network data and can give recommendation for the corresponding IMS functions responsible for access domain selection at call setup in which domain the given call should be established. The proposed solution also includes the necessary signalling procedures and IMS node function extensions that are necessary for implementing the proposed solution.

Further, equally without loss of generality, alternatively or simultaneously, the present technique may be summarized under the following items: 1) forced CSFB call initiation based on predictive information about the network status and user behaviour, and 2) signalling sequences of a call setup for the originating and for the terminating side legs.

Fig. 1 shows a principle of communications network 200 and components (inter alia, analytics engine 2005 and IMS core 2007) involved in which embodiments of the present disclosure can be performed. The communications network 200 may comprise the analytics engine 2005 (which may take the form of an OSS/BSS

(Operating Support System/Business Support System)), the IMS core 2007, a packet core 202, a circuit switched core 203, a Radio Access Network (RAN) 2001 and a UE 201. In turn, the IMS core 2007 may comprise a Proxy Call Session Control Function (P-CSCF) 2003, a Serving Call Session Control Function (S-CSCF) 2004 and a Service Centralization and Continuity Application Server (SCC-AS) 2006.

In particular, Fig. 1 shows a simplified view of the IMS and 3GPP network

architecture, showing only the entities relevant from the viewpoint of the present technique. The architecture comprises the IMS core 2007, the EPC (Evolved Packet Core) 202, the Circuit Switched core 203 and the RAN 2001. Without loss of generality, in the proposed solution, the OSS/BSS system and in particular, the Analytics function 2005 is connected to that of the IMS core 2007. The OSS/BSS analytics function 2005 may assist in the call establishment process to determine in which domain the call should be established. The details of the interconnection and signalling sequences are described below.

Fig. 2 shows components comprised in an exemplary device embodiment realized in the form of the analytics engine 2005 and the IMS core 2007. As shown in Fig. 2, the analytics engine 2005 comprises a core functionality (e.g., one or more of a Central Processing Unit (CPU), dedicated circuitry and/or a software module) 20051, an optional memory (and/or database) 20052, a transmitter 20053 and a receiver 20054. Moreover, the analytics engine 2005 comprises an optional maintainer 20055, an optional assigner 20056 and an optional learner 20057. Moreover, the IMS core 2007 comprises a core functionality (e.g., one or more of a Central Processing Unit (CPU), dedicated circuitry and/or a software module) 20071, an optional memory (and/or database) 20072, an optional transmitter 20073 and a receiver 20074. Moreover, the IMS core 2007 comprises an inquirer 20075, a selector 20076, an optional trigger 20077, an optional signaller 20078, an optional

interrogator 20079 and an optional initiator 200710.

In the following paragraphs, assume that x = 5 or 7 (the analytics engine 2005 and the IMS core 2007). As partly indicated by the dashed extensions of the functional blocks of the CPUs 200x1, the maintainer 20055, the assigner 20056 and the learner 20057 (of the analytics engine 2005) as well as the inquirer 20075, the selector 20076, the trigger 20077, the signaller 20078, the interrogator 20079 and the initiator 200710 (of the IMS core 2007) as well as the memory 200x1, the transmitter 200x3 and the receiver 200x4 may at least partially be functionalities running on the CPUs 200x2, or may alternatively be separate functional entities or means controlled by the CPUs 200x1 and supplying the same with information. The transmitter and receiver components 200x3, 200x4 may be realized to comprise suitable interfaces and/or suitable signal generation and evaluation functions.

The CPUs 200x1 may be configured, for example, using software residing in the memories 200x2, to process various data inputs and to control the functions of the memories 200x2, the transmitter 200x3 and the receiver 200x3 (as well as of the maintainer 20055, the assigner 20056 and the learner 20057 (of the analytics engine 2005) as well as the inquirer 20075, the selector 20076, the trigger 20077, the signaller 20078, the interrogator 20079 and the initiator 200710 (of the IMS core 2007)). The memory 200x2 may serve for storing program code for carrying out the methods according to the aspects disclosed herein, when executed by the CPU 200x1.

It is to be noted that the transmitter 200x3 and the receiver 200x4 may be provided as an integral transceiver, as is indicated in Fig. 2. It is further to be noted that the transmitters/receivers 200x3, 200x4 may be implemented as physical

transmitters/receivers for transceiving via an air interface or a wired connection, as routing/forwarding entities/interfaces between network elements, as functionalities for writing/reading information into/from a given memory area or as any suitable combination of the above. At least one of the maintainer 20055, the assigner 20056 and the learner 20057 (of the analytics engine 2005) as well as the inquirer 20075, the selector 20076, the trigger 20077, the signaller 20078, the interrogator 20079 and the initiator 200710 (of the IMS core 2007), or the respective functionalities, may also be implemented as a chipset, module or subassembly.

Fig. 3A shows a first portion of a method embodiment pertaining to the originating side which also reflects the interaction between the components of the apparatus embodiment, whereas Fig. 3B shows a second portion of the method embodiment pertaining to the terminating side which also reflects the interaction between the components of the apparatus embodiment. In the signalling diagrams of Figs. 3A and 3B, time aspects between signalling are reflected in the vertical arrangement of the signalling sequence as well as in the sequence numbers. It is to be noted that the time aspects indicated in Figs. 3A and 3B do not necessarily restrict any one of the method steps shown to the step sequence outlined in Figs. 3A and 3B. This applies in particular to method steps that are functionally disjunctive with each other.

As a preparatory measure in step SO-l, the maintainer 20055 of the analytics engine 2005 performs maintaining a mobility profile model per UE based on activity data of the UE enabling prediction of the probability that the SRVCC handover will occur. Still further, in an optional preparatory step S0-2, the assigner 20056 of the analytics engine 2005 performs assigning the probability to a VoLTE call setup based on a given set of input parameters. Lastly, as a further optional preparatory step, the learner 20057 of the analytics engine 2005 performs learning the mobility profile model on a per UE, per cell basis.

The advantages obtainable and possible use case pertaining to the optional preparatory steps SO-l to S0-3 will be described later in this document making reference to Figs. 4A and 4B.

Concerning the analytics engine 2005, the following applies:

- there are analytics systems that can collect, mediate and correlate low level activity logs available in different parts of the telecommunication systems and nodes and construct valuable information on subscriber activity. This latter information can generally be called user sessions, which contain compact information of subscriber activity for a given relatively short period. This highly detailed data set can be used for various use-cases in customer care, network operation and optimization. - the analytics solutions may usually be built upon a scalable high performance architecture that is able to response to the queries quickly in spite of the large amount of data to handle.

- In the present technique, a Subscriber Mobility Profiler is in the OSS/BSS analytics system to be able to track and store the subscriber's mobility patterns and then utilize the historical information in estimating the probability of leaving the LTE coverage (resulting in SRVCC handovers if it occurs during a VoLTE call) within a certain amount of time.

- The analytics engine 2005 has stored, per UE, a probability that an SRVCC handover will occur after initiation of a UE voice call in Voice over Long Term

Evolution (VoLTE).

Returning to Figs. 3A and 3B, the signalling sequence for a call setup involved in the present technique will be described. The depiction is split according to the originating side and terminating side parts (which may be part of a so-called end-to-end procedure to be described later).

Optional step Sl-0: the originating side UE-1 201-1 may start call setup by sending e.g. a SIPJnvite message towards the P-CSCF 2003. This message may pass transparently via the RAN 2001 and the remaining core network nodes.

Step Sl-1: the inquirer 20075 of the IMS core 2007 performs inquiring, from the analytics engine 2005, a recommendation on whether the Packet Switched, PS, domain or the Circuit Switched, CS, domain is to be the access domain for an originating side for the UE 201-1.

In other words, e.g. the P-CSCF 2003 receiving the SIP message interprets the message and may interrogate the Analytics function 2005 (located e.g., in OSS/BSS domain) for recommendation where to setup the call source leg, i.e., in the PS or in the CS domain.

Step Sl-2: the receiver 20054 of the analytics engine 2005 performs receiving, from the IMS core 2007, a request for a recommendation on whether the PS domain or the CS domain is to be an access domain for an originating side the UE.

Still further, the transmitter 20053 of the analytics engine 2005 performs transmitting the recommendation comprising the probability per UE. In turn, the receiver 20074 of the IMS core 2007 performs receiving the recommendation comprising the probability per UE that the SRVCC handover will occur.

Step Sl-3: The selector 20076 of the IMS core 2007 performs selecting, based on the probability, one of the PS domain and CS domain as the access domain for the originating side for the UE.

In other words, based on the received recommendation, e.g. the P-CSCF 2003 can make the final decision for the selection. Alternatively, instead of the P-CSCF 2003, also the S-CSCF 2004 function may decide of the access selection in the same way the P-CSCF 2003 does.

Case 1: CS domain is selected for the originating side:

Optional step Sl-4a: if the selected access domain for the originating side is the CS domain while the UE 201-1 is currently in the PS domain, the transmitter 20073 of the IMS core 2007 performs transmitting a negative reply to the UE.

In other words, in case the selected access is CS (while the UE 201-1 is in PS domain currently), the P-CSCF 2003 may send a negative reply to the UE, e.g., a SIP_Bye or a SIP_Cancel message, indicating - in the cause code - the reason of rejection. It is also possible to use either any of the existing cause codes, such as

"service_not_supported", or to define a new cause code for this purpose.

Optional step Sl-5a: the trigger 20077 of the IMS core 2007 performs triggering the UE 201-1 to fall back to the CS domain using Circuit Switched Fallback, CSFB, wherein the triggering is directed to the Originating Access Domain Selection (O- ADS) function in the UE.

In other words, in response to the rejection (e.g. SIP_Bye or SIP_Cancel message), the O-ADS function in the UE is triggered and subsequently, the O-ADS function decides to have the UE fall back to CS domain. Preferably, the rules of access selection in the UE are controlled by policies configured by the operator in the terminal.

Optional step Sl-6a: In this next step, the UE 201-1 executes a CSFB procedure signalling e.g. to the MME 2002 and initiates the call via the CS domain. Case 2: PS domain is selected for the originating side:

Optional step Sl-4b: In case the access selection at step Sl-3 decides for the PS domain, the SIP signalling may be continued e.g. from the P-CSCF 2003 towards the S-CSCF 2004.

Optional step Sl-5b: if the selected access domain for the originating side is the PS domain and the IMS core comprises the S-CSCF 2004 and the SCC-AS 2006, the signaller 20078 of the IMS core 2007 performs signalling, from the S-CSCF 2004 to the SCC-AS 2006, to attain access domain selection for a terminating side.

In other words, the S-CSCF 2004 may signal, to the SCC-AS 2006, for access domain selection. Without loss of generality, the SCC-AS 2006 may be a legacy function present in IMS core 2007 and may host the Terminating Access Domain Selection T- ADS logical function.

Optional step Sl-6b: if the IMS core 2007 is connected to the OSS/BSS system 2005, which in turn comprises the analytics engine 2005, the interrogator 20079 of the IMS core 2007 performs interrogating the analytics engine 2005 for the recommendation.

That is, the SCC-AS 2006 interrogates the analytics function/engine 2005 for the recommendation of access selection.

Optional step Sl-7b: the selection step Sl-3 may be performed by the SCC-AS 2006.

In other words, based on feedback received from the analytics function 2005 and using own information and algorithms, the SCC-AS 2006 may make the final decision for terminating side access domain selection.

Case 3: CS domain is selected for the terminating side, while the UE 201-2 is on the PS domain:

Optional steps Sl-4c and Sl-5c: if the selected access domain is the CS domain for a terminating side while a terminating UE 201-2 is currently in the PS domain, wherein the IMS core 2007 comprises the S-CSCF 2004 and the SCC-AS 2006, the initiator 200710 performs initiating, by the SCC-AS 2006 and via the MME 2002, an CSFB procedure towards the terminating UE. In other words, in the optional step Sl-4c, in case the selection (step Sl-3) decides for the CS domain (while the UE is currently on PS domain), the SCC-AS 2006 may initiate a CSFB procedure toward UE-2 (UE 201-2) via the MME 2002. In response to this initiation, in the optional step Sl-5c, the UE 201-2 may execute the necessary signalling and may switch to the CS domain in order to receive the incoming call.

As mentioned above, advantages obtainable and possible use case pertaining to the optional preparatory steps SO-1 to SO-3 are to be described in the following (making reference to Figs. 4A and 4B, where appropriate).

In particular, in the following, a subscriber mobility profiler module that runs in the OSS/BSS analytics system 2005 and provides information on the probability of SRVCC handover for each individual user is described. In a particular use case of SRVCC handover prediction, there are some use case specific considerations, for which a few possible solutions are exemplified.

The OSS/BSS analytics system 2005 may comprise a Subscriber Mobility Profiler Component. This component has two roles:

1. Subscriber Mobility Profile Learning, see optional step SO-1: Learn and

continuously maintain a mobility profile model for each individual user based on detailed activity data. That data that will enable prediction of the probability that an SRVCC handover happens during a voice call given a set of input parameters for a future VoLTE call setup request (e.g. position, time, called party, recent activity, UE type, etc.).

2. Subscriber Mobility Profile Utilization, see optional step SO-2: Given a set of input parameters for an actual VoLTE call setup request (e.g. position, time, called party, recent activity, UE type, etc.), assign a probability to this VoLTE call setup request that indicates the probability of a necessary SRVCC handover during this call if it is initiated in LTE.

Concerning the Subscriber Mobility Profile Learning, user activities may be logged and processed in the OSS/BSS analytics system 2005. The Subscriber Mobility Profiler may read the mobility information from the logs (sessions with and without handovers) and use it to train a model where a per-user per-cell mobility profile is learned (cf. optional step SO-3). The learning technique can adopt any standard statistical method (e.g. moving average, standard deviation, etc.), or any state-of- the-art machine learning method. Optionally, the mobility profile model may comprise the following entries per UE: time of day, user identifier, ID, and a mobility descriptor.

In other words, a possible realization of the mobility profile is a table with the following parameters:

[ Time of Day, User Identifier, Cell identifier, mobility_descriptors where the mobility_descriptors \s a collection of parameters describing the user's typical mobility pattern in the particular cell in a particular timeframe. Note that the mobility profile is trained not only by earlier voice activities, but may be trained also by other data activities as well.

Optionally, the mobility descriptor may comprise the following entries: a direction of movement inwards or outwards an LTE coverage area, an average estimated speed of movement, a variance of the speed, and a number of samples yielding the direction, the speed and the variance.

That is, an example table of the mobility profile filled with mobility descriptors is shown in the following table.

Speed Number of

Time of Day User ID Cell ID Direction Speed Variance Samples

Morning userl celll In 30 10 25

Afternoon userl celll Out 50 15 20

Evening userl cell2 - 0 0 85

Since the profiler is maintained for SRVCC optimization, only LTE cells are logged in the mobility profiler. The direction indicates if the user usually moves inwards or outwards LTE coverage area. The speed ^'is the average estimated speed of movement. The speed variance and the number of samples indicate the reliability of statistics, i.e., whether the variance is too high or the number of samples is too low, so that the model may not be reliable enough to make call admission decisions.

Usually, due to the regular daily routines, the mobility patterns of individual users are simple and easily predictable. In the particular example shown in table above, userl typically crosses celll in the morning while moving inwards the LTE coverage area and crosses celll in the afternoon moving outwards the LTE coverage area. The same user (user!) stays in another cell (cel/2) in the evening typically steadily without movement.

Fig. 4A shows a call duration histogram pertaining to refinement of the method embodiment. Optionally, the mobility profile model additionally may comprise at least one of the following entries: UE terminal type, applications used on the UE, and statistics on the length of the UE voice call.

In other words, additionally to the mobility profile records, other information sources can be collected and maintained such as terminal type, used applications, or statistics for the length of the voice call. An example for the statistics of the voice call length is shown in Fig. 4A, where the histogram of the voice call length for one user is plotted.

Moreover, multiple similar histograms can be maintained for each user where one histogram relates to one partner (called party in case of outgoing calls or calling party in case of incoming calls). The decomposition of the histogram for the different calling partners represents the fact that the calling time is usually heavily depends on the caller and the callee.

Subscriber Mobility Profile Utilization - SRVCC Handover Prediction

Once the Subscriber Mobility Profile has been created, it can be utilized to obtain the probability for a given subscriber at given time in a given cell that the user (the caller and/or the called party) leaves the LTE coverage area. More specifically, when a VoLTE call is initiated, it is possible to determine the probability of a subsequent SRVCC handover execution.

Option I: Optionally, the probability may be based on a second probability of the UE leaving an LTE coverage area.

In other words, the basic algorithm for determining the probability of leaving the LTE coverage area is to calculate the probability for each user for each cell for each time of day for a fixed timeframe (T).

Option II: Optionally, the second probability may be calculated for each UE, each cell and each time of day for a fixed timeframe. In this regard, Fig. 4B shows a diagram plotting call duration vs. probability of leaving an LTE coverage area pertaining to another refinement of the method embodiment.

In other words, a more advanced algorithm to determine the probability of leaving the LTE coverage area is to take into account the call duration histogram shown in Fig. 4B. In this case, instead of using a fixed timeframe, the probabilities for all timeframes in the histogram are calculated and the overall probability is obtained as the sum of the probabilities for the different timeframes, weighted by the histogram:

An example for the probabilities of leaving the LTE coverage area for multiple timeframes is shown in Fig. 4B.

Option III: Optionally, the second probability may be calculated as a weighted sum of the probabilities per timeframe multiplied by a call duration histogram entry per the timeframe.

As another option, the second probability may be calculated, per UE called, based on different histograms pertaining to the respective calling UEs, so that the sum of the probabilities for the different timeframes is weighted by the histogram related to the particular calling UE.

In other words, in an even more sophisticated algorithm, the calling party is taken into consideration. In the learning phase, different histograms are generated and maintained for the different calling parties. The overall probability of leaving the LTE coverage area is calculated as the sum of the probabilities for the different timeframes, weighted by the histogram related to the particular calling party.

Additionally, not only historical information such as the Subscriber Mobility Profile Learning can be used but instant information as well. If the current subscriber mobility profile is available in the following form (e.g. from active data sessions in the last couple of minutes)

[ Time of Day, User Identifier, Cell identifier, mobili^descriptors], then this information can be added to the historical information. The overall probability of leaving the LTE coverage area is then a weighted sum of the

probability obtained by the profile learning and the probability obtained by the instant mobility information:

P = w_iP_i + \v_h P_{h i} where w indicates weight (w₄ + w_h = l)_f Vindicates probability, index / indicates instant and index h indicates historical information.

Prediction algorithm: As a key output of the Mobility Profiler Component, the probability o SRVCC handover after initiating the call in VoLTE for the particular subscriber among the above particular circumstances will be given and

communicated towards the IMS core 2007 system.

The prediction algorithm may use the measured characteristics of the actual planned call (position, time, called party, UE device, etc.) and match it to the past (see options above). It may perform a special similarity search (e.g., K-nearest neighbors, or via a learnt model) among the particular IMSI's historical subscriber mobility profile records (those that were happened in the same cell or near that,

approximately at the same time (of day), and in general among similar circumstances as in the current situation).

The final prediction result will depend on the actual data found in the set of historical records that are similar to the current situation. The predicted probability will be proportional to the relative number of occurrences the particular IMSI left the LTE coverage in those similar situations found in the past.

In the following, some basic use case examples are given, illustrating, without loss of generality, the operation of the system and the benefits.

Example 1: going into work, calling a colleague

An individual user is just on the edge of an LTE network coverage and would start a VoLTE call. The present technique allows the call on VoLTE because the probability for SRVCC handover need is marginal in this situation. This is because at this time of day and at this day of week, from this cell, knowing his last visited cells, typically the user moves inwards the LTE network, to his workplace where his colleague is staying and the place is under LTE coverage.

Example 2: going home from work, calling wife

This is the opposite of the above example 1, i.e., the cell where the call is initiated is the same as in the above example, but the time of day is different, and the recently visited cell list is also different. All those indicators give rise to the assumption that the user is travelling home, which home is out of LTE coverage, and now the called party is his wife, and the call duration with the wife is typically around 15 minutes, which is presumably long enough for leaving the LTE coverage. Accordingly, that call will be initiated in WCDMA.

Example 3: user stavs at LTE edge, and calls for pizza

A subscriber (user) is currently not showing signs of movement (e.g. no recent cell changes are detected), but the call is initiated from a cell which is on the edge of the LTE coverage. The mobility profiler component assigns a low probability for moving out of LTE coverage during the call and thus the call will be VoLTE call because the called party is a pizza delivery company under LTE coverage, the call will be around 1 minute length, and the time of day is noon when the subscriber is typically not moving for long based on the built profile.

The present disclosure provides one or more of the following advantages:

• Minimization of the performance risks and signalling costs of SRVCC handovers in LTE.

• No requirement for changes in the legacy signalling flows and thereby possibly useable with legacy terminals and protocols. That is, only minimal changes and extensions to network node functions is introduced and no modification is made in the legacy IMS signalling protocols. The following IMS network nodes need extensions.

• From a broader perspective, in general, the feature in LTE / VoLTE call

admission and setup system will enable operators to rollout LTE even more aggressively.

• No need to modify any of the signalling interfaces of the SCC-AF toward other IMS nodes.

• No need for changes on the UE side behaviour, the existing O-ADS

functionality in the terminal may be reused. • The interface toward the analytics node/engine 2005 can be any type of Request-Response type of interface (or alternatively any Subscribe-Publish type of interface). In the simplest case, the interface could be a database query where the interrogating node could fetch the up to date information and access recommendation for the particular UE from a database. The database is continuously fed with information by the Analytics engine. In other cases, the Request-Response communication could be done via any state of the art inter-process messaging system via self-defined message formats.

It is believed that the advantages of the technique presented herein will be fully understood from the foregoing description, and it will be apparent that various changes may be made in the form, constructions and arrangement of the exemplary aspects thereof without departing from the scope of the invention or without sacrificing all of its advantageous effects. Because the technique presented herein can be varied in many ways, it will be recognized that the invention should be limited only by the scope of the claims that follow.

Claims

1. A method for optimizing, based on information from an analytics engine (2005), a decision concerning a Single Radio Voice Call Continuity, SRVCC, handover of a User Equipment, UE, (201-1, 201-2), the method being performed in an Internet Protocol Multimedia Subsystem, IMS, core (2007), and comprising the steps of:

inquiring (Sl-1), from the analytics engine, a recommendation on whether the Packet Switched, PS, domain or the Circuit Switched, CS, domain is to be the access domain for an originating side for the UE;

receiving (Sl-2) the recommendation comprising a probability per UE that an SRVCC handover will occur after initiation of a voice call in Voice over Long Term Evolution, VoLTE; and

selecting (Sl-3), based on the probability, one of the PS domain and CS domain as the access domain for the originating side for the UE.

2. The method according to claim 1, wherein, if the selected access domain for the originating side is the CS domain while the UE is currently in the PS domain, the method further comprises:

transmitting (Sl-4a) a negative reply to the UE.

3. The method according to claim 2, wherein the negative reply is one of a Session Initiation Protocol BYE, SIP_BYE, message and a SIP_Cancel message.

4. The method according to claim 2 or 3, further comprising:

triggering (Sl-5a) the UE to fall back to the CS domain using Circuit Switched Fallback, CSFB, wherein the triggering is directed to the Originating Access Domain Selection, O-ADS, function in the UE.

5. The method according to claim 1, wherein, if the selected access domain for the originating side is the PS domain and the IMS core comprises a Serving Call Session Control Function, S-CSCF, (2004) and a Service Centralization and Continuity Application Server, SCC-AS, (2006), the method further comprises:

signalling (Sl-5b), from the S-CSCF to the SCC-AS, to attain access domain selection for a terminating side.

6. The method according to claim 5, wherein the IMS core is connected to an Operating Support System/Business Support System, OSS/BSS, system (2005) comprising the analytics engine, and wherein the method further comprises:

interrogating (Sl-6b) the analytics engine for the recommendation.

7. The method according to claim 6, wherein the selection step is performed by the SCC-AS (Sl-7b).

8. The method according to claim 1, wherein, if the selected access domain is the CS domain for a terminating side while a terminating UE (201-2) is currently in the PS domain, wherein the IMS core comprises a Serving Call Session Control Function, S-CSCF, (2004) and a Service Centralization and Continuity Application Server, SCC-AS, (2006), and the method further comprises:

initiating (Sl-4c, Sl-5c), by the SCC-AS and via a Multimedia Management Entity, MME, (2002), a Circuit-switched Fallback, CSFB, procedure towards the terminating UE.

9. A method for optimizing, based on information from an analytics engine (2005), a decision concerning a Single Radio Voice Call Continuity, SRVCC, handover of a User Equipment, UE, (201-1, 201-2), the analytics engine having stored, per UE, a probability that an SRVCC handover will occur after initiation of a UE voice call in Voice over Long Term Evolution, VoLTE, the method being performed in the analytics engine and comprising the steps of:

receiving (Sl-2), from an Internet Protocol Multimedia Subsystem, IMS, core (2007), a request for a recommendation on whether the Packet Switched, PS, domain or the Circuit Switched, CS, domain is to be an access domain for an originating side for the UE; and

transmitting (Sl-2) the recommendation comprising the probability per UE.

10. The method according to claim 9, further comprising:

maintaining (SO-l) a mobility profile model per UE based on activity data of the UE enabling prediction of the probability that the SRVCC handover will occur.

11. The method according to claim 10, further comprising:

assigning (S0-2) the probability to a VoLTE call setup based on a given set of input parameters.

12. The method according to claim 10 or 11, further comprising:

learning (SO-3) the mobility profile model on a per UE, per cell basis.

13. The method according to any one of claims 10 to 12, wherein the mobility profile model comprises the following entries per UE:

time of day;

user identifier, ID; and

a mobility descriptor.

14. The method according to claim 13, wherein the mobility descriptor comprises the following entries:

a direction of movement inwards or outwards an LTE coverage area;

an average estimated speed of movement;

a variance of the speed; and

a number of samples yielding the direction, the speed and the variance.

15. The method according to claim 13 or 14, wherein the mobility profile model additionally comprises at least one of the following entries:

UE terminal type;

applications used on the UE; and

statistics on the length of the UE voice call.

16. The method according to any one of claims 9 to 15, wherein the probability is based on a second probability of the UE leaving an LTE coverage area.

17. The method according to claim 16, wherein the second probability is calculated for each UE, each cell and each time of day for a fixed timeframe.

18. The method according to claim 16, wherein the second probability is calculated as a weighted sum of the probabilities per timeframe multiplied by a call duration histogram entry per the timeframe.

19. The method according to claim 16, wherein the second probability is calculated, per UE called, based on different histograms pertaining to the respective calling UEs, so that the sum of the probabilities for the different timeframes is weighted by the histogram related to the particular calling UE.

20. A computer program product comprising program code portions for performing the method of any one of claims 1 to 19 when the computer program product is executed on one or more computing devices.

21. The computer program product of claim 20, stored on a computer readable recording medium.

22. An Internet Protocol Multimedia Subsystem, IMS, core (2007) for optimizing, based on information from an analytics engine (2005), a decision concerning a Single Radio Voice Call Continuity, SRVCC, handover of a User Equipment, UE, (201-1, 201- 2), the IMS core comprising:

a component (20075) configured to inquire, from the analytics engine, a recommendation on whether the Packet Switched, PS, domain or the Circuit

Switched, CS, domain is to be an access domain for an originating side for the UE; a component (20074) configured to receive the recommendation comprising a probability per UE that an SRVCC handover will occur after initiation of a voice call in Voice over Long Term Evolution, VoLTE; and

a component (20076) configured to select, based on the probability, one of the PS domain and CS domain as the access domain for the originating side for the UE.

23. An analytics engine (2005) for optimizing, based on information from the analytics engine, a decision concerning a Single Radio Voice Call Continuity, SRVCC, handover of a User Equipment, UE, (201-1, 201-2), the analytics engine having stored, per UE, a probability that an SRVCC handover will occur after initiation of a UE voice call in Voice over Long Term Evolution, VoLTE, the analytics engine comprising:

a component (20054) configured to receive, from an Internet Protocol Multimedia Subsystem, IMS, core (2007), a request for a recommendation on whether the Packet Switched, PS, domain or the Circuit Switched, CS, domain is to be an access domain for an originating side for the UE; and

a component (20053) configured to transmit the recommendation comprising the probability per UE.

24. A system (200) comprising:

the IMS core according to claim 22, wherein the IMS core is connected to an Operating Support System/ Business Support System, OSS/BSS, system (2005) comprising the analytics engine according to claim 23.

25. The system according to claim 24, wherein the analytics engine comprises a Subscriber Mobility Profiler.

26. The system according to claim 24 or 25, wherein the IMS node comprises one of a Proxy Call Session Control Function, P-CSCF, (2003) and a Serving Call Session Control Function, S-CSCF, (2007), wherein the one of the P-CSCF and the S-CSCF is configured to:

- be extended with an access selection logic;

- communicate with the analytics engine; and

- execute access selection towards the UE by rejecting UE Session Initiation Protocol, SIP, signalling.

27. The system according to claim 24 or 25, wherein the IMS node comprises a Service Centralization and Continuity Application Server, SCC-AS, (2006), wherein the SCC-AS is configured to:

- extend an existing Terminating Access Domain Selection, T-ADS, function to communicate with the analytics engine; and

- consider the information obtained from the analytics engine in the selection decision.