Pattern by wuyunyi


									                                 Mobile Networks

                                     Module F

      Transport Layer over Wireless Networks
               + Voice over IP (VoIP)

       JP Hubaux, P. Papadimitratos and M. Poturalski


Some slides addapted from Jochen H. Schiller, Nitin Vaidya, and James Kurose & Keith Ross

   TCP in Mobile Networks

   Real-time traffic in Mobile Networks

    Reminder: Transmission Control Protocol

                              Host A      Host B
   Reliable, in-order data

   Flow control

   Congestion avoidance
    and control

   End-to-end semantics

                              TCP basic operation

    Application writes                               Application reads bytes
   bytes in send buffer                                from receive buffer

                       Write 45 bytes
                       Write 15 bytes                         Read 40 bytes
Application layer      Write 20 bytes                         Read 40 bytes
Transport layer

                    Send buffer                     Receive buffer
                     Sender               ACKs        Receiver

                     TCP flow control

   Flow control is a speed-matching service
     Sender adjusts the transmission rate to the receiver

   Receiver advertises the remaining buffer space
    (rwnd)to the sender

   The sender keeps unacknowledged data below rwnd
        LastByteSent – LastByteAcked ≤ rwnd

Throughput (bps)

                   R                 Light traffic
                                           Arrival Rate << R
                                           Low delay
                                           Can accommodate more

                                     Congestion onset
                           Arrival         Arrival rate approaches R
                            Rate           Delay increases rapidly
                                           Throughput begins to saturate
Delay (sec)

                                           Arrival rate > R
                                           Large delays, packet loss
                                           Useful application throughput
                            Rate                                            6
                  TCP congestion control
     Keeps TCP off the congestion collapse cliff

     Congestion window mechanism
      LastByteSent – LastByteAcked ≤ min{cwnd, rwnd}
     Slow Start phase
       Increase congestion window size (cwnd) by one segment for each
        received ACK
       Congestion window increases exponentially


                                            Time (expressed in RTTs)     7
                 TCP congestion control

   Congestion Avoidance phase
     Congestion threshold ssthresh        cwnd
     When cwnd > ssthresh,
     increase cwnd slowly
    cwnd++ per round-trip-time (RTT)                ssthresh
        • Each time an ACK arrives,
          cwnd is increased by 1/cwnd
        • In one RTT, cwnd segments
          are sent, so total increase in
          cwnd is cwnd x 1/cwnd = 1
        • cwnd grows linearly

                                           Time (expressed in RTTs)

                                     TCP congestion control

                        Congestion                     Congestion detection:
                        Avoidance                        Timeout or
                                                         Receipt of duplicate ACKs
                                                           (Fast Retransmit)
Congestion window

                                                       Assumption: current cwnd
                                                        corresponds to available
                           ssthresh                    TCP Tahoe
                                                         ssthresh = ½ cwnd
                                                         cwnd = 1
                                                         Go back to Slow Start
                            Slow                       Over several cycles expect to
                            Start                       converge to ssthresh equal
                                                        to about ½ the available

                         Time (expressed in RTTs)                                  9
             TCP congestion control

   Fast Retransmit mechanism
     If a segment is dropped,
     subsequent segments trigger
     duplicate ACKs                     SEQ=1
    Sender retransmits segment         SEQ=2   ACK=1
     instantly (without waiting for a   SEQ=3
     timeout) when duplicate ACKs       SEQ=4
     are received (typically 3)                 ACK=1
                                        SEQ=5   ACK=1
   Improves performance
     Faster reaction to packet loss
   Implemented in TCP-Reno
    (more recent than TCP-Tahoe)

              Wireless and Mobile Networks

                     Wire-line Communication


Mobile Host (1)
                       Access Point

                  Wire-less Communication

                                                   Base Station
                      Mobile Host (2)
              Wireless and Mobile Networks


Mobile Host (1)
                        Access Point

    Wireless transmission errors
     High Bit Error Rates
     Packet (frame) loss
              Wireless and Mobile Networks


                   Base Station
