WO2015050547A1

WO2015050547A1 - Volte mobility scenarios with ims and non-ims voice bearers

Info

Publication number: WO2015050547A1
Application number: PCT/US2013/063239
Authority: WO
Inventors: Srinivasan Selvaganapathy; Curt Wong; Parthasarathi RAVINDRAN; Dario Serafino TONESI
Original assignee: Nokia Siemens Networks Oy
Current assignee: Nokia Solutions and Networks Oy
Priority date: 2013-10-03
Filing date: 2013-10-03
Publication date: 2015-04-09
Anticipated expiration: 2016-04-03

Abstract

The present invention provides methods, apparatuses and a computer program product relating to enhancements to Voice over LTE (Long Term Evolution) mobility scenarios to handle co-existence of IMS IP (Multimedia Subsystem) and non-IMS voice bearers with QoS (Quality of Service). The present invention includes composing, at a first network element, a message including an indication whether or not a voice bearer supports call continuity, and causing transmission of the message to a second network element.

Description

DESCRIPTION

Enhancements to VoLTE mobility scenarios to handle co-existence of IMS and non-IMS voice bearers with QoS

Field of the invention

The present invention relates to enhancements to Voice over LTE (Long Term Evolution) mobility scenarios to handle co-existence of IMS (Internet protocol Multimedia Subsystem) and non-IMS voice bearers with QoS (Quality of Service).

Background of the invention

The present invention relates to LTE networks which support voice services along with voice-call continuity during mobility scenarios with 3G networks.

In existing LTE systems, voice support is enabled by interworking of the LTE network with IMS network elements. The signaling related to voice-call setup is handled by the IMS network elements along with IMS client at UE (User Equipment) side. During UE mobility to 3G UTRAN (Universal Terrestrial Radio Access Network) which does not support IMS voice, the IMS voice bearer should be relocated via 3G MSC (Mobile Switching Center) as CS RAB (Circuit Switched Radio Access Bearer) and also the signaling towards UE should go via 3G MSC from IMS anchor point. This functionality is known as SRVCC (Single Radio Voice Call Continuity).

Fig . 1 shows an example of the VoLTE (Voice over Long Term Evolution) architecture along with SRVCC functionality support towards UTRAN 15.

To enable SRVCC, the VoLTE Architecture is modified as follows.

• IMS subsystem 11 should be connected to MSC 12 for routing the voice related signaling via 3G MSC.

• MME 13 should be connected to MSC 12 for requesting for conversion of IMS PS (Packet Switched) bearer to CS Voice bearer. Further elements of the VoLTE architecture shown in Fig . 1 are the SGW/PGW (Serving Gateway / Packet data network Gateway) 14, the UTRAN (Universal Terrestrial Radio Access Network) 15, the eNB (evolved NodeB) 16, the HSS (Home Subscriber Server) 17 and the PCRF (Policy and Charging Rule Function) 18. The SGW/PGW 14 implements a PCEF (Policy and Charging Enforcement Function) and is connected to the PCRF via a Gx-interface, as defined in document [1] .

As for E-UTRAN (Evolved Universal Terrestrial Radio Access Network) impact related to VoLTE and SRVCC, the key aspects are shown in the following .

• The voice EPS (Evolved Packet System) bearer is identified based on QCI (QoS (Quality of Service) Class Indicator) value 1 among all the bearers.

• E-UTRAN provides special features such as semi persistence scheduling, TTI-bundling and higher priority for scheduling to the EPS bearers with QCI= 1.

• During mobility towards UTRAN for UE with SRVCC capability, the SRVCC handover is triggered only if the UE has at least one QCI= 1 bearer.

At MME, the SRVCC handover is triggered if the eNB provides SRVCC-HO- indication in the Handover Required message and there exists an ERAB (EPS Radio Access Bearer) with QCI= 1.

In the following, a scenario for support of IMS and non-IMS based voice bearers (two ERABs with QCI= 1) is described .

In addition to IMS based voice services, other browser based applications (for example, webRTC (Web Real-Time-Communication Services)) also provide voice services. Voice calls can also be setup via these applications. When such applications are used in LTE UE, by default, this traffic is handled without any QoS treatment.

In order to allow an operator to provide QoS as similar to IMS voice for these applications, and also to reuse the IMS infrastructure for these applications, the LTE network will have additional connectivity for such application servers. These application servers interwork with IMS component to create the voice bearers with QoS. Various architecture options for interworking of IMS with webRTC applications are captured in document [3] . Fig . 2 shows an example of high level architecture for interworking of IMS and webRTC services.

The new architectures have two main aspects

• The application servers interwork with IMS components in such a way that the webRTC sessions are handled as same as IMS sessions in IMS components.

• This application interworking function will also activate the QCI= 1 bearer for the voice traffic of these applications via PCRF. This can be achieved by direct interface to PCRF or via IMS.

In the above architecture the LTE system supports IMS based voice services along with other voice applications such as webRTC. In this architecture, if the decision to trigger SRVCC is done just based on QCI value of ERAB, it will result in SRVCC handover trigger for the voice bearer of non-IMS based applications (e.g . webRTC) and the handover will fail eventually.

