WO2007042122A1

WO2007042122A1 - Method for monitoring communications in a cellular radiocommunication system

Info

Publication number: WO2007042122A1
Application number: PCT/EP2006/009015
Authority: WO
Inventors: Saso Stojanovski; Kaniz Mahdi
Original assignee: Nortel Networks Limited
Priority date: 2005-10-11
Filing date: 2006-09-15
Publication date: 2007-04-19

Abstract

The invention proposes a method for monitoring communications in a cellular radiocommunication system comprising a core network including switches, at least a call continuity control function node, as well as a plurality of radio access networks connected to the core network switches, each including at least one base station capable of radio communication with mobile stations and at least one radio network controller connected to at least some of the base stations and to the core network, wherein the radio access networks include first and second access networks. The method comprises the steps of, relative to a mobile station which was in communication and had a radio link connection with at least a base station of the first access network, generating an end of communication message which includes information for differentiating between a call release and a call abort, sending said end of communication message to the call continuity control function node and upon receipt at the call continuity control function node of the end of communication message, processing the message to distinguish whether the end of communication message designates a call release or a call abort, and triggering a procedure for transferring the communication to at least a base station of the second radio access network if the end of communication message designates a call abort.

Description

METHOD FOR MONITORING COMMUNICATIONS IN A CELLULAR RADIOCOMMUNICATION SYSTEM

The present invention relates to the monitoring of communications in a radiocommunication networks. The telecommunications world is now starting to migrate from circuit to packet, specifically Voice over IP (VoIP) is starting to be more widely deployed and used in the fixed line world. The wireless domain has been working on to handle this migration to packet to deliver advanced multimedia applications and services. To this end it has developed an architecture for the SIP infrastructure known in 3GPP (3^rd Generation Partnership Project) as IP Multimedia Subsystem (IMS). This architecture is also being adopted in 3GPP2 under the name of Mobile Media Distribution (MMD), and part of various initiatives such as ETSI TISPAN in defining next generation networks in an access independent way.

The 3GPP IP Multimedia Subsystem (IMS) is a service infrastructure that enables operators to provide multimedia services. It defines a number of service support functions that provide Session/Service/QoS Control, Authentication,

Routing and Interworking support, SIP Compression, Charging, etc. A detailed description of the 3GPP IMS is provided in the technical specification TS 23.228, v6.10.0, entitled « Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2 (Release 6) », published by the 3GPP in

June 2005.

The IP Multimedia subsystem utilizes an IP-Connectivity Access Network

(IP-CAN) to transport multimedia signaling and bearer traffic. An IP-CAN is a collection of network entities and interfaces that provides the underlying IP transport connectivity between a user equipment (UE) and the IMS entities. An example of

IP-CAN is the GERAN core network with GERAN and/or UTRAN access networks.

Most of the current cellular systems, in particular the UMTS systems, comprise on the one hand a core network and on the other hand one or more radio access networks. The UMTS core network comprises two distinct domains, the circuit switched (CS) domain and the packet switched (PS) domain, in order to differentiate between the circuit switched services and the packet switched services. Some functions, such as a call setup, are handled differently and implemented in different core network nodes according to the domain in which they are completed.

There currently is an ongoing specification work in 3GPP on the provision of continuity for the voice service (Voice Call Continuity feature, VCC) between the CS domain and the IMS. The current status of this work is reflected in the content of the technical report TR 23.806, version 1.5.1 , entitled "Voice Call Continuity between CS and IMS Study (Release 7)", published by the 3GPP organization in August 2005. The VCC work addresses a variety of transition situations for the continuity of a voice call provided by either the PS or the CS domain, while supported by either 2G (GERAN) or 3G (UTRAN) access networks. The issue of transitioning between different access technologies for a voice call handled in either the PS or the CS domain has been addressed in prior work. The 3GPP TR 23.806 focuses on transitions such as transferring a voice call serviced in the CN PS domain (that is, typically, a Voice over IP call) with a 3G access technology to a service in the CN CS domain, with a 2G access technology. This transition is referred to as 3G PS to 2G CS voice mobility.

