1. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
20 August 2008
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: [Extending the MAC Superframe of Spec]
Date Submitted: [7 July 2008]
Source: [Ghulam Bhatti] Company [MERL]
[Zafir Sahinoglu] Company [MERL]
Address: [201 Broadway, Suite 8, Cambridge, MA 02139]
Voice:[ , ],
Re: [IEEE e group]
Abstract: We present a comprehensive mechanism for channel access in a multi-hop wireless networks. As opposed to IEEE e-2006 spec, the proposed system is scalable and efficient. Contrary to TDMA-based schemes, which are ideal for single hop-networks (such as a star topology), our scheme facilitates a simple and easy channel hopping mechanism without a need for micro-management of time- slots. Minimal support from higher layers is required in the proposed system.
Purpose: We’re presenting it as a candidate frame structure in task group 15.4e
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
Bhatti, Sahinoglu – MERL
<author>, <company>

2. Distributed Beacon Enabled Wireless Networks
<month year>
doc.: IEEE <doc#>
20 August 2008
Distributed Beacon Enabled Wireless Networks
Dr. Ghulam Bhatti and Dr. Zafer Sahinoglu
MERL
7 July 2008
Bhatti, Sahinoglu – MERL
<author>, <company>

3. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
20 August 2008
Contents
Motivation and Goals
Proposed MAC Frame Structure
Deployment Scenario 1: Star networks
Deployment Scenario 2: Mesh networks
System Overview
Enhanced Superframe Structure
Proposed System – Option 1
Proposed System – Option 2
How to Get a Beacon Slot?
Bhatti, Sahinoglu – MERL
<author>, <company>

4. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
20 August 2008
Motivation and Goals
Wireless sensor networks are getting increasing attention for deployment under industrial and commercial environments.
Scalability, reliability, and latency are challenging issues.
IEEE standard fails to satisfy stringent requirements in industrial deployments.
Beacon-enabled mode is not scalable.
Non-beacon mode fails to satisfy latency and reliability requirements.
Pure TDMA schemes are good only for single-hop systems.
We propose a MAC that:
Operates in a distributed fashion.
Offers automatic resource management and is scalable.
No help from higher layers is needed for channel access management.
Allows channel hopping for higher reliability and better channel efficiency.
Allows retransmission of failed frames in the same superframe.
Allocates additional time-slots on demand in the same superframe.
Bhatti, Sahinoglu – MERL
<author>, <company>

5. Proposed MAC Frame Structure
<month year>
doc.: IEEE <doc#>
20 August 2008
Proposed MAC Frame Structure
Superframe consists of fixed-size time slots and has several parts
CAP1: Allows contention-based CSMA/CA channel access
CFP: Consists of zero or more pre-allocated GTSs
GACK1: Group ACK frame to acknowledge for GTS frames received in CFP
ECFP: Extended CFP used for ReTx of failed GTS transmissions and additional slot allocations on demand
GACK2: Group ACK frame to acknowledge for data frames received in ECFP
CAP2: Just like CAP1 but subject to availability of time in superframe
Used for ReTx of failed GTS frames in ECFP
Can be used for transmitting any other data frames
All these parts are optional but the superframe must have at least CAP1 or CFP
Superframe has the same size for all FFD nodes in a PAN
Slot size is fixed (e.g. 5ms) – it is not related to superframe size
Number of time slots is a configuration parameter (not limited to 16 as in 15.4 spec)
GACK1
GACK2
CFP
CAP1
ECFP
CAP2
Bhatti, Sahinoglu – MERL
<author>, <company>

6. Scenario 1: Star Networks
<month year>
doc.: IEEE <doc#>
20 August 2008
Scenario 1: Star Networks
Network may consist of many clusters
Each cluster runs independently as a star network
A cluster consists a central node (cluster-head) and multiple non-beaconing (RFD) child nodes
Cluster-head owns a superframe to communicate with child nodes
Each cluster may be operating on a different channel
Cluster-heads are connected to a backbone such as .11x or a bus
Mobility can easily be supported
A node moves away from its cluster and gets into the area of another cluster
It first scans for beacon from local cluster head to get info on the superframe
It transmit its request for a GTS in CAP1
A GTS can be allocated for one or multiple superframes duration
Alternatively it starts transmitting its data frame in CAP1 – it needs no GTS
Bhatti, Sahinoglu – MERL
<author>, <company>

