IEEE 802'15 subject

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 _at_
CUNY Address T677, EE Dept. Steinman Hall 140th
Street and Convent Ave, NY, NY 10031
Voice212-650-7260, FAX [phone],
EMaillee_at_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.
2
Enhancements to IEEE 802.15.4

• Myung Lee, Jianliang Zheng, Yong Liu
• Samsung Lab_at_ 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.

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.

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
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
2. Transactions Not Atomic (1)
ACK
Frame
ACK
Frame
(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
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
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 gt tack

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
4. Ambiguity of Primitive MLME-COMM-STATUS.indicat
ion (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
4. Ambiguity of Primitive MLME-COMM-STATUS.indicat
ion (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
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
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
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
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
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
Other Issues

• Isnt 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 Naeves ppt file, slide 3 Association
  time in non-beacon networks is too long for some
  applications
• Not very accurate according to our simulation
  results.