In the architecture shown in Fig . 2, AF (Application Function) 19 represents the application-interworking-node which interacts with IMS and PCRF to enable voice-session setup via existing IMS and PCRF components. In case of webRTC application, this node represents the webRTC interworking function. The remaining elements shown in Fig . 2 correspond to those shown in Fig . 1 and the same elements in Fig . 2 are denoted with the same reference signs as used in Fig . 1.

It is noted that webRTC is one such non-IMS based voice application which can be triggered from any browser. In such services, the call setup signaling is happening via application layers (http) instead of SIP (Session Initiation Protocol). Many of the operators who are having VoLTE deployments request for support of this application with QoS so that it will allow them to provide new avenue of application and revenue. Standardization discussions in IETF (Internet Engineering Task Force) and 3GPP (3 Generation Partnership Project) are ongoing to allow enabling the QoS for the voice bearers of these applications via IMS architecture and high level candidate architectures are captured in document [3] .

In the following, there are explained the high level steps involved in SRVCC handover for UE capable of SRVCC.

UE Attachment:

• As part of Attach /Tracking area update UE informs its capability of SRVCC to MME (Mobility Management Entity).

• MME checks with HSS for subscription details for IMS services as well as for SRVCC capability. HSS also provides STR-SN (Session-Transfer- Sequence-Number) for this UE to MME. This number should be used later during SRVCC mobility between MME and MSC as well as between MSC and IMS.

IMS Session Setup :

• Whenever UE makes Service-request, MME informs to eNB the SRVCC allowed indication to the UE. This parameter is set based on the stored information related to UE capability and presence of STR-SN for this UE.

Mobility scenario :

• Whenever UE moves toward UTRAN cells, eNB decides on SRVCC Handover based on the below condition

o Capability of target UTRAN node supporting SRVCC,

o Presence of QCI= 1 bearer (this indicates presence of voice bearer). If the target UTRAN is not capable of VoIP and there is QCI= 1 bearer active, eNB sets the SRVCC-HO-Indication in the Handover Required message.

• When MME receives the Handover Required message with SRVCC-HO- indication, MME splits the bearers as follows

o Bearer with QCI= 1 is relocated via MSC via conversion of PS (Packet Switched) to CS (Circuit Switched). o Remaining bearers are relocated via SGSN as normal PS handover.

• MME requires MSC for PS-CS conversion along with STR-SN number.

• MSC prepares the target UTRAN for CS RAB relocation.

• On successful preparation, based on STR-SN number, MSC interacts with IMS components to change the media and signaling path towards MSC.

• After preparation and IMS switching MSC informs the preparation success to MME.

• MME on getting response from SGSN and MSC triggers the Inter-RAT (Radio Access Technology) handover to UE.

• UE successfully transferred to UTRAN.

In the above sequence the decision of SRVCC handover at eNB and PS-CS conversion at MME is only based on QCI= 1 bearer.

Above behavior will result in impacts for the following major use-cases with both IMS and webRTC.

Use-case 1 : UE subscribed for VoLTE and SRVCC makes voice call via webRTC application.

When the non-IMS voice applications also creates bearer with QCI= 1 for UE which is capable of SRVCC and subscribed for the same, the above steps will be followed for this bearer also. But this will result in failure of the PS-CS conversion at MSC during its interaction with IMS for switching, because this bearer is not terminated in IMS.

Impact: The complete handover will fail because the target RNC will not proceed with relocation in case if the relocation preparation is not successful in both the domains.

Use-case 2 : UE has active IMS voice session and webRTC application also attempts for another voice session. In this use-case, there will be two bearers with QCI= 1 in eNB. During mobility UE will trigger SRVCC handover to MME. But MME is not aware of which QCI= 1 bearer should be transferred via MSC.

So there may occur a problem that there are chances that both IMS and non-IMS voice sessions are dropped if the wrong bearer is attempted for PS-CS conversion.

References:

[1] TS 29.212 : Gx Interface, Rell2

[2] TS 23.216: SRVCC -Stage 2 Description, Rell l

[3] TR 23.701 : Web Real Time Communication (WebRTC) Access to IMS, Rel l2 Summary of the Invention

It is therefore an object of the present invention to overcome the above mentioned problems and to provide methods, apparatuses and a program for enhancements to Voice over LTE mobility scenarios to handle co-existence of IMS and non-IMS voice bearers with QoS.

According to an aspect of the present invention there is provided a method comprising :

composing, at a first network element, a message including an indication whether or not a voice bearer supports call continuity, and

causing transmission of the message to a second network element.

According to another aspect of the present invention there is provided a method comprising :

determining, at a base station, whether there exists a radio access bearer having a predetermined quality of service and supporting call continuity, and

if it is determined that there exists a radio access bearer having a predetermined quality of service and supporting call continuity,

composing a handover required message including an indication that the radio access bearer supports call continuity. According to another aspect of the present invention there is provided a method comprising :

determining, at a base station, whether there exists a first radio access bearer having a predetermined quality of service and a second radio access bearer related to internet protocol multimedia subsystem, IMS, signaling, and if it is determined that there exists the first radio access bearer but not the second radio access bearer,

composing a handover required message including an indication for packet switched handover.

causing reception, at a network element, of a handover required message including an indication whether or not a radio access bearer supports call continuity,

determining, at the network element, whether or not the radio access bearer supports call continuity based on the received indication,