The TR 23.806 provides two methods for achieving a 3G PS to 2G CS voice mobility transition. A first method, described in section 6.3.8 of the technical report, combines a VCC transition from 3G PS to 3G CS (the voice call is transitioned on a different CN domain while serviced by the same access technology), followed by a classical radio access handover in order to transition from 3G CS to 2G CS. In a second method, referred to as CReDT (Call Reestablishment on Domain Transfer), described in Annex E of the technical report, the voice call is anchored prior to releasing the source (3G) radio resources, establishing the target (2G) radio resources and reestablishing the voice service in the CN CS domain.

Using such transition schemes requires the definition of control procedures, and in particular triggers, which can be operated either by a terminal (User Equipment, UE) or by the network. Trigger control procedures define how either a terminal or the network may decide to request the re-establishment of an active voice service to a different CN domain and/or with a different radio access technology. Such trigger can be based on the detection of a radio link failure situation. An object of the present invention is to offer a control scheme for a voice call transition.

Another object of the present invention is to process a radio link failure between a mobile station and a base station in a radio-communication system. The invention thus proposes a method for monitoring communications in a cellular radiocommunication system comprising a core network including switches, at least a call continuity control function node, as well as a plurality of radio access networks connected to the core network switches, each including at least one base station capable of radio communication with mobile stations and at least one radio network controller connected to at least some of the base stations and to the core network, wherein the radio access networks include first and second access networks. The method comprises the steps of, relative to a mobile station which was in communication and had a radio link connection with at least a base station of the first access network, generating an end of communication message which includes information for differentiating between a call release and a call abort, sending said end of communication message to the call continuity control function node and upon receipt at the call continuity control function node of the end of communication message, processing the message to distinguish whether the end of communication message designates a call release or a call abort, and triggering a procedure for transferring the communication to at least a base station of the second radio access network if the end of communication message designates a call abort.

Advantageously, said first access network is a 3G cellular access network, and said second access network is a 2G cellular access network. Advantageously, said mobile station was in a voice over internet protocol

(VoIP) communication.

Advantageously, the end of communication message which includes information for differentiating between a call release and a call abort is generated and sent at the first radio access network and designates a call abort. Advantageously, the procedure for transferring the communication to at least a base station of the second radio access network is a Voice Call Continuity procedure. - A -

Advantageously, the end of communication message which includes information for differentiating between a call release and a call abort is generated and sent at the mobile station, and designates a call release.

Advantageously, the end of communication message which includes information for differentiating between a call release and a call abort is a SIP BYE request message.

Advantageously, the end of communication message which includes information for differentiating between a call release and a call abort is a SIP BYE request message which includes a Reason Header and a status code. The invention also proposes a wireless terminal including means for implementing the above described methods.

The invention also proposes a core network including means for implementing the above described methods.

The invention also proposes a call continuity control function node including means for implementing the above described methods.

The invention also proposes a cellular radiocommunication system including means for implementing the above described methods.

The preferred features of the above aspects which are indicated by the dependent claims may be combined as appropriate, and may be combined with any of the above aspects of the invention, as would be apparent to a person skilled in the art.

- FIG 1 shows a general diagram of a cellular radiocommunication system architecture to which the invention can be applied ; and

- FIG 2 shows a diagram which illustrates the different steps of implicit notification according to the preferred embodiment of the invention.

The cellular radiocommunication system shown in Figure 1 comprises a cellular network with extensive coverage, e.g. national, managed by a general public operator.

This PLMN is conventionally divided into a core network 10, comprising interconnected switches, and two access networks 21 , 31 , a UMTS (3G) radio access network 21 and a GSM (2G) access network 31 providing the radio links with the mobile radio terminals 1.

The core network 10 is connected to fixed networks comprising a public switched telephone network (PSTN) and one or more packet transmission networks using respective protocols (PDP, Packet Data Protocol) such as X.25 or IP (Internet Protocol).

