WO2008053013A1

WO2008053013A1 - Moving between communications domains

Info

Publication number: WO2008053013A1
Application number: PCT/EP2007/061741
Authority: WO
Inventors: Kazuhiko Nakada; Bo ÅSTRÖM; Ralf Keller
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2006-11-03
Filing date: 2007-10-31
Publication date: 2008-05-08
Anticipated expiration: 2009-05-03
Also published as: GB0621927D0; GB2443462A

Abstract

There is provided a method and apparatus for operating a node in a communications network. The method comprises receiving a message relating to a client terminal session; generating a domain transfer request indicator and a domain transfer telecommunication number; and sending to the client terminal the generated domain transfer request indicator and domain transfer telecommunication number.

Description

Moving between Communications Domains

TECHNICAL FIELD

The present invention relates to the field of moving between communications networks, and in particular to moving between an IMS network and a Circuit Switched 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 that 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.

Voice Call Continuity (VCC) is an IMS application to transfer voice calls between a Circuit Switched (CS) domain and an IMS domain. VCC is a working item in 3GPP Release 7. VCC applications can be implemented in an ISC (IP Multimedia Service Control) connected IMS Application Server, and voice calls are always anchored at the VCC application to provide voice call continuity between the CS domain and the IMS domain. The VCC application server acts as a 3^rd party call control (3pcc) Back to Back User Agent (B2BUA) and updates the media address of a VCC user access leg towards the remote end when a user moves from a CS domain to an IMS domain or from an IMS domain to a CS domain. Figure 1 illustrates schematically a signalling and media path change example when a VCC user 101 moves from a CS domain 102 to an IMS domain 103.

When a VCC Application receives an INVITE message from a new IMS domain into which a user has just moved, the VCC Application needs to identify that this is an INVITE message requesting Domain Transfer. A VCC Domain Transfer URI (VDI) is populated in a Request-URI in an INVITE message to indicate that Domain Transfer shall be performed. On receipt of an INVITE message with VDI, the VCC Application Server 104 sends a re-INVITE or UPDATE message towards the remote end 105 to inform that the access leg bearer address has changed.

In 3GPP Release 7 VCC when a user moves from a CS network to an IMS network, it is assumed that only one on-going call exists for a VCC user, and the VCC application can find the corresponding source session anchored in VCC application by VCC user's Public User ID included in the INVITE message from a new IMS domain. It is also assumed that VDI is configured in User Equipment (UE) at initial provisioning of VCC service subscription, for example using Open Mobile Alliance (OMA) Device Management (DM).

Similarly, as shown in Figure 2, when a VCC user 101 moves from an IMS domain 103 to a CS domain 102, the user dials a VCC Domain Transfer Number (VDN) in the CS domain 102 to request a Domain Transfer (using normal call control procedures). A VDN is configured at initial VCC service subscription. A VDN is typically a number common to all VCC subscribers, and cannot be used to establish a call to one specific subscriber. The common number must first be translated into a user specific VDN. Customized Application for Mobile network Enhanced Logic (CAMEL) is used for this translation. The user-specific VDN is used as a Public Service Identity (PSI) in a SIP Request-URI, i.e. a DTF PSI (Domain Transfer Function Public Service Identity) in a Media Gateway Control Function (MGCF) 201. The DTF PSI can route the call to the VCC Application server 104, which recognizes that this is a Domain Transfer request (the VCC application has provided the user-specific VDN that is subsequently used as a DTF PSI).

The Public User ID can be used to identify the single on-going call anchored in the VCC Application Server 104.

A mechanism is needed in which the UE 101 can use the VDN and VDI to uniquely identify the session to be transferred between domains by the ICS-VCC or GSC application server.

SUMMARY

According to a first aspect of the present invention, there is provided a method of operating a node in a communications network. The method comprises receiving a message relating to a client terminal session, and generating a domain transfer request indicator and a domain transfer telecommunication number. The generated domain transfer request indicator and domain transfer telecommunication number are sent to the client terminal. By generating a domain transfer request indicator and a domain transfer telecommunication number relating to a terminal session, simultaneous sessions for the same user can be identified by the client terminal, and the session to be transferred between domains can be identified.

