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
July 5, 2004 Source Huai-Rong Shao, Jinyun
Zhang, Hui Dai Company Mitsubishi Electric
Research Labs Address 8th Floor, 201 Broadway,
Cambridge, MA 02139 Voice617-621-7517, FAX
617-621-7550, EMailshao_at_merl.com Re
Response to the call for proposal of IEEE
802.15.4b, Doc Number 15-04-0239-00-004b. Abstra
ct Discussion for several enhancements to
current IEEE 802.15.4 Purpose Proposal to IEEE
802.15.4b Task 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
Enhancements to 802.15.4

• Huai-Rong Shao, Jinyun Zhang, and Hui Dai
• Mitsubishi Electric Research Laboratories

3
Proposals

• Solutions to Direct and Indirect beacon conflicts
  in a WPAN with multiple coordinators
• Solutions to beacon conflicts between
  coordinators at different WPANs
• Time synchronization solutions for 802.15.4
• Time offset problem for big superframe
• Parameter mismatch problem A MAC packet could be
  larger than a superframe
• Multiple superframe sizes in the same WPAN
• Error in Figure 76
• Priorities between commands and data
• Duplicated ASSOCIATE.response
• Further explanations for beacon conflict and time
  synchronization topics

4
Direct and Indirect Beacon Conflict Problems
within the same WPAN

• Direct conflict
• Multiple coordinators within the same POS
• Example Two coordinators with parent-child
  relationship

• Indirect conflict
• Coordinators cannot reach each other directly but
  there are devices within the overlapped area of
  their POSes
• Example Two coordinators use the same channel
  and their POSes overlap with each other

5
Three Cases for Indirect Beacon Conflicts (1)
Beacon
C1
C1
C2
C2

• Case 1 D1 has been associated to coordinator C1
  and is keeping waking up. Then Coordinator C2
  joins the WPAN by associating to coordinator C3.
  D1 is also within C2s POS. C2 cannot hear C1s
  beacon and may use the same channel with C1 and
  send beacons at almost the same time with C1. The
  beacon conflict happens at D1. D1 will lose its
  synchronization with C1 and conduct orphan scan.
  After it gets C1s coordinator realignment
  command, it still cannot get C1s beacons.

6
Three Cases for Indirect Beacon Conflicts (2)

• Case 2 D1 has been associated to coordinator C1
  and often goes to sleep. During its sleep period,
  Coordinator C2 joins the WPAN by associating to
  coordinator C3, and uses the same channel with C1
  and send beacons at almost the same time with C1.
  D1 is also within C2s POS. When D1 wakes up, it
  loses its synchronization with C1 and conducts
  orphan scan. After it gets C1s coordinator
  realignment command, it still cannot get C1s
  beacons.

7
Three Cases for Indirect Beacon Conflicts (3)

• Case 3 Two coordinators C1 and C2 have been in
  the WPAN. They cannot hear to each other and may
  use the same channel and send beacons almost the
  same time. Then D1 wants to join the WPAN but it
  happens to be at the overlapped area of C1 and C2
  with indirect beacon conflicts. And there are no
  other coordinators within D1s POS to allow D1 to
  associate. D1 conducts active or passive scan but
  cannot get any beacons correctly due to indirect
  beacon conflicts. It will report no-beacon to
  upper layers. But this is a kind of fake
  no-beacon because there are actually two
  coordinators close to D1.

8
Solutions to Direct Beacon conflict (1)

• Asynchronous superframe mode
• If there is no superframe synchronization
  requirement among coordinators in a WPAN,
  Asynchronous mode can be used, i.e., each
  coordinator decides its superframe starting point
  randomly to avoid beacon conflicts with others.
• However, this method introduces a new problem of
  collision between beacon and data frames.
• In addition, most beacon-enabled WPANs require
  synchronization among coordinators.

9
Solutions to Direct Beacon conflict (2)

• Change the superframe structure as starting with
  a Beacon period which can contain multiple beacon
  frames.
• How does each coordinator choose a sending time
  of its own beacon frame within the Beacon period
  to avoid beacon conflicts?