if it is determined that the radio access bearer supports call continuity, performing conversion from packet switched to circuit switched handover for the radio access bearer.

According to another aspect of the present invention there is provided an apparatus for use in a first network element, comprising :

at least one processor,

at least one interface to at least one other network element, and

at least one memory for storing instructions to be executed by the processor, wherein

the at least one memory and the instructions are configured to, with the at least one processor, cause the apparatus at least to perform :

causing transmission of the message to a second network element. According to another aspect of the present invention there is provided an apparatus, comprising :

at least one processor,

at least one interface to at least one other network element, and

determining whether there exists a radio access bearer having a predetermined quality of service and supporting call continuity, and

composing a handover required message including an indication that the radio access bearer supports call continuity.

According to another aspect of the present invention there is provided an apparatus, comprising :

at least one processor,

at least one interface to at least one other network element, and

determining whether there exists a first radio access bearer having a predetermined quality of service and a second radio access bearer related to internet protocol multimedia subsystem, IMS, signaling, and

if it is determined that there exists the first radio access bearer but not the second radio access bearer,

at least one processor, at least one interface to at least one other network element, and at least one memory for storing instructions to be executed by the processor, wherein

causing reception of a handover required message including an indication whether or not a radio access bearer supports call continuity,

determining whether or not the radio access bearer supports call continuity based on the received indication,

means for composing, at a first network element, a message including an indication whether or not a voice bearer supports call continuity, and

means for causing transmission of the message to a second network element.

means for determining whether there exists a radio access bearer having a predetermined quality of service and supporting call continuity, and

means for composing a handover required message including an indication that the radio access bearer supports call continuity.

means for determining whether there exists a first radio access bearer having a predetermined quality of service and a second radio access bearer related to internet protocol multimedia subsystem, IMS, signaling, and if it is determined that there exists the first radio access bearer but not the second radio access bearer,

means for composing a handover required message including an indication for packet switched handover.

means for causing reception of a handover required message including an indication whether or not a radio access bearer supports call continuity,

means for determining whether or not the radio access bearer supports call continuity based on the received indication,

if it is determined that the radio access bearer supports call continuity, means for performing conversion from packet switched to circuit switched handover for the radio access bearer.

According to another aspect of the present invention there is provided a computer program product comprising code means adapted to produce steps of any of the methods as described above when loaded into the memory of a computer.

According to a still further aspect of the invention there is provided a computer program product as defined above, wherein the computer program product comprises a computer-readable medium on which the software code portions are stored .

According to a still further aspect of the invention there is provided a computer program product as defined above, wherein the program is directly loadable into an internal memory of the processing device.

Brief Description of the Drawings

These and other objects, features, details and advantages will become more fully apparent from the following detailed description of aspects/embodiments of the present invention which is to be taken in conjunction with the appended drawings, in which :

Fig . 1 is a diagram illustrating an example of a VoLTE architecture;

Fig . 2 is a diagram illustrating an example for high level architecture for interworking of IMS and webRTC services;

Fig . 3 is a signaling diagram illustrating a message sequence for creation of dynamic PCC (Policy Control and Charging) rule followed by creation of dedicated ERAB for voice bearer according to certain aspects of the present invention;

Fig . 4 is a signaling diagram illustrating a message sequence of a mobility procedure according to certain aspects of the present invention;

Fig . 5 is a flowchart illustrating an example of a method according to certain embodiments of the present invention;

Fig . 6 is a flowchart illustrating another example of a method according to certain embodiments of the present invention;

Fig . 7 is a flowchart illustrating another example of a method according to certain embodiments of the present invention;

Fig . 8 is a flowchart illustrating another example of a method according to certain embodiments of the present invention;

Fig . 9 is a diagram illustrating an example of an apparatus according to certain embodiments of the present invention.

Detailed Description

In the following, examples and embodiments of the present invention are described with reference to the drawings. For illustrating the present invention, the examples and embodiments will be described in connection with a cellular communication network based on a 3GPP based communication system, for example an LTE/LTE-A based system. However, it is to be noted that the present invention is not limited to an application using such types of communication system, but is also applicable in other types of communication systems and the like.

The basic system architecture of a communication network where examples of embodiments of the invention are applicable may comprise a commonly known architecture of one or more communication systems comprising a wired or wireless access network subsystem and a core network. Such an architecture may comprise one or more access network control elements, radio access network elements, access service network gateways or base transceiver stations, such as a base station or eNB, which control a coverage area also referred to as a cell and with which one or more communication elements or terminal devices such as a user equipment (UE) or another device having a similar function, such as a modem chipset, a chip, a module etc., which can also be part of a UE or attached as a separate element to a UE, or the like, are capable to communicate via one or more channels for transmitting several types of data. Furthermore, core network elements such as gateway network elements, policy and charging control network elements, mobility management entities and the like may be comprised .

The general functions and interconnections of the described elements, which also depend on the actual network type, are known to those skilled in the art and described in corresponding specifications, so that a detailed description thereof is omitted herein. However, it is to be noted that several additional network elements and signaling links may be employed for a communication to or from a communication element or terminal device like a UE and a communication network control element like a radio network controller, besides those described in detail herein below.

