1 / 9

Fast Cell Switching in Distributed Architecture

Fast Cell Switching in Distributed Architecture. Qualcomm, Lucent, Airvana, Nortel, Hitachi December 2006. Background.

elon
Télécharger la présentation

Fast Cell Switching in Distributed Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Fast Cell Switching in Distributed Architecture Qualcomm, Lucent, Airvana, Nortel, Hitachi December 2006

  2. Background • In TSG-A.2, contributions ‘A20-20061030-003 SS Centralized vs Distributed Evolved Architecture’ and ‘A20-20061030-004 Fast Cell Selection in Evolved Architecture’ from Samsung argue that: “The distributed architecture leads to a simpler RAN implementation, since the mobile’s MIP address can be used to route packets through the RAN. However, by moving ROHC and RLP to the edge of the network, features like fast cell selection (handoff) will become much more complex. It is not possible to effectively do fast cell selection and re-initialize RLP and ROHC on each handoff. Two possible solutions: • Context passing or state information sharing between TFs in the Active Set. This may lead to increased inter-TF signaling and/or additional air interface messaging. • Synchronous network data delivery in the FL (all TFs in the active set maintain the same ROHC, RLP states and receive FL data from an anchor-TF, and then transmit to the AT when selected). Synchronization signaling overhead in the network could be a problem.” • The UMB air-interface introduces some new features to simplify fast cell switching in distributed architecture

  3. UMB and Distributed Architecture • UMB has been designed to facilitate simple yet efficient L2/L3 handoff in a distributed architecture while still fully support a centralized architecture • UMB Fast Cell Switching (across AN) only requires very simple AN-AN co-ordination because: • Each AN has its own “route”, i.e., connection between each AN and AT is independently operated, e.g., • No PHY/MAC connection state needed to be transfer from the source AN to the target AN during Fast Cell Switching • Each AN uses independent RLP sequence number to communicate with the AT • Each AN uses independent RoHC compressor/decompressor to compress/decompress packets to/from the AT • RLP packets (e.g., partial IP packets) and signaling messages (e.g., RLP NAK) from one route can be tunneled through RLP in another route – making precise handoff timing unnecessary • No soft handoff/flow control between AN required during handoff • Stage 2 concept accepted in TSG-C WG2 • The following slides illustrate one way to support UMB Fast Cell Switching in an example distributed architecture.

  4. Example: UMB Distributed Architecture (FL) • Each AN in the AT’s Active Set has its own route • Anchor AN receives IP packets for the AT from the Internet and tunnels them to the current FL Serving AN • Each AN detects that it is a FL Serving AN autonomously and then requests GRE tunnel with Anchor AN • Previous FLSA tunnels RLP and IP packets to the current FLSA • Each AN can communicate with its peer protocols in the AT by encapsulating signaling messages in its own route then tunnel them through the current FLSA • Anchor AN will often be the same as FLSA

  5. Example: UMB Distributed Architecture (RL) • AT can communicate with its peer protocols in each AN by encapsulating signaling messages/data in its own route then tunnel them through the current RLSA • Each AN may route RL IP packets to the Internet directly or tunnel IP packets back to Anchor AN • This depends on operator’s policy • Each AN detects that it is a RL Serving AN autonomously – RLSA maybe different from FLSA • Any remaining RLP fragments for Previous RLSA route are tunneled through the new RLSA

  6. Forward-Link Serving AN Switch

  7. Reverse-Link Serving AN Switch

  8. RoHC and Fast Cell Switching • On the forward-link, since each AN has a RoHC compressor associated with its route, the serving AN uses its RoHC compressor to compress any full IP packets to be transmitted to the AT • The AT also has independent RoHC decompressor associated with each route and can apply the correct decompressor accordingly • Partial IP packets and header-compressed IP packets, while being tunneled through the serving AN, are still encapsulated in RLP of their original routes and the decompressors of the original routes will be used • Since the compressor at the AN and the decompressor at the AT are per route, the compressor/decompressor states are still in-sync after the AT has selected another route and then later reselected this route. The compressor can then optimally choose the smallest header that the decompressor can resume from • Also the same arguments apply on the reverse-link, as the AT has a RoHC compressor per route and each AN has the associated RoHC decompressor

  9. Conclusions • For Fast Cell Switching in a distributed architecture supporting UMB, there is no need for tight AN-AN coordination because of multiple routes support • Only need RLP tunnel and GRE/IP tunnel

More Related