Signaling for Streaming in IEEE e

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 /412r0 Submission S. Choi, Philips Research July 2001 Slide 1 Aligning e HCF and h TPC Operations Amjad Soomro, Sunghyun.
Doc.: IEEE /605r3 Submission November 2001 S. Kandala, et. al. Slide 1 CFB Ending Rule under HCF Srinivas Kandala, Ken Nakashima, Yashihiro Ohtani.
1 Medium Access Control Enhancements for Quality of Service IEEE Std e TM November 2005.
110/15/2003CS211 IEEE Standard Why we study this standard: overall architecture physical layer spec. –direct sequence –frequency hopping MAC layer.
1 Medium Access Control Enhancements for Quality of Service IEEE Std e TM November 2005.
Doc.: IEEE /678r1 Submission January 2003 Mark Bilstad, Cisco SystemsSlide 1 Uniform e Admissions Control Signaling for HCF and EDCF Bob.
Doc.: IEEE /0880r2 Submission Scheduled Trigger frames July 2015 Slide 1 Date: Authors: A. Asterjadhi, H. Choi, et. al.
Doc.: IEEE /494r0 Submission July 2001 Michael Fischer, Intersil (TGe Editor)Slide 1 Provisional Tge Ballot Comment Resolutions from the May,
Doc.: IEEE /618r0 Submission August 2002 Bobby Jose,Slide 1 RRM Requirements discussion on CCA Bobby Jose.
Doc.: IEEE /558r0 Submission John Kowalski, Sharp November 2001 Slide 1 Enabling Hybrid Coordinator Mobility John Kowalski Sharp Labs of America.
Doc.: IEEE /286 Submission Sept Sharp Laboratories of America, Inc.Slide 1 A IEEE e Proposal to support efficient MM streaming Srinivas.
Doc.: IEEE /628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 1 Issues with TI’s 2-Transmitter Proposal: a MAC & QoS perspective.
Doc.: IEEE /465r0 Submission Wim Diepstraten, Agere Systems July 2002 Slide 1 WiSP Wireless Sidelink Protocol Wim Diepstraten Gerrit Hiddink Agere.
Proposed Modifications to e-D4.0 Group ACK
Month Year doc.: IEEE yy/xxxxr0 May 2012
IEEE : Wireless LANs ALOHA, Slotted ALOHA
IEEE Quality of Service
Signaling for Parameterized QoS Support
Proposed Modifications to
HCF medium access rules
Proposal for IEEE solution
Requirements and Implementations for Intra-flow/Intra-AC DiffServ
Requirements and Implementations for Intra-flow/Intra-AC DiffServ
NAV Protection Mathilde Benveniste Avaya Labs, Research July 2003
A Scheduling Scheme for Level-2 Enhanced PCF MAC Service
An alternative mechanism to provide parameterized QoS
Multicast Group Management
Wireless Sidelink Protocol
NAV Protection Mathilde Benveniste Avaya Labs, Research July 2003
HCF Duration Field Set Rules
Hybrid Coordination Function (HCF) Frame Exchange and NAV Details
IEEE P Wireless RANs Date:
doc.: IEEE /xxx Authors:
Burst Transmission and Acknowledgment
Class-based Contention Periods (CCP) for the n MAC
QoS STA function applied to Mesh STA
Uniform e Admissions Control Signaling for HCF and EDCF
Clarification on Some HCF Frame Exchange Rules
HCF medium access rules
An alternative mechanism to provide parameterized QoS
Clarification on Some HCF Frame Exchange Rules
TGe Consensus Proposal
Comment resolution on CID 20175
Suggested changes to Tge D3.3
HCF medium access rules
Acknowledgement for Multicast Streams
QoS STA function applied to Mesh STA
Roaming Improvements to TGe
WME+ / Fasttrack Differences
+ RRM SG Telecon 1/8/03 August 2002 doc.: IEEE /506r0
Requirements and Implementations for Intra-flow/Intra-AC DiffServ
Simulation Results for Adaptive Rate Control
Uniform e Admissions Control Signaling for HCF and EDCF
Suggested changes to Tge D3.3
Proposed Resolutions of Some Comments Related to TSPEC Parameters
802.11e EDCA-APSD TXOP Handoff September 2003
HCF medium access rules
NAV Protection Mathilde Benveniste Avaya Labs, Research July 2003
NAV Operation Rules under HCF
HCF Channel Access And Inter-BSS Channel Sharing
Joint Proposal R1 update
Requirements and Implementations for Intra-flow/Intra-AC DiffServ
Month Year doc.: IEEE yy/xxxxr0 May 2012
Simulation Results for Adaptive Rate Control
Chapter 11 Comment Resolution for Letter Ballot 63
Srinivas Kandala Sharp Labs
Traffic Filter based Wakeup Service
NAV Operation Rules under HCF
Date: Authors: February 2010 Month Year
Presentation transcript:

Signaling for Streaming in IEEE 802.11e May 2001 Signaling for Streaming in IEEE 802.11e Srinivas Kandala, John M. Kowalski Sharp Laboratories of America Toru Ueda, Satoshi Terada, Masahiro Esashi STDC, Sharp Corporation Srinivas Kandala, et. al.

Signaling for streaming May 2001 Signaling for streaming How to set up, modify and tear-down a stream. References : Joint Proposal 00/71 IEEE 802.11e Draft Srinivas Kandala, et. al.

IEEE 802.11e Architecture Application LLC MAC L2BM SE DCF E-MLME PLME May 2001 IEEE 802.11e Architecture Application CE - Classification Entity (establishes parameters) L2BM - Layer 2 QoS BW Manager Client/server IP Station Management Entity CE SE - Scheduling Entity (only in HC, includes poll manager) CL - Convergence layer LLC MAC L2BM HCF SE EDCF An 802.11e Entity DCF Entities that may be needed, but not mandatory. E-MLME PLCP PLME The figure shows one possible architecture and is not binding. PMD Srinivas Kandala, et. al.

Upstream (ESTA to HC) - 1 of 3 May 2001 Upstream (ESTA to HC) - 1 of 3 1. Upon the request of the application or CE, SME generates the MLME-TSUPDATE.request. 2. If the ESTA is in a QBSS and if there is an HC present, the L2BM client in the ESTA will initiate the QoS Management Action Frame with code 0 (define traffic) to the HC. 3. The L2BM in the MLME of the HC, based on the channel characteristics will determine if there are sufficient resources. If so, it will send a QoS Management Action Frame to the requesting ESTA with code 1 and status 0 and sends the TSPEC to the SE for task scheduling. If not, it will send the action frame with status 1. 4. If the status is 0, the SE will schedule TxOP and inform the L2BM. The MLME will generate a MLME-TSUPDATE.indication to the SME and consequently the MAC sends the CF-Poll or Data+CF-Poll frame. Srinivas Kandala, et. al.

Upstream (ESTA to HC) - 2 of 3 May 2001 Upstream (ESTA to HC) - 2 of 3 5. Upon receipt of the action frame, a MLME-TSUPDATE.confirm will be generated by the MLME and sent to SME (at the sending ESTA). 6. If the status code is 1, the receiving ESTA may send a TSPEC subsequently or abandon completely. If the status code is 0, it may follows up by contending for the channel in EDCF mode and send a QoS-Data or QoS-Null (No Data) frame. Alternatively, the HC may send a QoS CF-Poll frame. 7. The HC upon the receipt of the data frames will read the queue size and update the SE with the queue size at the sending ESTA for schedule optimization. 8. If there is another stream(in downstream) that is registered by the same ESTA, the HC may piggyback the CF-Polls with the data. 9. If the source characteristics change, the SME in the sending ESTA will generate a MLME-TSUPDATE. request. This causes the MAC to send a QoS Management Action Request Frame with code 0. Srinivas Kandala, et. al.

Upstream (ESTA to HC) - 3 of 3 May 2001 Upstream (ESTA to HC) - 3 of 3 10. The L2BM in the HC, based on the traffic characteristics on the channel will determine if there are sufficient resources for these new parameters. If so, it will send a QoS Management Action Frame to the requesting ESTA with code 1 and status 0 and sends the traffic spec to the SE for task scheduling. Otherwise, it will send the action frame with status 1. 11. Upon the receipt of the action frame a MLME-TSUPDATE.confirm will be generated by the MAC and sent to SME. 12. If the status is 1, then the originally negotiated parameters would be continued to be used. The ESTA has the option of sending another QoS action frames with new parameters (code 0) or sending QoS action frame with code 2 for the deletion of the existing TSPEC. 13. If there is no more traffic to send, the ESTA may send the QoS Action frame with code 2 to notify the HC that its transmission has been completed (usually upon the recipient of a new MLME-TSUPDATE.request with TSAction set to Delete). The HC will respond with a QoS Action frame with code 4 to confirm the action. Srinivas Kandala, et. al.