Furthermore, the described network elements, such as communication network control elements, like an eNB, and the like, as well as corresponding functions as described herein may be implemented by software, e.g., by a computer program product for a computer, and/or by hardware. In any case, for executing their respective functions, correspondingly used devices, nodes or network elements may comprise several means and components (not shown) which are required for control, processing and communication/signaling functionality. Such means may comprise, for example, one or more processor units including one or more processing portions for executing instructions, programs and for processing data, memory means for storing instructions, programs and data, for serving as a work area of the processor or processing portion and the like (e.g ., ROM, RAM, EEPROM, and the like), input means for inputting data and instructions by software (e.g ., floppy disc, CD-ROM, EEPROM, and the like), user interface means for providing monitor and manipulation possibilities to a user (e.g ., a screen, a keyboard and the like), interface means for establishing links and/or connections under the control of the processor unit or portion (e.g ., wired and wireless interface means, an antenna, etc.) and the like. It is to be noted that in the present specification processing portions should not be only considered to represent physical portions of one or more processors, but may also be considered as a logical division of the referred processing tasks performed by one or more processors.

In existing systems, as described above, the SRVCC mobility is triggered at MME/eNB based on presence of QCI= 1 bearer. This assumes the voice bearers are always associated with IMS only. Under this assumption the SRVCC mobility via 3G-MSC will succeed always as there is IMS bearer associated with the UE at the time of mobility. When QCI= 1 bearer is created for non-IMS based applications such as webRTC, the current check based on QCI= 1 alone will result in mobility failures.

According to certain aspects of the present invention, the above problem is solved by having additional identification for IMS-voice bearer and based on the same triggering handover without causing mobility failures.

According to certain aspects of the present invention, there is proposed an additional attribute as part of bearer setup procedure to indicate whether the bearer can be transferred via SRVCC or not. The changes proposed for certain aspects of the present invention start from PCRF (Policy and Charging Rule Function).

As part of voice bearer setup, in case of IMS based voice services, the IMS component will request for PCRF to activate traffic flow with QCI= 1 along with traffic filter criteria. The PCRF, after checking with HSS, will request for activation of the QCI= 1 bearer with PDN-GW (Packet Data Network Gateway) which implements the PCEF (Policy and Charging Enforcement Function) functionality. PDN-GW will in turn create new dedicated bearer with QCI= 1.

In case the voice bearer setup corresponds to the non-IMS based voice-sessions, the application-server (AF) or the IMS component will request for the bearer creation to PCRF.

The below described changes are introduced as part of the invention to differentiate the IMS voice bearer which can be transferred via SRVCC and other voice bearers to the EPC (Evolved Packet Core) / eNB components so that the mobility scenario for UE having non-IMS based voice bearers are successful with graceful cleanup of non-IMS bearer prior to handover. Optionally, the MME/PGW can downgrade the QoS to lower value for the non-IMS bearer to allow this bearer to continue with reduced QoS.

In order to differentiate IMS bearers from non-IMS bearers, the webRTC (non- IMS) application / IMS component should indicate whether the traffic flow requested is SRVCC capable or not to PCRF. Based on the above indication, PCRF will inform the additional parameter to PDN-GW indicating that the bearer is SRVCC capable or not.

PDN-GW as part of bearer setup will include additional parameter RAB-SRVCC capability towards MME. MME will also inform the attribute towards eNB as part of ERAB setup / modify procedure. When IMS component or webRTC application server sets up the voice bearer, it informs the PCRF the Service Data-flow information via Rx Interface procedures. As part of this procedure an additional attribute bearer-type is included in the message. IMS component sets the SRVCC-Indicator to TRUE. Other (non-IMS) application components will set the SRVCC-Indicator to FALSE.

For the given SDF, PCRF creates the dynamic PCC rule for the subscriber to PCEF at PDN-GW. As part of new PCC rule creation, PCRF provides additional parameter SRVCC-Indicator as it is received from IMS/webRTC (non-IMS) application server.

The changes for the ERAB Creation procedure are here described .

When the PDN-GW creates dedicated bearer corresponding to the voice SDF, it includes the additional parameter RAB-SRVCC-capability . This parameter value is set as per the additional info received as part of dynamic PCC rule.

The eNB behavior modified during mobility procedure is as follows.

• The eNB will trigger SRVCC based handover only if the target UTRAN is not IMS capable and there exists one QCI= 1 ERAB with RAB-SRVCC-Capability is set to TRUE.

• In case there is no QCI=5 bearer (indicating IMS signaling) but QCI= 1 bearer is active at the time of mobility trigger, the eNB will not set the SRVCC handover indication. Because for IMS voice session to be active, the IMS signaling bearer is mandatory. So the absence of QCI=5 along with presence of QCI= 1 is indication that the voice bearer is setup via non-IMS applications. Here all the bearers including QCI= 1 will be transferred as PS handover.

o This behavior will resolve the use-case where the webRTC application is triggering voice calls, when no IMS based services (not only voice, but also any other non voice) are active in the UE.

MME behavior modified during mobility procedure is as follows. • When MME identifies the presence of QCI= 1 bearer with RAB-SRVCC- Capability = FALSE, MME can initiate the deactivation of dedicated bearer with PDN-GW with new cause = mobility-not-supported. MME can optionally request for downgrading the QCI value instead of deactivation of the bearer.

