Doc.: IEEE 802.15-04-0100-00-004b Submission March 2004 Myung Lee, et al, Samsung 1 NOTE: Update all red fields replacing with your information;

Slides:



Advertisements
Similar presentations
IEEE r0 Submission July 2007 R. Zhang, H. Jung, E. Lee, M. Lee Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks.
Advertisements

Doc.: IEEE b Submission Sept 2004 Liang Li, WXZJ Inc./Helicomm Slide 1 Project: IEEE P Working Group for Wireless Personal Area.
Doc.: IEEE b Submission November 2004 Robert Cragie, Jennic Ltd.Slide 1 NOTE: Update all red fields replacing with your information;
Doc.: IEEE /037r0 Submission January 2003 Ed Callaway, Motorola Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks.
Doc.: IEEE b Submission September 2004 Myung Lee, et al,Slide 1 NOTE: Update all red fields replacing with your information; they.
Doc.: IEEE e SubmissionSlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [beacon.
Feb doc:IEEE c Slide 1 Submission Pei Liu, Hisilicon. Project: IEEE P Working Group for Wireless Personal Area Networks.
Doc.: IEEE Submission September 2010 Hind Chebbo, FujitsuSlide 1 NOTE: Update all red fields replacing with your information; they.
e Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [The embedded.
Doc.: IEEE Submission Slide 1 NOTE: Update all red fields replacing with your information; they are required. This is a manual update in appropriate.
Doc.: IEEE Submission Oct Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title:
Doc.: b Submission Mar Song-Lin Young[Sharp Labs.] Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks.
Doc.: IEEE b Submission July 2004 Robert Poor, Lee Taylor, EmberSlide 1 Project: IEEE P Working Group for Wireless Personal.
Doc.: IEEE /317r0 Submission September, 2000 Allen Heberling, Eastman Kodak, CompanySlide 1 NOTE: Update all red fields replacing with your information;
Doc.: IEEE Submission September 2013 Li, Hernandez, Dotlic, Miura, NICT Slide 1 Project: IEEE P Working Group for Wireless.
Doc.:IEEE Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title:
Doc.: IEEE Submission Sept Byung-Jae Kwak, ETRISlide 1 NOTE: Update all red fields replacing with your information; they are.
Doc.:IEEE Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title:
Doc.: IEEE Submission Jan 2016 Al Petrick, Jones-Petrick and AssociatesSlide 1 NOTE: Update all red fields replacing with your information;
Doc.: IEEE Submission Oct Slide 1 Sangjae Lee (ETRI) et al Project: IEEE P Working Group for Wireless Personal Area.
Doc.: Submission May 2006 Myung LeeSlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission.
Doc.: IEEE Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Communicating.
Doc.: IEEE /250r0 Submission, Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: IEEE :
Doc.: IEEE e Submission July 2009 Andy Summers, Skip Ashton, EmberSlide 1 Project: IEEE P Working Group for Wireless Personal.
Doc.: IEEE Submission, Slide 1 NOTE: Update all red fields replacing with your information; they are required. This is a manual.
Doc.: IEEE m SubmissionSlide 1 May 2012 Project: IEEE P Working Group for Wireless Personal Area Networks(WPANs) Submission.
doc.: IEEE <doc#>
Submission Title: [EGTS Subgroup Report for IEEE e]
March 2004 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Synchronized Beacon Propagation for Spanning.
March 01 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: TG4 RFWaves MAC Proposal Overview Date Submitted:
doc.: IEEE <doc#>
March 01 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: TG4 RFWaves PHY Proposal Overview Date Submitted:
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Add name of submission] Date Submitted:
<month year> doc.: IEEE < e > <Sep 2008>
May 2006 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: WiMedia Liason Report May 06 Date Submitted:
May 2018 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Considerations on general MAC frame] Date Submitted:
May 2010 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [PIB Coordination in g] Date Submitted:
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Handling of non-ULI frame and Profile.
November, 2004 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposal for PostBeaconDelay in b]
NOV 01 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Application Specific Information Element] Date.
doc.: IEEE <doc#>
doc.: IEEE <doc#>
<May,2009> doc.: IEEE <doc .....> <July 2009>
September 2010 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG6 Proposed MAC comment resolution]
doc.: IEEE <doc#>
Submission Title: [Comment Resolutions for #345, #347, #348, and #349]
< November, 2011 > Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [More Low Energy Mechanism Details]
Submission Title: [Comment Resolutions for #309, #310, and #314]
doc.: IEEE <doc#>
<month year> <doc.: IEEE doc> September 2010
< April, 2012 > Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Improvement of Data Transmission in.
doc.: IEEE <doc#>
doc.: IEEE <doc#>
<month year> doc.: IEEE e doc.: IEEE < e >
<January 2002> doc.: IEEE <02/139r0> Nov, 2008
doc.: IEEE <doc#>
Submission Title: [Comment Resolutions for #345, #347, #348, and #349]
doc.: IEEE <doc#>
January 2000 doc.: IEEE /020r0 January 2000
March 01 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: TG4 RFWaves MAC Proposal Overview Date Submitted:
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [OFDM extension to lower data rates] Date.
doc.: IEEE <doc#1>
<month year> doc.: IEEE < e> doc.: IEEE < e>b
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [15.4j Coordinator Switching] Date Submitted:
<month year> doc.: IEEE July 2007
doc.: IEEE <doc#1>
Source: [Chunhui Zhu] Company [Samsung]
doc.: IEEE <doc#1>
August 2019 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Still More LB156 Comment Resolutions Date.
August 2019 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Still More LB156 Comment Resolutions Date.
Presentation transcript:

doc.: IEEE b Submission March 2004 Myung Lee, et al, Samsung 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 P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Enhancements to IEEE ] Date Submitted: [12 March, 2004] Source: [Myung Lee, Jianliang Zheng, Yong Liu] Company [Samsung CUNY] Address [T677, EE Dept. Steinman Hall 140 th Street and Convent Ave, NY, NY ] Voice:[ ], FAX: [ ], Re: [Response to the call for proposal of IEEE b, 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 MAC] Purpose:[For the discussion at IEEE b Study Group] Notice:This document has been prepared to assist the IEEE P 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 P

doc.: IEEE b Submission March 2004 Myung Lee, et al, Samsung 2 Enhancements to IEEE Myung Lee, Jianliang Zheng, Yong Liu Samsung CUNY

doc.: IEEE b Submission March 2004 Myung Lee, et al, Samsung 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 is too small.

doc.: IEEE b Submission March 2004 Myung Lee, et al, Samsung 4 1. Repeated Collisions (2) In current 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.

doc.: IEEE b Submission March 2004 Myung Lee, et al, Samsung 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.

doc.: IEEE b Submission March 2004 Myung Lee, et al, Samsung 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.

doc.: IEEE b Submission March 2004 Myung Lee, et al, Samsung 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

doc.: IEEE b Submission March 2004 Myung Lee, et al, Samsung 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.

doc.: IEEE b Submission March 2004 Myung Lee, et al, Samsung 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

doc.: IEEE b Submission March 2004 Myung Lee, et al, Samsung 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.

doc.: IEEE b Submission March 2004 Myung Lee, et al, Samsung 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.

doc.: IEEE b Submission March 2004 Myung Lee, et al, Samsung 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

doc.: IEEE b Submission March 2004 Myung Lee, et al, Samsung 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.

doc.: IEEE b Submission March 2004 Myung Lee, et al, Samsung 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.

doc.: IEEE b Submission March 2004 Myung Lee, et al, Samsung 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.

doc.: IEEE b Submission March 2004 Myung Lee, et al, Samsung 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.

doc.: IEEE b Submission March 2004 Myung Lee, et al, Samsung 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.

doc.: IEEE b Submission March 2004 Myung Lee, et al, Samsung 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.