Open-Source Based Prototype for QoS Monitoring and QoE Estimation in Telecommunication Environments

NGMAST 2011. Fifth International Conference on Next Generation Mobile Applications, Service and Technologies. 15. September 2011. Cardiff, Wales, UK.

Transcript

1. Open-­‐‑Source  Based  Prototype  for  QoS   Monitoring  and  QoE  Estimation  in   Telecommunication  Environments   Sebastian Schumann Slovak University of Technology Bratislava, Slovakia Cardiff, UK – 15. September 2011
2. Introduction •  Implementation for Quality of Service (QoS) and Experience (QoE) monitoring •  Works in Real-time Transport Protocol (RTP) based telecommunication environments •  Analysis o  QoS parameters are evaluated o  QoE is determined with the E-Model •  Output o  R-Factor, one-way delay, packet-loss probability o  Graphical representation
3. Environment •  Usage of Voice over IP (VoIP) increased over the last years •  It is not always possible to enforce QoS, esp. in unmanaged networks •  Size of measured network does not matter •  Measurement system o  Measurement points (probes) are distributed o  Central reporting unit collects and evaluates the data •  Focus on widespread networks, not system components
4. Motivation •  ngnlab.eu targets distributed VoIP environments and open-source based solutions •  Commercial solutions are expensive, only for operators •  Main goals o  Easy but flexible measurement design o  A non-intrusive online monitoring o  Informative results o  Ability to determine the geographical and technical source of degradations
5. “Competition”
6. Theory •  E-model used to determine QoE (calculated acc. several network parameters) •  Objective (i.e., calculated) value can be mapped to the subjective Mean Opinion Score (MOS) •  Impacts on speech quality are o  One-way delay o  Packet-loss probability o  Packet-loss distribution o  Speech codec •  Measurement and evaluation of values allow calculation of QoS/QoE during the call
7. Correlation  between  MOS   value  and  R-­‐‑Factor
8. Measured  Impairments  I •  One-way delay •  Measured by halving the Round-Trip-Time (RTT) value of the voice packets (estimation) •  Both directions possible •  RTT determination using measured values o  Time-stamp in PCAP o  Time-stamp in RTCP •  RTT1 =A2 -A1 -D2 •  RTT2 =A3 -A2 -D3 DLSR .. delay sender report A1 .. 1st SR passes ME A2 .. following SR D2 .. DL btw reception of SR1 and transmission of SR2
9. Measured  Impairments  II •  Packet loss probability •  Determined by recording the sequence number of each RTP packet that passes the ME •  The loss probability is updated after every 100 RTP packets o  The time distance is a good balance between the applied load on the ME, the network load, and the actuality of the measurement results on the EE
10. Measured  Impairments  III •  Packet loss distribution calculated acc. the patent of McGowan o  Overall packet loss probability (Ppl) o  Average length of all loss sequences •  Speech codec is determined by parsing the Session Description Protocol (SDP) during the session establishment procedure •  Knowledge is important in relation to the used compression method and its robustness against packet loss (packet loss robustness factor)
11. Network  setup
12. Application •  Measurement probes o  PCAP library captures packet for analysis o  Perl script extracts required information from each packet o  HTTP is used to exchange measured parameters •  Central reporting unit o  Java application o  Real-time monitoring with three detail levels (monitoring unit, call, details) o  Adjustable color indication when pre-set thresholds are reached
13. GUI
14. Measurement  setup
15. Results  I •  Non-degraded measurement •  Normal values •  Delay in path 2+4 high due to public network
16. Results  II •  Degraded measurement •  One-way delay on the Internet higher (20x) in paths 2+4 •  R-Factor decreased as well •  Knowing network and taking packet loss into account, low upload on office B is determined
17. Summary •  QoS and QoE can be measured using the designed prototype •  Implementation is scalable to smaller or larger Telco networks (probes can be distributed accordingly) •  Implementation can compete with professional equipment to a certain extent •  Extensions open but easily possible o  Alarms o  Visual network status display in real-time o  Follow-up calls for neg. quality calls o  Recording of call samples possible as well
18. Thank  you! Sebastian Schumann seb.schumann@gmail.com @s_schumann