• Each coordinator maintains and updates a
  neighboring coordinator table which records the
  beacon time information of its direct and
  indirect neighboring coordinators.
• Beacon time information is included in the beacon
  frame.
• Before a coordinator associates or starts a new
  PAN, it conducts active scan. It can records the
  beacon times allocated to other coordinators and
  put the information into the neighboring
  coordinator table.Then it can choose its own
  beacon transmission time to avoid collisions with
  coordinators within its POS.

10
Solutions to Direct Beacon conflict (3)

• However, if two coordinators within the same POS
  join the WPAN almost at the same time, it is
  still possible that the two coordinators choose
  the conflicted beacon transmission time.
• A simple solution After a coordinator receives
  the association response command indicating
  successful and begins to do MLME-START, it will
  not send out a beacon in the first superframe.
  Instead, in the first one or several superframes,
  it will sense the channel during its beacon
  transmission time. If the channel idle, it will
  send beacons periodically, otherwise, it will
  re-choose its beacon transmission time to avoid
  conflicts.
• The beacon conflict cannot be avoided completely.
  A beacon conflict notification command should be
  added to report beacon collisions.
• But how does a coordinator know the beacon time
  information of other coordinators outside its POS
  but have potential indirect beacon collisions
  with it?
• Indirect beacon conflict is a serious problem but
  not easy to solve!

11
Solutions to Indirect Beacon conflict (1)

• Based on the beacon period solution
• Two kinds of methods
• Reactive approach
• A coordinator doesnt do much to avoid the
  indirect beacon collisions during its association
  stage. The indirect beacon collisions can be
  detected and resolved later.
• Simple implementation. Very small changes to
  802.15.4-2003. But long time to recover from
  indirect beacon collisions.
• Proactive approach
• A coordinator tries its best to avoid the
  indirect beacon collisions during association
  stage. If cannot avoided in advance, the indirect
  beacon collisions can be detected and resolved
  later.
• Any device (FFD or RFD) needs to have the
  capability of forwarding its parent coordinators
  beacon time information.
• A new command, beacon time notification, is
  added.
• Complicated to maintain the neighboring
  coordinator table but lower possibility to cause
  indirect beacon conflicts.

12
Solutions to Indirect Beacon conflict (2)

• Reactive approach
• For the first case After D1 loses its
  synchronization with C1, it will conduct orphan
  scan. After it gets C1s coordinator realignment
  command, if it cannot get beacons from C1, it
  will do orphan scan again. After it gets the
  realignment command again but still cannot get
  beacons from C1. It will send out a beacon
  conflict notification command which contains C1s
  address and beacon time information. Coordinators
  receiving the beacon conflict notification
  command will adjust its beacon time if a beacon
  conflict is found.
• For the second case After D1 wakes up, it will
  lose synchronization with its coordinator. It
  will conduct similar procedure with that for the
  first case.

13
Solutions to Indirect Beacon conflict (3)

• Reactive approach
• For the third case
• Just do nothing if we allow the fake no-beacon
  to be reported.
• If we want to detect this kind of fake
  no-beacon caused by beacon conflict, we can
  improve orphan scan procedure in 802.15.4-2003 as
  follows.
• Before D1 reports no-beacon, it will do the
  improved orphan scan in which all coordinators
  who received the orphan notification command will
  respond. If a coordinator finds a device record
  of D1 in its device list, it will reply with a
  coordinator realignment command, otherwise, it
  will reply with a beacon time notification
  command the tell its own beacon time information.
  If D1 doesnt receive any coordinator realignment
  command or beacon time notification command, it
  will report no-beacon, otherwise, D1 will
  analyze the commands received and send out a
  beacon conflict notification command if finds any
  conflicts. Coordinators receiving the beacon
  conflict notification command will adjust its
  beacon time if a beacon conflict is found.
• It can been seen the improved orphan scan
  procedure can also solve the problems in Case 1
  and 2, but introduces more signaling overhead
  and changes to 802.15.4-2003.

14
Solutions to Indirect Beacon conflict (4)

• Proactive approach
• First case
• Suggest that all devices respond to the beacon
  request command actively or passively. However,
  in 802.15.4-2003, only coordinators can respond
  beacon request command.
