WO2008023162A2

WO2008023162A2 - Methods for call continuity telecommunication systems

Info

Publication number: WO2008023162A2
Application number: PCT/GB2007/003182
Authority: WO
Inventors: David Fox; Gavin Wong; Christopher David Pudney
Original assignee: Vodafone Group Plc
Priority date: 2006-08-22
Filing date: 2007-08-21
Publication date: 2008-02-28
Also published as: GB0616660D0; WO2008023162A3

Abstract

Call continuity for a mobile terminal 1 in a telecommunications system having a packet switched domain and a circuit switched domain is provided by transferring a call from the packet switched domain (e.g. SAE/LTE or UMTS PS) to the circuit switched domain (e.g. GSM), and is characterised by establishing a cipher key for use in the circuit switched domain whilst the call is in the packet switched domain.

Description

CALL CONTINUITY IN TELECOMMUNICATION SYSTEMS

Technical Field

The present invention relates to a method of providing call continuity in a telecommunications system having a packet switched domain and a circuit switched domain.

Background to the Invention

Currently 2G (GSM), 2.5G (GPRS) and 3G (UMTS/UTRA) mobile or cellular telecommunications networks (PLMNs) co-exist. The original GSM system operated only in the circuit switched (CS) domain. GPRS added the packet switched (PS) domain to the GSM system. UMTS operates in both the CS and PS domains. A development of the radio access network part of 3G mobile telecommunications is "evolved" UTRA or E-UTRA, also referred to as LTE (Long Term Evolution). "System Architecture Evolution" (SAE) is the development of the core network part of 3G mobile telecommunications. The combined core network and radio network development is sometimes referred to as SAE/LTE. SAE/LTE operates only in the PS domain. It is desirable for mobile terminals to provide continuous service when moving from an SAE/LTE or UMTS PS coverage area to a 3G or 2G CS coverage area.

