1. <month year>
doc.: IEEE <doc#>
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Supporting Joint GTS Extension]
Date Submitted: [20 Dec, 2008]
Source: [Jie Shen, Hailin Wang, Heqing Huang, Daoyuan Yao, Tao Xing, Z.F Zhao, Haitao Liu, Betty Zhou] Company [Shanghai Institute of Micro-system and Information Technology, Vinno Technologies Inc. Huawei]
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 delay 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
Slide 1
J Shen, X Tao, ZF Zhao 1
Page 1
<author>, <company>

2. Motivation
Merge EGTS extension from proposal e and e to support high throughput, scalability, low time delay in the industrial applications.
proposal e :
Multi-channel EGTS proposed
GTS extension for P2P communication in intra-PAN
Solution for intra-PAN P2P communication for high throughput
proposal e :
EGTS mesh extension for peer-to-peer communication
ABT and three-way-handshake for distributed EGTS allocation
Merge the two proposal as a joint EGTS extension proposal
1/ Rewrite the proposal e using distributed EGTS extension in intra-PAN with compare of two proposals.
Definition
Super-frame structure
2/ Redefine the EGTS Allocation procedure
3/ Express the EGTS Deallocation and Expiration
Beacon interval counter Table for EGTS Expiration

3. EGTS definition Proposal 15-08-0775-01-004e :
Beacon
CAP
CFP
Inactive
CHi
CHj
CHm
EGTS slot ….
Channels
GTS Slots
CH0
CH1
CH2
Both proposal share the same EGTS idea
EGTS is the GTS in CFP with multi-channel extension for high throughput
EGTS is expressed as time slot and channel tuple, define EGTS slot = tuple( time slot, channel)
Each link can have one or more EGTS slots
…….

4. Super-frame Structure
Super-frame structure in e is adopted
A simple PAN with one coordinator. Coordinator and FFD can announce their own beacons while RFD can’t.
CAP use one common channel
CFP include EGTS extension
A Beacon interval includes several super-frame as described in e for low time delay

5. Beacon interval counter Table for EGTS Expiration
EGTS destination node maintains Beacon interval counter Table for EGTS Expiration
The table record how many beacon interval has passed since each EGTS built.
When devices in a PAN set up EGTS, destination node initial a new counter for that EGTS
Destination node increases each counter every a beacon interval
When devices de-allocate EGTS, the counter for that EGTS is released
ABT Table

6. Allocation procedure in intra-PAN
Proposal e
Proposal e
Three-way-handshake EGTS Allocation:
Source Requesting destination
Three command frames are transmitted during CAP period
EGTS request
EGTS reply
EGTS notify
Coordinator assign EGTS in a PAN. Centralized EGTS assignment
Three-way-handshake allocation procedure is adopted to assign EGTS in a PAN.

7. EGTS Allocation Example in a PAN
intra-PAN P2P EGTS communication in e redefined as follow using three-way-handshake
As a example, 5 nodes in a PAN, node 3 set up EGTS connection to node 4, the procedure is as follow
Node 3 send unicast EGTS request with its ABT sub-block and Required number of slots
Node 4 Select appropriate slots and announce the assigned slots, neighbor nodes 3,1, 5 will update their ABT
Node 3 announce the assigned EGTS slots to neighbors, node 1, 2 ,4 update their ABT
Destination node 4 initial a new counter for the newly assigned EGTS
Node 3 and node 4 begin to communicate in the newly assigned EGTS slots

8. Allocation Rule
First, choose a time slot, which has at least one vacant channel.
Don’t assign two channels at the same time slot to a device. See Fig.1 (*)
Considering multi-hop delay (#)
Considering time schedule: try to assign time slots next to time slots haven been assigned to themselves. See Fig.2 time slots for A->B and B->C are successive (*)
Then, choose a channel that is available in that time slot
Considering adjacent channel interference avoidance (#)
Considering channel switch: try to avoid channel switch. See Fig channel for A->B and B->C is the same (*)
(* ) from proposal e
(#) from proposal e
CH 1
A->B
B->C
CH 2
Fig.2 efficient GTS allocation
Slots
A->B
B->C
CH n
CH m
Slots
Fig.1 conflicting GTS allocation

9. EGTS Duplicated Allocation Notification
Duplicated allocation can happen
Some nodes may miss some of EGTS reply or notify. (Broadcast is not reliable)
New joining node requests a slot not knowing the slot allocation state in the area.
Send EGTS collision notification during CAP period
The existing owner of the slot detects duplicated allocation by hearing neighbor’s EGTS reply or notify.
EGTS duplicated allocation notification (Unicast) from the existing owner.
Duplicated slot id (time slot, channel).
ABT sub-block (28 bytes) around the colliding time slot.
Forces the source and the destination nodes to retry three-way-handshake EGTS allocation.
( EGTS Duplicated Allocation Notification is from proposal e )

10. EGTS Deallocation EGTS Deallocation is necessary
when EGTS slots isn’t needed any more
When nodes leave a PAN
EGTS Deallocation procedure
Source de-allocating destination
Three command frames are transmitted during CAP period
EGTS Deallocation request
Unicast from a source to a destination .
Providing EGTS slots to deallocate (28 byte ABT sub-block).
EGTS Deallocation reply
Broadcast from the destination.
Deallocate slots in the sub-block and announce the deallocated EGTS slots to all neighbors (28 byte ABT sub-block).
EGTS Deallocation notify
Broadcast from the source
Announce the de-allocated EGTS slots to all neighbors (28 bytes ABT sub-block)
All neighbors that hear EGTS Deallocation Reply or Notify clear the de-allocated EGTS slots from ABT.
Destination deletes Beacon Interval counter for the EGTS

11. EGTS Deallocation Example
As an example, 5 nodes in a PAN, node 3 wants to de-allocate assigned EGTS with node 4, the procedure is :
Node 3 sends unicast EGTS Deallocation request with ABT sub-block which contain the EGTS Slots to deallocate
Node 4 deallocates EGTS slots and announce the deallocated slots, node 1,3,5,update their ABT
Node 3 announces the deallocated slots to neighbors, node 1, 2,4 updates their ABT
Destination node 4 deletes Beacon Interval counter for the EGTS
Finish EGTS de-allocation

12. EGTS Expiration EGTS Expiration is necessary
When the node fail and haven’t de-allocated its assigned EGTS slots
Two options of EGTS Expiration procedure
Option 1: set Maximum limitation of Beacon Intervals for EGTS expiration. When value in Beacon Interval counter Table is bigger than the limitation, Destination device announce EGTS Expiration to its all neighbor devices with (time slot ,channel) for the EGTS. All its neighbor devices update their ABT
Option 2: Coordinator announces ABT invalidation to devices in the PAN in CAP every N beacon intervals (N is very large). Nodes within the PAN clear their ABT and have to set up new ABT

13. EGTS control command
EGTS control commands should be added to MAC commands, including EGTS allocation, Deallocation, duplicated notification and Expiration .
MAC command frame from IEEE std
Each EGTS control command should be assigned a unique command frame Identifier that haven’t been used