Transcript Document 7474535

March 2004
doc.: IEEE 802.15-04-0100-00-004b
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:[[email protected]]
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.
Submission
Slide 1
Myung Lee, et al, Samsung Lab@CUNY
March 2004
doc.: IEEE 802.15-04-0100-00-004b
Enhancements to IEEE 802.15.4
Myung Lee, Jianliang Zheng, Yong Liu
Samsung Lab@ CUNY
Submission
Slide 2
Myung Lee, et al, Samsung Lab@CUNY
March 2004
doc.: IEEE 802.15-04-0100-00-004b
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.
Submission
Slide 3
Myung Lee, et al, Samsung Lab@CUNY
March 2004
doc.: IEEE 802.15-04-0100-00-004b
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.
Submission
Slide 4
Myung Lee, et al, Samsung Lab@CUNY
March 2004
doc.: IEEE 802.15-04-0100-00-004b
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.
Submission
Slide 5
Myung Lee, et al, Samsung Lab@CUNY
March 2004
doc.: IEEE 802.15-04-0100-00-004b
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.
Submission
Slide 6
Myung Lee, et al, Samsung Lab@CUNY
March 2004
doc.: IEEE 802.15-04-0100-00-004b
2. Transactions Not Atomic (1)
Frame
ACK
Frame
(tack)
(tack)
12 symbols ≤ tack ≤ 32 symbols
2 CCAs = 16 symbols
tack = 12 symbols
1 CCA = 8 symbols
(a) Non-beacon enabled
Submission
ACK
(b) Beacon enabled
Slide 7
Myung Lee, et al, Samsung Lab@CUNY
March 2004
doc.: IEEE 802.15-04-0100-00-004b
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.
Submission
Slide 8
Myung Lee, et al, Samsung Lab@CUNY
March 2004
doc.: IEEE 802.15-04-0100-00-004b
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
Submission
Slide 9
Myung Lee, et al, Samsung Lab@CUNY
March 2004
doc.: IEEE 802.15-04-0100-00-004b
3. macRxOnWhenIdle = ?
•
•
•
The default value of
mpib.macRxOnWhenIdle is false.
It does not make sense for nonbeacon enabled mode.
Solution
– Set the default to true for non-beacon
enabled mode.
Submission
Slide 10
Myung Lee, et al, Samsung Lab@CUNY
March 2004
doc.: IEEE 802.15-04-0100-00-004b
4. Ambiguity of Primitive MLME-COMMSTATUS.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 MLMECOMM-STATUS.indication to indicate it
corresponds to which of the following:
•
•
Submission
MLME-ASSOCIATE.response
MLME-ORPHAN.response.
Slide 11
Myung Lee, et al, Samsung Lab@CUNY
March 2004
•
•
4. Ambiguity of Primitive MLME-COMMSTATUS.indication (2)
Solution
Use different primitives to return results
from
•
•
•
doc.: IEEE 802.15-04-0100-00-004b
MLME-ASSOCIATE.response
MLME-ORPHAN.response
Or include another parameter in MLMECOMM-STATUS.indication to indicate it
is originated by which of the following:
•
•
Submission
MLME-ASSOCIATE.response
MLME-ORPHAN.response
Slide 12
Myung Lee, et al, Samsung Lab@CUNY
March 2004
doc.: IEEE 802.15-04-0100-00-004b
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.
Submission
Slide 13
Myung Lee, et al, Samsung Lab@CUNY
March 2004
doc.: IEEE 802.15-04-0100-00-004b
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.
Submission
Slide 14
Myung Lee, et al, Samsung Lab@CUNY
March 2004
doc.: IEEE 802.15-04-0100-00-004b
6. Batch Data Transmissions
Network
Device
Coordinator
Beacon
Data Request
ACK
Data
ACK
Data Request
ACK
Data
ACK
Combined together
Data Request
ACK
Data
ACK
Combined together
Submission
Omitted
Omitted
• 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.
Slide 15
Myung Lee, et al, Samsung Lab@CUNY
March 2004
doc.: IEEE 802.15-04-0100-00-004b
7. Adding postBeaconDelay (1)
O
A
B
D
C
Submission
E
F
• 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.
Slide 16
Myung Lee, et al, Samsung Lab@CUNY
March 2004
doc.: IEEE 802.15-04-0100-00-004b
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.
Submission
Slide 17
Myung Lee, et al, Samsung Lab@CUNY
March 2004
doc.: IEEE 802.15-04-0100-00-004b
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.
Submission
Slide 18
Myung Lee, et al, Samsung Lab@CUNY