The third generation partnership project (3GPP) has recently defined a new concept known as IMS (IP - based Multimedia Subsystem) that operates in the PS domain. The aim of IMS is to allow users such as mobile telephone network operators to provide services to their subscribers as efficiently and effectively as possible. For example, the IMS architecture supports the following communication types: voice, video, instant messaging, "presence" (a user's availability for contact), location-based services, email and web. Further communication types are likely to be added in the future. This diverse collection of communication devices requires efficient session management due to the number of different applications and services that will be developed to support these communication types. The 3GPP have chosen Session Initiation Protocol (SIP) for managing these sessions.

The SIP protocol is designed to establish IP based communication sessions between two or more end points or users. Once a SIP session has been established, communication between these end points or users can be carried out using a variety of different protocols (for example those designed for streaming audio and video). The description of these protocols is carried within the SIP session initiation messages.

With IMS, users are no longer restricted to a separate voice call or data session. Sessions can be established between mobile devices that allow a variety of communication types to be used and media to be exchanged. The sessions are dynamic in nature in that they can be adapted to meet the needs of the end users. For example, two users might start a session with an exchange of instant messages and then decide that they wish to change to a voice call, possibly with video. This is all possible within the IMS framework. If a user wishes to send a file to another user and the users already have a session established between each other (for example, a voice session) the session can be redefined to allow a data file exchange to take place. This session redefinition is transparent to the end user.

In addition to the use of UMTS Radio Access Networks (UTRAN) to carry an IMS-based call, an IMS-based call may also be carried by alternative access networks, such as WLAN, fixed broadband connections and the like.

There are three distinct operational planes in the IMS architecture: the application plane, the control plane and the media plane. The application plane includes various application server types that are all SIP entities. These servers host and execute services.

The control plane handles session signalling and includes distinct functions to process the signalling traffic flow, such as Call Session Control Functions (CSCF), Home Subscriber Server (HSS), Media Gateway Control Function (MGCF) and Media Resource Function Controller (MRFC). Subscriber requested services are provided using protocols such as SIP and Diameter.

The media plane transports the media streams directly between subscribers.

IMS can be provided over a plurality of different bearers, such as UMTS PS, LTE/SAE and WLAN.

Mobile networks such as 2G (GSM) or 3G (UMTS) telecommunications networks have an active state of communication with their mobile terminals and an inactive/idle state of communication with their terminals. When in the active state, as the mobile terminals move between different cells of the network, the communication session is maintained by performing a "handover" operation between the cells.

Conventionally, the mobile terminal or network determines whether a handover procedure should be triggered in dependence upon measurements of the radio signals of the cells in the region of the mobile terminal. A filter is applied to the signals (either by the network or by the mobile terminal) which calculates an average (e.g. arithmetical mean) value of these signals over a particular time period. This filtered/average values of the cells are then compared with each other or with a threshold value. In dependence upon these comparisons, handover related procedures are triggered. This handover process generally comprises taking radio signal measurements of neighbouring cells and comparing these to each other and to the radio signal of the current cell to determine which cell provides the best signal strength/quality. Handover to the best cell can then occur.

A problem exists when the radio coverage available from a (PS) only LTE Radio Access Network (RAN) deteriorates and the best candidate for handover is a (CS only) GSM radio access network. No mechanism is currently defined to enable a voice call to continue during this type of handover without significant interruption of the voice traffic.

Terminals are known which switch between WLAN and GSM circuit switched domain. These terminals have two radios running simultaneously. The terminals when in WLAN detect when the WLAN signal diminishes and then begin searching for an appropriate GSM CS connection and hand over to the GSM CS connection at an appropriate time. However, the provision of two radios is an expensive and complex solution.

Summary of the Invention

According to a first aspect of the invention, there is provided a method of providing call continuity for a mobile terminal in a telecommunications system having a packet switched domain and a circuit switched domain, the method including transferring a call from the packet switched domain to the circuit switched domain, characterised by establishing a cipher key for use in the circuit switched domain whilst the call is in the packet switched domain.

The cipher key may be obtained from a telecommunication node used previously by the mobile terminal when in the circuit switched domain - for example the visited MSC that is attached to the target base station in the circuit switched domain.

The cipher key may alternatively be established by a packet switched domain node requesting the mobile to generate a cipher key. For example, the packet switched domain node may request the mobile terminal to generate the cipher key, which is specifically for use after a handover from the packet switched to the circuit switched domain. The node may be an MME or an SGSN. The establishment of the cipher key may be is triggered in response to a decision to hand the caller to the circuit switched domain, or triggered when the call is started in the PS domain.

In another embodiment the cipher key used in the circuit switched domain comprises the cipher key used in the packet switched domain. The cipher key is transmitted from a packet switched domain node to a circuit switched domain node. The packet switched domain node may be an MME or an SGSN, and the circuit switched domain node may be at least one of an MSC, RNC, BSC and BTS.

According to a second aspect of the invention, there is provided a method of providing for a mobile terminal call continuity in a telecommunications system having packet switched domain and a circuit switched domain, the method including transferring a call from the packet switched domain to the circuit switched domain, characterised by adapting authentication storage means associated with the mobile terminal to generate an additional cipher key for use when the call is handed over from the packet switched domain to the circuit switched domain.

A key corresponding to the cipher key may be transmitted from a packet switched domain node to a circuit switched domain node for use in the circuit switched domain, the corresponding keys being used to encrypt and decrypt communications and/or integrity protect communications between the mobile terminal and the circuit switched domain node. The packet switched domain node is an MME or an SGSN, and the circuit switched domain node may be at least one of an MSC, RNC, BSC and BTS. According to a third aspect of the invention, there is provided a method of providing call continuity for a mobile terminal in a telecommunications system having a packet switched domain and a circuit switched domain, the method including transferring a call from the packet switched domain to the circuit switched domain, characterised by establishing a cipher key for use in the circuit switched domain, which cipher key is derived from a further cipher key used in the packet switched domain and/or other parameters known by both the mobile terminal and the telecommunications system.

In this embodiment, the cipher key is established by using a key derivation function on the further cipher key and/or other parameters known by both the mobile terminal and the network. Alternatively, the cipher key is established by using a hash function on the further cipher key and/or other parameters known by both the mobile terminal and the network. Further alternatively, the cipher key is established by using a one-way function on the further cipher key and/or other parameters known by both the mobile terminal and the network.

The function is performed by both the mobile terminal and a packet switched domain node. The packet switched domain node may be an SGSN and/or MME.

According to a fourth aspect of the invention, there is provided a method of providing call continuity for a mobile terminal in a telecommunications system having a packet switched domain and a circuit switched domain, the method including transferring a call from the packet switched domain to the circuit switched domain, characterised by determining whether to perform the transferring step in dependence upon the nature of the packet switched connections between the mobile terminal of the telecommunications system, including said call. The determining step may evaluate the or each call included in said packet switched connections to determine the type of call, and may determine whether the or each call is predominantly a voice call, as opposed to a data call, video call, etc. The determining step may be performed by the S-CSCF, the P-CSCF or the PCRF.

In the various embodiments the packet switched domain may comprise LTE/SAE or UMTS - which may provide IMS. The circuit switched domain comprises GSM or UMTS.

Brief Description of the drawings

For a better understanding of the present invention embodiments will now be described by way of example, with reference to the accompanying drawings, in which:

Figure 1 is a diagrammatic drawing of key elements of a mobile telecommunications system for use in explaining the operation of such a system;

Figure 2 shows one example of the messages sent to move an IMS (PS) voice call to a GSM (CS) radio link;

Figures 3A, 3B and 3C are a flow chart showing the steps taken to generate and process the messages shown in Figure 2; and

Figure 4 shows an example of the messages sent to move the call back from GSM (CS) to IMS (PS).

In the drawings like elements are generally designated with the same reference sign. Description of embodiment of the Invention

Key elements of a mobile telecommunications system, and its operation, will now briefly be described with reference to Figure 1.

Each base station (BS) corresponds to a respective cell of its cellular or mobile telecommunications network and receives calls/data from and transmits calls/data to a mobile terminal in that cell by wireless radio communication in one or both of the circuit switched or packet switched domains. Such a subscriber's mobile terminal (or User Equipment-UE) is shown at 1. The mobile terminal may be a handheld mobile telephone, a personal digital assistant (PDA), a laptop computer equipped with a datacard, or a laptop computer with an embedded chipset containing the UE' s functionality.

In a GSM (2G) mobile telecommunications network, each base station subsystem (BSS) 3 comprises one or more base transceiver stations (BTS) 8 and a base station controller (BSC) 4. A BSC may control more than one BTS. The BTSs and BSCs comprise the GSM radio access network (RAN).

In a UMTS (3G) mobile telecommunications network, each Radio Network Subsystem (RNS) 7 comprises a Radio Network Controller (RNC) 13 and one or more base stations, called Node B's 6. An RNC may control more than one Node B 6. The Node B's and RNCs comprise the UMTS radio access network

(RAN).

Conventionally, the base stations are arranged in groups and each group of base stations is controlled by one mobile switching centre (MSC), such as MSC 2 for base stations in BSSs 3, 54 and 5. As shown in Figure 1, the network has another MSC 6, which is controlling a further two BSSs 9 and 15 and one RNS 7. In practice, the network will incorporate many more MSCs and base stations than shown in Figure 1. Each subscriber to the network is provided with a smart card or SIM which, when associated with the user's mobile terminal identifies the subscriber to the network. The SIM card is pre-programmed with a unique identification number, the "International Mobile Subscriber Identity" (IMSI) which is not visible on the card and is not known to the subscriber, and also a unique key, Ki. The subscriber is issued with a publicly known number, that is, the subscriber's telephone number, by means of which calls to the subscriber are initiated by callers. This number is the MSISDN.

The network includes a home location register (HLR)/home subscriber server (HSS) 10 which, for each subscriber to the network, stores the IMSI and the corresponding MSISDN together with other subscriber data, such as the current or last known MSC of the subscriber's mobile terminal. The HSS is the master database for the network, and while logically it is viewed as one entity, in practice it will be made up of several physical databases. The HSS holds variables and identities for the support, establishment and maintenance of calls and sessions made by subscribers. As well as the basic HLR/authentication functions, the HSS may be enhanced through the use of additional databases and reference points. This enables the network to offer the subscriber advanced services and features by interfacing with service application servers based on CAMEL, OSA (Open Service Access) and SIP.

When the subscriber wishes to activate their mobile terminal in a network (so that it may make or receive calls subsequently), the subscriber places their SIM card in a card reader associated with the mobile terminal (terminal 1 in this example). The mobile terminal 1 then transmits the IMSI (read from the card) to the BTS 8 associated with the particular cell in which the terminal 1 is located. In a traditional network, the BTS 8 then transmits this IMSI to the , MSC 2 with which the BSS 3 is associated. In a network using the functionality described in 3GPP TS 23.236, the BSS follows prescribed rules to select which MSC to use, and then transmits this IMSI to the selected MSC. MSC 2 now accesses the appropriate HLR/HSS 10 and extracts the corresponding subscriber MSISDN and other subscriber data from the appropriate storage location, and stores it temporarily in a location in a visitor location register (VLR) 14. In this way, therefore the particular subscriber is effectively registered with a particular MSC (MSC 2), and the subscriber's information is temporarily stored in the VLR (VLR 14) associated with that MSC. The information stored on the VLR 14 includes a Temporary Mobile Subscriber Identification (TMSI) number for identification purposes for the terminal within the MSC 2. The TMSI number is an identification number that is typically 32 bits in length. In conventional systems, therefore, the TMSI number is not allocated to more than one user of a given system served by that MSC at one time. Consequently, the TMSI number is usually invalidated when the mobile station crosses into a new location served by a different MSC.

When the HLR 10 is interrogated by the MSC 2 in the manner described above, the HLR 10 additionally causes an authentication procedure to be performed on the mobile terminal 1. The HLR 10 transmits an authentication request comprising the subscriber identity (IMSI) to an AUC (authentication centre) for deriving authentication vectors (AVs). Based on the IMSI, the AUC generates a challenge, which is a random number, or obtains a stored challenge based on the IMSI, Also, the AUC generates an XRES (expected result), based on the challenge and a secret shared with the SIM, or obtains an XRES stored with the challenge.. The XRES is used to finalise the authentication. In a UMTS network, the AUC also generates an IK (integrity key) based on the shared secret and the challenge, which can be stored together with the XRES and the authentication data at the AUC and used for integrity checking messages sent between the mobile terminal 1 and the RNC.

The authentication data, XRES and CK/IK, are then transmitted to the MSC 2, which transmits the authentication challenge to the mobile telephone 1. The mobile telephone 1 generates a response by transmitting the authentication data to the SIM/USIM of the mobile telephone 1. The SIM/USIM generates, based on the Ki of the subscription stored on the SIM/USIM and the authentication challenge, a response corresponding to the XRES stored in the server.

For finalising the authentication according to SIM/USIM authentication the MSC 2 compares the response value with the value of the stored XRES for authentication control.

If the response from the mobile terminal 1 is as expected, the mobile terminal 1 is deemed authenticated. At this point the MSC 2 requests subscription data from the HLR 10. The HLR 10 then passes the subscription data to the VLR 14.

As part of the authentication process a cipher key CK for encrypting user and signalling data on the radio path is also established. This procedure is called cipher key setting. The key is computed by the mobile terminal 1 using a one way function under control of the key Ki and is pre-computed for the network by the AUC. Thus at the end of a successful authentication exchange both parties possess a fresh cipher key CK.

The authentication process will be repeated while the mobile terminal 1 remains activated and can also be repeated each time the mobile terminal makes or receives a call, if required.

Each of the MSCs of the network (MSC 2 and MSC 6) has a respective VLR (14 and 11) associated with it and operates in the same way as already described when a subscriber activates a mobile terminal in one of the cells corresponding to one of the base stations controlled by that MSC. When the subscriber using mobile terminal 1 wishes to make a call, having already inserted the SIM card into the reader associated with this mobile terminal and the SIM has been authenticated in the manner described, a call may be made by entering the telephone number of the called party in the usual way. This information is received by the BSS 3 and passed on to the MSC 2. The MSC 2 routes the calls towards the called party via the MSC 2. By means of the information held in the VLR 14, MSC 2 can associate the call with a particular subscriber and thus record information for charging purposes.

As described in the 3GPP Release 4 set of Specifications, the MSC 2 can be split into an MSC-Server (MSC-S) and Media GateWay (MGW).

The MSCs 2 and 6 support communications in the circuit switched (CS) domain - typically voice calls. Corresponding SGSNs 16 and 18 are provided to support communications in the packet switched (PS) domain - such as GPRS data transmissions. The SGSNs 16 and 18 function in an analogous way to the MSCs 2 and 6. The SGSNs 16, 18 are equipped with an equivalent to the VLR for the packet switched domain. GGSN 19 provides IP connectivity to the internet and/or private intranets.

When mobile terminal 1 attaches to the network, the SGSN 16 checks data transmitted from the SIM with data retrieved from the HLR/HSS 10 in order to authenticate the mobile terminal, in the manner described above in relation to the MSC 2. The transmission of PS data is then authorised by using the Access Point Name (APN) to help select a GGSN and activating a PDP context. The SGSN may provide the APN to a DNS server, and the DNS server may then return a list of GGSNs. The SGSN 16 sends a request for a PDP context to the GGSN 19. The GGSN 19, or an associated server, provides an appropriate IP address to the mobile terminal 1.. When switched on, a mobile terminal has an active mode and an idle mode. In the GPRS specifications, the idle mode is referred to as the "standby" mode; the active mode is referred to as the "ready" mode; and GPRS-idle means that the terminal is switched off. In 3G the idle mode is referred to as the "PMM idle" mode and the active mode is referred to as the "PMM connected" mode. In LTE the idle mode is referred to as the "LTE idle" mode and the active mode is referred to as the "LTE active" mode.

Elements of an LTE network are shown in Figure 1. The base stations 20,22 and 24 comprise an eNodeB (evolved Node B) 26. The RRC signalling with the mobile terminal 1 terminates at the eNodeB 26. The eNode Bs form the RAN of the LTE network. The eNodeB 26 performs the functions of both the Node B and a large part of the RNC of the 3G/UMTS network. The network core 28 of the LTE network includes Serving Gateway (S-GW) 29, PDN Gateway (P-GW) 30, the HLR/HSS 10 (a common HLR/HSS shared with the network core 12 of the GSM/UMTS network) and also Mobility Management Entity (MME) 32.

Although shown separately in Figure 1, the P-GW 30 and GGSN 19 may be combined to form a single element.

Both the GSM/UMTS and LTE networks can communicate with an external packet data network PDN 34.

Communications between the mobile terminal 1 and the network cores 12, 28 can be considered to be split into a control plane and a user plane. The control plane performs the required signalling, and includes the relevant application protocol and the signalling bearer for transporting the application protocol messages. Among other things, the application protocol is used for setting up the radio access bearer in the radio network layer. The user plane transmits data traffic and includes data streams and data bearers for the data streams. The data streams are characterized by one or more frame protocols specified for that interface. Generally speaking, the user plane carries data for use by a receiving terminal - such as data that allows a voice or picture to be reproduced - and the control plane controls how the data is transmitted.

In the IMS control plane, the terminal 1 communicates, via the relevant radio access network initially with the proxy-CSCF (P-CSCF) 40. The P-CSCF 40 ensures that SIP registration messages are passed to the correct home network core and that SIP session messages are passed to the correct serving - CSCF (S-CSCF) 42 once registration of the terminal has occurred. The user is allocated a P-CSCF 40 as part of the registration, and provides a two-way IPsec association with the device 1. All signalling traffic traverses the P- CSCF 40 for the duration of a SIP communication session.

The S-CSCF 42 interacts with the HSS 10 to determine user service eligibility from a user profile. The S-CSCF 42 is allocated for the duration of the registration.

The S-CSCF 42 is always in the home network core of the terminal. The P- CSCF 40 may be in the home network or in a visited network core. In this embodiment both the P-CSCF 40 and S-CSCF 42 are in and shared by the network cores 12 and 28.

Control plane signalling and the media plane signalling follow different paths, as indicated above. As mentioned earlier, the current IMS security architecture in TS 33.203 protects the IMS control plane only. It is assumed that the media plane is secure.

Briefly, the control plane security is provided by the S-CSCF 42 running SIM- based authentication and key agreement with the IMS client present on the mobile terminal 1. A session key is passed to the P-CSCF 40 and used to integrity and confidentiality protect signalling between the terminal 1 and the P-CSCF 40 using IPsec. Optionally, IPsec with UDP encapsulation may be used for IMS access over non-cellular access where a network address translator (NAT) may be present.

3GPP specifies the use of IPsec, and specifies a public key infrastructure (PKI) based key management solution for establishing IPsec between IMS cores. The use of transport layer security (TLS) is also possible.

From the description above, it will be understood that the coverage area of a mobile telecommunications network is divided into a plurality of cells, each of which is served by a respective base station.

A mobile terminal has an active mode and an idle/inactive mode. In the idle/inactive mode a mobile terminal "camps" on what is determined to be the best cell. As the mobile terminal moves around, the best cell changes and cell reselection is performed by the mobile terminal to change the cell on which the mobile terminal is camped.

When a calling party (whether a subscriber within the mobile telecommunications network or outside it) attempts to call a mobile terminal within the network, that mobile terminal must be paged. Paging is a process of broadcasting a message which alerts a specific mobile terminal to take some action - in this example, to notify the terminal that there is an incoming call to be received.

Having just discussed the idle/inactive mode, the active mode will now briefly be discussed. In the active mode, in order to allow a mobile terminal to maintain a call when the mobile terminal moves outside the coverage area of a cell, the call must be switched to an alternative cell automatically. This process is referred to as "handover". Handover is a time critical process requiring action to be taken before the radio link with the original cell degrades to such an extent that the call is lost. Handover requires synchronisation of events between the mobile terminal and the network.

Network-driven handover in UMTS is performed when necessary, as described in 3GPP TS 25.331. In this state a mobile terminal scans the pilot channels of up to 32 intra-frequency cells neighbouring its current cell. The mobile terminal forms a list of the best cells for possible handover based on the received signal strength and/or quality (i.e. the error rate in the received signal). The information in this list is passed to the UTRAN RNC 13 on an event- driven basis, e.g. when the signal strength or signal-to-noise ratio of one of the cells exceeds a threshold. The information list is used by a handover algorithm implemented in the UTRAN RNC 13. The algorithm that determines when handover occurs is not specified in the GSM or UMTS Standards. The algorithms essentially trigger a handover when the mobile terminal 1 provides a measurement of a neighbour cell received signal at the mobile terminal 1 above a predetermined quality received threshold, which typically has a relation to the quality of the received signal from the serving cell (e.g. better quality by some margin).

The embodiment now to be described in detail provides "single radio" Voice Call Continuity from PS domain to GSM (CS domain). By "single radio" it is meant that the mobile terminal has only a single radio transceiver. The embodiment enables a call in the PS domain comprising predominantly voice data to be handed over automatically to the GSM CS domain.

The mechanism may be extended to also allow the mobile to return to the PS domain when suitable coverage is available. Figure 2 shows an example of the main data exchanges involved in the movement of an IMS voice call over LTE to a GSM Circuit Switched radio link, and the flow chart of Figures 3A, 3B and 3C shows the steps taken.

With obvious changes, the message flow is also applicable to IMS voice over UMTS Packet Switched domain moving to GSM CS (these changes are indicated in parentheses). This flow can also be applied to WLAN (e.g. with suitably adapted PDG).

The 3GPP Anchor 45 is a combined S-GW 29, P-GW 30 and Anchor MGW.

Step A: When the P-CSCF 40 detects an IMS session that is a "candidate for Voice Call Continuity (VCC)" to the Circuit Switched domain, it passes an indication in message 1 to the Policy and Charging Rules Function (PCRF) 44. In turn the PCRF 44 passes this indication to the P-GW 30 which passes it on to the S-GW 29. Subsequently, this indication is passed to the eNodeB 26 (in LTE or in UMTS to the RNC 13), either directly or via the MME 32 (in LTE or in UMTS, via the SGSN).

Given that the IMS voice session might be one of several IMS sessions with that UE 1, the decision that the combination of sessions is (or is not) a "candidate for Voice Call Continuity" may need to originate from the S-CSCF 42 and possibly involve information stored at the HSS 10 and/or processing in application servers. Whether or not a call is a candidate for voice call continuity might depend upon whether the call is predominantly a voice call (as opposed to a data call, video call, etc.).

In other deployment scenarios, the PCRF 44 might make the decision that the call is a "candidate for VCC" without interaction with the P-CSCF 40. At point 2 in figure 2, while the IMS voice session is ongoing, voice data is exchanged in the RTP streams. These RTP streams flow between UE 1 and P- GW 30 passing through eNodeB 26 and S-GW 29. These RTP streams do not go through MSC-Server/MGW 2 or MME 32.

Step B: When the eNodeB 26 (or UMTS RNC 13) receives the "candidate for VCC" indication from the core network 28, the eNodeB 26 (or UMTS NodeB 6) can - e.g. dependent upon whether there are any GSM cells in the neighbourhood - include the GSM cells into the 'neighbour cell lists' which it sends to the UE 1. The absence of the "candidate for VCC" indication may be used by the eNodeB 26 to exclude GSM cells from the 'neighbour cell lists', and this may improve LTE to LTE handover performance.

Step C: The UE 1 sends Measurement Report messages to report the local radio environment to the eNodeB 26 in message 3.

Step D: It is determined whether the Measurement Reports sent by the UE 1 (and other information available in the eNodeB 26 - e.g. received UE 1 signal quality, eNodeB 26 load, etc) indicate that the best way to maintain the voice call is to perform a handover to a GSM cell.

Step E: If it is determined that handover to a GSM cell (especially a GSM cell that does not support EDGE and/or DTM) should be performed, then the eNodeB 26 constructs a "Handover Required to CS" message 4 and sends this to the MME 32. This "Handover Required to CS" message 4:

- informs the MME 32 of the address of the target cell and/or target RAN node (e.g. BTS 8/RNC 13);

- informs the MME 32 that this is a handover towards the CS domain

- requests the MME 32 to pass the "container of information" to the target RAN node - contains "handover cause" information

- etc.

Step F: When the MME 32 receives the "request to handover to the CS domain" message 4 it takes on the role of an anchor MSC-server in "basic inter-MSC handover" as described in TS 23.009 (which is fully incorporated herein by reference). In TS 23.009, the anchor MSC is called the "controlling MSC" and is often denoted as "MSC-A".

In order to undertake this task, the MME 32 needs some specific information, e.g. IMSI, and more specifically, the "current" CS domain security context (e.g. Cipher Key (CK), Cipher Key Sequence Number (CKSN), and if handing over to UMTS CS, also the Integrity Key (IK). The MME 32 needs the IMSI, but this can be supplied by the HSS as part of the basic subscription information.

There are several methods by which a CS domain CK could be obtained:

a) interrogation of visited MSC (as shown in the signalling flow of Figure 2) Using the IMSI, the MME 32 can request CK, CKSN and IK (with a new message) from the visited MSC 2 attached to the target BSC 4 (in the expectation that the mobile is attached to that MSC 2) - message 5. The CK, CKSN and IK are those used by the visited MSC last time the UE 1 was in the CS domain. This process will not always be successful (e.g. the mobile 1 might have travelled into a new MSC area; or the UE 1 might have been purged from that MSC 2; or the BSC 4 might be using "A-flex" (see TS 23.236) and the mobile might be attached to another MSC within the pool area), in which case, the MME 32 can use the IMSI to interrogate the HSS 10 to identify the visited MSC 2 (if one exists). Once the visited MSC 2 has been identified, then the MME 32 can obtain the current security context. Even with these steps, there remains the risk that the security contexts in visited MSC 2 and UE 1 are not aligned (e.g. if, since the last successful location update with the visited MSC 2, the UE 1 was rejected by a different PLMN and then returned to LTE-only coverage).

The reply from the visited MSC 2 is sent in message 6.

b) dummy CS domain authentication during handover preparation When the MME 32 receives the "request to handover to the CS domain" message 4 from the eNodeB 26, the MME 32 could initiate a "dummy CS domain authentication" with the UE 1.

