802.15.4k MAC additions working draft - Web view5.1.7 GTS allocation and management9. 5.1.8 Ranging9. 5.1.9 LLDN Transmission states9. 5.1.10 Deterministic and synchronous multi-channel

IEEE P802.15Wireless Personal Area Networks

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

Title TG4k MAC Subgroup working draft contribution

Date Submitted

[20 Dec 2011]

Source [Rolfe][Blind Creek Associates][]

Voice: [ +1.408.395.7202 ]Fax: [ ]E-mail: [ ben @ blindcreek.com ]

Re: [TG4k LECIM PHY development, MAC support]

Abstract Working draft for MAC additions necessary to support the LECIM PHYs

Purpose Draft standard development

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.

1Copyright © 2010 IEEE. All rights reserved.

This is an unapproved contribution to a Task Group Working Draft, subject to change.

1

2

3

4

IEEE 802.15.4k MAC Working Draft version: 2011-12-20

WARNING: Incomplete Work ProductWORKING DRAFT ONLY: Contribution to TASK GROUP Draft Development Process. DO NOT USE FOR ANY OTHER PURPOSE



1

2

3

4

5

6

7

8

910

Contents

Contents1. Overview......................................................................................................................................................1

1.1 General...................................................................................................................................................11.2 Scope.....................................................................................................................................................11.3 Purpose..................................................................................................................................................1

2. Normative references....................................................................................................................................1

3. Definitions, Acronyms and Abbreviations...................................................................................................23.1 Definitions.............................................................................................................................................23.2 Acronyms...............................................................................................................................................2

4. General Description......................................................................................................................................24.1 General...................................................................................................................................................24.2 Components of the WPAN....................................................................................................................24.3 Network topologies................................................................................................................................2

4.3.1 Star network formation.......................................................................................24.3.2 Peer to peer network formation..........................................................................2

4.4 Architecture...........................................................................................................................................24.4.1 PHY layer (PHY)................................................................................................24.4.2 MAC Sub-layer (General Characteristics)..........................................................2

4.5 Functional Overview.............................................................................................................................34.5.1 Superframe Structure..........................................................................................34.5.2 Data transfer model.............................................................................................34.5.3 Frame Structure..................................................................................................44.5.4 Improving probability of successful delivery.....................................................44.5.5 Power consumption considerations....................................................................64.5.6 Security...............................................................................................................6

4.6 Concept of primitives............................................................................................................................6

5. MAC protocol...............................................................................................................................................65.1 MAC functional description..................................................................................................................6

5.1.1 Channel Access...................................................................................................65.1.2 Starting and maintaining PANs..........................................................................85.1.3 Association and disassociation...........................................................................85.1.4 Synchronization..................................................................................................85.1.5 Transaction handling..........................................................................................85.1.6 Transmission, reception, and acknowledgment..................................................85.1.7 GTS allocation and management........................................................................95.1.8 Ranging...............................................................................................................95.1.9 LLDN Transmission states.................................................................................95.1.10 Deterministic and synchronous multi-channel extension (DSME)..................95.1.11 LE-transmission, reception and acknowledgment............................................95.1.12 Asynchronous multi-channel adaptation (AMCA).........................................13

5.2 MAC frame formats.............................................................................................................................13



1

2

3456

7

89

10

1112131415161718192021222324252627

282930313233343536373839404142

5.2.1 General frame formats......................................................................................135.2.2 Format of individual frame types.....................................................................145.2.4 Information Elements.......................................................................................14

5.3 MAC command frames.......................................................................................................................14

5......................................................................................................................................................................155.3.2..........................................................................................................................155.3.3..........................................................................................................................155.3.4..........................................................................................................................155.3.5..........................................................................................................................155.3.6..........................................................................................................................155.3.7..........................................................................................................................155.3.8..........................................................................................................................155.3.9..........................................................................................................................155.3.10........................................................................................................................155.3.11........................................................................................................................155.3.12........................................................................................................................15

5.4 MPDU Fragmentation.........................................................................................................................155.4.1 MPDU PHY adaptation, fragmentation and reaassembly................................155.4.2 Fragment cell formats.......................................................................................15

6. MAC services.............................................................................................................................................156.1 Overview.............................................................................................................................................156.2 MAC management service..................................................................................................................156.3 MAC data service................................................................................................................................156.4 MAC constants and PIB attributes......................................................................................................15

6.4.1 MAC constants.................................................................................................156.4.2 MAC PIB attributes..........................................................................................156.4.3 Calculating PHY dependent PIB values...........................................................15

7. Security.......................................................................................................................................................16

8. General PHY requirements.........................................................................................................................16

9. PHY services..............................................................................................................................................16

10. O-QPSK PHY...........................................................................................................................................16

