1. doc.: IEEE 802. 15-04-0448-00-004b Submission Aug. 2004 H. Shao, H. Dai, J. Zhang, Mitsubishi ElectricSlide 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Priority for some MAC commands, ad hoc beacon, broadcast data and urgent data ] Date Submitted: [August 24, 2004] Source: [Huai-Rong Shao, Hui Dai and Jinyun Zhang] Company [Mitsubishi Electric Research Labs] Address [8th Floor, 201 Broadway, Cambridge, MA 02139 ] Voice:[617-621-7517], FAX: [617-621-7550], EMail:[shao@merl.com] Re: [Response to call for proposal of IEEE 802.15.4b, Doc Number: 15-04-0239-00-004b.] Abstract:[Further explanation and revision of #91 in 802.15.4b comment database. Original proposal is at 15-04-0313-01-004b ] Purpose:[Proposal to IEEE 802.15.4b Task Group] Notice:This document has been prepared to assist the IEEE P802.15. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release:The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P802.15.

2. doc.: IEEE 802. 15-04-0448-00-004b Submission Aug. 2004 H. Shao, H. Dai, J. Zhang, Mitsubishi ElectricSlide 2 Priority for some MAC commands, ad hoc beacon, broadcast data and urgent data -- Further explanation to #91 in 15.4b comment database Huai-Rong Shao, Hui Dai and Jinyun Zhang Mitsubishi Electric Research Laboratories

3. doc.: IEEE 802. 15-04-0448-00-004b Submission Aug. 2004 H. Shao, H. Dai, J. Zhang, Mitsubishi ElectricSlide 3 Problem Statement (1) Some MAC commands and Ad hoc beacons have no ACK, and they may get lost due to conflict. –Coordinator Realignment command for PAN Configuration Change –A coordinator sends a realignment command to all devices associated to it. If the command is lost, many devices will become orphans or lose synchronization with its coordinator –Beacon request command –At non-beacon-enabled mode, if this command is lost, coordinators will not send out ad hoc beacons. –Ad hoc beacon –At non-beacon-enabled mode, a device sends out beacon request command during scan stage, and coordinators reply with ad hoc beacons. If beacon from a coordinator get lost, the device cannot associate to the coordinator.

4. doc.: IEEE 802. 15-04-0448-00-004b Submission Aug. 2004 H. Shao, H. Dai, J. Zhang, Mitsubishi ElectricSlide 4 Problem Statement (2) For some MAC commands who can be re-transmitted, MAC command loss and retransmission may result in long handshaking delay –For example, commands for association such as Association request command Experiments show that: –Command loss ratio could be really high, especially in small Beacon Order –Command loss ratio could still be high even it’s infrequent “Robert commented that his technical staff already experienced conflicts between data and MAC commands.” ( from minutes of Portland meeting15-04- 0359)

5. doc.: IEEE 802. 15-04-0448-00-004b Submission Aug. 2004 H. Shao, H. Dai, J. Zhang, Mitsubishi ElectricSlide 5 Problem Statement (3) In certain cases, data from some devices should have higher priority –The devices report errors founded –The devices report urgent event such fire alarm –The devices broadcast management configurations From Portland meeting minutes 15-04-0359 –“Key re-distribution, which is done using data frames, is much more important than any other frames” (By Ed)

6. doc.: IEEE 802. 15-04-0448-00-004b Submission Aug. 2004 H. Shao, H. Dai, J. Zhang, Mitsubishi ElectricSlide 6 Simulation I : Association Scene : devices send association requests to join a WPAN Simulation Setting –Star topology: 1 coordinator with 15 end devices. They are in the same POS –Each device transmits packets to a neighbor randomly chosen as background traffic –10 devices join the network sequentially and send request to join the network Observation from simulation –Command loss ratio is high in small Beacon Order –Command loss ratio is high even it’s infrequent

7. doc.: IEEE 802. 15-04-0448-00-004b Submission Aug. 2004 H. Shao, H. Dai, J. Zhang, Mitsubishi ElectricSlide 7 Loss Ratio of Association Request Command Beacon Order

8. doc.: IEEE 802. 15-04-0448-00-004b Submission Aug. 2004 H. Shao, H. Dai, J. Zhang, Mitsubishi ElectricSlide 8 Simulation II : Retrieve Data From Coordinator Scene : devices send requests to retrieve data from coordinator Simulation Setting –Star topology: 1 coordinator with 24 end devices. They are in the same POS –Each device transmits packets in 1pkt/sec to a neighbor randomly chosen as background traffic –Devices request the data from coordinator with different speed Observation from simulation –Data request loss ratio is high in small Beacon Order –Loss ratio decreases when beacon order increases

9. doc.: IEEE 802. 15-04-0448-00-004b Submission Aug. 2004 H. Shao, H. Dai, J. Zhang, Mitsubishi ElectricSlide 9 Loss Ratio of Data Request Command # of Data Request per Second Loss Ratio

10. doc.: IEEE 802. 15-04-0448-00-004b Submission Aug. 2004 H. Shao, H. Dai, J. Zhang, Mitsubishi ElectricSlide 10 Proposal Use 1 bit in the reserved fields in Frame Control to indicate the “urgent” attribute Add a “urgent” field to the MCPS-DATA.request primitive (Page 57, §7.1.1.1) Mechanisms can be implementation specific –Option 1 : Set a shorter back off contention window sizes for “urgent” packets –Option 2 : Add some period of delay before back off, and different priorities packet will choose different delay time.

11. doc.: IEEE 802. 15-04-0448-00-004b Submission Aug. 2004 H. Shao, H. Dai, J. Zhang, Mitsubishi ElectricSlide 11 Notes It is NOT QoS –Just a simple setting to deal with emergence situation –Only mark data as “urgent” when necessary