In order to do this, the MME 32 would retrieve a CS domain authentication vector from the HSS 10 and then send a "CS domain authentication request" to the UE 1 over the PS connection. As a result of this, the UE 1 generates CK and IK for use in the CS domain after the handover - but the UE 1 is constructed to NOT store these keys on the (U)SIM.

Submitting a request to generate keys to the SIM does not normally cause the keys to be stored on the SIM, hence any existing CS domain keys ought not to be overwritten. However, if other varieties of UICC card work in a different fashion, the MME 32 could allocate the CKSN to the value that is understood by all MSCs as "no key is available in the MS". This avoids mis- synchronisation between UE 1 and MSC in a later pure-CS domain call establishment.

This process does involve the consumption of authentication vectors and risks that, upon return to the CS domain, 'AUTN mis-synchronisation' is detected. However existing Release 99 functionality can be used to resolve this. The primary disadvantage of this approach is that it requires message exchange with the mobile during a "last resort handover", e.g. when the radio conditions are potentially very poor. (Note that GSM Handover Commands were optimised so that GSM handover can succeed even if the uplink from the mobile 1 has been lost).

c) dummy CS domain authentication at "call set up "

This is similar to (b) above, except that the CS domain authentication is performed when the "candidate for VCC" call is set up.

This avoids the problems with authenticating a mobile 1 on a degrading radio channel. However, it requires the MME 32 to perform an extra 'authentication on every call' or the development of a mechanism to store the CS domain keys and maintain their synchronism with the UE 1.

