July, 2015 IEEE P802.15-15/245r1
IEEE P802.15
Wireless Personal Area Networks
Project / IEEE P802.15 Working Group for Wireless Personal Area Networks (WPANs)Title / Low Latency Deterministic Networks (LLDN) base text for IEEE 802.15.4 REVc
Date Submitted / [08July, 2015]
Source / [Michael Bahr]
[Siemens AG]
[Otto-Hahn-Ring 6, Munich, Germany] / Voice:[+49-89-636-49926]
Fax:[ ]
E-mail:[bahr et siemens dod com]
Re: / Resolutions and responses to LLDN-related problems in IEEE 802.15.4 REVc. The LLDN-related problems are listed in document 15-14-0224-06.
Abstract / This document provides the base text of Low Latency Deterministic Networks (LLDN) to be included in IEEE 802.15.4 REVc. It is the textual basis for resolutions to issues in IEEE 802.15.4 REVc related to the LLDN mode. The LLDN-related problems are listed in document 15-14-0224-06.
The text is adapted to version DF5 of the IEEE 802.15.4 REVc document.
This document is the first step to a thorough resolution of comments and issues in IEEE 802.15.4 REVc related to Low Latency Deterministic Networks (LLDN), so that the LLDN mode stays in REVc of the IEEE 802.15.4 standard.
Purpose / Specification of Low Latency Deterministic Networks of IEEE 802.15.4e to be kept in REVc of IEEE 802.15.4.
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.
Low Latency Deterministic Networks (LLDN) base text for IEEE 802.15.4 REVc
This document provides the base text of Low Latency Deterministic Networks (LLDN) to be included in IEEE 802.15.4 REVc. It is the textual basis for resolutions to issues in IEEE 802.15.4 REVc related to the LLDN mode. The LLDN-related problems are listed in document 15-14-0224-06.
The text is adapted to version DF5 of the IEEE 802.15.4 REVc document.
This document is the first step to a thorough resolution of comments and issues in IEEE 802.15.4 REVc related to Low Latency Deterministic Networks (LLDN), so that the LLDN mode stays in REVc of the IEEE 802.15.4 standard.
The purpose of this document is to keep the specification of Low Latency Deterministic Networks of IEEE 802.15.4e in the REVc of IEEE 802.15.4.
This base text of 15-15/245 will be used as basis for the text of the resolutions for the LLDN issues for IEEE 802.15.4 REVc.
Further documents related to LLDN resolutions:
15-15/174r0Resolutions and responses to LLDN-related problems listed in 15-14-0224
15-15/249r0Low Latency Deterministic Networks (LLDN) in IEEE 802.15.4
To Editor: Insertinalphabeticalorderthefollowingdefinitions in “3.1 Definitions”:
downlink:Datacommunicationfromthepersonalareanetwork(PAN)coordinatortothePANdevice.
lowlatencydeterministicnetwork(LLDN):Apersonalareanetwork(PAN)organizedasastarnetworkwithasuperframestructureandusingLLDNframes.
lowlatencydeterministicnetwork(LLDN)device:AdeviceinanLLDNthatisassociatedtoanLLDNcoordinator.
slot owner: Alowlatencydeterministicnetwork(LLDN)devicethat isassignedexclusiveaccess rightsatthebeginningofatimeslotinanLLDN.
uplink:datacommunicationfromthepersonalareanetwork(PAN)devicetothePANcoordinator.
To Editor: Insert in “3.2 Acronyms and abbreviations” the following abbreviations and acronyms in alphabetical order:
ACKpositive acknowledgment
CTScleartosend
GACKgroup acknowledgment
LLlow latency
LLDNlow latency deterministic network
RTSrequest to send
To Editor: Insert in “4.3.15.5.1 Star network formation” the following paragraph as new 2nd paragraph:
Alowlatencydeterministicnetwork(LLDN)operatesinastartopology.MoreinformationonthestartopologyofLLDNsisgiveninAnnex I.”Applications of IEEE Std 802.15.4” [B2].
To Editor: Insert the following paragraph as 3rd itemin the 2nd paragraph of “5.7.1 4.5.1 Superframe structure”
—Superframe structure described in 4.5.1.35.7.1.1a based on LL-Beacons defined in 5.2.2.5.27.3.4a.2.
To Editor: Insert the following clause 5.7.1.1a before “5.7.1.2 Slotframes”
4.5.1.3 5.7.1.1a SuperframestructurebasedonLLBeacons
LLDNPANs(i.e.,macLLenabledisTRUE)usetheLLDNsuperframestructureasdescribedin5.1.1.66.2.6a.Thesuperframeisdividedintoabeaconslot,0or2managementtimeslots(i.e.,2ifmacLLDNmgmtTSisTRUE),andmacLLDNnumTimeSlotsnumberoftimeslotsofequallengthasshowninFigure4b.
Figure4b—LLDNSuperframewithdedicatedtimeslots
The first timeslot of each superframe contains an LL-Beacon frame. The LL-Beacon frame is used for synchronization with the superframe structure. It is also used for re-synchronization of devices that, for instance, went into power save or sleep mode.
The beacon timeslot may be followed by two management timeslots, one for downlink and one for uplink.
The remaining timeslots are assigned to the LLDN devices in the network; there is no explicit addressing necessary inside the frames provided that there is exactly one device assigned to a timeslot as per 5.1.1.6.66.2.6a.6. The determination of the sender is achieved through the indexing of timeslots. If there is more than one device assigned to a timeslot, the timeslot is referred to as shared group timeslot, and a simple addressing scheme with 8-bit addresses, macSimpleAddress, is used as described in 6.38.3.
5.7.2.2 4.5.2.1 Datatransfertoacoordinator
To Editor: Insert before 5.7.2.3 4.5.2.2 the following paragraph and figure at the end of 4.5.2.15.7.2.2:
WhenadevicewishestotransferdatatoaPANcoordinatorinanLLDN,itfirstlistensforthenetworkbeacon.Whenthebeaconisfound,thedevicesynchronizestothesuperframestructure.Atitsassignedtimeslot,thedevicetransmitsitsdataframetotheLLDNPANcoordinator.Ifthedevicetransmitsitsdataframeinadedicatedtimeslotorasslotownerofasharedgrouptimeslot,thedataframeistransmittedwithoutusingCSMA-CA.Ifthedevicetransmitsitsdataframeinasharedgrouptimeslotandisnottheslotowner,thedataframeistransmittedusingslottedCSMA-CAasdescribedin5.1.1.4.46.2.5.3a, or ALOHA described in 4.5.4.35.8.4.1,dependingontheusedPHY.TheLLDNPANcoordinatormayacknowledgethesuccessfulreceptionofthedatabytransmittinganoptionalacknowledgmentframe.Successfuldatatransmissionsin dedicatedtimeslotsor by theslotowner areacknowledgedbythe LLDN PANcoordinatorwithaGroupAcknowledgmenteitherinthenextbeaconorasaseparategroupacknowledgment(GACK)frame.ThissequenceissummarizedinFigure4c.
DedicatedtimeslotSharedgroup timeslot
Figure4c—CommunicationtoaPANcoordinatorinanLLDN
5.7.2.3 4.5.2.2 Datatransferfromacoordinator
Insert before 5.7.2.4 4.5.2.3 the following paragraphs and figure at the end of 5.7.2.34.5.2.2:
AdatatransferfromanLLDNPANcoordinatorisonlypossibleinthemacLLDNnumBidirectionalTStimeslotsdescribedin5.1.1.6.56.2.6a.5andiftheTransmissionDirectionfieldintheFlagsfieldofthebeaconindicatesdownlinkdirection.
WhentheLLDNPANcoordinatorwishestotransferdatatoanLLDNdeviceassignedtoabidirectionaltimeslotinanLLDN,itindicatesinthenetworkbeaconthatthetransmissiondirectionisdownlink.Attheappropriatetime,theLLDNPANcoordinatortransmitsitsdataframetothedevicewithoutusingCSMA-CA.ThedevicemayacknowledgethesuccessfulreceptionofthedatabytransmittinganacknowledgmentframetotheLLDNPANcoordinatorinthesametimeslotofthenextsuperframe.Inordertodoso,thetransmissiondirectionhastobeuplinkinthatsuperframe.ThissequenceissummarizedinFigure4d.
Figure4d—CommunicationfromaPANcoordinatortoadeviceinanLLDN
Insert in clause 5.7.4 “Access methods” the following text as 5th item in the list in the second paragraph
-simplified slotted CSMA-CA used in LLDNs, as described in 6.2.5.3a
To Editor: Insert in “6.2.1 5.1.1.1 Superframe structure” after the first paragraph the following text:
ForLLDNapplicationsanadditionalsuperframestructurewithLLDNbeaconsisrequired,asdescribedin5.1.1.66.2.6a.
To Editor: Insert the following clause 6.2.5.3a 5.1.1.4.4 before “6.2.5.4 CSMA-CA with PCA”
6.2.5.3a 5.1.1.4.4 LLDNsimplifiedCSMA-CA
AsimplifiedCSMA-CAalgorithmisusedduringManagementtimeslotsandSharedGrouptimeslotsinLLDNs.
ThesimplifiedCSMA-CA is a slottedCSMA-CA mechanismandfollowsthe samealgorithmasdescribedin5.1.1.4.1.6.2.5.1.
ThebackoffslotsofaUnitBackoffPeriodsymbolsarealignedwiththestartofthebeacontransmissioninmanagementtimeslotsandwithtSlotTxOwnerinsharedgrouptimeslots.
EachtimeadevicewishestotransmitdataframeswithCSMA-CAattheappropriateplaces,itlocatestheboundaryofthenextbackoffslotandthenwaitsforarandomnumberofbackoffslots.Ifthechannelisbusy,followingthisrandombackoff,thedevicewaitsforanotherrandomnumberofbackoffslotsbeforetryingtoaccessthechannelagain.Ifthechannelisidle,thedevicebeginstransmittingonthenextavailablebackoffslotboundary.AcknowledgmentandbeaconframesaresentwithoutusingaCSMA-CAmechanism.
To Editor: Insert the following clause 6.2.6a5.1.1.6 before “6.2.7 LE Functional description”
6.2.6a 5.1.1.6 LLDNSuperframestructure
6.2.6a.1 5.1.1.6.1 Generalstructureofsuperframe
TheLLDNsuperframeisdividedintoabeaconslot,managementtimeslotsifpresent,andmacLLDNnumTimeSlotsbasetimeslotsofequallengthasillustratedinFigure11e.
Superframe
Beacon / TN1 / TN2 / TN3 / TNn / Beacon / TN1 / TN2 / TN3 / TNntime
Slot
Figure11e—Superframewithdedicatedtimeslots
Thefirsttimeslotofeachsuperframecontainsabeaconframe.Thebeaconframeisusedforsynchronizationwith thesuperframestructure.It isalsoused for re-synchronization of devices thatwentinto powersave orsleepmode.
Theremainingtimeslotsareassignedtospecificdevicesofthenetwork.Eachtimeslotmayhaveassignedaso-calledslotowner.Theslotownerhasaccessprivilegesinthetimeslot(dedicatedtimeslot).Thereisnoexplicitaddressingnecessaryinside theframesiftheslotownertransmitsinitstimeslot.Thedeterminationofthesenderisachievedthroughthenumberofthetimeslot.Morethanonedevicecanbeassignedtoatimeslot(sharedgrouptimeslot).Thedevicesuseacontention-basedaccessmethod(modsimplifiedCSMA-CAasspecifiedin5.1.1.4.46.2.5.3a)andasimpleaddressingschemewith8-bitaddressesinsharedgrouptimeslots.
Multipleadjacentbasetimeslotscanbeconcatenatedtoasingle,largertimeslot,asillustratedinFigure11f.
managementtime slots / retransmissiontime slots / uplink
time slots / bidirectiona
time slots / l
Beacon / downlink / uplink / S1 / Sr / Sr+1 / ... / Sn / A1 / ... / Am
SubmissionPage 1Michael Bahr, Siemens AG
July, 2015 IEEE P802.15-15/245r1
presentif
macLLDNmgmtTS= TRUE
Superframe
macLLDNnumTimeSlots
macLLDNnumUplinkTSmacLLDNnumBidirectionalTSmacLLDNnumRetransmitTS
time
SubmissionPage 1Michael Bahr, Siemens AG
July, 2015 IEEE P802.15-15/245r1
Figure11f—Usageandorderofslotsinasuperframe
AsshowninFigure11f,thereisaspecificorderinthemeaningorusageofthetimeslots,asfollows:
—BeaconTimeslot:alwayspresent.
—ManagementTimeslots:onetimeslotdownlink,onetimeslotuplink,presenceisconfigurablein
macLLDNmgmtTSduringtheConfigurationstate.
—UplinktimeslotsforLLDNdevices:macLLDNnumUplinkTStimeslotsuplink(unidirectionalcommunication),macLLDNnumRetransmitTStimeslotsatthebeginningcanbereservedforretransmissionsaccordingtotheGroupAcknowledgementfieldcontainedintheLL-beaconasdescribedin5.2.2.5.27.3.4a.2and5.1.9.46.10a.4.
—BidirectionaltimeslotsforLLDNdevices:macLLDNnumBidirectionalTStimeslotsuplink/downlink(bidirectionalcommunication).
ItisalsopossibletouseaseparateGroupAcknowledgement(GACK)frameasdescribedin5.2.2.5.47.3.4a.4inordertofacilitateretransmissionsoffailedtransmissionsintheuplinktimeslotswithinthesamesuperframe.TheuseofaseparateGACKisconfigurableduringconfigurationmode.IftheuseofaseparateGACKisconfigured,thestructureofthesuperframeisasdepictedinFigure11g.
managementtimeslots / uplinktimeslots
GroupAcktimeslot / retransmissiontimeslots / bidirectional
timeslots
Beacon / downlink / uplink / S1 / ... / Sn-r-1 / GACK / Sn-r+1 / Sn / A1 / ... / Am
SubmissionPage 1Michael Bahr, Siemens AG
July, 2015 IEEE P802.15-15/245r1
presentif
macLLDNmgmtTS=TRUE
macLLDNnumTimeSlots
macLLDNnumUplinkTSmacLLDNnumBidirectionalTS
time
SubmissionPage 1Michael Bahr, Siemens AG
July, 2015 IEEE P802.15-15/245r1
macLLDNnumRetransmitTS
Figure11g—UsageandorderofslotsinasuperframewithconfigureduseofseparateGACK
DescriptionsofthefollowingconfigurationparametersandintervalsforthesuperframewithaseparateGACKareonlydifferentfortheUplinkTimeslots:
—BeaconTimeslot
—ManagementTimeslots
—UplinkTimeslots:macLLDNnumUplinkTSdenotesthetotalnumberoftimeslotsavailableforuplink(unidirectional)communication.Typically,onetimeslotisallocatedtoeachLLDNdevice.Inthiscase,MdenotesthenumberofLLDNdevices,macLLDNnumRetransmitTSdenotesthenumberoftimeslotsallocatedforLLDNdevicesthatfailedtheiroriginaltransmissionspriortotheGACKandneedtoretransmittheirmessage,andNdenotesthenumberofLLDNdevicesthatareallowedtoretransmit.OnetimeslotisallocatedforeachretransmittingLLDNdevice.
—GACK:ItcontainsanMbitbitmaptoindicatesuccessfulandfaileduplinktransmissionsinthesameorderastheuplinktransmissions.
—BidirectionalTimeslots
TheLLBeaconframeintheLLDNmodealwayscarriestheGACKbitmapevenifaseparateGACKframeisused.TheGACKbitmapisusedforacknowledgingthesuccessfulretransmissionsintimeslotsR1,R2,...,RNsincesomeoftheretransmittedframes(inR1,R2,…,RNtimeslots)mayfail.
6.2.6a.2 5.1.1.6.2 Beacontimeslot
ThebeacontimeslotisreservedfortheLLDNPANcoordinatortoindicatethestartofasuperframewiththetransmissionofabeacon.Thebeaconisusedtosynchronizethedevicesandtoindicatethecurrenttransmissionmode.Thebeaconalsocontainsacknowledgmentsforthedatatransmittedinthelastsuperframe.
Thebeacontimeslotisavailableineverysuperframe.
6.2.6a.3 5.1.1.6.3 Managementtimeslots
Thefirstportionofasuperframeafterthebeacontimeslotisformedbythemanagementtimeslots,i.e.,thedownlinkanduplinkmanagementtimeslots.
ThedownlinkdirectionisdefinedassendingdatatotheLLDNdevice.TheuplinkdirectionisdefinedassendingdatafromtheLLDNdevicetotheLLDNCoordinator.
Managementtimeslotsprovideamechanismforbidirectionaltransmissionofmanagementdataindownlinkanduplinkdirection.Downlinkanduplinktimeslotsareprovidedinequalnumberinasuperframe.Therearetwomanagementtimeslotspersuperframeatmaximum.Managementtimeslotsareimplementedassharedgroupaccesstimeslots.
Management downlinkand uplink timeslotsareusedinthe Discoverystateand the Configuration state andareoptionalintheOnlinestate.Thesestatesaredescribedin5.1.96.10a.
6.2.6a.4 5.1.1.6.4 Uplinktimeslots
Afterthemanagementtimeslots,timeslotsforthetransmissionofdataarecontainedinasuperframe.Uplinktimeslotsallowforunidirectionalcommunication(uplink)only.
ThefirstmacLLDNnumRetransmitTSofthemacLLDNnumUplinkTSuplinktimeslotsarededicatedtimeslotsforretransmissionsoffaileduplinktransmissionattemptsindedicatedtimeslotsoftheprevioussuperframe.Thedynamicassignmentofnodestoretransmissiontimeslotsisdescribedin5.1.9.46.10a.4.
6.2.6a.5 5.1.1.6.5 Bidirectionaltimeslots
BidirectionaltimeslotsallowforbidirectionalcommunicationbetweentheLLDNPANcoordinatorandtheLLDNdevice.Thedirectionofthecommunicationissignaledinthebeaconasdescribedin5.2.2.5.27.3.4a.2.BidirectionaltimeslotsareusedforthetransmissionofdevicedatatotheLLDNPANcoordinator(uplink)aswellasofdatafromtheLLDNPANcoordinatortotheLLDNdevice(downlink).
6.2.6a.6 5.1.1.6.6 Channelaccesswithintimeslots
EachtimeslotisdescribedbyfourtimeattributesasillustratedinFigure11handdescribedinTable0a.
SharedGroupTimeslot
Figure11h—Timeattributesoftimeslots
Table0a—Timeattributesoftimeslots
Attribute / DescriptiontSlotStart / Startingtimeoftimeslot
tSlotTxOwner / Endtimeofprivilegedaccessbydevicethatownsthetimeslot
tSlotTxGW / Iftimeslotisunused,LLDNPANcoordinatorcanusethetimeslot
tSlotEnd / Endtimeoftimeslot
From tSlotStarttilltSlotTxOwner,thedevicethatowns theslot,theslotowner,hasexclusiveaccesstothetimeslot.
FromtSlotTxOwnertilltSlotTxGW,anydeviceotherthantheLLDNPANCoordinatormayusethetimeslotfordatatransmissionwithamodifiedCSMA-CAaccessschemeasdescribedin5.1.1.4.46.2.5.3aifthetimeslotisnotusedbytheslotowner.Ifthetimeslotisnotusedbytheslotowner,theLLDNPANCoordinatorshallindicatethisbybroadcastingaClearToSend(CTS)SharedGroupframe(5.3.10.47.5.11d).ToreducethechancesofcollisionsfromotherLLDNdevicestryingtousethistimeslot,anLLDNdeviceshouldsendaRequestToSend(RTS)frame(5.3.10.57.5.11e)andwaitforthereceiptofthecorrespondingCTSframe(5.3.10.67.5.11f)thatidentifiesthisLLDNdevice,fromtheLLDNPANCoordinatorbeforeittransmitsitsdatawithamodifiedCSMA-CAaccessschemeasdescribedin6.2.5.3a5.1.1.4.4.
FromtSlotTxGWtilltSlotEnd,theLLDNPANcoordinatormayusethetimeslot,ifthetimeslotisstillunused.
Dedicatedtimeslots are reserved forasingle device(slotowner).Thisis achievedby setting tSlotTxOwnerandtSlotTxGW to tSlotEnd. A dedicated timeslot allowsthetransmissionof exactly one packet. Dedicatedtimeslotsareonlyusedduringonlinemodeasdescribedin5.1.9.46.10a.4.
Sharedgrouptimeslotswithcontention-basedaccessforeveryalloweddevicecanbeachievedbysettingtSlotTxOwnertotSlotStart.
6.7.4.2 Acknowledgment
To Editor: Insertin6.7.4.2beforethelastparagraphthefollowingtext:
LLDNsuseseveralmethodsfortheacknowledgmentofdatatransmissions.ThetimingsofthesemechanismsaredefinedbythesuperframestructureoftheLLDN.ThetransmissionofanLL-AcknowledgmentframeinresponsetoanLL-dataframeinanLLDNshallcommenceinthesamebidirectionaltimeslotinthenextsuperframe.TheLL-Acknowledgmentframeshallonlybeusedwithbidirectionaltimeslots.
To Editor: Insert before “6.11 DSME” the following subclause 6.10a
6.10a 5.1.9 LLDNtransmissionstates
6.10a.1 5.1.9.1 General
ThetransitionsbetweenthedifferenttransmissionstatesareillustratedinFigure34a.
ResetReset
Figure34a—Transitionsbetweentransmissionstates
Thediscovery state is thefirststep during network setup:the new devicesarediscovered andconfigured inthesecondstep,theconfigurationstate.Afterthesuccessfulcompletionoftheconfigurationstate,thenetworkcangointoonlinestate.Dataandreadingsfromthedevicescanonlybetransmittedduringonlinestate.Inordertoreconfigureanetwork,theconfigurationstatecanbestartedagain.
6.10a.2 5.1.9.2 Discoverystate
TheDiscoverystateisthefirststepduringnetworksetuporfortheadditionofnewdevicestoanexistingnetwork.
IntheDiscoverystate,thesuperframecontainsonlythetimeslotforthebeacondescribedin5.1.1.6.26.2.6a.2andtwomanagementtimeslots,onedownlinkandoneuplink(5.1.1.6.36.2.6a.3).
AnewdevicescansthedifferentchannelsuntilitdetectsanLLDNPANcoordinatorsendingbeaconsthatindicateDiscoverystate.
IfanewdevicereceivedabeaconindicatingDiscovery state,itattemptstoaccessthemediumintheuplinkmanagementtimeslotinaccordancewith5.1.1.4.46.2.5.3ainordertosendaDiscoverResponseframetotheLLDNPANcoordinator.TheDiscoverResponseframeisdescribedin5.3.10.17.5.11a.TheDiscoverResponseframecontainsthecurrentconfigurationofthedevice.ThenewdeviceshallrepeatsendingtheDiscoverResponseframeuntilitreceivesanacknowledgmentframeforitortheDiscoverystateisstoppedbytheLLDNPANcoordinator.Theacknowledgmentframeisdescribedin5.2.2.5.47.3.4a.4.
TheLLDNcoordinatorchangesfrom theDiscoverystate to theConfiguration stateifit didnot receiveanyDiscoverResponseframeswithinmacLLDNdiscoveryModeTimeoutseconds.
Figure34billustratestheDiscoverystate.
LLDNCoordinatorLLDNDevice
SubmissionPage 1Michael Bahr, Siemens AG
July, 2015 IEEE P802.15-15/245r1
StartDiscoverystate
ReceivedaDiscoverResponse
Frame, prepareAck
Beacon
Discover ResponseFrame
BeaconAckFrame
prepareResponse
the currentdeviceconfiguration
Resynchronizes
SubmissionPage 1Michael Bahr, Siemens AG
July, 2015 IEEE P802.15-15/245r1
Figure34b—FlowdiagramofDiscoverystate
6.10a.3 5.1.9.3 Configurationstate
TheConfigurationstateisthesecondstepduringnetworksetup.Itisalsousedfornetworkreconfiguration.
IntheConfigurationstate,thesuperframecontainsonlythetimeslotforthebeacondescribedin5.1.1.6.26.2.6a.2andtwomanagementtimeslots,onedownlinkandoneuplinkasdescribedin5.1.1.6.3.6.2.6a.3.
Ifadevicereceivedabeaconindicatingconfigurationstate,ittriestogetaccesstothetransmissionmediumintheuplinkmanagementtimeslotinordertosendaConfigurationStatusframetotheLLDNPANcoordinator.TheConfigurationStatusframeisdescribedin5.3.10.27.5.11b.TheConfigurationStatusframecontainsthecurrentconfigurationofthedevice.ThenewdeviceshallrepeatsendingtheConfigurationStatusframeuntilitreceivesaConfigurationRequestframeforitortheConfigurationstateisstoppedbytheLLDNPANcoordinator.TheConfigurationRequestframeisdescribedin5.3.10.37.5.11c.TheConfigurationRequestframecontainsthenewconfigurationforthereceivingdevice.Aftersuccessfullyreceivingthe
ConfigurationRequestframe,thedevicesendsanacknowledgmentframetotheLLDNPANcoordinator.Theacknowledgmentframeisdescribedin5.2.2.5.47.3.4a.4.
Figure34cillustratestheConfigurationstate.
LLDNCoordinatorLLDNDevice
SubmissionPage 1Michael Bahr, Siemens AG
July, 2015 IEEE P802.15-15/245r1
StartConfigurationstate
ReceivedaConfigurationStatusFrame,
PrepareConfigurationRequestFrame
Beacon
ConfigurationStatusFrameBeacon
ConfigurationRequestFrameBeacon
AckFrame
SynchronizeandprepareStatus
Framethatcontains
the currentdeviceconfiguration
Resynchronizes
ReceivedtheConfigurationRequestFramewith
thenewconfiguration,prepare AckFrame
Resynchronizes
SubmissionPage 1Michael Bahr, Siemens AG
July, 2015 IEEE P802.15-15/245r1
Figure34c—FlowdiagramofConfigurationstate
6.10a.4 5.1.9.4 Onlinestate
UserdataisonlysentduringOnlinestate.Thesuperframestartswithabeaconandisfollowedbyseveraltimeslots.ThedevicescansendtheirdataduringthetimeslotsassignedtothemduringtheConfigurationstate.Thedifferenttypesoftimeslotsaredescribedin5.1.1.66.2.6a.
TheexistenceandlengthofmanagementtimeslotsintheOnlinestatearecontainedintheConfigurationRequestframe.
ThesuccessfulreceptionofdataframesbytheLLDNPANcoordinatorisacknowledgedintheGroupAcknowledgment bitmapofthebeacon frame ofthe next superframedescribed in5.2.2.5.27.3.4a.2orina separateDataGroupAcknowledgmentframedepictedinFigure48h.Thisisthecaseforbothuplinktimeslotsandbidirectionaltimeslotsifthetransmissiondirectionisuplink.Figure34dillustratesanexampleoftheOnlinestateforuplinktransmissions.Inthisexample,thenetworkhasthreededicatedtimeslots,andLLDNdevice2isassignedtotimeslot2.
Ifretransmissiontimeslotsareconfigured(i.e.,macLLDNnumRetransmitTS0),theretransmissionslotsareassignedtotheownersofthefirstmacLLDNnumRetransmitTSwiththecorrespondingbitinthegroupacknowledgmentbitmapsettozero.EachLLDNdeviceshallexecutethealgorithmasillustratedinFigure34einordertodetermineitsretransmissiontimeslot.TheLLDNPANcoordinatorhastoexecuteasimilaralgorithminordertodeterminethesendersoftheframesintheretransmissionslots.
LLDNCoordinatorLLDNDevice2(uplink)
SubmissionPage 1Michael Bahr, Siemens AG
July, 2015 IEEE P802.15-15/245r1
Tim
StartOnlinestate
ReceivedaDataFrame,setAck
inBeacon
ReceivedaDataFrame,setAck
inBeacon
Beacon
DataFrametoLLDN Device1(uplink)
DataFrame
DataFrame to LLDNDevice3(uplink)
Beacon(withacknowledgements)
DataFrametoLLDNDevice1(uplink)
DataFrame
DataFrametoLLDNDevice3(uplink)
Beacon(withacknowledgements)
SynchronizeandprepareaDataFrame
ResynchronizeandprepareaDataFrame
Resynchronizes
SubmissionPage 1Michael Bahr, Siemens AG
July, 2015 IEEE P802.15-15/245r1
Figure34d—FlowdiagramofOnlinestateforLLDNdevices(uplink)
Ack[i]representstheuplinksuccessandmapstothebitb(i1)inthegroupacknowledgmentbitmapasillustrated in Figure 48e. Assumingthat the LLDN device hasbeen assigned to uplink timeslottimeslot“s,”Ack[s]representstheuplinksuccessofthatLLDNdevice.
IfthedatatransmissionoftheLLDNdevicehasfailedandhasnotbeenacknowledged,thatis,ack[s]iszero(i.e.,false),theLLDNdevicedeterminesthenumberoffailedtransmissionsinprevioustimeslotsexcludingretransmission timeslots.Thisnumber offailedtransmissions, NFT, is the number ofack[i] equal to 0 (i.e.,false)with(macLLDNnumRetransmitTS+1)i(s1).
AretransmissionispossibleifthenumberoffailedtransmissionsNFTislessthanmacLLDNnumRetransmitTS.TheLLDNdeviceretransmitsitsdatainretransmissiontimeslot(NFT+1).
IfthenumberoffailedtransmissionsNFTisequalorgreaterthanmacLLDNnumRetransmitTS,aretransmissionisnotpossible.
The successfulreceptionof dataframes byLLDNdevices assignedtobidirectionaltimeslots (transmissiondirectionisdownlink) isacknowledgedbyanexplicitacknowledgmentframe bythecorrespondingLLDNdevicesinthefollowingsuperframe.ThismeansthataftersettingtheTransmissionDirectionbitinthebeacondescribedin5.2.2.57.3.4atodownlinkandsendingadataframetooneormoreLLDNdevices,theLLDNPANcoordinatorshallsettheTransmissionDirectionbittouplinkinthedirectlyfollowingsuperframe.LLDNdevicesassignedtobidirectionaltimeslotsthathavesuccessfullyreceivedadataframefromtheLLDNPANcoordinatorduringtheprevioussuperframeshallsendanacknowledgmentframetotheLLDNPANcoordinator.LLDNdevicesthatdidnotreceiveadataframefromtheLLDNPANcoordinatormaysenddataframestothe LLDNPAN coordinatorduring thissuperframe with Transmission Direction bitsettouplink.Figure34fillustratestheOnlinestatewithLLDNdevicesassignedtobidirectionaltimeslots.Inthisfigure,thenetworkhasthreededicatedbidirectionaltimeslots,andLLDNdevice2isassignedtotimeslot2.
Figure34e—RetransmissionSlotAlgorithm
LLDNDevice2(bidirectional)
SubmissionPage 1Michael Bahr, Siemens AG
July, 2015 IEEE P802.15-15/245r1
StartOnline
Synchronize
SubmissionPage 1Michael Bahr, Siemens AG
July, 2015 IEEE P802.15-15/245r1
ReceivedDataFrameand
prepareAckFrameResynchronize
SubmissionPage 1Michael Bahr, Siemens AG
July, 2015 IEEE P802.15-15/245r1
Tim
Receiveda
set AckinBeacon
Resynchronizes
SubmissionPage 1Michael Bahr, Siemens AG
July, 2015 IEEE P802.15-15/245r1
Figure34f—FlowdiagramofOnlinestateforLLDNdevices(bidirectional)
SubmissionPage 1Michael Bahr, Siemens AG
July, 2015 IEEE P802.15-<doc#>
7.2.1 5.2.1.1 FrameControlfield
Change7.2.1 5.2.1.1 asindicated:
The Frame Control field for frames other than the LLDN frame, Multipurpose frame, Fragment frame, and Extended frameshall be formatted as illustrated in Figure 87. The Frame Control fields for LLDN frame, the Multipurpose frame, andExtended frame are specified in 5.2.2.5.17.3.4a.1, 7.3.5, and 7.3.6, respectively.
7.2.1.1 5.2.1.1.1FrameTypefield
ChangeTable52asindicated:
Table52—ValuesoftheFrameTypefield
Change the third paragraph of 7.2.1.8 5.2.1.1.6 and Table 7as follows:
7.2.1.8 5.2.1.1.6 DestinationAddressingModefield
If the Frame Type field does not specify an LLDN frame or Multipurpose frame, and the Source Addressing and Destination Addressing Mode fields are set to zero, and the PAN ID Compression field is set to one, the Frame Version field (described in 7.2.1.9) shall be set to 0b10.
Table73—ValidvaluesoftheDestinationAddressingModeandSourceAddressingModefields
Addressingmodevalueb1b0 / Description00 / PANIdentifierandAddressfieldsarenotpresent.
01 / Address field contains an 8-bit simple address.Reserved
10 / Addressfieldcontainsashortaddress(16bit).
11 / Addressfieldcontainsanextendedaddress(64bit).
7.2.1.9 5.2.1.1.7 FrameVersionfield
Change in 7.2.1.9 5.2.1.1.7 the Table8 as follows:
Table 8—Frame Version field values
Insertbefore“7.3.5 Multipurpose frame format” 5.2.3 thefollowingsubclause7.3.4a5.2.2.5:
7.3.4a 5.2.2.5 LowlatencyCommand F(LLDN) frameformat
7.3.4a.1 5.2.2.5.1 GeneralLLDNframeformat
ThegeneralLLDNframeshallbeformattedasillustratedinFigure48a.
Octets:1 / 0/1 / 0/1/5/6/10/14 / variable / 2FrameControl / SequenceNumber / AuxiliarySecurityHeader / FramePayload / FCS
MHR / MACpayload / MFR
Figure48a—GeneralLLframeformat
TheorderofthefieldsoftheLLDNframeshallconformtotheorderofthegeneralMACframeasillustratedinFigure35.
Foursubframetypesaredefined:LLBeacon,LL-data,LL-Acknowledgment,andLL-MACcommand.Thesesubframetypesarespecifiedin5.2.2.5.27.3.4a.2,5.2.2.5.37.3.4a.3,5.2.2.5.47.3.4a.4,and5.2.2.5.57.3.4a.5,respectively.
TheFrameControlfieldcontainsinformationdefiningthesubframetypeoftheLLDNframe.TheFrameControlfieldshallbeformattedasillustratedinFigure48b.
Bits:0–2 / 3 / 4 / 4 / 6–7FrameType / SecurityEnabled / FrameVersion / ACKRequest / SubFrameType
Figure48b—FormatoftheFrameControlfield(LLDNframe)
NOTE1—TheLLDNframewillberejectedbydevicescomplianttoIEEEStd802.15.4-2011sincetheFrameTypevalueislistedas“reserved”byIEEEStd802.15.4-2011.ThepositionoftheFrameTypeshouldnotbechangedinfutureversionsoftheprotocol.
TheFrameTypefieldshallcontainthevaluethatindicatesanLLDNframe,asshowninTable2.
NOTE2—TheFrameTypefieldcorrespondstotheFrameTypefieldofthegeneralMACframeformatin7.2 5.2.1 inmeaningandposition.TheframetypeforLLDNframesallowsefficientrecognitionofLLDNframeswithaFrameControlfieldof1octet,butallowstheusageofallotherMACframeswithinthesuperframestructureofanLLDN.
The SecurityEnabledfieldis1bitinlength,anditshallbesettooneiftheframeisprotectedbytheMACsublayerorsettozerootherwise.TheSequenceNumberfieldandtheAuxiliarySecurityHeaderfieldoftheMHRshallbepresentonlyiftheSecurityEnabledfieldissettoone.
The FrameVersionfieldspecifiestheversionnumbercorrespondingtotheframe.ThisfieldshallbesettozerotoindicateaframecompatiblewithIEEEStd802.15.4.Avalueofoneshallbereservedforfutureuse.
TheACKRequestfieldspecifieswhetheranacknowledgmentisrequiredfromtherecipientdeviceonreceiptofadataorMACcommandframe.Ifthisfieldissettoone,therecipientdeviceshallsendanacknowledgmentframeonlyif,uponreception,theframepassesthethirdleveloffilteringasdescribedin6.7.2 5.1.6.2. Ifthisfieldissettozero,therecipientdeviceshallnotsendanacknowledgmentframe.
TheFrameSubtypefieldindicatesthetypeoftheLLDNframe.ItshallbesettooneofthevalueslistedinTable3c.
Table3c—ValuesofFrameSubtypefield(LLDNframe)
FrameSubtypevalueb7b6 / Description00 / LL-Beacon
01 / LL-Data
10 / LL-Acknowledgment
11 / LL-MACcommand
TheSequenceNumberfieldspecifiesthesequenceidentifierfortheframe.TheSequenceNumberfieldshallbepresentonlyiftheSecurityEnabledfieldissettoone.
TheAuxiliarySecurityHeaderfieldhasavariablelengthandspecifiesinformationrequiredforsecurityprocessing,includinghowtheframeisactuallyprotected(securitylevel)andwhichkeyingmaterialfromtheMACsecurityPIBisused(referto7.59.5).ThisfieldshallbepresentonlyiftheSecurityEnabledfieldissettoone.Fordetailsonformatting,referto7.49.4.
TheFramePayloadfieldhasavariablelengthandcontainsinformationspecifictoindividualsubframetypesofanLLDNframe.
7.3.4a.2 5.2.2.5.2 LLBeaconframeformat
TheLLBeaconframeissentduringthebeaconslotineverysuperframe.TheLLBeaconframeshallbeformattedasillustratedinFigure48c.
Octets:1 / 0/1 / 0/1/5/6/10/14 / 1 / 1 / 1 / 1 / 0/1 / variable / 2
FrameControl / SequenceNumber / AuxiliarySecurityHeader / Flags / LLDNPAN
coordina-torIDfield / ConfigurationSequenceNumber / TimeslotSize / NumberofBaseTimeslotsinSuperframe / GroupAcknow-ledgment / FCS
MHR / MACPayload / MFR
Figure48c—FormatoftheLLBeaconFrame
TheorderofthefieldsoftheLLBeaconframeshallconformtotheorderofthegeneralLLDNframeasillustratedinFigure48a.
TheLLBeaconframehasashortMHRcontainingtheFrameControlfieldofoneoctet.
IntheFrameControlfield,theFrameTypefieldshallcontainthevaluethatindicatesanLLDNframe,asshowninTable2,andtheFrameSubtypefieldshallcontainthevaluethatindicatesanLLBeaconframe,asshowninTable3c.
TheFlagsfieldcontainscontrolinformation.ThestructureoftheFlagsfieldisshowninFigure48d.
Bits:0–2 / 3 / 4 / 5–7TransmissionState / TransmissionDirection / Reserved / NumberofBase Timeslots perManagementTimeslot
Figure48d—StructureofFlagsfieldofLLBeaconframe
The Transmission Statefield definesthetransmissionstate.Thevaluesforthe differenttransmission statesarespecifiedinTable3d.
Table3d—TransmissionStatesettings
Bits0–2 / TransmissionState000 / OnlineState(describedin5.1.9.46.10a.4)
100 / DiscoveryState(describedin5.1.9.26.10a.2)
110 / ConfigurationState(describedin5.1.9.36.10a.3)
111 / StateReset:Thedevicesresettheirstateofthediscoveryorconfiguration
TheTransmissionDirectionfieldindicatesthetransmissiondirectionofallbidirectionaltimeslotsduringthissuperframe. Ifthe Transmission Directionfieldis settozero,the directionofall bidirectionaltimeslotsis uplink(fromLLDNdevice toLLDNPANcoordinator).IftheTransmissionDirectionfield issettoone,thedirectionofallbidirectionaltimeslotsisdownlink(fromLLDNPANcoordinatortoLLDNdevice).TheTransmissionDirectionfieldisonlyusedinonlinestate.
TheNumberofBaseTimeslotsperManagementTimeslotfieldcontainsthenumberofbasetimeslotspermanagementtimeslot.Thisvalueappliestoboththedownlinkandtheuplinkmanagementtimeslot.Avalueofzeroindicatesthattherearenomanagementtimeslotsavailableinthesuperframe.
TheLLDNPANcoordinatorIDfieldcontainsthe8-bitsimpleaddress(i.e.,macSimpleAddress)oftheLLDNPANcoordinator.
TheConfigurationSequenceNumberfieldcontainsanintegernumberthatidentifies,togetherwiththeLLDNPANcoordinatorID,thecurrentconfigurationoftheLLDN.
TheTimeslotSizefielddefinesthelengthofabasetimeslotthroughthemaximumexpectednumberofoctetsofthedatapayloadofanLL-dataframe.Theactualtimeslotsizeinoctetsiscalculatedas
tTS:=(psp+(m+n)sm+macMinSIFSPeriodsymbols{ifm+naMaxSIFSFrameSize
octets}ormacMinLIFSPeriodsymbols{ifm+naMaxSIFSFrameSizeoctets})/v
withthedescriptionandvaluesforthe2450MHzPHYasanexampleasshowninTable3e.
Table3e—Exampleofasetofparameterandvalues
Variable / Description / Valuefor2450MHzPHYwithnosecurityenabledp / NumberofoctetsofPHYheader / 6octets
m / NumberofoctetsofMACoverhead(MHR+ MFR) / 3octetsforLL-Dataframes
n / Maximumexpectednumberofoctetsofdatapayload / ValueofTimeslotSizefieldofLL-Beaconframe
sp / NumberofsymbolsperoctetinPHYheader / 2symbolsperoctet
sm / NumberofsymbolsperoctetinPSDU / 2symbolsperoctet
v / Symbolrate / 62500symbols/s
TheNumberofBaseTimeslotsinSuperframefieldcontainsanintegernumberthatrepresentsthenumberofbasetimeslotsforLLDNdevicesimmediatelyfollowingthemanagementtimeslotsofthesuperframe(correspondstomacLLDNnumTimeSlots).TheNumberofBaseTimeslotsintheSuperframefieldisonlypresentintheOnlinestate.
TheGroupAcknowledgmentfieldisabitmapoflength(macLLDNnumTimeSlotsmacLLDNnumRetransmitTS)bits,paddedtoamultipleof8bits,asshowninFigure48e,toindicatesuccessfultransmissionsbyLLDNdevicesfromtheprevioussuperframe.Thesizeofthebitmapshallalwaysbeamultipleof8afterpaddingwithadditionalzerosattheendifnecessary.Intheseparategroupacknowledgmentconfiguration,thisfieldisnotpresentintheLLBeacon.TheGroupAcknowledgmentfieldisonlypresentinonlinemode.TheGroupAcknowledgmentfieldcontainsabitfieldwhereeachbitcorrespondstoatimeslotassociatedwithanLLDNdeviceexcludingretransmissiontimeslots.Bitb0oftheGroupAcknowledgementbitmapcorrespondstothefirsttimeslotafterthemacLLDNnumRetransmitTSretransmissiontimeslots,bitb1oftheGroupAcknowledgmentbitmapcorrespondstothesecondtimeslot,andsoon.Abitvalueofonemeansthecorrespondinguplinktransmissionintheprevioussuperframewassuccessful,andabitvalueofzeromeansthecorrespondinguplinktransmissionintheprevioussuperframefailedortherewasnouplinktransmission.Inthelattercase,theLLDNdeviceisallocatedatimeslotforretransmissioninthecurrentsuperframe.Becauseconcatenatedtimeslotsaremultiplesofbasetimeslots,aconcatenatedtimeslotoflengthofnbasetimeslotsshallhavenbitsinthegroupacknowledgmentbitmapatthecorrespondingpositions.Ifthedataframehasbeenreceivedduringasharedgrouptimeslot,allcorrespondingbitsofthissharedgrouptimeslotshallbesetaccordinglyintheGroupAcknowledgmentbitmap.
Bits:0 / 1 / ... / (macLLDNnumTimeSlots –macLLDNnumRetransmitTS
–1) / ...n*8–1
Acknowledgment of
transmissionintimeslot
macLLDNnumRetransmitTS
+1 / Acknowledgment of
transmissionintimeslot
macLLDNnumRetransmitTS
+2 / ... / Acknowledgment oftransmissionintime slotmacLLDNnumTimeSlots / Padding
Figure48e—StructureofGroupAcknowledgmentbitmap
7.3.4a.3 5.2.2.5.3 LL-Dataframeformat
TheLL-Dataframeissentduringonlinemodeindevicetimeslots.TheLL-dataframeshallbeformattedasillustratedinFigure48f.
Octets:1 / 0/1 / 0/1/5/6/10/14 / variable / 2FrameControl / SequenceNumber / AuxiliarySecurityHeader / DataPayload / FCS
MHR / MACPayload / MFR
Figure48f—FormatofLL-Dataframe
TheorderofthefieldsoftheLL-DataframeshallconformtotheorderofthegeneralMACframeasillustratedinFigure35.
TheLL-dataframehasashortMHRcontainingtheFrameControlfieldofoneoctet.
IntheFrameControlfield,theFrameTypefieldshallcontainthevaluethatindicatesanLLDNframe,asshowninTable2,andtheFrameSubtypefieldshallcontainthevaluethatindicatesanLL-dataframe,asshowninTable3c.
ThepayloadofanLL-dataframeshallcontainthesequenceofoctetsthatthenexthigherlayerhasrequestedtheMACsublayertotransmit.
7.3.4a.4 5.2.2.5.4 LL-Acknowledgmentframeformat
TheLL-Acknowledgmentframeissentduringonlinemodeinbidirectionaltimeslots.TheLL-AcknowledgmentframeshallbeformattedasillustratedinFigure48g.
Octets:1 / 0/1 / 0/1/5/6/10/14 / 1 / variable / 2FrameControl / SequenceNumber / AuxiliarySecurity
Header / Acknowledg-
menttype / Acknowledgmentpayload / FCS
MHR / MACpayload / MFR
Figure48g—FormatoftheLL-Acknowledgmentframe
TheorderofthefieldsoftheLL-AcknowledgmentframeshallconformtotheorderofthegeneralLLDNframeasillustratedinFigure48a.
TheLL-AcknowledgmentframehasashortMHRcontainingtheFrameControlfieldofoneoctet.
IntheFrameControlfield,theFrameTypefieldshallcontainthevaluethatindicatesasLLDNframe,asshowninTable2,andtheFrameSubtypefieldshallcontainthevaluethatindicatesanLL-Acknowledgmentframe,asshowninTable3c.
TheAcknowledgmentTypefieldindicatesthetypeofframethatisacknowledgedorthetypeofacknowledgment.PossiblevaluesarelistedinTable3f.
Table3f—Acknowledgmenttypes
Acknowledgedframetype/Acknowledgmenttype / AcknowledgmentpayloadConfigurationRequest / No
Data / No
DataGroupACK / Yes
DiscoverResponse / No
TheAcknowledgmentPayloadfieldisonlyavailableincertainacknowledgmenttypesasdepictedinTable3f.ThestructureandthelengthoftheAcknowledgmentPayloadfielddependsonthevalueoftheAcknowledgmentTypefield.
ThestructureoftheAcknowledgmentPayloadfieldoftheDataGroupACKframeisshowninFigure48h.
b0 / b1 / ... / bM–1Acknowledgementofuplinktransmissionintimeslot1 / Acknowledgementofuplinktransmission intimeslot2 / ... / AcknowledgementofuplinktransmissionintimeslotM
Figure48h—FormatoftheDataGroupACKframe
TheSourceIDfieldshallbean8-bitsimpleaddressthatidentifiesthetransmittingLLDNPANcoordinator.
Thesizeofthebitmapshallbeequaltothesmallestmultipleof8thatisgreaterthanorequaltothenumberoftimeslotsusedforuplinktransmissionsbytheLLDNdevices.
TheGroupAckFlagsfieldisabitmapofsizeequaltothesmallestmultipleof8thatisgreaterthanorequaltothenumberofuplinktimeslotsthatindicatesthestatesoftransmissionsoftheLLDNdevicesintheuplinktimeslotsofthecurrentsuperframe.Abitsettooneindicatesthefactthatthecoordinatorreceivedthedataframesuccessfullyinthecorrespondingtimeslot.Avalueofzeromeans,thatthecoordinatorfailedinreceivingadataframeinthecorrespondingslotfromoftheLLDNdevice.
7.3.4a.5 5.2.2.5.5 LL-MACCommandframeformat
TherearedifferenttypesofLL-MACCommandframessharingacommon,generalstructure,differingonlyattheCommandPayload.TheLL-MACcommandframeshallbeformattedasillustratedinFigure48i.
Octets:1 / 0/1 / 0/1/5/6/10/14 / 1 / variable / 2FrameControl / SequenceNumber / AuxiliarySecurity
Header / Command
FrameIdentifier / CommandPayload / FCS
MHR / MACpayload / MFR
Figure48i—FormatoftheLL-MACCommandframe
TheorderofthefieldsoftheLL-MACCommandframeshallconformtotheorderofthegeneralLLDNframeasillustratedinFigure48a.
TheLL-MACcommandframehasashortMHRcontainingtheFrameControlfieldofoneoctet.
IntheFrameControlfield,theFrameTypefieldshallcontainthevaluethatindicatesanLLDNframe,asshowninTable2,andtheFrame SubtypefieldshallcontainthevaluethatindicatesanLL-MACcommandframe,asshowninTable3c.
TheCommandFrameIdentifierfieldidentifiestheMACcommandbeingused.ThisfieldshallbesettooneofthenonreservedvalueslistedinTable5.
TheCommandPayloadfieldcontainstheMACcommanditself.Theformatsoftheindividualcommandsaredescribedin5.3.107.5.11a-7.5.11f.TheCommandPayloadfieldisofvariablelengthandcontainsdataspecifictothedifferentcommandframetypes.
Note to Editor: The LowLatencyNetworkInformation IE (0x20) of “5.2.4.2 Header Information Elements” (15.4e) has been omitted.
Note to Editor: The Group ACK IE (0x1f) of “5.2.4.2 Header Information Elements” (15.4e) and described in 5.2.4.12 “Group ACK IE” has been omitted.
7.5 5.3 MAC Ccommands frames
To Editor: Change in 7.5 5.3 the first paragraph and Table 50 as follows. Not all lines are given in Table 50:
The MAC commands are listed in Table 505along with their associated command identifier. All FFDs shallbe capable of transmitting and receiving all MAC command with Comamnd Identifier field of values 0x01–0x08, with the exception of the GTS Request command, while the requirements for an RFD are indicated byan “X” in the table. An FFD supporting one of TRLE, LLDN, DSME, RIT or DBS options shall support theassociated MAC commands in the range 0x0d−0x1e as identified by the associated functional group prefix,e.g., “DSME ” for the DSME option.
1Table 505—MAC commands
To Editor: Insert before Clause “7.5.12 DSME Association Request command“ 6 the following subclauses (7.5.11a-7.5.11f5.3.10-5.3.13.3.2):
7.5.11a 5.3.10.1 LL-Discover Response command
7.5.11a.1 5.3.10.1.1 General
The LL-Discover Response command contains the configuration parameters that have to be transmitted to the LLDN PAN coordinator as input for the configuration process in an LLDN.
This command shall only be sent by a device that has received an LL-Beacon (refer to 7.3.4a.25.2.2.5.2) indicating discovery mode as determined through the procedures of the Discovery state as described in 5.1.9.26.10a.2.
All devices shall be capable of transmitting this command, although an RFD is not required to be capable of receiving it.
The command payload of the discover response frame shall be formatted as illustrated in Figure 59a.
Octets: 1 / variableCommand Frame Identifier (defined in
Table 5) / Discovery parameters
Figure 59a—LL-Discover response command MAC payload
7.5.11a.2 5.3.10.1.2 MHR fields
The LL-Discover Response command can be sent using both MAC Command frames described in 7.3.4 5.2.2.4 or LL-MAC Command frames described in 7.3.4a.5. 5.2.2.5.5.
The Frame Type field of the Frame Control field shall contain the value that indicates a MAC command frame, as shown in Table 2.
The Source Addressing Mode field of the Frame Control field shall be set to three (64-bit extended addressing).
The Source Address field shall contain the value of aExtendedAddress.
In the Frame Control field of the LL-MAC Command frames, the Frame Type field shall contain the value that indicates an LL-MAC frame, as shown in Table 2, and the Sub Frame Type field shall contain the value that indicates an LL-MAC Command frame, as shown in Figure 48i.
7.5.11a.3 5.3.10.1.3 Command Frame Identifier field
The Command Frame Identifier field contains the value for the discover response command frame as defined in Table 5.
7.5.11a.4 5.3.10.1.4 Discovery Parameters field
The Discovery Parameters field contains the configuration parameters that have to be transmitted to the LLDN PAN coordinator as input for the configuration process. The discovery parameters consist of the following:
—Full MAC address
—Required timeslot duration, this is defined by the application of the device (e.g., size of payload data)
—Uplink/bidirectional type indicator
7.5.11b 5.3.10.2 Configuration Status Frame
7.5.11b.1 5.3.10.2.1 General
The Configuration Status command contains the configuration parameters that are currently configured at the device as input for the configuration process in an LLDN.
This command shall only be sent by a device that has received an LL-Beacon (described in 7.3.4a.2)5.2.2.5.2) indicating configuration mode as determined through the procedures of the configuration mode described in 5.1.9.36.10a.3.
All devices shall be capable of transmitting this command, although an RFD is not required to be capable of receiving it.
The command payload of the Configuration Status frame shall be formatted as illustrated in Figure 59b.
Octets: 1 / variableCommand Frame (defined in Table 5) / Configuration Parameters
Figure 59b—Configuration Status command MAC payload
7.5.11b.2 5.3.10.2.2 MHR fields
The configuration status command can be sent using both MAC Command frames described in 5.2.2.47.3.4 or LL-MAC Command frames described in 7.3.4a.5.5.2.2.5.5.
7.5.11b.3 5.3.10.2.3 Using MAC Command frames
The Frame Type field of the Frame Control field shall contain the value that indicates a MAC command frame, as shown in Table 2.
The Source Addressing Mode field of the Frame Control field shall be set to one (8-bit short addressing) or three (64-bit extended addressing).
The Source Address field shall contain the value of macSimpleAddress if the Source Addressing Mode field is set to one or aExtendedAddress if the Source Addressing Mode field is set to three.
In the Frame Control field of LL-MAC Command frames, the Frame Type field shall contain the value that indicates an LL-MAC frame, as shown in Table 2, and the Frame Subtype field shall contain the value that indicates an LL-MAC command frame, as shown in Table 3c.
7.5.11b.4 5.3.10.2.4 Command Frame Identifier field
The Command Frame Identifier field contains the value for the configuration status frame as defined in Table 5.
7.5.11b.5 5.3.10.2.5 Configuration Parameters field
The Configuration Parameters field contains the configuration parameters that are currently configured at the device. The configuration parameters consist of the following:
—Full MAC address
—Short MAC address
—Required timeslot duration, this is defined by the application of the device (e.g., size of payload data)