As an option, the domain transfer request indicator is a Voice Call Continuity Domain Transfer Uniform Resource Indicator, and the domain transfer number is a Voice Call Continuity Domain Transfer Number.

The method optionally comprises sending the domain transfer request indicator and the domain transfer number in a message selected from one of a session establishment message, a Session Initiation Protocol INFO message, a Session Initiation Protocol NOTIFY message, and a Session Initiation Protocol MESSAGE message. As an option, the method comprises generating the domain transfer request indicator and the domain transfer telecommunication number in response to receipt of a session establishment message. This allows the domain transfer request indicator and domain transfer telecommunications number to be used in the initial session after registration, and also in subsequent sessions. Alternatively, the method comprises generating the domain transfer request indicator and the domain transfer telecommunication number in response to receipt of a registration message. This allows the domain transfer request indicator and domain transfer telecommunications number to be used only in the initial session after registration.

Optionally, a plurality of generated domain transfer request indicators and domain transfer telecommunication numbers are sent to the client terminal. This allows the client terminal to receive domain transfer request indicators and domain transfer telecommunication numbers for all ongoing activities in a single message.

According to a second aspect of the invention, there is provided a node in a communications network. The node comprises means for receiving a message relating to a client terminal registration or session. Means are provided for generating a domain transfer request indicator and a domain transfer telecommunication number, and means are also provided for sending to the client terminal the generated domain transfer request and domain transfer telecommunication number.

Optionally, the domain transfer request indicator is a Voice Call Continuity Domain Transfer Uniform Resource Indicator, and the domain transfer number is a Voice Call Continuity Domain Transfer Number.

The node optionally comprises means to send the domain transfer request indicator and the domain transfer number in a message selected from one of a session establishment message, a Session Initiation Protocol INFO message, a Session Initiation Protocol NOTIFY message, and a Session Initiation Protocol MESSAGE message.

The domain transfer request indicator and the domain transfer telecommunication number are optionally generated in response to receipt of a session establishment message, which allows the domain transfer request indicator and the domain transfer telecommunication number to be used in the initial session after registration, and also in subsequent sessions. Alternatively, the domain transfer request indicator and the domain transfer telecommunication number are generated in response to receipt of a registration message, which allows the domain transfer request indicator and the domain transfer telecommunication number to be used only in the initial session after registration.

Optionally, means are provided for sending a plurality of domain transfer request indicators and domain transfer telecommunication numbers to the client terminal, which allows the client terminal to receive domain transfer request indicators and domain transfer telecommunication numbers for all ongoing activities in a single message.

According to a third aspect of the present invention, there is provided a client terminal for use in a telecommunications network. The client terminal comprises means to receive a domain transfer request indicator and a domain transfer telecommunication number, and means to subsequently use the received domain transfer request indicator and domain transfer telecommunication number to initiate a domain transfer.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 illustrates schematically in a block diagram the signalling when a VCC user moves from a CS network to an IMS network;

Figure 2 illustrates schematically in a block diagram the signalling when a VCC user moves from an IMS network to a CS network;

Figure 3 illustrates schematically in a block diagram the signalling when a VCC user moves from one IP-CAN network to another IP-CAN network;

Figure 4 illustrates schematically in a block diagram the signalling when an ICS-VCC user moves from a CS network to an IMS network via an ICS Terminal Adapter; Figure 5 illustrates schematically in a block diagram the signalling when an ICS-VCC user moves from an IMS network to a CS network via an ICS Terminal Adapter;

Figure 6 illustrates schematically the signalling required to generate and deliver VDI/VDN using a session establishment message method where an IMS session is the source access leg;

Figure 7 illustrates schematically the signalling required to generate and VDI/VDN using an originating session establishment message method where an ICS session is the source access leg;

Figure 8 illustrates schematically the signalling required to generate and deliver VDI/VDN using a terminating session establishment message method where an ICS session is the source access leg;

