Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)

1. Project: IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs) Submission Title: [EGTS Joint Proposal for IEEE 802.15.4e] Date Submitted: [January 19, 2009] Source: [Myung Lee, Seong-Soon Joo, Tae Rim Park, Betty Zhao, Ghulum Bhatti, Ning Gu, Jie Shen, Wei Hong] Address [] Voice:[+1-212-650-7260], FAX: [], E-Mail:[lee@ccny.cuny.edu] Re: [IEEE P802.15.4e] Abstract: [This document describes a joint proposal for IEEE 802.15.4e by EGTS members. While maintaining the backward compatibility to legacy IEEE 802.15.4b, the joint proposal meets all the MAC behaviors ratified by 802.15.4e TG. Currently, the EGTS Alliance comprises members from CUNY, ETRI, Samsung, Huawei, MERL, Vinno, SIMIT, and Arch Rock.] Purpose: [Discussion in 802.15.4e Task Group] 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.

2. EGTS Joint Proposal CUNY, ETRI, MERL, Huawei, Samsung, Arch Rock, SIMIT, and Vinno

3. Contributors • CUNY: Myung Lee, Gahng-Seop Ahn, Yang G. Kim, June S. Yoon, Rui Zhang, • Samsung: Tae Rim Park • ETRI : Seong-Soon Joo, Chang-Sub Shin, Anseok Lee, Wun-Cheol Jeong, Jong-Suk Chae • Mitsubishi (MERL): Ghulam Bhatti, Zafer Sahinoglu • Huawei: Betty Zhao, Liang Li , Yongjun Liu, Pei Liu, Yong Xu, Zhihao Xing • Arch Rock: Wei Hong, Jonathan Hui • SIMIT: Jie Shen, Tao Xing, Zhon Zhao Haitao Liu, • Vinno: Ning Gu,, Zhang Liang, Z.F Zhao

4. Handling Required MAC Behaviors (1) • ACK • Secure and Robust ACK, Group Ack • Channel diversity (hopping, agility) • Adaptive Slot and Channel Allocation with Adjacent Channel Interference, Optional distributed channel hopping • Superframe (GTS, TDMA) • Flexible and Backward-compatible Enhanced GTS, Embedded CFP • Low Power (Low duty Cycle) • Sampled Listening, CAP reduction, Optional inactive period • Overhead reduction (Short MAC address) • Distributed time slot and channel allocation, Distributed beacon scheduling, Embedded CAP, Reduced MAC header • Mesh support (Path diversity) • Tree and Mesh Support by EGTS structure

5. Handling Required MAC Behaviors (2) • Time synchronization (Relative, Absolute) • Time synchronization with deferred beacon • Resource Scheduling • Distributed EGTS allocation, Multiple QoS support, Sampled listening • Portability (Fast Assoc/disassoc, Associationless) • CAP, Localized channel allocation & Association • Beacon scheduling • Distributed beacon scheduling with beacon collision detection • Scalability • Distributed Approaches for resource scheduling, beacon scheduling • EGTS Joint Proposal also provides: • Reliability: EGTS Information Request, Embedded CAP, Deferred beacon • Backward Compatibility to 802.15.4 -2006

6. Table of contents • EGTS-based superframe structure • Distributed EGTS scheduling • Embedded CAP & CFP • Distributed Beacon scheduling • EGTS information request • Group Acknowledgement • Sampled listening • QoS Provision • Time Synchronization

7. EGTS-based Superframe Structure

8. EGTS-based superframe structure Channels CH0 CH1 CH2 … • Common channel : Beacon and CAP use a fixed single channel. • Multi-channel for Enhanced GTS • EGTS slot = tuple (time slot, channel) • More than one slot can be allocated for each link (Tx & Rx pair). • Multi-hop extension for EGTS • The usage of EGTS is extended to the nodes beyond one hop distance from PAN coordinator. • Beacon scheduling is required to provide multi-hop connection. • Multi-superframe extension for EGTS • A multi-superframe consists of N superframes. • The allocation pattern is repeated every multi-superframe. • We define MO (multi-superframe order) such that N = 2(MO – SO), where MO ≥ SO. • Multi-superframe Duration MD = aBaseSuperframeDuration*2MO symbols BO = 6, SO = 3, MO = 5 EGTS Slots

