1. July 2008
doc.: IEEE
July 2008
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Out-of-band control frame structure to enhance IEEE MAC]
Date Submitted: [July, 2008]
Source: [Wun-Cheol Jeong (1), Jong-Moon Chung (2), Chang-Sub Shin (1), Anseok Lee (1), Seong-Soon Joo (1)] Company [ETRI (1), Yonsei University (2)]
Address [161 Gajeong-Dong, Yuseong-Gu, Daejeon, Republic of Korea (1), Shinchon-Dong 134, Seodaemun-Gu, Seoul, Republic of Korea (2)]
E−Mail (1), (2), (1), (1),
Re: [ e group]
Abstract: [This document presents concepts providing reliable but fast channel access for dynamic heterogeneous traffic.]
Purpose: [Discussion in e Study Group]
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
W.-C. Jeong

2. Out-of-band control frame structure to enhance IEEE802.15.4-2006 MAC
July 2008
doc.: IEEE
July 2008
Out-of-band control frame structure to enhance IEEE MAC
Wun-Cheol Jeong, ETRI
Jong-Moon Chung, Yonsei University
Chang-Sub Shin, ETRI
Anseok Lee, ETRI
Seong-Soon Joo, ETRI
This work has been supported by the Ministry of Knowledge Economy (MKE) of the Republic of Korea under Grants 2008-F-052.
W.-C. Jeong

3. July 2008
doc.: IEEE
July 2008
Motivation
Current superframe structure is not flexible to accommodate dynamic traffic.
QoS provision may require more robust control of bandwidth requests instead of competing with data frame in CAP. Flexible but robust out-of-band control frame may provide efficient channel access.
Many services including industrial applications, require reliable and fast channel access for peer-to-peer communications.
W.-C. Jeong

4. Contents GTS request management Proposed superframe structure
July 2008
Contents
GTS request management
Proposed superframe structure
Improvement in flexibility to support heterogeneous traffic
Enhancements for stabilized reservation
More reliable data communication support after reservation
Proposed superframe structure: Control part & Data part
Summary
W.-C. Jeong

5. GTS request management
July 2008
GTS request management
In systems, GTS requests are sent in the CAP
This involves problems for reliability & latency control.
For delay sensitive services, e.g. real-time monitoring, these frames require guaranteed access in the superframe
It is especially true when considering non-transparent relaying
Guaranteed resources for GTS request frames would allow:
Enhancement of the MAC behavior in overloaded network
Avoid excessive peak of delay due to request/grant mechanism
W.-C. Jeong

6. Proposed Superframe Structure
July 2008
Proposed Superframe Structure
Superframe consists of a Control-Part and a Data-Part
Superframe Control-Part
During the CAP1 reservation period, a node which has data to send transmits a Channel Request Message (CRM) during CAP.
Superframe Data-Part
Based on Superframe schedule Assignment (SSA) the Super Frame Data Part assigns one or multiple time-slots to each node.
After the Superframe Data-Part the Superframe ends and a new Superframe begins with a new Control-Part.
CAP1
SSA1
CAP2
SSA2
TS1
TS2 …
TS#
Control-Part
Data-Part
Superframe
W.-C. Jeong

7. Superframe Control-Part
July 2008
Superframe Control-Part
During the CAP1 reservation period, a node which has data to send transmits a Channel Request Message (CRM) during CAP1.
CRM includes:
Source Address (SA)
Destination Address (DA)
Traffic Length Indicator (TLI)
Optional information (e.g., transmission data size, transmission period, traffic priority, sensor type, alarm type, etc.)
Based on the channel request messages in CAP1, the Superframe Schedule Assignment 1 (SSA1) is announced.
SSA1 includes the SA, DA, and Time-Slot Assignments of the Superframe.
Based on SSA1, some nodes may realize that their CRM sent during CAP1 was not accepted and during CAP2 (using random access time selection) will send another CRM.
Under heavy traffic conditions, this will allow nodes that have failed to obtain transmission access in the Superframe to have a second chance to obtain transmission access.
Under low traffic conditions, the second CAP can be skipped.
W.-C. Jeong

8. Superframe Control-Part (continued)
July 2008
Superframe Control-Part (continued)
Based on the channel request messages of CAP1 and CAP2, the Superframe schedule Assignment 2 (SSA2) is announced.
Traffic Load Dependent Configurations
During the network Initialization period a longer control-part could be beneficial.
Reservations made to slot assignments can be carried over to multiple Superframes.
Some nodes can request for channel access for very long durations (using the CRM).
Since this may make the Superframe too long (and also less flexible to short term request users), the SSA can indicate that for some nodes their reservation of time slots will automatically extend into the following Superframe.
The nodes that have been granted this extension assignment should not send a CRM in the following CAP.
W.-C. Jeong

9. July 2008
Superframe Data-Part
Based on SSA2 (or SSA1 for low trafffic connditions) the Super Frame Data Part assigns one or multiple time-slots to each node to be used during a single frame Supperframe duration.
For each node, the number of multiple time-slots during a single frame Supperframe duration will be based on the TLI and optional information (e.g., transmission data size, transmission period, traffic priority, sensor typre, alarm type, etc.) submitted by the CRM.
After the Superframe Data-Part the Superframe ends and a new Superframe begins with a new Control-Part.
W.-C. Jeong

10. Proposed Superframe Structure
July 2008
Proposed Superframe Structure
Superframe example during initialization: Extended Reservation & Scheduling Control-Part
Superframe example during application run time with high traffic
Superframe example during application run time with low traffic
CAP1
SSA1
CAP2
SSA2
CAP3
SSA3 …
TS#
Control-Part
Data-Part
Superframe
CAP1
SSA1
CAP2
SSA2
TS1
TS2 …
TS#
Control-Part
Data-Part
Superframe
CAP1
SSA1
CAP2
SSA2
TS1
TS2 …
TS#
Control-Part
Data-Part
Superframe
W.-C. Jeong

11. Summary Issues Proposed solutions July 2008
doc.: IEEE
July 2008
Summary
Issues
Proposed solutions
Lack of flexibility and efficiency
Dynamic Superframe structure
Introduction of CAP reservation periods and scheduling announcements for the control-part of the Superframe
Latency control
Reserved time-slots can be assigned for long periods, extending over multiple Superframes without further reservations, which provides reliability and delay-sensitive traffic support when needed.
Scalability (controllable and predictable regardless of network size)
Required improvements for power saving
In the control-part, transmission requests are made and checked by the users before transmission, therefore the network may grow, but the nodes will definitely know when to transmit and receive  scalable energy consumption profile
W.-C. Jeong

12. July 2008
Thanks ;)
W.-C. Jeong