Mobile Host (2)        (B)

    Mobility                                        Base Station
     Disconnection     Mobile Host (2)                  (A)

     Delays                                                13

   TCP
     Assumptions for the Wire-line Internet
        • Packet loss only due to congestion
        • Packet loss is rare
   Wireless and mobile networks
    TCP assumptions are not valid

   Problem: TCP under-performs
     TCP cannot distinguish between packet losses due to
     congestion and transmission or disconnection errors
    Reducing the congestion window when an error or a
     disconnection occurs is not necessary
    Throughput suffers

   What can we do about…
    transmission errors?
    errors due to mobility?

   Which part of the system functionality should we
    The sender?
    The receiver?
    An intermediate node?
    Some or all of the above?


   Transmissions errors
     Hide error losses from the sender
        • If the sender is unaware of the packet losses due to
         errors, it does not reduce the congestion window
    Inform sender of packet loss cause
        •If the loss is due to an error, the congestion window is
         not reduced

   Errors due to mobility
     Hide mobility from the TCP sender
     Make TCP adaptive to mobility

                  Solution classification

   Split-connection approaches
     Split a TCP connection into two: the wire-line part and wire-
       less part at a Base Station or Access Point (Foreign Agent)

   Link layer approaches
     Improve link layer reliability

   End-to-end approaches
     Modify TCP congestion control mechanism

   Hybrid approaches

Split-connection approaches

                    Indirect TCP (I-TCP)

                                    Access Point
                                    (Foreign Agent)     Mobile Host

             Standard TCP
                                            “Wireless” TCP

   Split the TCP connection at the FA into two parts
     FA buffers and retransmits received segments
     FA sends ACKs for the received segments
   Standard TCP on the wire-line link
   On the wireless link:
     TCP optimized for wireless
     Even standard TCP benefits from shorter RTT
         • Shorter timeout
         • Faster retransmissions
                        I-TCP example

Correspondent Host                        Foreign Agent   Mobile Host

                                       segment 2
             (short timeout thanks to short RTT)                    20
                    I-TCP and mobility

                                    Access Point (2)

               Socket migration
               and state transfer                Internet

Mobile Host                   Access point (1)

     Moving to a new foreign agent (FA) requires transfer
      of socket state
       Including segments buffered at the FA
                       I-TCP summary

   I-TCP Advantages
    No changes in the fixed network or hosts (TCP protocol), all current
     TCP optimizations still work
        •Potentially no changes in mobile hosts
    Wireless transmission errors do not “propagate” to the wire-line

   I-TCP Disadvantages
    Loss of end-to-end semantics
        • An ACK does not imply that the receiver got the segment; what if
        the foreign agent crashes?
        For mobility support, all FAs need to be I-TCP compatible, and the
        state needs to be transferred to maintain end-to-end semantics
    Higher end-to-end delays due to buffering and forwarding to a new
    Problem with security mechanisms, e.g. IPsec
        FA needs to spoof ACKs                                        22
                   Mobile TCP (M-TCP)

                                   Access Point
                                   (Foreign Agent)      Mobile Host

            Standard TCP
                                           “Wireless” TCP

   Handling of long and frequent disconnections
   Splits connection at FA as I-TCP does
   Foreign agent
    No caching, no retransmission
    Monitors all packets
    If it detects a disconnection (no ACKs from MN for a while)
        • Reports rwnd = 0 to sender
        • Sender automatically goes into “persist” mode: Does not
          timeout or in any other way change the congestion window
                     M-TCP summary

   M-TCP advantages
    End-to-end semantics preserved
    Moving to another FA does not require forwarding buffered
       packets to new FA (since FA does no buffering)

   M-TCP disadvantages
    Wireless link loss propagates to the wire-line network
    Packets lost due to link errors need to be retransmitted by the
    Problems with security mechanisms (just like I-TCP)

   M-TCP handles mobility errors, not transmission errors
        Hybrid approach similar to M-TCP

   The link layer is typically in a better position to detect
    mobility than the transport layer
     Link layer is often aware of ongoing handoffs
     In contrast, M-TCP detects disconnections only after a
       connection is closed, based on missing ACKs

   Hence, the link layer can trigger putting the sender
    (and possibly the MH) into “persistent” mode

                          Snooping TCP

         Local Retransmission                             Correspondent
                                Foreign                   Host

          Snooping of ACKs           Buffering of data
