1. doc.: IEEE 802.15-04-0100-00-004b Submission March 2004 Myung Lee, et al, Samsung Lab@CUNYSlide 1 NOTE: Update all red fields replacing with your information; they are required. This is a manual update in appropriate fields. All Blue fields are informational and are to be deleted. Black stays. After updating delete this box/paragraph. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Enhancements to IEEE 802.15.4] Date Submitted: [12 March, 2004] Source: [Myung Lee, Jianliang Zheng, Yong Liu] Company [Samsung Lab @ CUNY] Address [T677, EE Dept. Steinman Hall 140 th Street and Convent Ave, NY, NY 10031 ] Voice:[212-650-7260], FAX: [212-650-8249], EMail:[lee@ccny.cuny.edu] Re: [Response to the call for proposal of IEEE 802.15.4b, MAC Enhancement.] [If this is a response to a Call for Contributions, cite the name and date of the Call for Contributions to which this document responds, as well as the relevant item number in the Call for Contributions.] [Note: Contributions that are not responsive to this section of the template, and contributions which do not address the topic under which they are submitted, may be refused or consigned to the “General Contributions” area.] Abstract:[Discussion for several potential enhancements for current IEEE 802.15.4 MAC] Purpose:[For the discussion at IEEE 802.15.4b Study 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-0100-00-004b Submission March 2004 Myung Lee, et al, Samsung Lab@CUNYSlide 2 Enhancements to IEEE 802.15.4 Myung Lee, Jianliang Zheng, Yong Liu Samsung Lab@ CUNY

3. doc.: IEEE 802.15-04-0100-00-004b Submission March 2004 Myung Lee, et al, Samsung Lab@CUNYSlide 3 1. Repeated Collisions (1) Caused by hidden terminal problems and short backoff period. CSMA-CA will not work in the case of hidden terminals. A large backoff period can help alleviate the problem. The backoff period in IEEE 802.15.4 is too small.

4. doc.: IEEE 802.15-04-0100-00-004b Submission March 2004 Myung Lee, et al, Samsung Lab@CUNYSlide 4 1. Repeated Collisions (2) In current 802.15.4 backoff_period = aUnitBackoffPeriod × (2 BE – 1) where aUnitBackoffPeriod = 20 symbols BE = 2 to 5 for beacon enabled mode, or 3 to 5 for non-beacon enabled mode. So the maximum backoff period is max_backoff_period = 620 symbols = 310 bytes for 2.4 GHz band, or 77.5 bytes for 868/915 MHz bands.

5. doc.: IEEE 802.15-04-0100-00-004b Submission March 2004 Myung Lee, et al, Samsung Lab@CUNYSlide 5 1. Repeated Collisions (3) In case of hidden terminal problems, CSMA-CA will sense the channel as being idle. So only BE = 2 (in beacon enabled mode) or 3 (in non-beacon enabled mode) is used. For this small backoff period, the two hidden terminals have a very high probability to collide repeatedly.

6. doc.: IEEE 802.15-04-0100-00-004b Submission March 2004 Myung Lee, et al, Samsung Lab@CUNYSlide 6 1. Repeated Collisions (4) Solution –Relate BE to the retransmission status. Let txRetry denote the number of retransmissions for a certain frame, then set BE according to the following: BE = (2 + txRetry) to (5 + txRetry) for beacon enabled mode, or (3 + txRetry) to (5 + txRetry) for non-beacon enabled mode. –max_backoff_period for BE = (5 + txRetry) is: 255 * 20 = 5100 symbols = 2550 bytes for 2.4 GHz band.

7. doc.: IEEE 802.15-04-0100-00-004b Submission March 2004 Myung Lee, et al, Samsung Lab@CUNYSlide 7 2. Transactions Not Atomic (1) ACKFrame ( t ack ) t ack = 12 symbols 1 CCA = 8 symbols (a) Non-beacon enabled ACKFrame (t ack ) 12 symbols ≤ t ack ≤ 32 symbols 2 CCAs = 16 symbols (b) Beacon enabled

8. doc.: IEEE 802.15-04-0100-00-004b Submission March 2004 Myung Lee, et al, Samsung Lab@CUNYSlide 8 2. Transactions Not Atomic (2) Another transmission can happen between the transmissions of a frame and its acknowledgment (ACK). Here we focus on atomic problems caused by CCA and IFS, though hidden terminal problems can also lead to atomic problems.

9. doc.: IEEE 802.15-04-0100-00-004b Submission March 2004 Myung Lee, et al, Samsung Lab@CUNYSlide 9 2. Transactions Not Atomic (3) Solution –Increase CCA duration so that it is larger than t ack. –Specifically, let CCA = 13 symbols. This will solve the problem in non-beacon enabled mode. –For beacon enabled mode, we need to perform two CCAs. One solution is: CCA (13 sym) + delay (7 sym) + CCA (13 sym) = 33 sym > t ack

10. doc.: IEEE 802.15-04-0100-00-004b Submission March 2004 Myung Lee, et al, Samsung Lab@CUNYSlide 10 3. macRxOnWhenIdle = ? The default value of mpib.macRxOnWhenIdle is false. It does not make sense for non- beacon enabled mode. Solution –Set the default to true for non-beacon enabled mode.

11. doc.: IEEE 802.15-04-0100-00-004b Submission March 2004 Myung Lee, et al, Samsung Lab@CUNYSlide 11 4. Ambiguity of Primitive MLME-COMM- STATUS.indication (1) This primitive is used to indicate the status of certain communications. For example, notify SSCS by MAC of the results from carrying out MLME-ASSOCIATE.response MLME-ORPHAN.response No specific parameters are included in MLME- COMM-STATUS.indication to indicate it corresponds to which of the following: MLME-ASSOCIATE.response MLME-ORPHAN.response.

12. doc.: IEEE 802.15-04-0100-00-004b Submission March 2004 Myung Lee, et al, Samsung Lab@CUNYSlide 12 4. Ambiguity of Primitive MLME-COMM- STATUS.indication (2) Solution Use different primitives to return results from MLME-ASSOCIATE.response MLME-ORPHAN.response Or include another parameter in MLME- COMM-STATUS.indication to indicate it is originated by which of the following: MLME-ASSOCIATE.response MLME-ORPHAN.response

13. doc.: IEEE 802.15-04-0100-00-004b Submission March 2004 Myung Lee, et al, Samsung Lab@CUNYSlide 13 5. CSMA-CA for Multi-hop Beacon Enabled Networks (1) In current CSMA-CA, a node is assumed to act either as a coordinator or as a device, but not both. In a multi-hop beacon enabled environment, a node may act as both a coordinator and a device. So a node can have both beaconing parent and beaconing children. The current CSMA-CA does not take this situation into account, and a beacon could be destroyed by other frames.

14. doc.: IEEE 802.15-04-0100-00-004b Submission March 2004 Myung Lee, et al, Samsung Lab@CUNYSlide 14 5. CSMA-CA for Multi-hop Beacon Enabled Networks (2) Solution: Modify the CSMA-CA as follows: –A node shall begin to transmit a frame only if all the following conditions are satisfied: The channel is sensed as idle; The transaction can be finished before the end of the current CAP period corresponding to its beaconing parent or corresponding to any of its beaconing children, whichever arrives first. If required, beaconing sibling nodes can also be taken into account. –Otherwise, the node should wait for next superframe and restart CSMA-CA procedure again.

15. doc.: IEEE 802.15-04-0100-00-004b Submission March 2004 Myung Lee, et al, Samsung Lab@CUNYSlide 15 6. Batch Data Transmissions When a coordinator has multiple data packets for a device, the device needs to send data requests to poll all these packets one by one. A more efficient way is to embed the data request information in the ACK of the previous packet. The repeated data requests and their ACKs can be omitted.

16. doc.: IEEE 802.15-04-0100-00-004b Submission March 2004 Myung Lee, et al, Samsung Lab@CUNYSlide 16 7. Adding postBeaconDelay (1) To avoid beacon collisions as well as collisions between beacons and data packets, it is important to design a nice scheduling scheme for beacon enabled networks. For example, A has to prevent its data packets from destroying beacons from all its neighbors. Right after A catches the beacons from its parent O, it begins to transmit buffered data packets or send data requests under the control of the MAC layer. Even if the NWK layer is aware that there will be some beacons from its neighbors, it cannot stop the data transmissions that are automatically conducted by the MAC layer.

17. doc.: IEEE 802.15-04-0100-00-004b Submission March 2004 Myung Lee, et al, Samsung Lab@CUNYSlide 17 7. Adding postBeaconDelay (2) The NWK layer should be able to control the packet transmission time within each superframe. We propose to define a new parameter, postBeaconDelay. When one device receives beacons from its parent (coordinator), it has to delay all packet transmissions (or disable its transmitter) for postBeaconDelay. Similarly, after releasing beacons, coordinators have to backoff postBeaconDelay before transmitting any packets. The postBeaconDelay is stored at MAC PIB, and can be set and reset by the NWK layer at any time. The NWK layer can utilize this delay period for beacon scheduling.

18. doc.: IEEE 802.15-04-0100-00-004b Submission March 2004 Myung Lee, et al, Samsung Lab@CUNYSlide 18 Other Issues Isn’t macTransactionPersistenceTime (0x01f4, unit superframe) too long? Page 156, line 16: (for transaction, i.e., indirect transmission) "all subsequent retransmissions shall be transmitted using CSMA-CA". Page 158, line 14-16:"if a single transmission attempt has failed and the transmission was indirect, the coordinator shall not retransmit the data or MAC command frame. Instead, the frame shall remain in the transaction queue of the coordinator.“ Marco Naeve’s ppt file, slide 3: “Association time in non-beacon networks is too long for some applications” Not very accurate according to our simulation results.