Enabling UE access domain selection for terminated speech/video calls

Abstract

Methods, apparatuses, and systems are described for selecting an access domain for receiving a speech and/or video call at a mobile station of a mobile communications network in which calls are routed via a central service control common to a plurality of access domains. In one method, a terminating mobile station receives an INVITE and then, if the access network supports neither simultaneous circuit switched (CS) and packet switched (PS) connections nor voice over internet protocol (VoIP), the terminating mobile station transmits a message indicating that a CS bearer is required for a session.

Claims

1. A method for determining an access domain by a terminating mobile station of a mobile communications network, comprising: receiving an INVITE; determining an access domain based at least on capabilities of an access network and on the INVITE; and establishing a call based on the determined access domain, wherein determining the access domain comprises: if a bidirectional speech media and a voice over internet protocol (VoIP) are not supported by the access network, transmitting a message indicating that a circuit switched (CS) bearer is required for a session.

2. The method of claim 1, wherein the access domain is determined based also on policies of an operator.

3. The method of claim 1, wherein the message is a session progress message.

4. An apparatus for determining an access domain by a terminating mobile station in a mobile communications network, comprising: a transceiver configured to transmit or receive data; and a controller configured to: receive an INVITE, determine an access domain based at least on capabilities of an access network and on the INVITE, and establish a call based on the determined access domain, wherein determining the access domain comprises: if a bidirectional speech media and a voice over internet protocol (VoIP) are not supported by the access network, transmitting a message indicating that a circuit switched (CS) bearer is required for a session.

5. The apparatus of claim 4, wherein the access domain is determined based also on policies of an operator.

6. The apparatus of claim 4, wherein the message is a session progress message.

7. A method for processing an access domain of a terminating mobile station by an access network in a mobile communications network, comprising: transmitting, to the terminating mobile station, an INVITE; and receiving, from the terminating mobile station, a message indicating that a circuit switched (CS) bearer is required for a session if a bidirectional speech media and a voice over internet protocol (VoIP) are not supported by the access network, wherein the access domain is determined based at least on capabilities of the access network and on the INVITE.

8. The method of claim 7, wherein the access domain is determined also based on policies of an operator.

9. The method of claim 7, wherein the message is a session progress message.

10. An apparatus for processing an access domain of a terminating mobile station by an access network in a mobile communications network, comprising: a transceiver configured to transmit or receive data; and a controller configured to: transmit, to the terminating mobile station, an INVITE; and receive, from the terminating mobile station, a message indicating that a circuit switched (CS) bearer is required for a session if a bidirectional speech media and a voice over internet protocol (VoIP) are not supported by the access network, wherein the access domain is determined based at least on capabilities of the access network and on the INVITE.

11. The apparatus of claim 10, wherein the access domain is determined also based on policies of an operator.

12. The apparatus of claim 10, wherein the message is a session progress message.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) Various exemplary embodiments of the invention will now be described with reference to the attached figures in which:

(2) FIG. 1 is a flow chart showing an existing terminating call domain selection process for ICS;

(3) FIG. 2 is a flow chart showing a terminating call domain selection process for ICS according to an embodiment of the invention;

(4) FIG. 3 schematically shows functional components of a system according to the present invention.

(5) FIG. 4 illustrates the operations performed when a terminating terminal is IMS registered and the access network is capable of simultaneous CS and PS operation;

(6) FIG. 5 illustrates the operations performed when a terminating terminal is IMS registered and the access network is not capable of simultaneous CS and PS operation;

(7) FIG. 6 is a flow chart showing operations performed by an ICCF to determine the need to correlate a CS call with an incoming SIP call; and

(8) FIG. 7 is a flow chart showing a terminating call domain selection process for ICS according to an alternative embodiment of the invention.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE PRESENT INVENTION

(9) In an embodiment of the invention, an ICS UE receives a normal Session Initiation Protocol (SIP) INVITE via the PS domain, but then has the option of responding via the CS domain to the ICCF using USSD to inform the ICCF that simultaneous PS and CS operation was not possible. This comes from the fact that an IMS registered UE can always receive a SIP INVITE regardless of whether it is connected via an access network that is capable of simultaneous CS and PS operation (provided that it is not already engaged in a CS call). A further inventive step is that the response from the terminal to the initial SIP INVITE contains an indication that a CS bearer shall be used for the media part of the session, if the IP-CAN is not able to support conversational speech/video, e.g. via VoIP. This information could be sent using a IMS Communication Service Identifier (ICSI), or some other means that will inform the ICCF to expect a subsequent CS bearer establishment to be associated with the session in case the fact that the SIP response to the SIP INVITE was delivered to the ICCF by USSD is not sufficiently indicative.