Host                 End-to-end TCP connection

     “TCP-Aware Link Layer”
     Splits connection like I-TCP and M-TCP
       FA buffers and retransmits segments (if necessary)
       FA does not ACK buffered packets as I-TCP does
          (preserves end-to-end semantics)

            Snooping TCP: data transfer

   Data transfer to the Mobile Host
     FA buffers a segment until it receives an ACK from the MH
     FA detects segment loss via duplicate ACKs or a timeout
        • FA timeout is shorter than the round-trip timeout (RTO) at
        the sender
    FA locally retransmits lost segments
    FA drops duplicated ACKs from MH
        Prevents unnecessary retransmissions and congestion
        window reductions at the sender
        Does not violate end-to-end semantics:
        Even if the FA crashes before MH receives the segment,
        the sender will eventually detect the loss via a timeout
        and retransmit

            Snooping TCP: data transfer

   Data transfer from the Mobile
     FA detects segment loss on the      Foreign Agent   Mobile Host
     wireless link via missing sequence
    FA triggers retransmission of lost
     segment at MH
        •E.g., with a NACK mechanism
    MH retransmits data with a much
     shorter delay

               Snooping TCP and mobility

   When the MH moves to a new FA, should the
    buffered segments be transferred from the old FA?

    Not necessary
        • Even if some of the buffered segments are lost in the
            transition, the sender will eventually timeout and
            retransmit them
        •   This preserves end-to-end semantics

    Yet, this buffer transfer would improve performance because
      the timeout puts the sender into slow start phase

                Snooping TCP summary

   Snooping TCP advantages
    End-to-end semantics preserved
    No changes in the Correspondent Host (CH) required
    Transfer of buffered segments not necessary during handoff
        • MH can move to FA without Snoop TCP support
   Snooping TCP disadvantages
    Does not isolate wireless link failures as well as I-TCP does
        • If FA takes too long to retransmit a segment, CH will timeout
    Requires modifications at Mobile Host
        • NACK or similar mechanism to force retransmission
    Snooping cannot be done if TCP headers are encrypted (like in
     IPsec EPS; application layer security, e.g. TLS, is compatible)
    Dropping duplicate ACKs can break integrity

     Performance enhancing proxies (PEP)
Mobile Host              PEP       Internet          Corr. Host

   Transport layer proxies
     Local retransmissions and acknowledgements
     Any of the approaches reviewed above qualifies
   Application layer proxies
     HTTP, FTP, …
     Content cashing, filtering, compression, picture downscaling

   Big problem: breaks security end-to-end semantics
     Disables use of IP security
     Choose between PEP and security!
                 Deployment in practice

   [Wei06] reports that split-connection (similar to I-
    TCP) and application layer proxies are used by US
    cellular operators (GPRS and CDMA2000 networks)

   Deployed mechanism depends on traffic
                   Operator 1   Operator 2     Operator 3
       FTP         Split-TCP    Split-TCP           No
    HTTP data        Both       Split-TCP       Split-TCP
    HTTP image       Proxy        Proxy           Proxy
     plain TCP        No           No        Split-TCP (option)

Link layer approaches

         Forward Error Correction (FEC)

   FEC: Introduce redundancy in the packet, allowing a
    receiver to correct a limited number of errors
   Increasingly popular in wireless standards
     Repetition and Hamming codes in Bluetooth
     Convolutional codes in IEEE 802.11a
     Reed-Solomon + convolutional codes in WiMax
     Turbo codes in HSDPA
     LDPC in IEEE 802.11n
   Helps to avoid retransmissions
     Shorter and less variable transmission time
   Increases computational and bandwidth overhead
     Less of a concern nowadays thanks to Moore’s law

     Efficient link layer handoff: IEEE 802.11r

    Handoff without IEEE 802.11r
1.   MH discovers new AP                    communication with
2.   MH authenticates with new AP           old AP still possible
3.   MH (re)associates with new AP
4.   MH and new AP generate and confirm
     shared temporal keys (based on PSK     communication with
     or IEEE 802.1X)                        old AP no longer
5.   MH requests QoS resources              possible
6.   Data communication with new AP can
    IEEE 802.11r allows key generation and QoS
     resource allocation (steps 4 and 5) to take place
     prior or during (re)association (step 3)
