<month year> doc.: IEEE 802.15-<doc#> Project: IEEE P802.15 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, 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 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 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. Slide 1 J Shen, X Tao, ZF Zhao 1 Page 1 <author>, <company>

Motivation Merge EGTS extension from proposal 15-08-0417-03-004e and 15-08-0775-01-004e to support high throughput, scalability, low time delay in the industrial applications. proposal 15-08-0417-03-004e : Multi-channel EGTS proposed GTS extension for P2P communication in intra-PAN Solution for intra-PAN P2P communication for high throughput proposal 15-08-0775-01-004e : 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 15-08-0417-03-004e 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

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

Super-frame Structure Super-frame structure in 15-08-0775-01-004e 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 15-08-0775-01-004e for low time delay

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

Allocation procedure in intra-PAN Proposal 15-08-0417-03-004e Proposal 15-08-0775-01-004e 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.

EGTS Allocation Example in a PAN intra-PAN P2P EGTS communication in 15-08-0417-03-004e 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

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.2 channel for A->B and B->C is the same (*) (* ) from proposal 15-08-0417-03-004e (#) from proposal 15-08-0775-01-004e 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

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 15-08-0775-01-004e )

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

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

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

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 802.15.4-2006 Each EGTS control command should be assigned a unique command frame Identifier that haven’t been used