1. <month year>
doc.: IEEE
July 2007
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [IEEE WPAN Mesh Networks]
Date Submitted: [July, 2007]
Source: [Rui Zhang*, Hakyung Jung**, Eunjoo Lee ***, Myung Lee*]
Company [*CUNY, ** SNU, *** ETRI]
Address [Electrical Engineering, Steinman Hall, 140th St & Convent Ave, New York, NY 10031, USA]
Voice:[ ], FAX: [ ],
Re: []
Abstract: [This proposal discusses Portability issue arising in IEEE WPAN Mesh]
Purpose: [This proposal is provided for the discussion for IEEE WPAN Mesh]
Notice: This document has been prepared to assist the IEEE P 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 P
R. Zhang, H. Jung, E. Lee, M. Lee
Zheng, Liu, Zhu, Wong, Lee, Samsung

2. IEEE 802.15.5 WPAN Portability Proposal
July 2007
IEEE WPAN Portability Proposal
Rui Zhang*, Hakyung Jung**, Eunjoo. Lee***, Myung Lee*
* CUNY, ** SNU, *** ETRI
R. Zhang, H. Jung, E. Lee, M. Lee

3. July 2007
Objectives
To propose a leaf node portability based on the current IEEE draft.
Proposed leaf node portability includes following features:
Automatic portability detection
Compatible with current IEEE address scheme
Compatible with current IEEE routing scheme
R. Zhang, H. Jung, E. Lee, M. Lee

4. Proposal Outline Step1: Detect the problem
July 2007
Proposal Outline
Step1: Detect the problem
Step2: Carry out the MESH rejoin procedure
Step2-1: Active scanning
Step2-2: Select new parent & Association request (Portable DEV)
Step2-3: Address allocation & Association response (Potential Parent)
Step3: Inform relevant nodes of the portable node’s movement
Step4: Update the link-state table
R. Zhang, H. Jung, E. Lee, M. Lee

5. Step1: Detect the problem
July 2007
Step1: Detect the problem
R. Zhang, H. Jung, E. Lee, M. Lee

6. Step1: Detect the problem
July 2007
Step1: Detect the problem
Detection by leaf node
Data
No Ack
Ack X
Data
Detection the link failure by ACK missing
Optionally, use of absence of periodic Hello exchanges
depending on the frequency of Hello interval
In step 1: What would they (either parent or the leaf node) do when they detect the link failure (after trying several ACK)?
Don’t they already inform the originator of the link or node failure and update neighbor table?
How this mobility (or portability case) is different from the link or node failure?
I remember we discuss this. What was the decision we made about this problem?
Does old parent wait until it receive move-notify message from the new parent?
Clarify this.
R. Zhang, H. Jung, E. Lee, M. Lee

7. Step1: Detect the problem
July 2007
Step1: Detect the problem
No Ack
Detection by parent
Data
Data X
Ack
The same detection method as before.
Note: If the parents detect the problem, it will trigger the link
failure process (probe).
- The parent broadcasts link failure and relevant nodes change
NB list and connectivity matrix
- If any node sends packet to the portable node before it
report its new address, relevant nodes will send back route
error message to the sender.
Grammar: If the parent detects the problem….
R. Zhang, H. Jung, E. Lee, M. Lee

8. Step 2: Carry out the MESH rejoin procedure
July 2007
Step 2: Carry out the MESH rejoin procedure
R. Zhang, H. Jung, E. Lee, M. Lee

9. Step 2: Carry out the MESH rejoin procedure
July 2007
Step 2: Carry out the MESH rejoin procedure
Step2-1: Active scanning
- Initiates the MESH rejoin procedure.
- Performs ‘active scanning’
- Beacon frame contain coordinator status.
R. Zhang, H. Jung, E. Lee, M. Lee

10. Step 2: Carry out the MESH rejoin procedure
July 2007
Step 2: Carry out the MESH rejoin procedure
Potential parent with insufficient capability
Beacon (w/ incapable status)
Beacon (w/ capable status)
Potential parent with sufficient capability
Portable device
Additional information in beacon payload can prevent the portable device from selecting an incapable device as a suitable parent
R. Zhang, H. Jung, E. Lee, M. Lee

11. Step 2: Carry out the MESH rejoin procedure
July 2007
Step 2: Carry out the MESH rejoin procedure
Step2-2: Select new parent & Association request
(Portable DEV)
- Choose the suitable parent address
Note: “suitable parent” is regarded as implementation issue
Rejoining to previously joined parent can be advantageous
- Initiate MAC association procedure.
R. Zhang, H. Jung, E. Lee, M. Lee

12. Step 2: Carry out the MESH rejoin procedure
July 2007
Step 2: Carry out the MESH rejoin procedure
Step2-3: Address allocation & Association response
-The MDEV that received MAC Association Request command
determines whether it has knowledge of requesting device
If yes, allocate the previously assigned short address
If no, assign new short address
- Association Response with new short address for portable device.
- If the attempt to rejoin was unsuccessful, trigger the rejoin procedure
with the second best potential parents from step2-2.
R. Zhang, H. Jung, E. Lee, M. Lee