End-to-end approaches

            Fast Retransmit and Fast Recovery

   Assumptions
     Congestion causes many segments to       SEQ=1
     be dropped                                        ACK=1
    If a single segment is dropped, but the   SEQ=3
     triggered duplicate ACKs are delivered,   SEQ=4
     the network is probably not congested             ACK=1
                                               SEQ=5   ACK=1
   Hence                                              ACK=1
     No need for drastic reduction of
     congestion window (as in TCP Tahoe)
    Fast Recovery phase

               TCP Tahoe vs TCP Reno

   3 duplicate ACKs arrive          3 duplicate ACKs arrive
    Fast Retransmit: instantly       Fast Retransmit: instantly
     retransmit 1st
                  lost segment         retransmit 1st lost segment
    ssthresh = ½ cwnd                ssthresh = ½ cwnd
    cwnd = 1                         cwnd = ssthresh + 3
    Enter Slow Start                 Enter Fast Recovery
                                     Fast Recovery
                                      Increase cwnd    by 1 segment
                                       for every duplicate ACK
          Every duplicate ACK
                                      When new ACK received
          received indicates a            • cwnd = ssthresh
          delivered segment               • Enter Congestion Avoidance
          A new segment              If a timeout occurs
          can be transmitted              • Reset cwnd to 1
                                          • Enter Slow Start

             TCP Reno vs TCP new-Reno

                                      Fast Recovery (FR)
                                       Note last segment transmitted
   Fast Recovery                       before entering FR as n
    Increase cwnd  by 1
                                       Increase cwnd by 1 segment
                                        for every duplicate ACK
     segment for every duplicate        received
     ACK received
    When new ACK received             When new partial ACK
                                        received (for k < n)
        • cwnd = ssthresh                  • Retransmit 1 unacked
        • Enter Congestion
    If a timeout occurs
                                           • Remain in Fast Recovery
                                       When ACK for n received
        • Reset cwnd to 1                  • cwnd = ssthresh
        • Enter Slow Start                 • Enter Congestion Avoidance
                                       If a timeout occurs
                                           • Reset cwnd to 1
                                           • Enter Slow Start

    Performance comparison of TCP variants

   With single packet lost in congestion window, TCP Reno and
    TCP new-Reno avoid Slow Start, and outperform TCP Tahoe
     cwnd oscillates around the optimal
                Congestion                         Triple duplicate ACK
        20                    Time-out


            5                            Behavior of Reno and new-Reno
                             Time (expressed in RTTs)

   With multiple packet lost per congestion window (not shown in
    the figure), TCP Reno underperforms severely; new-Reno
    introduced to resolve this
     Bursty packet loss common in mobile networks
        Selective acknowledgment (SACK)

   TCP acknowledgements are cumulative
     ACK n acknowledges correct and in-sequence receipt of
     packets up to n
    The sender only learns about the first lost segment
        What if more segments are lost?
   Selective retransmission as one solution
     RFC2018 allows for acknowledgements of single packets,
     not only acknowledgements of in-sequence packet streams
     without gaps
    Sender can retransmit missing packets more efficiently
   Advantage
     Higher efficiency
   Disadvantage
     More complex software in the receiver, more buffer needed
       at the receiver (CPU-, memory- and power-constraint MH)
                       Long disconnections
Correspondent Host                 timeout

                                                 connection idle

                 MH disconnected              MH connected
  Mobile Host

        TCP doubles RTO each time a timeout occurs
         Can cause unnecessary idle time after longer disconnection

                       Long disconnections