11. Binary phase-shift keying (BPSK) PHY..................................................................................................16

12. Amplitude shift keying (ASK) PHY........................................................................................................16

13. Chirp spread spectrum (CSS) PHY..........................................................................................................16

14. UWB PHY................................................................................................................................................16

15. GFSK PHY...............................................................................................................................................16

16. SUN PHYs................................................................................................................................................16

17. MSK PHY................................................................................................................................................17



1234

56789

10111213141516171819

2021222324252627

28

29

30

31

32

33

34

35

36

37

38

18. LRP UWB PHY.......................................................................................................................................17

19. LECIM PHYs...........................................................................................................................................17



1

234

802.15.4k WORKING DRAFT, MAC sub-group Doc # 15-11-0882-00-004k

Draft<opt_Trial-Use><Gde./Rec. Prac./Std.> for <Complete Title Matching PAR>

NOTE: When preparing a draft amendment, the editors will include only the section headings where changes to the base standard are made. Amendments, when completed, will not contain any empty sub-clauses. In this outline all of the clauses and sub-clauses of the base standard are included for preliminary draft development (and because it is easier in Word). If there is no annotation in a section it is likely the amendment would not have contents for that section.

This outline is based on P8021.15.4-2011 taking into account (nearly) approved amendments 15.4e, 15.4f and 15.4g. By the time LECM balloting begins these will be completed approved amendments.

This is a working draft outline so it excludes the IEEE Boilerplate that will be added to the draft prior to balloting.

No additions Clause 1 are expected.

1. Overview

1.1 General

1.2 Scope

1.3 Purpose

2. Normative references

No changes expected.



1

2

3

45678

910

1112

13

14

15

16

17

18

19

20


3. Definitions, Acronyms and Abbreviations

3.1 Definitions

3.2 Acronyms

Insert in 3.2 in alphabetical order the following acronyms:

HWSL hybrid wakeup sample listening

4. General Description

Clause 4 is informative “big picture” overview. Normative text does NOT go in clause 4. The specific behaviors, structures and formats of things go in the appropriate PHY and MAC clauses.

4.1 General

Will add overview clauses as needed.

4.2 Components of the WPAN

Add in this clause any new categories of “device” that LECM adds, for example, assumptions about LECM coordinator vs LECM end device.

4.3 Network topologies

4.3.1 Star network formation Insert before 4.3.2 the following paragraphs:

LECIM networks are primarily star topology, with data flowing primarily from the endpoint devices to the coordinator. The coordinator is not as limited with respect to energy and available resources as endpoints devices, in which energy consumption is critical and resources may be very limited. This asymmetry is a characteristic feature of the LICEM network.

4.3.2 Peer to peer network formation

4.4 Architecture

4.4.1 PHY layer (PHY)

4.4.2 MAC Sub-layer (General Characteristics)The following MAC enhancements are included to support of Low Energy Critical Infrastructure Monitoring PHYs defied in clause 16:

Enhanced timing and synchronization capabilities to support synchronous and asynchronous channel access in both beacon enabled and non-beacon enabled operation

Enhanced low energy mechanisms



1

2

3

4

5

6

78

9

10

11

12

1314

15

1617

18192021

22

23

24

252627

2829

30


MPDU fragmentation to support extremely low data rates and limited PSDU sizes

Priority channel access

MAC SAP and PIB extensions for PHY control and configuration

4.5 Functional Overview

4.5.1 Superframe Structure

4.5.1.1 GeneralInsert text at into the enumerated list:

Superframe structure described in 4.5.1.2 based on beacons defined in 5.2.2.1 with an Information Element (IE) defined in 5.2.4.3.4 (DSME PAN Descriptor) and priority channel access slots.

Priority access enabling structure described in 4.5.1.5 supporting priority channel access in beacon-enabled CAP.

4.5.1.2 DSME multi-superframe structure

4.5.1.5 Use of superframe structure for LECIM Priority based contention channel access is provided in beacon-enabled mode by allocating the first two timeslots during the CAP of each superframe (see Figure 8). When the multi-superframe multi-superframe structure (Figure 4a) is in use, first two time slots in each CAP in the multi-superframe are allocated for high priority access.

When configured to support priority access, the priority access slots are used by devices with critical events to report, as defined by the higher layer via [PIB attribute and/or MLME or MCPS data service parameters], using the currently configured CAA mode (8.2.7). Transmission of messages with other than critical event priority will commence following the priority access timeslots.

4.5.2 Data transfer modelMay describe synchronized channel access (how MAC and PHY are used together). Refer to appropriate sub-clauses for normative descriptions.

4.5.2.1 Data transfer to a coordinatorA general overview of the uplink communication.