Figure 9 illustrates schematically the signalling required to generate and deliver VDI/VDN using a SIP INFO message method where an IMS session is the source access leg;

Figure 10 illustrates schematically the signalling required to generate and deliver VDI/VDN using a SIP INFO message method where an ICS session is the source access leg;

Figure 11 illustrates schematically the signalling required to generate and deliver VDI/VDN using a SIP NOTIFY message method where an IMS session is the source access leg;

Figure 12 illustrates schematically the signalling required to generate and deliver VDI/VDN using a SIP NOTIFY message method where an ICS session is the source access leg; Figure 13 illustrates schematically the signalling required to generate and deliver VDI/VDN using a SIP MESSAGE message method where an IMS session is the source access leg;

Figure 14 illustrates schematically the signalling required to generate and deliver VDI/VDN using a SIP MESSAGE message method where an ICS session is the source access leg;

Figure 15 illustrates schematically the signalling required to generate and deliver VDI/VDN at registration where an IMS session is the source access leg;

Figure 16 illustrates schematically the signalling required to generate and deliver VDI/VDN at registration where an ICS session is the source access leg;

Figure 17 illustrates schematically in a block diagram an Application Server according to an embodiment of the invention; and

Figure 18 illustrates schematically in a block diagram User Equipment according to an embodiment of the invention.

DETAILED DESCRIPTION

In circumstances where User Equipment 301 moves from one IMS network to another IMS network, Generic Session Continuity (GSC) extends the VCC concept by providing IP Connectivity Access Network (IP-CAN) to IP-CAN continuity. GSC is an application that is typically implemented as an add-on to a VCC application, used to transfer any Communication Service (CoSe) between 2 IP-CANs 302, 303 and is implemented in an ISC connected IMS Application server 304. A CoSe session is always anchored at the GSC application server, which acts as 3pcc B2BUA and updates the media address of a GSC user access leg towards the remote end when UE 301 moves from one IP-CAN 302 to another IP-CAN 303. The example illustrated in Figure 3 shows the use of a VDI mechanism in a GSC application. A particular Domain Transfer request is identified by a VDI, and is transferred in a Request-URI in an INVITE message 305 from the new IP-CAN 303.

Although VCC R7 assumed only one on-going voice session, GSC extends this assumption to multiple numbers of any CoSe sessions. The GSC application needs the information to identify the corresponding source session to be transferred to a new IP- CAN 303 when it receives an INVITE message with a VDI. A GSC user's Public User ID is enough to identify a GSC user, but not enough to identify the concerned session if the GSC user has ongoing multiple sessions. The multiple sessions can be the same CoSe towards multiple remote users or multiple CoSe sessions to the same remote user or those combinations.

IMS Centralized Services (ICS) is a work item in 3GPP ReI 8 that makes it possible to offer IMS services over many types of access networks, such as a CS network. The

Service Engine (service implementation) resides in an IMS network, and the CS network is merely used as an access network to the services in the IMS network. In addition to providing access to the IMS service engine, ICS also extends the VCC solution developed in 3GPP ReI 7. VDIs/VDNs can be used for ICS voice call continuity.

The VDI mechanism described above can be used with ICS (IMS Centralised Service)- compliant networks, as illustrated in Figure 4. In order to support, for example, mid- call signalling, line identification services, and conference services in IMS, ICS introduces an IA (IMS Adapter (which is a CS Terminal Adapter towards IMS)) 401 and the ICS protocol carried over USSD dialogues or any other suitable bearers between a UE 301 and the IA 401. The IA 401 emulates a Proxy Call Session Control Function (P-CSCF) towards the Serving Call Session Control Function (S-CSCF) 402. A Media Proxy (MP) 403 is also introduced so that IA 401 can manipulate and control the media part on behalf of the UE 301.

In a similar manner to VCC, ICS-VCC can be implemented as an ISC connected application to transfer the voice session between an ICS CS access network and a PS access network, implemented in an IMS Application Server and typically as an extension to a VCC/GSC application. ICS-VCC also acts as 3pcc B2BUA and identifies the session transfer request by VDI in an INVITE message from a new access leg.