The core network 10 comprises a GERAN core network, which includes in the packet domain intermeshed switches, called GSNs ("GPRS Support Nodes"), which communicate with one another through a standardized interface called Gn. We distinguish between GGSNs 15 ("Gateway GSNs") which serve as gateways with external networks such as the Internet for example, and SGSNs 16 ("Serving GSNs") which are linked to a UTRAN through an interface called Iu. The GERAN core network includes in the CS domain mobile switching centers (MSC) combined with visitor location registers (VLR). These MSCs ensure circuit switching for circuit mode telephone or data transfer communications. Some MSCs (G-MSCs) act as a gateway with the fixed networks, especially with the PSTN.

The core network 10 also includes an IM CN subsystem 1 1 which comprises IMS entities and can be seen from an architectural viewpoint as an overlay to the GERAN core network architecture. Fig. 1 illustrates an IMS Proxy- CSCF node 12 (P-CSCF) which is the first contact point within the IM CN subsystem 1 1 . Its address is discovered by UEs, and it behaves as a SIP "Proxy" and may behave as a SIP "User Agent" (both SIP functions are described in the SIP specification RFC 3261 , « SIP: Session Initiation Protocol », published by the Internet Engineering Task Force (IETF) in June 2002). The Serving-CSCF (S- CSCF) node 13 performs the IMS session control services for the UE, and maintains an IMS session state as needed by the network operator for support of the services. The functions performed by a S-CSCF during an IMS session are: registration, session-related and session-unrelated flows, SIP signaling vis-a-vis a destination endpoint, and generation of Charging Data Records (CDR). The IMS Proxy-CSCF node 12 includes means for exchanging data with a

Policy Decision Function (PDF) node through a so-called Gq interface. The Policy Decision Function (PDF) may be a logical entity of the P-CSCF or a separate physical node. If the PDF is implemented in a separate physical node, the interface between the PDF and the P-CSCF is the Gq interface standardized in the 3GPP technical specification TS 23.207, v6.6.0, entitled "End-to-end Quality of Service (QoS) concept and architecture (Release 6)", published by the 3GPP in Sept. 2005. The Gq interface is based on the DIAMETER protocol, specified in the IETF RFC 2748, "The COPS (Common Open Policy Service) Protocol », published by the IETF in June 2000. The SIP protocol is an application layer signaling protocol, specified in the

RFCs 2543 and 3261. SIP specifies client and server entities, and procedures for initializing a communication between such entities. In this description, a "client" is any computing system that receives the services of another computing system, a "server", whether or not that client computing system also provides services to other computing systems. Two types of SIP servers are specified: proxy servers and redirection servers. Upon receipt of a request, a proxy server identifies the next node in the path towards the destination, and forwards the request to the identified node, whereas a redirection server merely indicates to the client the next node to which the request should be sent. SIP addresses are similar to electronic mail addresses, and are of the user@host form, wherein the "user" field designates for instance a user name or a phone number, and the "host" field a domain name or an address. The SIP protocol includes inter alia methods, called INVITE, BYE, REGISTER, OPTIONS and CANCEL. Responses to sent messages that correspond to these methods are defined by codes. The INVITE method is used to initialize a call session between two SIP users. The SIP protocol also provides some mobility features, and allows for a user to access services notwithstanding its location or the device/terminal used with a SIP client, thanks notably to the REGISTER methods.

