GB2434058A

GB2434058A - Network capability to transmit voice information via a packet switched network portion

Info

Publication number: GB2434058A
Application number: GB0600410A
Authority: GB
Inventors: Craig Kelvin Bishop; Chen-Ho Chin; Gert-Jan Van Lieshout
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2006-01-10
Filing date: 2006-01-10
Publication date: 2007-07-11
Anticipated expiration: 2026-01-10
Also published as: GB0600410D0; GB2434058B

Abstract

A method of signalling information between a mobile station and a serving network element of a mobile communications network, wherein the network element transmits information to the mobile terminal relating to the networks capabilities to transmit voice information via a packet switched network portion.

Description

Mobile Communications The present invention relates to mobile

communications devices and systems. More particularly, but not exclusively, the invention relates to transmitting information relating to the network's capabilities to transmit voice information via a packet switched network portion, to voice call continuity services andlor transmitting information relating to the terminal's capability to support.

Outline description of VCC and its associated call origination procedures The 3GPP Voice Call Continuity service provides the capability to transfer the path of a voice call between CS and IMS domains, and vice versa.

The service assumes an UE capable of supporting two separate call legs related to the same voice communication (one over the CS domain and one over the IMS). In order to facilitate the transfer of calls between domains, all CS & [MS voice calls from and to VCC capable UE are anchored in the subscriber's IMS domain.

Figure 1 shows the functional architecture for VCC. It does not represent any change from the existing 3GPP reference architecture in that CCCF and NeDS functions are implemented as SIP Application Servers. At the time of writing it has not been agreed whether CCCF and NeDS should be co-located. This figure assumes that they are, hence only one ISC interface is shown.

An UE registers with Call Continuity Control Function (CCCF) at time of HE 1MS registration following the procedure defined in 23.288 for Application Server registration with the filter criteria set that 3rd party registration is required via ISC interface.

A CCCF exists for each voice continuity event in the system and controls the establishment of call legs required to transfer a call between CS and IMS. If a UE is involved in multiple calls all requiring VCC, then a separate CCCF exists for each call.

VCC registration During and following the IMS registration procedure, VCC information is exchanged between UE and CCCF. This includes: * FromUE=>CCCF * UE CS status (detached, attached-idle/attached-active) * User preferences * FromCCCF=>UE * CCCF PSI and associated CS routing number * Operator policy The exact information exchange mechanism has not yet been specified, but the post registration exchange of information is likely to be handled by a mutual SIP Subscribe/Notify process. I.e. the UE subscribes to information from the CCCF, and the CCCF subscribes to information from the UE. Each will in turn be notified upon initial subscription and as information changes.

Call origination from IMS domain At the time of call origination from the IMS domain, the SIP iNVITE is routed via the CSCF's to the CCCF using initial filter criteria. The CCCF records the call event (assigns call reference, and records route to stay in signalling path for call) and routes the call back to the S-CSCF so that S-CSCF can perform termination handling to IMS/CS domains as defined in TS 23.228. IMS anchoring of VCC calls originated in the IMS domain is independent of whether the UE is CS attached or detached.

If the terminal is not capable of supporting VCC procedures, but the user is a subscriber to VCC services, the lack of VCC capability in the terminal could be informed to the CCCF during IMS registration. In that case, the CCCF could decide not to IMS anchor the call. Given that S-CSCF and CCCF are both located in the user's home network, and that the IMS bearer is established end to end, it is debatable whether there would be much benefit in not IMS anchoring an IMS originated call from a VCC subscriber.

Call origination from CS domain The default mechanism (only mandated mechanism) for IMS anchoring of VCC calls originated in the CS domain is to use CAMEL triggers at the VMSC. This means it is possible to anchor calls even if the UE is not IMS registered at the time of call originating.

If the terminal is not capable of supporting VCC procedures, but the user is a subscriber to VCC services, the CCCF for the call cannot be aware of the lack of VCC capability in the terminal, as no prior exchange of VCC information will have been possible between the UE and CCCF.

Figure 2 shows the message flow for CS originated VCC calls.

1. A Call Control SETUP message is sent from the UE to the VMSC.

2. Originating CAMEL Subscription Information (0-CS!) triggering in gsm SSF at VMSC sends JnitialDP message towards gsmSCF function of CCCF.

3. CCCF creates IP Multimedia Routing Number (IMRN) which gsmSCF returns to VMSC in CONNECT message (CCCF notes information required to complete call towards called party).

4. VMSC routes call towards MGCF in user's home IMS network using IMRN.

5. MGCF initiates SIP iNVITE towards I-CSCF.

6. I-CSCF retrieves from HSS the CCCF associated with IMRN and forward the SIP INVITE.

7. The CCCF terminates incoming leg and initiates outgoing leg towards original called party acting as Back to Back User Agent (B2BUA).

It is an aim of the present invention to improve the voice call continuity service.

It is another aim of the present invention to provide a mobile terminal in a communications system with additional information.

According to one aspect of the present invention, there is provided a method of signalling information between a mobile station and a serving network element of a mobile communications network, wherein the network element transmits information to the mobile terminal relating to the networks capabilities to transmit voice information via a packet switched network portion.

In this way the mobile terminal may for example use the information to decide whether voice call continuity (VCC) services can be provided in its current location. The UE may then decide whether to indicate the possibility/desirability of supporting VCC to the Call Continuity Control Function (CCCF) prior to or at the time of call establishment. Based on this information, the CCCF may decide not to IMS anchor the call from the VCC subscriber.

Alternatively, the mobile terminal may use the information for deciding whether calls are performed via the circuit switched domain.

Alternatively, the mobile terminal may use the information for selecting one of the following possibilities: i) communicating via a packet switched service; or ii) communicating via combined circuit switched and IP multimedia service.

