WO2008098612A1

WO2008098612A1 - Communicating between networks

Info

Publication number: WO2008098612A1
Application number: PCT/EP2007/051357
Authority: WO
Inventors: Arne Pehrsson; Bo ÅSTRÖM
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2007-02-12
Filing date: 2007-02-12
Publication date: 2008-08-21

Abstract

A method and apparatus for communicating between user equipment on a Circuit Switched access network and an IP Multimedia Subsystem network is provided. The method comprises sending call/session establishment protocol-related information over a signalling channel of the Circuit Switched access network between an IP Multimedia Subsystem Adapter function and the user equipment. In one embodiment, the information relates to Session Initiation Protocol signalling and the signalling channel carries the information using Unstructured Supplementary Service Data.

Description

Communicating Between Networks

Field of the Invention

The invention relates to the field of communicating between communications networks, and in particular between a Circuit Switched network and an IP Multimedia Subsystem network.

Background to the Invention

IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. By growing the number of basic applications and the media which it is possible to combine, the number of services offered to the end users will grow, and the inter-personal communication experience will be enriched. This will lead to a new generation of personalised, rich multimedia communication services.

IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3 GPP) to provide IP Multimedia services over mobile communication networks (3GPP TS 22.228, TS 23.228, TS 24.229, TS 29.228, TS 29.229, TS 29.328 and TS 29.329 Releases 5 to 7). IMS provides key features to enrich the end-user person-to-person communication experience through the use of standardised IMS Service Enablers, which facilitate new rich person-to-person (client- to-client) communication services as well as person-to-content (client-to-server) services over IP-based networks. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly.

Figures 1 illustrates schematically how the IMS fits into a mobile network architecture in the case of a Packet Switched (PS) and Circuit Switched (CS) access domains. Call/Session Control Functions (CSCFs) operate as SIP proxies with the IMS. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S- CSCF a request received from a SIP terminal via a P-CSCF.

The IP Multimedia Subsystem (IMS) is a service platform concept originally developed by 3GPP and later on adopted also by other standardization forums. IMS relies on IP as a transport technology. Using IP for voice communication, however, presents some challenges, especially in the mobile community where Voice Over IP (VoIP) enabled packet switched (PS) bearers may not always be available. To allow operators to offer IMS-based services while voice enabled PS-bearers are being built out, the industry has developed solutions that use Circuit Switched (CS) networks to access IMS services. These solutions are herein referred to as IMS Centralized Services (ICS).

The principle architecture for ICS is shown in Figure 2. Note that Figure 2 shows the protocols that would typically be used in a 3GPP system. Other protocols may apply in other deployment situations.

Prior to placing or receiving IMS calls over CS, a user with user equipment must first register in the CS network via the serving Mobile-services Switching Centre (MSC)/Visitor Location Register (VLR) by means of an International Mobile Subscriber Identity (IMSI) Attach/Location Registration procedure. During this procedure the user's user profile is downloaded to the MSC/VLR from the user's Home Location Register (HLR). The user profile may also contain Customized Applications for Mobile networks Enhanced Logic (CAMEL) triggers, and addresses to a GSM Service Control Function (gsmSCF) node that contains service logic for services implemented over the CAMEL Application Part (CAP) protocol. This service logic can be used to implement routing of originating calls to an IMS network. Such routing can be performed statically for every originating call, or dynamically based on criteria such as the visited Public Land Mobile Network (PLMN) to only route to an IMS network when in the home PLMN, if an operator so allows.

Prior to placing or receiving IMS calls over a CS network, a user may also register with an IMS network. A method of registering with an IMS network from a CS network is described in PCT/EP2006/068073.