4.5.2.2 Data transfer from a coordinatorA general overview of downlink communication.

4.5.2.3 Peer-to-peer data transfersNo changes expected.

4.5.3 Frame StructureInsert at the end of 4.5.3:

When MPDU fragmentation is used (Add the following text and figure Add a figure for ‘Schematic view of the PPDU with MPDU Fragmentation’.

4.5.4 Improving probability of successful deliveryDescription of MPDU fragmentation as a reliability enhancing mechanism.

Insert new subclause between 4.5.4.1 and 4.5.4.2:



1

2

3

4

5

67

89

1011

12

1314151617

18192021

222324

2526

2728

2930

3132

3334

3536

37


4.5.4.1 a CSMA-CA used with priority channel accessWhen using a LECIM PHY in a Nonbeacon-enabled PAN, where unslotted CSMA-CA channel access mechanism is applied, priority channel access is achieved by an use of the alternate backoff mechanism (see 5.1.1.4). The alternate mechanism will, uses a fixed backoff window instead of an exponential backoff and will on average, provide less backoff duration for priority access than for normal access. In addition, the priority channel access continues to follow the channel, even if it is assessed busy, to gain immediate access to the channel once it is assessed idle.

Beacon-enabled PANs using a LECIM PHY dedicate CAP time slots in the beginning of a superframe for priority channel access. Priority frames may commence in the priority slot(s) and continue through the duration of the CAP. Priority frames in the priority access slots utilize persistent CSMA-CA with reduced CW and an alternate backoff mechanism for channel access, as described in [xref]. Priority frames during the non-priority slots of the CAP utilize CSMA-CA as described in 5.1.1.4 with an alternate backoff mechanism.

4.5.4.2 ALOHA mechanismInsert following after the last paragraph of 4.5.4.2:

When priority channel access is enabled, priority the alternate (fixed window) backoff mechanism is used (see xref). When operating in a Beacon-enabled PAN, slotted ALOHA improves efficiency of channel access. When slotted ALOHA with priority access, the first two time slots after the beacon are dedicated for priority channel access traffic. The backoff slot length is PHY dependent and must be able to accommodate at minimum the transmission of a single MPDU fragment.

Insert new subclause between 4.5.4.2 and 4.5.4.3

4.5.4.2 a MPDU FragmentationWith the addition of very low data rate PHY operating modes the resulting increase in duration over the air of the MAC frame can lead to increased interference potential, susceptibility to channel conditions changing during the duration of a MAC frame transmission, and other effects that may reduce reliable transfer in some environments typical of LECIM applications. In some PHY modes the PSDU size available may be smaller than the size of a full MAC frame. To preserve the functionality and proven reliability of the MAC defined in this standard and to make these PHY characteristics transparent to the majority of MAC functional capability, optional MPDU fragmentation is provided.

MPDU fragmentation operates on the complete MPDU and adapts it to the specific PHY and PHY operating mode. To reduce over the air overhead, some MAC header information is compressed or suppressed in the over the air exchange, by establishing a fragement sequence (transaction) context. The MPDU content is distributed into fragments, each packaged into an PPDU for transmission. Information in the fragment, combined with the fragment sequence context, provides identification of the individual fragment, what sequence it belongs to and where the fragment fits into the sequence. Each fragment carries an incremental validity check sequence to detect errors in each fragment. A schematic view of fragmenting the MPDU in to a fragment sequence is shown in Figure 1. In this standard the term “fragment” refers to an individual MPDU fragment, the term “fragment sequence” refers to the collection of fragments transmitted that comprise together the original MPDU, “fragment number” is the position, in the sequence, of an individual fragment, and the “fragment sequence ID” identifies the fragment sequence.



1234567

89

10111213

1415

1617181920

21

2223242526272829

3031323334353637383940


Figure 1 Schematic View of MPDU Fragmentation

Each fragment may be individually acknowledged and retransmitted. Retransmission of only missed fragments and reduce air time and improve reliability. The complete MPDU transaction may be acknowledged.

4.5.4.3 Frame acknowledgeInsert new subclauses at the end of 4.5.4.3:

4.5.4.3.1 Fragment Incremental acknowledge (I-ACK)The incremental acknowledgement (I-ACK) is used during the fragment sequence transfer to determine which fragments have been received successfully and which need to be retransmitted. An I-ACK may aggregate the status of one or more fragments. The number of fragment status reports grouped into an I-ACK is controlled by the higher layer. The format of the I-ACK is given in 5.1.6.4.2a.

4.5.4.3.2 MPDU completion acknowledgeThe MPDU acknowledgement mechanism may be used to report status of a fragment sequence transaction upon reconstruction of the MPDU at the recipient. The reassembly and validation process may require processing time in the MAC sublayer or higher layers prior to transmitting the final acknowledgement. A method is provided to coordinate the acknowledgement. Because fragment failures may due to conditions on a specific frequency channel, itt may also be desired to be able to transmit the acknowledgement and subsequent retransmissions on a different channel. A coordination mechanism is provided to support this capability (xref). Means is also provided to include feedback to the initiator of the transaction, such as link quality information (xref to IE definitions), which is made available to the higher layer and may be used for adjusting fragmentation parameters or PHY configuration based on performance.

4.5.4.4 Data verificationTo accommodate individual fragment acknowledgement, a fragment validation sequence (FVS) is included with each fragment. The recipient uses the FVS and fragment number to determine which fragments of the sequence have been received correctly and which are missing. The I-ACK reports the status of 1 or more received fragments. The FVS is described in (xref).

The reassembled MPDU also carries a frame check sequence (FCS). The MAC may apply this FCS as a validity check of the reassembled MPDU.



1

2

3

456

78

910111213

14151617181920212223

2425262728

2930

31


4.5.5 Power consumption considerationsA good place to give overview of the “Low Energy” part of LECM.

4.5.6 SecurityNo changes expected

4.6 Concept of primitives

No changes expected.

5. MAC protocol

5.1 MAC functional description

5.1.1 Channel Access

5.1.1.1 Superframe structureWhen priority access is enabled and the superframe shown in Figure 8 is in use, the two first time slots in the CAP as shown in Figure 8 shall be dedicated for priority channel access. When priority access is enabled and the multi-superframe shown in Figure 34g is in use, the first two time slots in each CAP shall be dedicated for priority channel access. See 5.1.1.4.

5.1.1.2 Incoming and outgoing superframe timing

5.1.1.3 Interframe spacing (IFS)

5.1.1.4 CSMA-CA Algorithm

5.1.1.4.1 CSMA with priority channel accessThis clause describes the alternate backoff used to support priority channel access for transmission of a critical event priority message. The backoff procedure shall be used when the CCA returns channel busy.

If the MAC sublayer cannot proceed, it it shall wait until the expiration of the two first time slots of the CAP in the next superframe and apply a further random backoff delay before evaluating whether it can proceed again.

Using a LECIM PHY, in the Nonbeacon-enabled PAN, where unslotted CSMA-CA is used, the critical event priority transmission may be initiated at any time. When CAA returns channel busy, the alternate backoff is used: BE remains constant for subsequent retransmissions. The first transmission attempt shall set the BE to the value of MACMinBE-1 (with default value of MACMinBE = 2). In addition, the priority channel access follows a persistent CSMA mechanism, where a device continues to monitor the channel and decrements the value of unit backoff periods any time the channel is sensed idle for duration of backoff slot in order to gain access to the channel as soon as possible.

In a beacon enabled PAN, a critical event priority message transmission may be initiated in any part of the CAP. When transmission is initiated in the priority time slots, and the CCA returns channel busy, the alternate backoff mechanism shall be used as follows: BE remains constant (tentatively 2, or MACMinBE) for retransmissions. The first transmission attempt shall set the BE to the value of MACMinBE-1.

When the critical event priority transmission is initiated in the CAP other than in the priority access timeslots, the primary CSMA-CA as defined in 5.1.1.4 with the above alternate backoff mechanism.



12

34

5

6

7

8

9

1011121314

15

16

17

181920

212223

24252627282930

31323334

3536

Ben, 01/17/12,

Don’t know what this means.

Ben, 01/17/12,

should be a new CCA mode?


5.1.1.4.2 LECIM Aloha Priority Channel AccessWhen critical event priority channel access is in use with CCA mode 4 (ALOHA), priority channel access is achieved by using an alternate backoff mechanism. Backoff is defined in macLECIMAlohaBackoffSlot durations. A macLECIMAlohaBackoffSlot duration is a PHY and deployment dependent parameter. It shall be sufficiently long to accommodate the transmission of a single MPDU fragment with associated IFSs and any ACK frames. The backoff window size shall stay constant during retransmissions

In Beacon-enabled PANs, slotted Aloha is applied for more efficient channel access. When critical event priority channel access is in use, the slot length equals to macLECIMAlohaBackoffSlot duration. In addition, the two first time slots after the beacon transmission are dedicated for priority channel access traffic. Priority frames may be transmitted in the entire CAP portion of the superframe.

5.1.1.5 TSCH-Slotframe structure

5.1.1.6 LLDN Superframe structure

5.1.1.7 LE-Functional descriptionChange text as indicated:

This subclause specifies functionalities of devices supporting the PIB attributes:

macCSLPeriod macRITPeriod macCSLMaxPeriod macHWSLMaxPeriod macHWSLPeriod macLowEnergySuperframeSupported and macLowEnergySuperframeSyncInterval

5.1.1.7.1 LE-Contention access period (LE-CAP)Change the text of the first paragraph as shown:

When macCSLPeriod is non-zero, CSL is deployed in CAP, while HWSL is deployed in CAP when macHWSLPeriod is non-zere. CSL behavior is defined in 5.1.11.1, and HWSL behavior is defined in 5.1.11.3. The macRITPeriod shall be set to zero in a beacon-enabled PAN.

5.1.1.7.2 LE-Superframe structure

5.1.1.7.3 LE- incoming and outgoing superframe timing

5.1.1.7.4 LE-ScanChange the first paragraph of 5.1.1.7.4:

When macCSLPeriod is non-zero, CSL is deployed in channel scans. When macCSLMaxPeriod is non-zero, each coordinator broadcasts beacon frames with wakeup frame sequence. When macHWSLPeriod is non-zero, each endpoint device deploy HWSL in channel scans. When macHWSLMaxPeriod is non-zero, each coordinator send wakeup sequence. This both allows devices to perform channel scans with low duty cycles.



123456

789

10

11

12

13

1415

16

1718192021222324

2526

272829

30

31

3233

3435363738


5.1.2 Starting and maintaining PANsNew methods to support LECIM go here, additions to scan for example.

5.1.3 Association and disassociationExpect there may be some sort of abbreviated link context setup considerations.

5.1.4 SynchronizationProbably some additional considerations for LECIM for both beacon and non beacon cases.

5.1.4.1 Synchronization with beacons

5.1.4.2 Synchronization without beacons

5.1.4.3 Orphaned device realignment

5.1.4.4 LECIM SynchronizationAlternately we may just add a separate section, or fold in to beacon or non-beacon cases as appropriate.

5.1.5 Transaction handling

5.1.6 Transmission, reception, and acknowledgmentExpect all sub-clauses will have some changes related to MPDU fragmentation

5.1.6.1 Transmission

5.1.6.2 Reception and rejectionExpect some additional filtering for MPDU fragmentation will be required based on context ID, sequence # or something like that.

5.1.6.3 Extracting pending data from a coordinatorNo changes expected; MPDU fragmentation should run ‘below’ this function.

5.1.6.4 Use of acknowledgments and retransmissionsAdd appropriate subclauses for incremental acknowledge and retransmission of fragments. Since these will be inserted between existing clauses they get the number of the preceding subclause with “a” appended.

5.1.6.4.1 No acknowledgment

5.1.6.4.2 a Incremental fragment acknowledgement

5.1.6.4.3 a Incremental fragment retransmission

5.1.6.5 Promiscuous modeNo changes expected for LECIM.

5.1.6.6 Transmission scenariosExpect a few new ones to be needed.

5.1.7 GTS allocation and managementDon’t’ expect changes in here.

5.1.8 RangingNo changes expected.



12

34

56

7

8

9

1011

12

1314

15

161718

1920

212223

24

25

26

2728

2930

3132

3334


5.1.9 LLDN Transmission statesNo changes expected.

5.1.10 Deterministic and synchronous multi-channel extension (DSME)

5.1.11 LE-transmission, reception and acknowledgment

5.1.11.1 Coordinated sampled listening (CSL)

5.1.11.2 Receiver initiated transmission (RIT)Insert new subclauses before 5.1.12:

5.1.11.3 LECIM Alternate/Hybrid LE scheme

5.1.11.3.1 GeneralThe Alternate/Hybrid LE mode is active when macLEenabled is TRUE while CSL and RIT are disabled, as indicated by macCSLPeriod and macRITPeriod set to zero.

The basic LECIM Hybrid LE mode is illustrated in figure 34sa.

Figure 2 34sa Basic LECIM LE mode operations

5.1.11.3.2 LECIM LE TransmissionIn LECIM networks, transmissions are mainly from endpoint devices to coordinator. As described in 4, as power of the coordinator is not as limited as endpoint devices, in LECIM LE mode, the coordinator shall keep listening for the channel, except it has data frame to send, or need to send beacon frames when macLowEnergySuperframeSupported is TRUE.

Endpoint device shall keep sleeping for the normal time, when it has data frame to send, it will enable its transmitter, and send the data frame.

When macLowEnergySuperframeSupported is TRUE, endpoint device will send data frames by using slotted Aloha or slotted CSMA-CA. Otherwise, endpoint device will send data frames by using unslotted Aloha or unslotted CSMA-CA.

On receipt of data frame from endpoint device, if the coordinator has data frame need to send to the corresponding endpoint device, it will send the corresponding data frame as Acknowledgement for the received data frame. And if the coordinator has more than one data frame need to send to the same endpoint device, it can indicate it by setting the pending field in the frame. Otherwise, the coordicator will send Acknowledgement frame back.



12

3

4

5

67

8

91011

12

13

14

1516171819

2021

222324

2526272829


After sending data frame to coordinator, the endpoint device shall wait for macAckWaitDuration. If an acknowledgement frame is received within macAckWaitDuration and contains the same DSN as the original transmission, or an new data frame is receive from the coordinator within macAckWaitDuration, the transmission is considered successful. Otherwise, the device shall conclude that the transmission has failed, and will retransmit the data frame as macMaxFrameRetries be set.

If the endpoint device received data frame from coordinator, it need the send acknowledgement as IEEE 802.15.4-2011 defined, and decided to turn off receiver or not by the pending field of the received data frame.

5.1.11.3.3 Hybrid Wakeup Sample Listening (HWSL)When the PIB attribute macHWSLenabled is TRUE, the Hybrid Wakeup Sample Listening (HWSL) mode is enabled, to guarantee timely transmission from coordinator to endpoint devices.

If PIB attribute macHWSLenabled is TRUE, the value of PIB attribute macCSLPeriod and macRITPeriod will be ignored.

Figure 3 34sb unicast transmission of HWSL modeAs described in 5.1.11.3.2, for daily transmission from the coordinator to endpoint devices, the coordinator shall transmit the data the endpoint device until received data frames from the corresponding endpoint device. In some cases, the latency will be very long, HWSL mode is used for the emergency data frame from the coordinator to the endpoint device, and support broadcast data frame from the coordinator.

In HWSL mode, coordinator shall keep channel listening, and if it has emergency data frame to send, the transmission of the payload frame is preceded with a sequence HWSL wakeup frames.

The HWSL wakeup sequence is consist of a sequence of HWSL wakeup frames, and the interval of each HWSL wakeup frame is defined by the PIB attribute macHWSLWakeupInterval. Between sending the two HWSL wakeup frames, the coordinator will change to listen the channel. The maximum length of HWSL wakeup sequence is macHWSLMaxPeriod.

Endpoint devices performs a channel sample every macHWSLPeriod time. If the channel sample does not detect any HWSL wakeup frame from the coordinator on the channel, the endpoint device shall disable the receiver until the next channel sample time, and then performs the next channel sample.

If the coordinator has unicast frame to send, the destination address of HWSL wakeup frame shall be set to the address of corresponding endpoint device. On receipt of the unicast HWSL wakeup frame when the endpoint device performed channel sample, it shall first check the destination address. If the destination address is match, the endpoint device shall inform the higher layer, stop the periodly channel sample, send back HWSL data request frame to the coordinator, and wait for macDataWaitDuration for incoming unicast data frame.



12345

678

91011

1213

14

15

16171819

2021

22232425

262728

293031323334


If the coordinator received HWSL data request frame from the cooresponding endpoint device after sending an unicast HWSL wakeup frame, it shall stop sending the HWSL wakeup sequence, and send the corresponding unicast data frame to the endpoint immediately, and then wait for macAckWaitDuration, for the acknowledgement from endpoint device.

On receipt of the incoming unicast data frame, the endpoint device will send back corresponding acknowledgement to the coordinator.

If the next higher layer of the coordinator has multiple frames to transmit to the same destination, it can set the frame pending bit of frame control field to one in all but the last frame.

HWSL unicast transmission is performed in the following steps by the MAC layer of the coordinator:

a) Perform CSMA-CA to acquire the channel

