Doc.: IEEE 802.15-04-0313-01-004b Submission July 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi...

July 2004

H. Shao, J. Zhang, H. Dai, Mitsubishi Electric Slide 1

doc.: IEEE 802.15-04-0313-01-004b

Submission

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)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 ]Voice:[617-621-7517], FAX: [617-621-7550], EMail:[[email protected]]

Re: [Response to the call for proposal of IEEE 802.15.4b, Doc Number: 15-04-0239-00-004b.]

Abstract: [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.

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

Enhancements to 802.15.4

Huai-Rong Shao, Jinyun Zhang, and Hui Dai

Mitsubishi Electric Research Laboratories

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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

C1 C2

D1

C2

C1

Beacon

C2

C1

Beacon

C1 C2D1

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

Three Cases for Indirect Beacon Conflicts (1)

• 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 C2’s POS. C2 cannot hear C1’s 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 C1’s coordinator realignment command, it still cannot get C1’s beacons.

C2

C1

Beacon

C1 C2D1

C3

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission


• 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 C2’s POS. When D1 wakes up, it loses its synchronization with C1 and conducts orphan scan. After it gets C1’s coordinator realignment command, it still cannot get C1’s beacons.

C2

C1

Beacon

C1 C2D1

C3

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission


• 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 D1’s 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.

C2

C1

Beacon

C1 C2D1

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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.

C2

C1

C3

C1 C2D1

C3

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission


• 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.

Beacon

BP

Time

CAP CFP

Superframe

CAP: Contention Access PeriodCFP: Contention Free PeriodBP: Beacon Period

BP CAP CFP

Superframe

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission


• 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!

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

Solutions to Indirect Beacon conflict (1)

• Based on the beacon period solution• Two kinds of methods

– Reactive approach • A coordinator doesn’t 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 coordinator’s 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.

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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 C1’s 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 beacon’s from C1. It will send out a beacon conflict notification command which contains C1’s 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.

C2

C1

Beacon

C1 C2D1

C3

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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 doesn’t 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.

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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 coordinator’s beacon time information.

• ( Another possible method: allow that one beacon frame can contain both its own and its parent coordinator’s 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 coordinator’s 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.

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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

C1 C2

D1

C2

C1

Beacon

C2

C1

Beacon

C1 C2D1PAN1 PAN2

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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.

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

Timing in Packet Transmission

• 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

PHY PHY

MAC MACPacket created

at t1

First bit of Packet is received at t3

Packet reach MAC layer at t4

First bit on Channelat t2

Coordinator Device

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

Timing Orders

Coor’s Clock

Device’s Clock

t1 t2 t3 t4

t1’ t2’ t3’ t4’

At the same time point, the time readings maybe different due to clock drift

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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 sender’s network interface before being put in the channel

– Receive Error • t4 – t3: time needed for processing at receiver’s network interface

• We need to minimize/estimate Access Error, Receive Error and estimate Propagation Delay

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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

Propagation DelayBeacon Interval

Propagation Delay Coordinator

Device

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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 t1+T– Device estimates T’ = t4’-t3’– At t4’, device sets its timer to t1+T+ T’.

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

Solution 2

• Require the Physical layer support time reading function• Mechanism:

– At the coordinator side, it still estimates T=t2-t1 and accordingly adjusts the timestamp in packet to t1+T.

– 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 t1+T– t3’=t2-t3’~=t3-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

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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.

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

Error Upper Bound Estimation for All Above Solutions

• Define new variable – maxProcessingError – maxPropagationDelay

• Synchronization Error Upper Bound: – maxProcessingError + maxPropagationDelay

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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

• aSuperframeDurationTime*aTimeSyncOrder

• Use specific message for time synchronization in non-beacon network

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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 (10^6) 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 60*2k*16/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 it’s 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.

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

Beacon

orderSuperframe 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 <1 bit <1 65

1 30.72ms 1.23us <1 bit <1 32

2 61.44ms 2.46us <1 bit <1 18

3 122.88ms 4.92us About 1 bit <1 8

4 245.76ms 9.83us About 2 bits <1 4

5 491.52ms 19.66us About 4 bits 1 2

6 983.04ms 39.32us 8=1byte 2 <=1

7 1.966s 78.64us 16=2 bytes 4 <=1

8 3.93s 157.29us 32=4bytes 8 <=1

9 7.86s 314.57us 64=8 bytes 16 <=1

10 15.73s 629.14us 128=16 bytes 32 <=1

11 31.46s 1.26ms 256=32 bytes 64 <=1

12 62.91s 2.52ms 512=64 bytes 128 <=1

13 125.83s 5.03ms 128 bytes 256 <=1

14 251.66s 10.07ms 256 bytes 512 <=1

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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?

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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 order=0 Beacon order=0

• aBaseSuperframeDuration =16*60/40 = 24 (ms)

• However ..– aMaxPHYPacketSize = 127 byte – Time to tx maxpacket = 127*8/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

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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 didn’t 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

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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.

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

Duplicated ASSOCIATE.response Problem

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

Scenario : p.71 Figure 25

ASSOCIATE.request

Acknowledgement

ASSOCIATE.response

Ack Lost

ASSOCIATE.response

Device Coordinator

(retransmission)??

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

• Solution– When a device receives duplicated ASSOCIATE.response,

it checks whether it’s 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.

Solution to Duplicated ASSOCIATE.response

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

Answers three questions on beacon conflicts

• Q1: What’s 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: What’s the minimized change to current 802.15.4 to handle direct and indirect beacon conflicts?

• A: Very small changes.

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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.

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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 n=8, the beacon conflict probability should be no less than 14.3%.

C1

C2

C3

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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 n=8, m=4, and k=1, the beacon conflict probability should be no less than 33%.

C

GC1

PC2

C1 C2

Cm

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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?

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

C

Different beacon conflict areas for a coordinator

Direct beacon conflict area

Indirect beacon conflict area

None beacon conflict area

r r

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

Minimal changes to 802.15.4 for handling beacon conflicts (1)

• Introduce new MAC constants or PIB attributes: Length of beacon period macBeaconPeriodDuration,beacon 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.

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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).

July 2004


doc.: IEEE 802.15-04-0313-01-004b

Submission

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 doesn’t 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.

Doc.: IEEE 802.15-04-0313-01-004b Submission July 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi...

Documents

Transcript of Doc.: IEEE 802.15-04-0313-01-004b Submission July 2004 H. Shao, J. Zhang, H. Dai, Mitsubishi...