Also shown on figure 1 in the IM CN subsystem 1 1 is a Call Continuity Control Function (CCCF) node 14 which provides functions for call continuity between the Circuit Switch domain and IMS entities using an IP Connectivity Access Network such as the GERAN core network 10. Further details on the functions provided by the CCCF entity can be found in section 6.2.1 of the 3GPP TR 23.806 v.1 .5.1. The IM CN subsystem 1 1 also includes an application server (AS) which provides multimedia services, and interacts with one or several Multimedia Resource Function nodes to ensure delivery of multimedia services. The architecture of the Multimedia Resource Function is provided in the 3GPP technical specification TS 23.228. In the example shown, the PLMN is a third generation network of the UMTS type (Universal Mobile Telecommunication System), and incorporates a 2G, GSM type (Global System for Mobile communications) access network (GERAN) 31 , and a 3G, UMTS type access network (UTRAN, "UMTS Terrestrial Radio Access Network"). The UTRAN is the most common access network for UMTS systems, and is composed of controllers called RNCs ("Radio Network Controllers") and of base stations called "Node B" distributed over the zone of coverage of the access network and each controlled by one of the RNCs. Shown of Fig. 1 is a UTRAN 21 which comprises a certain number of RNCs 22, some of which are linked to a SGSN of the GERAN core network 10 and/or to a MSC of the GERAN core network 10 through a so-called Iu interface (a single RNC is represented in Figure 1 ). Each RNC controls one or more nodes B 23 through a so-called interface lub. The radio interface between a node B 23 and a UMTS terminal 1 (UE, "User Equipment") is called Uu. Also shown in Fig. 1 is a GSM access network 31 , composed of base transceiver stations (BTS) 32 distributed over the 3G network coverage area for communicating by radio with mobile terminals, and base station controllers (BSC) 33 connected to the GERAN core network 10 and each monitoring the base stations 32 via so-called Abis interfaces. Of course, the invention is applicable to other types of PLMN.

The mobile station 1 includes means for communicating with 3G UMTS equipments, and is as such a UMTS terminal. It also includes means for communicating with 2G GSM equipments, and is as such also a GSM terminal. When in communication, for instance with a remote terminal, the communication is advantageously performed using 3G wireless equipments of the telecommunication system. Such 3G equipments comprises at least a 3G base station (that is a UMTS Node-B) 23 which is in communication with the UMTS terminal 1 via a radio interface. Such 3G equipments also include a RNC 22 which controls the Node-B 23 and the communication involving terminal 1. The 3G equipments also comprises, in the GERAN core network, a 3G switch, which may be either an MSC ("Mobile Switching Center") if the communication is in circuit mode (CS domain), or a SGSN if the communication is in packet mode (PS domain), with which the RNC 22 communicates.

A communication involving the mobile terminal 1 , and a distant terminal, is therefore served through the above described 3G equipments as well as other equipments in the system with which the distant terminal (remote party) communicates.

In the following we assume that a point to point voice communication between terminal 1 and another terminal takes place, using 3G equipments, in CS mode. This voice communication may be a voice over IP communication, and it is also assumed that it involves entities in the IM CN subsystem 11.

The call setup process in the UMTS PS domain uses the concept of PDP context. A PDP context is a communication session context, which may be defined as a collection of information relating to a communication session. More specifically, the PDP context contains the information necessary for transmitting the user information between the mobile, the UMTS network, and an external packet data network. Before initiating a transfer of data, the UE requests from the core network the activation of a PDP context. The core network will proceed with verifying that the attributes of the requested PDP context comply with the user subscription. Several PDP contexts can be simultaneously active for a given user. A user may indeed want to activate several concurrent sessions, e.g. in order to simultaneously check two electronic mailboxes hosted by different Internet Access providers. In such a case, the UE must activate as many PDP contexts as it needs concurrent communication sessions. The voice communication makes use of the radio interface between the terminal 1 and the Node-B 23. The RNC 22 controls radio resources, including the radio resources allocated to the terminal 1 , according to the RRC ("Radio Resource Control") described in the technical specification TS 125.331 , v5.6.0, published in September 2003 by the 3GPP organization. In particular, the RNC should detect the occurrence of specific radio conditions on the radio link between the terminal 1 and the Node-B 23, so as to trigger a process for transferring the communication on other resources, usually referred to as "handover" process.

In order to trigger the handover process, both the terminal 1 and the Node- B 23 carry out radio measurements, that includes for instance field levels on the uplink and downlink between the terminal 1 and the Node-B 23, field levels on the downlinks from neighboring cells, as well as other measurements (see section 8.4 of the above-mentioned TS 125.331 ).

A handover process will typically be triggered by a RNC when measurements completed by the base station and the terminal show that a condition for transferring the communication is met. This can be the case when the radio field level or the estimated quality level of the radio link between the terminal and the base station is too low.