b) If the previous acknowledged unicast data frame to the destination has the frame pending bit set and is within macHWSLFramePendingWaitT (defined in Table 52j), go to step d).

c) For the duration of wakeup sequence length, transmit HWSL wakeup frames by the interval of macHWSLWakeupInterval.

d) If the coordinator has pending unicast data frame to send, set the pending bit of the frame control field to one, then transmit unicast data frame.

e) Wait for up to macAckWaitDuration symbol time for the acknowledgment frame if the acknowledge request field in the unicast data frame is set to one.

f) If the acknowledgment frame is received, go to step g), otherwise, start retransmission process.

g) If the coordinator has pending unicast data to send, go to step b), otherwise turn off the HWSL mode, keep listening for the channel.

Figure 4 (34sc) –broadcast transmission of HWSL modeIf the coordinator has broadcast frame to send, the destination address of HWSL wakeup frame shall be set to 0xffff, and include the remaining time of the broadcast data frame transmission.

On receipt of the broacast HWSL wakeup frame when the endpoint device performed channel sample, it shall inform the higher layer, stop the periodly channel sample, send back HWSL data request frame to the



1234

56

78

9

10

1112

1314

1516

1718

19

2021

22

23

2425

2627


coordinator, back to sleep status until the remaining time indicated in the broadcast HWSL wakeup frame, then turn on the receiver, and waiting for the corresponding broadcast data frame.