Preferably, the information is included in a Non-Access Stratum (NAS) message between the Core Network and the terminal.

The information may be signalled during UE registration in the Routing Area Update Accept or in the Attach Accept message. Both messages include the information element Network Feature Support, which has two spare bits available (as described in section 10.5.5.23 of TS 24.008). In this case the information could be tailored to individual subscribers, but its resolution Preferably, the information is included in a dedicated Radio Access Network message.

In this way greater (cell level) resolution is provided and a more dynamic management of local voice traffic between PS and CS domain can be achieved. However, in this way the information could not be tailored for individual subscribers.

Embodiments of the present invention will now be described, by example only, with reference to the accompanying figures, whereby: Fig. I is a schematic outline of a VCC functional architecture into which the present invention can be implemented; and Fig. 2 is a schematic message flow diagram for CS originated VCC calls.

Above an outline description of Voice Call Continuity (VCC) registration and call origination is given.

When describing the procedure for CS originated VCC calls, the 3GPP technical report TR 23.806 states: "If the UE is in a location where VCC is not possible andlor desirable, the gsmSCF directs the VMSC to continue with normal call origination procedures." This implies that in some circumstances dependent on the location of the UE, the CCCF should not IMS anchor the call.

The advantages to not anchoring the call are that it: -reduces unnecessary signalling in the network (an IMS anchored call will always be routed to the IMS domain of the called party, even if it is to be terminated in the CS domain); -can reduce call setup latency (due to the reduction in call signalling); -allows for more optimised routing of the call (compared to case where call is IMS anchored); -may result in improved speech quality for the calling party (due to reduction in codec switching in the user plane); Further given that VCC is a subscription based service, it is possible that a VCC subscriber may be using a terminal that is not VCC capable (e.g. a standard 2G terminal, with a VCC subscription USIM). In that case, VCC would not be possible regardless of the location of the UE, so it would be desirable not to IMS anchor any of the calls made by that terminal.

The idea proposed herein seeks to solve the problem that whilst it is not always desirable to IMS anchor a CS originated call from a VCC subscriber there is at present no mechanism enabling such anchoring to not take place. The proposal describes a mechanism whereby the desirability/possibility of using VCC within a call is communicated by the serving network to the UE via the system information broadcast or during registration signalling, arid by the UE to the CCCF in the home network via the SETUP and InitialDP messages sent at the time of CS call establishment.

OPTIONAL IMS ANCHORING FOR CS ORIGTNATED CALLS FROM VCC

SUBSCRIBERS

When describing the procedure for CS originated VCC calls, the 3GPP technical report TR 23.806 states: "If the UE is in a location where VCC is not possible andlor desirable, the gsmSCF directs the VMSC to continue with normal call origination procedures." This implies that in some circumstances dependent on the location of the UE, the gsmSCF in the CCCF should not anchor the call. It is not clear however: a) How the CCCF situated in the UE's home network, can know whether the UE is in a location where VCC is possible/desirable.

