METHOD FOR MANAGING COMMUNICATION SESSIONS AND RELATED
DEVICES
The present invention relates to the management of communication sessions in a radiocommunication system.
It is applicable in particular to 2G or 3G wireless networks.
In a 3G wireless network, such as a UMTS (Universal Mobile Telecommunication System) network for instance, it is possible to have a configuration where a RNC (Radio Network Controller) is connected to multiple Core Network nodes (CN nodes) like MSCs (Mobile Switching Centers) in the circuit switched domain or SGSNs (Serving GSNs, where GSN designates a "GPRS Support Node") in the packet switched domain. Such configuration is known as Iu- Flexibility (or "Iu Flex") and is described in the technical specification 3GPP TS 23.236, "Intra-domain connection of Radio Access Network (RAN) nodes to multiple Core Network (CN) nodes". It may happen that a particular CN node, like a SGSN serving communication sessions in cooperation with a RNC, cannot serve sessions any longer. This can be the case for example if the SGSN needs to be stopped for maintenance reasons.
In such case, the ongoing sessions will be dropped after a timeout and lost. And the mobiles involved in the ongoing sessions will have to re-initiate their sessions on their own.
An object of the present invention is to avoid such inconvenience.
A more particular object of the invention is to preserve the ongoing sessions even when the CN node serving the sessions is no more available. The invention thus proposes a method for managing communication sessions in a radiocommunication system comprising a core network including a plurality of nodes and a radio access network including at least one radio network controller connected to a respective set of core network nodes, each ongoing session being served by a core network node in cooperation with a radio network controller. According to this method, ongoing sessions served by a first core network node in cooperation with a radio network controller are relocated to be
served by at least one second core network node in cooperation with said radio network controller, when the first core network node is no more available to continue to serve said ongoing sessions, the first and second core network nodes belonging to the set of core network nodes to which said radio network controller is connected.
When applied to the 3G context described in the introduction of the present application, the method allows transfer of ongoing sessions from a source CN node, like a source SGSN (or a source MSC) to a target CN node, like a target SGSN (or a target MSC), while keeping the same RNC for the sessions (source and target CN nodes belong to the same pool area). The established sessions are thus preserved even in case some maintenance activities for example are planned to occur on the source CN node.
Thus, the method allows taking an additional benefit from the presence of multiple CN nodes for one RAN (Radio Access Network) during the session. According to other aspects of the invention which may be used alone or in combination with any other one : the second core network node can be selected by the first core network node according to a predetermined criterion, where the predetermined criterion can comprise load balancing between the at least two second core network nodes ; the second core network node can be requested by the first core network node that the ongoing sessions are relocated to be served by said second core network node in cooperation with said radio network controller ; the method can comprise the steps of informing said radio network controller that the first core network node is no more available to continue to serve said ongoing sessions, and sending a request from said radio network controller to the first core network node so that the ongoing sessions are relocated to be served by at least one second core network node in cooperation with said radio network controller ; - the first core network node can be unavailable to continue to serve said ongoing sessions due to maintenance activities to come on it ;
new sessions presented to said radio network controller can be directed to be served by a third core network node in cooperation with said radio network controller, the third core network node belonging to the set of core network nodes to which said radio network controller is connected and being different from the first core network node ; the third core network can be selected within the set of core network nodes to which said radio network controller is connected, according to a predetermined criterion, where the predetermined criterion can comprise load balancing within the set of core network nodes to which said radio network controller is connected.
The invention also proposes a radiocommunication system comprising a core network including a plurality of nodes and a radio access network including at least one radio network controller connected to a respective set of core network nodes, the system being arranged for managing communication sessions so that each ongoing session is served by a core network node in cooperation with a radio network controller. The system comprises means for implementing the above- mentioned method, said means comprising means for relocating ongoing sessions served by a first core network node in cooperation with a radio network controller so that said ongoing sessions are served by at least one second core network node in cooperation with said radio network controller, when the first core network node is no more available to continue to serve said ongoing sessions, the first and second core network nodes belonging to the set of core network nodes to which said radio network controller is connected.
The invention also proposes a core network node of a core network including a plurality of nodes, the core network belonging to a radiocommunication system further comprising a radio access network including at least one radio network controller connected to a respective set of core network nodes. The core network node comprises means for, when said core network node is no more available to continue to serve ongoing sessions it serves in cooperation with a radio network controller, selecting at least one other core network node and requesting that said ongoing sessions are relocated to be served by the at least one other core network node in cooperation with said radio network controller, said core network
- A - node and at least one other core network node belonging to the set of core network nodes to which said radio network controller is connected.
The invention also proposes a radio network controller of a radio access network of a radiocommunication system further comprising a core network including a plurality of nodes, the radio network controller being connected to a set of core network nodes each arranged for serving communication sessions in cooperation the radio network controller. The radio network controller comprises means for receiving information according to which a first core network node is no more available to continue to serve ongoing sessions it serves in cooperation with the radio network controller, and means, responsive to said reception of information, for sending a request to the first core network node so that the ongoing sessions are relocated to be served by at least one second core network node in cooperation with the radio network controller, the first and second core network nodes belonging to the set of core network nodes to which the radio network controller is connected. The invention also proposes a computer program product comprising instructions for at least partly implementing the above-mentioned method, when loaded and executed on computer means of the radiocommunication system.
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 is an example of traffic routing within a radiocommunication system ;
- FIG.2 is an example of traffic routing within the radiocommunication system of FIG.1 , after relocation of ongoing sessions according to the invention ;
- FIG.3 shows possible information exchanges within a radiocommunication system, for achieving relocation according to the invention. The invention is illustrated here in its application to a 3G system, implementing Iu Flex. Indeed, the invention is particularly relevant and efficient in this application since long-lived Iu-PS connections exist. Of course, the invention
could also apply to other radiocommunication systems.
According to the invention, a session redirection procedure is used to transfer the traffic on a CN node to other CN nodes in an CN nodes pool. The redirection procedure is illustrated in the following figures. In the following, the packet switched domain is more particularly considered, so that the CN nodes in question are SGSNs. Of course, MSCs could be used instead, when considering the circuit switched domain.
FIG.1 shows a SGSN pool serving a pool area. Interruption of service due to some maintenance activities for instance is scheduled on SGSN2. In FIG.1 , the traffic of SGSN2 is indicated with thick lines. Before the maintenance can start, all the traffic on SGSN2 will be redirected to other SGSNs in the pool.
In FIG.2, all SGSN2 traffic is now redirected to new SGSNs in the pool. Maintenance activities can start on this node without any impact on end users.
In other words, all the ongoing sessions served by SGSN2 in cooperation with a given RNC are relocated to be served by another SGSN in the pool in cooperation with said RNC. The pool here represents the set of SGSNs to which the RNC is connected.
The session redirection procedure is based on the relocation procedure described in the technical specifications 3GPP TS 23.060, "General Packet Radio Service (GPRS); GPRS Tunneling Protocol (GTP) across the Gn and Gp interface", and 3GPP TS 25.413, "Universal Mobile Telecommunications System (UMTS);
UTRAN Iu interface Radio Access Network Application Part (RANAP) signalling".
Such procedure is used to relocate the ongoing sessions to a new SGSN. In the relocation procedure as per this invention, the target RNC would be the same as the source RNC so that source SGSN receiving the relocation request should be configured to determine a target SGSN of the same pool area to serve this identical
RNC.
The main steps of the session redirection procedure are shown in FIG.3. This figure shows the redirection of a session from an old to a new SGSN. The numbers of the steps described below correspond to the ones indicated in FIG.3.
1 ) The network operating company decides to perform maintenance
activities on a SGSN. The Session Redirection procedure is initiated by setting a parameter in each RNC connected to that SGSN (O&M).
At this point both uplink and downlink user data flows via the old SGSN.
Before starting the session redirection, each RNC connected to the old SGSN blocks the connection of new sessions on the old SGSN.
2) Each RNC will start relocating all the sessions connected to that SGSN. An NRI (Network Resource Identifier) is associated with this SGSN and the RNC can identify all the IMSIs connected to this NRI.
In order not to overload the Iu interface, the redirection of the sessions can be done sequentially.
The RNC sends a Relocation Required message (Relocation Type, Cause, Source ID, Target ID, Source RNC to target RNC transparent container) to the old SGSN. The Source ID and the Target ID are set to the RNC ID.
3) The old SGSN (which supports Intra Domain Connection of RAN Nodes to Multiple CN Nodes) is configured with all possible new SGSNs for each handover/relocation target RNC. The old SGSN selects one new SGSN in the SGSN pool. The selection can be based on a predetermined criterion, including for instance load balancing, i.e. load sharing.
The old SGSN initiates the relocation resource allocation procedure by sending a Forward Relocation Request message (IMSI, Tunnel Endpoint Identifier Signalling, MM Context, PDP Context, Target Identification, RAN transparent container, RANAP Cause) to the new SGSN.
The PDP context contains GGSN Address for User Plane and Uplink TEID for Data (to this GGSN Address and Uplink TEID for Data the old SGSN and the new SGSN send uplink packets). At the same time a timer is started on the MM and PDP contexts in the old SGSN.
4) The new SGSN sends a Relocation Request message (Permanent NAS UE Identity, Cause, CN Domain Indicator, Source-RNC to target RNC transparent container, RABs to be setup) to the RNC. Only the Iu Bearers of the RABs are setup between the RNC and the new SGSN.
For each requested RAB, the RABs to be setup, information elements shall contain information such as RAB ID, RAB parameters, Transport Layer Address, and Iu Transport Association. SGSN shall not establish RABs for PDP contexts with maximum bit rate for uplink and downlink of 0 kbit/s. The RAB ID information element contains the NSAPI value, and the RAB parameters information element gives the QoS profile. The Transport Layer Address is the SGSN Address for user data, and the Iu Transport Association corresponds to the uplink Tunnel Endpoint Identifier Data.
At the reception of a Relocation Request message, as the Source ID and the Target ID are the same, the RNC allocates the resources on the Iu interface to the new SGSN including the Iu user plane.
The RNC sends the Relocation Request Acknowledge message (RABs setup, RABs failed to setup) to the new SGSN.
Each RAB to be setup is defined by a Transport Layer Address, which is the RNC Address for user data, and an Iu Transport Association, which corresponds to the downlink Tunnel Endpoint Identifier for user data. For each RAB to be set up, the RNC is able to receive simultaneously downlink user packets both from the old
SGSN and from the new SGSN.
5) When resources for the transmission of user data between the RNC and the new SGSN have been allocated and the new SGSN is ready for relocation, the
Forward Relocation Response message (Cause, RANAP Cause, and RAB Setup Information) is sent from the new SGSN to the old SGSN.
6) The following CAMEL procedure calls shall be performed (see referenced procedures in 3GPP TS 23.078) CAMEL_GPRS_PDP_Context_Disconnection, CAMEL_GPRS_Detach and
CAMEL_PS_Notification.
They are called in the following order:
- The CAMEL_GPRS_PDP_Context_Disconnection procedure is called several times: once per PDP context. The procedure returns as result "Continue". - Then the CAMEL_GPRS_Detach procedure is called once. The procedure returns as result "Continue".
- Then the CAMEL_PS_Notifιcation procedure is called once. The procedure returns as result "Continue".
7) The old SGSN continues the redirection procedure by sending a Relocation Command message to the RNC. 8) On reception of Relocation command, the RNC switches the uplink connection from the old SGSN to the new one. For all RABs, the RNC starts transmission of uplink user data to the new SGSN.
The RNC sends the Relocation Detect message to the new SGSN.
9) After transmission of the Relocation Detect message, the RNC sends the Relocation Complete message to the new SGSN.
The purpose of the Relocation Complete procedure is for the RNC to indicate the completion of the relocation of the session on the Iu interface.
10) Upon receipt of the Relocation Complete message, the new SGSN shall signal to the old SGSN the completion of the relocation procedure by sending a Forward Relocation Complete message.
11 ) Upon reception of the Relocation Complete message, the new SGSN sends Update PDP Context Request messages (new SGSN Address, SGSN Tunnel Endpoint Identifier, QoS Negotiated, serving network identity) to the GGSNs concerned. The SGSN should send the serving network identity to the GGSN. The GGSNs update their PDP context fields and return an Update PDP Context Response (GGSN Tunnel Endpoint Identifier).
The RNC monitors the data received on both Iu interfaces (old and new). When downlink data is received on the new Iu connection, the RNC switches the downlink path to the new Iu connection. 12) Upon receiving the Forward Relocation Complete message, the old
SGSN sends an Iu Release Command message to the RNC. When the RNC data- forwarding timer has expired the RNC responds with an Iu Release Complete.
13) The new SGSN informs the HLR (Home Location Register) of the change of SGSN by sending Update Location (SGSN Number, SGSN Address, IMSI, IMEISV) to the HLR.
14) The HLR sends Cancel Location (IMSI, Cancellation Type) to the old SGSN with Cancellation Type set to Update Procedure.
The old SGSN acknowledges with Cancel Location Ack (IMSI).
15) The HLR sends Insert Subscriber Data (IMSI, GPRS Subscription Data) to the new SGSN. The SGSN constructs an MM context for the MS (Mobile
Station) and returns an Insert Subscriber Data Ack (IMSI) message to the HLR.
16) The HLR acknowledges the Update Location by sending Update Location Ack (IMSI) to the new SGSN.
17) The new SGSN sends a P-TMSI Reallocation Command message to the MS. The new P-TMSI includes the NRI (Network Resources Identifier) of the new SGSN. The MS returns a P-TMSI Reallocation Complete message to the SGSN.
It should be understood that other information exchanges could be carried out as well, in view of relocating the ongoing sessions served by a source SGSN in cooperation with a RNC so that they are served by at least another SGSN of the pool in cooperation with said RNC.
In particular, the source SGSN could be aware of the maintenance activities to come on it. Thus, it could initiate the relocation procedure on its own without receiving any request from the RNC. This avoids the step 1) of informing the RNC of the maintenance activities to come on the source SGSN.
Advantageously, new sessions presented to a given RNC can be directed to be served by another SGSN in the pool in cooperation with said RNC. The selection of this SGSN can be achieved according to a predetermined criterion, such as load balancing within the SGSN pool. Some or all the steps described above could be carried out by virtue of one or several computer programs loaded and executed on computer means of the radiocommunication system.