Presentation is loading. Please wait.

Presentation is loading. Please wait.

Ist-muse.org On the Enhancement of QoE for IPTV Services through Knowledge Plane Development Bart De Vleeschauwer Wim Van de Meerssche Pieter Simoens Filip.

Similar presentations


Presentation on theme: "Ist-muse.org On the Enhancement of QoE for IPTV Services through Knowledge Plane Development Bart De Vleeschauwer Wim Van de Meerssche Pieter Simoens Filip."— Presentation transcript:

1 ist-muse.org On the Enhancement of QoE for IPTV Services through Knowledge Plane Development Bart De Vleeschauwer Wim Van de Meerssche Pieter Simoens Filip De Turck Bart Dhoedt Piet Demeester Edith Gilon Kris Struyve Tom Van Caenegem

2 BB Europe — 2 ist-muse.org Overview > Access network challenges > Monitoring Plane & Knowledge Plane > Monitoring in the home network

3 BB Europe — 3 ist-muse.org Access Network Overview Service Providers Service Edge Access Node Residential Gateway End Device User Access NetworkHome Network

4 BB Europe — 4 ist-muse.org Services & Challenge > Classic best-effort internet services: Web Surfing, , File Transfer, … > New services: VOIP, Broadcast IPTV, Video on Demand, Gaming Higher Requirements: – Interactivity, Media quality, Zapping Time, Setup Time, Synced Sound, Artifact-free Video > Need for guaranteed Quality of Experience = how the user experiences the service Influenced by network jitter, delay and loss How can we detect & automatically solve QoE degradation?

5 BB Europe — 5 ist-muse.org Overview > Access network challenges > Monitoring Plane & Knowledge Plane > Monitoring in the home network

6 BB Europe — 6 ist-muse.org Monitor Plane MP/KP: Architecture Knowledge Plane QoE decrease detectedroot cause analysis Monitoring data sources restorative action

7 BB Europe — 7 ist-muse.org Monitor Plane Logical layer containing all monitoring tools: SNMP: Read & write device parameters Set traps IPFIX (or netflow): Flow statistics TR-069 Residential gateway configuration & monitoring …

8 BB Europe — 8 ist-muse.org Knowledge Plane Solution Execution Monitoring Plane Data Reduction Knowledge plane Overview Active: e.g. generate additional ICMP ping requests Passive: e.g. additional threshold in RMON MIB Anomaly Detection Diagnosis and Solution Additional queries over available data Initialize new anomaly detection modules Additional info might be needed for accurate fault recovery Initiate new monitor probes Anomaly is detected e.g. FEC, interleaving, local retransmission, device reconfiguration, warn end-user or network management, … Solve Problem Continuous monitoring

9 BB Europe — 9 ist-muse.org Monitor Plane MP/KP: Example Knowledge Plane QoE decrease detectedroot cause analysisrestorative action Loss Detected ADSL-line Statistics: loss detected Loss in Home Network Add FEC to stream Cause known: ADSL-line loss

10 BB Europe — 10 ist-muse.org Overview > Access network challenges > Monitoring Plane & Knowledge Plane > Monitoring in the home network

11 BB Europe — 11 ist-muse.org Home Network Monitoring How to monitor? Limited or no knowledge & control of end-devices > Active monitoring > Passive monitoring Loss, RTT and Jitter monitoring From the Access Node ?

12 BB Europe — 12 ist-muse.org Active Monitoring > Dedicated software Assumes control of end-devices and end-device software by access network > ICMP-based Each IP device should support “ping” Can measure RTT, jitter and loss Problem: – Firewall – Might be handled differently than other traffic – Large Loss detection overhead! – To detect a packet loss ratio p, you need 10/p packets > Active monitoring isn’t very useful

13 BB Europe — 13 ist-muse.org Passive Monitoring > From in the access network, monitor packets from and to the home network > Use service specific algorithms to derive home network parameters > Use cases: Broadcast TV using RTP/RTCP VoD using TCP

