WO2016056811A1

WO2016056811A1 - Single radio voice call continuity

Info

Publication number: WO2016056811A1
Application number: PCT/KR2015/010537
Authority: WO
Inventors: Ricky Kumar KAURA; Curt Chi-Ho WONG
Original assignee: Samsung Electronics Co., Ltd.
Priority date: 2014-10-07
Filing date: 2015-10-06
Publication date: 2016-04-14
Also published as: GB201418802D0; GB2531083A

Abstract

A method of operating a network device in a mobile communications network including a first RAN having a Packet Switched, PS, domain and at least one target RAN having a Circuit Switched, CS, domain. The method comprises determining whether the CS domain of at least one target RAN supports a first codec, and determining whether a mobile device supports the first codec for voice bearers in a CS domain. If the determination is that the CS domain of at least one target RAN and the mobile device support the first codec, the method further comprises sending, during Single Radio Voice Call Continuity, SRVCC, handover of a voice bearer from the PS domain of the first RAN to the CS domain of a selected target RAN supporting the first codec, a transcoding checking indicator to a mobility controller associated with the selected target RAN. The transcoding checking indicator is usable by the mobility controller to select a codec to include within an access transfer request directed to an Internet Protocol, IP, Multimedia Subsystem, IMS, with which the voice bearer is anchored.

Description

SINGLE RADIO VOICE CALL CONTINUITY

The present invention relates to Single Radio Voice Call Continuity (SRVCC). In particular, certain embodiments of the present invention relate to codec-related aspects of SRVCC where there is a transfer of a voice bearer from a Packet Switched (PS) network to a Circuit Switching (CS) network. Particular embodiments of the present invention can be implemented within a 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) or LTE Advanced compliant mobile communications network comprising a mobile terminal (also referred to herein as the User Equipment, UE) and network equipment.

Wireless or mobile (cellular) communications networks in which a mobile terminal (UE, such as a mobile handset) communicates via a radio link to a network of base stations or other wireless access points connected to a telecommunications network, have undergone rapid development through a number of generations. The initial deployment of systems using analogue signalling has been superseded by Second Generation (2G) digital systems such as Global System for Mobile communications (GSM), which typically use a radio access technology known as GSM Enhanced Data rates for GSM Evolution Radio Access Network (GERAN), combined with an improved core network.

Second generation systems have themselves been largely replaced by or augmented by Third Generation (3G) digital systems such as the Universal Mobile Telecommunications System (UMTS), which uses a Universal Terrestrial Radio Access Network (UTRAN) radio access technology and a similar core network to GSM. UMTS is specified in standards produced by 3GPP. Third generation standards provide for a greater throughput of data than is provided by second generation systems. This trend is continued with the move towards Fourth Generation (4G) systems.

3GPP design, specify and standardise technologies for mobile wireless communications networks. Specifically, 3GPP produces a series of Technical Reports (TR) and Technical Specifications (TS) that define 3GPP technologies. The focus of 3GPP is currently the specification of standards beyond 3G, and in particular an Evolved Packet System (EPS) offering enhancements over 3G networks, including higher data rates. The set of specifications for the EPS comprises two work items: Systems Architecture Evolution (SAE, concerning the core network) and LTE concerning the air interface. The first set of EPS specifications were released as 3GPP Release 8 in December 2008. LTE uses an improved radio access technology known as Evolved UTRAN (E-UTRAN), which offers potentially greater capacity and additional features compared with previous standards. SAE provides an improved core network technology referred to as the Evolved Packet Core (EPC). Despite LTE strictly referring only to the air interface, LTE is commonly used to refer to the whole of the EPS, including by 3GPP themselves. LTE is used in this sense in the remainder of this specification, including when referring to LTE enhancements, such as LTE Advanced. LTE is an evolution of UMTS and shares certain high level components and protocols with UMTS. LTE Advanced offers still higher data rates compared to LTE and is defined by 3GPP standards releases from 3GPP Release 10 up to and including 3GPP Release 12. LTE Advanced is considered to be a 4G mobile communication system by the International Telecommunication Union (ITU).

The present invention is implemented within an LTE mobile network. Therefore, an overview of an LTE network is shown in Figure 1. The LTE system comprises three high level components: at least one UE 102, the E-UTRAN 104 and the EPC 106. The EPC 106 communicates with Packet Data Networks (PDNs) and servers 108 in the outside world. Figure 1 shows the key component parts of the EPC 106. It will be appreciated that Figure 1 is a simplification and a typical implementation of LTE will include further components. In Figure 1 interfaces between different parts of the LTE system are shown. The double ended arrow indicates the air interface between the UE 102 and the E-UTRAN 104. For the remaining interfaces user data is represented by solid lines and signalling is represented by dashed lines.

The E-UTRAN 104 comprises a single type of component: an eNB (E-UTRAN Node B) which is responsible for handling radio communications between the UE 102 and the EPC 106 across the air interface. An eNB controls UEs 102 in one or more cell. LTE is a cellular system in which the eNBs provide coverage over one or more cells. Typically there is a plurality of eNBs within an LTE system. In general, a UE in LTE communicates with one eNB through one cell at a time.

Key components of the EPC 106 are shown in Figure 1. It will be appreciated that in an LTE network there may be more than one of each component according to the number of UEs 102, the geographical area of the network and the volume of data to be transported across the network. Data traffic is passed between each eNB and a corresponding Serving Gateway (S-GW) 110 which routes data between the eNB and a PDN Gateway (P-GW) 112. The P-GW 112 is responsible for connecting a UE to one or more servers or PDNs 108 in the outside world. The Mobility Management Entity (MME) 114 controls the high-level operation of the UE 102 through signalling messages exchanged with the UE 102 through the E-UTRAN 104. Each UE is registered with a single MME. There is no direct signalling pathway between the MME 114 and the UE 102 (communication with the UE 102 being across the air interface via the E-UTRAN 104). Signalling messages between the MME 114 and the UE 102 comprise EPS Session Management (ESM) protocol messages controlling the flow of data from the UE to the outside world and EPS Mobility Management (EMM) protocol messages controlling the rerouting of signalling and data flows when the UE 102 moves between eNBs within the E-UTRAN. The MME 114 exchanges signalling traffic with the S-GW 110 to assist with routing data traffic. The MME 114 also communicates with a Home Subscriber Server (HSS) 116 which stores information about users registered with the network.

Within an LTE network, data is transferred between different components of the network using bearers. An EPS bearer serves to transfer data between a UE and a P-GW. The data flow is bi-directional. Data carried by an EPS bearer comprises one or more service data flows carrying data for a particular service, for instance streamed media, including voice. Each service data flow comprises one or more packet flows.

LTE is designed primarily as a high speed PS network. Voice services are processed using the PS network, which contrasts with the conventional provision of voice services through a separate CS network connection for GSM and UMTS. In order to support packet services a separate Internet Protocol (IP) Multimedia Subsystem (IMS) network is provided (shown in Figure 2, described below), coupled to the EPC 106. Voice services are therefore provided as Voice over Internet Protocol (VoIP) over LTE (VoLTE) through the use of the IMS network.

As LTE radio access networks are introduced, these networks are typically deployed alongside legacy GSM and UMTS Radio Access Networks (RANs). This is usually to enhance network coverage and capacity, particularly where LTE networks are initially only deployed in major cities. UEs are typically capable of communication using two or more Radio Access Technologies (RATs), for example a UE may be able operate using LTE, where this is available, but also able to operate using a legacy radio access technology such as GERA and UTRA, in those service areas of the network where LTE is unavailable. Where handover from an LTE network to a GSM or UMTS network is required, a UE may follow a defined procedure to fall back to using a GSM or UMTS network for voice communications, typically falling back to CS voice communications, according to a Voice Call Continuity (VCC) handover procedure.

For LTE voice calls the IMS network is used to control PS services offered over the E-UTRAN. In contrast, control of CS services in a GSM/UMTS network is the responsibility of a mobility controller, such as a Mobility Switching Centre (MSC also referred to herein as an MSC server). The MSC typically communicates with the session transfer controller provided by the IMS, during session transfer according to a VCC handover procedure.