(10) This invention builds on the ICS architecture described in 3GPP TR 23.892 that enables an IMS Core Network that can be accessed via an IP-CAN or to a more limited extent via the CS domain for the transport of user media and/or session establishment signalling. In particular, this invention enables the domain selection function in ICS networks to be placed in the UE for the purposes of call termination.

(11) FIG. 2 presents an example logical flow in the case where the UE is allowed to determine the appropriate domain for session termination based on operator policy and the capabilities of the access network. In this case, the UE can also make the decision of whether a PS or USSD based control channel should be used for associated control signalling. According to an aspect of the invention, the ICCF is always included in the call flow for MT calls.

(12) As shown in FIG. 2, after a call notification arrives, at S41, at the ICCF, the ICCF determines, at S43, if the terminating terminal is IMS registered via IP-CAN. If so, the ICCF sends, at S45, an SIP INVITE to the terminating terminal, regardless of the capability of the IP-CAN and the local access network to support real time speech/video e.g. via VoIP. On receiving the SIP INVITE, the terminating terminal determines, at S47, if the local access network supports VoIP. If VoIP is supported, the terminating terminal responds, at S49, using a SIP 18x message and a normal IMS session ensues.

(13) If the terminating terminal determines, at S47, that the access network does not support VoIP, the terminating terminal checks, at S51, if the access network supports simultaneous communication in the CS and the PS domains. If so, the terminating terminal responds, at S53, with SIP 183 message (Session Progress) in the PS domain indicating that the media will be carried by a CS bearer, and establishes a CS bearer towards the ICCF for transport of media. The indication in the SIP 183 message that the media will be carried by a CS bearer can take a number of different forms: the SIP INVITE from the ICCF could convey an SDP offer containing a media line specifically indicating media transport via the CS domain, and the UE provides an SDP answer containing only the CS related media line; alternatively a SIP 415 message (unsupported media) could be sent, which could be interpreted by the ICCF, knowing that the ICS UE was registered via CS to receive IMS services, that a CS bearer should be established for the media transport. The IMS session then ensues, at S55, using the CS bearer for media with SIP via the PS domain for control and configuration of services.

(14) If the terminating terminal determines, at S51, that the local access network is not able to support simultaneous CS and PS communication, then the terminating terminal responds, at S61, by sending a “progress” message using USSD via the CS domain indicating that the session should be established via the CS domain, and establishes a CS bearer towards the ICCF for transport of media. Alternatively, the UE could respond by sending a new SIP 4xx message towards the ICCF indicating that USSD should be used for CS bearer control. The IMS session then ensues, at S63, using the CS bearer for media with ICCP via USSD for control and configuration of services.

(15) If the ICCF determines, at S43, that the terminating terminal is not IMS registered via IP-CAN, the ICCF determines, at S57, if the terminating terminal is registered to receive IMS via the CS domain. If so, the ICCF sends, at S59, an incoming call notification to the terminating terminal via USSD. Following receipt of the incoming call notification, the terminating terminal responds, at S61, using USSD via the CS domain and establishes a CS bearer towards the ICCF for transport of media. The IMS session then ensues, at S63, using the CS bearer for media with ICCP via USSD for control and configuration of services.

(16) If the ICCF determines, at S57, that the terminating terminal is not registered to receive IMS via the CS domain, the ICCF checks, at S65, if the terminating terminal is registered to receive normal CS. If it is, the ICCF completes, at S67, the session as a standard CS call towards the terminating terminal. If it is not, the ICCF determines, at S69, that the call cannot be completed.

(17) The present invention is applicable to the IP Multimedia System (IMS) centralised service (ICS) whose architecture requirements are discussed in 3GPP TR23.892 v1.0.0, which may be downloaded from www.3gpp.org and is hereby incorporated herein in its entirety by reference.

(18) FIG. 3 schematically shows the main functional components of an ICS system relevant to the present invention. It will be appreciated that an ICS component includes many other functional components, but these have not been included in FIG. 3 for ease of illustration.

