Packet switched (PS) handover procedures are used to handover an MS (Mobile Station) with one or more packet flows from a source cell to a target cell. The source and target cells can be located within the same BSS (Base Station System), then the handover is called an Intra-BSS HO, in different BSSs within the same SGSN (Serving GPRS Support Node), then called an Inter-SGSN HO) or belong to different SGSNs (Inter-SGSN HO), or in different systems implementing different radio access technologies, called Inter-RAT (Radio Access Type)/mode HO (Intra-SGSN as well as Inter-SGSN).
Common for all handover procedures is that they comprise a PS handover preparation phase and a PS handover execution phase. Generally the PS handover preparation phase comprises the steps of making a decision in the source radio access network to request a PS (Packet Switch) handover for an MS and sending a request to the SGSN with which it was connected (old SGSN in the case of an Inter-SGSN HO), for an Inter-SGSN HO a request from the old SGSN to the new SGSN, to reserve resources in the target network nodes before ordering the MS to move to the target cell involving different procedures depending on the type of the HO. When the handover preparation phase has been successfully completed, the PS handover execution phase follows. It among other things comprises copying and forwarding packets from the old SGSN to the relevant source radio access network node and to the new, target, radio access network node. In case of an Inter-SGSN HO at the end of the handover procedure, user plane addresses are updated so that the SGSN will start receive packets from GGSN.
PS handover procedures of different types are discussed in 3GPP TS 43.129 v.6.9.0 (2006-09). Of particular concern are here IRAT PS handover procedures as referred to above which may be more complicated since they consist of handovers from one radio access technology to another.
3GPP TR 23.873 v.4.0.0 suggests a so called one tunnel approach which separates transport and control functionality of an SGSN. Suggested are a so called SGSN controller (cSGSN) which performs all control functions of an SGSN and an enhanced GGSN (Gateway GPRS Support Node), called xGGSN, performing SGSN and GGSN transport functionality. It enables a direct GTP (GPRS Tunneling Protocol) tunnel between the radio access network and the xGGSN and this means that the SGSN is bypassed as far as user plane traffic is concerned within the PS domain. The one tunnel approach is however only applicable for UTRAN/GERAN Iu mode and hence not for the GERAN Gb interface. When the so called direct or one tunnel approach is implemented, the SGSN provides the RAN (Radio Access Network) with the TEID (Tunnel Endpoint Identifier) and user plane address of the GGSN, and GGSN with the TEID and user plane address of the RAN.
The one tunnel concept has not taken the IRAT PS handover procedures as specified in 3GPP TS 43.129 into consideration. This means that if the one tunnel concept is used it may lead to very complex signalling since the downlink payload has to be routed through the source SGSN according to 3GPP TS 43.129.
3GPP TR 23.809 suggests two alternative solutions to this problem. According to one of the solutions, there is no impact on GGSN. For a PS Intra-SGSN handover from GERAN A/Gb mode to GERAN/UTRAN Iu mode, since the one tunnel approach cannot be used in GERAN A/Gb mode, two tunnels are always used in the SGSN which means that SGSN can duplicate and relay downlink data. For an Intra-SGSN PS handover from GERAN/UTRAN Iu mode to GERAN A/Gb mode, packets received by the source RNC (Radio Network Controller) are forwarded to the target BSS (Base Station Subsystem) via the SGSN. At the end of the handover procedure, user plane addresses are updated so that the SGSN will start receive packets from GGSN.
For an Inter-SGSN PS handover from UTRAN/GERAN Iu mode to GERAN A/Gb mode, downlink packets received by the source RNC are forwarded via the old and the new SGSN:s to the target BSS. At the end of the handover procedure, user plane addresses are updated so that the SGSN will start receive packets from GGSN. Thus, in the first case, in order to enable bicasting, the source RNC will copy and forward packets to SGSN where they can be forwarded to target BSS, which will forward packets to the MS to assure that there will be no or little packet loss during the handover. This means that the SGSN will receive packets on the uplink, which packets actually form part of the downlink packet flow. This may produce a complicated situation in addition to unnecessary sending of payload packets as well as control signalling. In the latter case, for an Inter-SGSN PS handover, in order to enable bicast, RNC has to copy and forward packets to the old SGSN which forwards them to the new SGSN for forwarding to the target BSS. In this case SGSN will receive uplink packets which actually form part of the downlink packet flow and a lot of unnecessary sending of payload packets and control signalling is produced.
According to the other solution, for an Inter-SGSN handover, after the handover preparation period, a new SGSN sends the new SGSN user plane tunnel information to the GGSN in an Update PDP context request message to establish the user plane between the new SGSN and GGSN. GGSN then stores both the SGSN tunnel information and source RNC/BSS tunnel information. After receiving a relocation command, the RNC forwards the downlink packets to the GGSN and the GGSN forwards them to the new SGSN. When the PS handover preparation phase is completed the new SGSN informs the GGSN that the RNC/BSS tunnel should be removed. This means that substantial signalling capacity over the Iu interface is needed since the source RNC has to be informed about the forwarding. This produces an unnecessary load on the SGSN control plane. Additionally the GGSN will have problems in keeping track of which packets that actually are uplink (UL) packets and which are downlink (DL) packets since both UL and DL packets are sent from the same RNC which leads to possible LI (Legal Intercept) and S-CDR (SGSN-Call Detail Records) mismatches and faults.
To summarize, for both solutions there will be an unnecessary signalling load as well as payload over the Iu interface and the core network. Furthermore it becomes difficult to distinguish between uplink and downlink payload packets.
USPTO Backgrounds
USPTO Backgrounds