ISO/IEC 29145-2:2014

ISO/IEC 29145-2
Edition 1.0 2014-03
INTERNATIONAL
STANDARD
Information technology – Wireless beacon-enabled energy efficient mesh
network (WiBEEM) standard for wireless home network services –
Part 2: MAC layer
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form
or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from
either IEC or IEC's member National Committee in the country of the requester. If you have any questions about
ISO/IEC copyright or have an enquiry about obtaining additional rights to this publication, please contact the address
below or your local IEC member National Committee for further information.

IEC Central Office Tel.: +41 22 919 02 11
3, rue de Varembé Fax: +41 22 919 03 00
CH-1211 Geneva 20 info@iec.ch
Switzerland www.iec.ch
About the IEC
The International Electrotechnical Commission (IEC) is the leading global organization that prepares and publishes
International Standards for all electrical, electronic and related technologies.

About IEC publications
The technical content of IEC publications is kept under constant review by the IEC. Please make sure that you have the

latest edition, a corrigenda or an amendment might have been published.

IEC Catalogue - webstore.iec.ch/catalogue Electropedia - www.electropedia.org
The stand-alone application for consulting the entire The world's leading online dictionary of electronic and
bibliographical information on IEC International Standards, electrical terms containing more than 30 000 terms and
Technical Specifications, Technical Reports and other definitions in English and French, with equivalent terms in 14
documents. Available for PC, Mac OS, Android Tablets and additional languages. Also known as the International
iPad. Electrotechnical Vocabulary (IEV) online.

IEC publications search - www.iec.ch/searchpub IEC Glossary - std.iec.ch/glossary
The advanced search enables to find IEC publications by a More than 55 000 electrotechnical terminology entries in
variety of criteria (reference number, text, technical English and French extracted from the Terms and Definitions
committee,…). It also gives information on projects, replaced clause of IEC publications issued since 2002. Some entries
and withdrawn publications. have been collected from earlier publications of IEC TC 37,

77, 86 and CISPR.
IEC Just Published - webstore.iec.ch/justpublished

Stay up to date on all new IEC publications. Just Published IEC Customer Service Centre - webstore.iec.ch/csc
details all new publications released. Available online and If you wish to give us your feedback on this publication or
also once a month by email. need further assistance, please contact the Customer Service
Centre: csc@iec.ch.
ISO/IEC 29145-2
Edition 1.0 2014-03
INTERNATIONAL
STANDARD
Information technology – Wireless beacon-enabled energy efficient mesh

network (WiBEEM) standard for wireless home network services –

Part 2: MAC layer
INTERNATIONAL
ELECTROTECHNICAL
COMMISSION
PRICE CODE
U
ICS 35.200 ISBN 978-2-8322-1449-7

– 2 – ISO/IEC 29145-2 © ISO/IEC 2014
CONTENTS
FOREWORD . 5
INTRODUCTION . 6
1 Scope . 7
2 Normative reference . 7
3 Terms, definitions and abbreviations . 7
3.1 Terms and definitions . 7
3.2 Abbreviations . 8
3.3 Conventions . 9
4 Conformance . 10
5 Overview of the WiBEEM technology . 10
6 MAC layer specifications . 10
6.1 General . 10
6.2 MAC layer service specifications . 10
6.2.1 Service overview . 10
6.2.2 MAC data service . 11
6.2.3 MAC management service . 17
6.2.4 Association primitives . 17
6.2.5 Disassociation primitives . 22
6.2.6 Beacon notification primitive . 24
6.2.7 Primitives for reading PIB attributes . 27
6.2.8 RAP management primitives . 28
6.2.9 Primitives for orphan notification . 31
6.2.10 Primitives for resetting the MAC layer . 34
6.2.11 Primitives for specifying the receiver enable time . 35
6.2.12 Primitives for channel scanning . 37
6.2.13 Communication status primitive . 39
6.2.14 Primitives for writing MAC PIB attributes . 41
6.2.15 Primitives for updating the superframe configuration . 42
6.2.16 Primitives for synchronising with a WRC . 45
6.2.17 Primitives for requesting data from a WRC . 47
6.3 MAC frame formats . 49
6.3.1 General . 49
6.3.2 General MAC frame format . 50
6.3.3 Beacon frame format . 52
6.3.4 MAC command frame format . 52
Bibliography . 62

Figure 1 – MAC layer structure . 11
Figure 2 – Message sequence chart describing the MAC data service . 16
Figure 3 – Message sequence chart for association . 22
Figure 4 – Message sequence chart for disassociation . 24
Figure 5 – Message sequence chart for RAP allocation initiated by a device . 31
Figure 6 – Message sequence chart for RAP deallocation initiated by a device and the
WMC . 31