If the coordinator received HWSL data request frame from the cooresponding endpoint device after sending a broadcast HWSL wakeup frame, it will keep sending the HWSL wakeup sequence, until received HWSL data request frames from all the endpoint devices or until macHWSLMaxPeriod. The coordinator will send corresponding broadcast data frame in the designed time.

5.1.11.4 Implicit receiver Initiated transmission (I-RIT)

5.1.11.4.1 GeneralThe implicit receiver initiated transmission (I-RIT) is an alternative low energy MAC for nonbeacon-enabled PANs. I-RIT is designed to be used for end devices, such as sensors, that primarily transmit information to a coordinator but have no way of determining when they should make use of conventional RIT. Instead of transmitting a RIT data request, when an end device has I-RIT enabled, the device turns its receiver on for a known period of time, at a known interval after each transmission, so that the end device makes itself available to receiver information from the coordinator. I-RIT mode is turned on when PIB attribute macIRITPeriod is non-zero and is turned off when macIRITPeriod is zero. The values of macCSLPeriod (in coordinated sample listening) and macRITPeriod, shall be set to zero when the value of macIRITPeriod is nonzero. Transmission and reception in I-RIT mode is illustrated in Figure 5 (34sd).

Endpoint

Concentrator

TX

RX

TX

RX

DataPending