d) re -use of PS domain key in the CS domain

At least while using UMTS PS, the SGSN 16 and UE 1 can derive the CK to use on the GSM PS domain (when using LTE, similar functionality is anticipated to exist in the MME 32). From a signalling and connectivity perspective, this GSM PS domain cipher key could be signalled by the MME 32 to the relay MSC (in TS 23.009, the relay MSC is denoted MSC-B) and on to the BSC and BTS for use on the CS connection.

However, this method may raise security concerns.

e) generation of extra key at PS domain authentication

Currently, when the mobile terminal 1 passes an Authentication Challenge into the UICC, several security keys are generated (which match the ones contained in the authentication vectors sent from the HSS 10 to the SGSN 16/MME 32). This could be extended so that other keys can be generated by the UICC - one of these could be a "VCC-only CS domain key". The UE uses this key after handover and it would match the one sent from the HSS 10 to the SGSN 16/MME 32 (and onto the relay MSC which in turn sends it to the BSS) for this purpose.

This approach appears promising, but, this requires a new UICC. However the generation of LTE keys probably also requires a new UICC - and 'backwards compatibility' mechanisms to use old UICCs are likely to be specified.- see (f) below.

f) hash function in UE.

This is a complement to (e) above, wherein the mobile terminal 1 uses a "hash function" on the PS domain key(s) generated by the USIM to generate a "VCC- only CS domain key".