ISO/IEC 29145-2 © ISO/IEC 2014 – 3 –
Figure 7 – Beacon lost (orphan notification) message sequence chart . 33
Figure 8 – Message sequence chart for updating the superframe configuration . 45
Figure 9 – Message sequence chart for synchronising to a WRC in a beacon-enabled
WPAN . 47
Figure 10 – Message sequence chart for requesting data from the WRC. 49
Figure 11 – General MAC frame format . 50
Figure 12 – Beacon frame format . 52

Table 1 – MLDE-DATA.request parameters . 12
Table 2 – MLDE-DATA.confirm parameters . 13
Table 3 – MLDE-DATA.indication parameters . 14
Table 4 – MLDE-ERASE.request parameters . 15
Table 5 – MLDE-ERASE.confirm parameters . 16
Table 6 – Summary of the primitives accessed through the MLME-SAP . 17
Table 7 – MLME-ASSOCIATE.request parameters . 18
Table 8 – MLME-ASSOCIATE.indication parameters . 19
Table 9 – MLME-ASSOCIATE.response parameters . 20
Table 10 – MLME-ASSOCIATE.confirm parameters . 21
Table 11 – MLME-DISASSOCIATE.request parameters . 22
Table 12 – MLME-DISASSOCIATE.indication parameters . 23
Table 13 – MLME-DISASSOCIATE.confirm parameters . 24
Table 14 – MLME-BEACON-NOTIFY.indication parameters . 25
Table 15 – Elements of mesh descriptor . 26
Table 16 – MLME-READ-MIB.request parameters . 27
Table 17 – MLME-READ-MIB.confirm parameters . 28
Table 18 – MLME- RAP-MANAGEMENT.request parameters . 29
Table 19 – MLME-RAP-MANAGEMENT.confirm parameters . 29
Table 20 – MLME-RAP-MANAGEMENT.indication parameters . 30
Table 21 – MLME-BEACON-LOST.indication parameters . 32
Table 22 – MLME-BEACON-LOST.indication parameters . 33
Table 23 – MLME-RESET.request parameters . 34
Table 24 – MLME-RESET.confirm parameters . 35
Table 25 – MLME-RX-ON.request parameters . 35
Table 26 – MLME-RX-ON.confirm parameters . 36
Table 27 – MLME-SCAN.request parameters . 37
Table 28 – MLME-SCAN.confirm parameters . 39
Table 29 – MLME-COMM-RESULT.indication parameters . 40
Table 30 – MLME-WRITE-MIB.request parameters . 41
Table 31 – MLME-WRITE-MIB.confirm parameters . 42
Table 32 – MLME-START.request parameters . 43
Table 33 – MLME-START.confirm parameters . 44
Table 34 – MLME-SYNC.request parameters . 45
Table 35 – MLME-SYNC-LOSS.indication parameters . 46

– 4 – ISO/IEC 29145-2 © ISO/IEC 2014
Table 36 – MLME-INDIRECT-COMM.request parameters . 48
Table 37 – MLME-INDIRECT-COMM.confirm parameters . 48
Table 38 – MAC command frame . 53
Table 39 – Association request command . 53
Table 41 – Association response command . 54
Table 42 – Association status field . 55
Table 43 – Disassociation notification command format . 55
Table 44 – Disassociation reason code . 56
Table 45 – Data request command format . 57
Table 46 – Mesh ID conflict notification command format . 57
Table 47 – Orphan notification command format . 58
Table 48 – Beacon request command format . 58
Table 49 – Co-ordinator realignment command format . 59
Table 50 – CFP request command format . 60
Table 51 – CFP characteristics field format . 60
Table 52 – Rate reconfiguration request format . 60
Table 53 – Data rate . 61
Table 54 – Rate reconfiguration request command format . 61

ISO/IEC 29145-2 © ISO/IEC 2014 – 5 –
INFORMATION TECHNOLOGY –
WIRELESS BEACON-ENABLED ENERGY EFFICIENT MESH NETWORK
(WIBEEM) STANDARD FOR WIRELESS HOME NETWORK SERVICES –

