1 / 12

Signaling for Streaming in IEEE 802.11e

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. Signaling for streaming. How to set up, modify and tear-down a stream. References : Joint Proposal 00/71

taariq
Download Presentation

Signaling for Streaming in IEEE 802.11e

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

  8. 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.

  9. 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.

  10. 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.

  11. 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.

  12. 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.

More Related