(19) As shown in FIG. 3, an originating UE 1 communicates, via a local Radio Access Network (RAN) 3, with a call session control function (CSCF) 5. Those skilled in the art will appreciate that there are in fact three types of call session control functions, the proxy CSCF, the serving CSCF and the interrogating CSCF. However, for ease of explanation these have been grouped together in FIG. 3.

(20) The CSCF 5 is connected to an IMS CS Control Function (ICCF) 7. The ICCF 7 provides functions necessary for provision of IMS services for calls originated or terminated over CS access networks and for calls transferred between CS and PS access networks. As shown in FIG. 3, the ICCF 7 includes two functions: the CS Access Adaptation Function (CAAF) and the Remote User Agent (RUA).

(21) The ICCF 7 is connected to the Home Subscriber Server (HSS) 9, a Media Gateway Controller Function (MGCF) 11 and a Media Gateway 13. The HSS 9 is a mater user database containing subscription related information and can provide information about the location of a user. The MGW 13 interfaces with the media plane of the CS domain, and the MGCF 11 performs control protocol conversion.

(22) The HSS 9, the MGCF 11 and the MOW 13 are all connected, via a visited mobile switching centre (VMSC) 15 and a radio access network 17, to the terminating UE 19.

(23) When accessing IMS services via the CS domain, an IMS CS control channel (ICCC) is used to transport control signalling between the ICS UE and the IMS. The ICCC can be established over the CS domain network, in which case it is referred to as I1-cs, or over the PS domain, in which case it is referred to as I1-ps.

(24) The USSD transport mechanism used in the CS domain, does not offer as much bandwidth as the PS bearer, and accordingly a suitable IMS CS Control Protocol (ICCP) is required.

(25) FIG. 4 shows an example message flow for call establishment when the terminal is IMS registered and the access network is capable of simultaneous CS and PS operation.

(26) Whilst this message flow is not completely new what is different and illustrates the invention is in Step 6. In Step 6 upon receiving the SIP INVITE request, it is the UE who makes the decision on which domain the UE wants to complete the call. Furthermore, once that decision is taken by the UE, the UE conveys that indication back to the IMS Circuit Switched control function (ICCF) in Step 7.

(27) 1. An incoming SIP INVITE is received at the S-CSCF of the B party with an Offer containing SDP from the A-party.

(28) 2. The S-CSCF forwards the INVITE to the ICCF.

(29) 3. The ICCF sends a 183 Session Progress back to the S-CSCF.

(30) 4. The S-CSCF sends the 183 Session Progress to the A-party.

(31) 5. The ICCF (acting as a B2BUA) establishes a session over I1-ps by sending an INVITE to the B-party. The INVITE contains a dynamic RUA PSI to enable the ICCF to later on correlate the outgoing session control signalling with the incoming bearer control signalling.

(32) 6. UE-B responds with a 183 Session Progress, providing an indication to the ICCF that a CS bearer is required for the media transport, so that the ICCF will expect the subsequent INVITE from the UE that is associated with the CS bearer establishment.

(33) 7. UE-B sends a SETUP message to the VMSC to establish the Bearer Control Signalling session. The SETUP message includes the RUA PSI DN as the called party number. This will establish the circuit voice bearer between the UE and IMS.

(34) 8. The VMSC responds with a call proceeding message and begins to set up the Bearer Control Signalling session.

(35) 9. The VMSC processes the SETUP message and sends an IAM to the MGCF. The SETUP message contains the RUA PSI DN. [NOTE: Standard VMSC procedures for CS origination]

(36) 10. The MGCF performs a setup of the MOW and creates an INVITE with an Offer containing the SDP from the MGW. The INVITE is sent to the ICCF (via the I/S-CSCF). [NOTE: Standard MGCF procedure for PSTN origination]

(37) 11. The I/S-CSCF forwards the INVITE to RUA of ICCF.

(38) 12. The ICCF sends an UPDATE to the S-CSCF with an Answer to the Offer from the A-party, containing the SDP from the MGW.

(39) 13. The S-CSCF forwards the UPDATE to the A-party.

(40) 14. The S-CSCF receives a 200 OK to the UPDATE.

(41) 15. The S-CSCF forwards the 200 OK to the ICCF.

(42) 16. The ICCF sends a 183 Session Progress to S-CSCF with an Answer to the Offer from the MGW, containing the SDP from the A-party.

(43) 17. The S-CSCF sends the 183 Session Progress to the MGCF.

(44) 18. The MGCF creates an ACM and sends it to the VMSC.

(45) 19. Alerting is sent from the VMSC to UE B.