A UE may be equipped with a single radio transceiver, for reasons of economy or for minimising power consumption, so that simultaneous communication with two radio access networks is not possible. In this case the handover protocol typically uses a break-before-make radio connection during handover. Handover procedures known as Single Radio Voice Call Continuity (SRVCC) procedures have been developed for such situations. These have been extended to include video SRVCC (vSRVCC) procedures for handing over conversational video calls (that is, calls with voice and video content). Reference to SRVCC throughout this document should be considered to extend to vSRVCC.

According to a first aspect of the present invention there is provided a method of operating a network device in a mobile communications network including a first RAN having a Packet Switched, PS, domain and at least one target RAN having a Circuit Switched, CS, domain, the method comprising: determining whether the CS domain of at least one target RAN supports a first codec; and determining whether a mobile device supports the first codec for voice bearers in a CS domain; wherein if the determination is that the CS domain of at least one target RAN and the mobile device support the first codec, the method further comprises sending, during Single Radio Voice Call Continuity, SRVCC, handover of a voice bearer from the PS domain of the first RAN to the CS domain of a selected target RAN supporting the first codec, a transcoding checking indicator to a mobility controller associated with the selected target RAN; wherein the transcoding checking indicator is usable by the mobility controller to select a codec to include within an access transfer request directed to an Internet Protocol, IP, Multimedia Subsystem, IMS, with which the voice bearer is anchored.

The transcoding checking indicator may be sent to a mobility controller associated with the selected target RAN only if the CS domain of the selected target RAN supports the first codec.

The first RAN may comprise: a Long Term Evolution, LTE, RAN; or a High Speed Packet Access, HSPA, enabled Universal Terrestrial Radio Access Network, UTRAN.

If the first RAN comprises an LTE RAN the network device may comprise a Mobility Management Entity, MME, associated with the LTE RAN; and if the first RAN comprises a HSPA enabled UTRAN the network device may comprise a Serving General Packet Radio Service, GPRS, Support Node, SGSN, associated with the HSPA enabled UTRAN.

If the at least one target RAN comprises an Enhanced data rates for GSM Evolution RAN, GERAN or a UTRAN the mobility controller may comprise a Mobile Switching Centre, MSC, server.

The first codec may comprise a preferred codec for CS voice received from a Home Subscriber Server, HSS, associated with the mobile device.

The transcoding checking indicator may comprise the preferred codec for CS voice; and wherein the preferred codec for CS voice may be arranged to be included within an access transfer request directed to an IMS with which the voice bearer is anchored by the mobility controller within the selected target RAN.

The transcoding indicator may be arranged to instruct the mobility controller associated with the selected target RAN to obtain a codec used for the most recently made active IMS session.

The at least one target RAN may comprise a group of at least two target RANs operating according to different Radio Access Technologies, RATs, the method further comprising: determining a preferred RAT according to whether each RAN in the group supports the first codec or in accordance with a network operator policy; and sending an indication of a preferred RAT to a base station associated with the mobile device, the base station being responsible for selecting a target RAN from the group during a SRVCC procedure.

The determination of a preferred RAT may be further in accordance with a network operator policy in the event that more than one RAN in the group supports the first codec.

The method may further comprise: determining if the preferred RAT has changed if a network operator policy has changed; and sending an updated indication of a preferred RAT to the base station associated with the mobile device if the preferred RAT has changed.

The first codec may comprise a currently used codec for the voice bearer within the PS domain of the first RAN.

The transcoding checking indicator may comprise the currently used codec; and wherein the currently used codec is arranged to be included within an access transfer request directed to an IMS with which the voice bearer is anchored by the mobility controller within the selected target RAN.

The method may further comprise receiving an indication of the currently used codec within a Non-Access Stratum, NAS, message from the mobile device.

The method may further comprise receiving an indication of the currently used codec from a Proxy Call Session Control Function, P-CSCF, within the IMS via Policy and Charging Control, PCC messaging.

The method may further comprise receiving an indication of the currently used codec from a HSS associated with the mobile device, the HSS having received an indication of the currently used codec from an Service Centralisation and Continuity Application Server, SCC AS, within the IMS.

The method may further comprise: determining if the preferred RAT has changed if the currently used codec has changed; and sending an updated indication of a preferred RAT to the base station associated with the mobile device if the preferred RAT has changed.

According to a second aspect of the present invention there is provided a network device in mobile communications network including a first RAN having a Packet Switched, PS, domain and at least one target RAN having a Circuit Switched, CS, domain, wherein the network device is arranged to: determine whether the CS domain of at least one target RAN supports a first codec; and determine whether a mobile device supports the first codec for voice bearers in a CS domain; wherein if the determination is that the CS domain of at least one target RAN and the mobile device support the first codec, the network device is further arranged to send, during Single Radio Voice Call Continuity, SRVCC, handover of a voice bearer from the PS domain of the first RAN to the CS domain of a selected target RAN supporting the first codec, a transcoding checking indicator to a mobility controller associated with the selected target RAN; wherein the transcoding checking indicator is usable by the mobility controller to select a codec to include within an access transfer request directed to an Internet Protocol, IP, Multimedia Subsystem, IMS, with which the voice bearer is anchored.

The network device is further arranged to implement the above method.

Another aspect of the invention provides a computer program comprising instructions arranged, when executed, to implement a method and/or apparatus in accordance with any one of the above-described aspects. A further aspect provides machine-readable storage storing such a program.

It is an aim of certain embodiments of the present invention to provide a modified SRVCC procedure that may reduce processing performed within a GSM/UMTS network after handover of a voice bearer from an LTE network or another type of PS network offering voice or voice and video calls.

Embodiments of the invention are further described hereinafter with reference to the accompanying drawings, in which:

Figure 1 schematically illustrates an overview of an LTE mobile communication network;

Figure 2 schematically illustrates SRVCC in an LTE mobile communication network;

Figure 3 schematically illustrates the effect of MSC codec selection on transcoding following an SRVCC procedure;

Figure 4 illustrates actions upon initial network attach in accordance with a first embodiment of the present invention;

Figure 5 is a flowchart illustrating logic implemented by a MME within an LTE network in accordance with a first embodiment of the present invention;

Figure 6 illustrates MME actions at the time of SRVCC handover in accordance with a first embodiment of the present invention;

Figure 7 illustrates MSC actions at the time of SRVCC handover in accordance with a first embodiment of the present invention;

Figure 8 is a flowchart illustrating logic implemented by an MSC in accordance with a first embodiment of the present invention;

Figure 9 illustrates MME actions at the time of SRVCC handover in accordance with a second embodiment of the present invention;

Figure 10 is a flowchart illustrating updating a preferred RAT in accordance with a second embodiment of the present invention;

Figure 11 illustrates a first alternative for informing an MME of the actual codec in use in accordance with a second embodiment of the present invention;

Figure 12 illustrates a second alternative for informing an MME of the actual codec in use in accordance with a second embodiment of the present invention;

Figure 13 illustrates a third alternative for informing an MME of the actual codec in use in accordance with a second embodiment of the present invention;

Figure 14 illustrates MME actions at the time of SRVCC handover in accordance with a second embodiment of the present invention;

Figure 15 is a flowchart illustrating logic implemented by an MSC in accordance with a second embodiment of the present invention; and

Figure 16 schematically illustrates SRVCC in a HSPA mobile communication network.

Embodiments of the invention will now be described in the context of an LTE compliant mobile wireless communications network operating in accordance with the 3GPP LTE standards up to Release-12 and beyond. However, it will be understood that this is by way of example only and that other embodiments may involve other wireless networks, operating at least partially in compliance with other releases and other standards. In particular, the present invention is concerned with SRVCC, which provides the ability to transition a voice call from the VoLTE PS domain to a legacy radio access network operating a CS domain. SRVCC may include support for GSM and UMTS and optionally also CDMA 1x CS domains. The skilled person will appreciate that similar considerations will also apply for SRVCC to other CS RATs, which should be considered to be included within the scope of the present invention as defined by the claims. SRVCC allows an operator of such a legacy network to incrementally deploy VoLTE services for a newly deployed LTE network without the requirement to provide ubiquitous LTE coverage, and VoLTE functionality, from day one. Furthermore, while the majority of the following description refers to SRVCC from a LTE PS network, the present invention is not limited to this. The skilled person will appreciate that similar considerations will also apply for SRVCC from other PS RATs such as High Speed Packet Access (HSPA - which should be considered to include variants and developments including HSPA+ also referred to as Evolved High-Speed Packet Access) which should be considered to be included within the scope of the present invention as defined by the claims. An explanation of how the principles of the present invention may be transferred from LTE to, for instance, HSPA is included below.