• In the case of deactivation PGW shall release the mapping of the SDF to QCI= 1 and further packets for this SDF (RTP (Real-time Transport Protocol) packets) will be sent via default bearer. This step ensures that the voice bearer is not released but instead it will continue without QoS treatment after handover. This procedure can go in parallel with relocation preparation.

• Another option for MME implementation is to trigger the ERAB modification towards PGW to use lower QoS profile which is supported at target.

According to certain aspects of the present invention, there is also conceivable an extension of the solution for IMS video-calls.

With reference to document [2], the video bearers of the IMS call will be created with an additional flag vSRVCC indicator towards MME. MME uses this parameter of the bearer to identify the video bearer which needs to be transferred via CS.

When the system supports both IMS and non-IMS based (webRTC) video services, the differentiation of the video-bearers of non-IMS services will be done with the below changes at IMS/AF.

• IMS/AF, while creating the SDF for its video-bearer which is not from IMS client, shall indicate that this bearer does not support vSRVCC to PCRF.

• Based on the same PCRF also inform to PDN-GW as part of creation of PCC rule for this video-bearer.

• This will result in PDN-GW creating EPS bearers with MME without the vSRVCC indicator set for non-IMS services With the above changes, the logic of MME to decide on whether to trigger vSRVCC for video call is modified as below.

• MME will trigger PS-CS conversion for bearers with QCI= 1 and RAB- SRVCC-Capability set to TRUE and the bearer which have vSRVCC indicator set.

• If there are no QCI= 1 bearer with RAB-SRVCC-Capability set to TRUE, MME will not trigger the SRVCC handover and these bearers will be released prior to PS handover.

With the above logic, when the UE is having video-call via webRTC application, the MME will not trigger the SRVCC towards MSC.

Fig . 3 is a signaling diagram illustrating the message sequence for creation of dynamic PCC rule followed by creation of dedicated ERAB for voice bearer according to certain aspects of the present invention for IMS based voice services.

The key steps modified according to certain aspects of the present invention are as follows (cf. Fig . 3).

Step S31 denotes the IMS registration and IMS signaling until trigger of voice bearer setup. In step S32, the IMS component, when requesting for SDF creation for voice services also provides additional info SRVCC-Indicator = TRUE. The PCRF, when it creates a new PCC rule for the flow related to this voice bearer, also includes a new AVP (Attribute Value Pair) SRVCC-Indicator = TRUE in step S33. Then, in step S34, when the PDN-GW creates ERAB for this PCC rule, the ERAB is created with QCI= 1 and RAB-SRVCC-Capability is set to TRUE.

When the voice call is setup via webRTC application or if the IMS is setting up the voice bearer for webRTC-type of applications, the above message sequence is modified as below. In step S32, SRVCC-Indicator will be set to FALSE, in step S33, the same info is sent to PDN-GW via PCRF (SRVCC-Indicator = FALSE), and in step S34, the ERAB created for this bearer will have the RAB-SRVCC-Capability set to FALSE.

The message sequence illustrated in Fig . 4 provides the mobility procedure modified according to certain aspects of the present invention for LTE to UTRAN handover for both IMS and non-IMS (e.g ., WebRTC) originated voice bearers.

The procedure shown in Fig . 4 is as follows.

1. As the eNB is aware of the QCI= 1 bearers and its RAB-SRVCC-capability, the SRVCC HO decision is modified as follows:

o If the target node does not support IMS voice (i.e. if the target node is part of 3G UTRAN and does not support required 3G QoS corresponding to QCI= 1), and

o The eNB has one active bearer with QCI= 1 and with RAB-SRVCC- Capability set to TRUE,

^■ The SRVCC HO Indication will be set to TRU E.

o Otherwise this parameter will be set to FALSE.

If there are more than one active QCI= 1 bearers,

o SRVCC HO indication is set as per the logic mentioned above.

o The PS-RABs to be modified in Source-Target-container will be set to the RAB corresponding to QCI= 1 with RAB-SRVCC-capability set to TRUE.

2. MME, when it does bearer splitting, will do PS-CS conversion with MSC only for the bearer with QCI= 1 and RAB-SRVCC-Capability = TRUE.

3. If there is another QCI= 1 bearer with RAB-SRVCC-Capability = FALSE, the MME will release this bearer with SGW/PDN-GW with additional indication that mobility is not supported .

PDN-GW will release the mapping corresponding to this SDF and further RTP packets via default bearer with default-QoS.

Alternatively, instead of releasing the QCI= 1 bearer which does not support SRVCC, MME can modify the bearer QoS with PDN-GW to a lower value which can be supported at target-node as part of relocation procedure. As to the differentiation of non Voice bearers when eNB connects to legacy EPC which does not support the new parameter and the non-IMS application does not interwork with IMS, the following is noted .

Under these conditions, if the eNB finds QCI= 1 bearer active during handover but there are no QCI=5 bearer corresponding to IMS signaling, it understands that this voice bearer is originated from non IMS applications.

Consequently, the eNB shall not trigger the SRVCC handover and continue with normal handover.

This new eNB internal behavior does not require any interface impact in order to allow the non-IMS voice bearer to be relocated without failure.