14 BB Europe — 14 ist-muse.org RTP/RTCP monitoring > Overview: RTP/RTCP basics Jitter Monitoring Loss Monitoring RTP RTCP Sender Reports RTCP Receiver Reports

15 BB Europe — 15 ist-muse.org RTP/RTCP > RFC 3550: RTP: A Transport Protocol for Real-Time Applications > Two protocols RTP protocol for data packets RTCP protocol for control traffic > RTP packets contain data Sequence number Timestamps (Sampling instant of first octet in the RTP data packet) > RTCP packets contain control & feedback information

16 BB Europe — 16 ist-muse.org RTCP Messages > SDES, source description items > BYE, end of participation > APP, application specific > SR, Sender Report > RR, Receiver Report Report Block

17 BB Europe — 17 ist-muse.org RTP/RTCP loss estimation > Receiver report: > Same calculations can be done on AN, by looking at RTP stream # Expected - # Received Fraction lost since last RR Loss

18 BB Europe — 18 ist-muse.org Access node home network loss detection Receiver Reports (loss=A) RTP Monitoring on AN (loss=B) Calculate: A - B Access NetworkHome Network

19 BB Europe — 19 ist-muse.org RTP/RTCP interarrival Jitter estimation > Interarrival jitter: variance in interarrival time Server Access Node (AN) SjSj time > End-to-end jitter is reported in RR > Do analogous calculations on RTP at AN to determine Server – AN jitter > Compare end-to-end jitter (RR) and Server-AN jitter SkSk AjAj AkAk End-Device RjRj RkRk SiSi AiAi RiRi

20 BB Europe — 20 ist-muse.org TCP monitoring > Overview: TCP basics RTT & Jitter Monitoring Loss Monitoring Our algorithm: ANTMA TCP

21 BB Europe — 21 ist-muse.org TCP: Basics DP 1 Sender Receiver Monitoring Point 1 A1 ACK 1

22 BB Europe — 22 ist-muse.org TCP: Loss DP 1 Time-out! Sender Receiver Monitoring Point 1 A1 1 ACK 1

23 BB Europe — 23 ist-muse.org 1 TCP: Flights DP 1DP 2ACK 1 Sender Receiver Monitoring Point A1 2 ACK 2 A2

24 BB Europe — 24 ist-muse.org TCP Middle Monitoring: RTT & Jitter in home network > RTT is time between seeing a data packet, and seeing its matching ACK > “RTT Jitter” can be derived from RTT > Finding matching ACK is hard when loss & jitter occur: A A1 A4 A4 A4 ACK 1 DP 1  Need smart matching for jitter detection!

25 BB Europe — 25 ist-muse.org TCP Middle Monitoring: Loss in Home Network > Counting retransmissions Unreliable, as jitter can cause retransmissions Tests on the internet show difference with loss can be very high > “Smart” counting retransmissions Assume multiple losses in row are jitter, and ignore them Bursty loss is seen as jitter!

26 BB Europe — 26 ist-muse.org TCP Middle Monitoring: ANTMA > ANTMA = “Access Network TCP Monitoring Algorithm” > What? Loss, RTT & Jitter estimations Measure each TCP connection separately Monitor only home network part of connection > How? Passive monitoring of packets on AN (or RGW) History is evaluated by various rules Packets are matched with their ACK

27 BB Europe — 27 ist-muse.org TCP Middle Monitoring: ANTMA Example MP ACK 1DP 1DP 2DP 3DP 4DP 5DP 6ACK 2ACK 3 123A1A2A3456 ACK 3 History: 123A1 Can match:1,3 A2A ,66 LOST

28 BB Europe — 28 ist-muse.org Conclusion > Monitoring Plane Monitoring in Acces Network Monitoring in Home Network – RTP/RTCP – TCP > Knowledge Plane Detect & Solve QoE degradations

29 BB Europe — 29 ist-muse.org Questions?


Download ppt "Ist-muse.org On the Enhancement of QoE for IPTV Services through Knowledge Plane Development Bart De Vleeschauwer Wim Van de Meerssche Pieter Simoens Filip."

Similar presentations


Ads by Google