Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

1. 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.

2. Motivation 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 13, July 2008

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

4. 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

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

6. 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.

7. 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. Slot3 Slot4 Slot5 Slot16 CH1 CH2 CH3 CH15

8. P2P GTS Allocation Rule 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. Slots CH 1 A->B CH 2 D->C Fig.1 inefficient GTS allocation D->C CH 1 A->B 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

9. 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.

10. 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.

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

12. 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.

13. 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.

14. Thanks