1 / 13

J Shen, X Tao, ZF Zhao

Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [ Supporting Joint GTS Extension ] Date Submitted: [ 20 Dec, 2008 ]

bunny
Download Presentation

J Shen, X Tao, ZF Zhao

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. Beacon CFP CAP Inactive CHi CHj CHm CHm GTS Slots Channels CH0 CH1 CH2 EGTS definition Proposal 15-08-0775-01-004e : Proposal 15-08-0417-03-004e : • 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 EGTS slot …. …….

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

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

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

  8. Slots Slots A->B B->C A->B CH n CH 1 B->C CH m CH 2 Fig.2 efficient GTS allocation Fig.1 conflicting GTS allocation 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

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

  10. EGTS Deallocation is necessary • when EGTS slots isn’t needed any more • When nodes leave a PAN • EGTS Deallocation procedure • Sourcede-allocatingdestination • 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

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

More Related