(46) 20. The ICCF sends a 200 OK to S-CSCF in response to the INVITE in Step 12.

(47) 21. The S-CSCF forwards the 200 OK to the MGCF.

(48) 22. The MGCF creates an ANM and sends it to the VMSC.

(49) 23. The VMSC sends a Connect to UE B. The set up of the bearer is complete.

(50) 24. User alerting at UE B; UE B sends 180 Ringing to the ICCF.

(51) 25. The ICCF forwards the 180 Ringing to the S-CSCF for communicating toward UE A.

(52) 26. The S-CSCF forwards the 180 Ringing to UE A.

(53) 27. User answer at UE B; UE B sends a 200 OK to the ICCF for the INVITE in Step 6.

(54) 28. The ICCF forwards the 200 OK to the S-CSCF for communicating toward UE.

(55) 29. The S-CSCF forwards the 200 OK towards to the A-party.

(56) FIG. 5 shows an example message flow call establishment when the terminal is IMS registered, but the access network is not capable of simultaneous CS and PS operation.

(57) This message flow is new and shows that the ICS UE can respond to an incoming INVITE by sending a progress message via USSD to the ICCF. This informs the ICCF that further signalling for this session will be via USSD.

(58) 1. An incoming SIP INVITE is received at the S-CSCF of the B party with an Offer containing SDP from the A-party.

(59) 2. The S-CSCF forwards the INVITE to the ICCF.

(60) 3. The ICCF sends a 183 Session Progress back to the S-CSCF.

(61) 4. The S-CSCF sends the 183 Session Progress to the A-party.

(62) 5. The ICCF (acting as a B2BUA) establishes a session over I1-ps by sending an INVITE to the B-party. The INVITE contains a dynamic RUA PSI to enable the ICCF to later on correlate the outgoing session control signalling with the incoming bearer control signalling.

(63) 6. INVITE arrives at UE B. UE B determines that there is no simultaneous CS and PS capability in the access network. UE B sends Progress a USSD message to the VMSC. The VMSC forwards the USSD (Progress) to the HSS. The HSS forwards the USSD (Progress) to the CAAF of the ICCF. ICCF knows that USSD will be used for subsequent control signalling.

(64) 7. UE-B sends a SETUP message to the VMSC to establish the Bearer Control Signalling session. The SETUP message includes the RUA PSI DN as the called party number. This will establish the circuit voice bearer between the UE and IMS.

(65) 8. The VMSC responds with a call proceeding message and begins to set up the Bearer Control Signalling session.

(66) 9. The VMSC processes the SETUP message and sends an IAM to the MGCF. The SETUP message contains the RUA PSI DN. [NOTE: Standard VMSC procedures for CS origination]

(67) 10. The MGCF performs a setup of the MGW and creates an INVITE with an Offer containing the SDP from the MGW. The INVITE is sent to the ICCF (via the US-CSCF). [NOTE: Standard MGCF procedure for PSTN origination]

(68) 11. The I/S-CSCF forwards the INVITE to RUA of ICCF.

(69) 12. The ICCF sends an UPDATE to the S-CSCF with an Answer to the Offer from the A-party, containing the SDP from the MGW.

(70) 13. The S-CSCF forwards the UPDATE to the A-party.

(71) 14. The S-CSCF receives a 200 OK to the UPDATE.

(72) 15. The S-CSCF forwards the 200 OK to the ICCF.

(73) 16. The ICCF sends a 183 Session Progress to S-CSCF with an Answer to the Offer from the MGW, containing the SDP from the A-party.

(74) 17. The S-CSCF sends the 183 Session Progress to the MGCF.

(75) 18. The MGCF creates an ACM and sends it to the VMSC.

(76) 19. Alerting is sent from the VMSC to UE B.

(77) 20. The ICCF sends a 200 OK to S-CSCF in response to the INVITE in Step 12.

(78) 21. The S-CSCF forwards the 200 OK to the MGCF.

(79) 22. The MGCF creates an ANM and sends it to the VMSC.

(80) 23. The VMSC sends a Connect to UE B. The set up of the bearer is complete.

(81) 24. User Alerting at UE B; UE B sends Ringing in a USSD message to the VMSC. The VMSC forwards the USSD (Ringing) to the HSS. The HSS forwards the USSD (Ringing) to the CAAF of the ICCF.