b) How the UE can signal to the CCCF in its home network whether it is in a location where VCC is possible/desirable.

c) How the UE can know whether it is in a location where VCC is possible/desirable.

The advantages to not anchoring the call are that it: -reduces unnecessary signalling in the network (an IMS anchored call will always be routed to the IMS domain of the called party, even if it is to be terminated in the CS domain); -can reduce call setup latency (due to the reduction in call signalling); -allows for more optimised routing of the call (compared to case where call is IMS anchored); -may result in improved speech quality for the calling party (due to reduction in codec switching in the user plane); Further given that VCC is a subscription based service, it is possible that a VCC subscriber may be using a tenninal that is not VCC capable (e.g. a standard 2G terminal). In that case, VCC would not be possible regardless of the location of the UE, so it would be desirable not to IMS anchor any of the calls made by that terminal. As explained in Appendix 1 section Al.3, if the UE is not IMS registered at the time of call setup, there is no way for the CCCF to know whether the terminal of the calling VCC subscriber is capable of supporting VCC procedures.

Given the above there are two issues that need to be addressed when deciding whether to IMS anchor a CS originated call from a VCC subscriber.

I. Whether it is desirable to use VCC in a call. This should be decided in the CCCF based on the VCC subscriber preferences and home network operator policy.

2. Whether it is possible to use VCC in a call. This is not just dependent on location. It should be possible for the UE to indicate the VCC possibility decision based on the terminal VCC capability. In addition, it could be possible for the serving network to indicate whether VCC is possible e.g. based on its capability to support Vo1P via its PS network.

The UE could determine VCC desirability/possibility based on four factors: 1. Terminal VCC capability 2. User VCC preference 3. VoIP capability of attached PS network 4. Availability of local IP-CANs (e.g. WLAN hotspot) In the case of 3 the network would need to inform the UE of the network's VoIP capability. This could be achieved for example via System In formation Broadcast, or during Routing Area Update, or GPRS attached signalling. The user VCC preference (2) could be tied to the availability of local IP-CANs (4), e.g. so that calls made in areas where no suitable IP-CANs were detected should not be anchored.

Further, cases 1 and 2 could be considered as semi-static information that would not change during the lifetime of a call, where as cases 3 and 4 could be considered as dynamic information that could change as the terminal moves during the lifetime of the call.

Communicatin2 VCC possibility/desirability from servin2 network to UE To help the UE decide whether VCC is possible in its current location, the serving network could send and indication of whether it supports VoIP via its PS domain. On receiving this information, the UE could decide whether to indicate the possibility/desirability of call anchoring to the CCCF at the time of call establishment.

Below other applications for the concept of signalling the network's VoW capability to the UE will be described.

Include information in NAS signaling messages The information could be signalled during UE registration in the Routing Update Accept or in the Attach Accept message. Both messages include the information element Network Feature Support, which has two spare bits available (as described in section 10.5.5.23 of TS 24.008). In this case the information could be tailored to individual subscribers, but its resolution would be at Location Area level.

Include information in System Information Broadcast The information could be broadcast in the System Information Broadcast. This would provide greater (cell level) resolution and facilitate for more dynamic management of local voice traffic between PS and CS domain, but could not be tailored for individual subscribers.

This method further extends to the Radio Network procedures that transfer system information through dedicated signalling, for instance, the UTRAN Mobility Information transfer procedures of the UMTS Radio Access Network.

Send information to UE via USSD It would also be possible to send serving network VoIP capability information to the UE via USSD.

Send information to UE via SMS It would also be possible to send serving network VoIP capability information to the UE via SMS.

Communicatin2 VCC possibility/desirability from UE to CCCF In order that the CCCF can make a decision on whether to anchor the CS originated call from the VCC subscriber, the UE should send an indication of whether it is desirable/possible to support VCC during the call.

Include information in Classmark 2.

One way to do this would be to include the possibility/desirability information in NAS signalling message between the UB and the network. e.g. Location update request, and CM Service Request. Classmark 2, as defined in 3GPP TS 24.008 is sent in these messages, has one spare bit available in each of octets 3, 4 and 5. The VCC capability information could also be provided to the network via classmark change procedure described in TS 44.108 section 3.4.10. Classmark 2 is automatically included in the InitialDP message (see message 2 in figure 2), so on reception of the InitialDP message the gsmSCF in the CCCF could check the VCC possibility/desirability bit(s) and respond accordingly. i.e. either by sending a CONNECT message containing IMRN directing the VMSC to route the call towards the user's IMS domain for anchoring, or by sending a continue message so that the call is routed normally.