Part 2: MAC layer
FOREWORD
1) ISO (International Organization for Standardization) and IEC (International Electrotechnical Commission) form the
specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in
the development of International Standards. Their preparation is entrusted to technical committees; any ISO and
IEC member body interested in the subject dealt with may participate in this preparatory work. International
governmental and non-governmental organizations liaising with ISO and IEC also participate in this preparation.
2) In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote.
3) The formal decisions or agreements of IEC and ISO on technical matters express, as nearly as possible, an
international consensus of opinion on the relevant subjects since each technical committee has representation
from all interested IEC and ISO member bodies.
4) IEC, ISO and ISO/IEC publications have the form of recommendations for international use and are accepted
by IEC and ISO member bodies in that sense. While all reasonable efforts are made to ensure that the
technical content of IEC, ISO and ISO/IEC publications is accurate, IEC or ISO cannot be held responsible for
the way in which they are used or for any misinterpretation by any end user.
5) In order to promote international uniformity, IEC and ISO member bodies undertake to apply IEC, ISO and
ISO/IEC publications transparently to the maximum extent possible in their national and regional publications.
Any divergence between any ISO/IEC publication and the corresponding national or regional publication
should be clearly indicated in the latter.
6) ISO and IEC provide no marking procedure to indicate their approval and cannot be rendered responsible for
any equipment declared to be in conformity with an ISO/IEC publication.
7) All users should ensure that they have the latest edition of this publication.
8) No liability shall attach to IEC or ISO or its directors, employees, servants or agents including individual experts
and members of their technical committees and IEC or ISO member bodies for any personal injury, property
damage or other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees)
and expenses arising out of the publication of, use of, or reliance upon, this ISO/IEC publication or any other IEC,
ISO or ISO/IEC publications.
9) Attention is drawn to the normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
10) Attention is drawn to the possibility that some of the elements of this International Standard may be the subject of
patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
International Standard ISO/IEC 29145-2 was prepared by subcommittee 25: Interconnection
of information technology equipment, of ISO/IEC joint technical committee 1: Information
technology.
The list of all currently available parts of the ISO/IEC 29145 series, under the general title
Information technology – Wireless beacon-enabled energy efficient mesh network (WiBEEM)
for wireless home network services, can be found on the IEC web site.
This International Standard has been approved by vote of the member bodies, and the voting
results may be obtained from the address given on the second title page.
This publication has been drafted in accordance with the ISO/IEC Directives, Part 2.

– 6 – ISO/IEC 29145-2 © ISO/IEC 2014
INTRODUCTION
This International Standard specifies the WiBEEM (Wireless Beacon-enabled Energy Efficient
Mesh network) protocol, which provides low-power-consuming mesh network functions by
enabling the “beacon mode operation”. WiBEEM is based on IEEE 802.15.4 standard with
additional upper layer protocols and a specific usage of the MAC layer protocol. Through the
novel use of beacons, WiBEEM technology achieves longer battery life, larger network
support, quicker response, enhanced mobility and dynamic reconfiguration of the network
topology compared with other protocols such as ZigBee.
In the beacon mode, Beacon information propagates over the entire mesh network nodes
during the BOP (Beacon-Only Period) of the superframe structure without any beacon
conflicts by utilising a smart beacon scheduling technique in the BOP. It also provides
location information about moving devices without spending extra time running a positioning
and locating algorithm by using RSSI (Received Signal Strength Indication). These features
allow the WiBEEM protocol to be widely used for wireless home network services in the
ubiquitous network era.
One of the key features of the WiBEEM protocol is that it has a special time interval called
BOP (Beacon-Only Period) in the superframe structure that allows more than two beacons to
be transmitted. This unique time period is located at the beginning of the Superframe.
Because the BOP does not use the CSMA/CA mechanism, the network will not work properly
in the beacon mode unless an appropriate algorithm is applied. This algorithm needs to
manage and control multiple beacons in a single superframe. The solution is the Beacon
Scheduling method applied in the BOP to avoid collisions among beacons, providing
synchronisation among all the nodes of the entire mesh network.
For the network layer, the NAA (Next Address Available) mechanism, which is a short address
allocation algorithm, has been adopted to provide an efficient way of utilising the complete 16-
bit address space. The NAA algorithm does not limit the maximum number of children nodes
that a node of a mesh network can have. Since the number of children nodes is unlimited, the
NAA mechanism allows the WiBEEM protocol to be used not only for home network services,
but also for community services. WiBEEM can be used where high network expandability
through efficient use of short address spaces, device mobility and end-to-end QoS are
required.
This part of the standard ISO/IEC 29145 specifies the Medium Access Control (MAC) layer of
the WiBEEM protocol.
ISO/IEC 29145-2 © ISO/IEC 2014 – 7 –
INFORMATION TECHNOLOGY –
WIRELESS BEACON-ENABLED ENERGY EFFICIENT MESH NETWORK
(WIBEEM) STANDARD FOR WIRELESS HOME NETWORK SERVICES –

