1. 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, , China]
Voice:[ ], FAX: [ ],
Re: [IEEE e 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 P SG4e Call for Application on 14 November, 2007]
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

2. <11 January, 2008r>
doc.: IEEE <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>

3. <11 January, 2008r>
doc.: IEEE <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>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

19. Conclusion Support Peer to Peer communication within GTS.
Support channel selection in order to improve throughput and reduce the time delay.
Compatible with STD.

20. Thanks