Extending MAC Superframe in IEEE 802.15.4 Spec

1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title:[Extending the MAC Superframe of 802.15.4 Spec] Date Submitted: [7 July 2008] Source: [Ghulam Bhatti] Company [MERL] [Zafir Sahinoglu] Company [MERL] Address: [201 Broadway, Suite 8, Cambridge, MA 02139] Voice:[617-621-7513, 617-621-7588], E-Mail: [gbhatti@merl.com, zafer@merl.com] Re: [IEEE 802.15.4e group] Abstract: We present a comprehensive mechanism for channel access in a multi-hop wireless networks. As opposed to IEEE802.15.4e-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 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. Bhatti, Sahinoglu – MERL

2. Distributed Beacon Enabled Wireless Networks Dr. Ghulam Bhatti and Dr. Zafer Sahinoglu MERL 7 July 2008 Bhatti, Sahinoglu – MERL

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

4. Motivation and Goals • Wireless sensor networks are getting increasing attention for deployment under industrial and commercial environments. • Scalability, reliability, and latency are challenging issues. • IEEE802.15.4-2006 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

5. GACK1 GACK2 ECFP CAP1 CAP2 CFP 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) Bhatti, Sahinoglu – MERL

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

7. GACK1 GACK2 BEACON ECFP CAP1 CAP2 CFP Clustered Wireless Network Bhatti, Sahinoglu – MERL

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

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

10. A n n o u n c e m e n t C y c l e M1 M2 M3 M4 B1 B2 B3 B4 BC M1 M2 M3 M4 B1 B2 B3 Beacons from the same device 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 --- --- Bhatti, Sahinoglu – MERL

11. GACK1 GACK1 GACK1 GACK1 GACK2 GACK2 GACK2 GACK2 ECFP ECFP ECFP ECFP CAP1 CAP1 CAP1 CAP1 CAP2 CAP2 CAP2 CAP2 CFP CFP CFP CFP 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 --- --- Bhatti, Sahinoglu – MERL

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

13. GACK1 GACK2 ECFP CAP1 CAP2 CFP Channel C1 for OwnerNode(B1) CAP1 CAP2 CFP ECFP Channel C2 for OwnerNode(B2) ECFP CAP1 CAP2 CFP Channel Ck for OwnerNode(Bk) 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 M1 … M4 B1 B2 B3 --- Bk --- I D L E --- Bhatti, Sahinoglu – MERL

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

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

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

17. 4 x 8 7 9 5 5 6 9 1 2 3 2 Beacon Scheduling BG[x] = {x, 5, 8, 9} BG[x] = {x} BG[x] = {x, 5} BG[x] = {x, 5, 8} BG[5] = {5, 8} 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

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

19. Thanks Bhatti, Sahinoglu – MERL