9. CAP Period Reduction in MSF (optional) • This is an optional behavior that happens only when “CAP reduction flag” is on. • Motivation: Lower duty cycle, more GTS slots. • Each multi-superframe (MSF) has only one CAP period. • Beacon indicates the next CAP period time. • Every node synchronizes the CAP period. • Number of available EGTS slots in a multi-superframe • Without CAP reduction: S1 =16 channels * (7 *2(MO – SO)) time slots • With CAP reduction: S2 =16 channels * (7 + (2(MO – SO)-1) * 15) time slots BO = 6, SO = 3, MO = 5

10. EGTS Scheduling

11. Slots CH 1 A->B B->C CH 2 Fig.2 efficient GTS allocation Slots CH n A->B B->C CH m Fig.1 conflicting GTS allocation EGTS Allocation Rule • First, choose a time slot (or slots), which has at least one vacant channel. • More than one slot can be allocated for each link (Tx & Rx pair). • Don’t assign two channels at the same time slot to a device. See Fig.1 • Considering multi-hop delay (as discussed in the 15-08-0775-01-004e). • 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

12. EGTS Allocation Bitmap Table (ABT) • Each node maintains a Neighborhood Allocation Bitmap Table (ABT) • Example (MO = SO = 3) • ABT size = 14 bytes • 0: Vacant, 1: Allocated (self or neighbors) • Row: time slot, Column: channel • 00000000 00000000 • 01000100 01000100 • 00000000 00000000 • 00001000 00000100 • 00000000 00000000 • 00000000 01000000 • 00000000 00000000

13. ABT sub-block … … 00000000 00000000 00001000 00000100 00000000 00000000 00000000 01000000 00001000 00000000 00000000 00000000 01000100 00000100 00000000 00000000 00001000 00000100 00000000 00000000 00000000 01000000 00000000 00000000 10000000 01000000 01000100 01000100 00000000 00000000 00001000 00000100 00000000 00000000 00000000 01000000 10000000 00000000 00000000 00000000 00000000 00000000 10000000 00000000 00000000 00000000 … • Entire bitmap may be too big to be transmitted by Beacon or EGTS command frames • Example (MO = 7, SO = 3) • ABT size = 224 bytes • 0: Vacant, 1: Allocated. • Row: time slot, Column: channel • Solution: • Send a ABT sub-block (with an index indicating beginning & ending of a block) • Example: 28 bytes sub-block.

14. Three-way-handshake EGTS Allocation • Source Requesting destination • Three command frames are transmitted during CAP period • EGTS request • Unicast from a source to a destination . • Providing locally available slots (28 byte ABT sub-block). • Required number of slots (depending on data rate). • EGTS reply • Broadcast from the destination. • Select appropriate slots in the sub-block and announce the assigned EGTS slots to all neighbors (28 byte ABT sub-block). • EGTS notify • Broadcast from the source • Announce the assigned EGTS slots to all neighbors (28 bytes ABT sub-block) • Schedule Update • Those nodes who are reachable by EGTS Rep and EGTS Notify. • Beacons do not carry EGTS allocation information • Entire EGTS bitmap may be too big. • Periodically sending EGTS bitmap is energy consuming.

15. EGTS Allocation Example (from node 3) Slot = tuple (time slot, channel) MO = SO Node 1 assigns slot (10,15) for Node 3 • 2. EGTS reply, broadcast • Payload : • Dst addr (3) • new allocated ABT sub-block • {0000000000000000 • 0000100000000000 • … • 0000000000000000} Every node that hears the broadcasts updates its allocation bitmap table (ABT) • EGTS request, unicast • Payload : • Number of slots • ABT sub-block • {0000000000100000 • 0000000000000000 • … • 0000000000000000} • 3. EGTS notify, broadcast • Payload : • Dst addr (1) • new allocated ABT sub-block • {0000000000000000 • 0000100000000000 • … • 0000000000000000} Assuming slot (9,21) is already assigned from node 4 for transmitting frames to node 3

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