The SGSN 16/MME 32 implements the same "hash function" on the authentication vector received from the HSS 10 to generate the "VCC-only CS domain key". The SGSN 16/MME32 sends this "VCC-only CS domain key" onto the relay MSC which in turn sends it to the BSS.

One extra issue that is common to (b) to (f) above is that, for handover from UMTS-PS VoIP to GSM CS, there is a technical possibility that, while in UMTS, the mobile 1 might have a CS connection active at the same time as the PS connection. This situation is obvious to the RNC 13, and can lead to either the RNC 13 abandoning the UMTS CS domain connection, or, to the RNC 13 instructing the MME 32 to follow a different procedure .

Step G: Once the Cipher Key (and for a UMTS CS domain target cell, IK) has been determined, the MME 32 includes them in the Prepare Handover Request message 7 to the relay MSC server - (MSC-S/MGW) 2. Step H: (Messages 8, 9, 10) Normal handover processing (the target

GSM BSS 3 and MSC-S/MGW 30 are unaware that this is a PS to CS handover).

Step I: (Messages 11, 12) The MME 32 treats the S-GW 29 as a MGW and organizes connections from the S-GW/MGW 29 (45) to the MGW associated with the relay MSC-S 2. On the downlink, bicasting of the user plane data may be enabled.

Step K: (Message 13) the MME 32 sends the Handover Command to the eNodeB 26.

