A New Approach for Serving Radio Network Controller Relocation in UMTS All-IP Network

A New Approach for Serving Radio Network Controller Relocation in UMTS All-IP Network
of 9
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  A New Approach for Serving Radio Network Controller Relocation in UMTS All-IP Network  Ai-Chun Pang ∗ , Yi-Bing Lin † , Hsien-Ming Tsai ‡ and Prathima Agrawal §∗ Dept. of Comp. Sci & Info. Engr., National Taiwan UniversityTaipei, Taiwan, R.O.C.; Email: † Chair Professor, Providence UniversityTaichung, Taiwan, R.O.C.; Email: ‡ Quanta Research Inst., Quanta Computer Inc.Taoyuan, Taiwan, R.O.C.; Eamil: § Internet Architecture Research Lab., Telcordia TechnologiesMorristown, NJ 07960-6438;  Abstract —To support real-time multimedia services in UMTSall-IP network, 3GPP TR 25.936 proposed two approachesto support real-time  Serving Radio Network Controller   (SRNC)switching, which require packet duplication during SRNC re-location. These approaches significantly consume extra systemresources. This paper proposes the  fast SRNC relocation  (FSR)approach that does not duplicate packets. In FSR, a packetbuffering mechanism is implemented to avoid packet loss at thetarget RNC. We propose an analytic model to investigate theperformance of FSR. The numerical results show that packet lossat the source RNC can be ignored. Furthermore, the expectednumber of packets buffered at the target RNC is small, whichdoes not prolong packet delay. I. I NTRODUCTION Mobility, privacy and immediacy offered by wireless accesscommonly create new opportunities for Internet business,and mobile networks are becoming a platform that providesleading-edge Internet services. Through integration of theInternet and the third generation (3G) wireless communication,next generation telecommunications networks will provideglobal information access for mobile users [11]. 3GPP [1],[5], [6] proposed the  Universal Mobile TelecommunicationsSystem  (UMTS) all-IP architecture to integrate the IP andwireless technologies, which has evolved from the GSM, General Packet Radio Service  (GPRS), and UMTS Release1999.Figure 1 shows a UMTS all-IP network architecture (anotherUMTS all-IP option can be found in [1], [5]). In this figure,the dashed lines represent signaling links, and the solid linesrepresent data and signaling links. The UMTS all-IP network connects to the  Packet Data Network   (PDN; see Figure 1 (a))or the  IP Multimedia Core Network Subsystem  (see Fig-ure 1 (b)) through the  Serving GPRS Support Node  (SGSN; seeFigure 1 (c)) and the  Gateway GPRS Support Node  (GGSN;see Figure 1 (d)). The SGSN connects to the radio accessnetwork. The GGSN provides interworking with the externalPDN, and is connected with SGSNs via an IP-based GPRSbackbone network. Both the GGSN and SGSN communicatewith the  Home Subscriber Server   (see Figure 1 (e)) to obtainmobility and session management information of subscribers.The  UMTS Terrestrial Radio Access Network   (UTRAN) con-sists of   Node B s (the UMTS term for base stations; seeFigure 1 (f)) and  Radio Network Controller  s (RNCs; seeFigure 1 (g)) connected by an ATM network. A  user equip-ment   (UE; see Figure 1 (h)) communicates with one or moreNode Bs through the radio interface  Uu  based on the  Wideband CDMA  (WCDMA) radio technology [8].In the UMTS all-IP network, the IP packets are routedbetween the UE and the GGSN. By using the  Packet DataProtocol  (PDP) context activation procedure [4], a PDP con-text is created to establish the routing path for IP packetdelivery. Besides the packet routing information (e.g., the UE’sIP address), the PDP context also contains the QoS profiles andother parameters. Due to the CDMA characteristics, multipleradio paths (for delivering the same IP packets) may existbetween the UE and more than one Node Bs. An exampleof multiple routing paths is illustrated in Figure 2 (a). Inthis figure, an IP-based  GPRS Tunneling Protocol  (GTP)connection is established between the GGSN and RNC1. TheUE connects to two Node Bs (B1 and B2). Node B1 isconnected to RNC1, and Node B2 is connected to RNC2. AnIur link between RNC1 and RNC2 is established so that thesignal (i.e., IP packets) sent from the UE to Node B2 can beforwarded to RNC1 through RNC2. RNC1 then combines thesignals from Node B1 and B2, and forwards them to SGSN1.Similarly, the packets sent from the GGSN to RNC1 will beforwarded to both Node B1 and RNC2 (and then Node B2). Inthis example, RNC1 is called the  Serving RNC   (SRNC). RNC2is called the  Drift RNC   (DRNC), which transparently routesthe packets through the Iub (between the Node B and the RNC)and Iur (between two RNCs) interfaces. Suppose that the UEmoves from Node B1 toward Node B2, and the radio link between the UE and Node B1 is disconnected. In this case,the routing path will be  < UE ↔ Node B2 ↔ RNC2 ↔ RNC1 ↔ SGSN1 ↔ GGSN >  as shown in Figure 2 (b). 0-7803-8356-7/04/$20.00 (C) 2004 IEEEIEEE INFOCOM 2004  Node BNode B RNCRNCUTRANHSSCore Network UEUE PDN IMS: IP Multimedia Core Network Subsystem HSS: Home Subscriber ServerGGSN: Gateway GPRS Support Node UE: User EquipmentRNC: Radio Network Controller SGSN: Serving GPRS Support Node Node B: Base Station PDN: Packet Data Network UTRAN: UMTS Terrestrial Radio Access Network  SGSNSGSN GGSNIMS g ab cdef signalingsignaling and data h Fig. 1. The UMTS All-IP Network Architecture GGSNSGSN1SGSN2Node B1Node B2GGSNSGSN1SGSN2Node B1Node B2GGSNSGSN1SGSN2Node B1Node B2UEUEUE (a) The UE connects to bothB1 and B2(c) The UE connects to B2(After Relocation) packet routing path (b) The UE connects to B2(Before Relocation) IurIubIubIurIubIubIurIubIubRNC2RNC1RNC1RNC2RNC2 RNC1 (Source RNC)(Target RNC)(Source RNC)(Target RNC)(Source RNC)(Target RNC) Fig. 2. SRNC Relocation 0-7803-8356-7/04/$20.00 (C) 2004 IEEEIEEE INFOCOM 2004  In this scenario, it does not make sense to route packetsbetween the UE and the core network through RNC1. There-fore SRNC relocation may be performed to remove RNC1from the routing path. After SRNC relocation, the packets arerouted to the GGSN directly through RNC2 and SGSN2 (seeFigure 2 (c)), and RNC2 becomes the SRNC.In 3GPP TS 23.060 [4], a lossless SRNC relocation pro-cedure was proposed for non-real-time data services. In thisapproach, in the beginning of SRNC relocation, the sourceRNC (RNC1 in Figure 2 (b)) first stops transmitting downlink IP packets to the UE. Then it forwards the next packets to thetarget RNC (RNC2 in Figure 2 (b)) via a GTP tunnel betweenthe two RNCs. The target RNC stores all IP packets forwardedfrom the source RNC. After taking over the SRNC role, thetarget RNC restarts the downlink data transmission to the UE.In this approach, no packet is lost during the SRNC switchingperiod. Unfortunately, this approach does not support real-timedata transmission because the IP data traffic will be suspendedfor a long time during SRNC switching. In order to supportreal-time multimedia services, 3GPP TR 25.936 [3] proposes SRNC duplication  (SD) and  core network bi-casting  (CNB).These two approaches duplicate data packets during SRNCrelocation, which may not efficiently utilize system resources.In this paper, we propose a new approach called  fast SRNC relocation  (FSR) to provide real-time SRNC switching withoutpacket duplication.II. R ELATED  W ORK This section describes the previously proposed SRNC re-location procedures for real-time multimedia services; that is, SRNC duplication  (SD) and  core network bi-casting  (CNB)proposed in 3GPP TR 25.936 [3].  A. SRNC Duplication (SD) Consider Figure 2 (b). Suppose that the UE is connected tothe source RNC and SGSN1 before performing SRNC reloca-tion. The target RNC is the drift RNC, which is connected tothe source RNC via the Iur interface. After SRNC relocation,the SRNC role is moved from the source RNC to the targetRNC, and the IP packets for the UE are directly routed throughSGSN2 and the target RNC (see Figure 2 (c)). Figure 3 showsthe four stages of the SD procedure. Stage I (Figure 3 (a))initiates SRNC relocation. In this stage, the user IP packetsare delivered through the old path  < GGSN ↔ SGSN1 ↔ sourceRNC ↔ target RNC ↔ UE > . The following steps are executed.1-2. When the Node B of the source RNC no longerconnects to the UE, the source RNC initiates SRNCrelocation. Specifically, the source RNC sends a Relocation Required  message (including the ID of the target RNC) to SGSN1. GGSN 243 signalingdata GGSN 6 GGSN 910 GGSN 11121213 ` (a) Stage I (b) Stage II(c) Stage III (d) Stage IV IurIurIur 578 SGSN2SGSN1 SGSN1 SGSN2SGSN1 SGSN2SGSN2SGSN1SourceRNCTargetRNCTargetRNCSourceRNC 1 TargetRNCSourceRNCTargetRNCSourceRNC Iu IuIu Fig. 3. The SRNC Duplication (SD) Approach 3. Based on the ID of the target RNC, SGSN1 deter-mines if the SRNC relocation is intra-SGSN SRNCrelocation or inter-SGSN SRNC relocation. Assumethat it is inter-SGSN SRNC relocation. By sendinga  Forward Relocation Request  message, SGSN1requests SGSN2 to allocate the resources (to bedescribed in Step 4) for the UE.4. SGSN2 sends a  Relocation Request  message withthe  Radio Access Bearer   (RAB) parameters to thetarget RNC. The RAB parameters include the trafficclass (e.g., conversational, streaming, interactive orbackground), traffic handling priority, maximum andguaranteed bit rates, and so on [2]. After all nec-essary resources for the RAB are successfully allo-cated, the target RNC sends a  Relocation RequestAcknowledge  message to SGSN2.In Stage II (Figure 3 (b)), a forwarding path  < sourceRNC → target RNC → UE >  for downlink packet delivery iscreated between the source and the target RNCs through the Iuinterface. The source RNC duplicates the packets and forwardsthese packets to the target RNC. Thus the downlink packetsare simultaneously transmitted through both the old path (viathe Iur interface) and the forwarding path (via the Iu interface)between the source RNC and the target RNC. Note that 3GTR25.936 [3] did not clearly describe if an Iu link can bedirectly established between two RNCs. If not, an indirect path < source RNC → SGSN1 → SGSN2 → target RNC >  is required. 0-7803-8356-7/04/$20.00 (C) 2004 IEEEIEEE INFOCOM 2004  To favor the SD approach, we assume a direct link betweenthe source and target RNCs. The following steps are executedin Stage II.5-6. SGSN2 sends a  Forward Relocation Response message to SGSN1, which indicates that all re-sources (e.g., RAB ) are allocated. SGSN1 forwardsthis information to the source RNC through a  Relo-cation Command  message.7. Upon receipt of the  Relocation Command  mes-sage, the source RNC duplicates the downlink pack-ets and transmits the duplicated packets to the tar-get RNC through the forwarding path (via the Iuinterface at the IP layer). The forwarded packetsare discarded at the target RNC before it becomesthe SRNC (i.e., before the target RNC receives the Relocation Commit  message at Step 8).In Stage III (Figure 3 (c)), the Iur link between the sourceRNC and the target RNC (i.e., the old path) is disconnected.The downlink packets arriving at the source RNC are for-warded to the target RNC through the Iu link (i.e., theforwarding path). A data-forwarding timer is maintained in thesource RNC. When the timer expires, the forwarding operationat the source RNC is stopped. The following steps are executedin Stage III.8. With a  Relocation Commit  message, the sourceRNC transfers  Serving Radio Network Subsys-tem  (SRNS) context (e.g., QoS profile for the RAB)to the target RNC.9. Upon receipt of the  Relocation Commit  message,the target RNC sends a  Relocation Detect  messageto SGSN2, which indicates that the target RNC willbecome the SRNC.10. At the same time, the target RNC sends a RAN Mobility Information  message to the UE.This message triggers the UE to send theuplink IP packets to the target RNC. Afterthe UE has reconfigured itself, it replies the RAN Mobility Information Confirm  message to thetarget RNC.In Stage IV (Figure 3 (d)), the packet routingpath is switched from the old path to the new path < GGSN ↔ SGSN2 ↔ target RNC ↔ UE > . At this stage, thetarget RNC becomes the SRNC. The source RNC forwards thedownlink packets to the target RNC until the data-forwardingtimer expires. The following steps are executed in Stage IV.11. SGSN2 sends a  Update PDP Context Request message to the GGSN. Based on the received mes-sage, the GGSN updates the corresponding PDP con-text and returns a  Update PDP Context Response message to SGSN2. Then the downlink packet rout-ing path is switched from the old path to the new SourceRNCGGSN 1243 signalingdata GGSN 567 GGSN 9810 GGSN 11121213 ` (a) Stage I (b) Stage II(c) Stage III (d) Stage IV Iur IurIur SGSN1 SGSN2 SGSN1 SGSN2SGSN1 SGSN2 SGSN1 SGSN2TargetRNCTargetRNCSourceRNCSourceRNCTargetRNCSourceRNCTargetRNC Fig. 4. The Core Network Bi-casting (CNB) Approach path. At this moment, the target RNC receives thedownlink packets from two paths (i.e., the forwardingand new paths), and transmits them to the UE. Sincethe transmission delays for these two paths are notthe same, the packets arriving at the target RNCmay not be in sequence, which results in out-of-orderdelivery.12. By sending the  Relocation Complete  messageto SGSN2, the target RNC indicates thecompletion of the relocation procedure. ThenSGSN2 exchanges this information with SGSN1using the  Forward Relocation Complete  and Forward Relocation Complete Acknowledge message pair.13. Finally, SGSN1 sends an  Iu Release Command message to request the source RNC to release the Iuconnection in the forwarding path. When the data-forwarding timer expires, the source RNC replies an Iu Release Complete  message.  B. Core Network Bi-casting (CNB) Figure 4 shows the four stages of the CNB procedure whenthe communicating UE moves from the source RNC to thetarget RNC. Stage I (Steps 1-4, Figure 4 (a)) is the same asStage I in SD, which requests the target RNC to allocate thenecessary resources for relocation. 0-7803-8356-7/04/$20.00 (C) 2004 IEEEIEEE INFOCOM 2004
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!