• After receiving a beacon request command, if a
  device is a coordinator, besides its beacons sent
  periodically, it will also reply with a beacon
  time notification command to report its parent
  coordinators beacon time information.
• ( Another possible method allow that one beacon
  frame can contain both its own and its parent
  coordinators beacon time information, so beacon
  notification commands from coordinators can be
  avoided).
• If a device who received the beacon request
  command is not a coordinator, it will reply with
  a beacon time notification command to report its
  parent coordinators beacon time information.
• With the above improvement, at the association
  stage, a coordinator can get beacon time
  information of other coordinators that have
  potential indirect beacon conflict with it.
• Solutions for the second and the third case are
  the similar with those in reactive approach.

15
Direct and Indirect Beacon Conflict among
different WPANs

• Direct conflict
• Multiple coordinators within the same POS but
  belong to different WPANs
• Example Two PAN coordinators at 868Mhz close to
  each other.

• Indirect conflict
• Coordinators cannot reach each other directly but
  there are devices within the overlapped area of
  their POSes
• Example Two WPANs use the same channel and their
  POSes overlap with each other

PAN1
PAN2
16
Solutions to Beacon conflicts among coordinators
in different PANs

• If there is superframe synchronization
  requirement between two WPANs, similar solutions
  with those for the same WPAN.
• If there is no superframe synchronization
  requirement between two WPANs, but coordinators
  are synchronized in each WPAN, the devices within
  the overlapped area need to detect the beacon
  conflict, and calculate the time relation between
  superframes from two WPANs. With the time
  relation, similar solutions to solve the beacon
  conflicts with those for coordinators within the
  same PAN.
• If the two PANs choose different Superframe
  sizes, the coordinator with the bigger superframe
  need to maintain a table to record those time
  slots in CAP and CFP allocated to beacons in the
  other WPAN to avoid the collisions between beacon
  and data frames. Another solution is to set
  different transmission priorities for beacons and
  data frames.

17
Problem Statement for Time Synchronization in
802.15.4

• Time synchronization is important
• Maintain superframe/slot synchronization among
  devices
• fine-tuned coordination of wake/sleep duty cycles
  to reduce power consumption
• Preserve the event orders
• Time synchronization is also important to
  security protocols since the clock reading is
  often used for encryption key generation
• Loop free routing (Robert Poor said)
• Difficulty
• Time drift due to various reasons including both
  software and hardware

18
Timing in Packet Transmission
Coordinator
Device
Packet reach MAC layer at t4
Packet created at t1
MAC
MAC
PHY
PHY
First bit on Channel at t2
First bit of Packet is received at t3

• At t1, packet is created in MAC layer. t1 is the
  carried timestamp
• At t2, the first bit of Packet is put on the
  channel by sender
• At t3, the first bit of Packet is received by
  receiver
• At t4, packet passes the PHY layer and is
  accepted by MAC layer

19
Timing Orders
Coors Clock
t1
t2
t3
t4
t1
t2
t3
t4
Devices Clock
At the same time point, the time readings maybe
different due to clock drift
20
In the above scenario

• Simple case
• Device simply adjusts its timer from t4 to t1.
  t1 is the timestamp in the packet received.
• However, t4 should be set to t4
• Errors Sources
• Propagation Delay
• t3 t2 message propagation time in the air
• Access Error
• t2 t1 time needed for processing at senders
  network interface before being put in the channel
• Receive Error
• t4 t3 time needed for processing at receivers
  network interface
• We need to minimize/estimate Access Error,
  Receive Error and estimate Propagation Delay

21
Propagation Delay
Beacon Interval
Coordinator
Propagation Delay
Device

• Propagation Delay varies for different devices
• POS is limited to 10m in 802.15.4-2003
• Propagation Delay is small (lt33.33ns) and
  relatively easier to calculate

22
Processing Error

• If there is no processing delay on both sides
• Packet Timestamp t1 should be the same as t2, i.e
  the time when the first bit is passed to the
  channel
• Receiving time t4 should be the same as t3,
  i.e. the time when the first bit is received