Embodiments of the present invention will now be described in the context of a telecommunication network including first and second radio access networks. A first RAN includes a PS domain, for instance an LTE radio access network (the E-UTRAN) in association with an EPC, supporting PS voice communication. A second RAN includes a CS domain, for instance GERAN or UTRAN, or both, supporting CS voice communication.

Initial deployments of LTE networks are typically within areas of coverage of existing RANs, such as legacy GERANs or UTRANs. On initial deployment, an LTE network may provide service to a smaller geographical area than that covered by existing legacy networks, for example covering only city centres, and the areas covered may not be contiguous. Furthermore, only a subset of the available network features may be enabled, and the enablement of features may not be uniform across the network. In particular, due to its potentially enhanced data capacity in comparison with legacy systems, initial deployments of E-UTRAN may concentrate on providing high bandwidth data services, for example to LTE enabled equipment such as personal digital assistants (PDAs) or to user equipment in the form of plug in communication modules for laptop computers. For this reason, the primary LTE voice service (VoLTE) may not be available in certain areas. Given that LTE has no native support for CS voice services, it is clear that if these are required they must be provided by a legacy network offering a CS domain.

If a UE moves out of an area of coverage of an E-UTRAN network, then a handover to a UTRAN or GERAN network may be required. For a UE having a single radio transceiver the handover may be implemented through an SRVCC procedure. Advantageously, an SRVCC procedure prevents established voice calls from being terminated and provides minimal service interruption.

Referring now to Figure 2, this shows signalling paths in a wireless communications network in support of a SRVCC procedure. Portions of the network corresponding to Figure 1 will not be described in detail again. A UE 102 is connected to a first RAN, being in this example an E-UTRAN radio access network 104 across the LTE-Uu air interface. In a situation such as that described in the preceding paragraphs, handover may be required to a second RAN, for example UTRAN or GERAN 202. Handover is represented by the double arrow 2014, indicating that it may take place in either direction, and a UE 102' is shown connected to the UTRAN or GERAN radio access network 202 across the Um/Uu air interface respectively. UE 102' comprises the UE 102 after the handover has taken place and so is drawn with a dashed line to indicate that the UE cannot be connected to both RANs simultaneously.

As discussed in greater detail in connection with Figure 1, the LTE network incorporates the EPC 106. In connection with SRVCC, core signalling between the LTE network and the GSM/UMTS network is managed by the MME 114. The MME 114 is connected to the HSS 116 across the S6a interface, the E-UTRAN 104 across an S1-MME interface and the S-GW/P-GW 110,112 across an S11 interface. The E-UTRAN 104 and the S-GW/P-GW 110,112 are themselves connected across a S1-U interface. The HSS 116 and the S-GW/P-GW 110,112 act in support of handover within the EPC 106.

The P-GW 112 and therefore, indirectly, the S-GW 110 are connected to an IMS network 206 across a SGi interface. Specifically, the S-GW/P-GW 110,112 are connected to a Proxy Call Session Control Function (P-CSCF) or a Serving CSCF (S-CSCF) 208 which are responsible for the correct routing and transmission of voice data between the UE and the other endpoint of the voice call.

The IMS 206 also connects to the GSM/UMTS network. Specifically the connection is between a Mobile Switching Centre (MSC) 210 and the P-CSCF/S-CSCF 208 for routing voice data between the GSM/UMTS network and the IMS network after handover. The MSC 210 is a mobility controller responsibility for controlling the routing to data to and from UEs within the GSM/UMTS network. The MSC 210 also connects to the MME across a Sv network for exchanging signalling in support of the handover. The MSC 210 connects to the UTRAN/GERAN 202 across a lu-cs/A interface.

Finally, the GSM/UMTS network includes a Serving General Packet Radio Service Support Node (SGSN) 212, which has a connection to the MME 114 across an S3 interface and to the UTRAN/GERAN 202 across a lu-ps/Gb interface.

The IMS 206 comprises a core network server for the LTE network, which may be a Service Centralisation and Continuity Application Server (SCC AS) 214, the functionality of which will be described in greater detail below.

An explanation of how SRVCC currently is implemented now follows. Under CS Fall Back (CSFB) no VoLTE service is provided by the LTE network and all voice calls must by default be wholly performed within a CS domain of another network. In contrast, SRVCC is concerned with seamlessly handling a VoLTE voice call that is currently underway (in an active state, an alerting state or a pre-alerting state as described below). Specifically, a UE which is currently engaged in a VoLTE voice call may, for instance, move to a region in which LTE radio coverage is week (or the network may for some other reason decide to pass the call to a GSM/UMTS network).

The MME 114 notifies the MSC 210 of the need to switch the voice call from the PS LTE domain to the CS GSM/UMTS domain. As part of this the MME 114 splits voice bearers from non-voice bearers. Non-voice bearers are to be handled separately in the PS domain of the GSM/UMTS network. A handover is initiated for LTE voice bearers to the CS network. That is, the MME 114 initiates relocation of the voice bearers towards the MSC server 210 and non-voice bearers to the SGSN 212. If the legacy network does not provide a PS domain (for instance, a GSM network without a Dual Transfer Mode (DTM) and hence no SGSN 212) then non-voice bearers are suspended and only voice bearers are relocated to the MSC 210. The treatment of non-voice bearers following handover to a GSM/UMTS network is outside of the scope of the present specification.

The MSC 210 establishes a bearer path for the voice call. Solid line 220 shows the voice bearer within the LTE PS domain prior to SRVCC handover. The voice bearer 220 extends between the UE 102 and the IMS network 206. Dotted line 222 indicates the Session Initiation Protocol (SIP) signalling pathway between the UE and the IMS network 206 for initialising the voice call. In Figure 2 the transfer of the voice bearer from the UE 102, via the UTRAN 104, the MME 114, and the MSC 210 to the IMS network 206 is shown by the arrow 216. The voice bearer after SRVCC handover is indicated by the dashed line 224. The voice bearer 224 extends between the UE 102 and the IMS network 206. Negotiation of a voice bearer between the MSC 210 and the IMS 206 is performed via an SIP INVITE message. Specifically, the MSC 210 negotiates IMS session transfer and selects the parameters of a voice bearer for use after handover. The P-CSCF/S-CSCF 208 is responsible for performing the transfer of bearer paths. When the MSC 210 is ready for handover the MSC 210 sends a transfer request to the UE 102 via the E-UTRAN 104. After handover the UE 102 commences CS voice processing for the remainder of the call and voice data is transferred solely through the GSM/UMTS network. The VoLTE bearer between the UE 102 and the IMS 206 is deleted.

The skilled person will appreciate that the above description of conventional SRVCC procedures is simplified for the purposes of brevity. In particular, the above description of SRVCC relates to a network triggered handover procedure for which greater detail can be found within 3GPP TS 23.216, TS 24.008 and TS 29.280. The skilled person will be familiar with these standards. In addition, SRVCC may comprise an IMS session level transfer procedure for which greater detail can be found within 3GPP TS 23.237 and TS 24.237. The skilled person will be familiar with these standards. Similar considerations discussed below in connection with transcoding apply to network triggered SRVCC and IMS session level transfer SRVCC.