In the following, according to certain aspects of the present invention, alternative variants without interface changes to Gx and Rx interfaces are described.

If the parameters provided to PDN-GW as part of new SDF (or PCC rule) creation as per existing interface use unique values/ranges across IMS based and non- IMS based flows, PDN-GW can use such parameters also to decide whether the RAB-SRVCC-Capability is to be set to TRU E or to FALSE (i.e., if the HO for the voice bearer is executed by means of SRVCC or as a PS-Handover). This alternative implementation is possible for operators having IMS, PDN-GW and PCRF components from same vendor.

An extension of the solution for interworking of IMS and non-IMS video-calls according to certain aspects of the present invention will described in the following .

To allow the MME to differentiate the video bearers of IMS from non-IMS's (e.g ., webRTC), the non-IMS application server/Interworking function shall indicate that the video bearer does not support vSRVCC as part of its SDF creation towards PCRF. This change is sufficient with the basic proposal for MME to differentiate IMS and non IMS video bearers. Fig . 5 is a flowchart illustrating an example of a method according to certain embodiments of the present invention.

According to certain embodiments of the present invention, the method may be implemented in a network element and comprises composing, at a first network element, a message including an indication whether or not a voice bearer supports call continuity in a step S51, and causing transmission of the message to a second network element in a step S52.

According to certain embodiments of the present invention, the first network element is a component of a multimedia subsystem, the message is a request for setting up the call, the indication indicates that the voice bearer supports call continuity, and the second network element includes a policy charging and rules function.

According to certain embodiments of the present invention, the first network element is a component of an application function other than a multimedia subsystem, the message is a request for setting up the call, the indication indicates that the voice bearer does not support call continuity, and the second network element includes a policy charging and rules function.

According to certain embodiments of the present invention, the first network element includes a policy charging and rules function, the message is a policy and charging control rule, and the second network element is a gateway including a policy and charging enforcement function.

According to certain embodiments of the present invention, the first network element is a gateway including a policy and charging enforcement function, the message is a message for setting up a radio access bearer, and the second network element is a base station.

According to certain embodiments of the present invention, the gateway is a serving gateway / packet data network gateway, PGW/SGW, and the message is transmitted from the gateway via a mobility management entity to the base station.

Fig . 6 is a flowchart illustrating another example of a method according to certain embodiments of the present invention.

According to certain embodiments of the present invention, the method may be implemented in a base station, like e.g . an eNode B, and comprises determining, at a base station, whether there exists a radio access bearer having a predetermined quality of service and supporting call continuity in a step S61, and if it is determined that there exists a radio access bearer having a predetermined quality of service and supporting call continuity, composing a handover required message including an indication that the radio access bearer supports call continuity in a step S62.

Fig . 7 is a flowchart illustrating another example of a method according to certain embodiments of the present invention.

According to certain embodiments of the present invention, the method may be implemented in a base station, like e.g . an eNode B, and comprises determining, at a base station, whether there exists a first radio access bearer having a predetermined quality of service and a second radio access bearer having a predetermined quality of service related to internet protocol multimedia subsystem, IMS, signaling in a step S71, and if it is determined that there exists the first radio access bearer but not the second radio access bearer, composing a handover required message including an indication for packet switched handover in a step S72.

According to certain embodiments of the present invention, the method further comprises causing transmission of the handover required message including the indication to a mobility management entity (MME).

Fig . 8 is a flowchart illustrating another example of a method according to certain embodiments of the present invention. According to certain embodiments of the present invention, the method may be implemented in a network element, like e.g . mobility management entity (MME), and comprises causing reception, at a network element, of a handover required message including an indication whether or not a radio access bearer supports call continuity in a step S81, determining, at the network element, whether or not the radio access bearer supports call continuity based on the received indication in a step S82, and, if it is determined that the radio access bearer supports call continuity, performing conversion from packet switched to circuit switched handover for the radio access bearer in a step S83.

According to certain embodiments of the present invention, if it is determined that the radio access bearer does not support call continuity, the method further comprises causing deactivation of the radio access bearer.

According to certain embodiments of the present invention, if it is determined that the radio access bearer does not support call continuity, the method further comprises causing transmission of the radio access bearer with reduced quality of service.

According to certain embodiments of the present invention, the call includes voice call and video call, and the call continuity includes voice call continuity and video call continuity.

Fig . 9 is a block diagram showing an example of an apparatus according to certain embodiments of the present invention.

In Fig . 9, a block circuit diagram illustrating a configuration of an apparatus 90, such as of a network element or part of a network element, is shown, which is configured to implement the above described aspects of the invention. It is to be noted that the apparatus 90 shown in Fig . 9 may comprise several further elements or functions besides those described herein below, which are omitted herein for the sake of simplicity as they are not essential for understanding the invention. Furthermore, even though reference is made to a network element, the apparatus may be also another device having a similar function, such as a chipset, a chip, a module etc., which can also be part of a network element or attached as a separate element to a network element, or the like.