Part 2: MAC layer
1 Scope
This part of ISO/IEC 29145 specifies the MAC of the WiBEEM (Wireless Beacon-enabled
Energy Efficient Mesh network) protocol for wireless home network services that supports a
low power-consuming wireless mesh network as well as device mobility and QoS.
2 Normative reference
The following documents, in whole or in part, are normatively referenced in this document and
are indispensable for its application. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any
amendments) applies.
ISO/IEC 29145-1:2014, Information technology – Wireless beacon-enabled energy efficient
mesh network (WiBEEM) for wireless home network services – Part 1: PHY layer
IEEE 802.15.4:2003, IEEE Standard for Information technology – Telecommunications and
information exchange between systems – Local and metropolitan area networks – Specific
requirements – Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY)
Specifications for Low-Rate Wireless Personal Area Networks (LR-WPANs)
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 29145-1, as
well as the following apply.
3.1.1
association
service used to establish the membership of a device in a wireless mesh network
3.1.2
co-ordinator
wireless device configured to provide synchronisation services through the transmission of
beacons
Note 1 to entry: If a co-ordinator is the principal controller of a wireless mesh network, it is called the WMC
(WiBEEM Mesh Co-ordinator).
3.1.3
device
entity containing an implementation of the WiBEEM applications, NWK, MAC and physical
interface to the wireless medium

– 8 – ISO/IEC 29145-2 © ISO/IEC 2014
3.1.4
disassociation
service that removes an existing association
3.1.5
frame
data format of aggregated bits from a medium access control (MAC) layer entity transmitted in
a specified sequence
3.1.6
logical channel
abstract representation of a communications link independent of the physical implementation
Note 1 to entry: Defines "logical channel" as it is used this International Standard.
3.1.7
mobile device
device that uses network communications while in motion
3.1.8
orphaned device
device that has lost its parent node with its associated mesh network
3.1.9
packet
format of aggregated bits transmitted in a specified sequence across the physical medium
3.1.10
payload data
contents of a data message that is being transmitted
3.1.11
personal operating space
space of typically about 10 m around a person or an object, no matter whether this person or
object is stationary or in motion
3.1.12
protocol data unit
unit of data exchanged between two peer entities
3.1.13
service data unit
information delivered as a unit through a service access point (SAP)
3.2 Abbreviations
The following acronyms and abbreviations are used in this standard. They are commonly used
in other industry publications.
BI Beacon Interval
BN Beacon Number
BO Beacon Order
BOP Beacon Only Period
BSN Beacon Sequence Number
BTTSL Beacon Transmit Time Slot Length
CAP Contention Access Period
ISO/IEC 29145-2 © ISO/IEC 2014 – 9 –
CFP Contention-Free Period
CRC Cyclic Redundancy Check
CSMA-CA Carrier Sense Multiple Access With Collision Avoidance
DSN Data Sequence Number
ED Energy Detection
ID Identifier
IFS Interframe Space or Spacing
LIFS Long Interframe Spacing
LQ Link Quality
LQI Link Quality Indication
LR-WPAN Low-Rate Wireless Personal Area Network
MAC Medium Access Control
MFR MAC Footer
MHR MAC Header
MIB MAC Information Base
MLME MAC Layer Management Entity
MLME-SAP MAC Layer Management Entity-Service Access Point
MPDU MAC Protocol Data Unit
MSDU MAC Service Data Unit
NAA Next Address Available
PDU Protocol Data Unit
PHY Physical Layer
PIB PAN Information Base
PLME Physical Layer Management Entity
PLME-SAP Physical Layer Management Entity-Service Access Point
POS Personal Operating Space
PQP Prioritised QoS Period
QoS Quality of Service
RAP Reservation-based Access Period
RSSI Received Signal Strength Indication
RX Receive or Receiver
SAP Service Access Point
SD Superframe Duration
SDL Specification and Description Language
SDU Service Data Unit
SO Superframe Order
WED WiBEEM End Device
WiBEEM Wireless Beacon-enabled Energy Efficient Mesh network
WMC WiBEEM Mesh Co-ordinator
WRC WiBEEM Routable Co-ordinator
3.3 Conventions
All the italicized words used in this standard represent relevant constants defined and stored
in the MIB (Management Information Base) of each layer.