In the example illustrated in Fig. 1 , the RNC 22 detects a condition for a transfer of the ongoing communication from the Node-B 23, which is a 3G equipment, to the BTS 24 which is a 2G equipment. This will happen for instance while the terminal 1 is leaving the Node-B 23 geographic coverage area, and enters the BTS 24 geographic coverage area.

In the example illustrated in Fig. 1 , the 2G BTS 32 does not support a Voice over IP bearer service for a voice communication. As a consequence, a handover process would not successfully transfer the voice over IP communication supported by the 3G wireless network (UTRAN and PS core network) to the 2G wireless network (GERAN and CS core network). In such circumstances, triggering a VCC process from 3G PS to 2G CS is very desirable.

The CReDT approach relies on the following fundamental features: firstly, the UE somehow detects the need for initiating the CReDT procedure. Secondly, upon deciding to initiate the CReDT procedure, the UE has to explicitly notify the 3G wireless network about its intent, which allows the 3G wireless network to act appropriately. In particular, the 3G wireless network will put the remote party on hold, instead of releasing the voice communication. However, in a situation of loss of radio coverage, the terminal 1 may not have sufficient information in order to trigger the CReDT procedure. For instance, the terminal 1 may not know whether or not there is a 2G cell suitable for being a target cell for a VCC procedure, at the time immediately preceding the radio link failure with the base station 23 supporting the voice communication. This will typically be the case if the so-called compressed mode has not been activated in the 3G wireless network. Also, even though the terminal 1 may be aware of the presence of a suitable 2G target base station 32, it may not know whether or not the 2G target base station 32 supports a voice over IP bearer service.

In such conditions it is likely that the radio link will fail before the UE can trigger the CReDT procedure.

When such a radio link failure occurs with the terminal 1 , it is detected by the 3G wireless network. This typically assumes the following sequence of events: the UTRAN 21 sends a radio access bearer release request message to the SGSN 16 through the Iu interface. Responsive to the reception of this message, the SGSN sends a PDP context modify request message to the GGSN, which sends, via the Policy Decision Function (PDF) node, a session abort signal to the P-CSCF 12. The P-CSCF 12 triggers a SIP BYE request to the CCCF 14.

According to a preferred embodiment of the invention, a SIP BYE request transmitted from the P-CSCF 12 to the CCCF 14 as a consequence of a radio link failure includes information which allows the CCCF 14 to differentiate it from a SIP

BYE request which would be generated by the terminal 1 upon normal release of the voice over IP communication.

The IETF (Internet Engineering Task Force) has recently defined a new SIP header referred to as the Reason Header (see Request for Comments 3326). The Reason Header may be carried in a SIP request message, and in particular a SIP BYE request. Furthermore, the SIP protocol provides additional optional information called status code (e.g. status code 503 "Service Unavailable", status code 480 "Temporarily Unavailable") which may be included either in SIP response messages or Reason Header fields. Therefore the SIP BYE request transmitted from the P-CSCF 12 to the

CCCF 14 as a consequence of radio link failure includes according to the preferred embodiment of the invention a Reason Header which carries a status code indicating to the CCCF 14 that a radio link failure event has most likely occurred. Therefore the presence of the Reason Header with an appropriate status code in a SIP BYE request shall be interpreted by the CCCF 14 as an implicit PS to CS CReDT notification. Responsive to the reception and processing of such a SIP BYE request with a Reason Header and a status code, the CCCF 14 will take whichever step required for a VCC CReDT procedure. The following is described in more details in the 3GPP TR 23.806. The CCCF 14 starts the PS to CS CReDT process and acquires an announcement port on the MRF function for application of announcement towards the remote party. It also sends a SIP message (for instance, a SIP UPDATE message) to the remote party in order to report inactivity on the user's connection and avoid inactivity timer expiry resulting in premature release of the call by the other end. The CCCF 14 then updates the remote party with the SDP of the announcement port at the MRF node to establish announcement toward the remote party. Upon detection of the radio link failure, the terminal (UE) registers with the 2G MSC. It then initiates an IMS to CS transition request towards the CCCF 14 after registering with the 2G MSC. The CCCF 14 updates the remote party with the user's CS connection information, completing the transition from 3G IMS to 2G CS. Although this approach requires some minor changes at the P-CSCF 12 function, it avoids the signaling of unnecessary information and also avoids potential false notifications.

