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
• Parameter mismatch problem
• Duplicated ASSOCIATE.response
• Priorities between commands and data
• Multiple superframe sizes in the same WPAN
• Error in Figure 76

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
• Detect the Superframe/Slot Boundary
• Maintain superframe synchronization among
  coordinators
• Preserve the event orders.
• Difficulty
• Clock 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

• Ideal 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 (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 in 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
• 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
• In the coordinator side, it still estimates t2-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 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 lSynchronization period
• Add a new variable aTimeSyncOrder
• aSuperframeDurationTimeaTimeSyncOrder
• Use specific message for time synchronization in
  non-beacon network

29
Parameter mismatch problem

• 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 278/40 25.4ms 24 ms
• Maximum possible size
• Without backoff, 120 bytes,
• with 1 backoff 2 CCA, at most 112 bytes
• Same problem in 868 MHZ band

30
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

31
Duplicated ASSOCIATE.response Problem
Scenario
ASSOCIATE.request
Acknowledgement
Device
Coordinator
ASSOCIATE.response
Ack Lost
ASSOCIATE.response
??
(retransmission)

• What should device do with retransmitted
  ASSOCIATE.response ?

32
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
  matched, the device sends back ACK to the
  coordinator that sent this ASSOCIATE.response.
  Otherwise, it discards this ASSOCIATE.response.

33
Priorities between commands and data

• Suggest to set different priorities for command,
  data and maybe ad-hoc beacon frames.
• Why?
• Command frame usually is more important than data
• Some commands broadcast and cannot use ACK for
  reliable transmission
• How? Set different backoff time between command
  and data transmissions

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
• Solution Either distinguish priorities of data
  and beacon transmissions or specify same
  superframe size for all coordinators in the same
  WPAN.

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