The above discussion of SRVCC has focussed on transfer of a voice call that is currently in progress. This may be more precisely referred to as SRVCC for a call in an "active" state in which the UE has sent or received a "SIP 200 OK" for the IMS session. SRVCC may also be performed for a call in an "alerting" state (the UE has sent or received a "SIP 180 Ringing" for the IMS session or in a "pre-alerting" state (the UE has sent or received a "SIP 183 Session Progress" for the IMS session. The following discussion should be considered to apply equally to all three options except where otherwise explicitly noted.

The role of the IMS network within SRVCC procedure will now be described in greater detail. Prior to handover to a GSM/UMTS network, the UE 102 may have multiple voice media streams (active and inactive) that are carried over multiple EPS voice bearers or are multiplexed over a single EPS voice bearer. The decision whether multiplexing is permitted is made by the Policy and Charging Rules Function (PCRF) which forms part of the EPC 106 (but not shown in Figure 1 or Figure 2) connecting to the S-GW 110, the P-GW 112 and also the IMS 206. The principle role of the PCRF is to control the policy and charging treatment that a service data flow will receive on behalf of the network. In contrast, the MME 114 and the E-UTRAN 104 do not know how many voice streams are carried inside an EPS bearer. Regardless of the number of established EPS voice bearers, the MME 114 triggers only one transaction across the Sv interface, which results in only one voice media session transfer initiated by the MSC Server 210.

IMS Service Continuity can be provided via the home network, specifically by the SCC AS 214 forming part of the IMS network 206. The SCC AS 214 serves to transfer voice bearers from the LTE network (via the P-GW 112) to the GSM/UMTS network (via the MSC server 210). Alternatively, if the UE 102 is currently connected to an LTE network outside of the home network, IMS Service Continuity can be provided via the IMS of the visited network, and specifically an Access Transfer Control Function (ATCF, not illustrated in Figure 2). When the UE 102 is outside of the home network, implementing IMS Service Continuity through the ATCF serves to reduce the duration of voice interruption during SRVCC by moving the IMS anchor point closer to the VoLTE equipped UE. This is accomplished by the ATCF and an Access Transfer Gateway (ATGW) both within the IMS network connected to the visited LTE network. During registration of the UE 102 with the visited network the ATCF notifies the visited network MME that it is responsible for IMS service continuity. During an SRVCC procedure, when the MME 114 communicates with the MSC server 210, subsequent processing uses the ATCF and ATGW located in the visited VoLTE network as opposed to communicating with the SCC AS 214 of the home network.

All IMS sessions are anchored at the SCC AS 214 connected to the home network. However, if the UE 102 is out of the home network, IMS sessions may be additionally anchored at the ATCF as discussed above. While the UE 102 may have multiple voice media streams carried over multiple EPS voice bearers or multiplexed over a single EPS voice bearer, only one of those voice streams may be selected for SRVCC by the ATCF/SCC AS 214 in accordance with 3GPP TS 23.237. The ATCF/SCC AS 214 can transfer at most one active session to the CS domain. As a result of SRVCC all other sessions are made inactive. Specifically, the ATCF/SCC AS 214 transfers the anchored voice session that was most recently made active. The EPS 106 does not need to know which voice session will actually be transferred by the IMS 206. The treatment of inactive sessions is outside of the scope of the present patent application and so will not be further described.

In order to transmit voice data within a wireless communication network it is necessary to encode the voice data in accordance with a codec format. A number of different codec formats are defined by 3GPP. Two of the most widely deployed codecs within 3GPP compliant networks are the Adaptive Multi-Rate (AMR) audio codec and AMR Wideband (AMR-WB) which offers higher quality voice than AMR due to accepting a wider audio bandwidth. More recently, the Enhanced Voice Services (EVS) codec has been added offering further improved voice performance. An EVS compliant UE may also implement AMR-WB interoperable mode in which if the UE becomes aware that the other termination point of a media stream is not compliant with EVS, the UE effectively performs its own transcoding and sends AMR-WB speech packets. This is achieved by a Media Gateway (MGW) informing the UE through in-band signalling to switch to AMR-WB such that transcoding at the MGW can cease. A network element must be EVS aware to take advantage of the AMR-WB interoperable mode of EVS.

It will be appreciated that the codecs that are deployed within different networks may vary, and indeed not all UEs may offer the same selection of codecs. Consequently, transcoding of media streams may be required. This is implemented by MGWs within the wireless communication networks. MGWs provide the ability to convert voice media on voice bearers to a codec which is commonly supported by each end point of a media stream.

Should transcoding be required following SRVCC then this transcoding of media streams may be provided between the IMS network and the GSM/UMTS CS network by a MGW associated with a Media Gateway Controller Function (MGCF) within the IMS network (not shown in Figure 2). Alternatively, transcoding of media in IMS can be provided by a Media Resource Function Processor (MRFP), an IMS Access Gateway (IMS-AGW) associated with an IMS Application Layer Gateway (IMS-ALG) or a Transition Gateway (TrGW) associated with an Interconnection Border Control Function (IBCF), none of which are shown in Figure 2.

Following SRVCC, transcoding may additionally occur at a Media Resource Function (MRF) in the home IMS, a CS-MGW associated with the MSC server 210 or an ATGW associated with an ATCF, none of which are shown in Figure 2.

It will be understood that as part of the SRVCC procedures the MSC is required to determine a suitable codec to encode media streams transmitted between the UE and the IMS. Cleary one criterion must be that the MSC should select a codec supported by the UE. In order to provide the MSC with this information, when an SRVCC capable UE attaches to the E-UTRAN, the UE provides a list of codecs supported by the UE for CS access. This list of supported codecs is supplied at the time of attaching to the E-UTRAN to the MME, though it is not used unless or until there is an SRVCC procedure.

Upon SRVCC handover, the MME sends the list of supported codecs to the MSC. The MSC uses the list to select a suitable voice codec with the RAN for the CS voice call and the selected voice codec is indicated back to the UE via the handover command message. It is not possible for the UE to indicate a preferred codec in the event that multiple codecs are supported.

While the media stream between the MSC and the UE is initiated after SRVCC handover, it will be understood that the media stream between the MSC and the IMS network reflects a rerouting of the media stream previously transmitted to the EPS. According to the prior art implementation of SRVCC, the MSC is not aware of the codec that was selected for the IMS session in LTE, and therefore upon SRVCC handover the MSC may select a codec that requires the media to be transcoded between the UE and the IMS (or in the IMS). This transcoding may represent an unnecessary processing overhead in the event that the UE and the CS network elements support the same codec selected for the IMS session in LTE, but an alternative codec is selected by the MSC.

According to the prior art SRVCC procedures a decision by the MSC to avoid additional transcoding is not possible as this would have to be based upon knowledge of the actual codec in use or the intended codec for use and this is not available to the MSC.

Current functionality when media descriptions are in conflict on the IMS side after SRVCC are defined by 3GPP TS 24.237, section 6A.5:

6A.5 SDP [Session Description Protocol] media description conflict between target and remote access leg

When the SCC AS, the EATF [Emergency Access Transfer Function] or the ATCF receives an SDP offer on the target access leg, the SDP media descriptions on the target access leg and the remote access leg, can be in conflict. The way how the SCC AS, EATF and ATCF resolve the conflict is implementation dependent.

...

NOTE　2: An example on how to solve a conflict can be that transcoding functionality is enabled by inserting an MRF (in case of SCC AS or EATF) or an ATGW (in case of ATCF). Another example is that 488 (Not Acceptable Here) response is sent with the correct SDP media description.

From this it can be seen that there is no provision within the current 3GPP standards to avoid the need for additional transcoding following SRVCC handover. Indeed the focus in the prior art is on how to provide the necessary transcoding through the provision of a suitable MGW.

Table 1 identifies exemplary transcoding requirements according to the codec selected for the voice bearer in the PS domain in a first network (for instance LTE or HSPA as will be explained in further detail below) before SRVCC handover and the codec subsequently selected for use in the CS domain in a second network (for instance GSM or UMTS) after SRVCC handover.

[Table 1]

It will be appreciated that it is desirable to minimise or completely remove the need for transcoding following an SRVCC procedure. Specifically, it will be appreciated that it is desirable to remove the need for additional transcoding following an SRVCC procedure which arises as a result of an undesirable selection of a codec by an MSC. More precisely, the MSC negotiates with the IMS for a codec to use and the negotiated codec may cause additional transcoding. It may be the case that transcoding occurs elsewhere along the media stream unrelated to the selection of a codec by the MSC. The need to minimise transcoding arises partly from the desire to reduce unnecessary processing, but also due to the negative effect of transcoding on voice quality. Avoiding transcoding is particularly important for High Definition (HD) Voice. One option to reduce the use of transcoding is for the ATCF to renegotiate with the remote end any random codec selected by the MSC during an SRVCC procedure. However, this may extend the perceived time it will take to conclude a call transfer and the speech interruption that might result due to the time the negotiation will take.

Referring now to Figure 3, this schematically illustrates the effect of MSC codec selection on transcoding following an SRVCC procedure. The different codecs in use during different sections of a voice call are shown. Part 1 shows a single codec (codec 1) in use between the LTE UE 102 and the IMS prior to SRVCC handover and a separate codec (codec 3) operating between the IMS and the other end point 302 of the media stream. Part 2 shows the situation following an SRVCC handover in which there is a mismatch between the codec selected by the MSC (codec 2) and the codec used prior to the handover (codec 1) and which continues to be the basis of communications between the MSC and the IMS. The result of this is that transcoding is required at the MSC as indicated at point 304. Part 3 shows the situation in which the codec selected by the MSC matches the codec already in use by the IMS (codec 1), such that transcoding is not required at the MSC as indicated by at point 306.

The above discussion assumes that the selection of codecs used within the LTE network matches the available codecs within the GSM/UMTS network, the only constraint upon the MSC codec negotiation with the IMS being the list of codecs supported by the UE, which is provided to the MSC via the MME. However, this assumption may not be valid. In certain situations it may be impossible to avoid transcoding following SRVCC due to the codecs made available in the target RAN selected by the LTE network for handover.

Specifically, a wireless network operator may make a policy decision to allow a certain codec for voice calls to be used on a particular RAT, for instance LTE, but not to allow that codec to be used within the CS domain of another RAT, for instance GSM. For example, CS GSM may not be equipped to support AMR-WB or EVS or these codecs may not be enabled. Furthermore, the wireless network operator may have a defined preference for which legacy RAT is to form the primary target domain for SRVCC, for instance CS GSM, with the result that RAT dependency issues may constrain the likelihood that codec negotiation by the MSC will not introduce additional transcoding. Table 2 illustrates a number of scenarios that may occur regarding codecs available in each RAT. EVS is being supported within LTE in Rel-12 and it is proposed to allow EVS to be supported in GSM CS and UMTS CS. Similarly, AMR-WB can be supported on LTE and UMTS CS and is an operator-only enabled option for GSM CS.

[Table 2]

The selection of the network to which to handover during an SRVCC procedure is the responsibility of the base station, for instance the eNB in LTE. However, the eNB does not know the currently used codec in VoLTE and therefore is unable to take this into account when selecting a suitable RAT to which to handover to minimise or avoid additional transcoding.

A further constraint of the ability of the MSC to negotiate a codec with the IMS which would not introduce additional transcoding arises in a scenario where the UE has multiple on-going voice media sessions (for instance one active and one on HOLD) which use different codecs. It is not readily apparent which one should be targeted for use following an SRVCC procedure to reduce additional transcoding.

Certain embodiments of the present invention described below seek to overcome certain of the disadvantages of prior art SRVCC procedures as described above. In particular, certain embodiments of the present invention seek to reduce or avoid the introduction of additional transcoding requirements following an SRVCC procedure.

Firstly, this may be achieved by allowing the mobility controller (MME for LTE) to influence the RAT selection by the base station (eNB for LTE) for determining the network for handover.

Secondly, this may be achieved by improving the ability of a mobility controller in the selected RAN (MSC for GSM or UMTS) to negotiate an appropriate codec based on the supported codecs of the UE. Based on the action of the eNB in choosing a specific RAT to hand the UE over to, in accordance with certain embodiments of the present invention the mobility controller of the first RAN sends the mobility controller of the second RAN a transcoding checking indicator to be used following the SRVCC procedure. In accordance with certain embodiments of the present invention, the transcoding checking indicator is used to trigger the MSC to determine an appropriate codec. The transcoding checking indicator may comprise an indication that the MSC should seek information from the IMS regarding recently used codecs, a preferred codec for CS voice for that UE or the actual codec used in LTE for the voice bearer to be transferred, as will be described below in connection with first and second embodiments of the present invention.

In accordance with certain embodiments of the present invention, if the transcoding checking indicator is sent to the MSC by the MME, the MSC negotiates with the ATCF or the SCC AS to find out the codec used in the session. Based on the result of the negotiation, the MSC can initiate access transfer and avoid transcoding at the MSC or ATGW if the CS domain and the UE in a CS mode support the codec currently used by the IMS. As such, the codec used by the IMS determines whether it is possible to avoid additional transcoding, and if it is possible the selection of the handover RAT by the eNB and the actions of the MSC determine whether additional transcoding is in fact avoided.

In accordance with a first embodiment of the present invention, selection of a codec is based at least in part upon a preferred codec indication received from the home network for each UE. The IMS associated with the home network always uses a specific "preferred codec for voice" (for instance, EVS) for each UE for voice media bearers over LTE. The home IMS may have to provide transcoding to a remote party if the remote party does not support the same "preferred codec?.

The HSS within the UE's home network indicates this "preferred codec for voice" to the MME in the current network (which may be the home network or a visited network) as a new subscription parameter. Referring to Figure 4, this illustrates actions performed at the time of initial network attach. As shown at point 402, this "preferred codec for voice" is stored by the HSS 116 as an additional subscription option parameter for each UE 102 (along with existing subscription parameters which will be familiar to the skilled person). The preferred code for voice subscription parameter is made available by the HSS 116 to the MME 114 for use in accordance with the first embodiment of the present invention during an Update Location Request (ULR) / Update Location Answer (ULA) exchange as shown by

messages

404, 406, with the ULA message shown including the additional parameter. In addition, as discussed above, an SRVCC capable UE already indicates to the MME in NAS messaging the supported codecs for CS speech calls for that UE as part of network Attach procedures within an Attach message 408 or alternatively or additionally within Tracking Area Updates (TAUs) and Routing Area Updates (RAUs) (not shown in Figure 4). The preferred codec for voice parameter is stored by the MME 114 as shown at point 410. As further shown in Figure 4 at point 412 the MME 114 also stores a network policy (in this case the network illustrated is a VPLMN) which may, for instance as illustrated, allow the preferred coded for voice to be used during SRVCC procedures or allowing for downgrade to another codec. As noted at point 414, the UE supported codecs received in Attach message 408, the HSS preferred codec for voice parameter for that subscriber/UE received in message 406 and network, for instance VPLMN, policy is used to drive the MME's decision whether to include a RAT preference in an Initial Context Set-up message 416 sent to the eNB 104. The determination of a RAT preference will be described in greater detail below in connection with Figure 5. After message 416 is received by the eNB, an Attach-Accept message 418 is returned to the UE 102.

As described in connection with Figure 4 above, during an SRVCC procedure, the MME indicates a "preferred target RAT" to the eNB. The determination of a "preferred target RAT" will now be described in connection with Figure 5. The MME takes into account the "supported codecs" from the UE, the "preferred codec for voice" received from the HSS within home network and network operator policies. At step 502 a check is first made whether the preferred codec for voice is supported by the CS domain of available target RANs (either GERAN or UTRAN 202 in Figure 2). If none of the available CS domains of target RANs support the preferred codec for voice then at step 506 a determination is made that no transcoding checking indicator (described in greater detail below) is to be sent to the MSC 210. Otherwise, at step 504 a check is made whether the UE 102 supports the preferred codec for voice in the CS domain. If not then the process passes to step 506 and then ends. If so, then at step 508 a check is made whether the preferred codec for voice is supported only by the UTRAN or by both UTRAN and GERAN. If only UTRA, then at step 510 an internal policy is checked regarding whether UTRA can be indicated as a target RAT. If not then the process passes to step 506 and then ends. If so, then at step 514 an indication is passed to the eNB 104 that the preferred target RAT for SRVCC is UTRA.

If the check at 508 reveals that both UTRAN and GERAN support the preferred codec for voice then at step 512 an internal network policy is checked regarding whether the preferred target RAT is UTRA, GERA or there is no preference. According to the result of that check, the process either passes to step 514, step 516 at which an indication is passed to the eNB 104 that the preferred target RAT for SRVCC is GERA or at step 518 it is determined that no preference should be indicated to the eNB 104, which should remain responsible for determining a network for SRVCC handover in accordance with prior art techniques. It will be appreciated that even if a RAT preference is sent to the eNB, selection of a RAN for SRVCC handover remains the responsibility of the eNB. In some embodiments the eNB may be free to override the RAT preference. At step 520 a transcoding checking indicator is passed to the MSC 210 as will be described in greater detail below.

The preferred target RAT may be a preference for SRVCC handover to UTRA or SRVCC handover to GERA. For example, the output from the decision process can be that the preferred target is UTRA to maintain WB-AMR or EVS in CS domain. Table 3 illustrates exemplary selections of preferred RATs in accordance with the first embodiment of the present invention. The first column indicates the codecs supported by the UE for CS voice as provided to the MME 114 by the UE 102 within an initial Attach message 408 (for instance). In each example in Table 3 the UE supports EVS, AMR-WB, and AMR. The second column indicates the preferred codec for voice parameter provided to the MME 114 by the home HSS 116 for that UE 102 in a ULA message 406. The third column indicates the policy of the network operator (which as discussed above may be the home network or may be a visited network). The third column indicates exemplary scenarios regarding which RAT is preferred (or if either is acceptable) for each possible preferred codec for voice received from the HSS 116. The fourth column indicates the preferred target RAT selected by the eNB 104 according to the logic of Figure 5 at

steps

514, 516 and 518 (including the option that no preferred target RAT parameter is passed to the eNB (step 518).

[Table 3]

As CS resources are reserved by the MSC 210, network operator policy implemented by the MME 114 is taken into consideration to decide the appropriate codec to be used after SRVCC transfer for the UE. At SRVCC handover procedure, the MME 114 sends the transcoding checking indicator to the MSC 210 at step 520, which will now be described in greater detail in connection with Figure 6.

Referring now to Figure 6, this illustrates actions performed at the MME 114 at the time of SRVCC handover. As noted at point 602, the MME has stored the preferred codec for voice received from the home HSS 116 for that UE 102 (referred to in Figure 6 as a subscribed codec for SRVCC. When handover is required the MME 114 receives a Handover Required message 604 from the eNB, which includes a SRVCC HO indication including the target RAN selected by the eNB 104 for SRVCC handover (which may be selected according to the preferred target RAT parameter passed to the eNB 104 by the MME 114 at

steps

514, 516 and 518 of Figure 5, or this may have been overridden by the eNB 104 according to other selection criteria). The MME 114 is therefore informed at point 606 that, according to one example, a 3G UMTS cell is selected by the eNB 104 for handover and the MME sends a transcoding checking indicator towards the MSC 210 associated with the target 3G cell in accordance with step 520 of Figure 5. This transcoding checking indicator is passed within a PS to CS Request message 608 which also includes a list of codecs supported by the UE (as is conventional).

In accordance with a first option, the transcoding checking indicator merely comprises a flag or other indication that the MSC should seek to determine an appropriate codec in order to minimise the risk of additional transcoding being required. Specifically, the MSC needs to determine the codec used for the most recently made active session at the IMS. Referring to Figure 7, this illustrates actions performed at the MSC at the time of SRVCC handover. As noted at point 706, the MSC 210 is now in receipt of the transcoding checking indicator which triggers the MSC to send a SIP OPTIONS request 708 to the ATCF 702 asking for voice media session capabilities. It will be understood that Figure 7 relates to an example in which the UE 102 is in a visited network, whereas if the UE 102 were in its home network the SIP OPTIONS request message 708 would be sent to the SCC AS of the home IMS network 206. The ATCF 702 communicates with the ATGW 704 using the H.248 protocol, though this communication and the role of each of the ATCF and the ATGW in providing the requested information is outside of the scope of the present invention.

At point 710 the ATCF 702 determines, in conjunction with the ATGW 704, finds the most recently made active IMS session and returns an SDP body containing codec information for that session. The ATCF 702 sends a SIP 200 OK message 712 containing in an SDP Body (Multipurpose Internet Mail Extension (MIME) type of application/SDP) the codec used for the most recently made active IMS session. The codec in the SDP Body is then selected by the MSC 210 at point 714 as the codec to offer to the IMS network 206 in an SIP INVITE (STN-SR) access transfer request message 716 to minimise the risk of the network having to perform additional transcoding. It will be understood that in accordance with the prior art the MSC 210 is required to select a codec to include in the access transfer request message 716 on the basis only of the list of codecs supported by the UE 102 and network operator policy, which greatly increases the chances of additional transcoding being required. This is illustrated in Figure 8 which shows the logic implemented by the MSC 210. At step 800 the MSC checks whether a transcoding checking indicator has been received. If so then at step 802 the negotiation with the ATCF or the SCC AS described in Figure 7 is performed to find out the codec currently in use for the most recently made active session. At step 804 access transfer is performed using the negotiated codec. If at step 800 it is determined that the MSC 210 has not received a transcoding checking indicator then at step 806 access transfer is performed by the MSC in accordance with the prior art.

In accordance with a second option, the transcoding checking indicator sent to the MSC by the MME may directly indicate the "preferred codec for voice" received from the HSS (and previously used to send a preferred target RAT indicator to the eNB). The MSC 210 may then proceed to send an access transfer request message 716 to the IMS network 206 containing the preferred codec for voice, thereby removing the need to send the SIP OPTIONS request message 708 to the ATCF/SCC AS to obtain the codec used for the most recently made active session.

It will be understood that both the first option and the second option of this embodiment of the present invention contrast with the prior art in which the MSC selects a codec with which to include in the SDP Offer to the IMS on the basis of no prior knowledge of what codec might be suitable (other than which codecs the UE supports).

The first embodiment of the present invention described above is based at least in part upon the MME indicating a "preferred target RAT" to the eNB and then sending a transcoding checking indicator to the MSC, based upon a "preferred codec for voice" for received from a home HSS. In contrast, in accordance with a second embodiment of the present invention, the MME takes these actions based upon the actual codec used for the voice media stream within the LTE network. This is based upon the MME being updated with the actual codec in use within the LTE network prior to SRVCC handover.

Similarly to the first embodiment of the invention, in accordance with the second embodiment of the present invention during an SRVCC procedure, the MME indicates a "preferred target RAT" to the eNB. To determine a "preferred target RAT" the MME takes into account the "supported codecs" from the UE, the "actual codec" currently in use within the LTE network and network operator policies. This determination is illustrated in Figure 9, which is broadly similar to Figure 5 described above.

The MME takes into account the "supported codecs" from the UE, the actual codec currently in use and network operator policies. At step 902 a check is first made whether the actual codec for voice is supported by the CS domain of available target RANs (either GERAN or UTRAN 202 in Figure 2). If none of the available CS domains of target RANs support the preferred codec for voice then at step 906 a determination is made that no transcoding checking indicator is to be sent to the MSC 210. Otherwise, at step 904 a check is made whether the UE 102 supports the actual codec in use within the LTE network in the CS domain. If not then the process passes to step 906 and then ends. If so, then at step 908 a check is made whether the actual codec in use is supported only by the UTRAN or by both UTRAN and GERAN. If only UTRA, then at step 910 an internal policy is checked regarding whether UTRA can be indicated as a target RAT. If not then the process passes to step 906 and then ends. If so, then at step 914 an indication is passed to the eNB 104 that the preferred target RAT for SRVCC is UTRA.

If the check at 908 reveals that both UTRAN and GERAN support the preferred codec for voice then at step 912 an internal network policy is checked regarding whether the preferred target RAT is UTRA, GERA or there is no preference. According to the result of that check, the process either passes to step 914, step 916 at which an indication is passed to the eNB 104 that the preferred target RAT for SRVCC is GERA or at step 918 it is determined that no preference should be indicated to the eNB 104, which should remain responsible for determining a network for SRVCC handover in accordance with prior art techniques. It will be appreciated that even if a RAT preference is sent to the eNB, selection of a RAN for SRVCC handover remains the responsibility of the eNB. In some embodiments the eNB may be free to override the RAT preference. At step 920, at the time of an SRVCC handover procedure, a transcoding checking indicator is passed to the MSC 210. In accordance with the second embodiment of the invention the transcoding checking indicator comprises the actual codec. As the MME knows the actual codec in use within the LTE network, it can directly influence the codec to be offered by the MSC. As for the second option of the first embodiment of the invention the MSC can proceed directly to sending an access transfer request to the IMS containing the actual LTE codec in the SDP Offer.

Table 4 illustrates exemplary selections of preferred RATs in accordance with the second embodiment of the present invention. The first column indicates the codecs supported by the UE for CS voice as provided to the MME 114 by the UE 102 within an initial Attach message 408 (for instance). In each example in Table 4 the UE supports EVS, AMR-WB, and AMR. The second column indicates the actual codec currently in use for an IMS voice bearer for that UE 102. The third column indicates the policy of the network operator (which as discussed above may be the home network or may be a visited network). The third column indicates exemplary scenarios regarding which RAT is preferred (or if either is acceptable). The fourth column indicates the preferred target RAT selected by the eNB 104 according to the logic of Figure 9 at

steps

914, 916 and 918.

[Table 4]

In accordance with the prior art, the MME (or the eNB) does not know the codec that is in current use within the LTE network. In order to provide this to the MME, every time the codec changes this must be signalled to the MME. In particularly, this may be signalled to the MME from the UE in NAS messaging. If the actual codec has changed during the life of a Quality of Service (QoS) Class Indentifier-1 (QCI-1) session (conversational voice EPS bearer), the MME can update the new "preferred target RAT" to the eNB via a new S1-AP message. This process is illustrated in Figure 10. At step 1002 the MME 114 determines whether the actual codec in use has been modified since the last update for a preferred target RAT sent to the eNB. If not then the process ends at step 1004. If so then at step 1006 a check is made whether the preferred target RAT needs to be modified. It may be that even though the currently used codec has changed, the selected target RAT according to the logic of Figure 9 has not changed, in which case the process ends at step 1004. If, however, a new preferred target RAT is determined then a new S1-AP message is sent to the eNB 104 at step 1008 to update the preferred target RAT.

The MME can be provided with the actual codec in current use in several different ways. A first option is for the UE to indicate the actual codec used to the MME via a NAS message as illustrated in Figure 11. This requires the IMS application in the UE to indicate the codec being associated with QCI-1 at the NAS layer. The codec in use is first determined through communication between the UE 102 and the P-CSCF 1102 through an SIP INVITE message 1104 and then an IMS establishment procedure as set out at point 1106. Then, the UE indicates the chosen codec to the MME in a NAS message 1108 (which could be any suitable existing NAS message or a new message. At point 1110 the MME stores the chosen codec as the currently used codec, which is used as described above. Point 1112 notes that it the codec is changed then the UE is required to provide an update to the MME using the same procedure.

A second option illustrated in Figure 12,

parts

1104 and 1106 of which being the same as for Figure 11. In accordance with the second option, during IMS session establishment, the P-CSCF 1102 indicates the codec used to a Policy and Charging Rules Function (PCRF) 1202 within the LTE network (not shown in Figure 2) via the Rx interface in PCC/Rx message 1204. The PCRF then indicates the actual codec in use to the MME via the Gx interface using General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTP-U) signalling in

messages

1206 and 1208. Similarly for the first option, the chosen codec is stored as the currently used codec by the MME at point 1210 and if the codec changes the update procedure is performed again at point 1212.

A third option illustrated in Figure 13,

parts

1104 and 1106 of which being the same as for Figure 11. During IMS session establishment, for the anchored voice session, the SCC AS indicates the selected codec to the HSS in a Sh Update message 1304 and the HSS notifies this to the MME in an IDR/IDA message 1306. Similarly for the first and second options, the chosen codec is stored as the currently used codec by the MME at point 1308 and if the codec changes the update procedure is performed again at point 1310.

Knowing the exact codec in used by MME allows the MME to choose a CS target RAT for SRVCC handover which will not require additional transcoding. At any time when the codec in use has changed during use of the same EPS bearer (QCI-1) (for instance, the UE places the first session on HOLD and start a second IMS session and the codec being used for the 2nd session is different than first) then the MME needs to be updated by either the UE, the PCRF or the HSS/IMS with the new codec information. This change of codec may result is a new preferred target RAT decision, and if so this will be indicated to eNB via a new S1-AP message. An example of this is shown in Figure 14 in which the UE requests service from the MME in message 1402. At point 1404 the MME selects a preferred RAT for SRVCC and this is communicated to the eNB in an Initial Context Set-up message 1406. If at point 1408, for whatever reason, that selection of a preferred target RAT changes, then the new S1-AP message 1410 is sent to the eNB.

As noted above, during an SRVCC procedure in accordance with the second embodiment of the present invention a transcoding checking indicator comprising the actual codec in use is sent to the MSC by the MME. Referring to Figure 15 this illustrates logic implemented by the MSC according to whether this is received, with a check being made at step 1502. If so, an access transfer request is sent to the IMS network at step 1504 using the actual codec. If not, then at step 1506 an access transfer request message is sent with the included codec being selected by the MSC in accordance with the prior art. In this respect if an actual codec in use is sent to the MSC according to the second embodiment of the present invention then this is similar to the second option of the first embodiment of the present invention in which the preferred codec for voice is sent to the MSC as the transcoding checking indicator. The operation of the MME at the time of SRVCC handover is generally the same as illustrated in Figure 6 in connection with the first embodiment of the present invention, substituting actual codec in use for the transcoding checking indicator as appropriate.

Advantageously, by determining the codec to be used on the target access in accordance with the first and second embodiments of the invention, this prevents or renders less likely the need for transcoding from the MSC/MGW or ATCF/ATGW to the IMS. The codec to be used on the target access may be determined by matching the supported codecs of the UE on CS access with a codec obtained by the MSC from the IMS (relating to the most recently made active IMS session), a preferred code for voice or the codec actually used in the LTE network. The "preferred codec for voice" can be determined by the operator by knowing the voice subscription of the user and the handset offered through the subscription. This then drives the intended codec for SRVCC to avoid the need for transcoding.

A further advantage of the present invention is that providing the ability for the visited network operator to drive the target RAT selection for SRVCC, the visited network operator is provided with the ability to support the preferred codec and thereby avoid the need for transcoding. Due to the logic on the MME, regarding the selection of a preferred target RAT, even where negotiation between the MSC and the ATCF/SCC AS is required, there is an increased likelihood of this negotiation yielding a codec that can be selected by the MSC to avoid transcoding.

As noted above, the majority of the embodiments described above concern a situation in which SRVCC handover is from an LTE network to GERA or UTRA. However, the present invention is not limited to this. SRVCC handover, and the handling of codecs to minimise transcoding, of a voice (or voice and audio) bearer from a PS network to a network operating a CS domain so that that the bearer is moved from the PS domain to the CS domain falls within the scope of the present application. As one further example, reference is now made to Figure 16 which illustrates the change of bearers from a PS HSPA domain to a CS GERA or UTRA domain. Voice over HSPA (VoHSPA) makes use of an IMS network and a HSPA enable UTRA network to provide PS voice services. It will be clear that there are similar circumstances to those described above in which transfer of a voice bearer to a CS domain will be required.

Figure 16 generally corresponds to Figure 2. Portions of Figure 16 common to Figure 2 will not be described again. The mechanisms for both LTE and HSPA SRVCC to a CS domain are broadly the same. the application of the above techniques can be mapped to the example of HSPA in Figure 16 by substituting the MME 114 with a first SGSN 1604 forming part of a HSPA enabled UMTS network. E-UTRAN 104 is replaced with a HSPA enabled UTRAN 1602. S/P-GW 110/112 are placed with a Gateway GPRS Support Node (GGSN) 1606. In the VoHSPA scenario of Figure 16 the SGSN 1604 is responsible for the functionality implemented by the MME 114 in Figure 2: determining a preferred RAT and communicating this to the HSPA enabled UTRAN 1602 across the lu-ps interface (in place of the S1-MME interface of Figure 2. The SGSN 1604 is also responsible for determining whether to send a transcoding checking indicator to the MSC 210, including through communication with the HSS 116 (across the Gr interface in place of the S6a interface).

Figure 16 is derived from 3GPP TS 23.216 regarding HSPA SRVCC architecture and the details of this and how this can be used to extend the examples given above for LTE will be readily apparent to the skilled person. It will be appreciated that similar modifications would be readily apparent to extend the present invention to SRVCC handover of a voice bearer from any PS domain to any CS domain.

It will be appreciated that embodiments of the present invention can be realized in the form of hardware, software or a combination of hardware and software. Any such software may be stored in the form of volatile or non-volatile storage, for example, a storage device like a ROM, whether erasable or rewritable or not, or in the form of memory, for example, RAM, memory chips, device or integrated circuits or on an optically or magnetically readable medium, for example, a CD, DVD, magnetic disk or magnetic tape or the like. It will be appreciated that the storage devices and storage media are embodiments of machine-readable storage that are suitable for storing a program or programs comprising instructions that, when executed, implement embodiments of the present invention. Accordingly, embodiments provide a program comprising code for implementing apparatus or a method as claimed in any one of the claims of this specification and a machine-readable storage storing such a program. Still further, such programs may be conveyed electronically via any medium including a communication signal carried over a wired or wireless connection and embodiments suitably encompass the same.

Throughout the description and claims of this specification, the words "comprise" and "contain" and variations of them mean "including but not limited to", and they are not intended to (and do not) exclude other components, integers or steps. Throughout the description and claims of this specification, the singular encompasses the plural unless the context otherwise requires. In particular, where the indefinite article is used, the specification is to be understood as contemplating plurality as well as singularity, unless the context requires otherwise.

Features, integers or characteristics described in conjunction with a particular aspect, embodiment or example of the invention are to be understood to be applicable to any other aspect, embodiment or example described herein unless incompatible therewith. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive. The invention is not restricted to the details of any foregoing embodiments. The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed. It will be also be appreciated that, throughout the description and claims of this specification, language in the general form of "X for Y" (where Y is some action, activity or step and X is some means for carrying out that action, activity or step) encompasses means X adapted or arranged specifically, but not exclusively, to do Y.

The reader's attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference...

The above embodiments are to be understood as illustrative examples of the invention. Further embodiments of the invention are envisaged. It is to be understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims.

Claims

A method of operating a network device in a mobile communications network including a first RAN having a Packet Switched, PS, domain and at least one target RAN having a Circuit Switched, CS, domain, the method comprising:

determining whether the CS domain of at least one target RAN supports a first codec; and

determining whether a mobile device supports the first codec for voice bearers in a CS domain;

wherein if the determination is that the CS domain of at least one target RAN and the mobile device support the first codec, the method further comprises sending, during Single Radio Voice Call Continuity, SRVCC, handover of a voice bearer from the PS domain of the first RAN to the CS domain of a selected target RAN supporting the first codec, a transcoding checking indicator to a mobility controller associated with the selected target RAN;

wherein the transcoding checking indicator is usable by the mobility controller to select a codec to include within an access transfer request directed to an Internet Protocol, IP, Multimedia Subsystem, IMS, with which the voice bearer is anchored.
A method according to claim 1, wherein the transcoding checking indicator is sent to a mobility controller associated with the selected target RAN only if the CS domain of the selected target RAN supports the first codec.
A method according to claim 1 or claim 2, wherein the first RAN comprises:

a Long Term Evolution, LTE, RAN; or

a High Speed Packet Access, HSPA, enabled Universal Terrestrial Radio Access Network, UTRAN.
A method according to claim 3, wherein if the first RAN comprises an LTE RAN the network device comprises a Mobility Management Entity, MME, associated with the LTE RAN; and

wherein if the first RAN comprises a HSPA enabled UTRAN the network device comprises a Serving General Packet Radio Service, GPRS, Support Node, SGSN, associated with the HSPA enabled UTRAN.
A method according to any one of the preceding claims, wherein if the at least one target RAN comprises an Enhanced data rates for GSM Evolution RAN, GERAN or a UTRAN the mobility controller comprises a Mobile Switching Centre, MSC, server.
A method according to any one of the preceding claims, wherein the first codec comprises a preferred codec for CS voice received from a Home Subscriber Server, HSS, associated with the mobile device.
A method according to claim 6, wherein the transcoding checking indicator comprises the preferred codec for CS voice; and

wherein the preferred codec for CS voice is arranged to be included within an access transfer request directed to an IMS with which the voice bearer is anchored by the mobility controller within the selected target RAN.
A method according to claim 6, wherein the transcoding indicator is arranged to instruct the mobility controller associated with the selected target RAN to obtain a codec used for the most recently made active IMS session.
A method according to any one of the preceding claims, wherein the at least one target RAN comprises a group of at least two target RANs operating according to different Radio Access Technologies, RATs, the method further comprising:

determining a preferred RAT according to whether each RAN in the group supports the first codec or in accordance with a network operator policy; and

sending an indication of a preferred RAT to a base station associated with the mobile device, the base station being responsible for selecting a target RAN from the group during a SRVCC procedure.
A method according to claim 9, wherein the determination of a preferred RAT is further in accordance with a network operator policy in the event that more than one RAN in the group supports the first codec.
A method according to claim 9 or claim 10, further comprising:

determining if the preferred RAT has changed if a network operator policy has changed; and

sending an updated indication of a preferred RAT to the base station associated with the mobile device if the preferred RAT has changed.
A method according to any one of the preceding claims, wherein the first codec comprises a currently used codec for the voice bearer within the PS domain of the first RAN.
A method according to claim 12, wherein the transcoding checking indicator comprises the currently used codec; and

wherein the currently used codec is arranged to be included within an access transfer request directed to an IMS with which the voice bearer is anchored by the mobility controller within the selected target RAN.
A method according to claim 12 or claim 13, further comprising receiving an indication of the currently used codec within a Non-Access Stratum, NAS, message from the mobile device.
A method according to claim 12 or claim 13, further comprising receiving an indication of the currently used codec from a Proxy Call Session Control Function, P-CSCF, within the IMS via Policy and Charging Control, PCC messaging.
A method according to claim 12 or claim 13, further comprising receiving an indication of the currently used codec from a HSS associated with the mobile device, the HSS having received an indication of the currently used codec from an Service Centralisation and Continuity Application Server, SCC AS, within the IMS.
A method according to any one of claims 12 to 16 when dependent on claim 9, further comprising:

determining if the preferred RAT has changed if the currently used codec has changed; and

sending an updated indication of a preferred RAT to the base station associated with the mobile device if the preferred RAT has changed.
A network device in mobile communications network including a first RAN having a Packet Switched, PS, domain and at least one target RAN having a Circuit Switched, CS, domain, wherein the network device is arranged to:

determine whether the CS domain of at least one target RAN supports a first codec; and

determine whether a mobile device supports the first codec for voice bearers in a CS domain;

wherein if the determination is that the CS domain of at least one target RAN and the mobile device support the first codec, the network device is further arranged to send, during Single Radio Voice Call Continuity, SRVCC, handover of a voice bearer from the PS domain of the first RAN to the CS domain of a selected target RAN supporting the first codec, a transcoding checking indicator to a mobility controller associated with the selected target RAN;

wherein the transcoding checking indicator is usable by the mobility controller to select a codec to include within an access transfer request directed to an Internet Protocol, IP, Multimedia Subsystem, IMS, with which the voice bearer is anchored.
A network device according to claim 18, wherein the network device is further arranged to implement the method of any one of claims 1 to 17.