Correspondent Host                  timeout   Fast Retransmission triggered

                  MH disconnected               MH connected
  Mobile Host

        TCP doubles RTO each time a timeout occurs
         Can cause unnecessary idle time after longer disconnection
        A Mobile Host aware of connection state can “wake up” the CH
         Trigger fast retransmit with duplicate ACKs
        Simple solution
         No changes at CH necessary
         But TCP at MH needs to be aware of connectivity
         Transaction oriented TCP (T-TCP)

   TCP phases
     Connection setup, data transmission, connection release
     Using 3-way-handshake needs 3 packets for setup and
     release, respectively
    Thus, even short messages need a minimum of 7 packets!
   Transaction oriented TCP
     RFC1644 describes a TCP version to avoid this overhead
     Connection setup, data transfer and connection release can
     be combined
    Thus, only 2 or 3 packets are needed
   Advantage
     Efficiency for single packet transaction
   Disadvantage
     Requires TCP modifications at all hosts

             Explicit notification approaches

   Explicit congestion notification
     Instead of TCP indirectly inferring congestion, let routers
      and/or other hosts inform the sender/receiver directly
     Requires changes to TCP and the routing infrastructure
   Explicit bad state notification
     Base Station/Access Point (FA) keeps track of wireless link
     Bad link conditions are signal to the Correspondent Host
     Correspondent Host reacts accordingly
         Reduces/freezes transmission rate
         Resumes transmission at previous rate when good state
         notification arrives
     Requires using a FA and making changes to TCP at all

   Many proposed techniques
   Different characteristics and requirements

   TCP used in more heterogeneous networks nowadays
     Mobile networks
     Over satellite links
     Wide-spanning high-bandwidth networks
   Can a single TCP protocol perform in these settings?
   Or should we develop specialized TCP versions (and split TCP
    connections when possible)?


   H. Elaarg, “Improving TCP Performance over Mobile Networks,” ACM Computing Surveys,
    Vol. 34, No. 3, September 2002
   A. Bakre, B.R. Badrinath. I-TCP: Indirect TCP for Mobile Hosts. ICDCS 1995
   K. Fall, S. Floyd. Simulation-based comparisons of Tahoe, Reno and SACK TCP. ACM
    Sigcomm 1996
   K. Brown, S. Singh. M-TCP: TCP for mobile cellular networks. ACM Sigcomm 1997
   H. Balakrishnan, S. Seshan , R. H. Katz. Improving reliable transport and handoff
    performance in cellular wireless networks. Wireless Networks. Volume 1, Issue 4, 1995
    (this is the reference addressing Snooping TCP)
   J. Border , M. Kojo , J. Griner , G. Montenegro , Z. Shelby. Performance Enhancing
    Proxies Intended to Mitigate Link-Related Degradations. RFC 3135, June 2001
   W. Wei, C. Zhang, H. Zang, J. Kurose, and D. Towsley. Inference and Evaluation of Split-
    Connection Approaches in Cellular Data Networks. PAM 2006
   M. Mathis, J. Mahdavi, S. Floyd, A. Romanov. TCP selective acknowledgment options.
    RFC 2018, October 1996
   R. Braden. T/TCP -- TCP Extensions for Transactions Functional Specification. RFC
    1644, July 1994
   K. Ramakrishnan, S. Floyd, D. Black. The Addition of Explicit Congestion Notification
    (ECN) to IP. RFC 3168, September 2001
   B.S. Bakshi, P. Krishna, N.H. Vaidya, D.K. Pradhan. Improving Performance of TCP over
    Wireless Networks. ICDCS 1997

      Real-time traffic in Wireless Networks

   TCP
     Reliable in-order delivery (no loss)
     Throughput optimization

   Real-time traffic
     Constant throughput requirements

   We focus on VoIP
    Represents the most demanding interactive real-time traffic

   Call establishment protocols
     SIP, H.323, …

   Transport protocols
     RTP, RTCP, …

   Audio (voice) codecs
     ITU G.711, ITU G.722, ITU G.729, GSM, …

           SIP: Session Initiation Protocol

   SIP long-term vision:
     All telephone calls, video conference calls take place over
     People are identified by names or e-mail addresses, rather
      than by phone numbers
     You can reach callee, no matter where callee roams, no
      matter what IP device callee is currently using

   Note: technically SIP is an application layer protocol
     However, provided functionality not too different from Mobile
       IP or HIP

                        SIP Services

   Setting up a call
     Establishing a connection between caller and callee
     Negotiation of media type, encoding
     Call termination
   Callee localization
     Map mnemonic identifier to current IP address
   Call management
     Add new media streams during call
     Change encoding during call
     Invite others
     Transfer, hold calls

                     Setting up a call to known IP address

                                                                                                Alice’s SIP invite
                                                                                                 message indicates her                                                        Port number
                     INVITE bob
                                                                                                     IP address
                     c=IN IP4 16
                     m=audio 38
                                                                                                     Preferred encoding to
                                060 RTP/A
                                           VP 0                                                       receive (PCM μLaw)
                                                              port 5060     Bob's
                                                                            terminal rings
                                                                                                Bob’s 200 OK
                                         200 OK
                                                         .210.89                                 message indicates his
                                         c=IN IP4 193.64
                                         m=audio 48 753 RTP/AVP 3
                 port 5060                                                                           Port number
                                                                                                     IP address
                                                              port 5060
                                                                                                     Preferred encoding

                                              m Law audio
                port 38060
                                                                                                SIP messages can be
                                                                                                 sent over TCP or UDP
                                                                                                     Here sent over
                                                             port 48753

              time                                                       time                                                 54
                 Setting up a call (more)

   Codec negotiation
     Bob can reject proposed codec with
       606 Not Acceptable Reply
       and include a list of supported codecs
    Alice can then send new INVITE message, advertising
       different encoder
   Rejecting a call
     Bob can reject with replies “busy,” “gone,” “payment
       required,” “forbidden”
   Media can be sent over RTP or some other protocol

        Name translation and user location

   Caller knows only callee’s name or e-mail address
   Need to get IP address of callee’s current host
     User moves around, changing IP address
     User has different IP devices (PC, PDA, car device)
   Result can be based on
     Time of day (work, home)
     Caller (don’t want boss to call you at home)
     Status of callee (calls sent to voicemail when callee is
       already talking to someone)

   Service provided by SIP servers
     SIP registrar server
     SIP proxy server
                    SIP Registrar

   When Bob starts SIP client, client sends SIP
    REGISTER message to Bob’s registrar server