When an ICS user makes a call, the originating call is made using the basic CS call setup procedure (see 3GPP TS 24.008) towards the serving MSC/VLR. The MSC/VLR uses information contained in a previously downloaded user profile to ascertain if ICS- routing of the call is to be applied. ICS-routed calls are statically routed into an IMS network for originating services execution, regardless of the dialled called party number. The call is routed into an IMS network via an IMS Adaptor function (IA). The prime role of IA is to adapt the CS call to IMS. A prime mechanism in the mobile community today for statically routing calls to a specific node, like the IA, is CAMEL, but other mechanisms can be used as well, e.g. other IN variants.

Figure 3 illustrates the procedure for statically routing an originating ICS call to an IMS network via an IMS adapter using CAMEL. The steps are as follows:

1. The ICS-user originates a call.

2. The MSC/VLR informs the gsmSCF of the call origination, including call information such as called and calling party numbers (gsmSCF contains service logic for services based on the CAMEL mechanisms.

3. The gsmSCF relays the call information to the IA. In Figure 3, the gsmSCF and IA are shown as two separate network entities. However, they may be co-located, eliminating the need for an external interface between the two entities. 4. The IA allocates a routing number to be used to route the originating call from the MSC/VLR to the IA and returns the routing number back to the gsmSCF.

5. The gsmSFC relays the routing number back to the MSC/VLR.

6. The MSC/VLR routes the originated call onwards to the IA using the allocated routing number as a called party number.

7. The IA receives the call and uses the called party number (routing number) to associate the received call with the call information conveyed in steps 2-3. The IA then formats a SIP INVITE message, based on this call information and forwards the SIP INVITE into IMS for originating call processing.

The principle explained in the above description is used, for example, in VCC (Voice Call Continuity) in 3GPP Release 7 for static routing of originating calls into IMS.

The procedure for terminating calls is similar to that for originating calls. Terminating calls to an ICS-user are routed through an IA after terminating services execution in IMS and from there forwarded to the ICS-user over the CS-network. The same protocols and procedures that are used for ordinary terminating CS-calls are used to deliver the call to the ICS-user. Mobile Application Part (MAP) protocol is used to retrieve the roaming number from the MCS/VLR via the HLR, and ISDN User Part (ISUP) or a similar protocol is used to subsequently set up the roaming forwarding leg to the serving MSC/VLR.

Figure 4 illustrates the procedure for setting up a terminating call to an ICS user. The steps are as follows:

1. After terminating services execution in an IMS network, the call is routed to the IA (the IA receives a SIP INVITE message). 2. The IA queries the user's HLR for a roaming number, using the MAP Send Routing Info procedure.

3. The HLR sends a MAP Provide Roaming Number to the serving MSC/VLR. The MSC/VLR allocates a roaming number and returns it to the HLR.

4. The HLR returns the roaming number to the IA in the Send Routing Info response.

5. The IA forwards the call to the serving MSC/VLR, using ISUP or a similar protocol with the allocated roaming number as a called party.

6. The MSC/VLR sends a SETUP message to deliver the call to the ICS-user.

In the above example the roaming forwarding, i.e. querying the HLR for a roaming number and forwarding the call to that roaming number, is handled by the IA. It is also possible for the IA to route the call via a GMSC that will perform the roaming forwarding to the visited MSC/VLR. An example of a method of enforcing a call to be routed via a GMSC is by prefixing the called party number (MSISDN).

The above description refers to an IMS Adapter. The function of the IA may be performed by an Media Gateway Control Function (MGCF) at the border between a PSTN/ISDN network and an IMS network. Alternatively, this function may be performed by a network entity within an IMS network (the CS Adaptation Function in 3GPP Technical Specification 23.206, Voice Call Continuity between CS and IMS, is an example of a network entity that may perform the IA-function). Figures 2 to 4 illustrate the IA integrated with a MGCF.

IMS offers a number of features compared to traditional PSTN/ISDN services that may be useful to users of CS networks. However, some of these features rely on end-user information which is exchanged over the SIP protocol in IMS, but which cannot be conveyed over the PSTN/ISDN protocols used to access IMS services over a CS network. Examples of such end-user information are SIP-URIs and Caller Preferences. Because SIP URIs cannot be conveyed over PSTN/ISDN networks, ICS users cannot establish calls to IMS users using SIP-URIs (e.g. sip:firstname. lastname@operator.com), but can only establish calls to users using MSISDNs/TEL-URLs when placing calls in a CS network. Similarly, ICS users may wish to use Caller Preferences to, for example, indicate that an originating call must not be forwarded to a mail system. Note that whilst the SIP protocol is specifically referred to, the same problem arises with other session establishment protocols that cannot be conveyed over PSTN/ISDN protocols.

Summary

Additional signalling is required to allow ICS users to exploit the capabilities of IMS. To extend the PSTN/ISDN protocols to support the applicable IMS-specific information elements would be very cumbersome and would have a significant impact on existing standards and legacy networks, especially the MSC/VLRs.

According to a first aspect of the invention, there is provided a method of communicating between user equipment on a Circuit Switched access network, and an IP Multimedia Subsystem network. The method comprises sending call/session establishment protocol-related information over a signalling channel of the Circuit Switched access network between an IP Multimedia Subsystem Adapter function and the user equipment.

It is preferred that the call session/establishment protocol is Session Initiation Protocol, as this is the protocol used by IMS for establishing sessions. In this case, the information may conveniently be sent in the form of text.

The information may be sent using Unstructured Supplementary Service Data. This allows communication between the user equipment and the IP Multimedia Subsystem Adapter function of information that could not normally be sent using typical PSTN/ISDN protocols.

In order to reduce signalling, the method may comprise requesting additional call information in response to an indication from user equipment. For originating calls, additional information will not be requested in every case, but only where it has been requested. The indication may, for example, be the inclusion of additional information in a called party number, or it may simply be calling a specific called party number.

The method may comprise sending to the IP Multimedia Subsystem Adapter function an address of an intermediate node via which the user equipment accesses the access network. Typically, the intermediate node may be a Mobile-services Switching Centre or a Visitor Location Register.

For terminating calls, the method may comprise checking whether a subscriber policy permits the sending of call/session establishment protocol-related information prior to sending the information. In this way a network operator can control the amount of signalling in establishing a call between an IMS network and user equipment on a Circuit Switched network.

The call/session establishment protocol-related information may include information such as a Session Initiation Protocol Uniform Resource Identifier, Caller Preferences, From Field, and P-Asserted Id.

According to a second aspect of the invention, there is provided user equipment for use in a Circuit Switched access network, comprising means to send and receive Session Initiation Protocol-related information using Unstructured Supplementary Service Data.

According to a third aspect of the invention, there is provided an IP Multimedia Subsystem Adapter (IA) comprising means to send and receive Session Initiation Protocol-related information using Unstructured Supplementary Service Data from user equipment on a Circuit Switched access network.

According to a fourth aspect of the invention, there is provided a Global System for Mobile Communications Service Control (gsmSCF) Function node comprising: a receiver for receiving a communication from a Mobile-services Switching Centre or Visitor Location Register, the communication including the address of the Mobile-services Switching Centre or Visitor Location Register; a transmitter for transmitting the Mobile-services Switching Centre or Visitor Location Register address to an IP Multimedia Subsystem Adapter.

In most instances, the gsmSCF is co-located with the IA.

Brief Description of the Drawings

Figure 1 illustrates schematically the integration of an IP Multimedia Subsystem into a mobile communications system;

Figure 2 illustrates an example of the hardware required to access IMS services from a Circuit Switched network;

Figure 3 illustrates the procedure for statically routing an originating ICS call to an IMS network via an IMS adapter using CAMEL;

Figure 4 illustrates the procedure for setting up a terminating call to an ICS user;

Figure 5 is a flow diagram illustrating the procedure for routing call information;

Figure 6 illustrates the procedure for routing call information where the call originates from an ICS user; and Figure 7 illustrates the procedure for routing call information where the call terminates at an ICS user.

Detailed Description

According to an embodiment of the invention, a signalling channel that is capable of carrying information, such as text, is established between the user's user equipment and an IMS Adapter function. The signalling channel is used to exchange SIP specific information that could not otherwise be exchanged using conventional CS protocols. This is illustrated in Figure 5.

Unstructured Supplementary Service Data (USSD) is a standard for transmitting information over GSM signalling channels, and is defined in GSM 02.90 (UMTS 22.090) and GSM 03.90 (UMTS 23.090). USSD may be used for the signalling channel between the user equipment and the IA. USSD is built into Global System for Mobile Communications (GSM) standards for supporting the transmission of information over GSM networks, and can also be used with Universal Mobile Telecommunications Systems (UMTS) technologies. USSD allows user interaction between applications based on a GSM/UMTS Public Land Mobile Network (PLMN) and user equipment.

A USSD message may be initiated by either the network, the UE (the term UE is herein used as a generic name that incorporates Mobile Stations, MS, and other terminal types) or a subscriber using the UE. In network initiated USSD messages, the network may either request information from the UE, or information may be simply sent and displayed to the UE.

In the case of a call originating from an ICS-user, such calls are statically routed to an IA, using, for example, CAMEL. Standard PSTN/ISDN call information such as the called party number and calling party number are conveyed to the IA from the serving MSC/VLR in this process. Upon reception of the call the IA checks whether the user has indicated the existence of additional call information that could not be conveyed by the CS protocols used to set up the call to the IA. The existence of additional information can be indicated by means of, for example, a specific called party number, or a specific prefix appended to the called party number. When a specific called party number is used to instruct the IA to query the user for additional call information, the receiver of the call itself is provided as part of the additional information.

When a user has indicated that additional call information exists, the IA sets up a separate ICS signalling channel to the user to retrieve the additional call information. Whilst the signalling channel is described as a 3GPP USSD channel, other mechanisms may be used in place of USSD, for example SMS. When using USSD the calling party number (MSISDN) is used to establish the USSD dialogue between the IA and the user. The protocols and procedures necessary to establish the USSD dialogue already exist within the 3GPP standard. A new USSD Service Code, however, must be assigned and used to identify queries for additional end-user information in ICS. By providing an indication that additional call information exists, unnecessary signalling is reduced, as no USSD channel is set up between the IA and the user equipment unless the indication of additional call information is provided.

To establish the USSD dialogue the IA needs to know the address of the MSC/VLR where the user is currently present. The CAMEL message between the MSC/VLR and gsmSCF contains the MSC/VLR address (E.164 number). This address is forwarded to the IA (step 3 of Figure 6). The IA then uses the MSC/VLR address to set up a Network Initiated USSD dialogue for querying the UE for additional call information.

The query also includes the called party number to allow the user to identify the call to which the query refers. This may be needed if, for example, a user originates and immediately disconnects a call, and subsequently originates a new call. To avoid signalling races and associating a query with the wrong call, a user should not initiate a call to the same called party number until the first call has been queried for additional information, or a short timer has expired. The basic call information received in conjunction with routing the call to the IA together with the additional information retrieved from the user over the ICS signalling channel is used by the IA to format an originating SIP INVITE message on behalf of the user. This SIP message is then forwarded into IMS for originating services execution, according to standard IMS procedure.

An overview of the embodiment in the case of an originating call is illustrated in Figure 6 and involves the following steps (steps 1-6 are the same as those shown in Figure 3):

1. The ICS-user originates a call;

2. The MSC/VLR informs the gsmSCF of the call origination, including call information such as called and calling party numbers (the gsmSCF contains service logic for services based on the CAMEL mechanisms);

3. The gsmSCF relays the call information to the IA;

4. The IA allocates a routing number to be used to route the originating call from the MSC/VLR to the IA and returns the routing number back to the gsmSCF;

5. The gsmSCF relays the routing number back to the MSC/VLR;

6. The MSC/VLR routes the originated call onwards to the IA using the allocated routing number as the called party number;

7. The IA receives the call and uses the called party number (routing number) to associate the received call with the call information conveyed in steps 2-3. The IA also queries the user for additional call information, if the user has indicated that such information exists;

8. The user responds with the additional call information; 9. The IA formats a SIP INVITE message, based on the call information received during the static routing of the call to the IA plus the received additional call information, and forwards the SIP INVITE into IMS for originating call processing.

Figure 6 shows the logical view of the Network Initiated USSD dialogue between the IA and the user. Physically the USSD dialogue may be set up in any of the following ways:

1. Via the HLR and MSC/VLR using the user MSISDN as a "Global Title" in the No.7 network.

2. Directly via the MSC/VLR by first querying the user's HLR for the MSC/VLR address. Querying for the MSC/VLR address can be done with the MAP operation "Send Routing Info for SM".

3. Directly via the MSC/VLR using the MSC/VLR address forwarded to the IA by the gsmSCF in step 3 above. This is the preferred solution since it limits the signalling in terms of messages and involved nodes.

Where a call from an IMS network terminates with the ICS user equipment, the call is routed through an IA after terminating services execution in IMS. When receiving a SIP INVITE the IA first checks if any call information exists that cannot be conveyed over the protocols used in the CS-network and which will have to be sent using the ICS signalling channel. In order to limit the signalling an embodiment of the invention limits the sending of the call information that cannot be conveyed over the protocols used in the CS-network to the following circumstances:

• Only those subscribers that have specifically subscribed to an "additional call information" service. This assumes that the IA has access to such subscriber information. • Only those information elements which are relevant for the services that the user has subscribed to are sent as additional call information (for example, the. caller's SIP- URI is sent only if the recipient user has subscribed to a Calling Line Presentation service).

• To further limit information transfer, operators may specify a subset of IMS specific information elements that are considered for transferring as additional call information.

When the IA has determined that additional call information exists, the IA initiates a communication with the user over the ICS-signalling channel to inform the user of the additional call information for a terminating call which is about to be set up. The IA then sets up the terminating call over the CS-network to the recipient ICS-user using the same protocols and procedures as for ordinary terminating CS-calls, as illustrated in Figure 4. To avoid race conditions the IA waits for an acknowledgement from the user equipment of the additional call information before setting up the terminating call.

The IA may include the caller's MSISDN (TEL-URI) in the additional call information, if it is present on the terminating IMS side. This allows the recipient user to explicitly correlate the incoming CS-call with the additional information sent over the ICS signalling channel.

An overview of the terminating call case, based on a USSD ICS signalling channel, is shown in Figure 7 and involves the following steps (steps 5-9 described below are the same as steps 2-6 described for Figure 4):

1. After terminating services execution in IMS the call is routed to the IA (the IA receives a SIP INVITE message). If the user subscribes to the "additional call information" service, the IA checks whether any additional call information exists that needs to be transferred to the recipient user over an ICS signalling channel. 2. Where additional information exists, the IA initiates a communication with the user over a USSD signalling channel to deliver this information. The USSD communication is established as a MAP Network Initiated USSD request via the recipient subscriber's HLR.

3. The HLR sends the USSD message to the MSC/VLR where the subscriber is located.

4. The Network Initiated USSD request is sent to the user equipment, which stores the information, acknowledges the request and waits for a terminating CS call. Since a signalling communication channel already exists between the user and the serving MSC/VLR as a result of the USSD request, no paging is needed when the CS call arrives. This speeds up the call set up.

5. The IA queries the user's HLR for a roaming number, using the MAP Send Routing Info procedure. Querying the HLR for a roaming number is not done until the user has acknowledged receipt of the additional call information to avoid race conditions. To speed up the call set up, the roaming number query may be carried out in parallel with the additional call information signalling in steps 2-4. In such a case, step 8 below is not performed until the user has acknowledged receipt of the additional call information. This procedure requires that the time supervision of allocated roaming numbers in the serving MSC/VLR is long enough to bridge the time to receive the user acknowledgement plus the time to forward the terminating call to the MSC/VLR).

6. The HLR sends a MAP Provide Roaming Number to the serving MSC/VLR. The MSC/VLR allocates a roaming number and returns it to the HLR.

7. The HLR returns the roaming number to the IA in a Send Routing Info response. 8. The IA forwards the call to the serving MSC/VLR, using ISUP or a similar protocol, with the allocated roaming number as a called party number.

9. The MSC/VLR sends a SETUP message to deliver the call to the ICS-user.

10. The ICS user's UE informs the user of the incoming call through the normal MMI, and also displays additional information such as caller's SIP-URI, if received. The UE also acknowledges the reception of the terminating call to the IA via USSD (the USSD dialog may then be terminated).

11. The call set up then proceeds as for normal GSM calls.

In the above example the roaming forwarding is handled by the IA. It is also possible for the IA to route the call via a GMSC that will perform the roaming forwarding to the visited MSC/VLR. Furthermore, in step 5 it is suggested that querying the HLR for a roaming number is not done until the user has acknowledged receipt of the additional call information to avoid race conditions. An alternative to this would be to delay querying the HLR for a roaming number until after a pre-determined time has elapsed.

The invention allows the exchange of additional call information, which cannot be carried by the CS-network protocols, between an IA and an ICS user using USSD or an equivalent protocol. By limiting the exchange of additional call information, signalling is reduced. For an originating call, the IA may be provided with the MSC/VLR address necessary to setup a USSD dialogue directly towards the serving MSC/VLR from the gsmSCF. This allows ICS users to benefit from additional IMS features which otherwise would not be available due to the inability of current PSTN/ISDN protocols to convey certain SIP specific information elements.

It will be appreciated by the person of skill in the art that various modifications may be made to the above-described embodiments without departing from the scope of the present invention. For example, the embodiments described above use USSD for the signalling channel, but other standards such as SMS may be used in place of USSD.

Claims

CLAIMS:

1. A method of communicating between user equipment on a Circuit Switched access network, and an IP Multimedia Subsystem network, the method comprising sending call/session establishment protocol-related information over a signalling channel of the Circuit Switched access network between an IP Multimedia Subsystem Adapter function and the user equipment.

2. A method according to claim 1, wherein the call session/establishment protocol is Session Initiation Protocol.

3. A method according to claim 1 or 2, wherein the information is sent in the form of text.

4. A method according to claim 1, 2 or 3, comprising sending the information using Unstructured Supplementary Service Data.

5. A method according to any one of the preceding claims, comprising requesting additional call information in response to an indication from user equipment.

6. A method according to claim 4, wherein said indication is selected from one of including additional information in a called party number, and calling a specific called party number.

7. A method according to any one of the preceding claims, comprising sending to the IP Multimedia Subsystem Adapter function an address of an intermediate node via which the user equipment accesses the access network.

8. A method according to any one of claims 1 to 4, comprising checking whether a subscriber policy permits the sending of call/session establishment protocol-related information prior to sending the information.

9. A method according to any one of the preceding claims, wherein the call/session establishment protocol-related information includes information such as a Session Initiation Protocol Uniform Resource Identifier, Caller Preferences, From Field, and P- Asserted Id.

10. User equipment for use in a Circuit Switched access network, comprising means to send and receive Session Initiation Protocol-related information using Unstructured Supplementary Service Data.

11. An IP Multimedia Subsystem Adapter comprising means to send and receive Session Initiation Protocol-related information using Unstructured Supplementary Service Data from user equipment on a Circuit Switched access network.

12. A Global System for Mobile Communications Service Control Function node comprising: a receiver for receiving a communication from a Mobile-services Switching

Centre or Visitor Location Register, the communication including the address of the

Mobile-services Switching Centre or Visitor Location Register; a transmitter for transmitting the Mobile-services Switching Centre or Visitor

Location Register address to an IP Multimedia Subsystem Adapter.