7. Clustered Wireless Network
<month year>
doc.: IEEE <doc#>
20 August 2008
Clustered Wireless Network
GACK1
GACK2
CFP
CAP1
ECFP
CAP2
BEACON
Bhatti, Sahinoglu – MERL
<author>, <company>

8. Scenario 2: Mesh Networks
<month year>
doc.: IEEE <doc#>
20 August 2008
Scenario 2: Mesh Networks
Network may consist of many beaconing (FFD) and non-beaconing (RFD) nodes
Every FFD node may have FFD and RFD child nodes
An FFD can communicate with its child nodes as well as its peer nodes
Every FFD node must be aware of superframes of its peer nodes
It must be able to receive their beacons
We need a mechanism for systematic beacon trasmissions (beacon scheduling?)
Every FFD tries to avoid interfering peers’ communications
Channel hopping can be used
Roaming can also be supported
Mobile node must be able to find the beacon of local FFD nodes
It can transmit in CAP1 or request a GTS in the following superframe
Bhatti, Sahinoglu – MERL
<author>, <company>

9. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
20 August 2008
System Overview
One common channel is used for control messages and all remaining channels for data communications.
All nodes periodically transmit their beacons on the control channel
Each node uses another channel for transmission of the data part of its superframe
A node selects a suitable data communication channel for its superframe before joining the network (can be changed later)
Optionally, channel hopping can be used for data transmisions
Each node can operate its own cluster of sleeping child (RFD) nodes
Additional fields such as GACK (Group ACK) and ECFP (Extended CFP) are used for ret-transmissions and allocations of extra slots.
Bhatti, Sahinoglu – MERL
<author>, <company>

10. Enahanced MAC Frame Structure
<month year>
doc.: IEEE <doc#>
20 August 2008
Enahanced MAC Frame Structure
Beacons: A fixed Announcement Channel is used for beacon transmissions
The channel is selected at the time of starting a PAN
Time between two consecutive beacons transmitted by the same device is called Announcement Cycle
The size of Announcement Cycle may vary in different parts of a network
The minimum and maximum size for this cycle is configurable
Beacon slots are allocated by a distributed algorithm
The first several slots are used for control messages and data broadcasts
CSMA/CA is used for channel access in this part M3 M4 B1 B2 BC M1 M2
A n n o u n c e m e n t C y c l e B3
Beacons from the same device B4
---
---
Bhatti, Sahinoglu – MERL
<author>, <company>

11. Proposed System – Option 1
<month year>
doc.: IEEE <doc#>
20 August 2008
Proposed System – Option 1
A n n o u n c e m e n t C y c l e M1 … M4 B1 B2 B3
--- Bk
I D L E M1 … M4 B1 B2 B3
--- Bk
---
GACK1
GACK2
CFP
CAP1
ECFP
CAP2
GACK1
GACK2
CFP
CAP1
ECFP
CAP2
GACK1
GACK2
CFP
CAP1
ECFP
CAP2
GACK1
GACK2
CFP
CAP1
ECFP
CAP2
---
Bhatti, Sahinoglu – MERL
<author>, <company>

12. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
20 August 2008
Notes on Option 1
All nodes must finish their communications before the start of control slots (M1-M4) of next Announcement Cycle.
Right after transmitting its beacon, a nodes switches over to its channel and starts transmitting its superframe.
Channel hopping (based on slots) can optionally be used for communications during the superframes.
This scheme allows the nodes to have superframes of different sizes.
A node using beacon slot B1, for example, can have longer superframe than the superframe of a node that uses B2 for its beacon transmission.
Variable sized superframes allow more busy nodes (e.g. nodes closer to sink) a longer time for channel access.
Bhatti, Sahinoglu – MERL
<author>, <company>