Register Message:

    Via: SIP/2.0/UDP
    Expires: 3600

                       SIP Proxy

   Alice sends invite message to her proxy server
     Contains address
   Proxy responsible for routing SIP messages to callee
     Possibly through multiple proxies
   Callee sends response back through the same set of
   Proxy returns SIP response message to Alice
     Contains Bob’s IP address
   Proxy analogous to local DNS server

Caller                                 SIP registrar
places a call to                                                         SIP
                                                 2                      registrar
                                 SIP proxy                    
(1) Jim sends INVITE           3
message to umass SIP
                                       1                7                        5
(2) Proxy forwards
request to upenn                                                             6

registrar server
(3) upenn server returns                                  9
                                                                             SIP client
redirect response,              SIP client                         
indicating that it should

(4) umass proxy sends INVITE to eurecom registrar
(5) eurecom registrar forwards INVITE to (keith’s SIP client)
(6-8) SIP response sent back
(9) media sent directly between clients.
Note: there is also a SIP ack message, which is not shown
                 Comparison with H.323

   H.323 is a signaling protocol for real-time interactive traffic
      Alternative to SIP
   H.323 is a complete, vertically integrated suite of protocols for
    multimedia conferencing: signaling, registration, admission
    control, transport, codecs
   SIP is a single component. Works with RTP, but does not
    mandate it. Can be combined with other protocols, services
   H.323 comes from the ITU (telephony).
   SIP comes from IETF: Borrows much of its concepts from HTTP
     SIP has Web flavor, whereas H.323 has telephony flavor.
   SIP uses the KISS principle: Keep it simple and stupid !

                Real-Time Protocol (RTP)

   RTP specifies packet structure for
    packets carrying audio, video data
   RTP runs in end hosts
   RTP packets encapsulated in UDP
    RTP encapsulation is only seen at end
       systems (not by intermediate routers)
   RTP does not provide any mechanism to
    ensure timely data delivery or other QoS
    Routers provide best-effort service,
       making no special effort to ensure that
       RTP packets arrive at destination in timely

                        RTP Example

   Consider sending 64 kbps PCM-encoded voice over RTP
   Application collects encoded data in chunks, e.g., every 20
    msec = 160 bytes in a chunk.
   Audio chunk + RTP header form RTP packet, which is
    encapsulated in UDP segment
   RTP header indicates type of audio encoding in each packet
     Sender can change encoding during conference
   RTP header also contains sequence numbers, timestamps

       Real-Time Control Protocol (RTCP)

   Works in conjunction with RTP
   Each participant in RTP session periodically
    transmits RTCP control packets to all other
   Each RTCP packet contains sender and/or receiver
    reports about useful statistics
     # packets sent
     # packets lost
     Inter-arrival jitter
   Feedback can be used to control performance
     Sender may modify its transmissions based on feedback
                  VoIP and the link layer

   Micro-mobility support for VoIP
    Efficient layer 2 handover (already covered)

   Real-time traffic over the link layer
     Cellular networks link layer designed with real-time traffic in
     We focus on real-time traffic over IEEE 802.11

            VoIP over IEEE 802.11 DCF

   DCF (Distributed Coordination Function) is a best-
    effort service
     No QoS guarantees on channel access delay
     Contention for the channel
     Unlucky node can experience significant delays

    DIFS                       DIFS
           medium busy                contention     next frame
           direct access if
           medium is free  DIFS         time slot

                            IEEE 802.11 DFC: VoIP only
                  Many experimental and analytical evaluations
                   5 to tens of connections can be supported (depending on codec
                      and voice chunk duration)
                  Example (AP handles VoIP connection only):
