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