Tr@Ins6 Trackside Communication Herman Claus

335 views
286 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
335
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Tr@Ins6 Trackside Communication Herman Claus

  1. 1. Handover solution for Pico-Cells Herman Claus – based on work from Tom Van Leeuwen Siemens, Nokia Siemens Networks, OTN
  2. 2. Outline  The Project and The Company  Problem statement  Existing solutions  Radio over Fibre solution  WLAN Fast Handover  Supporting Hardware  Future evolution 2
  3. 3. The Project and the Company  During the project, the Siemens Herentals company went through a lot of changes  At the start, Siemens Herentals (formerly Atea) formed the Com Division of Siemens Belgium  Two departments were interested in this project  Siemens OTN department : world leader in track-side communication for metro, also interested in trains etc.  IP-on-trains for TGV by Siemens Services department  The project received a GO with a dual goal  Build up and exchange knowledge about IP-on-trains  Good partners  Own knowledge from Services  Build up knowledge about communication with metro  Experimental technology for OTN  IBBT knowledge
  4. 4. The Project and the Company  During the project  Siemens Com carved out from Siemens  Nokia Transmission Systems carved out from Nokia  Both merged to form Nokia Siemens Networks
  5. 5. The Project and the Company  In Herentals  Siemens Com merged with Nokia Transmission Systems  Corporate R&D at Herentals (with the exception of OTN) was spun off (160 developers) and sold to Devoteam  11 june 2008, after several months of negotiations, it was announced that the OTN group wil carve out and is due to be independend july 1st 2008 (GIMV -> see www.gimv.be for press releases and other information)  All this had its impact on the project  But with the help of he IBBT the project could be finalised  This presentation : only the OTN part of the project is described  IP-on-trains : contact Walter van Brussel, is explained in the other WPs
  6. 6. Problem statement  Communication with metro  Tunnels  Communication with trains  No cheap global wireless coverage  Cost of bandwidth for wireless is high  Bandwitdh x surface should somehow be related to cost  So : use pico-cells  For moving vehicles : handover problem  The faster the more problematic  Same solution for use in tunnels  So there is a technological problem  Remark : there is also an economical one  Base stations are expensive, so picocells are, too.
  7. 7. Problem statement  Pico-cells are a problem  Speed of access point is no problem for most technologies  But handover between cells is  Eg : WiFi : cell of 200 m diameter, speed 120 kmh,  handover every 6 seconds, bad conditions at the edge  Normally handover takes time  Problems with VPN connections etc  What is needed is  Seamless handover mechanism  Handover invisible to end-device and to network  Part of the problem solved by other WPs  Making handover invisible to end user and network  Same problem as eg satellite etc.  So : concentrate on handover mechanism
  8. 8. Existing solutions  IST projects FIFTH and MOWGLY  DVB-S2, DVB-RCS  IBBT project FAMOUS  WLAN for fast moving users  InterAccess Point protocol modification proposed  Several algorithms studied  Predicting future access point  Easily adaptable to trains and metro  Making handover mechanism faster  Eg SyncScan algorithm for optimising scanning
  9. 9. Existing solutions  On the level of fast context switching  Solutions available  Our project  Fast re-association of wireless connection  Be as standard as possible  Two solutions developed by IBBT / Ghent  Radio over fibre based solution  WLAN GAP filler solution
  10. 10. Radio over Fibre solution  Not part of the project  Idea : between antenna and electronics of the base station there is a wire  With fibre this wire can span hughe distances  So :  make many antennae, place them widely apart  connect them to one set of electronics  Use overlapping frequencies  neither base station, neither moving access point is aware of the fact that the moving access point is moving
  11. 11. Radio over Fibre solution  Some manipulation of datastreams required  See article feb 2007 IEEE Communications Magazine  Problem : economical : cost of antennae-base stations
  12. 12. WLAN Fast Handover  Handover problem : wireless layer problem  When moving from one cell to another cell  Old cell : communication dies  New cell : communication starts up  Dying and starting under bad conditions (low power budget)  Uses lots of time because of robust modulation, broadcast messages etc : normal communication in cell disrupted  Idea :  Separate the handover from normal communication in the cell  Cell 1 uses channel1 : high speed encoding  Cell 2 uses channel2 : high speed encoding  Cell 1 and Cell 2 also support channel3  Channel3 is used for handover,  overlaps in space between cells  Uses soft handover  Low-speed robust encoding
  13. 13. WLAN Fast Handover Radius Gateway Server Fast Roaming WLAN Switch for Rail Systems Data – 802.11a/g Control - 802.11h Fast Roaming Fast Roaming Fast Roaming Fast Roaming WLAN AP WLAN AP WLAN AP WLAN AP Fast Roaming WLAN Client 13
  14. 14. WLAN Fast Handover  Client  1 interface  802.11a/g data channel  802.11h control channel  Lightweight Access Points  2 interfaces  same dedicated handover frequency  limited functionality  handoff limited to change in WLAN channel  Switch  association, authentication and security
  15. 15. Handover
  16. 16. The GAP filler solution  The problem it solves  The system handles frequency handovers under good signal conditions  The handover frequency of Channel3 guarantees low speed but continuous operation of wireless link  The handover does not disrupt the high speed communication  Association with channel1, channel2 and channel3 can be done while no data is being transmitted over this paricular interface
  17. 17. Hardware  OTN developed a generic supporting hardware  Ethernet layer based data transport  Supporting TDM separated IP channels over one fibre  Transparant to all higher layers  Central switch can ‘directly’ connect to access points  Controlled delay  All channels can be serviced individually
  18. 18. Hardware Segment 1 Segment 2 Segment 11 Segment 12 10Mbps 25Mbps 10Mbps 30Mbps Backplane Backplane Backplane Backplane Logic 1 Logic 2 Logic 9 Logic 10 Ethernet programmable Switch logic Port1 Port2 Port9 Port10 User side
  19. 19. Hardware Front-end FPGA 10/100Mbps 1 10 * max. 196 Mbps 10/100Mbps 2 . Backplane . . . . 10/100Mbps 10 . Maximum 12 segments 10/100/1000Mbps 11 Maximum 784 Mbps 10/100/1000Mbps 12 2 * max. 784 Mbps
  20. 20. Future  Merging of several technolgies needed  Fast handover  Billing and access control  VPN structures  The job ain’t finished yet

×