Step L: The eNodeB 26 sends the handover instruction to the UE 1

Step M: The handover message that is sent to the UE 1 instructs the UE 1 to move from PS domain to CS domain, and instructs the UE to use the correct Cipher Key. The eNodeB 26 encodes the message so that the LTE UE 1 is able to distinguish this "handover to CS domain" command from the more usual "handover within PS domain" commands. The UE 1 accesses the target cell and Handover Complete messages are sent through the relay MSC 2 to the MME 32 (messages 14 and 15).

Step N: (Message 16a) the MME 32 tells the S-GW/MGW 29 (45) to activate the user plane and to inform (via the P-GW 30) the PCRF 44.

Step O: (Message 16b) the old radio resources are released.

Step P: If the handover fails, the MME 32 informs the S-GW/MGW 29

(45) and steps Q to U are not performed. Step Q: (message 17) the S-GW/P-GW 29/30 (45) informs the PCRF 44 that the IMS voice call is now "terminating" on the S-GW 29.

Step R: the S-GW 29 provides the PCRF 44 with an IP address/port to which the UE 1 related SIP signalling can be addressed.

Step S: (message 18) the PCRF 44 passes this information to the P-

CSCF 40. Message 19 acknowledges completion of steps Q, R and S.

Step T: (message 20) the P-CSCF 40 registers with the S-CSCF 42 on behalf of the UE 1. This step is only required if the IMS registration cannot be maintained after the handover has occurred. (The eNodeB 26 and/or MME 32/SGSN 16 knows from the combination of UE 1 classmark information and the GSM cell/BSS Dual Transfer Mode capability whether or not IMS registration can be maintained. This information is passed from the MME 32 to the PCRF 44 and onto the P-CSCF 40.)

