<month year> doc.: IEEE Nov 2005

Slides:



Advertisements
Similar presentations
IEEE r0 Submission July 2007 R. Zhang, H. Jung, E. Lee, M. Lee Slide 1 Project: IEEE P Working Group for Wireless Personal Area Networks.
Advertisements

Doc.: IEEE xxx Submission January 2015 N. Sato and K. Fukui (OKI)Slide 1 Project: IEEE P Working Group for Wireless Personal Area.
Doc.: IEEE b Submission September 2004 Myung Lee, et al,Slide 1 NOTE: Update all red fields replacing with your information; they.
Doc.: IEEE e Submission Jan, 2009 Ning Gu, Liang Zhang, Haito Lui Slide 1 Project: IEEE P Working Group for Wireless Personal.
Doc.: IEEE //0128r0 Submission Slide 1 March 2006 J. Zheng, Samsung CUNY Project: IEEE P Working Group for Wireless Personal Area.
Doc.: IEEE Submission March, 2006 Chunhui Zhu, Michael Sim, Sebastian MaxSlide 1 Project: IEEE P Working Group for Wireless.
July 12, 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Increasing Broadcast Reliability] Date.
Submission Title: [Proposal for MAC Peering Procedure]
March 2004 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Synchronized Beacon Propagation for Spanning.
<month year> doc.: IEEE <# > <April 2008>
June 2006 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposed Scenarios for Usage Model Document.
<month year> doc.: IEEE < e > <Sep 2008>
doc.: IEEE <doc#>
Submission Title: [SG5 Closing Report Mar04]
doc.: IEEE <doc#>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
Submission Title: [Beacon scheduling MAC hooks]
November, 2004 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Proposal for PostBeaconDelay in b]
<month year> doc.: IEEE July 2005
<month year> doc.: IEEE < > <September 2017>
<May,2009> doc.: IEEE <doc .....> <July 2009>
Submission Title: Example of P2P route discovery
<month year> September 2012
doc.: IEEE <doc#>
Submission Title: [Proposal for MAC Peering Procedure]
Date Submitted: [November 9, 2009]
doc.: IEEE <doc#>
<month year> doc.: IEEE <xyz> January 2001
May 2006 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [A Solution to Exposed Node Problem in Mesh.
Submission Title: [TG5 Closing Report at Mid-Week Plenary, LA, CA]
Doc: xyz January 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG5 Closing Report]
Nov Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Implementation Approaches for LPWAN Extension]
doc.: IEEE <doc#>
November 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Distributed channel hopping MAC for industrial.
Jul 12, /12/10 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: Summary of L2R Preliminary Proposals.
doc.: IEEE <doc#>
doc.: IEEE <doc#>
Submission Title: [Proposal for MAC Peering Procedure]
Submission Title: [Shared GTS Structure]
November 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG5 Motions at Mid-Week Plenary] Date.
<month year> doc.: IEEE May 2005
Source: [Pat Kinney] Company [Kinney Consulting LLC]
doc.: IEEE <doc#>
<month year> doc.: IEEE <xyz> November 2000
Submission Title: [IEEE WPAN Mesh Reference Model]
doc.: IEEE <doc#>
July 12, 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Increasing Broadcast Reliability] Date.
doc.: IEEE <doc#>
May 2006 doc.: IEEE May 2006 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Mesh.
doc.: IEEE <doc#>
Submission Title: [Proposal for MAC Peering Procedure]
doc.: IEEE <doc#>
<month year> doc.: IEEE e doc.: IEEE < e >
<month year> doc.: IEEE August 2014
4 May 2019 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Issues with Beacon-Mode SuperFrame Structure.
doc.: IEEE <doc#>
doc.: IEEE <doc#>
doc.: IEEE <doc#>
<month year> doc.: IEEE < e> doc.: IEEE < e>b
Submission Title: [Extend-Superframe and GTS Structure]
doc.: IEEE <doc#>
<month year> doc.: IEEE July 2007
Submission Title: [IEEE WPAN Mesh – Technical Discussion]
<month year> doc.: IEEE July 2007
Source: [Chunhui Zhu] Company [Samsung]
May 2008 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [TG5 Motions at Mid-Week Plenary] Date Submitted:
doc.: IEEE <doc#>
May 2014 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: TG9 Hop Discussion Date Submitted: May 15, 2014.
Presentation transcript:

<month year> doc.: IEEE 802.15-05-0256-00-0005 Nov 2005 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [IEEE 802.15.5 WPAN Mesh Networks Summary] Date Submitted: [19 July, 2005] Source: [Jianliang Zheng, Yong Liu, Chunhui Zhu, Marcus Wong, Myung Lee] Company [Samsung] Address [Samsung Lab@CUNY, 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: [Call for Proposal: IEEE P802.15-5/0071] Abstract: [This document discusses Samsung’s proposal for IEEE 802.15.5 WPAN Mesh, based on Meshed-Tree approach.] Purpose: [This proposal is provided to be adopted as a recommended practice for IEEE 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. Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

IEEE 802.15.5 WPAN Mesh Networks <month year> doc.: IEEE 802.15-05-0256-00-0005 Nov 2005 IEEE 802.15.5 WPAN Mesh Networks Jianliang Zheng, Yong Liu, Chunhui Zhu, Marcus Wong, Myung Lee Samsung Lab @ CUNY Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

<month year> doc.: IEEE 802.15-05-0256-00-0005 Nov 2005 Objectives To construct Mesh Networking Layer over IEEE 802.15.4 MAC and PHY Proposed Mesh Network includes following features: Meshed Tree Formation Block Addressing Routing Key Pre-distribution * Multicasting ** Extensible to IEEE 802.15.3 MAC and PHY *, ** Refer to 15-05-0256-01-0005-802-15-5-mesh-networks-samsung Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

Contents Meshed tree approach Centralized approach <month year> doc.: IEEE 802.15-05-0256-00-0005 Nov 2005 Contents Meshed tree approach Centralized approach Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

Meshed Tree <month year> doc.: IEEE 802.15-05-0256-00-0005 Nov 2005 Meshed Tree Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

Outline Adaptive Robust Tree (ART) Mesh Networking Summary ART <month year> doc.: IEEE 802.15-05-0256-00-0005 Nov 2005 Outline Adaptive Robust Tree (ART) ART Meshed ART (MART) Mesh Networking Data Forwarding Route Discovery Tree Route Repair Summary Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

ART: Initialization Phase <month year> doc.: IEEE 802.15-05-0256-00-0005 Nov 2005 ART: Initialization Phase [children#][children#]=[8][6] A [beg,end,next]=[1,16,1] [beg,end,next]=[17,28,17] Stage 1: Association [5][2] [5] B J Stage 2: Reporting number of children [3,12,3] [13,16,13] [19,28,19] C H K [1][2][1] [3][1] [1] Stage 3: Address assignment An ART is formed. Additional addresses can be reserved. [5,6,5] [7,10,7] [11,12,11] [21,26,21] [27,28,27] [15,16,15] D E G I L O [1][1] [0] [0] [1] [0] [0] [23,24,23] [25,26,25] [9,10,9] F M N [0] [0] [0] Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

ART: Normal Phase Normal data transmissions <month year> doc.: IEEE 802.15-05-0256-00-0005 Nov 2005 ART: Normal Phase [8][6] A 0 Normal data transmissions [1,16,1] [17,28,17] [5][2] [5] B 1 J 17 [3,12,3] [13,16,13] [19,28,19] Example: Node C  node L C 3 H 13 K 19 [1][2][1] [3][1] [1] Nodes are still allowed to join the network [5,6,5] [7,10,7] [11,12,11] [21,26,21] [15,16,15] [27,28,27] D 5 E 7 G 11 I 15 L 21 O 27 [1][1] [0] [0] [1] [0] [0] [23,24,23] [25,26,25] [9,10,9] F 9 M 23 N 25 [0] [0] [0] Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

Neighbors treat each other as a child. <month year> doc.: IEEE 802.15-05-0256-00-0005 Nov 2005 Meshed ART (MART) Neighbors treat each other as a child. [8][6] [1,16,1] [17,28,17] A 0 [5][2] [5] [3,12,3] [13,16,13] [19,28,19] B 1 J 17 [1,16,1] [17,28,17] [13,16,13] Shorter path C H 13 [1] K [15,16,15] Elimination of SPOFs [17,28,17] …… D E G I L O F M N Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

Data Forwarding Start <month year> doc.: IEEE 802.15-05-0256-00-0005 Nov 2005 Find an optimal route in NTT? route in ARTT? Find an auxiliary Use the route found Start Use tree route 1 2 4 3 Y N Optimal routes Non-optimal routes Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

Route Discovery (1) Case 1: Source has an optimal route <month year> doc.: IEEE 802.15-05-0256-00-0005 Nov 2005 Route Discovery (1) A Case 1: Source has an optimal route No route discovery B J C H K D E G I L O Example 1: node F  node I (optimal non-tree route) F M N Example 2: node J  node M (optimal tree route) Optimal non-tree route Optimal tree route Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

<month year> doc.: IEEE 802.15-05-0256-00-0005 Nov 2005 Route Discovery (2) A B J E D C I H K L O G F M N Case 2: Source has no optimal route; but destination has. dst. Example 1: node F  node I Bi-directional routes are set up dst. Here only give an example that destination has an optimal non-tree route; The case that destination has an optimal tree route can be more easily handled. Example 2: node N  node J No routing entry created src. src. unicast RREQ unicast RREP existing optimal non-tree route Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

<month year> doc.: IEEE 802.15-05-0256-00-0005 Nov 2005 Route Discovery (3) A Case 3: Neither the source nor the destination has optimal route. B J C H K Example: node I  node O D E G I L O src. dst. Source will time out if the unicast RREQ does not get through; then the source will flood an RREQ. F M N unicast RREQ broadcast RREQ RREP Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

Tree Route Repair Node K fails <month year> doc.: IEEE 802.15-05-0256-00-0005 Nov 2005 Tree Route Repair A Node K fails Node J broadcasts an RREQ to locate node K, with a limited TTL. B J C H K All nodes below node K that have received the RREQ reply. D E G I L O Node J selects the best path and sends an RCFM to activate it. If no reply, node J will increase TTL and try again. An RERR will be sent to the source if several tries fail. Not all broadcast propagations are shown in the Figure. Multiple branches (e.g, also branch O) can be repaired during above procedure. F M N MART route RREP RREQ RCFM Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

Tree Route Repair (cont.) <month year> doc.: IEEE 802.15-05-0256-00-0005 Nov 2005 Tree Route Repair (cont.) Data Forwarding after tree route repair A [desIn,19,28,down,19] [desIn,21,26,normal,13] B J 17 C H 13 K [desIn,21,26,normal,21] [srcIn,21,26,normal,17] Note the entry [srcIn,21,26,normal,17] at node H may be ignored if there is another high priority entry. For example, the path from node M to node C will be M  L  H  C. D E G I L 21 O [1][1] [23,24,23] [25,26,25] parent=13 F M N Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

Summary Adaptive address assignment Efficient tree repair <month year> doc.: IEEE 802.15-05-0256-00-0005 Summary Nov 2005 Adaptive address assignment avoiding “running out of addresses” problem Efficient tree repair no address re-assignment Meshed ART (MART) shorter path Robustness Mesh networking (Tree routing + Non-tree routing) optimal routes no broadcast (even with limited TTL) if either the source or the destination has an optimal route no flooding if there is a (non-optimal) route from the source to the destination Note that there is no RTS/CTS in 802.15.4. Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

Centralized Approach <month year> doc.: IEEE 802.15-05-0256-00-0005 Nov 2005 Centralized Approach Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

Basic Mechanisms Tree formation Tree addressing Tree routing <month year> doc.: IEEE 802.15-05-0256-00-0005 Basic Mechanisms Nov 2005 Tree formation Tree addressing Tree routing Topology server setup Beacon scheduling Reactive shortcut formation Two-address strategy Route repair Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

<month year> doc.: IEEE 802.15-05-0256-00-0005 Tree Formation Nov 2005 The node initiating the network becomes the PAN coordinator. In the network formation stage, all coordinators shall enable their receivers to catch beacon requests from new nodes. No regular beaconing is allowed before the beacon scheduling is done. New nodes perform active scan to collect beacons from their neighbors. Every new node selects a neighbor, which has the best path quality to the PAN coordinator, as its parent. Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

Tree Addressing <month year> doc.: IEEE 802.15-05-0256-00-0005 Nov 2005 Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

Tree Routing Node H sends a packet to node F. <month year> doc.: IEEE 802.15-05-0256-00-0005 Nov 2005 Tree Routing Node H sends a packet to node F. As H does not have any child, it forwards the packet to its parent C. C finds that F has an address out of its address block. So it forwards the packet to its parent A. As F’s address falls into A’s address block, and A further finds that F’s address is between the addresses of child B and C, so A forwards the packet to B. B forwards the packet to F. Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

<month year> doc.: IEEE 802.15-05-0256-00-0005 Topology Server Setup Nov 2005 Either the PAN coordinator or a resource sufficient node can serve as the topology server. All other nodes can reach the topology server by using tree routing. Each coordinator shall report its superframe parameters and link states to the topology server. Each coordinator may periodically scan its neighbors' beacons and report significant link changes to the server. There can be two or more topology servers acting as backup of each other. Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

<month year> doc.: IEEE 802.15-05-0256-00-0005 Beacon Scheduling Nov 2005 When receiving the neighboring information of a coordinator, the topology server assigns a contention-free beacon time-slot to the coordinator. Every coordinator gets a beacon time slot that is not overlapped with the active periods of its two-hop neighbors. This two-hop beacon scheduling ensures that each node can correctly capture all its neighbors’ beacons and locate their active periods. Once a coordinator receives the beacon time assignment, it can emit regular beacons and operate in beacon-enabled mode. Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

Reactive Shortcut Formation <month year> doc.: IEEE 802.15-05-0256-00-0005 Reactive Shortcut Formation Nov 2005 An active source sends a shortcut request (SCRQ) message to the topology server. The topology server calculates the optimal shortcut by using the Dijkstra’s algorithm. The topology server sends a shortcut notification (SCNF) message to the destination. The destination sends a shortcut reply (SCRP) message to the source to establish routing entries along the shortcut. Relay nodes along the shortcut shall locate and record the active periods of their previous-hop and next-hop neighbors. Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

Summary Establish a self-routing tree to cover the whole network <month year> doc.: IEEE 802.15-05-0256-00-0005 Nov 2005 Summary Establish a self-routing tree to cover the whole network Schedule beacon transmissions at a topology server to avoid beacon collisions Calculate shortcuts between active source-destination pairs at a topology server to avoid flooding based route discovery Quickly recover from link/node failures by recalculating new routes or reforming the tree Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

Key Pre-Distribution <month year> doc.: IEEE 802.15-05-0256-00-0005 Nov 2005 Key Pre-Distribution Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

Key Pre-Distribution 1 6 Center 2 5 3 4 <month year> doc.: IEEE 802.15-05-0256-00-0005 Nov 2005 Key Pre-Distribution 1 6 Center 2 5 3 4 Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

K1 K2 K3 K4 K5 K6 K7 K8 K9 K10 1 2 3 4 5 6 <month year> doc.: IEEE 802.15-05-0256-00-0005 Nov 2005 1 2 3 4 5 6 K1 K2 K3 K4 K5 K6 K7 K8 K9 K10 Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

Common Key Computation <month year> doc.: IEEE 802.15-05-0256-00-0005 Common Key Computation Nov 2005 1 2 3 K34=H( )= 4 =Hash(K5||K10) 5 No other node can compute K34 ! 6 Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

WMN and Key Pre-Distribution <month year> doc.: IEEE 802.15-05-0256-00-0005 Nov 2005 WMN and Key Pre-Distribution Mesh clients 1 3 2 Need secure Connection ! 4 5 K45=H( ) K45=H( ) Backbone Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

WMN and Key Pre-Distribution <month year> doc.: IEEE 802.15-05-0256-00-0005 WMN and Key Pre-Distribution Nov 2005 1 3 2 4 EK45(message) 5 K45=H( ) K45=H( ) Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

WMN and Key Pre-Distribution <month year> doc.: IEEE 802.15-05-0256-00-0005 WMN and Key Pre-Distribution Nov 2005 5 K45=H( ) 1 3 EK45(message) 2 4 K45=H( ) Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung

Benefits of using KPDS in Distributed Key Management <month year> doc.: IEEE 802.15-05-0256-00-0005 Nov 2005 Benefits of using KPDS in Distributed Key Management Any link between nodes is secured through common key of a pair No need for on-line servers Simple node’s exclusion and association Self-healing through key refresh Robustness due to distributed solution Simple implementation and low resources requirements Zheng, Liu, Zhu, Wong, Lee Zheng, Liu, Zhu, Wong, Lee, Samsung