Data

DataExchange

Figure 5 (34sd) - I-RIT transmission

5.1.11.4.2 I-RIT data request transmission and receptionIn I-RIT mode, a device turns on its receive macIRITPeriod symbol periods after the last bit of its transmitted frame for a period of macIRITListenDuration symbol periods for incoming frame and goes back to idle state until the next frame is transmitted

Upon reception of frame during the I-RIT reception period, it notifies its arrival to the next higher layer by initiating corresponding indication primitive. The next higher layer will determine the successive operations based on the content of the received frame.



12

3456

7

89

1011121314151617

18

19

20

21222324

252627


5.1.12 Asynchronous multi-channel adaptation (AMCA)

5.2 MAC frame formats

Expect to add new Information Elements to 5.2.4, which will require adding to table 4b and new subclauses starting at 5.2.4.23.

5.2.1 General frame formats

5.2.1.1.3 Frame pending fieldChange the first paragraph of 5.2.1.1.3 as shown:

When operating in Low Energy (LE) CSL mode or HWSL mode, the frame pending bit may be set to one to indicate that the transmitting device has back-to-back frames to send to the same recipient and expects the recipient to keep the radio on until the frame pending bit is reset to zero.

5.2.2 Format of individual frame typesChange the 3rd line of Table 3b as shown:

