Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Supporting Peer to Peer Network and Improving throughput by enhanced GTS ] Date Submitted: [11 July, 2008] Source: [Jie Shen , Daoyuan Yao, Tao Xing, Z.F Zhao, Hanlin Deng] Company [Shanghai Institute of Micro-system and Information Technology, Vinno Technologies Inc. ] Address [NO.865 Changning Road, Shanghai, 200050, China] Voice:[+86 21 6251 1070], FAX: [+86 21 6213 2314], E-Mail:[Jerryshen08@gmail.com, liang_1@yahoo.com] Re: [IEEE 802.15.4e group] Abstract: [This document suggests a new solution adopting channel selection within GTS to support peer to peer communication, improve the throughput and reduce the time of peer to peer guaranteed communication] Purpose: [This document is a response to item a) better support the industrial markets and b)increase the GTS flexibility such as peer to peer in IEEE P802.15.SG4e Call for Application on 14 November, 2007] 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.

<11 January, 2008r> Motivation doc.: IEEE 802.15-<doc#> 13, July 2008 Current GTS is only for the connection between device and coordinator. GTS for the communication between device and device should be considered. There are not enough GTS with single channel, multi-channel could be used to improve the capacity Page 2 <author>, <company>

Overview 2006 STD Enhancement on GTS CAP CFP Inactive A B D E C CAP PAN Coordinator Device CAP CFP Inactive Beacon GTS 2006 STD A B D E PC C CAP CFP Inactive Beacon CHi CHj CHm …. PC A B C D E F G H J I Enhancement on GTS The coordinator use the public channel to allocate GTS on different channels.

GTS Maintenance and Extension Maintain the aMinCAPperiod slots when allocating GTS. (same as 2006 STD) GTS extension: P2C Mode (device to coordinator): Same as 2006 STD One P2C candidate channel P2P Mode ( device to device): 15 P2P candidate channels in 2.4GHz band which should be scanned before selected

P2P Mode ……. Channels Slots CH0 CH1 CH2 E-> PC: P2C GTS1 A-> B: P2P GTS1 C-> D: P2P GTS2 H-> PC: P2C GTS2 F-> G: P2P GTS3 J-> I: P2P GTS4 PC A B C D E PAN Coordinator Device F G H J I

P2P GTS Request The information of source and destination addresses should be added in the GTS request primitive. MLME-GTS.request ( GTSCharacteristics, P2PDstAddr, P2PSrcAddr, SecurityLevel, …. ) The reserved bit 6 of GTSCharacteristics shall contain the type of GTS. Subfield shall be set to zero if P2C mode, and set to one if P2P mode.

P2P GTS Allocation Channels are scanned in order from lowest channel number to highest. PAN coordinator can decide which channels could be used to allocate GTS for P2P. PAN coordinator start checking the candidate channels in order to find the channel which has enough capacity to allocate GTS. Once finding the suitable channel (having enough capacity), then allocate GTS on that channel. After scanning all channels, if there is no channel having enough capacity for the GTS allocation, PAN coordinator shall reject the GTS request. CH1 CH2 CH3 CH15 Slot3 Slot4 Slot5 Slot16

P2P GTS Allocation Rule Rule 1: Slots Rule 1: The PAN coordinator first considers allocating a new GTS on the channel with allocated GTSs and enough capacity, otherwise, other suitable channel will be selected. Rule 2: If there are several P2P GTSs related with one node (node B), The PAN coordinator shall guarantee that there is no overlay slots between any two P2P GTSs. See Fig.3 and Fig.4. CH 1 A->B CH 2 D->C Fig.1 inefficient GTS allocation CH 1 A->B D->C CH 2 Fig.2 efficient GTS allocation Slots CH n A->B CH m B->C Fig.3 conflicting GTS allocation CH n A->B CH m B->C Fig.4 valid GTS allocation unallocated slot

P2P GTS Usage The device need to check the validity of GTS transmission and receiving. The device should switch transmission channel to specified channel at the beginning of P2P GTS, and switch back to P2C channel at the end of P2P GTS.

GTS Deallocation All GTS deallocation request of device shall be transmitted on the P2C channel during CAP period. The PAN coordinator deallocates the expired P2P GTS.

P2P GTS Reallocation The PAN coordinator shall remove the gaps in the P2P channels, but will not switch any GTS among different channels. CAP CFP Inactive GTS3 GTS2 GTS1 GTS4 GTS5 GTS6 GTS7 GTS8 GTS9 A CAP CFP Inactive GTS3 GTS1 GTS4 GTS5 C GTS9 GTS7 CAP CFP Inactive GTS3 GTS1 GTS4 GTS5 GTS6 GTS7 GTS8 GTS9 B GTS2

P2P GTS Expiration Since PAN coordinator can not check whether the P2P GTSs on different channels are idle. Each P2P GTS should be valid less then aMaxP2PGTSDuration superframes, then will expire automatically. After the expiration, the device has to request GTS again in case of necessity. The PAN coordinator will deallocate any expired GTS.

Conclusion Increase the capacity of network. Support Peer to Peer communication within GTS. Support channel selection in order to improve throughput and reduce the time delay. Compatible with 802.15.4 2006 STD.

Thanks