(82) 25. The CAAF of the ICCF performs the necessary adaptation and relays the information needed for generation of the SIP message at the RUA of the ICCF. The RUA of the ICCF acting as a B2BUA creates a 180 Ringing and sends it to the S-CSCF for communicating with UE A.

(83) 26. The S-CSCF forwards the 180 Ringing to UE A.

(84) 27. User Answer at UE B; UE B sends Answer in a USSD message to the VMSC. The VMSC forwards the USSD (Answer) to the HSS. The HSS forwards the USSD (Answer) to the CAAF of the ICCF.

(85) 28. The CAAF of the ICCF performs the necessary adaptation and relays the information needed for generation of the SIP message at the RUA of the ICCF. The RUA of the ICCF acting as a B2BUA creates a 200 OK and sends it to the S-CSCF for communicating with UE A.

(86) 29. The S-CSCF forwards the 200 OK towards to the A-party.

(87) Similarly Step 6 of FIG. 5 is new and different illustrating the invention. In Step 6 upon receiving the SIP INVITE request, it is the UE who makes the decision on which domain the UE wants to complete the call. Once that decision is taken by the UE, that decision is made known to the ICCF (in Step 7).

(88) For what is illustrated in both FIG. 4 and FIG. 5, the ICCF has to make a correlation of the CS call to the IMS call (from UE A) as the call between UE-A and UE-B is not completed through the IMS CN in the normal IMS way of call completion. So in Step 7 (of both FIG. 4 and FIG. 5) the UE response with 183 Session progress has to lead the ICCF has to conclude if correlation with the CS domain is required. FIG. 6, gives a diagrammatic illustration of the process leading the ICCF to determine the need for such correlation.

Modifications and Further Embodiments

(89) It is not necessary for registration in the IMS to be required by a CS connected terminal unless an IP-CAN is available. As such, the concept that the ICCF knowing the UE was registered via CS to receive IMS services may be redundant. However, the use of an SDP offer/answer mechanism is still valid.

(90) FIG. 7 presents another exemplary logical flow in the case where the UE is allowed to determine the appropriate domain for session termination in conjunction with the ICCF based on operator policy and the capabilities of the access network. Note that this example assumes the UE to be ICS capable. The ICS information such as operator policy and RUA PSI DN is communicated to the ICS UE in a manner similar to that used for terminal provisioning in VCC. Domain selection based on operator policy would enable the home network to remain in control of the domain selection decision. In this case, the UE can also make the decision of whether a PS or USSD based control channel should be used for associated control signalling. A solution such as this would remove the need to pass information between the visited access network and the home IMS, and could also reduce the amount of signalling sent via USSD. Further it makes for a more elegant solution for MT domain selection in the case of an ICS home network maintaining the access network independence of the IMS, and would be gracefully forward compatible as an increasing number of IP-CAN s become VoIP capable. It could also help to overcome issues relating to domain selection in the case of signalling free mobility between the EPS and legacy access networks.

(91) The example termination process is as follows:

(92) 1. The ICCF will always be included in the call flow for MT calls.

(93) 2. If the terminal is IMS registered the ICCF sends an INVITE to the terminating UE (regardless of the capability of the IP-CAN to support real time speech/video e.g. via VoIP which is not known).

(94) a. If the terminal determines it is in a VoIP capable IP-CAN it will respond to the INVITE with a standard 18x response and the session will be established via IMS.

(95) b. If the terminal determines it is in a IP-CAN where VoIP cannot be supported, but where the access network can support simultaneous PS and CS, it will respond with a 183 response, that indicates that the media should be carried via a CS bearer. The UE will then establish a CS bearer towards the ICCF, and the ICCF will correlate the CS bearer with the IMS session (INVITE/183 Progress). The session will be treated as an IMS session using a CS bearer for transport of the media.

(96) c. If the terminal determines it is in a IP-CAN where VoIP cannot be supported and where there is no simultaneous CS and PS in the access network, it could respond by sending a “progress” message via USSD towards the ICCF by way of indicating that the session should be established via the CS domain using I1-cs procedures. The ICCF will correlate with the IMS signalling (INVITE) for the session. Further control and configuration of services will be via USSD.

(97) 3. If the terminal is not IMS registered via an IP-CAN but is CS registered, the ICCF will use USSD to send the incoming call notification towards the terminal. The UE will establish a CS bearer towards the ICCF using I1-cs call establishment procedures that the ICCF will correlate with the IMS signalling (INVITE) for the session. Further control and configuration of services will be via USSD.