User Equipment 301 may move from an ICS domain 404 to an IMS domain 405. Where VCC assumes only one voice on-going session, ICS-VCC extends this assumption to multiple numbers of voice sessions and allows multiparty call session continuity. The ICS-VCC Application Server 304 therefore needs additional information to identify the concerned existing session to be transferred to an IMS network when it receives an INVITE message 406 with a VDI. The Public User ID of ICS-VCC user is not sufficient in this case since multiple sessions may be subject to domain transfer.

The same problem occurs for allocation of VDNs (and DTF PSI) in ICS-VCC when multiple calls are transferred from an IMS domain to a CS domain. Note that in ICS- VCC it might not even be possible to use CAMEL to translate a VDN to a DTF PSI. Instead, the VDN has to be used to route a call to the ICS-VCC Application Server 304 directly, and hence is used in the same way as the VDI (see Figure 5). This means that the VDN cannot be common to all ICS users as in the VCC VDN scenario described above, where the solution relied on a CAMEL translation of the common VDN into a user-specific VDN. Other means to send a user specific VDN are needed for ICS.

In order to provide a mechanism in which the UE 301 can use the VDN and VDI to uniquely identify the session which is transferred between domains by the ICS-VCC or GSC application server, there is provided a per-session dynamic VDI / VDN concept.

As compared to the VDI/VDN concept in 3GPP Release 7 VCC, which is configured at initial provisioning, a Dynamic VDI/VDN is generated on a per session basis. Session herein is assumed to mean a dialogue as specified in RFC 3261 and is identified by a "from" tag, a "to" tag and a call ID.

Dynamic VDI has the following characteristics: • The VDI is a SIP URI;

• The VDI can be recognised as a Domain Transfer request in a GSC or ICS-VCC application;

• A Dynamic VDI must identify a particular source session for a user with a Public User ID in a GSC or in an ICS-VCC Application;

• The same Dynamic VDI value may be reallocated after the concerned session has been terminated (i.e. Dynamic VDI has a life time until the session expires).

Dynamic VDN (and DTF PSI) has the following characteristics:

• The VDN is an E.164 number that is dialled from a UE 301, and which must be assigned per user and per source session to be transferred. The VDN is translated by an IA 401 into a DTF PSI. VDN and DTF PSI have a one-to-one relationship in an ICS-VCC Application Server 303. • The VDN (and corresponding DTF PSI) can be recognised as a Domain Transfer request in the ICS-VCC application;

• A Dynamic VDN (and corresponding DTF PSI) identifies a particular source session of a user with a particular Public User ID in the ICS-VCC Application. (Note - DTF PSI is also dynamically allocated to identify the target leg in 3GPP Rel7, but the dynamic nature introduced here is to identify the particular source session) ;

• The same Dynamic VDN (and corresponding DTF PSI) value is reallocated after the concerned session is terminated (i.e. Dynamic VDN (and corresponding DTF PSI) has a life time until the session expires).

Dynamic VDI/VDN delivery at session establishment

In one embodiment of the invention, a dynamic VDI/VDN is generated and delivered at session establishment. VDIs/VDIs may be delivered to a UE 301 within the established session or outside the session. This method is applicable to the first session after registration as well as subsequent sessions after registration. The VDI/VDN is always generated at each session establishment, and this is also the case for the target access leg, i.e. the VDI/VDN generated at source access leg is used for handover from a source access leg to a target access leg, but not re-used for subsequent handover from the target access leg to a further new access leg.

There are several alternative methods for VDI/VDN delivery at session establishment, including the following:

• Session establishment message

• SIP INFO message

• SIP NOTIFY message (dialogue event package)

• SIP MESSAGE message

Session establishment message