17. EGTS Deallocation & Expiration • EGTS Expiration • If an allocated EGTS is not used for longer than N beacon intervals, the allocation expires. • Each destination device maintains a counter table for EGTS Expiration. • EGTS Deallocation • Deallocation also uses three-way-handshake (request, reply, notify). • Deallocation is performed • when a source device finds out EGTS expiration. • when a destination device does not need to use EGTS any longer. ABT Table

18. Optional Channel Hopping • In addition to the mandatory Channel Adaptation, Channel Hopping is optionally provided. • Distributed channel offset management • Nodes share configurable channel hopping sequence with different channel offset values to obtain frequency diversity. • Each node has its own offset values. • Offset information (bitmap) in beacon.

19. Embedded CAP & CFP

20. Embedded CAP • In 15.4b, a CFP slot for one node’s transmission • Embedded CAP • To allow remaining time in GTS for other nodes to (re)transmit frames via CSMA/CA

21. Residual Time in each GTS slot Successful Longest frame transmission = 360 symbols Still 600 symbols = 9.6 ms is left

22. Operation of Embedded CAP • No change for each node’s GTS slot. • During other GTSs • Nodes wait for ACK • CSMA/CA to compete the channel for (re)transmission • Some special cases • Multiple packets: ACK should notify the existence of subsequent frames until the final ACK • No packet: the assigned GTS device send a short probe frame and the ACK(broadcast type) will be sent back by PC to release the channel for other nodes

23. An Example • Proposed Embedded CAP: the node 1 can access node 2’s CFP using CSMA/CA .Latency = 15.36ms

24. Embedded CFP • Problem of 802.15.4b • The minimum EGTS slot size = 0.96 msec (when SO=0). • Some application only need to transmit very small frames (e.g. 1 byte payload). • Motivation of Embedded CFP • To improve latency, scalability, and utilization. • To maintain the backward compatibility to 802.15.4b. • Operations of Embedded CFP • Reduced MAC header (to match the small payload). • The first packet in a EGTS slot is sent by main owner of the slot. • The remaining time in the EGTS slot is split into sub slots. • The owner of each sub slot sends a packet in a contention free fashion.

25. Beacon scheduling

26. Beacon Scheduling Definition • The Beacon Scheduling definition is as: • Beacon interval is defined by BO • SD bitmap length is defined by BO and SO • The beacon slot of first superframe in MSF is used by PAN Coordinator • There is no particular inactive period in EGTS Alliance’s superframe structure, but unused slots and vacant SD could be treated as inactive period. • Beacon allocation information of one-hop neighbor nodes is expressed in SD bitmap field of beacon frame • Bit with value “1” means this SD bank is allocated while bit with value “0” is vacant • for example: BO=8, MO = 7, SO = 5 SD bitmap length = 2(BO - SO) = 8 bits Bitmap value : 10110101

