1 / 18

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

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 ]

adamma
Télécharger la présentation

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

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. 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 140th 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. 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. Myung Lee, et al, Samsung Lab@CUNY

  2. Enhancements to IEEE 802.15.4 Myung Lee, Jianliang Zheng, Yong Liu Samsung Lab@ CUNY Myung Lee, et al, Samsung Lab@CUNY

  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. Myung Lee, et al, Samsung Lab@CUNY

  4. 1. Repeated Collisions (2) • In current 802.15.4 backoff_period = aUnitBackoffPeriod × (2BE – 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. Myung Lee, et al, Samsung Lab@CUNY

  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. Myung Lee, et al, Samsung Lab@CUNY

  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. Myung Lee, et al, Samsung Lab@CUNY

  7. 2. Transactions Not Atomic (1) Frame ACK Frame ACK (tack) (tack) tack= 12 symbols 1 CCA = 8 symbols 12 symbols ≤tack ≤ 32 symbols 2 CCAs = 16 symbols (a) Non-beacon enabled (b) Beacon enabled Myung Lee, et al, Samsung Lab@CUNY

  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. Myung Lee, et al, Samsung Lab@CUNY

  9. 2. Transactions Not Atomic (3) • Solution • Increase CCA duration so that it is larger than tack. • 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 > tack Myung Lee, et al, Samsung Lab@CUNY

  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. Myung Lee, et al, Samsung Lab@CUNY

  11. 4. Ambiguity of PrimitiveMLME-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. Myung Lee, et al, Samsung Lab@CUNY

  12. 4. Ambiguity of PrimitiveMLME-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 Myung Lee, et al, Samsung Lab@CUNY

  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. Myung Lee, et al, Samsung Lab@CUNY

  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. Myung Lee, et al, Samsung Lab@CUNY

  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. Myung Lee, et al, Samsung Lab@CUNY

  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. Myung Lee, et al, Samsung Lab@CUNY

  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. Myung Lee, et al, Samsung Lab@CUNY

  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. Myung Lee, et al, Samsung Lab@CUNY

More Related