As illustrated in Figure 6, a VDI/VDN may be delivered and generated using session establishment signalling. In an originating case, a 200 OK message 601 delivers VDI/VDN to User Equipment (UE) 301, and in a terminating case, an ACK message 602 delivers the VDI/VDN to UE 301. The VDI/VDN information can be included in the SIP body of either the 200 OK message or the ACK message using an XML body, or a new SIP Information Element.

If the source access leg is an ICS leg, then a 200 OK message is mapped to an ICS call initiation result message 701 in the ICS protocol between the UE 301 and the IA 401, as shown in Figure 7. In a terminating case, the ACK message is mapped to an ICS incoming call result 801, as shown in Figure 8, in order to deliver the VDI/VDN to the UE 301.

SIP INFO message

Alternatively, the VDI/VDN may be generated and delivered to a UE 301 using a SIP INFO message 901, as illustrated in Figure 9. INFO is a general mechanism to carry application level information during the session. After a session is established, an Application Server (AS) 304 sends the VDI/VDN towards the UE 301 using an INFO message. The VDI/VDN information can be included using an XML body, or a new SIP Information Element. If the source access leg is an ICS leg, then the INFO message is mapped to ICS info 1001 in an IA 401 in order to deliver the VDI/VDN to the UE 301, as shown in Figure 10.

SIP NOTIFY message

In an alternative embodiment, the VDI/VDN is generated and delivered using an event notification mechanism and a SIP NOTIFY message, as illustrated in Figure 11. In this case the UE 301 acts as a SUBSCRIBER and the AS 304 acts as a NOTIFIER. UE 301 is subscribed to a dialogue event package of its own and receives a notification when the session is established. VDI/VDN information is included in a NOTIFY message 1101. The VDI/VDN information can be included in SIP using an XML body, or a new SIP Information Element.

If the source access leg is an ICS leg, then the NOTIFY message 1201 is mapped to an ICS notify 1202 in the IA 401 in order to deliver VDI/VDN, as illustrated in Figure 12.

SIP MESSAGE message

In a further alternative embodiment, and as illustrated in Figure 13, a SIP MESSAGE message may be used by the UE 301 to request VDIs/VDNs, and by the network to deliver VDIs/VDNs to the UE 301. The SIP MESSAGE transaction is not sent over an established SIP session, and the UE 301 therefore includes information that allows the VCC/GSC/ICS application to assign VDIs/VDNs appropriately. Such information includes the calling party ID, the called party ID, and a "transaction reference" that is used end-to-end between the UE 301 and the VCC/GSC/ICS Application Server 304 (and therefore, must not be altered by intermediate nodes). This information and the subsequent delivery of VDIs/VDNs may be sent as an XML body, or a new SIP Information Elements.

This solution also allows the UE 301 to request VDIs/VDNs for all ongoing activities in one SIP message transaction. The UE 301 includes several "request components" inside the SIP MESSAGE message 1301 ; one for each session that is to be transferred. Likewise, the VCC/GSC/ICS Application Server 304 includes several "VDI/VDN components" in the reply 1302 back to the UE 301 . When the source access leg is from an ICS domain, the SIP MESSAGE message procedure must be mapped onto an ICS procedure, as shown in Figure 14.

Dynamic VDI/VDN delivery at registration

In an alternative embodiment, VDI/VDN is generated and delivered to UE at registration. The VDI/VDN is reserved for the coming initial session. This method is only applicable to identify the initial session after registration.

A third party registration mechanism is used to inform the AS 304 that registration has taken place. A SIP MESSAGE message 1501 is used to deliver VDI/VDN towards the UE 301, as illustrated in Figure 15. The VDI/VDN information can be included in the SIP message body using XML or new SIP Information Elements.

If the source access leg is an ICS leg, then a MESSAGE message 1601 is mapped to an ICS VDI/VDN delivery message 1602in the IA in order to deliver the VDI/VDN to the UE 301, as illustrated in Figure 16.

The dynamic VDN/VDI delivery at registration can be combined with the delivery at session establishment as follows:

The UE receives a first VDI/VDN during registration. These are valid for the first session that is established by the UE 301.