Table 3b – LE-specific MAC PIB attribute

Attribute Request Identifier

PIB attribute IE Type IEs to include

3 macLEenabled Header LE CSL, or LE RIT, HWSL LE (5.2.4.7, 5.2.4.8, 5.2.4.8a.)

5.2.4 Information Elements

5.2.4.2 Header Information ElementsInsert the following row into Table 4b:

Table 4b—Element IDs, Header IEs

Element ID Content Length Name Description0x21 4 LE HWSL Defined in 5.2.4.8a

Insert new subclause between 5.2.4.8 and 5.2.4.9:

5.2.4.8 a HWSL IEThe structure of HWSL IE is illustrated in Figure 48ua.

Octets: 2 2HWSL Phase HWSL Remain Time

Figure 48ua – HWSL IEThe HWSL Phase field specifies the remaining time of the HWSL wakeup sequence, the range of the value of this filed is 0x0000 – 0xffff, by 10 symbols.



1

2

3

45

6

78

91011

1213

14

15

16

17

18

1920

21

22

23

2425

26

2728


The HWSL Remain Time specifies the remaining time of the incoming data frame, the range of the value of this filed is 0x0000 – 0xffff, by 10 symbols.

5.3 MAC command frames

Insert the following rows into Table 5:

Table 5 – MAC command frames

Command frame identifier Command name RFD SubclauseTX RX

0x21 HWSL-data request X 5.3.12.20x22 HWSL-wakeup 5.3.12.1

Insert new subcluse after 5.3.12.1:

5.

5.1.1

5.1.2

5.1.3

5.1.4

5.1.5

5.1.6

5.1.7

5.1.8

5.1.9

5.1.10

5.1.11

5.1.11.1 HWSL data request commandTBD

5.1.11.2 HWSL wakeup commandTBD

5.2 MPDU Fragmentation

When MPDU fragmentation is enabled, the completed MPDU will be transformed into a sequence of fragment cells as described in this subclause. The context of the fragment sequence is established between the initiating device and the recipient device, certain MHR fields may be transformed or elided, a fragment



