Month 2000 doc.: IEEE /xxx July 2002

Slides:



Advertisements
Similar presentations
Doc: IEEE /705ar0 Submission Javier del Prado et. al November 2002 Slide 1 Mandatory TSPEC Parameters and Reference Design of a Simple Scheduler.
Advertisements

Doc.: IEEE /0604r1 Submission May 2014 Slide 1 Modeling and Evaluating Variable Bit rate Video Steaming for ax Date: Authors:
Achieving Quality of Service in Wireless Networks A simulation comparison of MAC layer protocols. CS444N Presentation By: Priyank Garg Rushabh Doshi.
1 Medium Access Control Enhancements for Quality of Service IEEE Std e TM November 2005.
Dynamic Tuning of the IEEE Protocol to Achieve a Theoretical Throughput Limit Frederico Calì, Marco Conti, and Enrico Gregori IEEE/ACM TRANSACTIONS.
Company LOGO Provision of Multimedia Services in based Networks Colin Roby CMSC 681 Fall 2007.
1 Medium Access Control Enhancements for Quality of Service IEEE Std e TM November 2005.
doc.: IEEE /560r1 Submission John Kowalski, Sharp November 2001 Adding Rate Parameter to the TSPEC /Queue State Element John Kowalski Sharp.
Doc.: IEEE /601r0 Submission Harada Yasuo, Matsushita Electric Ind. Slide 1 November20 01 Delayed Acknowledgement v.s. Normal Acknowledgement.
Doc.: IEEE /076r1 Submission Feb Dr. William ShvodianSlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Doc.: IEEE /558r0 Submission John Kowalski, Sharp November 2001 Slide 1 Enabling Hybrid Coordinator Mobility John Kowalski Sharp Labs of America.
Doc.:IEEE /517r0 Submission August 2002 IBM Research Slide 1 Some Clarifications to IEEE e, Draft 3.2, August 2002 H.L. Truong and G. Vannuccini.
Doc.: IEEE /248r0 Submission Bobby JoseSlide 1 February 2002 Contention Free TXOP Request and Allocation Issues Bobby Jose,
Doc.: IEEE /076r0 Submission Feb Dr. William ShvodianSlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
9. Principles of Reliable Data Transport – Part 1
IEEE e Performance Evaluation
Delayed Acknowledgement v.s. Normal Acknowledgement
HCF and EDCF Simulations
How to collect STAs’ Tx demands for UL MU
Switching Techniques In large networks there might be multiple paths linking sender and receiver. Information may be switched as it travels through various.
IEEE : Wireless LANs ALOHA, Slotted ALOHA
QoS Tutorial Date: Authors: Nov 2008 Nov 2008
EDCF TXOP Bursting Simulation Results
Month Year Doc Title Jan 2018
Requirements and Implementations for Intra-flow/Intra-AC DiffServ
Summary of Changes to TSPEC (in Document 406r3)
GAPA - Efficient, More Reliable Multicast
CC/RR Performance Evaluation - Revisited
Provision of Multimedia Services in based Networks
Scheduling Algorithms in Broad-Band Wireless Networks
An alternative mechanism to provide parameterized QoS
Sharp Laboratories USA
Signaling Acceptable Error Rate in TSPEC
doc.: IEEE /xxx Authors:
Yiannis Andreopoulos et al. IEEE JSAC’06 November 2006
GAPA - Efficient, More Reliable Multicast
EDCF Issues and Suggestions
Considerations for OBSS Sharing using QLoad Element
Zafer Sahinoglu, Ghulam Bhatti, Anil Mehta
QoS Poll Modifications Allowing Priority
DL MU-MIMO ack protocol
<January 2002> doc.: IEEE <02/139r0> March, 2008
An alternative mechanism to provide parameterized QoS
TGe Consensus Proposal
IEEE MEDIA INDEPENDENT HANDOVER DCN:
Group Block Acknowledgements for Multicast Traffic
Delayed Acknowledgement v.s. Normal Acknowledgement
DL MU MIMO Error Handling and Simulation Results
Acknowledgement for Multicast Streams
A Fair Scheduling Scheme for HCF
Requirements and Implementations for Intra-flow/Intra-AC DiffServ
Considerations for OBSS Sharing using QLoad Element
Proposed Resolutions of Some Comments Related to TSPEC Parameters
Delayed Acknowledgement v.s. Normal Acknowledgement
UL MU Random Access Analysis
Should Parameterized QoS be Optional
OFDMA performance in 11ax
Feedback-jamming ARQ mechanisms
Schedule Element Synchronization and Simplification
November 2007 doc.: IEEE /2752r1 July 2008
802.11g Contention Period – Solution for Co-existence with Legacy
QoS Metrics Date: Authors: January 2005 Month Year
40 MHz Vs 20 MHz for video Date: Authors: July 2009
Proposed Resolution for Draft 3.0
Proposed Timestamp Field for Strictly Ordered Indication
802.11e QoS Tutorial Date: Authors: Oct 2008 Oct 2008
Modeling and Evaluating Variable Bit rate Video Steaming for ax
Should Parameterized QoS be Optional
Satellite Packet Communications A UNIT -V Satellite Packet Communications.
TXOP Request: in Time vs. in Queue Size?
Presentation transcript:

Month 2000 doc.: IEEE 802.11-00/xxx July 2002 Description of Requirements for Scheduler Behavior & Suggested Modifications to TSPEC John Kowalski Sharp Labs July, 2002 John Kowalski, Sharp Labs John Doe, His Company

Outline How to define normative behavior for a scheduler July 2002 Outline How to define normative behavior for a scheduler Suggestions for new TSPEC parameters Unnecessary TSPEC parameters Conclusions John Kowalski, Sharp Labs

How to define normative behavior for a scheduler July 2002 How to define normative behavior for a scheduler Parameterized QoS transmission characteristics Constraints and conditions unique to 802.11e/ parameterized QoS transfer Defining normative requirements of a scheduler John Kowalski, Sharp Labs

The Scheduling Problem is an Allocation Problem July 2002 The Scheduling Problem is an Allocation Problem Beacon Interval Over several beacon intervals, “blacking out” time for beacons, contention, etc. we are left with an amount of time for allocating TXOPs. John Kowalski, Sharp Labs

July 2002 Typical Assumptions We can partition the beacon interval into those parts that are allocated for beacons & contention. Further partitions are made up to a particular granularity and no finer. Polls, ACKs, etc. are subsumed into the allocation as needed (Poll is not part of TXOP). Thus for the purposes of the scheduler, we basically still just have an allocation problem. However, to simplify things this allocation can be performed as part of the bandwidth management/admission control process. John Kowalski, Sharp Labs

July 2002 Constraints and conditions unique to 802.11e/ parameterized QoS transfer (1) The medium drops packets. The PHY rate changes. The medium retransmits packets Collisions happen. The TSPEC represents an agreement between HC, WSTA, (and direct link receiver, if direct link), to provide transmission within certain bounds of latency, jitter, and throughput. But this guarantee is, because of the wireless link, probabilistic in nature. The TSPEC supplies data on MSDU characteristics. Many applications contend for BW with differing parameter objectives. John Kowalski, Sharp Labs

July 2002 Constraints and conditions unique to 802.11e/ parameterized QoS transfer (2) BUT The queue sizes are knowable by the HC. The PHY rate is knowable by the HC Because of the wireless medium, if the STA can, it’s always best to transmit at the highest “reliable” PHY rate, to maximize capacity & avoid collisions. Because of parameterized QoS characteristics & wireless medium, it’s best to make polling equally distributed on the medium. John Kowalski, Sharp Labs

Defining normative requirements of a scheduler (1) July 2002 Defining normative requirements of a scheduler (1) Assume an i.i.d. channel, say, with 10% PER for a 1000 octet packet. Assume a maximum number of retransmissions (determined from the delay bound). Assume a maximum TXOP allocation (greater than the nominal TXOP allocation required by an error-free channel). (The scheduler would allocate more TXOPs). The maximum TXOP allocation can be determined as follows. John Kowalski, Sharp Labs

