Presentation is loading. Please wait.

Presentation is loading. Please wait.

15-07-0639-00-0005 Submission March, 2007 Chunhui Zhu / SamsungSlide 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

Similar presentations


Presentation on theme: "15-07-0639-00-0005 Submission March, 2007 Chunhui Zhu / SamsungSlide 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)"— Presentation transcript:

1 15-07-0639-00-0005 Submission March, 2007 Chunhui Zhu / SamsungSlide 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [IEEE 802.15.5 WPAN Mesh – Technical Discussion] Date Submitted: [March 13, 2007] Source: [Chunhui Zhu] Company [Samsung] Address [75 W Plumeria Dr. San Jose, CA 95134] Voice:[408-544-5667], FAX: [408-544-5666], E-Mail: [c.zhu@samsung.com] Re: [] Abstract:[This is for the discussion on 802.15.5 low rate WPAN mesh.] Purpose:[for discussion and reference] 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.

2 15-07-0639-00-0005 Submission March, 2007 Chunhui Zhu / SamsungSlide 2 Low Rate WPAN Mesh Discussion Chunhui (Allan) Zhu Mar. 13 th, 2007 Samsung Electronics

3 15-07-0639-00-0005 Submission March, 2007 Chunhui Zhu / SamsungSlide 3 Outline Current Technical Issues Additional Features Desired Our Ultimate Objectives

4 15-07-0639-00-0005 Submission March, 2007 Chunhui Zhu / SamsungSlide 4 Current Technical Issues

5 15-07-0639-00-0005 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

6 15-07-0639-00-0005 Submission March, 2007 Chunhui Zhu / SamsungSlide 6 Review – SSCS Primitives IEEE Address

7 15-07-0639-00-0005 Submission March, 2007 Chunhui Zhu / SamsungSlide 7 Review – SSCS Primitives

8 15-07-0639-00-0005 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

9 15-07-0639-00-0005 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.

10 15-07-0639-00-0005 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 )

11 15-07-0639-00-0005 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.

12 15-07-0639-00-0005 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?

13 15-07-0639-00-0005 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.

14 15-07-0639-00-0005 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).

15 15-07-0639-00-0005 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?

16 15-07-0639-00-0005 Submission March, 2007 Chunhui Zhu / SamsungSlide 16 Additional Features Desired

17 15-07-0639-00-0005 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?

18 15-07-0639-00-0005 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.

19 15-07-0639-00-0005 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?


Download ppt "15-07-0639-00-0005 Submission March, 2007 Chunhui Zhu / SamsungSlide 1 Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)"

Similar presentations


Ads by Google