Downstream (HC to ESTA) - 1 of 2 May 2001 Downstream (HC to ESTA) - 1 of 2 1. The application or the CE will make the SME generate the MLME-TSUPDATE.request. 2. The L2BM in the MLME determines the resources with the help of the SE. If there are enough resources and if the stream can be admitted, the L2BM will make MAC send a QoS Action management frame with code 0 to define TSPEC. This is needed to ensure that the receiving ESTA has proper capabilities (like buffer etc.) 3. If the receiving ESTA has the capability it will send the QoS Action management frame with code 1 and status 0. Otherwise, it will send the action frame with status 1. The MLME of the ESTA will generate the MLME-TSUPDATE.indication and send to the SME. 4. MLME in the sending ESTA will generate a MLME-TSUPDATE.confirm and send it to its SME. The MAC will send data to the recipient during the TxOPs assigned by SE. Srinivas Kandala, et. al.

Downstream (HC to ESTA) - 2 of 2 May 2001 Downstream (HC to ESTA) - 2 of 2 6. The SME of the ESTA containing the HC may generate a new MLME-TSUPDATE.request to reflect the changes in source characteristics. If it is generated, steps 2 through 4 are repeated to ensure that there are enough resources and that the receiver can cope with the new parameters. 7. As before, when a transmission ends the SME generates a MLME-TSUPDATE.request with delete as TSAction. The MAC will send an action management frame with code 2 to indicate the deletion of the TSPEC to the receiving ESTA. Srinivas Kandala, et. al.

Sidestream (ESTA to ESTA) - 1 of 3 May 2001 Sidestream (ESTA to ESTA) - 1 of 3 1. The application or the CE will make the SME generate the MLME-TSUPDATE.request. 2. The MLME will make the MAC generate a directed Probe Request to the ESTA whose address is in the TSPEC. 3. The MAC at the receiving ESTA will respond with a Probe Response announcing its capabilities to the sending ESTA. 4. To determine the PHY rate, the sending ESTA will send an RTS at the highest possible rate that the receiving ESTA and the HC are capable of receiving. The duration field in the RTS will cover only the expected CTS. 5. The receiving ESTA will respond with a CTS with the duration set to 0. If there is no CTS, the sending ESTA will send an RTS with a reduced rate. The receiving ESTA will respond with a CTS. This may be repeated a few times to determine the PHY rate. 6. This procedure may be repeated with the HC to ensure HC can read the Data frames’ headers (may not be necessary). Srinivas Kandala, et. al.

Sidestream (ESTA to ESTA) - 2 of 3 May 2001 Sidestream (ESTA to ESTA) - 2 of 3 7. The L2BM client in the MLME through the MAC will send a QoS Action management frame to the HC. 8. The L2BM in the MLME of the HC determines the resources with the help of the SE. If there are enough resources and if the stream can be admitted, the L2BM will make MAC send a QoS Action management frame with code 0 to define TSPEC to the recipient of the stream. This is needed to ensure that the receiving ESTA has proper capabilities (like buffer etc.) 9. If the receiving ESTA has the capability it will send the QoS Action management frame with code 1 and status 0. Else, it will send the action frame with status 1. The MLME of the ESTA will generate the MLME-TSUPDATE.indication and send to its own SME. 10. The L2BM in the HC will initiate a QoS Management Action response Frame with code 1 and the status code that it received from the recipient of the stream to the originating ESTA. If the status code is 0, the L2BM will also update the SE with the TSPEC for the scheduling of the TxOP. Srinivas Kandala, et. al.

Sidestream (ESTA to ESTA) - 3 of 3 May 2001 Sidestream (ESTA to ESTA) - 3 of 3 11. Upon the receipt of the QoS management action frame, the stream originating ESTA’s MLME will generate a MLME-TSUPDATE.confirm with the appropriate status code. 12. As in the case of upstream, the sending ESTA will either wait for the poll frame or contend in the EDCF and will respond to the CF-Polls sent by the HC. 13. Throughout the data transfer, the HC mayl read the headers of all the frames sent by the sending ESTA to have the updated queue size in order to the scheduling of TxOPs. 14. Any changes in the Traffic characteristics will be signaled by the sending ESTA to the HC and the HC will determine the availability of the resources and relay the updates to the receiving ESTA. The receiving ESTA will consequently respond back only to the HC and the HC will send the appropriate action management frame back to the stream originating ESTA. Srinivas Kandala, et. al.

Further Considerations May 2001 Further Considerations A STA associating or reassociating with Tspec as a parameter to allow for roaming. Expand the fields in the Tspec element to include the source protocol port (like TCP/UDP/Other). Srinivas Kandala, et. al.