Doc.:IEEE 802.11-02/525Ar0 Submission September 2002 Mathilde Benveniste, Avaya Labs Slide 1...

September 2002

Mathilde Benveniste, Avaya LabsSlide 1

doc.:IEEE 802.11-02/525Ar0

Submission

Simplifying PollingSimplifying Polling

Mathilde [email protected]

Dongyan ChenAvaya Labs Research

September 2002


doc.:IEEE 802.11-02/525Ar0

Submission

BackgroundBackground

• Avaya is interested in QoS (e.g. VoIP) and channel throughput in the enterprise space

• Minimal delay for time-sensitive applications and efficient channel use are the focus -- regardless of data rate

September 2002


doc.:IEEE 802.11-02/525Ar0

Submission

MotivationMotivation

• RRs serve QoS while promoting efficient channel use– RRs keep polling list short – limited to active

stations– RRs permit the polling mechanism to work

for burstry traffic as well as periodic traffic

• Simple implementation is attractive in an RR mechanism

September 2002


doc.:IEEE 802.11-02/525Ar0

Submission

TerminologyTerminology

• CC/RR the reservation mechanism for polling, as it appears in D3.0

• EDCF/RR alternative reservation mechanism for polling – no CCI; RRs comprise top priority EDCF class– the RR could be the QoS-Null frame

September 2002


doc.:IEEE 802.11-02/525Ar0

Submission

Simulations in Simulations in 01/571r0 01/571r0

• In 01/571r0 the results showed a better performance of CC/RR compared to ‘straight’ PCF– Straight PCF polls all associated stations

• These results were not sufficient to validate the CC/RR mechanism– The results simply showed that a managed polling list improves

performance

September 2002


doc.:IEEE 802.11-02/525Ar0

Submission

Simulations in Simulations in 02/305r0 02/305r0 • 02/305r0 results showed better performance with

CC/RR compared to EDCF/RR while using a short CP– CFP uses up to 18 ms in a 20 ms cycle– Only 2 ms provided for CP; a fairer allocation of channel time would

have averted the high collision rate affecting the RRs

• 02/305r0 results showed long access delays with EDCF/RR caused by DCF contention despite use of PF differentiation– A Persistence Factor was included, but not set at lowest value; a

better choice of EDCF parameters would have protected the RRs

• The results in 02/305r0 do not establish the superior performance of CC/RR over EDCF/RR– CC/RR is compared to a sub-optimal EDCF/RR specification

September 2002


doc.:IEEE 802.11-02/525Ar0

Submission

Our objectiveOur objective

• To present an efficient specification of EDCF/RR

• To show simulation results comparing EDCF/RR to CC/RR

September 2002


doc.:IEEE 802.11-02/525Ar0

Submission

Simulation ScenariosSimulation ScenariosUplink and downlink transmission through HCF in CP The performance of the two reservation mechanisms

– CC/RR: CCI period=5 ms; CCOPS=50 – EDCF/RR: PF=0.5 [01/409r2]; AIFS=PIFS; CWmin=8; Cwmax=2

is compared under two scenarios• Under low load (LL)

The load consists of time-sensitive bursty traffic (Load1, p 8)

• With heavy DCF load (HL)A best effort load of 5 stations, 1 Mpbs per station, is added

(Load2, p 8)

The same HCF implementation used on the downlink for both scenarios

September 2002


doc.:IEEE 802.11-02/525Ar0

Submission

Traffic ScenariosTraffic Scenarios

Two loads considered on 11Mbps DS channel Load1 is transmitted by polling; it generates frequent RRs

– 8 stations engaged in two-way exchange with AP of time-sensitive bursty traffic

– Payload [excludes MAC & PHY overhead] per packet =120 bytes; inter-arrival fixed at 10 ms when ON; exponential 342 ms ON /650 ms OFF (example: silence suppressed voice)

Load2 contends for the channel through DCF– 5 stations sending low priority data uplink– Payload per packet=724 bytes; inter-arrival exponential

at 7 ms

September 2002


doc.:IEEE 802.11-02/525Ar0

Submission

Statistics ReportedStatistics Reported

• RR ETE (end-to-end) delay• Load1 uplink ETE delay –

– Simple poll scheduling– Optimized poll scheduling

• Load1 downlink ETE delay• Load2 load ETE delay

September 2002


doc.:IEEE 802.11-02/525Ar0

Submission

RR end-to-end delay (sec)RR end-to-end delay (sec)

CC/RR-LL under Light Load

EDCF/RR-LL

CC/RR-HL under Heavy LoadEDCF/RR-HL

EDCF/RR gets the RRs out sooner

September 2002


doc.:IEEE 802.11-02/525Ar0

Submission

Load1 uplink end-to-end delay (sec)Load1 uplink end-to-end delay (sec)


EDCF/RR-LL


Without optimization

EDCF/RR leads to lower uplink delay

September 2002


doc.:IEEE 802.11-02/525Ar0

Submission

Load1 uplink end-to-end delay (sec)Load1 uplink end-to-end delay (sec)


EDCF/RR-LL


With optimization

Even with optimization EDCF/RR does at least as well

September 2002


doc.:IEEE 802.11-02/525Ar0

Submission

Load1 downlink end-to-end delay (sec)Load1 downlink end-to-end delay (sec)


EDCF/RR-LL


Downlink performance is the same for the two mechanisms

September 2002


doc.:IEEE 802.11-02/525Ar0

Submission

Load2 end-to-end delay (sec)Load2 end-to-end delay (sec)

CC/RR-HL

EDCF/RR-HL

under Heavy Load

•CC/RR dedicates channel time (20% in this example) to CCI that could be otherwise used for transmission

•EDCF/RR uses channel more efficiently

September 2002


doc.:IEEE 802.11-02/525Ar0

Submission

ConclusionsConclusions

• EDCF/RR gets the RRs out sooner• EDCF/RR uses channel more efficiently• EDCF/RR performs at least as well as

CC/RR under all situations– Light load– Heavy load– Optimized and non-optimized poll

scheduling

• EDCF/RR is simpler to implement

September 2002


doc.:IEEE 802.11-02/525Ar0

Submission

MotionMotion

• Remove CCI from D3.0• Devote top priority EDCF class to RRs

exclusively • Re-introduce the persistence factors

and use lowest PF value for RRs only

Doc.:IEEE 802.11-02/525Ar0 Submission September 2002 Mathilde Benveniste, Avaya Labs Slide 1...

Documents

Transcript of Doc.:IEEE 802.11-02/525Ar0 Submission September 2002 Mathilde Benveniste, Avaya Labs Slide 1...