13. Proposed System – Option 2
<month year>
doc.: IEEE <doc#>
20 August 2008
Proposed System – Option 2
A n n o u n c e m e n t C y c l e M1 … M4 B1 B2 B3
--- Bk
I D L E M1 … M4 B1 B2 B3
--- Bk
---
CFP
CAP1
ECFP
CAP2
GACK1
GACK2
Channel C1 for OwnerNode(B1)
Channel C2 for OwnerNode(B2)
Channel Ck for OwnerNode(Bk)
---
Bhatti, Sahinoglu – MERL
<author>, <company>

14. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
20 August 2008
Notes on Scheme 2
All nodes listen during control slots (M1-M4).
All nodes listen for beacons from neighbor nodes.
All nodes start data communication part of their superframe simultaneously.
Each node uses a different channel.
Channel hopping (based on slots) can optionally be used for communications during the superframes.
Announcement channel can also be included in hopping sequence.
Peer nodes communicate using contention based channel access or using a guaranteed time slots (GTS).
Minimal or no intervention from higher layers is needed for channel and GTS allocations.
Bhatti, Sahinoglu – MERL
<author>, <company>

15. Proposed MAC Frame Structure – Information in Beacon
<month year>
doc.: IEEE <doc#>
20 August 2008
Proposed MAC Frame Structure – Information in Beacon
{F0}
{F0}
{F1}
{F2}
{F3}
{F4}
{F5}
{F9}
GTS
GTS
CFP
Extended
CFP
CAP2
Listen/Sleep
CAP
CFP
CAP
GTS
GTS
GTS
GTS
Frame
Control
Sequence
Number
Source ID
PAN ID
Beacon
Interval
Super frame
Interval
Channel Index for superframe
Available Virtual
Time Slots (AVTS)
GTS
Device List
GTS
Indices
GTS
Directions
Information in the GACK
GACK
{F3}
{F6}
GTS
GTS
CFP
CFP
CAP
Listen
CFP
CAP
GTS
GTS
GTS
GTS
Source ID
Group ACK Flags
CAP Channel Index
Extended CFP Channel Index
{F6}
{F3}
Bhatti, Sahinoglu – MERL
<author>, <company>

16. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
20 August 2008
How to Get a Beacon Slot?
Before joining a PAN, a node performs a scan Announcement Channel
Finds the size of Announcement Cycle
Determines empty/available beacon slots
Decides which channel(s) is/are good for its data communications
It gets Neighbor Group (NG) of each of its neighbor
It constructs its Extended Neighbor Group (ENG) from received NGs
It transmits it claim in a control slot of next Announcement Cycle
It claims the lowest empty slot available in its ENG
It declares the channel it will be using for its superframe
Bhatti, Sahinoglu – MERL
<author>, <company>

17. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
20 August 2008
Beacon Scheduling 6 4 8 1 5 2 5 2 x 7 3 9
BG[x] = {x, 5, 8, 9}
BG[x] = {x, 5}
BG[x] = {x}
BG[x] = {x, 5, 8}
BG[5] = {5, 8} 9
BG[8] = {1, 5, 8}
BG[9] = {1, 7, 9}
EBG[x] = {x, 1, 5, 7, 8, 9}
 x = 2
BG[x] = {2, 5, 8, 9}
Bhatti, Sahinoglu – MERL
<author>, <company>

18. Synchronization among nodes
<month year>
doc.: IEEE <doc#>
20 August 2008
Synchronization among nodes
Any given node listens only a part of Announcement Period (i.e. no activity detected in some beacon slots) B1 B2 B3 B4 …. BC M1 M2
BG[5] = {5, 8} B6 B7 B9
B10 B8 B5 B2 B3 B4 …. BC M1 M2 B6 B7 B9
B10 B8 B5
BG[8] = {1, 5, 8} B1 B2 B3 B4 …. BC M1 M2 B6 B5 B8
B10 B9 B7 B1
BG[9] = {1, 7, 9}
BG[2] = {2, 5, 8, 9} B1 B3 B4 …. BC M1 M2 B6 B7
B10 B9 B8 B2 B5
Nodes must have good clocks for reliable synchronization
Bhatti, Sahinoglu – MERL
<author>, <company>

19. doc.: IEEE 802.15-<doc#>
<month year>
doc.: IEEE <doc#>
20 August 2008
Thanks
Bhatti, Sahinoglu – MERL
<author>, <company>