• Thus, to increase accuracy
• Timer should be read at the PHY layer in order to
  minimize the error.
• However, packet is created at the MAC layer,
  which implies the timestamp in sender side must
  be obtained at MAC layer

23
Solution 1

• Similar to 802.11, access error and receive error
  are estimated at the MAC layer
• Mechanism
• Coordinator estimates T t2-t1 and accordingly
  adjusts the timestamp in packet as t1T
• Device estimates T t4-t3
• At t4, device sets its timer to t1T T.

24
Solution 2

• Require the Physical layer support time reading
  function
• Mechanism
• At the coordinator side, it still estimates
  Tt2-t1 and accordingly adjusts the timestamp in
  packet to t1T.
• While in the device side, it reads the time at
  exactly t3 at PHY layer. Thus, the receiver
  error is minimized.
• Device adjusts its timer by adding t1T
  t3t2-t3t3-t3.
• Add attributes to PHY PIB
• phyTimeOn boolean
• Switch physical timer between on and off to avoid
  overhead
• phyRxTime
• The receiving time of the first bit of latest
  PSDU from the physical medium

25
Solution 3 To be more accurate

• Based on Solution 2, but the coordinator sends
  two packets to the device. The synchronization
  message carries the adjusted timerstamp while the
  following MAC command carries the actual
  transmitting time at the physical layer.
• Mechanism
• Coordinator estimates access error t2-t1 and
  accordingly adjusts the timestamp in
  synchronization message
• Coordinator sends synchronization message to
  device. t2 is recorded in phyTxTime
• Device receives synchronization message and reads
  the time t3 at physical layer
• Coordinator sends MLME-TIME.notify to device
• Device set its timer by adding t2 t3.
• If the MAC command is lost due to packet
  collision, the device could still use the
  adjusted timestamp to correct the local clock.

26
Solution 3 To be more accurate (Cont.)

• Add another attribute to PHY PIB
• phyTxTime
• The sending time of the first bit of previous
  PSDU at the physical medium
• Adding a new MAC command
• MLME-TIME.notify
• To carry phyTxTime

27
Error Upper Bound Estimation for All Above
Solutions

• Define new variable
• maxProcessingError
• maxPropagationDelay
• Synchronization Error Upper Bound
• maxProcessingError maxPropagationDelay

28
Other Issues in Time Synchronization

• Time synchronization conducted at association
  procedure
• Use Beacon for time synchronization in
  beacon-enable network
• Add optional timestamp fields to Beacon payload
• Adjusting Synchronization period
• Add a new variable aTimeSyncOrder
• aSuperframeDurationTimeaTimeSyncOrder
• Use specific message for time synchronization in
  non-beacon network

29
Time offset problem for big superframe

• PPM means parts per million which means, for 1
  milliion pulses, how many deviation will be
  there. Thus 40 ppm means for every 1 million
  (106) pulses, there would be 40 deviation. For a
  crystal with K MHZ, the clock offset per second
  would be 1/K K 40 40 us. And two
  neighboring nodes clock difference could be up
  to 80us per second in the worst case.
• With beacon order k, the length of the superframe
  is 602k16/62.5 ms 0.01536 2ks.
• At 2.5Ghz band,
• Transmission time for 1 symbol is 16us (1/62.5ms)
• A bit transmission takes about 1/250 ms 4 us
• In order to receive a packet, a node needs to
  sense at least 2 out of the 4 preambles in order
  to make sure its actually a packet. Thus, it can
  only miss at most 16bits. On the 2.4G band, the
  transmission time of 2 bytes is 16/250 0.064 ms
  64 us.