It is proposed that one or two of these spare bits be used to indicate to the network whether VCC is possible/desirable. If two of the spare bits were used it would be possible to indicate separately whether VCC was possible (e.g. based on terminal capability, user preference) and whether VCC was desirable (e.g. based on availability of IP-CANs in the area of the calling UE at the time of call establishment). In that case the CCCF in the home network could decide whether to override an indication that VCC was not desirable and to anchor the call in case the user subsequently moved into the coverage area of a suitable IP-CAN.

Classmark 2 could also be extended and the UE VCC capability indicated in an extension to that classmark in order that VCC capability signalling does not use up all the remaining spare bits of the classmark.

Include information in SETUP message.

An alternative method to achieve this would be for the UE to include VCC the possibility/desirability indication in the SETUP message sent as part of the Call Control protocol during the call establishment procedure (see message 1 of the message flow in figure 2). The gsmSSF in the VMSC could then include that indication in the InitialDP message sent towards the gsmSCF at the CCCF (see message 2 in figure 2), so that it can respond accordingly.

i.e. either by sending a CONNECT message containing IMRN directing the VMSC to route the call towards the user's IMS domain for anchoring, or by sending a continue message so that the call is routed normally.

The 3GPP Call Control protocol is specified in 3GPP TS 24.008. The format for the SETUP message in the case of mobile originated call establishment is shown in table 9.70a of that document. One of the information elements contained in the SETUP message from the UE is Call Control Capabilities (described in table 10.5.89 of TS 24.008). The purpose of this information element is to identify the Call Control Capabilities of the mobile station. The information element is four octets in length. It has one spare bit in octet 3 and four spare bits in octet 4. When CAMEL services are triggered in the VMSC, the gsmSSF includes some of the information from the SETUP message in the InitialDP message sent to the gsmSCF. It is proposed that VCC capability/possibility be added to the InitialDP below the InitialDPArgExtension defined in section 6.1.1 of 29.078.

It is again proposed that one or two of the spare bits could be used as described above.

Include information in Classmark 3.

A further alternative would be to include the UE VCC possibility/desirability information in Classmark 3. This is not presently included in the InitialDP message, but could be added in the same way as proposed above for the SETUP message.

Include information in Classmark (2 or 3) and in SETUP message To facilitate the CCCF decision making process, another alternative would be to include the semi-static information (see above) in the classmark (e.g. Classmark 2) and the dynamic information in the SETUP message sent at the time of call establishment. The CCCF could then choose whether to anchor the call based on whether the VCC possibility/desirability was static (i.e. not likely to change during the course of the call), dynamic (i.e. more likely to change during the course of the call/dependent on the preferences/policy of the serving network.

Optional IMS anchoring for CS terminated calls originated in the CS domain In the same way as for CS originated VCC calls as described above, the UE can include capability information in Classmark 2 or Classmark 3 for CS terminated calls that were originated in the CS domain. In this case, the decision to anchor the call is taken by the CCCF after receiving the InitialDP message from the GMSC to which the incoming call was routed. This is another application for the idea of including static (see below) VCC capability information in Classmark 2 or Classmark 3.

In the following other applications will be described for a network element transmitting information to the mobile terminal relating to the network's capabilities to transmit voice information via a packet switched network portion.

Basically, the concept of a 3GPP network being able to signal is Voice over IP capability with respect to its Packet Switched (PS) network is fundamental to the user terminal being able to decide whether or not a voice call should be established via Circuit Switched (CS) or IMS domains. Prior to the release 6 of the 3GPP TJMTS standard, Voice over IP (V0IP) was not supported via the IMS domain due to a mixture of insufficient bandwidth being available in the access networks, and IMS not being adequately specified. From release 6 with a more fully featured IMS and the introduction of Enhanced Uplink Packet Access it shoud be possible to support VoIP via IMS from 3GPP IP-Connectivity Access Networks (IP-CANs). However, for reasons of traffic management, some networks might prefer sometime to not offer VoIP support in the PS networks. In that case it would be desirable to direct voice calls to take place via the CS domain. This could be achieved by signalling the network's PS VoIP capability.

The above described application is a generic application for signalling the network's VoIP capability.

Another possible application is the CSI (Combined CS and IIMS services) phase 2 work item currently being elaborated by 3GPP, as well as the IMS enhancement work items.

In CSI Phase 1, it is so designed that the Voice Call part is always carried over the CS domain. In CSI Phase 1, there is only ever an end-to-end CSI call, ie. UEs of both parties must be able to support the combining of CS and PS sessions.

In CS! Phase 2, the view is that fully fledge IMS UEs in an IMS network that can support VoIP will be making VoW + data sessions to a CS! capable UE. So while one party may be in a VoIP scenario, the other party could be utilising combining of CS and PS sessions.

Progressing from that, it is highly likely that in CS! Phase 2 such [MS UEs are also CS! capable UEs.

So for the IMS and CSI capable UE to make the intelligent' choice of whether to initiate a VoIP + Data sessions or to initiate a CS! call, the UE needs to know the VoIP capability of the network / LA / RA / cell it is currently registered and camped on.

The reverse is also true of a CSI capable UE making a call to a UE which is both fully!MS capable and CS! capable.

a) whether this called UE is in a VoIP capable network could mean whether the call is completely entirely by IMS call session control or if called UE is not in a VoW network the call could then be offered as a CSI call (ie. combined PS sessions with CS call). Thus from that perspective, the CSI capability of the UE must not only be known to the NETWORK but that the NETWORK's VoJP capability where the called UE is physically in must also be known to the NE call processes.

b) even if the called UE is in a Vo1P capable network (or VoIP part of the network), the UE could be given the choice of whether to complete the call through Vo!P or through CS!. For this the UE/User need the knowledge of whether the NETWORK (or that part of the NETWORK) is VoIP capable.

