Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [Supporting peer to peer 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> doc.: IEEE 802.15-<doc#> Motivation Peer to peer communications with low latency are required in many scenarios of industrial applications. The current GTS allocation is not efficient to support peer to peer communication. The current superframe structure may not offer sufficient GTS slots for different QoS levels in one WPAN as only one channel used. Page 2 <author>, <company>

<11 January, 2008r> doc.: IEEE 802.15-<doc#> Enhancement on GTS Support the communication between device to coordinator, and device to device by enhancement on GTS. Introduce channel offset attribute to GTS descriptor to support channel selection within peer to peer GTS (P2P GTS). One CFP Slot may be allocated to more than one node’s GTS if the difference between any of their channel offset exceeds a specified parameter aMinOffsetThreshold. (15 channels can be allocated to GTS in the 2.4GHz bands) Page 3 <author>, <company>

GTS Allocation and Management 1. Overview 2. CAP Maintenance 3. GTS Extension 4. GTS Request 5. GTS Allocation 6. GTS Usage 7. GTS Deallocation 8. GTS Reallocation 9. GTS Expiration

1.Overview CAP CFP Inactive 2006 STD A B D E C Beacon GTS 2006 STD A B D E PC C Supporting Peer to Peer communication within GTS which can be redefined as “guaranteed time slots for any two nodes” CAP CFP Inactive Beacon PC A B C D E F G H J I Enhancement on GTS

2. CAP Maintenance Maintain the aMinCAPperiod slots when allocating GTS. (same as 2006 STD)

3. GTS Extension GTS extension on mode P2C mode: device to coordinator P2P mode: device to device GTS extension on channel The number of P2C candidate channel : 1 The number of P2P candidate channels which should be scanned before selected : 15

P2C Mode A B C D PC CAP CFP Inactive Beacon GTS 1 GTS 2 GTS 3 GTS 4 PAN Coordinator Device GTS 1 CAP CFP Inactive Beacon GTS 2 GTS 3 GTS 4

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

4. GTS Request For P2C mode, the MLME-GTS.request primitive is generated by the next higher layer of a device and issued to its MLME to request the allocation of a new GTS. For P2P mode, the MLME-GTS.request primitive is generated and information of source and destination addresses should be added in the GTS request primitive.

5. GTS Allocation For P2C mode, the PAN coordinator decides whether to allocate a GTS based on the requirements of the GTS request and the current available capacity on the P2C channel in the superframe. For P2P mode: Next page.

P2P GTS Allocation Method 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 (candidate channels). 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

6. GTS Usage P2C GTS usage: When the MAC sublayer of device receives the MCPS-DATA.request primitive with TxOptions, the validity of transmit GTS needs to be determined When the MAC sublayer of PAN coordinator receives the MCPS-DATA.request primitive with TxOptions, the validity of receive GTS needs to be determined.

GTS Usage P2P GTS usage: the device not only need to check the validity of transmit GTS or receive GTS, but also 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.

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

8. GTS Reallocation P2C mode: P2P mode: The deallocation of a GTS may result in the superframe becoming fragmented. The PAN coordinator shall ensure that any gaps in the P2C Channel are removed to maximize the length of the CAP. P2P mode: The PAN coordinator shall remove the gaps in the P2P channel, but will not shift any GTS among different P2P channels. CAP CFP Inactive GTS3 GTS2 GTS1 GTS4 GTS5 GTS6 GTS7 GTS8 GTS9 A CAP CFP Inactive GTS3 GTS1 GTS4 GTS5 GTS7 GTS9 C CAP CFP Inactive GTS3 GTS1 GTS4 GTS5 GTS6 GTS7 GTS8 GTS9 B GTS2

9. GTS Expiration For P2C GTS, the PAN coordinator can detect when a device has stopped using a GTS by checking the utilization efficiency of the GTS, then decide the expiration of the GTS. For P2P GTS, since PAN coordinator can not check whether the P2P GTS is idle. Each P2P GTS should be valid 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 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