<month year> doc.: IEEE 802.15-05-0256-00-0005 July 2007 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [IEEE 802.15.5 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:[+1-212-650-7260], FAX: [+1-212-650-8249], E-Mail:[lee@ccny.cuny.edu] Re: [] Abstract: [This proposal discusses Portability issue arising in IEEE 802.15.5 WPAN Mesh] Purpose: [This proposal is provided for the discussion for IEEE 802.15.5 WPAN Mesh] 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. R. Zhang, H. Jung, E. Lee, M. Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 email 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

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

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

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