13. Step 2: Carry out the MESH rejoin procedure
July 2007
Step 2: Carry out the MESH rejoin procedure
Potential parent with insufficient capability
Beacon (w/ incapable status)
Beacon (w/ capable status)
Potential parent with sufficient capability
Associate Response (Rejoin)
Portable device
Associate Request (Rejoin)
The Associate response will contain the short address for the portable device
R. Zhang, H. Jung, E. Lee, M. Lee

14. Step 3: Inform relevant nodes of the node’s movement
July 2007
Step 3: Inform relevant nodes of the node’s movement
Note: We have two different approaches to inform the portability.
Centralized: we should inform old parents and network
coordinator(NC) of the portable device rejoin.
Distributed: we only need to inform old parents of the portable
device rejoin.
R. Zhang, H. Jung, E. Lee, M. Lee

15. Step 3: Centralized: Inform the old parent and NC of the rejoin
July 2007
Step 3: Centralized: Inform the old parent and NC of the rejoin
Unicast Rejoin-Notify to the old parent and NC
① Portable device IEEE address
② Portable device new short address
③ Portable device previous short address
NC updates the Address Mapping Table
NC shall maintain Address Mapping Table, which stores a mapping between IEEE address and short address of devices
R. Zhang, H. Jung, E. Lee, M. Lee

16. Step 3: Centralized: Inform the old parent and NC of the rejoin
July 2007
Step 3: Centralized: Inform the old parent and NC of the rejoin
On receipt of Rejoin-Notify, the old parent will broadcast Move Notify containing the old and new short address.
On receipt of Move-Notify, the devices change the status of corresponding entry in neighbor list to “Moved” state and update the connectivity matrix
R. Zhang, H. Jung, E. Lee, M. Lee

17. Step 3: Centralized: Inform the old parent and NC of the rejoin
May 2005
Step 3: Centralized: Inform the old parent and NC of the rejoin
After that, Once there is a packet for the portable device.
Any device having information of “moved node” will indicate this error by replying Route Error to the originating sender
On receipt of Route Error, the originating sender will query NC about new short address
On receipt of query, the NC will respond the new short address to the originating sender
Zheng, Liu, Zhu, Wong, Lee

18. Step 3: Centralized: Inform the old parent and NC of the rejoin
July 2007
Step 3: Centralized: Inform the old parent and NC of the rejoin
Addr Request and response
Data
3. Update Address Mapping Table
Route Error
4. Move Notify
2.Rejoin Notify X
Data
Associate exchange
4. Move Notify
Pan Coordinator
Portable device
1. Move
Data Sender
R. Zhang, H. Jung, E. Lee, M. Lee

19. Step 3: Distributed: Inform the old parent rejoin
July 2007
Step 3: Distributed: Inform the old parent rejoin
Compared with centralized approach, the distributed approach has several differences as follows:
Do not use network coordinator for keeping the address
mapping table.
The move notify contain both the new/old short address of
portable device.
Data will be re-routing when it arrives at nodes which receive the move-notify.
Date will be re-routing when it arrives at nodes that receive the move-notify.
R. Zhang, H. Jung, E. Lee, M. Lee

20. Step 3: Distributed: Inform the old parent rejoin
July 2007
Step 3: Distributed: Inform the old parent rejoin
Data
Addr Resp
3. Move Notify
2.Rejoin Notify X
Data
Associate exchange
3. Move Notify
As I asked before, in the picture, does (3) Move Notify happened as a response to (2) Move Notify from a new parent? I think so.
Then, again, what does the old parent do until it is notified of the “Move Notify”?
Shouldn’t old parent first report error (by broadcasting two hop+1) as soon as it detects the missing ACKs (possbilities are 1) link failure between the old parent and the leaf node, 2) leaf node failure, or 3) leaf node mobility.
Clarify this. If the sender keeps on sending data to the leaf node, how do you handle the situation.
Assume usually, the time taken between the movement would be quite large, perhaps, upto 1 or two minutes to hours.
This problem has to be linked to error conditions (link or node failure cases).
My intuition is that first, the old parent regards the situation as link failure to leaf node or leaf node failure, and then, inform neighbors (broadcast two hop +1) of the link failure or node failure and update the two hop neighbor table in the regions (and optionally send unicast error message to the sender). Then, if the data from sender arrives around this area, the packet will be dropped (or buffered in the mobility case) and the first node encountering the data will unicast the sender of the node failure. At this time, it does not know whether the node moved away or it is really node or link failure.
Once it received “move-notify”, then, only then, it broacasts two hop +1 neighbors about the movement.
Most likely in the realistic scenarios, the sender by now inform the upper layer that the destination is not reachable. So, there may not be new packets to come to the old leaf node.
Let us discuss this further, via first. Without resolving this it would be problematic.
Let me know what you think.
Pan Coordinator
Portable device
1. Move
Data Sender
R. Zhang, H. Jung, E. Lee, M. Lee

21. Step 4: Update the link-state table
July 2007
Step 4: Update the link-state table
R. Zhang, H. Jung, E. Lee, M. Lee

22. Step 4: Update the link-state table
July 2007
Step 4: Update the link-state table
Update the link-state table : New parent broadcasts Hello message to notify the neighbors of its link-state change
R. Zhang, H. Jung, E. Lee, M. Lee

23. Thanks Q & A Right now the implementation is in progress. July 2007
R. Zhang, H. Jung, E. Lee, M. Lee