Step U: (message 21) the P-CSCF 40 sends a re-invite to the S-CSCF 42 to provide the IP address/port provided by the S-GW/MGW 29(45) such that the voice data can be sent to the S-GW/MGW 29(45) instead of the UE 1.

Note that the UE ldoes not release the PDP context.

The subsequent handover of the VCC call back from GSM CS to LTE VoIMS will now be briefly described with reference to Figure 4 which shows the main steps involved in the movement of VCC call back from GSM CS to an IMS voice call over LTE.

With obvious changes, the message flow is also applicable to movement form GSM CS to IMS voice over UMTS PS. Messages 1, 2: normal inter-MSC handover preparation. For this case, the BSC 4 needs to be aware that the target cell is an LTE or UMTS cell, and for a UMTS target cell, to be able to decide whether to perform CS-CS handover or CS-PS handover.

Message 3: the MME 32 retrieves its internally stored PS domain keys and sends the Handover request to the eNodeB 26.

Message 4: the eNodeB 26 formats the handover command and returns it to the MME 32. (With a UMTS nodeB, the UE is instructed to use the PS domain by the UMTS RNC.)

Messages 5, 6: the MME 32 instructs the S-GW/MGW 29(45) to prepare for the domain switch handover (e.g. by bicasting the downlink user plane data).

