Your SlideShare is downloading. ×
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
E Multipoll Fec Persistence Portals
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

E Multipoll Fec Persistence Portals


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Multipoll, FEC, Persistence, Portals Greg Chesson, Aman Singla,
  • 2. Multipoll poll description
    • CF-Poll
      • Both downlink and uplink data movement are provided
      • Consider only uplink because Multipoll does not provide downlink
      • Uplink sequences:
          • Pn denotes the nth poll
          • Ui denotes the ith uplink frame
            • P1 <SIFS> U1 <SIFS> P2 <SIFS> U2 <SIFS> CF-End
            • P1 <SIFS> U1 <SIFS> P2 <no response> <PIFS> P3 <SIFS> U3 <SIFS> CF-End
            • Pi contains ACK for Ui-1
      • Airtime for N polls and uplink frames
        • N * (frame header + SIFS) + N*(uplink frames + SIFS) + CF-End
        • Assume headers are sent at low PHY rate
        • Assume uplink frames at higher PHY rate if possible
  • 3. Multipoll multipoll description
    • CF-Multipoll
      • Uplink or sidelink only: assigns N fixed-duration TxOPs to stations
        • Each station transmits after the previous station’s TxOPLimit (+SIFS)
        • Entire TxOPLimit period is always used (even on short uplink frames)
            • Use all the time all the time
        • Non-response by station consumes the entire TxOPLimit slot
            • Not so for CF-Poll
      • Multipoll sequences
            • MP[1-N] <SIFS> U1 <SIFS> U2 <SIFS> <no response> <SIFS> U4 // U3 damaged
            • MP[1-N] ********************************************* // damaged MP
      • Airtime for N polls
            • MP Header + NStations*4 + N*(TxOPLimit + SIFS)
  • 4. Multipoll Timing at 6 Mb/s seconds Number of polled stations Poll Multipoll Large frames (2K) Small frames (100B)
  • 5. Multipoll Timing at 36 Mb/s Large frames (2K) Small frames (100B) CF-Poll Multipoll seconds Number of Polled Stations
  • 6. Multipoll comparison
    • Airtime improvement (reduction) using multipoll instead of polls
      • assumes no errors and no wasted airtime
      • Improvement is real, but small
    • Penalties for using multipoll
      • Entire allocated timeslot wasted on non-responding stations
        • Expect this to happen on channel errors where MP is not received by all
        • Not a problem with poll: coordinator recovers after PIFS if no response
      • TxOplimit allocation must be set and processed for each timeslot
        • Ongoing complexity for HC and stations (ESTA must parse entire MP frame)
        • No variable timing or state needed with poll (one poll rather than variable N)
      • Unused portion of timeslot is dead airtime (not reclaimed)
        • Creates vulnerability from OBSS, DCF, and ad hoc stations
        • Can become less efficient than per-station polling (no similar dead time)
        • Not a problem with poll: uplink uses airtime only as needed
      • ACK policy
        • Not part of multipoll protocol, must become part of uplink handshake or come from a different ACK mechanism, introducing inefficiency and delay either way
        • Not a problem with poll: ACKs are built-into the sequence of poll messages
  • 7. Multipoll Resolution
    • Multipoll as proposed does not provide broad efficiency improvements
    • Multipoll as proposed has numerous penalities
    • Multipoll, even without channel errors, can be less efficient than poll
    • Proposal:
      • Delete Multipoll and all references
      • Use CF-Poll instead of Multipoll
      • Allow CF-Poll syntax for use by HC at any time
        • Subject to channel access rules for HC (when they are finalized)
  • 8. FEC observations
    • Raw channel data:
      • packet error rate (PER) as function of (range, PHY rate, frame size).
      • Single transmitter, no interference, packet losses caused by channel
    • PER increases with higher PHY rates, distance, larger frames.
    • 11a and 11b systems show similar behavior
      • Knee of PER curve at approx 10% PER, except for lowest PHY rate
    Distance PER 10% 90%
  • 9. FEC successful application
    • FEC in satellite/broadcast downlinks
      • PER of 10^-6 needed for high-quality mpeg-2 video
      • Retransmission not possible
        • it’s a broadcast-only downlink
        • FEC must succeed (reduce PER to 10^-5 or better)
      • per-frame FEC reduces PER by approx 10^-2 (only)
      • Therefore, conservative (slow) PHY rates must be chosen
        • Raw downlink PHY must have approx 1% PER (before FEC)
        • FEC then reduces packet loss rate to 10^-4 or 10^-5
    • Note: high-quality video
      • 8 Mbit/s base rate
      • May burst to 12 Mbit/s or so
      • Needs 500 frames/sec if 2KByte frames are used
  • 10. FEC TGe draft proposal
    • FEC in 802.11 MAC
      • Expect 10^-1 (10%) or more packet error rates (PER) for 11a, 11b
        • Based on measurement and expected practice (except for lowest PHY rates)
        • Much higher expected PER than in satellite applications
      • Expect 10^-2 to 10^-3 PER after FEC
        • May need 5 retransmissions/sec for an 8 MBit/s video stream (!)
        • Retransmissions will contribute to increased jitter
      • FEC overhead is
        • 10% payload (redundancy bytes added to header and payload)
        • Plus extra TxOP and airtime for Delayed Ack and its Ack
        • Plus the residual retransmissions
          • Unless slow PHY rate (with 1% PER) is selected (unlikely)
        • This is a lot of overhead when compared to retransmission
  • 11. FEC implementation issues
    • Optimistic/pipelined Decode
      • Header can be validated in pipelined fashion
      • The number of error blocks can be determined in near real-time
      • ACK can be generated in SIFS time, knowing that correction will succeed
    • Delayed ACKs
      • When do you know that a Delayed Ack is not forthcoming?
        • I.e. when do we retransmit?
        • Adds even more delay jitter
      • Sending MAC must maintain state for each non-Acked packet
        • How many such packets?
        • For how long?
      • Receiving MAC needs out-of-order assembly buffers
        • Size is related to delay-bandwidth product of Delayed Acks
        • Size is related to number of Delay-Ack streams
      • What is a minimum interoperable implementation?
      • Need TCP-like sophistication to select good parameters
  • 12. FEC compared to retransmission
    • FEC
      • >10% channel overhead for redundant information
      • Will also need retransmission (unless low PHY rate is used)
      • Will need TCP-like out-of-order assembly and controls
      • Does not improve jitter
    • Retransmission
      • Channel overhead is function of PER – not a constant 10%
      • In-order delivery, no complex state
      • has less overhead than FEC for practical PERs
    • Conclusion
      • FEC may not always be the best procedure
      • FEC may be useful at low PHY rates for broadcast/multicast
      • Delayed ACKs have significant unresolved issues
  • 13. FEC resolution
    • Retain FEC
      • Define Capability bit and FEC-encoded bit
    • Remove Delayed Acks
    • Proceed with two motions and editing instructions from document 01/458
  • 14. Persistence Factor simulation models
    • Must include channel error model
      • Channel measurements show that PER will be significant
      • Simulated Latency-jitter-bandwidth numbers meaningless without PER
        • Especially jitter
      • Should incorporate 10% channel error rate for realism
        • Based on 11ab measurements
        • Based on expectations of rate adaptation implementations
    • Demonstration
      • observe media simulations with and without 10% PER
  • 15. Persistence Simulation Scenario: 4 phones, 2 video, 10 background, EDCF @ 36 Mb/s (packet loss only from collisions) phones videos background Remove loads
  • 16. Persistence Same scenario, adding 10% PER Bandwidth glitches Caused by retransmission Backoff delay when Background load Is applied
  • 17. Persistence (showing latency distribution per flow) Phones: mean = 1.5ms, deviation = 5+ms Videos: mean = 15+ms, deviation = 30 ms Not good
  • 18. Persistence Backoff-related Jitter Demonstrated with PER
    • “ Optimistic” (no PER) simulation suggests that life is wonderful.
    • “ Realistic” (PER) simulation shows unacceptable jitter for media streams.
    • Proposed solutions (both in Tge draft proposal)
      • Persistence Factor
        • Defines fractional exponent per TC instead of binary exponential backoff
        • Hi-priority traffic would increase backoff window at slower (fractional) rate
        • Implementation complexity: must compute uniform distributions over non-power-of-two windows (considered costly)
        • Good for stream (slow rate of increasing backoff)
        • Bad for channel (can increase congestion because of slow backoff increases)
      • aCWMax[TC]
        • Already present in MIB
        • Provides upper bound for backoff window based on traffic category
        • Retains simple power-of-two computations and scaling from existing MACs
        • Good for stream (limits backoff window to an upper bound)
        • Good for channel (fast backoff increase)
  • 19. Persistence Same scenario using CWMax[TC] to bound retransmission window for video and voice traffic Bandwidth aberrations removed Lower background Bandwidth peaks
  • 20. Persistence Improved latency and jitter for media flows retransmission jitter becomes negligible Phones before: mean = 1.5ms, deviation = 5+ms after: mean = [.95,1.6], deviation = [.7,1.98] Videos before: mean = 15+ms, deviation = 30 ms after: mean = [1.8,2.3], deviation = [1.7,2.2]
  • 21. Persistence Resolution
    • Both mechanisms are in the draft standard
    • Both mechanisms solve the problem (reduce backoff-related jitter)
    • aCWMax[TC]
      • Is better from a channel perspective (fast backoff to a limit)
      • Is less complex (uses existing CWMin/CWMax and random generator)
    • Persistence Factor
      • Not as good from a channel perspective (can increase contention)
      • Is more complex (adds fractional scaling, requires new random generator)
    • Proposal
      • Remove the redundant mechanism (Persistence)
      • Move aCWMax[TC] from MIB to QoS Parameter Set Element CWMax[TC]
  • 22. Bridge Portals state of the art
    • Useful concept
    • Non-802.11 bridges
      • Define unique protocols for discovery, routing, announcement, etc
      • CableLabs-defined QoS bridges invoke RSVP/SBM
      • IPv6 provides Neighbor Discovery protocol and messages
      • Bluetooth has Service Discovery Protocol
      • Universal Plug and Play (UPNP) is a candidate discovery layer
    • Should 802.11 define Yet Another Protocol (YAP) for Discovery?
      • No compelling reason
      • Unlikely to improve on existing art
      • Very unlikely to replace existing art
    • Should 802.11 be usable with existing protocols?
      • Absolutely
      • Requires both 802.11 DS and non-802.11 DS
  • 23. Bridge Portals simple approach
    • Implement multiple station addresses in MAC
      • “ multi-homing”, but at Layer 2
    • Use one address to associate with BSS
    • Use others to communicate with BPs
    • Use BP-unique protocols to locate and acquire services
      • No need to provide non-802.11 discovery services in 802.11
    • Notes:
      • Technique mentioned by Michael Fischer and others
      • Some implementations may already exist
      • Useful technique for mobility protocols
      • Equivalent to simultaneous membership in both BSS and IBSS
      • Requires no new 802.11 protocol