delayed >150ms
Ratio of packets

                                                                      Taken from [Cai06]
                                                                      Downlink traffic,
                                                                      IEEE 802.11b,
                                                                      rate 11Mbps,
                                                                      ns2 simulations

                                Number of voice connections

     G.729: audio data compression algorithm

                  Rapid performance collapse with too many voice connections
                     IEEE 802.11 PCF

   PCF (Point Coordination Function) was designed in
    part to provide QoS guarantees
   Many drawbacks
     Single point of failure: Access Point
     PCF interleaves polling periods with contention periods; the
     latter can cause unpredictable delays
    Unknown transmission time of polled nodes can introduce
     unpredictable delays
    Trade-off between polling scheme complexity and efficiency
    Not clear how overlapping BSSs in PCF mode should
    Does not define traffic classes
   Not deployed in practice

                         IEEE 802.11e

   IEEE 802.11e defines Quality-of-Service (QoS)
    extensions to IEEE 802.11
   Two new channel access methods:
     Enhanced Distributed Channel Access (EDCA)
        • Extension of DCF
        • 4 traffic classes with different priorities
    (Hybrid Coordination Function)-Controlled Channel
      Access (HCCA)
        •Similar to PCF

   EDCA: Enhanced Distributed Channel Access
   EDCA defines 4 traffic classes with different priorities (listed
    from highest to lowest priority)
     Voice, Video, Best-effort, Background
   Channel access method as in DCF
   Each class uses different values of parameters
      Arbitration Interframe Space (AIFS)
      Backoff (BO) contention window size range (CWmin, CWmax)
        medium busy                   contention   next frame
                                        CW                         t


                            Frame to transmit

          Priority-based distribution

queue 0      queue 1     queue 2        queue 3
                                                     To prioritize traffic
                                                      internally EDCA
                                                      makes use of
                                                       Separate queue for
                                                        each class
Backoff      Backoff      Backoff       Backoff
AIFS[0]      AIFS[1]      AIFS[2]       AIFS[3]        A virtual collision
 BO[0]        BO[1]        BO[2]         BO[3]          handler

           Virtual collision handler

                           Transmission attempt

                   IEEE 802.11e summary

   Best-effort prioritizing of traffic
   Connections in the same class contend as with DCF
     Adding a few too many voice connections degrades the
       performance significantly for all nodes
   Hence need for admission control
     Prevents oversubscribing to a channel
     Provides some control over latency
     Challenge: overlapping BSSs
   Security concerns
     Misbehaving stations could attempt to assign highest priority
       to their traffic


   L.Cai, Y. Xiao, X.S. Shen, J.W. Mark. VoIP over WLAN: voice
    capacity, admission control, QoS, and MAC: Research Articles.
    International Journal of Communication Systems, Volume 19, Issue 4,
    May 2006
   L.X. Cai, X. Shen, J.W. Mark, L. Cai, Y. Xiao. Voice capacity analysis
    of WLAN with unbalanced traffic. IEEE Transactions on Vehicular
    Technology vol. 55, no. 3, May 2006
   J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson,
    R. Sparks, M. Handley, E. Schooler. SIP: Session Initiation Protocol.
    RFC 3261, June 2002
   H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. RTP: A
    Transport Protocol for Real-Time Applications. RFC 3550, July


To top