Fig. 2 is a diagram which illustrates the different steps described above. According to another embodiment of the invention, a SIP BYE request transmitted from the VCC-capable terminal (UE) further to a normal communication release includes information which allows the CCCF 14 to differentiate it from a SIP BYE request which would be generated by the P-CSCF 12 as a consequence of a radio link failure. In particular, a SIP BYE request transmitted from the VCC-capable terminal (UE) further to a normal communication release may include a Reason Header carrying a status code which indicates to the CCCF 14 that a normal call release has occurred. The absence of the Reason Header is then interpreted by the CCCF 14 as an implicit indication that the communication session has been aborted by the P-CSCF 12, which shall be further interpreted as an implicit CReDT notification. Responsive to the reception and processing of such a SIP BYE request which does not include a Reason Header carrying the appropriate status code, the CCCF 14 may trigger a PS to CS CReDT procedure as described above.

A significant advantage of this approach is that it requires no change to the existing IMS specifications. In yet another embodiment of the invention, a SIP BYE request transmitted from the P-CSCF 12 to the CCCF 14 as a consequence of a radio link failure includes a Reason Header and status code different from the Reason Header and status code included in a SIP BYE request which would be generated by the terminal 1 upon normal release of the communication. The functions described in the present document may be implemented in one or several network entities or apparatus, and the present invention is not limited to implementation of each function in a corresponding, separate, physical network entity, apparatus or node. Interfaces designed and specified between two functions so that said functions may interoperate or cooperate with each other may be logical interfaces, for instance when both functions are implemented in the same physical node.

Claims

W E C L A I M :

1. Method for monitoring communications in a cellular radiocommunication system comprising a core network (10) including switches (15,16), at least a call continuity control function node (14), as well as a plurality of radio access networks (21 ,31 ) connected to the core network switches (15,16), each including at least one base station (23,32) capable of radio communication with mobile stations (1 ) and at least one radio network controller (22,33) connected to at least some of the base stations (23,32) and to the core network (10), wherein the radio access networks include first (21 ) and second (31 ) access networks, the method comprising the steps of, relative to a mobile station (1 ) which was in communication and had a radio link connection with at least a base station (23) of the first access network (21 ):

Generating an end of communication message which includes information for differentiating between a call release and a call abort;

Sending said end of communication message to the call continuity control function node (14);

Upon receipt at the call continuity control function node (14) of the end of communication message, processing the message to distinguish whether the end of communication message designates a call release or a call abort, and triggering a procedure for transferring the communication to at least a base station (32) of the second radio access network (31 ) if the end of communication message designates a call abort.

2. Method according to claim 2, wherein said first access network is a 3G cellular access network, and said second access network is a 2G cellular access network.

3. Method according to claim 1 or 2, wherein said mobile station was in a voice over internet protocol (VoIP) communication.

4. Method according to any one of claims 1 to 3, wherein the end of communication message which includes information for differentiating between a call release and a call abort is generated and sent at the first radio access network and designates a call abort.

5. Method according to any one of claims 1 to 4, wherein the procedure for transferring the communication to at least a base station of the second radio access network is a Voice Call Continuity procedure.

6. Method according to any of claims 1 to 5, wherein the end of communication message which includes information for differentiating between a call release and a call abort is generated and sent at the mobile station and designates a call release.

7. Method according to any of claims 1 to 6, wherein the end of communication message which includes information for differentiating between a call release and a call abort is a SIP BYE request message.

8. Method according to claim 7, wherein the end of communication message which includes information for differentiating between a call release and a call abort is a SIP BYE request message which includes a Reason Header and a status code.

9. A wireless terminal including means for implementing a method according to any of claims 1 to 8.

10. A core network including means for implementing a method according to any of claims 1 to 8.

11. A call continuity control function node including means for implementing a method according to any of claims 1 to 8.

12. A cellular radiocommunication system including means for implementing a method according to any of claims 1 to 8.