Submission March, 2007 Chunhui Zhu / SamsungSlide 1 Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [IEEE WPAN Mesh – Technical Discussion] Date Submitted: [March 13, 2007] Source: [Chunhui Zhu] Company [Samsung] Address [75 W Plumeria Dr. San Jose, CA 95134] Voice:[ ], FAX: [ ], Re: [] Abstract:[This is for the discussion on low rate WPAN mesh.] Purpose:[for discussion and reference] 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

Submission March, 2007 Chunhui Zhu / SamsungSlide 2 Low Rate WPAN Mesh Discussion Chunhui (Allan) Zhu Mar. 13 th, 2007 Samsung Electronics

Submission March, 2007 Chunhui Zhu / SamsungSlide 3 Outline Current Technical Issues Additional Features Desired Our Ultimate Objectives

Submission March, 2007 Chunhui Zhu / SamsungSlide 4 Current Technical Issues

Submission March, 2007 Chunhui Zhu / SamsungSlide 5 In order not to change the existing implementations of SSCS and MAC, we need to make these two interfaces identical. Reference Model

Submission March, 2007 Chunhui Zhu / SamsungSlide 6 Review – SSCS Primitives IEEE Address

Submission March, 2007 Chunhui Zhu / SamsungSlide 7 Review – SSCS Primitives

Submission March, 2007 Chunhui Zhu / SamsungSlide 8 Data Plane If we look at the interface SSCS provides to its own upper layer, we will see it can only get three parameters from the upper layer: SrcAddr, DstAddr and Data. Question 1: How SSCS get the additional information to feed this primitive? SSCS MAC

Submission March, 2007 Chunhui Zhu / SamsungSlide 9 MAC Data Service This is the interface the SSCS will use to communicate with our mesh layer (mesh services). Question #2: Is the information enough for mesh layer? For comparison, ZigBee’s Radius, NonmemberRadius, DiscoverRoute SecurityEnable are not supported in MAC primitives, although some of them are not needed in our case. What if we need some parameters that are not included in this primitive? Making MESH-DATA a superset of MCPS-DATA could be a solution.

Submission March, 2007 Chunhui Zhu / SamsungSlide 10 How to Differentiate Uni-/Multi-/Broadcast from Upper Layer Note by using the MESH- DATA.request itself, we are not able to tell whether the packet is to be transmitted using unicast, multicast or broadcast. Address 0xffff can be one hop broadcast but does not mean network-wide broadcast. The TxOptions parameter does not tell us that. MESH-DATA.request ( SrcAddrMode, SrcPANId, SrcAddr, DstAddrMode, DstPANId, DstAddr, msduLength, msdu, msduHandle, TxOptions )

Submission March, 2007 Chunhui Zhu / SamsungSlide 11 Status of Mesh Layer The MESH-DATA.confirm primitive is supposed to provide the status of the mesh layer to the upper layer. However, due to the fact that we are using the MAC primitives to communicate with the upper layer, if we define more status values other than those have been defined in the MAC/PHY, the upper layer may not be able to understand them. Sometimes it is useful for the upper layer to know the status of mesh layer. But in this case we can only inform the upper layer the status of the MAC layer unless we add more values for mesh layer, and the application layer above SSCS can understand them.

Submission March, 2007 Chunhui Zhu / SamsungSlide 12 End-to-End ACK? Since the upper layer is not aware of the exist of the mesh, it can request ACK using the TxOptions parameter in the MESH- DATA.request primitive. Question: –Do we interpret this as mesh layer end-to-end ACK? Or is it too complicated?

Submission March, 2007 Chunhui Zhu / SamsungSlide 13 Types of Devices Usually in mesh networks there are two kinds of devices. –MAC layer: FFD and RFD –Network layer: Router/Relay and non-Router/End Devices Shall we define two kinds of devices? –If yes, shall we use MAC terms or Network terms? In terms of describing functions, NWK terms are better; In terms of showing clear layering, MAC terms are better. –Current terms used in the spec: WPAN Mesh Device (WMD) vs. WPAN End Device (WED) –Better ideas? _________________ How much do we want to differentiate these two types of devices? –For example, RFDs don’t send beacon, cannot allow other nodes to join, can sleep and etc.

Submission March, 2007 Chunhui Zhu / SamsungSlide 14 Link Quality & Routing Matrix Shall we use link quality for link and route selection? –Suggest we at least use link quality in the association process (selecting the right parent node to join).

Submission March, 2007 Chunhui Zhu / SamsungSlide 15 Beacon or Non-Beacon Our current draft candidate supports non-beacon network. Do we also want to support beacon network? –If so, how do we do it?

Submission March, 2007 Chunhui Zhu / SamsungSlide 16 Additional Features Desired

Submission March, 2007 Chunhui Zhu / SamsungSlide 17 Power Saving Features Based on our experience, battery life of always-on routers/mesh access points will last only for days. So the support of low power router is critical for the success of this recommended practice. Shall we open for proposals/contributions on this feature?

Submission March, 2007 Chunhui Zhu / SamsungSlide 18 Portability/Mobility Portability/mobility is also a very important and necessary feature for many applications. Examples include –A LR-WPAN device which is a universal remote control may move from one room to another to control different devices. –A LR-WPAN device which is also a cell phone or PDA may be carried from one point to another and wants to be connected all the time. –As in Ho-In’s smart parking lot example, the LR-WPAN device can be installed in a car. I think this is also a topic we may want to open for additional contribution again.

Submission March, 2007 Chunhui Zhu / SamsungSlide 19 Our Ultimate Objectives Based on current situation, especially the man power we put into the project, I believe our best bet is to come up with a Simple mesh with all the essential features, which, in my mind, include –Reliable, scalable and robust unicast, multicast and broadcast routing (efficient broadcast desirable and lacking) –Very low power consumption, both routers and end devices. –Supports portability/mobility. –Other must-haves?