The UE receives a new pair of VDI/VDN at subsequent session establishment. Unless otherwise indicated, the new pair is to be used for the next session (hence the UE 301 keeps a record of at least two pairs).

Note: In the case or registration, de-registration and / or switching off/on UE 301, the UE 301 deletes any previously stored VDI/VDNs. Referring to Figure 17, there is illustrated an Applications Server for use in a network. The application server 304 comprises a receiver 1701 for receiving a message, as described in the various embodiments above, relating to registration of the UE 301. A processor 1702 is provided for generating a VDI/VDN. A database 1703 may be provided for storing VDI/VDNs to ensure no collision with previously assigned VDI/VDNs. A transmitter 1704 is provided to send the VDI/VDN to the UE 301.

Referring to Figure 18, there is illustrated user Equipment 301. The UE 301 comprises a receiver 1801 for receiving a VDI/VDN from the AS 304, and a processor 1802 and transmitter 1803 for subsequent use of the VDI/VDN when initiating a domain transfer. The invention described herein provides for identification of simultaneous sessions for the same user (Public User Identity), and allows domain transfers to be carried out for all ongoing activities. It also provides dynamic allocation of user-specific VDI/VDN, per session allocation of user-specific VDI/VDN, and subsequent per session allocation of user-specific VDI/VDN.

Claims

CLAIMS:

1. A method of operating a node in a communications network, the method comprising: receiving a message relating to a client terminal session; generating a domain transfer request indicator and a domain transfer telecommunication number; and sending to the client terminal the generated domain transfer request indicator and domain transfer telecommunication number.

2. The method of operating a node as claimed in claim 1, wherein the domain transfer request indicator is a Voice Call Continuity Domain Transfer Uniform resource Indicator, and the domain transfer number is a Voice Call Continuity Domain Transfer Number.

3. The method of operating a node as claimed in claim 1 or 2, comprising sending the domain transfer request indicator and the domain transfer number in a message selected from one of a session establishment message; a Session Initiation Protocol INFO message; a Session Initiation Protocol NOTIFY message; and a Session Initiation Protocol MESSAGE message.

4. The method of operating a node as claimed in claim 1, 2 or 3, comprising generating the domain transfer request indicator and the domain transfer telecommunication number in response to receipt of a session establishment message.

5. The method of operating a node as claimed in claim 1, 2 or 3, comprising generating the domain transfer request indicator and the domain transfer telecommunication number in response to receipt of a registration message.

6. The method of operating a network node according to any one of the preceding claims, further comprising: sending to the client terminal a plurality of generated domain transfer request indicators and domain transfer telecommunication numbers.

7. A node in a communications network comprising: means for receiving a message relating to a client terminal registration or session; means for generating a domain transfer request indicator and a domain transfer telecommunication number; and means for sending to the client terminal the generated domain transfer request indicator and domain transfer telecommunication number.

8. The node as claimed in claim 7, wherein the domain transfer request indicator is a Voice Call Continuity Domain Transfer Uniform resource Indicator, and the domain transfer number is a Voice Call Continuity Domain Transfer Number.

9. The node as claimed in claim 7 or 8, comprising means to send the domain transfer request indicator and the domain transfer number in a message selected from one of a session establishment message; a Session Initiation Protocol INFO message; a Session Initiation Protocol NOTIFY message; and a Session Initiation Protocol MESSAGE message.

10. The node as claimed in claim 7, 8 or 9, comprising means to generate the domain transfer request indicator and the domain transfer telecommunication number in response to receipt of a session establishment message.

11. The node as claimed in claim 7, 8 or 8, comprising means to generate the domain transfer request indicator and the domain transfer telecommunication number in response to receipt of a registration message.

12. The node as claimed in any one of claims 7 to 11, comprising means for sending to the client terminal a plurality of generated domain transfer request indicators and domain transfer telecommunication numbers.

13. A client terminal for use in a telecommunications network, the client terminal comprising: means to receive a domain transfer request indicator and a domain transfer telecommunication number; and means to subsequently use the received domain transfer request indicator and domain transfer telecommunication number to initiate a domain transfer.