The apparatus 90 may comprise a processing function or processor 91, such as a CPU or the like, which executes instructions given by programs or the like related to the flow control mechanism. The processor 91 may comprise one or more processing portions dedicated to specific processing as described below, or the processing may be run in a single processor. Portions for executing such specific processing may be also provided as discrete elements or within one or more further processors or processing portions, such as in one physical processor like a CPU or in several physical entities, for example. Reference sign 92 denotes transceiver or input/output (I/O) units (interfaces) connected to the processor 91. The I/O units 92 may be used for communicating with one or more management entities and or user equipments. The I/O units 92 may be a combined unit comprising communication equipment towards several network elements, or may comprise a distributed structure with a plurality of different interfaces for different network elements. Reference sign 93 denotes a memory usable, for example, for storing data and programs to be executed by the processor 91 and/or as a working storage of the processor 91.

The processor 91 is configured to execute processing related to the above described aspects. In particular, the processor 91 is configured to perform composing, at a first network element, a message including an indication whether or not a voice bearer supports call continuity, and causing transmission of the message to a second network element.

According to certain embodiments of the present invention, the processor 91 is configured to perform determining, at a base station, whether there exists a radio access bearer having a predetermined quality of service and supporting call continuity, and if it is determined that there exists a radio access bearer having a predetermined quality of service and supporting call continuity, composing a handover required message including an indication that the radio access bearer supports call continuity.

According to certain embodiments of the present invention, the processor 91 is configured to perform determining, at a base station, determining whether there exists a first radio access bearer having a predetermined quality of service and a second radio access bearer related to internet protocol multimedia subsystem, IMS, signaling, and if it is determined that there exists the first radio access bearer but not the second radio access bearer, composing a handover required message including an indication for packet switched handover. According to certain embodiments of the present invention, the processor 91 is configured to perform causing transmission of the handover required message including the indication to a mobility management entity (MME).

According to certain embodiments of the present invention, the processor 91 is configured to perform causing reception of a handover required message including an indication whether or not a radio access bearer supports call continuity, determining whether or not the radio access bearer supports call continuity based on the received indication, if it is determined that the radio access bearer supports call continuity, performing conversion from packet switched to circuit switched handover for the radio access bearer.

According to certain embodiments of the present invention, the processor 91 is configured to perform, if it is determined that the radio access bearer does not support call continuity, causing deactivation of the radio access bearer.

According to certain embodiments of the present invention, the processor 91 is configured to perform, if it is determined that the radio access bearer does not support call continuity, causing transmission of the radio access bearer with reduced quality of service.

In the foregoing exemplary description of the apparatuses, only the units/means that are relevant for understanding the principles of the invention have been described using functional blocks. The apparatus may comprise further units/means that are necessary for its respective operation as network element, base station, management entity, and the like, respectively. However, a description of these units/means is omitted in this specification. The arrangement of the functional blocks of the apparatus is not construed to limit the invention, and the functions may be performed by one block or further split into sub-blocks. When in the foregoing description it is stated that the apparatus (or some other means) is configured to perform some function, this is to be construed to be equivalent to a description stating that a (i.e. at least one) processor or corresponding circuitry, potentially in cooperation with computer program code stored in the memory of the respective apparatus, is configured to cause the apparatus to perform at least the thus mentioned function. Also, such function is to be construed to be equivalently implementable by specifically configured circuitry or means for performing the respective function (i.e. the expression "unit configured to" is construed to be equivalent to an expression such as "means for").

For the purpose of the present invention as described herein above, it should be noted that

- method steps likely to be implemented as software code portions and being run using a processor at an apparatus (as examples of devices, apparatuses and/or modules thereof, or as examples of entities including apparatuses and/or modules therefore), are software code independent and can be specified using any known or future developed programming language as long as the functionality defined by the method steps is preserved;

- generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the aspects/embodiments and its modification in terms of the functionality implemented;

- method steps and/or devices, units or means likely to be implemented as hardware components at the above-defined apparatuses, or any module(s) thereof, (e.g ., devices carrying out the functions of the apparatuses according to the aspects/embodiments as described above) are hardware independent and can be implemented using any known or future developed hardware technology or any hybrids of these, such as MOS (Metal Oxide Semiconductor), CMOS (Complementary MOS), BiMOS (Bipolar MOS), BiCMOS (Bipolar CMOS), ECL (Emitter Coupled Logic), TTL (Transistor-Transistor Logic), etc., using for example ASIC (Application Specific IC (Integrated Circuit)) components, FPGA (Field-programmable Gate Arrays) components, CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) components; - devices, units or means (e.g. the above-defined apparatuses, or any one of their respective units/means) can be implemented as individual devices, units or means, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device, unit or means is preserved;

- an apparatus may be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such chip or chipset; this, however, does not exclude the possibility that a functionality of an apparatus or module, instead of being hardware implemented, be implemented as software in a (software) module such as a computer program or a computer program product comprising executable software code portions for execution/being run on a processor;

- a device may be regarded as an apparatus or as an assembly of more than one apparatus, whether functionally in cooperation with each other or functionally independently of each other but in a same device housing, for example.

In general, it is to be noted that respective functional blocks or elements according to above-described aspects can be implemented by any known means, either in hardware and/or software, respectively, if it is only adapted to perform the described functions of the respective parts. The mentioned method steps can be realized in individual functional blocks or by individual devices, or one or more of the method steps can be realized in a single functional block or by a single device.

Generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the present invention. Devices and means can be implemented as individual devices, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device is preserved . Such and similar principles are to be considered as known to a skilled person.