– 10 – ISO/IEC 29145-2 © ISO/IEC 2014
4 Conformance
A wireless device that claims conformance to this standard shall implement all the primitives
that are specified in 6.2 and the MAC frame formats in 6.3. Each WiBEEM device shall be
able to act as a WMC, a WRC and a WED. When operating in the role of a WMC it shall act
as specified in 5.3.2 of ISO/IEC 29145-1:2014, when operating in the role of a WRC, it shall
act as specified in 5.3.3 of ISO/IEC 29145-1:2014, and when operating in the role of a WED, it
shall act as specified in 5.3.3 of ISO/IEC 29145-1:2014.
5 Overview of the WiBEEM technology
Clause 5 of ISO/IEC 29145-1:2014 presents an overview of the WiBEEM technology and the
functionalities of the WiBEEM devices.
6 MAC layer specifications
6.1 General
This clause specifies the MAC layer of this standard. The MAC layer handles all access to the
physical radio channel and is responsible for the following tasks:
– generating network beacons if the device is a co-ordinator;
– synchronising to network beacons;
– supporting the mesh network association and disassociation;
– supporting device security;
– employing the CSMA/CA mechanism for channel access;
– handling and maintaining the RAP mechanism;
– providing a reliable link between two peer MAC entities;
– providing multi-rate operation between PLME and MLME.
Constants and attributes that are specified and maintained by the MAC layer are written in the
text of this clause in italics. Constants have a general prefix of “a”. Attributes have a general
prefix of “mac”.
6.2 MAC layer service specifications
6.2.1 Service overview
The MAC layer services provide an interface between the MAC layer and the PHY layer. The
MAC layer conceptually includes a management entity called MLME. This entity shall provide
the service interfaces through which layer management functions may be invoked. MLME is
also responsible for maintaining a database of managed objects pertaining to the MAC layer.
This database is referred to as the MIB representing the MAC layer information base. The
MAC layer provides two services, accessed through two SAPs:
– MAC data service, accessed through the MAC layer data SAP (MLDE-SAP), and
– MAC management service, accessed through the MLME-SAP.
These two services provide the interface between the MAC and the PHY layers, via the PLDE-
SAP and PLME-SAP interfaces shown in Figure 1. In addition to these external interfaces, an
implicit interface also exists between the two layers.

ISO/IEC 29145-2 © ISO/IEC 2014 – 11 –
MLME-ASSOCIATE.Request
MLME-DISASSOCIATE.Request
MLME-READ-MIB.Request
MLME-CFP-MANAGEMENT.Request
MLME-RESET.Request
MLME-RX-ON.Request
MLME-ASSOCIATE.Indication MLME-ASSOCIATE.Confirm
MLME-SCAN.Request
MLME-DISASSOCIATE.Indication MLME-DISASSOCIATE.Confirm
MLME-WRITE-MIB.Request
MLME-BEACON-HEARD.Indication MLME-READ-MIB.Confirm
MLME-START.Request
MLME-CFP-MANAGAMENT.Indication MLME-CFP-MANAGAMENT.Confirm
MLME-SYNC.Request
MLME-BEACON-LOST.Indication MLME-RESET.Confirm
MLME-INDRIECT-COMM.Request
MLME-COMM-RESULT.Indication MLME-RX-ON.Confirm
MLME-SYNC-LOSS.Indication MLME-SCAN.Confirm
macAckWaitDuration
MLME-ASSOCIATE.Response MLME-WRITE-MIB.Confirm
macAssociationPermit
MLME-BEACON-LOST.Response MLME-START.Confirm
macAutoRequest
MLME-INDIRECT-COMM.Confirm
macBattLifeExt
macBattLifeExtPeriods
macBeaconOrder
macBeaconTxTime
macBeaconPayload
macBeaconPayloadLength
MLDE-DATA.Request macBSN
NWK Layer Entity
MLDE-ERASE.Request macCoordExtendedAddress
macCoordShortAddress
MLDE-SAP MLME-SAP
macDSN
macCFPPermit
macMaxCSMABackoffs
MLDE-DATA.Confirm
macMinBE
MLDE-DATA.Indication
macMeashID
MLDE-ERASE.Confirm
macPromiscuousMode
MAC Layer MLME
macRxOnWhenIdle
macShortAddress
MIB
macSuperframeOrder
macTransactionPersistenceTime
macBeaconOnlyPeriodLength
PLDE-SAP PLME-SAP
macMaxBeaconTxTime
macMyBeaconTxTime
PHY Layer Entity
macMaxBeaconNumber
Figure 1 – MAC layer structure
6.2.2 MAC data service
6.2.2.1 Overview
The MLDE-SAP supports the transport of MAC protocol data units (MPDUs) between peer
MAC entities.
6.2.2.2 MLDE-DATA.request
6.2.2.2.1 Function
The MLDE-DATA.request primitive requests the transfer of a data MSDU from a local MAC
entity to a single peer MAC entity.
6.2.2.2.2 Semantics of the service primitive
The semantics of the MCPS-DATA.request primitive are as follows:
MLDE-DATA.request (
SrcAddrMode,
SrcMeshId,
SrcAddr,
DstAddrMode,
DstMeshId,
DstAddr,
msduLength,
msdu,
msduHandle,
– 12 – ISO/IEC 29145-2 © ISO/IEC 2014
TxOptions
)
Table 1 specifies the parameters for the MLDE-DATA.request primitive.
Table 1 – MLDE-DATA.request parameters
Name Type Valid range Description
The source addressing mode for this primitive and subsequent
MPDU. This value can take one of the following values:
0x00 = no address (addressing fields omitted, see 6.3.2).
SrcAddrMode Integer 0x00 to 0x03
0x01 = reserved.
0x02 = 16-bit short address.
0x03 = 64-bit extended address.
The 16-bit Mesh identifier of the entity to which the MSDU is
SrcMeshId Integer 0x0000 to 0xffff
being transferred.
As specified by
Device The individual device address of the entity to which the MSDU is
SrcAddre theSrcAddrMode
address being transferred.
parameter
The destination addressing mode for this primitive and
subsequent MPDU. This value can take one of the following
values:
0x00 = no address (addressing fields omitted, see 6.3.2).
DstAddrMode Integer 0x00 to 0x03
0x01 = reserved.
0x02 = 16-bit short address.
0x03 = 64-bit extended address.
The 16-bit mesh network identifier of the entity to which the
DstMeshId Integer 0x0000 to 0xffff
MSDU is being transferred.
As specified by the
Device The individual device address of the entity to which the MSDU is
DstAddr DstAddrMode
address being transferred.
parameter
≤ aMaxMAC- The number of octets contained in the MSDU to be transmitted
msduLength integer
FrameSize by the MAC layer entity.
Set of The set of octets forming the MSDU to be transmitted by the
msdu
–
octets MAC layer entity.
The handle associated with the MSDU to be transmitted by the
msduHandle integer 0x00 to 0xff
MAC layer entity.
The 3 bits (b , b , b ) indicate the transmission options for this
0 1 2
MSDU.
0x01 = acknowledged transmission
TxOptions Bitmap 3-bit field
0x02 = RAP transmission
0x04 = Indirect transmission
0x08 = security enabled transmission