Defining normative requirements of a scheduler (2) July 2002 Defining normative requirements of a scheduler (2) Example: 1000 octet packets (including all overhead), 4ms TXOP time, 36Mbps transmission, 8Mbps required MAC transfer rate (including all overhead), 24Mbps ACK, beacon interval of 100ms, 10% PER (no FEC). Assume i.i.d. channel. (Channel is memoryless.) ->1000 packets per second must be transmitted MAC SAP to MAC SAP. -> 13 PPDUs can fit in a 4ms TXOP. -> Up to 8 retries are needed for high-quality video John Kowalski, Sharp Labs

Defining normative requirements of a scheduler (3) July 2002 Defining normative requirements of a scheduler (3) Probability that at least M errors in TXOP (first row is “error free”) probability): We can view the stream as a continuous sequence of packets, and over-allocate TXOPs based on them. In such a case, a TSPEC violation happens if there are more than the over-allocation bounded number of errors. John Kowalski, Sharp Labs

Defining normative requirements of a scheduler (4) July 2002 Defining normative requirements of a scheduler (4) Based on the above, we can compute, for TXOP allocations above the minimum, what the probability of schedule violation. Consider a “naive” scheduler that allocates only 8% more TXOPs above the error-free rate. P[TSPEC violation in 1 hour]= 0.75 Consider, OTOH, a scheduler that allocates 10% more TXOPs above the error free rate. Then P[TSPEC violation in 8 hours]  3.5X10-4 Normative requirements for a scheduler can thus be formulated for admitted streams that have a certain probability of not meeting the TSPEC over a certain period of time. John Kowalski, Sharp Labs

Defining normative requirements of a scheduler -final comments July 2002 Defining normative requirements of a scheduler -final comments Note: Actual 802.11 channels will often have correlated errors (dependent error rates). However, as long as the dependency 0 “fast enough” a similar approach may be taken if the dependency can be characterized. Rate dynamically changes in practical 802.11 systems. This approach may be taken for an “average” PHY rate, or minimum PHY rate (which might be too conservative & waste bandwidth). John Kowalski, Sharp Labs

July 2002 This suggests a way to determine normative scheduler behavior - and a modification to the TSPEC TSPECs are considered to be scheduled correctly if, with some probability pviolate the TSPEC is violated in a period of time TTSPEC. With these parameters, some form of admission control, as well as normative behavior of scheduling, and inference of TSPEC violation could be implemented. There is a simplification of this idea that permits simple schedulers to be built. In addition, there are parameters in the TSPEC that we don’t feel are really needed. John Kowalski, Sharp Labs

Definition of new TSPEC parameters (1) July 2002 Definition of new TSPEC parameters (1) Tcycle The basic time of TXOP allocation (Typically O(Beacon Interval) ) Tmin The minimum amount of total TXOP duration which should be allocated in Tcycle. Tgap The maximum amount of gap time between each TXOP. TXOPmin The minimum amount of any one TXOP duration (useful for Burst ACK, etc.) Tmax The maximum amount of total TXOP duration which is allocated in Tcycle. Tcycle Tcycle … … T1,1 T1,2 T1,3 T1,N T2,1 T2,2 T2,3 T2,N G1,1 G1,2 G1,N G2,1 G2,2 G2,N T1,1 +T1,2 +T1,3 + … + T1,N >= Tmin T2,1 +T2,2 +T2,3 + … + T2,N >= Tmin G1,i =< Tgap ( for all i ) G2,i =< Tgap ( for all i ) Ti,j >= TXOPmin ( for all i, j ) John Kowalski, Sharp Labs

