qos - corridor
Transcription
qos - corridor
CORRIDOR Implementation examples Christophe COUTURIER, Jean-Marie BONNIN Télécom Bretagne [email protected] Dorin PANAITOPOL, Luxmiram VIJAYANDRAN Thales Communications Systems [email protected] CORRIDOR Final workshop – Lille – June 2015 QOS: A SOLUTION FOR MULTI‐SERVICE Final Workshop V i l l e n e u v e d ’ A s c q – J u n e , 2 5 th 2 0 1 5 2 Proposed solution for QoS • Based on DiffServ architecture (RFC 2475) – Classification / Shaping/ Scheduling (or routing) EF: Expedited Forwarding AF: Assured Fowarding BE: Best Effort WRED: Weighted Radom Early Detection PHB: Per Hop Behavior DSCP: DiffServ Code Point • Using RED/WRED ... – Better integration with TCP Final Workshop V i l l e n e u v e d ’ A s c q – J u n e , 2 5 th 2 0 1 5 3 QoS: Proposed architecture • Downlink – on home agent – To be investigated • Uplink – on mobile router – Easy (new equipment) Final Workshop V i l l e n e u v e d ’ A s c q – J u n e , 2 5 th 2 0 1 5 4 QoS: Simulation results (ns‐3) Final Workshop V i l l e n e u v e d ’ A s c q – J u n e , 2 5 th 2 0 1 5 5 QoS: Simulation results (ns‐3) INTEGRATION WITH APPLICATIONS Final Workshop V i l l e n e u v e d ’ A s c q – J u n e , 2 5 th 2 0 1 5 7 TCP is not suited to changing conditions • For TCP loss = congestion • In our case losses are due to – Radio – Handovers – QoS • => need to improve TCP behaviour – With minimum impact on applications and infrastructure Final Workshop V i l l e n e u v e d ’ A s c q – J u n e , 2 5 th 2 0 1 5 8 One solution: FreezeTCP • CR enables to anticipate perturbations – Radio losses, HO, sensing • “Freeze” the transmission for this period – With FreezeTCP, transmission is blocked by the remote end by advertising a rx window of 0 size • New propositions – Smart integration with Mobile Router (MR) – Constraint advertised window size Final Workshop V i l l e n e u v e d ’ A s c q – J u n e , 2 5 th 2 0 1 5 9 FreezeTCP: Integration in CORRIDOR architecture • FreezeTCP implemented as a socket enhancement in the end user stack – Installation as a plug‐in – => compatible with end 2 end applications • Anticipation is performed by CM (in MR) – CM triggers the (un)Freeze on the end user • Asymmetric solution – Difficult to implement on servers – But passenger traffic is mainly download Final Workshop V i l l e n e u v e d ’ A s c q – J u n e , 2 5 th 2 0 1 5 10 FreezeTCP: Integration • Minimum impact Radio cut-off Connection freezed – Intelligence in Cognitive Manager – Plug‐in in end‐user terminal – NO impact on server New MR ‐> plug‐in signalisation Standard TCP signalisation Final Workshop V i l l e n e u v e d ’ A s c q – J u n e , 2 5 th 2 0 1 5 11 FreezeTCP: Why constraining window size ? • Window size = flow control – Sender (or MR) modulate the throughput • Traffic recovery – TCP generates traffic burst (fast recovery) – TCP is not suited to “block of losses” – => latency • Other application – MR can mitigate TCP flows in case of congestion Final Workshop V i l l e n e u v e d ’ A s c q – J u n e , 2 5 th 2 0 1 5 12 FreezeTCP: Simulation results (ns‐3) Final Workshop V i l l e n e u v e d ’ A s c q – J u n e , 2 5 th 2 0 1 5 13 FreezeTCP: Simulation results (ns‐3) Final Workshop V i l l e n e u v e d ’ A s c q – J u n e , 2 5 th 2 0 1 5 14 MOBILITY AND SPECTRUM MANAGEMENT Final Workshop V i l l e n e u v e d ’ A s c q – J u n e , 2 5 th 2 0 1 5 15 (CORRIDOR) Mobility and Spectrum Management Intra‐RAT HandOver: New Handover algorithm (UE side) for Intra‐RAT HO (LTE to LTE) – description on separate slide Inter‐RAT HandOver: New Handover algorithm (UE side) for Inter‐RAT HO (LTE to WiFi and viceversa) – description on separate slide Final Workshop V i l l e n e u v e d ’ A s c q – J u n e , 2 5 th 2 0 1 5 16 Possible Solution for Intra‐RAT HandOver Final Workshop V i l l e n e u v e d ’ A s c q – J u n e , 2 5 th 2 0 1 5 17 Possible Solution for Inter‐RAT HandOver Final Workshop V i l l e n e u v e d ’ A s c q – J u n e , 2 5 th 2 0 1 5 18 Message Sequence Chart (MSC) for Inter‐RAT HandOver 19 Advantages of using DataBase Approach For intra‐RAT handover the functionalities of the DB are: • For knowledge of LTE eNB positions, their frequencies and their cell IDs (at both physical and architectural level) • For computing the Doppler shifts with respect to each eNB • From the functional point of view to assist the Mobility Processing block and the PHY layer. For inter‐RAT handover the functionalities of the DB are: • For knowledge of the WLAN hotspots and LTE coverage • For knowledge of WLAN and LTE quality (transmission power) • For knowledge of correspondence between location and quality parameters • From the functional point of view to assist the intelligent Cognitive Radio Manager Final Workshop V i l l e n e u v e d ’ A s c q – J u n e , 2 5 th 2 0 1 5 20 NS‐3 SIMULATION RESULTS VIDEO Final Workshop V i l l e n e u v e d ’ A s c q – J u n e , 2 5 th 2 0 1 5 21 Thank you for your attention QUESTIONS ? Final Workshop V i l l e n e u v e d ’ A s c q – J u n e , 2 5 th 2 0 1 5 22 BACKUP SLIDES Final Workshop V i l l e n e u v e d ’ A s c q – J u n e , 2 5 th 2 0 1 5 23 New Possible Services Requiring High Data Rates (see D3.1 & D3.2) Traffic Type: UL (UpLink) or DL (DownLink) Service Type (examples)* On‐board Internet Access (business access only, during peak periods) On‐board Internet Access (normal user access only, during peak periods) Train Video Surveillance (e.g. Closed Circuit TV or CCTV) Semi‐Embedded Video Transmission (TVSE Application) – for controlling doors. Minimum Total Traffic for All Services (except normal user access) UL Minimum Required Traffic 2 Mbits/sec 90 Mbits/sec 1 Mbits/sec 512 Kbits/sec 3,5 Mbits/sec DL Minimum Required Traffic 7 Mbits/sec 800 Mbits/sec 512 Kbits/sec 12 Mbits/sec 19,5 Mbits/sec * Other additional services might exist, e.g. for train control purposes (for operating the train) – but this would require very low data rate with very high priority. Current minimum required throughput needs are not satisfied by current technology. LTE might be the answer but LTE has not been designed for high speed platforms and has to be evaluated and modified accordingly. Final Workshop V i l l e n e u v e d ’ A s c q – J u n e , 2 5 th 2 0 1 5 24 DP1 Diapositive 24 DP1 At the rail stations one can use WiFi to download and upload train information. Therefore this service will most probably not impact the cellular network side. PANAITOPOL Dorin; 03/06/2015 QoS Requirements/Service (see D3.1 & D3.2) QoS Requirements Service Type (examples)* On‐board Internet Access (business access only) Train Video Surveillance (e.g. Closed Circuit TV or CCTV) Semi‐Embedded Video Transmission (TVSE Application) – for controlling doors. First Connection Establishment Time < 5 sec. < 5 sec. < 2 sec. Connection Delay < 5 sec. < 5 sec. < 300 ms Delay Variation < 1 sec. < 40 ms (1 image Tx time) < 40 ms (1 image Tx time) Availability of Data Rate Inside or outside tunnels, on all 4 TGV branches Inside or outside tunnels, on all 4 TGV branches Video cameras installed on the station platform Packet Loss Yes (Allowed) No (Not allowed) No (Not allowed) Required Speed Up to 320 km/h Up to 320 km/h 0‐10 km/h # of Users Sharing the Same Connection 100‐150 users/train Minimum 1 user/train 6 real‐time video (if only 1 camera is used cameras/train at the time) * Other additional services might exist, e.g. for train control purposes (for operating the train) – but this would require very low data rate with very high priority, so throughput is not a problem for other additional services. However, the prioritization and the differentiation of data flow should be reconsidered. Open Air Interface Protocol Stack Final Workshop V i l l e n e u v e d ’ A s c q – J u n e , 2 5 th 2 0 1 5 26