6.2.2.2.3 Appropriate usage
The MLDE-DATA.request primitive is generated by a local MAC entity when an MSDU is to be
transferred to a peer MAC entity.
6.2.2.2.4 Effect on receipt
On receipt of the MLDE-DATA.request primitive, the MAC layer entity begins the transmission
of the supplied MSDU.
ISO/IEC 29145-2 © ISO/IEC 2014 – 13 –
6.2.2.3 MLDE-DATA.confirm
6.2.2.3.1 Function
The MLDE-DATA.confirm primitive reports the results of a request to transfer a data MSDU
from a local MAC entity to a single peer MAC entity.
6.2.2.3.2 Semantics of the service primitive
The semantics of the MLDE-DATA.confirm primitive are as follows:
MLDE-DATA.confirm (
msduHandle,
Status
)
Table 2 specifies the parameters for the MLDE-DATA.confirm primitive.
Table 2 – MLDE-DATA.confirm parameters
Name Type Valid range Description
The handle associated with the MSDU being
MsduHandle Integer 0x00 to 0xff
confirmed.
SUCCESS,
TRANSACTION_OVERFLOW,
TRANSACTION_EXPIRED,
CHANNEL_ACCESS_FAILURE,
INVALID_RAP, NO_ACK,
Status Enumeration The status of the last MSDU transmission.
UNAVAILABLE_KEY,
FRAME_TOO_LONG,
FAILED_SECURITY_CHECK,
or
INVALID_PARAMETER
6.2.2.3.3 When generated
The MLDE-DATA.confirm primitive is generated by the MAC layer entity in response to an
MLDE-DATA.request primitive. The MLDE-DATA.confirm primitive returns a status of either
SUCCESS, indicating that the request to transmit was successful, or the appropriate error
code including TRANSACTION_ OVERFLOW, TRANSACTION_EXPIRED,
CHANNEL_ACCESS_FAILURE, INVALID_RAP, NO_ACK, UNAVAILABLE_KEY,
FRAME_TOO_LONG, FAILED_SECURITY_CHECK, or INVALID_PARAMETER.
6.2.2.3.4 Appropriate usage
On receipt of the MLDE-DATA.confirm primitive, the MAC of the initiating device is notified of
the result of its request to transmit. If the transmission attempt was successful, the status
parameter will be set to SUCCESS. Otherwise, the status parameter will indicate the error.
6.2.2.4 MLDE-DATA.indication
6.2.2.4.1 Function
The MLDE-DATA.indication primitive indicates the transfer of an MSDU from the MAC layer to
the local MAC entity.
– 14 – ISO/IEC 29145-2 © ISO/IEC 2014
6.2.2.4.2 Semantics of the service primitive
The semantics of the MLDE-DATA.indication primitive are as follows:
MLDE-DATA.indication (
SrcAddrMode,
SrcMeshID,
SrcAddr,
DstAddrMode,
DstMeshID
DstAddr,
msduLength,
msdu,
mpduLinkQuality,
SecurityUse,
ACLEntry
)
Table 3 specifies the parameters for the MLDE-DATA.indication primitive.
Table 3 – MLDE-DATA.indication parameters
Name Type Valid range Description
The source addressing mode for this primitive
corresponding to the received MPDU. This value can take
one of the following values:
0x00 = no address (addressing fields omitted).
SrcAddrMode Integer 0x00 to 0x03
0x01 = reserved.
0x02 = 16-bit short address.
0x03 = 64-bit extended address.
The 16-bit Mesh identifier of the entity from which the
SrcMeshID Integer 0x0000 to 0xffff
MSDU was received.
Specified by the
Device The individual device address of the entity from which the
SrcAddre SrcAddrMode
address MSDU was received.
parameter
The destination addressing mode for this primitive
corresponding to the received MPDU. This value can take
one of the following values:
0x00 = no address (addressing fields omitted).
DstAddrMode Integer 0x00 to 0x03
0x01 = reserved.
0x02 = 16-bit short device address.
0x03 = 64-bit extended device address.
The 16-bit Mesh identifier of the entity to which the MSDU
DstMeshID Integer 0x0000 to 0xffff
is being transferred.
The individual device address of the entity to which the MSDU is
DstAddr Device address Specified by the DstAddr
being transferred.
The number of octets contained in the MSDU being indicated by
msduLength integer ≤ aMaxMAC-FrameSize
the MAC layer entity.
The set of octets forming the MSDU being indicated by the MAC
msdu Set of octets -
layer entity.
LQI value measured during reception of the MPDU. Lower values
mpduLinkQuality integer 0x00 to 0xff
represent lower LQI.
SecurityUse Boolean TRUE or FALSE The security level purportedly used by the received data frame.
ACLEntry integer 0x00 to 0x08 Parameter Value of ACL macSecurityMode