27. Beacon Scheduling Approach for Tree Topology • Beacon scheduling method • Each node maintains a SD bitmap to represent usage of its multiple SD. For instance, SD bitmap 01010000 means SD bank 2 and SD bank 4 are occupied and other SD bank are vacant. • Childdevicealready knows parent node’s vacant SD bitmap (the vacant SD bitmap is contained in beacon frame and updated once any SD is occupied. • Once been designated by parent node to start beacon scheduling, device obtains neighbor node’s vacant SD information by scanning during those vacant SD. • Do AND operation between those vacant SD bitmap and obtains a “mutual vacant SD bitmap”. • Pick the first available SD from mutual vacant SDbitmapand notifies this scheduling information to its parent nodes during CAP or EGTS. The first slot of this SD shall be chosen for beacon transmitting. • Construct own vacant SD bitmap based on mutual vacant SD bitmap and insert this bitmap information into own beacon frame.

28. Beacon SchedulingApproach for mesh topology • New joining node • Listen neighbor’s beacons during maximum BI • Select empty SD in two hop boundary from neighbor’s bitmap info. • Notify SD information(allocation-notify command frame) to its neighbor nodes during CAP • Wait until CAP • If receive SD duplication information(duplication-notify command) from neighbor nodes • then, have to try to find new vacant SD (go step 1) • Else • will try to transmit beacon frame in selecting SD • Neighbor nodes update bitmap info from new joining node’s beacon frame • Node which can detect possible beacon collision • If listen two successive SD information frame (allocation-notify command) in same CAP period • Then, transmit SD duplication information to the last notifying node.

29. Beacon collision detection method • In Tree Networks, every node starts its beacon scheduling under its parent node’s supervision, no beacon collision would happen. • If there are beacon collisions several times in Mesh Networks, Node A notifies the collision to neighbor nodes with CAP or Beacon. • If nodes(D, E) listen collision information, try to select other vacant SD. • Nodes (D, E) retry for a new allocation.

30. EGTS Information Request

31. EGTS Retrieve Coordinator EGTS information request EGTS information reply EGTS Node • Upon successful EGTS allocation, node may lose synchronization with its coordinator sometimes. • When that occurs, EGTS information request and reply are transmitted during CAP period to retrieve the allocated EGTS. • EGTS information request • Unicast from a source to a destination . • Request for synchronization and EGTS information. • EGTS information reply • Unicast from the destination. • Including timestamp and EGTS information.

32. Beacon-enabled PAN: Coordinator Device Communicate in beacon mode Promiscuous PAN: Connection Device Nonbeacon-enabled PAN: Coordinator Device Communicate in nonbeacon mode EGTS Extension for Non-Beacon Networks • EGTS exists in the superframe structure of beacon-enabled network. • Some special nodes ( ‘connection device’) which uses EGTS can also send and receive data in nonbeacon-enabled network at the same time. • So, through the connection devices, any two nodes can interact without changing their communication mode (beacon/nonbeacon), and the network can be extended to large regardless of beacon modes.

33. Group Acknowledgement

34. Advantages of GACK • Reduces communication overhead • Saves BW: No need to send ACK for each data frame received by a coordinator • Saves Time: No overhead associated with constantly switching between Rx and Tx • Allows automatic and distributed resource management • Nodes can request a GTS allocation when and where needed • Offers a better scalability to network traffic • Offers a mechanism for retransmission of failed GTS frames (in same superframe) • GACK frame indicates failed GTS frames and allocates extra time slots for retransmission of these frames in Extended CFP of current superframe • A failed GTS frame need not to wait until a GTS in the next superframe • Allows adaptability to traffic load • A node can piggyback its request (in regular GTS frame) for allocation of additional timeslots to deal with local bursty traffic (e.g. generated when alarms blown off) • GACK indicates if additional time slots were allocated to requesting node • Additional time slots will be allocated for transmission in ECFP

35. 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: Same as 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 • Entire superframe may consists of GTSs, only CSMA period, or a combination of both • Superframe has the same size for all FFD nodes in a PAN • Slot size is fixed (e.g. 5ms) – it does not depend on the size of superframe • The size and number of time slots in the superframe is a configuration parameter (not limited to 16 as in IEEE 802.15.4 spec)

36. Superframe Structure 1 GACK2 GACK2 GACK1 GACK1 CAP1 CFP ECFP BEACON GACK2 GACK1 GACK in EGTS-based superframe structure

37. Sampled Listening

38. Basic Sampled Listening • Sampled Listening • DARPA Packet Radio 1987 • Aloha-PS, B-MAC, X-MAC, etc. wakeup signal data frame sender t channel sample reception receiver t

39. Coordinated Sampled Listening (CSL) Over 802.15.4 • Wakeup signal • Back-to-back 15.4 packets (chirp packets) • Introduce a new frame type in 15.4e • Can be a data frame for backward compatibility • CSMA only at the beginning of chirp sequence • Channel sampling • Staged-wakeup of receiver based on RSSI threshold and SFD detection • Receive chirp packet • Abort if DST is for someone else, otherwise • Turn off receiver until rendezvous time (RZTime) then receive data frame optional 2 4 1 1 2 1 2 2 2 1 Preamble SFD Len FCF DSN DSTPAN DST RZTime Chan CRC

40. Secure and Robust Acknowledgement • Problems in current 15.4 ACK frame • Lack of addressing information  false positives • Lack of security  vulnerability to link-layer attacks • Lack of payload  difficulty to piggyback neighbor info • New ACK frame • Same as data frame except frame type is ACK • Addressing + DSN to eliminate ambiguity • Same security modes as data frame • Payload for piggybacking schedule information • Relax ACK timing requirement 4 1 1 2 1 variable variable variable variable 2 Preamble SFD Len FCF DSN Addressing Security Header Payload MIC CRC

41. Local Scheduling • Include channel sampling phase and period in ACK payload • Sender wait to transmit right before receiver’s next channel sampling time scheduled unscheduled sender t receiver t

42. Streaming over Sampled Listening • Set Frame Pending bit in 15.4 header when communicating multiple frames back-to-back to the same destinations • Receiver keeps listening when Frame Pending bit is set • Sender only chirps at the beginning of stream • Better throughput and efficiency packet stream sender t receiver t

43. Fitting into 802.15.4 2006 • Non-beacon mode (current dominating use of 15.4) • Low-power option to non-beacon mode • Beacon mode • Low-power network join CAP CFP Inactive Radio On Scheduled On/Off Radio Off CAP CFP CAP CFP Low-power Scheduled On/Off Low-power Scheduled On/Off

44. QoS Provisioning

45. Grades of Service Quality inWPAN • Service quality requirements • general application data • one single frame expected to be delivered to the sink with the probability 0.6 no later than 5sec • frame loss tolerable, delay tolerable  best effort • delay sensitive application data • one single frame must be delivered to the sink within 20ms • frame loss tolerable, low delay required  delay sensitive • bulk application data • train of frames must be delivered to the sink within 1sec • low frame loss required, delay tolerable  loss sensitive • periodic application data • variance of inter-arrival time between consecutive frames at the sink needed to be within 100ms • low frame loss required, low delay variance required  premium • Control signaling quality requirements • general command frames • loss sensitive command : association request commands • urgent command frames • real time command : network realignment, emergency notice

46. Provisioning of Grades of Service Quality • Provide access channels for supporting grades of service quality • prioritized CAP • contention based access channel • multiple grades of access : low, high • prioritized EGTS • periodic access channel, reservation process required • multiple grades of periodically guaranteed access : low, high • Operation rules • prioritized CAP • priority control on processing MCPS-DATA.request, MCPS-DATA.indication primitives • priority control on backoff period adjustment • prioritized EGTS • priority control on processing MCPS-DATA.request, MCPS-DATA.indication primitives • priority control on processing MLME-GTS.request primitive • If ‘MLME-GTS.request’ command of higher priority is received and the EGTS slots have been used out, coordinator may reduce or cease the slots of EGTS being used by the nodes sent command of lower priority earlier.

47. MAC Primitives and Functions • Four classified access channels between device & coordinator • MAC PIB • add macPrioritizedChannelAccess • (b0) 0 : CSMA, 1 : EGTS • (b1) 0 : Low Priority, 1 : High Priority • MAC primitives • MLME-START.request • add PrioritizedChannelAccess • (b0) 0 : CSMA, 1 : EGTS • (b1) 0 : Low Priority, 1 : High Priority • MLME-GTS.request • add PrioritizedChannelAccess • 2 bit, (b0b1) 10: low priority EGTS, 11 : high priority EGTS • MCPS-DATA.request • extend TxOptions • (b0) 0 : CSMA, 1 : EGTS • (b1) 0 : Low Priority, 1 : High Priority

48. Usage of classified access channels • Command frames • urgent command • use high priority CAP (b0b1=01) • general command • use low priority CAP (b0b1=00 ) • (or reserve an EGTS slot for control signaling) • Application frames • general application data • use low priority CAP (b0b1=00) • (or reserve a low priority EGTS slot for services) • delay sensitive application data • Use high priority CAP (b0b1=01) • bulk application data (b0b1=10 ) • reserve a low priority EGTS slot for services • periodic application data (low delay high reliability) • reserve a high priority EGTS slot for services ((b0b1=11)

49. Time synchronization using deferred beacon

50. Motivation & Objectives • Motivation : Beacon collision problem in IEEE802.15.4 MAC • Beacon transmitted without back-off algorithm • Possible interfered in mesh topology • Unreliable wireless environment • Objectives : Support reliable beacon transmission • Prevent beacon collision in mesh environment • deferred beacon information • Compensate synchronization time • average the consecutive time values