To further illustrate the above point let's consider the following commercial aspect. It is a driven wish by NETWORK operators to more and more move' over to providing services through the PS domain. Towards this end, it is obvious that NETWORK operators will attempt to market VoIP as much as possible and likely at discounted rates to encourage user takeup. A User knowing that he/she is in a physical position that allows VoW could be persuaded to use VoIP instead of making a Voice Call over CS domain. Thus the need to indicate VoIP capability of the NETWORK / LA / RA / cell that the UE is physically registered to or camped on.

It is to be understood that the above describes embodiments are set out by way of example only, and that many variations or modifications are possible within the scope of the appended claims.

Claims

CLAIMS: 1. A method of signalling information between a mobile station

and a serving network element of a mobile communications network, wherein the network element transmits information to the mobile terminal relating to the networks capabilities to transmit voice information via a packet switched network portion.

2. A method according to claim 1, wherein the information relates to the network capabilities to provide VoIP services.

3. A method according to claim I or 2, wherein the information is included in a Non-Access Stratum (NAS) message between the Core Network and the terminal.

4. A method according to claims 1, 2 or 3, wherein the information is included during registration and/or registration updates of the mobile terminal.

5. A method according to any preceding claim, wherein the information is included in a ROUTiNG AREA UPDATE ACCEPT message.

6. A method according to any preceding claim, wherein the information is included in an ATTACH ACCEPT message.

7. A method according to claims 1, 2 or 3, wherein the information is included in a dedicated Radio Access Network message.

8. A method according to claim 7, wherein the information is included in a system information broadcast message.

9. A method according to claims 1, 2 or 3, wherein the information is included in Unstructured Supplementary Service Data.

10. A method according to claims 1, 2 or 3, wherein the information is send to the mobile station via a short message service.

ii. A method according to any preceding claim, wherein, on receiving the information relating to the network capabilities, the mobile terminal determines whether voice call continuity services are to be used for a communications with another telecommunications terminal.

12. A method according to claim 11, wherein the mobile terminal indicates the possibility andlor desirability of call anchoring to a call continuity control function.

13. A method according to any preceding claim, wherein, on receiving the information relating to the network capabilities, voice calls are preformed via the circuit switched domain.

14. A method according to any preceding claim, wherein, on receiving the information relating to the network capabilities, the mobile stations selects one of the following possibilities: i) communicating via a packet switched service; or ii) communicating via combined circuit switched and IP multimedia service.

15. A method according to claim 14, wherein said mobile station is the calling party's mobile station.

16. A method according to claim 14, wherein said mobile station is the caller party's mobile station.