ISO/IEC 29145-2 © ISO/IEC 2014 – 15 –
6.2.2.4.3 When generated
The MLDE-DATA.indication primitive is generated by the MAC layer and issued to the SSCS
on receipt of a data frame at the local MAC layer entity.
6.2.2.4.4 Appropriate usage
On receipt of the MLDE-DATA.indication primitive, the MAC entity is notified of the arrival of
data at the device.
6.2.2.5 MLDE-ERASE.request
6.2.2.5.1 Function
The MLDE-ERASE.request primitive allows the next higher layer to erase an MSDU from the
transaction queue.
6.2.2.5.2 Semantics of the service primitive
The semantics of the MLDE-ERASE.request primitive are as follows:
MLDE-ERASE.request  (
msduHandle
)
Table 4 specifies the parameters for the MLDE-ERASE.request primitive.
Table 4 – MLDE-ERASE.request parameters
Name Type Valid range Description
The handle of the MSDU to be purged from the transaction
msduHandle Integer 0x00 to 0xff
queue.
6.2.2.5.3 Appropriate usage
The MLDE-ERASE.request primitive is generated by the next higher layer whenever a MSDU
is to be erased from the transaction queue.
6.2.2.5.4 Effect on receipt
On receipt of the MLDE-ERASE.request primitive, the MAC layer attempts to find in its
transaction queue the MSDU indicated by the msduHandle parameter. If an MSDU has left the
transaction queue, the handle will not be found, and the MSDU can no longer be erased. If an
MSDU matching the given handle is found, the MSDU is discarded from the transaction queue,
and the MAC layer issues the MLDE-ERASE.confirm primitive with a status of SUCCESS. If
an MSDU matching the given handle is not found, the MAC layer issues the MLDE-
ERASE.confirm primitive with a status of INVALID_HANDLE.
6.2.2.6 MLDE-ERASE.confirm
6.2.2.6.1 Function
The MLDE-ERASE.confirm primitive allows the MAC layer to notify the next higher layer of the
success of its request to erase an MSDU from the transaction queue.
6.2.2.6.2 Semantics of the service primitive
The semantics of the MLDE-ERASE.confirm primitive are as follows:

