Motivations (I) Voip over WiFi is gaining popularity thanks to the widespread diffusion of

Download 445 b.
Hajmi445 b.

Motivations (I)

  • VoIP over WiFi is gaining popularity thanks to the widespread diffusion of

    • WiFi-enabled devices: mobile phones, laptopos, PDAs
    • VoIP applications: Skype, Yahoo Messenger, MSN Messenger, Linphone…
  • However, providing good voice quality is a challenging task due to several factors

Motivations (II)

  • Some are out of the control of a single STA…

    • wired part of the e2e connection
      • Round trip delay, packet dropping in congested router,
    • wireless part of the e2e connection
  • … while others are under control of the STA

    • application level
      • voice codec, playout buffer scheme, error concealment techniques,…
    • MAC/PHY level

Aim of the work

  • Goal: providing good quality of VoIP over WiFi under varying connection conditions

  • Method: Adaptive Parameters Optimization Scheme

    • Cross-layer iterative adaptation of system parameters
  • Basic idea: estimate, foresee, select

    • Estimate factors that you cannot control
      • current system state (focused on wireless part only)
    • Foresee what you would get by acting on the factors that you can control
      • QoS for different (MAC) parameters setting by using a mathematical model of the system
    • Select the setting that maximizes QoS
  • Features: non cooperative, standard compliant, modular

APOS architecture

Parameters vectors (, )

  • Vectors  &  include all controllable parameters

  • We distinguish between fixed parameters ()

    • Parameters that hardly change in time
      • voice codec, playout delay, packet aggregation level, wired-path latency,…
    • …or that cannot be changed preserving std compliancy
      • contention window, transmission power, …
  • And tuneable parameters: =[rmax,R]

  • We optimize over vector  only though APOS can potentially apply to all the controllable parameters!!!

APOS architecture

System state vector ()

  • System state vector  shall…

    • summarize the collective effect of factors that cannot be controlled
    • be almost invariant to single STA parameters setting
  • We set  =[Pcoll, TB, SNR] where

    • Pcoll: Collision probability
    • TB : Channel busy period
    • SNR: Signal to Noise Ratio

MSE: Medium State Estimate

  • Pcoll and TB can be directly obtained from MAC counters/measuraments

    • standard management information base (MIB)
      • NTs: # ack.ed MSDU tx by the STA
      • NTf: # non ack.ed MSDU tx by the STA
      • NRs: # received data frames with valid FCS
      • NRf: # received data frames with invalid FCS
    • channel occupancy statistics seen by the STA

MSE: Medium State Estimate

  • SNR can be determined from

    • MAC counters
    • + basic probability properties:

APOS architecture

WLM: Wireless Link Model

  • WLM feeds the QEB with the expected packet loss rate (Ploss) and average end to end delay (Te2e) at the varying of the <> input vectors

  • We assume that wired-path delay and losses are negligible

    • however, the model can accommodate these factors by using, for instance, RTCP reports
  • Te2e is mainly due to the wireless link delay and the playout buffer

  • Ploss is given by frame dropped by the 802.11 card and frames arriving after their playback time

  • Assuming that the buffering time buff is given, the WLM outputs depend on the wireless link losses and delay only!

Wireless link delay

  • Goal: estimate mean ms, and variance s2 of the system time

    • Time taken by a voice packet to cross the wireless link
  • Method: model the wireless link as a D/G/1 queue-server system where

    • customers  MPDUs generated by the upper layers
    • arrival rate  frame-generation rate of the voice codec (fixed)
    • server  MAC entity
    • service time y  time taken by the MAC entity to process a MPDU (either delivering it to the peer unit or dropping it after rmax unsuccessful tx attempts)
      • We assume {yj} are i.i.d r.v. also independent of the arrival process
  • Complete statistical analysis is available in the literature [Servi-’86] but requires roots search for complex polynomial!

    • not suitable for portable devices (as cel. phones)
  • We prefer to relinquish the complete statistic in favour of a simpler (though less accurate) estimate of first and second order delay statistics…

Service time statistics (1/2)

  • Given  [Pcoll,TB,SNR] , [R,rmax] and [L,...] the service time is given by

  • Working this expression we get* the 1st, 2nd and 3rd-order moments of y

    • my=E[y]
    • My=E[y2]
    • My(3)=E[y3]

Service time statistics (2/2)

Wireless link delay

  • System time s can be expressed as

    • x: number of customers (MPDUs) in the system at the arrival epoch
    • y’: residual service time of the (possible) customer in service at the arrival epoch
    • H(x) : Heaviside function
  • taking expectations we finally get

    • statistical mean (ms):
    • statistical power (Ms):
      •  = my = Pr[x > 0] (load factor)
    • whereas, applying renewal theorem, we get:

Packet losses

  • Losses due to the wireless link

  • Losses due to playout underrun

    • Pbuff & delay jitter s are related through the Chebyshev bound*
    • Hence, Pbuff can be estimated as
  • Overall losses

APOS architecture

QEB: Quality Evaluation Block

  • The QEB implements the utility function Q proposed in [Boutr.03]

    • inspired by the E-Model
    • ITU-T recommendations G.107 and G.113
  • R=Q(vcodec, Ploss,Te2e)

  • R can be mapped to Mean Opinion Score (MOS)

APOS architecture

APO: Adaptive Parameters Optimization

  • do forever

    • MOSopt=0
    • get  =[Pcoll, TB, SNR] from MSE
    • for =[rmax,R] in parameter space do
      • compute [Ploss,Te2e]=WLM()
      • compute MOS = Q(Ploss,Te2e)
      • If MOS > MOSopt,
        • MOSopt = MOS
        • opt = 
      • endif
    • endfor
  • endo

Model Validation


  • Theoretically optimal  setting in the  space

    • TB fixed
  • Optimal R and rmax depend on both Pcoll,

    • with low Pcoll, rate adaptation can be more aggressive
    • with high SNR, rmax strongly depend on Pcoll


  • Parameters optimization permit to maintain good MOS in many situations

    • Red lines: std param.s setting
    • Black lines: APOS


  • APOS framework is a stand-alone, std compliant solution

    • mathematical model based on of network status information locally available in commercial devices
  • APOS enhances VoIP performance by cycling over three steps

    • 1) estimate the contention level and quality of the wireless medium
    • 2) model the effect of parameters tuning on e2e QoS
    • 3) select the best configuration for the current medium status
  • Optimization can be performed on any subset of tuneable parameters

    • We reported only R & rmax optimization, but we also tested playout buffer, voice codec and so on...
  • Although parameters might be tuned independently one another (as done by today rate adaptation algorithms), joint optimizing of multiple parameters yield much better results!

  • APOS scheme is specialized to voice application, though the general framework might be adapted to other QoS services

Do'stlaringiz bilan baham:

Ma'lumotlar bazasi mualliflik huquqi bilan himoyalangan © 2017
ma'muriyatiga murojaat qiling