30
Beacon order Superframe duration Clock offset per superframe (40ppm) Offset of bits per superframe Offset of symbosls per superframe Frequency (1 sync per of superframes)
0 15.36ms 0.61us lt1 bit lt1 65
1 30.72ms 1.23us lt1 bit lt1 32
2 61.44ms 2.46us lt1 bit lt1 18
3 122.88ms 4.92us About 1 bit lt1 8
4 245.76ms 9.83us About 2 bits lt1 4
5 491.52ms 19.66us About 4 bits 1 2
6 983.04ms 39.32us 81byte 2 lt1
7 1.966s 78.64us 162 bytes 4 lt1
8 3.93s 157.29us 324bytes 8 lt1
9 7.86s 314.57us 648 bytes 16 lt1
10 15.73s 629.14us 12816 bytes 32 lt1
11 31.46s 1.26ms 25632 bytes 64 lt1
12 62.91s 2.52ms 51264 bytes 128 lt1
13 125.83s 5.03ms 128 bytes 256 lt1
14 251.66s 10.07ms 256 bytes 512 lt1
31
Time offset problem found from the table

• When beacon order is high, the slot boundary
  calculation might be inaccurate at the end of the
  superframe.
• Solution1 Parameter adjustment
• Solution 2 Clarify that in beacon-enabled
  network with big superframe size, GTS cannot be
  used. But how to decide the maximal Beacon order?

32
Parameter mismatch problem A MAC packet could be
larger than a superframe

• In some parameter settings, packet size could be
  bigger than superframe size
• 915 MHZ superframe order0 Beacon order0
• aBaseSuperframeDuration 1660/40 24 (ms)
• However ..
• aMaxPHYPacketSize 127 byte
• Time to tx maxpacket 1278/40 25.4ms gt 24 ms
• Maximum possible size
• Without backoff, 120 bytes,
• with 1 backoff 2 CCA, at most 112 bytes
• Same problem in 868 MHZ band

33
Solutions to parameter mismatch problem

• Solution 1 Decrease the maximum packet size for
  915 and 868 Mhz
• Solution 2 maxSuperframeOrder and macBeaconOrder
  begins from 1 instead of 0

34
Multiple superframe sizes in the same WPAN

• P.100, 7.1.14.1 MLME-START.request and P. 148
  7.5.2.4 Beacon generation, both PAN coordinators
  and coordinators can specify the Beacon order and
  superframe order
• 802.15.4-2003 didnt specify all coordinators
  within the same beacon-enabled WPAN should use
  the same superframe size
• If use different superframe sizes, collisions
  between data and beacon frames may happen
• Solution1 Specify same superframe size for all
  coordinators in the same WPAN by the PAN
  coordinator.
• Solution 2 Either distinguish priorities of data
  and beacon transmissions

35
Error in Figure 76

• According to page. 148, 7.5.2.3 Starting a PAN
  requires to perform Active Scan
• Page. 180, Figure 76 should add Active Scan after
  the Energy detection SCAN but before selecting
  PANId, shortAddress, and LogicalChannel

36
Priorities between commands and data

• Suggest to set different priorities for command,
  data and maybe ad-hoc beacon frames.
• Why?
• Some MAC commands would be more important than
  data
• Some commands or data may broadcast and cannot
  use ACK for reliable transmission
• Solution1 Set different back off contention
  window sizes for different priorities packets
• Solution2 Add some period of delay before back
  off, and different priorities packet will choose
  different delay time.

37
Duplicated ASSOCIATE.response Problem
Scenario p.71 Figure 25
ASSOCIATE.request
Acknowledgement
Device
Coordinator
ASSOCIATE.response
Ack Lost
ASSOCIATE.response
??
(retransmission)

• ACK frame could be lost even no access collision.
• What should device do with retransmitted
  ASSOCIATE.response ?

38
Solution to Duplicated ASSOCIATE.response

• Solution
• When a device receives duplicated
  ASSOCIATE.response, it checks whether its the
  same as the local configuration. If they are not
  matched, the device sends back ACK to the
  coordinator that sent this ASSOCIATE.response.
  Otherwise, it discards this ASSOCIATE.response.

39
Answers three questions on beacon conflicts

• Q1 Whats the probability of indirect beacon
  conflict? If it is rarely happens, there is no
  need to add mechanisms to make the standard
  complicated.
• A The probability could be high enough in some
  cases by theoretical analysis.
• Q2 Why to handle beacon conflicts at the MAC
  layer? It should be handled at the network layer.
• A It is possible to ask network layer to perform
  some tasks, however, MAC layer cannot avoid
  taking some actions besides a time information.
  In addition, handling beacon conflicts at MAC
  layer can avoid extra interactions between
  Network and MAC layers.