12

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

2021

2223

24

252627


check sequence, fragment descriptor, and fragment content are packaged into a PPDU for the PHY in use according to PHY specific parameters and parameters provided by the higher layer. Each fragment

5.2.1 MPDU PHY adaptation, fragmentation and reassembly

5.2.1.1 Fragment sequence context

5.2.1.2 Fragment cell formats

5.2.1.3 Fragmentation

5.2.1.4 Reassembly

5.2.2 Fragment Acknowledgement and retransmissionTwo levels of fragment acknowledgement are provided, acknowledgement of fragments during the transfer process (incremental acknowledgment) which provide “progress reports” and acknowledgement of the reassembled MPDU. In each, the status of individual fragments is indicated and the initiating device can retransmit only those fragments which were not received and validated.

5.2.2.1 Incremental fragment Acknowledgement (I-ACK)The I-ACK is generated incrementally during the fragment sequence transfer and report status indicating which fragments have been successfully received up to that point. The interval of I-ACK is determined by the IACK_interval parameter of the MCPS-Data.request. Upon completion of transmission of each IACK_interval fragment cells, the initiating device will suspend transfer and wait macIACKtimeout for the expected I-ACK. Upon reception of the I-ACK, fragments indicated as not received correctly shall be retransmitted. The number of retransmissions is limited by macMPDUFragRetryMax.

Options: IACK field of the fragment descriptor is set upon transmission of every IACK-interval packet, or the IACK_interval value is transferred with the fragment sequence context only.

The I-ACK will include the fragment status field, constructed as shown in [ref].

5.2.2.2 Aggregated MPDU transfer acknowledgementIf the received MPDU has Acknowledgment requested indicated in the MHR, the generated acknowledgement (using the Enhanced Acknowledgement) will include an the Fragment Status IE, constructed and transmitted as described here. The MPDU acknowledgement may contain information to support the channel switching notification.

Between the reception of last fragment of the group and transmission of MPDU acknowledgment, because the recipient MAC sublayer needs some time to process received fragments and prepare acknowledgement. MPDU acknowledgement or channel switching notification (CSN) command, there is a possibility that other devices in the network may access and use the medium so that MPDU acknowledgement or CSN command is further delayed. If channel condition change significantly, the transmission of following groups will be impacted. The following subclauses provides fuctions that may be used to mitigate the impact.

5.2.2.3 Channel switching for fragment sequence exchange



12

3

4

5

6

7

89

101112

13141516171819

2021

22

2324252627

28293031323334

3536

37

38


6. MAC services

6.1 Overview

6.2 MAC management service

6.3 MAC data service

6.4 MAC constants and PIB attributes

6.4.1 MAC constants

6.4.2 MAC PIB attributes

6.4.3 Calculating PHY dependent PIB values

6.4.3.7 LE-specific MAC PIB attributesInsert new row into Table 52j:

Table 52j – LE-specific MAC PIB attribute:

Table 52j

Attribute Type Range Description DefaulmacHWSLPeriod Integer 0 - 65535 HWSL sampled listening

period in unit of 10 symbols.0

macHWSLMaxPeriod Integer 0 - 65535 Maximum length of HWSL wakeup sequence of 10 symbols.

macHWSLPeriod

macHWSLFramePendingWaitT Integer (macMinLIFSPeriod + max number of symbols per PPDU) - 65535

Number of symbols to keep the receiver on after receiving a data frame with frame pending bit of control field set to one.

-

macIRITPeriod Integer 0x00000–0xffff

The interval (in symbol periods) from the end of the transmitted frame to the beginning of the I-RIT listening period. 0 means I-RIT is off

0x00

macIRITListenDuration Integer 0x00-0xff The duration of listening time (in symbol periods) where the receiver is listening for the beginning of a frame to receive.

0x64



1

2

3

4

5

6

7

8

910

11

12

13

14


7. Security

No changes expected at this time.

8. General PHY requirements

9. PHY services

10. O-QPSK PHY

11. Binary phase-shift keying (BPSK) PHY

12. Amplitude shift keying (ASK) PHY

13. Chirp spread spectrum (CSS) PHY

14. UWB PHY

15. GFSK PHY

16. SUN PHYs

Added by 15.4g TG.

17. MSK PHY

Added by 15.4f RFID TG.

18. LRP UWB PHY

Added by 15.4f RFID TG.

19. LECIM PHYs



1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

Documents

802.15.4k MAC additions working draft - Web view5.1.7 GTS allocation and management9. 5.1.8 Ranging9. 5.1.9 LLDN Transmission states9. 5.1.10 Deterministic and synchronous multi-channel