fast cell switching in distributed architecture qualcomm, lucent, airvana, nortel, hitachi december...
Post on 19-Jan-2018
212 Views
Preview:
DESCRIPTION
TRANSCRIPT
Fast Cell Switching in Distributed Architecture
Qualcomm, Lucent, Airvana, Nortel, Hitachi
December 2006
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
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.
FLSA (FL Serving AN)
AT
Anchor ANPrevious FLSA
IP Cloud
RLP Tunnel
Route b Route cRoute a
Route a
Route b
Route c
IP
IP Packets
AT
GRE Tunnel
GRE Tunnel
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
RLSA (RL Serving AN)
Anchor ANPrevious RLSA
IP Cloud
RLPTunnel(Signaling)IP
RLP Tunnel
(RLP Fragments)
Route b Route cRoute a
Route a
Route b
Route c
IP
IP
AT
IPIP
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
Forward-Link Serving AN Switch
Tunneled Data(Full IP packets)
AT Target FLSA
(Route A)
Source FLSA/ Anchor AN(Route B)
HA
AT decides to select Target
FLSA
CQI
Data (IP)Data (RLP Route B)
DataRouteAddDataRouteAddAck
Data (IP)Data (RLP Route A)
RLP Route B {partially sent packets / compressed packets}
Phy SignalData Tunnel MsgData MIP Signal
L2 SignalRLP Tunnel
IMS SignalTunneled Data
FLAB + Data (Route B packetsencapsulated in
Route A)
Reverse-Link Serving AN SwitchAT
Target RLSA
(Route A)
HA
AT decides to switch to
Target RLSA
Request
Source RLSA/
Anchor AN(Route B)
Data (RLP Route B)
Handoff Complete
RLAB
Data (IP)
Data (RLP Route A) Data (IP)
* Packets routed either to CN, HA or anchor AN based on whether ingress filtering is on
RLP Route B {partiallyrcvd packets}
Data(Route B Packets
encapsulated in Route A)
Phy SignalData Tunnel MsgData MIP Signal
L2 SignalRLP Tunnel
IMS SignalTunneled Data
Tunneled Data* (Full IP packets)
Data (IP)
DataRouteAddDataRouteAddAck
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
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
top related