Software in the sense of the present description comprises software code as such comprising code means or portions or a computer program or a computer program product for performing the respective functions, as well as software (or a computer program or a computer program product) embodied on a tangible medium such as a computer-readable (storage) medium having stored thereon a respective data structure or code means/portions or embodied in a signal or in a chip, potentially during processing thereof.

It is noted that the aspects/embodiments and general and specific examples described above are provided for illustrative purposes only and are in no way intended that the present invention is restricted thereto. Rather, it is the intention that all variations and modifications which fall within the scope of the appended claims are covered.

Claims

1. A method, comprising :

causing transmission of the message to a second network element.

2. The method according to claim 1, wherein

the first network element is a component of a multimedia subsystem, the message is a request for setting up the call,

the indication indicates that the voice bearer supports call continuity, and the second network element includes a policy charging and rules function.

3. The method according to claim 1, wherein

the first network element is a component of an application function other than a multimedia subsystem,

the message is a request for setting up the call,

the indication indicates that the voice bearer does not support call continuity, and

the second network element includes a policy charging and rules function.

4. The method according to claim 1, wherein

the first network element includes a policy charging and rules function, the message is a policy and charging control rule, and

the second network element is a gateway including a policy and charging enforcement function.

5. The method according to claim 1, wherein

the first network element is a gateway including a policy and charging enforcement function,

the message is a message for setting up a radio access bearer, and the second network element is a base station.

6. The method accoding to claim 5, wherein

the gateway is a serving gateway / packet data network gateway, PGW/SGW, and the message is transmitted from the gateway via a mobility management entity to the base station.

7. A method, comprising :

8. A method, comprising :

determining, at a base station, whether there exists a first radio access bearer having a predetermined quality of service and a second radio access bearer having a predetermined quality of service related to internet protocol multimedia subsystem, IMS, signaling, and

9. The method according to claim 7 or 8, further comprising :

causing transmission of the handover required message including the indication to a mobility management entity, MME.

10. A method, comprising :

determining, at the network element, whether or not the radio access bearer supports call continuity based on the received indication, if it is determined that the radio access bearer supports call continuity, performing conversion from packet switched to circuit switched handover for the radio access bearer.

11. The method according to claim 10, further comprising

if it is determined that the radio access bearer does not support call continuity, causing deactivation of the radio access bearer

12. The method according to claim 10, further comprising

if it is determined that the radio access bearer does not support call continuity, causing transmission of the radio access bearer with reduced quality of service.

13. The method according to any one of claims 1 to 12, wherein

the call includes voice call and video call, and

the call continuity includes voice call continuity and video call continuity.

14. An apparatus for use in a first network element, comprising :

at least one processor,

at least one interface to at least one other network element, and

causing transmission of the message to a second network element.

15. The apparatus according to claim 14, wherein

16. The apparatus according to claim 14, wherein

the message is a request for setting up the call,

the second network element includes a policy charging and rules function.

17. The apparatus according to claim 14, wherein

18. The apparatus according to claim 14, wherein

19. The apparatus according to claim 18, wherein

20. An apparatus, comprising :

at least one processor,

at least one interface to at least one other network element, and

determining whether there exists a radio access bearer having a predetermined quality of service and supporting call continuity, and if it is determined that there exists a radio access bearer having a predetermined quality of service and supporting call continuity,

21. An apparatus, comprising :

at least one processor,

at least one interface to at least one other network element, and

determining whether there exists a first radio access bearer having a predetermined quality of service and a second radio access bearer having a predetermined quality of service related to internet protocol multimedia subsystem, IMS, signaling, and

22. The apparatus according to claim 20 or 21, further comprising :

23. An apparatus, comprising :

at least one processor,

at least one interface to at least one other network element, and

causing reception of a handover required message including an indication whether or not a radio access bearer supports call continuity, determining whether or not the radio access bearer supports call continuity based on the received indication,

24. The apparatus according to claim 23, wherein the at least one memory and the instructions are further configured to, with the at least one processor, cause the apparatus to perform :

if it is determined that the radio access bearer does not support call continuity, causing deactivation of the radio access bearer.

25. The method according to claim 23, wherein the at least one memory and the instructions are further configured to, with the at least one processor, cause the apparatus to perform :

26. The method according to any one of claims 14 to 25, wherein

the call includes voice call and video call, and

the call continuity includes voice call continuity and video call continuity.

27. An apparatus for use in a first network element, comprising :

means for causing transmission of the message to a second network element.

28. An apparatus, comprising :

if it is determined that there exists a radio access bearer having a predetermined quality of service and supporting call continuity, means for composing a handover required message including an indication that the radio access bearer supports call continuity.

29. An apparatus, comprising :

means for determining whether there exists a first radio access bearer having a predetermined quality of service and a second radio access bearer related to internet protocol multimedia subsystem, IMS, signaling, and

30. An apparatus, comprising :

31. A computer program product including a program for a processing device, comprising software code portions for performing the steps of any one of claims 1 to 13 when the program is run on the processing device.

32. The computer program product according to claim 31, wherein the computer program product comprises a computer-readable medium on which the software code portions are stored.

33. The computer program product according to claim 31, wherein the program is directly loadable into an internal memory of the processing device.