– 16 – ISO/IEC 29145-2 © ISO/IEC 2014
MLDE-ERASE.confirm (
msduHandle,
Status
)
Table 5 specifies the parameters for the MLDE-ERASE.confirm primitive.
Table 5 – MLDE-ERASE.confirm parameters
Name Type Valid range Description
The handle of the MSDU requested to be erased from the
msduHandle Integer 0x00 to 0xff
transaction queue.
SUCCESS or The status of the request to be erased an MSDU from the
Status Enumeration
INVALID_HANDLE transaction queue.

6.2.2.6.3 When generated
The MLDE-ERASE.confirm primitive is generated by the MAC layer entity in response to an
MLDE-ERASE.request primitive. The MLDE-ERASE.confirm primitive returns a status of either
SUCCESS, indicating that the erase request was successful, or INVALID_HANDLE, indicating
an error.
6.2.2.6.4 Appropriate usage
On receipt of the MLDE-ERASE.confirm primitive, the next higher layer is notified of the result
of its request to purge an MSDU from the transaction queue. If the erase request was
successful, the status parameter will be set to SUCCESS. Otherwise, the status parameter
will indicate the error.
6.2.2.7 Data service message sequence chart
Figure 2 illustrates a sequence of messages necessary for a successful data transfer between
two devices.
Figure 2 – Message sequence chart describing the MAC data service

ISO/IEC 29145-2 © ISO/IEC 2014 – 17 –
6.2.3 MAC management service
The MLME-SAP allows the transport of management commands between the next higher
layer and the MLME. Table 6 summarises the primitives supported by the MLME through the
MLME-SAP interface. Primitives marked with an (opt) are optional.
Table 6 – Summary of the primitives accessed through the MLME-SAP
Name Request Indication Response Confirm
MLME-ASSOCIATE O O (opt) O (opt) O
MLME-DISASSOCIATE O O O
MLME-BEACON-HEARD O
MLME-READ-MIB O  O
MLME-RAP-MANAGEMENT O (opt) O (opt) O (opt)
MLME-BEACON-LOST O (opt) O (opt)
MLME-RESET O  O
MLME-RX-ON O  O
MLME-SCAN O  O
MLME-COMM-RESULT O
MLME-WRITE-MIB O  O
MLME-START O (opt)  O (opt)
MLME-SYNC O
MLME-SYNC-LOSS O
MLME-INDIRECT-COMM O  O
6.2.4 Association primitives
6.2.4.1 Overview
MLME-SAP association primitives define how a device becomes associated with a WMC or
WRC. All devices shall provide an interface for the request and confirm association primitives.
The indication and response association primitives are optional for a WED.
6.2.4.2 MLME-ASSOCIATE.request
6.2.4.2.1 Function
The MLME-ASSOCIATE.request primitive allows a device to request an association with a
WRC.
6.2.4.2.2 Semantics of the service primitive
The semantics of the MLME-ASSOCIATE.request primitive are as follows:
MLME-ASSOCIATE.request   (
LogicalChannel,
Co-ordAddrMode,
Co-ordMeshId,
Co-ordAddress,
CapabilityInformation,
SecurityEnable
)
Table 7 specifies the parameters for the MLME-ASSOCIATE.request primitive.

– 18 – ISO/IEC 29145-2 © ISO/IEC 2014
Table 7 – MLME-ASSOCIATE.request parameters
Name Type Valid range Description
Selected from the available
The logical channel on which to attempt
LogicalChannel Integer logical channels supported by
association.
the PHY
The WRC addressing mode for this primitive
and subsequent MPDU. This value can take
one of the following values:
Co-ordAddrMode Integer 0x02 to 0x03
2 = 16-bit short address.
3 = 64-bit extended address.
The identifier of the mesh network with which
Co-ordMeshId Integer 0x0000 to 0xffff
to associate.
Device As specified by the Co- The address of the WRC with which to
Co-ordAddress
address ordAddrMode parameter. associate.
Specifies the operational capabilities of the
CapabilityInformation Bitmap –
associating device.
TRUE if security is enabled for this transfer or
SecurityEnable Boolean TRUE or FALSE
FALSE otherwise.
6.2.4.2.3 When generated
This primitive is generated by the next higher layer of an unassociated device and issued to
its MLME to request an association with a WRC. If the device wishes to associate with a WRC
on a beacon enabled mesh network, the MLME may optionally track the beacon of that WRC
prior to issuing this primitive.
6.2.4.2.4 Effect on receipt
On receipt of this primitive, the MLME of an unassociated device first updates
phyCurrentChannel with the value
...