• Q3 Whats the minimized change to current
  802.15.4 to handle direct and indirect beacon
  conflicts?
• A Very small changes.

40
The probability of beacon conflict

• Two coordinators with parent-child relation must
  have beacon conflicts under 802.15.4-2003 if they
  synchronize to each other.
• A tree topology with three coordinators
  (grandfather- parent-child) is an obvious case
  for indirect beacon conflicts.
• The probability of direct and indirect beacon
  conflict depends on superframe size, beacon
  period size, and WPAN density, etc. In some cases
  it could be high.
• In a word, indirect beacon conflicts cannot be
  regarded as small probability event and be
  ignored.

41
The probability analysis for Indirect beacon
conflicts

• Assume Beacon period can hold n beacons totally.
• In a simple tree based multi-coordinator topology
  showed on the right, the probability of indirect
  beacon conflict is at least 1/(n-1).
• If the superframe size is small, n should not be
  very large, for example, if n8, the beacon
  conflict probability should be no less than
  14.3.

42
The probability analysis for Indirect beacon
conflicts

• Generally, assume Beacon period can hold n
  beacons totally, and a coordinator want to join
  the WPAN by association, and there are m other
  coordinators within its POS and k other
  coordinators within its indirect beacon conflicts
  area.
• The probability of indirect beacon conflict is at
  least 1/(n-m-k).
• For example, in the right diagram, if n8, m4,
  and k1, the beacon conflict probability should
  be no less than 33.

43
Handling beacon conflicts at MAC or Network
layer?

• P.17 of 802.15.4-2003, features of MAC sub layer
  are beacon management, ..
• When a coordinator associate, it gets neighboring
  coordinators beacons during the scan stage at
  the MAC layer, it can choose the beacon time at
  the MAC layer. There is no need to report to
  network layer first and then schedule beacons at
  the network layer by introducing the overhead of
  Interactions between two layers.
• Beacon conflicts can only happen with the double
  transmission range, it is local issue, can be
  handled at MAC layer.
• Beacon conflict detection can be handled at MAC
  layer
• PAN descriptor and device list handled at the MAC
  layer
• Neighboring table is handled at the network layer
• What could be taken at either network or MAC?
  What must be taken at the MAC layer?

44
(No Transcript)
45
Minimal changes to 802.15.4 for handling beacon
conflicts (1)

• Introduce new MAC constants or PIB attributes
  Length of beacon period macBeaconPeriodDuration,be
  acon slot size aBeaconSlotDuration, beacon slot
  number assigned to the coordinator
  macBeaconSlotAssigned, or other similar
  parameters about beacon period.
• (If consider beacons can have variable sizes,
  macBeaconPeriodDuration, macBeaconFrameDuration
  and macBeaconStartingPosition can replace the
  above three parameters).
• The above three parameters are required in both
  direct and indirect beacon conflict handlings.

46
Minimal changes to 802.15.4 for handling beacon
conflicts (2)

• Beacon conflict notification command needs to be
  added for indirect beacon conflict.
• Beacon time notification command needs to be
  added if fake no-beacon case need to be solved
  (optional).
• Neighboring coordinator table needs to be added
  if try to provide proactive method for indirect
  beacon conflict (optional).

47
More explanations about time synchronization part

• The ideas of solution 2 and 3 are very similar
  with those specified in IEEE-1588 (Thanks Ed for
  providing the information)
• However, IEEE-1588 doesnt define the related PIB
  attributes, MAC commands and Performance up bound
  parameters.
• We suggest the follow terms be specified in
  802.15.4 as optional
• Up bound parameters
• maxProcessingError
• maxPropagationDelay
• Solution 2
• phyTimeOn boolean
• Switch physical timer between on and off to avoid
  overhead
• phyRxTime
• The receiving time of the first bit of latest
  PSDU from the physical medium
• Solution 3
• phyTxTime
• MLME-TIME.notify
• Why? Some people told me their WPAN device
  hardware supports time reading and setting
  functions already. Parameter standardization
  helps to implement time synchronization between
  devices from different device providers.