Messages 7, 8: the handover proceeds

Message 9: the MME 32 instructs the S-GW/MGW 29(45) to use the

PS domain uplink user data, and to inform the PCRF 44 that the UE 1 has returned.

Messages 10, 11: old radio resources are released and the improved QoS bearer is established on the LTE side.

Message 12: at any time after message 8 is sent the UE 1 sends a re- invite to the P-CSCF 40, and the P-CSCF 40 contacts the S-CSCF 42. This moves the user plane termination to the UE 1.

Claims

1. A method of providing call continuity for a mobile terminal in a telecommunications system having a packet switched domain and a circuit switched domain, the method including transferring a call from the packet switched domain to the circuit switched domain, characterised by establishing a cipher key for use in the circuit switched domain whilst the call is in the packet switched domain.

2. The method of claim 1, wherein the cipher key is obtained from a telecommunication node used previously by the mobile terminal when in the circuit switched domain.

3. The method of claim 2, where the node is an MSC.

4. The method of claim 1, wherein the cipher key is established by a packet switched domain node requesting the mobile to generate a cipher key.

5. The method of claim 4, wherein the packet switched domain node requests the mobile terminal to generate the cipher key, which is specifically for use after a handover from the packet switched to the circuit switched domain.

6. The method of claim 4 or 5, where the node is an MME or an SGSN.

7. The method of claim 4,5 or 6, wherein the establishment of the cipher key is triggered in response to a decision to hand the caller to the circuit switched domain.

8. The method of claim 4,5 or 6, wherein the establishment of the cipher key is triggered when the call is started in the PS domain.

9. The method of claim 1, wherein the cipher key used in the circuit switched domain comprises the cipher key used in the packet switched domain.

10. The method of claim 9, wherein the cipher key is transmitted from a packet switched domain node to a circuit switched domain node.

11. The method of claim 9, wherein the packet switched domain node is an MME or an SGSN.

12. The method of claim 9,10 or 11, wherein the circuit switched domain node is at least one of an MSC, RNC, BSC and BTS.

13. A method of providing for a mobile terminal call continuity in a telecommunications system having packet switched domain and a circuit switched domain, the method including transferring a call from the packet switched domain to the circuit switched domain, characterised by adapting authentication storage means associated with the mobile terminal to generate an additional cipher key for use when the call is handed over from the packet switched domain to the circuit switched domain.

14. The method of claim 13, wherein a key corresponding to the cipher key is transmitted from a packet switched domain node to a circuit switched domain node for use in the circuit switched domain, the corresponding keys being used to encrypt and decrypt communications and/or integrity protect communications between the mobile terminal and the circuit switched domain node.

15. The method of claim 14, wherein the packet switched domain node is an MME or an SGSN.

16. The method of claim 14 or 15, wherein the circuit switched domain node is at least one of an MSC, RNC, BSC and BTS.

17. A method of providing call continuity for a mobile terminal in a telecommunications system having a packet switched domain and a circuit switched domain, the method including transferring a call from the packet switched domain to the circuit switched domain, characterised by establishing a cipher key for use in the circuit switched domain, which cipher key is derived from a further cipher key used in the packet switched domain and/or other parameters known by both the mobile terminal and the telecommunications system.

18. The method of claim 17, wherein the cipher key is established by using a key derivation function on the further cipher key and/or other parameters known by both the mobile terminal and the network.

19. The method of claim 17, wherein the cipher key is established by using a hash function on the further cipher key and/or other parameters known by both the mobile terminal and the network.

20. The method of claim 17, wherein the cipher key is established by using a one-way function on the further cipher key and/or other parameters known by both the mobile terminal and the network.

21. The method of claim 17,18,19 or 20, wherein the function is performed by both the mobile terminal and a packet switched domain node.

22. The method of claim 21, wherein the packet switched domain node is an SGSN and/or MME.

23. A method of providing call continuity for a mobile terminal in a telecommunications system having a packet switched domain and a circuit switched domain, the method including transferring a call from the packet switched domain to the circuit switched domain, characterised by determining whether to perform the transferring step in dependence upon the nature of the packet switched connections between the mobile terminal of the telecommunications system, including said call.

24. The method of claim 23, wherein said determining step evaluates the or each call included in said packet switched connections to determine the type of call.

25. The method of claim 24, wherein it is determined whether the or each call is predominantly a voice call.

26. The method of claim 23, 24 or 25 wherein the said determining step is performed by the S-CSCF.

27. The method of claim 23, 24 or 25 wherein the said determining step is performed by the P-CSCF.

28. The method of claim 23, 24 or 25 wherein the said determining step is performed by the PCRF.

29. The method of any one of claim 1 to 28, wherein the packet switched domain comprises LTE/SAE.

30. The method of any one of claims 1 to 29, wherein the packet switched domain comprises UMTS.

31. The method of any one of claims 1 to 30, wherein the packet switched domain comprises IMS.

32. The method of any of claims 1 to 31, wherein the circuit switched domain comprises GSM.

33. The method of any of claims 1 to 32, wherein the circuit switched domain comprises UMTS