Definition of new TSPEC parameters (2) July 2002 Definition of new TSPEC parameters (2) Thus, one can infer a TSPEC violation if one asks for Tmin (which is more than enough to get the stream through assuming errored transmissions but consistently uses Tmax seconds. OTOH this Tmax parameter may be chosen to ensure robustness of the transmission while constraining the stream’s overall bandwidth requirement. Tgap is chosen based on the number of retries permitted, the overall delay bound of the application, Burst ACK buffer size, etc. TXOPmin is useful to guage how many retransmissions may be made per TXOP, which is useful for matching Burst ACK buffer size and TXOP size with application delay requirements. Sender would choose these parameters- scheduler need not guess them! John Kowalski, Sharp Labs

Definition of new TSPEC parameters (3) July 2002 Definition of new TSPEC parameters (3) Note that Tmin and Tmax can be chosen to perform the behavior to detect a TSPEC violation: if “enough” Tmax allocations (or failures to transmit a QoS Null) happen, it might be assumed the TSPEC is violated- action could be taken subject to new admission control parameters. Bandwidth Management Policy 4 Options: Never tear down a stream by the HC but do not give it more bandwidth. Never tear down a stream by the HC but give it more bandwidth if available, without re-negotiation of the TSPEC1. Keep it up until the TSPEC violations are detected N times, at which point re-negotiation is done by the sender without tearing down stream (HC never tears down stream nor gives it more BW w/o re-negotiation.) HC may “tear down” the stream when the TSPEC is violated N times. (By simply not polling the STA). It is assumed that the sender station will re-negotiate the TSPEC most of the time. However, the HC cannot realistically guarantee extra bandwidth beyond that negotiated for streams that go bad outside of its bandwidth management policy. 1. Someday this might cost money to an end-user. John Kowalski, Sharp Labs

New TSPEC parameters accommodate RSVP and existing 802.11e parameters. July 2002 New TSPEC parameters accommodate RSVP and existing 802.11e parameters. Path bandwidth can be mapped into the above time parameters. Path latency and jitter can be inferred from the parameters TGAP+ knowledge of number of retries (when Burst ACK is used). Path_MTU can be inferred from nominal MSDU size, and queue size at higher layer- there really is no need seen to negotiate this at the MAC layer, which uses fragmentation in any event. John Kowalski, Sharp Labs

What’s not really needed in the TSPEC July 2002 What’s not really needed in the TSPEC Mean Data Rate Minimum Data Rate Delay Bound Jitter Bound Max Burst Size Inter-arrival Interval Minimum PHY rate may still be needed. Hard to do with a scheduler that’s working with a Burst ACK buffer anyway. Moreover we found that these need be represented by only 1 bound. John Kowalski, Sharp Labs

July 2002 New TSPEC parameters are isomorphic to RSVP parameters for all applications we’ve considered. (1) Minimum & Mean Data Rates are known by application, and sender. Typically they are, for (quasi)isochronous applications, well bounded (often CBR). With the (negotiated) minimum PHY these are easily converted into the parameters of this proposal (with the inclusion of retries- something to which current TSPEC is agnostic. John Kowalski, Sharp Labs

July 2002 New TSPEC parameters are isomorphic to RSVP parameters for all applications we’ve considered. (2) Delay and Jitter for application: For a fixed number of retries Burst ACK/Immediate ACK/No ACK options Map into Tmin, TXOPmin, (Tmax), TGap -by the sender. The sender will estimate how much delay his ACK, retry options incur, and create polling instructions to ensure that his delay and jitter bounds are met. The interarrival interval, etc. is, in fact an overdetermined variable. The Inactivity interval is the same as before. John Kowalski, Sharp Labs

July 2002 New TSPEC parameters are isomorphic to RSVP parameters for all applications we’ve considered. (3) We have not paid a great deal of attention to highly bursty applications. We are not certain of the need for parameterized QoS for these applications, but we would be willing to consider them if the need was demonstrated. John Kowalski, Sharp Labs

Scheduler Model For Each Flow , for each STA: July 2002 Scheduler Model For Each Flow , for each STA: Everybody’s TSPECs - mapped into scheduling parameters Detections of Bad TSPECs. Knowledge about “blacked out” times (beacon, contention, OBSS info…) A polling Sequence Queue Size Information (now optional!) John Kowalski, Sharp Labs

July 2002 New TSPEC John Kowalski, Sharp Labs

Conclusions We’ve defined a way to characterize scheduler behavior July 2002 Conclusions We’ve defined a way to characterize scheduler behavior We’ve considered a model that allows for an HC, with minimal knowledge of stream, to infer TSPEC violations if desired. We’ve proposed a way to simplify the TSPEC Additional benefit: An HC need not have any additional higher layer signaling to coordinate polling! Motion. John Kowalski, Sharp Labs