This message will disappear after all relevant tasks have been resolved.

Semantic MediaWiki

There are 1 incomplete or pending task to finish installation of Semantic MediaWiki. An administrator or user with sufficient rights can complete it. This should be done before adding new data to avoid inconsistencies.

1. Introduction

802.15.4 is a widely used communication protocol that enables the creation of Wireless Personal Area Networks (WPAN). As technology continues to evolve, 802.15.4 remains a popular choice for WPAN applications due to its low-power consumption and reliable performance.

Some examples of application domains that use this protocol include:

Home automation: 802.15.4 is used in smart home devices such as smart thermostats, lighting systems, and security systems to enable wireless communication between devices.
Industrial automation: The protocol is used in industrial automation systems to enable wireless communication between sensors, actuators, and other devices.
Healthcare: 802.15.4 is used in healthcare applications such as remote patient monitoring and medical device communication.
Environmental monitoring: The protocol is used in environmental monitoring systems to enable wireless communication between sensors that measure temperature, humidity, and other environmental factors.

The 802.15.4 standard defines two layers that correspond to the Data Link and Physical layers of the OSI model. MAC layer is responsible for managing access to the wireless medium and providing a standardized interface to the upper layers of the protocol stack. The PHY layer is responsible for transmitting and receiving data over the wireless medium, including modulation, coding, and channel selection. This protocol offers a range of modulation options, but the main focus is on O-QPSK, which operates in the 2.4 GHz frequency band and has a bandwidth of 2 MHz. With a data rate of 250kbit/s and a short range of a few dozen meters, it is ideal for low-power applications. Together, these two layers provide a standardized approach to managing low-rate wireless personal area networks, making it easier for devices from different manufacturers to communicate with each other.

The protocol offers two modes: beacon network and non-beacon network mode. The main focus is the non-beacon network mode, which is designed to conserve power by eliminating the need to receive beacons periodically. This makes it an ideal choice for battery-powered devices that require long battery life.

2. 802.15.4 Network

2.1. Device type

There are two types of devices that can be used in a WPAN: Full Function Device (FFD) and Reduced Function Device (RFD).

An FFD is a device that can perform all functions within a WPAN. This includes the ability to act as a PAN coordinator or a coordinator. A PAN coordinator is responsible for creating and managing the WPAN, while a coordinator is responsible for managing communication within a specific area of the WPAN.

On the other hand, an RFD is a device that has limited functionality within a WPAN. It cannot act as a coordinator, and is typically used as an end device that communicates with an FFD. An end device is a device that is located at the edge of the WPAN and communicates with other devices within the network.

2.2. Topology

Overall, the choice of devices and topology depends on the specific requirements of the WPAN. FFD offers greater flexibility and control, while RFDs is simpler and more cost-effective. Similarly, different topologies offer different advantages and limitations, and the choice depends on factors such as range, complexity, and reliability.
In Wireless Personal Area Networks (WPANs), there are various types of topologies that can be used, each with its own advantages and limitations. With these two device types, it is possible to create three topologies:

Star network topology connects devices to a central hub, allowing for easy setup and management, but may be limited by range and hub failure. It is the most secure network topology.
Peer-to-peer topology connects devices directly to each other, without the need for a central hub. This allows for more flexibility in communication and eliminates the risk of a single point of failure. However, it may be more difficult to manage and monitor the network, and the range may be limited by the strength of the signal between devices.
Cluster Tree topology connects devices in a hierarchical structure, with a central node at the top and multiple branches extending out to other nodes. This allows for more complex communication patterns and can provide greater range than a star or peer-to-peer topology. However, it may be more difficult to set up and maintain, and the network may be affected if the central node fails.

2.3. Address type

In 802.15.4, there are two types of addresses used for communication between devices: short addresses and extended addresses.

Short addresses are 16-bit addresses that are generally assigned to devices by the network coordinator. Once assigned by the coordinator, this type of address is suggested rather than the extended address.

Extended addresses are 64-bit addresses that are globally unique and assigned to devices by the manufacturer. Above all, they are used for associating.

Both short and extended addresses can be used for unicast, multicast, and broadcast communication. Unicast communication is between two specific devices, multicast communication is between a group of devices, and broadcast communication is to all devices in the network.

2.4. PAN ID

In an 802.15.4 network, the PAN ID (Personal Area Network Identifier) is a unique identifier that is used to distinguish one network from another. It is a 16-bit value that is assigned to each network and is used by devices to identify which network they belong to.

The PAN ID is used in conjunction with the MAC (Media Access Control) address to create a unique identifier for each device on the network. When a device joins a network, it must be configured with the correct PAN ID to be able to communicate with other devices on the same network.

The PAN ID is important because it allows multiple 802.15.4 networks to coexist in the same physical area without interfering with each other. Devices on different networks with different PAN IDs will be able to communicate with each other, only if the destination PAN ID is set correctly.

2.5. CCA mode

To perform a Clear Channel Assessment (CCA), at least one of these three modes must be used:

CCA mode 1: Energy above Energy Detection (ED) threshold. CCA must report a busy medium upon detecting any energy above the ED threshold. Only this method is implemented in WB and WBA.
CCA mode 2: Carrier detection. CCA must report a busy medium only upon the detection of a signal compliant with the 802.15.4 standard with the same modulation characteristics of the PHY currently in use by the device.
CCA mode 3: Carrier detection and energy above detection energy threshold

There are two metrics that can be used to assess the quality of a channel: Link Quality Indicator (LQI) and Energy Detection (ED).

Link Quality Indicator: LQI is a metric that measures the quality of the received signal. It is used to determine the reliability of the communication link between two devices. LQI is typically measured on a scale of 0 to 255, with higher values indicating better signal quality.

Energy Detection: ED is a metric that measures the energy level on a specific channel. It is used to determine if there is any activity on the channel and to identify potential interference sources. ED is typically measured on a scale of 0 to 255, with lower values indicating lower energy levels.

Both LQI and ED can be used in conjunction with the CCA modes to determine the quality of a channel and to make decisions about when to transmit data.

2.6. CSMA-CA

Carrier Sense Multiple Access with Collision Avoidance (CSMA-CA) is a medium access control algorithm that uses one of the CCA modes defined in 802.15.4 to determine if a channel is clear before transmitting data. In CSMA-CA, the device listens for activity on the channel before transmitting data. If the channel is busy, the device will wait for a random amount of time to avoid collisions before attempting to transmit again.

The CSMA-CA algorithm works as follows:

The device performs a CCA on the channel before transmitting data.
If the channel is busy, the device waits for a random amount of time before attempting to transmit again. The random wait time is chosen to avoid collisions with other devices that may also be waiting to transmit.
If the channel is clear, the device transmits the data.

CSMA-CA is effective in avoiding collisions and ensuring that data is transmitted successfully. However, it may result in increased latency and reduced throughput due to the random wait times.

In IEEE 802.15.4-2015, the backoff durations are controlled by the backoff exponent (BE), with default values of macMinBE set to 3 and macMaxBE set to 5. However, from the Zigbee specification annex D, the recommended default values for macMinBE and macMaxBE are 5 and 8 respectively. These higher values that are recommended by ZigBee provide better joining performance in dense networks where many devices may be responding to a beacon request. The number of backoff (NB) is the number of times the CSMA-CA algorithm was required to back off while attempting the current transmission.

2.7. Different Scans

In 802.15.4, there are five types of scans that can be performed by a device: ED (Energy Detection), Active, Enhanced Active, Passive and Orphan scan.

ED scans involve the device measuring the energy level on a specific channel to determine if there is any activity on that channel. This type of scan is useful for determining the quality of the channel and identifying potential interference sources. This could be used by a prospective PAN coordinator to select a channel on which to operate prior to starting a new PAN.

Active scans involve the device actively transmitting a scan request (Beacon Request frame) to the network coordinator and waiting for a response (Beacon frame). The response includes information about the available network, such as the PAN ID, channel, and coordinator address. Active scans are useful when a device is searching for a specific network to join.

Enhanced Active scans involve the device actively transmitting a scan request (Enhanced Beacon Request frame) to the network coordinator and waiting for a response (Enhanced Beacon frame), similar to Active Scan. However, Enhanced Active Scan includes additional information in the scan request, such as the device's capabilities and requirements. This allows the network coordinator to provide a more tailored response, including information about the network's suitability for the device.

Passive scans involve the device listening to network traffic on different channels without actively transmitting any signals. The device captures frames transmitted by other devices to discover existing networks. This method is not useful in non-beacon enabled networks where devices do not periodically broadcast Beacon frames.

Orphan scans are performed by a device that has lost its parent node in a network. The device will perform an orphan scan to relocate its coordinator. The orphan scan involves the device transmitting Orphan Notification frame and waiting for a response from its parent node; Coordinator Realignment frame.

Active, passive, orphan, ED, enhanced active scans can be performed on a specific channel or on all available channels. The choice of scan type and channel depends on the specific use case and the requirements of the device.

2.8. Frame format

Each MAC frame contains a 2-byte Frame Control Field (FCF) at the beginning of the frame. Bits 0-2 of the FCF specify the frame type, which can be one of the following eight types:

Beacon frame (000), used to scan networks
Data frame (001), used to transmit data from higher layers
Acknowledgment frame (010)
MAC command (011), such as, association request, association response, beacon request, data request...
Reserved (100)
Multipurpose (101)
Fragment (110)
Extended (111)

The maximum size for a MAC frame is 127 bytes, including the MAC header, payload, and MAC footer. The size of the MAC header is variable depending on the fields used, such as PANID compression, Sequence Number (SN) suppression, and Information Elements (IEs), the MAC footer is 2 bytes of CRC, and the payload can reach the remaining number of bytes.

The MAC header can include fields such as the frame type, addressing information, sequence number and information elements. The MAC footer includes a Frame Check Sequence (FCS) field, which is used to verify the integrity of the frame.

2.9. Information Element

In simple terms, IEs (Information Elements) are used to convey additional information between two communicating devices. IEs are optional and can be included in MAC frames to provide additional context or functionality.
For example, an IE can be used to provide information about

The capabilities of a device
Supported data rates or power saving features
Support vendor-specific extensions or custom protocols.

There is no maximum header/payload IEs size limit, apart from the 127-byte frame size limit for the O-QPSK PHY. This feature was introduced in the 2015 standard. It is worth mentioning that for MAC 2.0 certification, some tests involving IEs are not mandatory. In the Zigbee R22/R23 standard, frames that use IEs can be in Appendix D.
The following MAC primitives can request including IEs in the transmitted frames associated with these primitives or indicate their reception in the associated MAC frames:

MLME-SCAN.request
MLME-START.request
MLME-BEACON.request
MCPS-DATA.request / MCPS-DATA.confirm / MCPS-DATA.indication
MLME-BEACON-REQUEST.indication
MLME-BEACON-NOTIFY.indication
MLME-COMM-STATUS.indication
MLME-IE-NOTIFY.indication
MLME-PIB.request: macEbHeaderIeList, macEbPayloadIeList, macEbFilteringEnabled, macEbsn, macEbAutoSa...

General MAC frame format

If the IE Present field in the Frame Control field is set to one, the IE field will be present. The IE field is composed of the Header IEs and Payload IEs subfields.
Header IEs, if present, follow the Auxiliary Security Header and are part of the MHR. Header IEs, if present, may require termination. A header termination IE is required prior to the payload IEs because the address space of payload IEs and header IEs is not distinct. Hence it is not possible to detect when the header IEs stop and payload IEs begin.
Payload IEs, if present, follow the MHR and are considered part of the MAC payload, i.e., they may be encrypted. A set of payload IEs may require termination.

Format IE field

Header Termination 1: 0x7E
Header Termination 2: 0x7F
Payload Termination: 0xF

2.10. ACK

The Acknowledgement (ACK) frame is a short frame that is sent by the receiving device to confirm that it has successfully received a data frame from the transmitting device. There are two types of acknowledgement: the Imm-ACK and the Enh-ack. The Imm-ACK consists only of the FCF and the sequence number, whereas the enh-ACK can have as many fields as a data frame. The Imm-ACK frame has the following specifications:

Frame Control Field: The frame control field is set to indicate that the frame is an ACK frame.
Sequence Number: The sequence number of the ACK frame is set to the sequence number of the data frame that it is acknowledging.

The ACK frame is sent immediately after the receiving device successfully receives a data frame. If the transmitting device does not receive an ACK within a specified time period (default 512us), it assumes that the transmission was unsuccessful and will retransmit the data frame, by default there are 3 retries.

2.11. IFS

Interframe Spacing (IFS) is the time interval between two consecutive frames. The IFS can vary depending on the type of frame being transmitted and whether or not an Acknowledgement (ACK) is required. AIFS (Acknowledgement Inter-Frame Spacing), LIFS (Longer Inter-Frame Spacing), and SIFS (Short Inter-Frame Spacing) are different types of IFS used to manage the transmission of frames and acknowledgements between devices.

When a device sends a frame and expects an ACK in return, it uses AIFS between the transmitted frame and the ACK. For the O-QPSK PHY, the AIFS value is equal to SIFS which is equal to 12 symbols (192 microseconds at 2.4 GHz). This allows the device to quickly send the ACK and reduce the overall delay in communication.

When a device sends a frame of up to aMaxSifsFrameSize, it must be followed by SIFS. Frames with lengths greater than aMaxSifsFrameSize must be followed by LIFS of 40 symbols (640 microseconds at 2.4 GHz).

2.12. Primitive categories

The MLME (MAC Sublayer Management Entity) is a sublayer of the MAC layer that is responsible for managing the operation of the MAC layer. The MLME provides a set of management functions that are used to configure and control the behavior of the MAC layer.
The MLME includes functions such as:

Scan
Association
Disassociation
Get a PIB
Set a PIB
Data Poll
Reset
Start

The MCPS (MAC Common Part Sublayer) is a sublayer of the MAC layer that is responsible for managing the transmission and reception of data frames. The MCPS provides a set of functions that are used to send and receive data frames between devices in the network.
The MCPS includes functions such as:

Data
Purge

The IEEE 802.15.4 standard use the concept of primitives to describe the services provided by one layer to the next.

<primitive>.request
<primitive>.indication
<primitive>.response
<primitive>.confirm

The MAC PIB (MAC Protocol Information Base) is a collection of parameters that define the behavior of the MAC layer. The MAC PIB is used by the MAC layer to configure and manage the operation of the network. The MAC PIB includes parameters such as:

PAN ID
Short Address
Extended Address
Mac Association Permit
Mac Auto Request
Mac Beacon Payload

These parameters can be set and modified by the network coordinator or by individual devices in the network depending on the type of parameter.

3. Architecture

3.1. MAC Layer & APIs

The MAC (Media Access Control) layer is an important component of the 802.15.4 protocol, responsible for managing access to the wireless medium and ensuring reliable communication between devices.

The MAC layer in 802.15.4 in both the WB and WBA products provides several APIs (Application Programming Interfaces) for controlling the behavior of the MAC layer. These APIs are used by the upper layers of the protocol stack to send and receive data, manage network resources, and perform other tasks. They implement the MAC primitives described in the previous section. In the following sections the primitive/api name may be used interchangeably.

The MAC sublayer provides two services:

MCPS (MAC Common Part Sublayer) allows the transport of data, also called MAC data service.
MLME (MAC Sublayer Management Entity) allows the transport of management commands between the next higher layer and the MAC layer except for the TX and the RX functionalities, also called MAC management service interfacing.

Summary of the primitives accessed through the MCPS-SAP and MLME-SAP

Name	Request	Indication	Response	Confirm
MCPS-DATA	X	X		X
MCPS-PURGE	X			X
MLME-ASSOCIATE	X	X	X	X
MLME-BEACON-NOTIFY		X
MLME-BEACON	X			X
MLME-BEACON-REQUEST		X
MLME-COMM-STATUS		X
MLME-DISASSOCIATE	X	X		X
MLME-GET	X			X
MLME-ORPHAN		X	X
MLME-POLL	X	X		X
MLME-RESET	X			X
MLME-RX-ENABLE	X			X
MLME-SCAN	X			X
MLME-SET	X			X
MLME-START	X			X
MLME-SYNC-LOSS		X

All the APIs listed hereafter are extracted from the WB product. However, the APIs in both the WB and WBA products are quite similar except for the following differences:

In WB, the APIs start with the prefix "MAC" while for WBA, they start with the prefix "ST_MAC". Example: WB-> MAC_MCPSDataReq, WBA->ST_MAC_MCPSDataReq.
In WBA, the request and response APIs have an extra parameter: MAC_handle * st_mac_hndl, which specifies the MAC instance.
WB products adhere to the 802.15.4-2006 standard, while WBA products adhere to the 802.15.4-2020 standard. Accordingly, some APIs and/or API parameters may differ based on the differences in these two versions of the specifications.
Both products support only the MAC 802.15.4 non-beacon-enabled PAN mode.

The following is a list for the most common status codes that may be returned by the API:

INVALID_PARAMETER: Some of the parameters are not supported or are out of range.
CHANNEL_ACCESS_FAILURE: CSMA-CA algorithm fails.
NO_ACK: No acknowledgment is received when it is expected.
FRAME_TOO_LONG: The length of the frame exceeds the maximum size it can be.
TRANSACTION_EXPIRED: Returned when a response is expected but it was not received within the expected time, or when the critical transaction is not sent out in time.
TRANSACTION_OVERFLOW: Returned when there is no capacity to store another transaction.
NO_BEACON: Returned when active scan did not receive any beacon.
NO_DATA: Returned when the data request is sent but no indirect data is received.

3.1.1. MCPS-DATA

A successful reception and validation of a frame is optionally confirmed with an acknowledgement if requested by the transmitting device. The difference between acknowledged and unacknowledged transmission is illustrated in the following sequence charts.

For unacknowledged data transmissions, the ack_Tx field in the MCPS-DATA.request primitive is set to False. The CSMA-CA algorithm in the MAC layer is used to check for channel availability. If the channel is free, the data frame is transmitted with the Acknowledge Request (AR) field set to 0. When the data is received by the receiving device (Device 2), the MAC layer in Device 2 issues MCPS-DATA.Indication to pass the received data to the NWK layer. The MAC Layer in Device 1 issues MCPS-DATA.Confirm primitive to indicate the transmission status to the NWK layer.

For acknowledged data transmissions, the ack_Tx field in the MCPS-DATA.request primitive is set to True. The CSMA-CA algorithm in the MAC layer is used to check for channel availability. If the channel is free, the data frame is transmitted with the Acknowledge Request (AR) field set to 1. When the data is received successfully by the receiving device (Device 2), the MAC layer in Device 2 issues MCPS-DATA.Indication to pass the received data to the NWK layer. Device 2 also transmits ACK as requested by Device 1. If the ACK is received within macAcResponseWaitTime, the MAC Layer in Device 1 issues MCPS-DATA.Confirm primitive to indicate the success of the transmission.

However, if Device 1 does not receive the ACK, either because Device 2 did not receive the data or because the the ACK frame itself was is not received by Device 1, the MCPS-DATA.Confirm primitive is issued to the NWK layer to indicate transmission failure with the NO_ACK (0xE9) error code.

3.1.1.1. MCPS-DATA.request

This API is used to request the transfer of data to another device.

MAC_Status_t MAC_MCPSDataReq( const MAC_dataReq_t * pDataReq );

The argument of this API:

pDataReq: A pointer to a structure that contains the data request parameters.

MAC_dataReq_t structure parameters:

Parameter	Description	Type	Valid range
msduPtr	Pointer to the MSDU that should be transmitted.	uint8_t*
src_addr_mode	The source addressing mode for this MPDU.	uint8_t	NONE, SHORT, EXTENDED
dst_addr_mode	The destination addressing mode for this MPDU.	uint8_t	NONE, SHORT, EXTENDED
a_dst_PAN_id	The PAN ID of the entity to which the MSDU is being transferred.	uint16_t	0x0000 - 0xFFFF
dst_address	The address of the entity to which the MSDU is being transferred.	MAC_addr_t	As specified by the DstAddrMode parameter
msdu_handle	The handle associated with the MSDU to be transmitted by the MAC sublayer entity.	uint8_t	0x00 - 0xFF
msdu_length	Length of the MSDU that should be transmitted.	uint8_t
ack_Tx	TRUE if acknowledged transmission is used, FALSE otherwise.	uint8_t	TRUE, FALSE
GTS_Tx	Not used on non-beacon-PAN	uint8_t	FALSE
indirect_tx	TRUE if indirect transmission is to be used, FALSE otherwise.	uint8_t	TRUE, FALSE
security_level	The security level to be used. Supports only Security level 0.	uint8_t	TRUE, FALSE
key_id_mode	The mode used to identify the key to be used. Not used in Security level 0.	uint8_t	-
a_key_source	The originator of the key to be used.Not used in Security level 0.	uint8_t[8]	As specified by the KeyIdMode parameter
key_index	The index of the key to be used. Not used in Security level 0.	uint8_t	0x01–0xFF

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.1.2. MCPS-DATA.indication

This API is used to indicate the reception of data from another device.

MAC_Status_t APP_MAC_mcpsDataIndCb( const  MAC_dataInd_t * pDataInd )

The argument of this API:

pDataInd: A pointer to a structure that contains the data indication parameters.

MAC_dataInd_t structure parameters:

Parameter	Description	Type	Valid range
src_addr_mode	The source addressing mode for this primitive corresponding to the received MPDU.	uint8_t	NONE, SHORT, EXTENDED
a_src_PAN_Id	The PAN ID of the entity from which the MSDU was received. Valid only when a source PAN ID is included in the received frame.	uint8_t[2]	0x0000 - 0xFFFF
src_address	The address of the entity from which the MSDU was received.	MAC_addr_t	As specified by the src_addr_mode parameter
dst_addr_mode	The destination addressing mode for this primitive corresponding to the received MPDU.	uint8_t	NONE, SHORT, EXTENDED
a_dst_PAN_Id	The PAN ID of the entity to which the MSDU is being transferred. Set to the receiver’s PAN ID if the PAN ID is not carried in the received frame.	uint8_t[2]	0x0000 - 0xFFFF
dst_address	The address of the entity to which the MSDU is being transferred.	MAC_addr_t	As specified by the dst_addr_mode parameter
msduPtr	Pointer to the set of octets forming the MSDU being indicated by the MAC sublayer entity including payload IEs if present.	uint8_t*	-
msdu_length	The number of octets contained in the MSDU being indicated	uint8_t
mpdu_link_quality	LQI value measured during reception of the MPDU.	uint8_t	0x00 - 0xFF
DSN	The Data Sequence Number of the received Data frame if one was present.	uint8_t	0x00 - 0xFF
a_time_stamp	The time, in symbol periods, at which the data were received	uint8_t[4]	0x00000000 - 0xFFFFFFFF
rssi	The Received Signal Strength Indicator is a measure of the RF power level	uint8_t	0x00 - 0xFF
security_level	The security level to be used. Supports only Security level 0.	uint8_t	TRUE, FALSE
key_id_mode	The mode used to identify the key to be used. Not used in Security level 0.	uint8_t	-
a_key_source	The originator of the key to be used.Not used in Security level 0.	uint8_t[8].	-
key_index	The index of the key to be used. Not used in Security level 0.	uint8_t	-

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.1.3. MCPS-DATA.confirm

This API is used to reports the results of a request to transfer data to another device.

MAC_Status_t APP_MAC_mcpsDataCnfCb( const  MAC_dataCnf_t * pDataCnf );

The arguments of this API are:

pDataCnf: A pointer to a structure that contains the data confirm parameters.

MAC_dataCnf_t structure parameters:

Parameter	Description	Type	Valid range
msdu_handle	The handle associated with the MSDU being confirmed.	uint8_t	0x00 - 0xFF
status	The status of the last MSDU transmission.	uint8_t	SUCCESS, INVALID_ADDRESS, or see status code list above

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.2. MCPS-PURGE

The MCPS-Purge enables the deletion of indirect data from the transaction queue. In the following analysis, three scenarios will be illustrated; one successful and two unsuccessful.

In the first case, MCPS-DATA.Request with indirect_tx set to True and the msdu_handle set to 0x00 is issued. This ID is used to identify the data. Subsequently, MCPS-PURGE.Request primitive with msdu_handle = 0x00 is issued to eliminate the data from the queue. MCPS-PURGE.Confirm is received with status indicating success of the operation. It is important to note that in this sequence, MCPS-DATA.Confirm must not be received.

In the second case, MCPS-PURGE.Request primitive with msdu_handle set to 0x00 is issued. However, since there is no data present in the queue, the MCPS-PURGE.Confirm returns the status INVALID_HANDLE.

In the final case, MCPS-DATA.Request with indirect_tx set to True and the msdu_handle set to 0x00 is issued. Following this, MCPS-PURGE.Request primitive with msdu_handle set to 0x01 is issued. However, since there is no data present with this specific ID in the queue, the MCPS-PURGE.Confirm returns the status INVALID_HANDLE.

3.1.2.1. MCPS-PURGE.request

This API is used to request the next higher layer to purge an MSDU from the transaction queue.

MAC_Status_t MAC_MCPSPurgeReq( const MAC_purgeReq_t * pPurgeReq );

The argument of this API:

pPurgeReq: A pointer to a structure that contains the purge request parameters.

MAC_purgeReq_t structure parameters:

Parameter	Description	Type	Valid range
msdu_handle	The handle of the MSDU to be purged from the transaction queue.	uint8_t	0x00 - 0xFF

3.1.2.2. MCPS-PURGE.confirm

This API is used to notify the next higher layer of the success of its request to purge an MSDU from the transaction queue.

MAC_Status_t APP_MAC_mcpsPurgeCnfCb( const  MAC_purgeCnf_t * pPurgeCnf )

The argument of this API:

pPurgeCnf: A pointer to a structure that contains the purge confirm parameters.

MAC_purgeCnf_t structure parameters:

Parameter	Description	Type	Valid range
msdu_handle	The handle of the MSDU requested to be purged from the transaction queue.	uint8_t	0x00 - 0xFF
status	The status of the last MSDU transmission.	uint8_t	SUCCESS, INVALID_HANDLE

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.3. MLME-ASSOCIATE

The Association primitives enable the process of associating within a PAN. Two scenarios will be illustrated hereafter: one successful and one unsuccessful.
In the successful case, the NWK layer on the device side initiates the association procedure by issuing the MLME-ASSOCIATE.Request primitive. The 802.15.4 MAC on the device side transmits a MAC Association Request to the coordinator. The coordinator responds with an ACK. The acknowledgment to an Association Request command does not mean that the device has associated; it just acknowledges the successful reception of the request. The MAC layer on the coordinator issues MLME-ASSOCIATE.Indication to the NWK layer. A coordinator must allow association only if macAssociationPermit is set to TRUE. In this successful scenario, it is assumed that macAssociationPermit is set to True as the current resources available on the PAN are sufficient to allow another device to associate. Thus, the NWK layer in the coordinator responds with MLME-ASSOCIATE.Response, resulting in the indirect transmission of the MAC Association Response to the Device, i.e. the MAC Layer forms the Association Response message and waits for the device to attempt extracting it. The MAC layer on the device side must attempt to extract the Association Response from the coordinator by sending Data Request command. The coordinator will then transmit the Association Response to the device. On receiving the Association Response, the MAC layer on the device side must issue MLME-ASSOCIATE.Confirm with the status set to SUCCESS to the NWK layer.

In the unsuccessful case, it is assumed that macAssociationPermit is set to False as the current resources available on the PAN are not sufficient to allow another device to associate. The NWK higher layer of the coordinator should inform the MAC sublayer, and the MAC must generate an Association Response command containing Association Status field indicating a failure. When the device extracts the Association Response from the coordinator, it must issue MLME-ASSOCIATE.Confirm with the status set to PAN access denied to the NWK layer.

3.1.3.1. MLME-ASSOCIATE.request

This API is used to request association with a coordinator in a PAN (Personal Area Network).

MAC_Status_t MAC_MLMEAssociateReq( const  MAC_associateReq_t * pAssociateReq );

The argument of this API:

pAssociateReq: A pointer to a structure that contains the association request parameters.

MAC_associateReq_tstructure parameters:

Parameter	Description	Type
channel_number	The logical channel on which to attempt association.	uint8_t
channel_page	The logical channel page on which to attempt association.	uint8_t
coord_addr_mode	The addressing mode used by the coordinator.	uint8_t
capability_information	The operational capabilities of the associating device.	uint8_t
a_coord_PAN_id	The identifier of the PAN with which to associate.	uint8_t[2]
security_level	The security level to be used. Supports only Security level 0.	uint8_t
key_id_mode	The mode used to identify the key to be used. Not used in Security level 0.	uint8_t
a_key_source	The originator of the key to be used.Not used in Security level 0.	uint8_t[8].
coord_address	The address of the coordinator.	MAC_addr_t
key_index	The index of the key to be used. Not used in Security level 0.	uint8_t

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation. API capability information is used to transmit certain information to the coordinator defined by the upper layers. In no case will the lower layers configure any of this information.

3.1.3.2. MLME-ASSOCIATE.indication

This API is used to indicate the reception of an Association Request command.

MAC_Status_t APP_MAC_mlmeAssociateIndCb( const  MAC_associateInd_t * pAssociateInd );

The argument of this API:

pAssociateInd: A pointer to a structure that contains the association indication parameters.

MAC_associateInd_t structure parameters:

Parameter	Description	Type	Valid range
a_device_address	The address of the device requesting association.	uint8_t[8]	any extended address
capability_information	The operational capabilities of the device requesting association.	uint8_t	0x00 - 0xFF
security_level	The security level to be used. Supports only Security level 0.	uint8_t	TRUE, FALSE
key_id_mode	The mode used to identify the key to be used. Not used in Security level 0.	uint8_t	-
a_key_source	The originator of the key to be used.Not used in Security level 0.	uint8_t.	-
key_index	The index of the key to be used. Not used in Security level 0.	uint8_t	-

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.3.3. MLME-ASSOCIATE.response

This API is used to initiate a response to an MLME-ASSOCIATE.indication primitive.

MAC_Status_t MAC_MLMEAssociateRes(const MAC_associateRes_t * pAssociateRes);

The argument of this API:

pAssociateRes: A pointer to a structure that contains the associate response parameters.

MAC_associateRes_t structure parameters:

Parameter	Description	Type	Valid range
a_device_address	The address of the device requesting association.	uint8_t[8]	Any valid extended address
a_assoc_short_address	The short address allocated by the coordinator on successful association. This parameter is set to 0xffff if the association was unsuccessful.	uint16_t	0x0000–0xFFFF
security_level	The security level to be used. Supports only Security level 0.	uint8_t	TRUE, FALSE
key_id_mode	The mode used to identify the key to be used. Not used in Security level 0.	uint8_t	-
a_key_source	The originator of the key to be used. Not used in Security level 0.	uint8_t[8].	-
key_index	The index of the key to be used. Not used in Security level 0.	uint8_t	-
status	The status of the association procedure.	uint8_t	0x00 -0x03

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.3.4. MLME-ASSOCIATE.confirm

This API is used to inform the next higher layer of the initiating device whether its request to associate was successful or unsuccessful.

MAC_Status_t APP_MAC_mlmeAssociateCnfCb( const  MAC_associateCnf_t * pAssociateCnf );

The argument of this API:

pAssociateCnf: A pointer to a structure that contains the associate confirm parameters.

MAC_associateCnf_t structure parameters:

Parameter	Description	Type	Valid range
a_assoc_short_address	The short address allocated by the coordinator on successful association. This parameter will be equal to 0xFFFF if the association attempt was unsuccessful.	uint8_t[2]	0x0000 - 0xFFFF
status	The status of the association attempt.	uint8_t	SUCCESS, NO_DATA, or see return codes above
security_level	The security level to be used. Supported only Security level 0.	uint8_t	TRUE, FALSE
key_id_mode	The mode used to identify the key to be used. Not used in Security level 0.	uint8_t	-
a_key_source	The originator of the key to be used. Not used in Security level 0.	uint8_t[8].	-
key_index	The index of the key to be used. Not used in Security level 0.	uint8_t	-

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.4. MLME-COMM-STATUS.indication

This API is used to indicate a communications status.

MAC_Status_t APP_MAC_mlmeCommStatusIndCb( const  MAC_commStatusInd_t * pCommStatusInd )

The argument of this API:

pCommStatusInd: A pointer to a structure that contains the CommStatus indication parameters.

MAC_commStatusInd_t structure parameters:

Parameter	Description	Type	Valid range
a_PAN_id	The PAN ID of the device from which the frame was received or to which the frame was being sent.	uint8_t[2]	0x0000 - 0xFFFF
src_addr_mode	The operational capabilities of the device requesting association.	uint8_t	NONE, SHORT, EXTENDED
src_address	The address of the entity from which the frame originated.	MAC_addr_t	Short address or extended address
dst_addr_mode	The destination addressing mode for this primitive.	uint8_t	NONE, SHORT, EXTENDED
dst_address	The address of the device for which the frame was intended.	MAC_addr_t	Short address or extended address
security_level	The security level to be used. Supports only Security level 0.	uint8_t	TRUE, FALSE
key_id_mode	The mode used to identify the key to be used. Not used in Security level 0.	uint8_t	-
a_key_source	The originator of the key to be used.Not used in Security level 0.	uint8_t[8].	-
key_index	The index of the key to be used. Not used in Security level 0.	uint8_t	-
status	TThe communications status.	uint8_t	0x00 - 0xFF

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.5. MLME-BEACON

3.1.5.1. MLME-BEACON.request

MLME-BEACON.request is supported in WBA products only. This API is used by a coordinator or PAN coordinator to request its MAC sublayer to transmit a Beacon or Enhanced Beacon frame. The frame is then broadcast to all devices within the coordinator's range. It is used to manage network synchronization and provide network information to devices.

MAC_Status_t ST_MAC_MLMEBeaconReq( const  MAC_beaconReq_t * pBeaconReq);

The argument of this API:

pbeaconReq: A pointer to a structure that contains the beacon request parameters.

MAC_beaconReq_t structure parameters:

Parameter	Description	Type	Valid range
beacon_type	Indicates if the beacon request to be sent is a beacon or an enhanced beacon.	uint8_t	BEACON, ENHANCED BEACON
channel_number	The channel number to use.	uint8_t	11 - 26
channel_page	The channel page to use, always 0 in non-beacon-PAN	uint8_t	0
superframe_order	The length of the active portion of the superframe, including the beacon frame, always 15 in non-beacon-PAN	uint8_t	15
header_ie_list	The header IEs, excluding Termination IEs, to be included in the Beacon frame. If empty, then no header IEs are included.	ST_MAC_hdr_ie[NB_HDR_IES]	-
pyld_ie_list	The payload IEs, excluding Termination IEs, to be included in the Beacon frame. If empty, then no payload IEs are included.	ST_MAC_pyld_ie[NB_PYLD_IES]	-
beacon_security_level	The security level to be used for beacon frames.	uint8_t	0x00 - 0x07
beacon_key_Id_mode	The mode used to identify the key to be used. This parameter is ignored if the beacon_security_level parameter is set to 0x00.	uint8_t	0x00 - 0x03
beacon_key_source	The originator of the key to be used. This parameter is ignored if the beacon_key_id_mode parameter is ignored or set to 0x00 or 0x01.	uint8_t[8]	-
beacon_key_index	The index of the key to be used. This parameter is ignored if the beacon_key_id_mode parameter is ignored or set to 0x00.	uint8_t	0x01 - 0xFF
src_addr_mode	The source addressing mode for this MPDU.	uint8_t	NONE, SHORT, EXTENDED
dst_addr_mode	The destination addressing mode for this primitive and subsequent beacon.	uint8_t	NONE, SHORT, EXTENDED
dst_address	If sent in response to an MLME-BEACON-REQUEST.indication, the device who sent the beacon request, otherwise the short broadcast address.	MAC_addr_t	-
BSN_suppression	If beacon_type is ENHANCED_BEACON, then if BSN_suppression is TRUE, the EBSN (Enhanced Beacon Sequence Number) is omitted from the frame, and the Sequence Number Suppression field of the Frame Control field is set to one	uint8_t	TRUE, FALSE

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.5.2. MLME-BEACON.confirm

This API is used to to inform the next higher layer of the initiating device the status of its request to transmit Beacon

MAC_Status_t APP_MAC_mlmeBeaconCnfCb( const ST_MAC_beaconCnf_t * pBeaconCnf )

The argument of this API:

pBeaconCnf: A pointer to a structure that contains the beacon confirm parameters.

ST_MAC_beaconCnf_t structure parameters:

Parameter	Description	Type	Valid range
status	The result of the attempt to send the beacon or enhanced beacon.	uint8_t	SUCCESS, or see return codes above

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.5.3. MLME-BEACON-NOTIFY.indication

This API is used to indicate when a beacon is received.

MAC_Status_t APP_MAC_mlmeBeaconNotifyIndCb( const  ST_MAC_beaconNotifyInd_t * pBeaconNotifyInd)

The argument of this API:

pBeaconNotifyInd: A pointer to a structure that contains the beacon notify indication parameters.

MAC_beaconNotifyInd_t structure parameters:

Parameter	Description	Type	Valid range
BSN	The BSN of the Beacon frame.	uint8_t	0x00 - 0xFF
PAN_descriptor	The PAN Descriptor for the received Beacon frame.	ST_MAC_PAN_Desc_t	-
pend_addr_spec	The beacon pending address specification.	uint8_t	-
a_addr_list	The addresses of the devices for which the beacon source has data.	MAC_addr_t[g_MAX_PENDING_ADDRESS_c]	-
beacon_type	Indicates a beacon or enhanced beacon was received.	uint8_t	BEACON, ENHANCED_BEACON
header_ie_list	The header IEs, excluding Termination IEs, that were included in the Beacon frame. If empty, then no header IEs were included.	ST_MAC_hdr_ie[NB_HDR_IES]	-
pyld_ie_list	The payload IEs, excluding Termination IEs, that were included in the Beacon frame. If empty, then no payload IEs were included.	ST_MAC_pyld_ie[NB_PYLD_IES]	-
sduPtr	Pointer to the set of octets comprising the Beacon Payload field, if present.	uint8_t*	-

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.5.4. MLME-BEACON-REQUEST.indication

This API is used to indicate the receipt of a Beacon Request command or an Enhanced Beacon Request command. It is only available when macBeaconAutoRespond is FALSE. This API is supported on WBA products only.

MAC_Status_t APP_MAC_mlmeBeaconReqIndCb( const  ST_MAC_beaconReqInd_t * pBeaconReqInd )

The argument of this API:

pBeaconReqInd: A pointer to a structure that contains the beaconReq indication parameters.

ST_MAC_beaconReqInd_t structure parameters:

Parameter	Description	Type	Valid range
BeaconType	Indicates if the beacon request was for a beacon or an enhanced beacon.	uint8_t	BEACON, ENHANCED BEACON
SrcAddr Mode	The operational capabilities of the device requesting association.	uint8_t	NONE, SHORT, EXTENDED
SrcAddr	The device who sent the beacon request, if present; otherwise, the short broadcast address.	MAC_addr_t	Short address or extended address
DstPanId	The PAN ID contained in the beacon request, or the broadcast PAN ID if PAN ID not present.	uint16_t	0x0000 - 0xFFFF
HeaderIeList	The header IEs, excluding Termination IEs, to be included in the Beacon frame. If empty, then no header IEs are included.	-	-
PayloadIeList	The payload IEs, excluding Termination IEs, to be included in the Beacon frame. If empty, then no payload IEs are included.	-	-

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.5.5. MLME-SYNC-LOSS.indication

This API is used to indicate the loss of synchronization with a coordinator.

The loss of synchronization may be due to the detection of PAN ID conflict, where two coordinators of different MAC addresses may be transmitting Beacons using the same PAN ID. In which case, a new PAN ID must be selected for the PAN. Another reason is when the coordinator sends Realignment command to the associated devices. In this case, on receiving this command, the MAC layer of the device will issue the MLME-SYNC-LOSS.indication to the NWK layer.

MAC_Status_t APP_MAC_mlmeSyncLossIndCb( const ST_MAC_syncLoss_t * syncLossPtr )

The argument of this API:

pOrphanInd: A pointer to a structure that contains the orphan indication parameters.

MAC_orphanInd_t structure parameters:

Parameter	Description	Type	Valid range
loss_reason	The reason the synchronization is lost.	uint8_t	PAN_ID_CONFLICT, REALIGNMENT
a_pan_id	The PAN ID with which the device lost synchronization.	uint8_t[2]	0x0000–0xFFFF
channel_number	The channel number on which the device lost synchronization or to which it was realigned.	uint8_t	11 - 26
channel_page	The channel page on which it was realigned. Always 0 on non-beacon-PAN	uint8_t	0
security_level	The security level to be used. Supports only Security level 0.	uint8_t	TRUE, FALSE
key_id_mode	The mode used to identify the key to be used. Not used in Security level 0.	uint8_t	-
a_key_source	The originator of the key to be used. Not used in Security level 0.	uint8_t.[8]	-
key_index	The index of the key to be used. Not used in Security level 0.	uint8_t	-

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.6. MLME-DISASSOCIATE

The Disassociate primitives enable the process of disassociation in a PAN. Two scenarios is illustrated hereafter: the first scenario is device initiated disassociation and the second is coordinator initiated disassociation that uses indirect transmission to transmit the Disassociation Notification. It is important to note that the second method is only implemented on WB products.

In the first scenario, the NWK layer of the device issues MLME-DISASSOCIATE.Request with the parameter tx_indirect set to False. The MAC layer transmits Disassociation Notification, and the coordinator responds with an ACK. On receiving the Disassociation Notification, the MAC layer of the coordinator issues MLME-DISASSOCIATE.Indication to the NWK layer. Finally, the MAC layer of the device issues MLME-DISASSOCIATE.Confirm with a status set to SUCCESS.

In the second scenario, the NWK layer of the coordinator issues MLME-DISASSOCIATE.Request with the parameter tx_indirect set to True. Since tx_indirect is True, the MAC of the coordinator must send the Disassociation Notification command to the device using indirect transmission; i.e., the Disassociation Notification command must be added to the list of pending transactions stored on the coordinator. The coordinator sends a Beacon with the data pending field indicating that there is data pending for this device. The device sends a MAC Data Request to the coordinator, which thus sends the Dissociation Notification. On receiving the Disassociation Notification, the MAC layer of the device issues MLME-DISASSOCIATE.Indication to the NWK layer. Finally, the MAC layer of the coordinator issues MLME-DISASSOCIATE.Confirm with a status set to SUCCESS.

An associated device must disassociate itself by removing all references to the PAN. The NWK layer of a coordinator should disassociate a device by removing all references to that device.

3.1.6.1. MLME-DISASSOCIATE.request

This API is used by an associated device to notify the coordinator of its intent to leave the PAN. It is also used by the coordinator to instruct an associated device to leave the PAN.

MAC_Status_t MAC_MLMEDisassociateReq( const  MAC_disassociateReq_t * pDisassiociateReq );

The argument of this API:

pDisassociateReq: A pointer to a structure that contains the disassociation request parameters.

MAC_disassociateReq_t structure contents:

Parameter	Description	Type
device_addr_mode	Specifies the addressing mode used by the device.	uint8_t
a_device_PAN_id	Contains the identifier of the PAN that the device belongs to.	uint8_t[2]
disassociate_reason	Specifies the reason for the disassociation.	uint8_t
device_address	Contains the device's address.	MAC_addr_t
tx_Indirect	Specifies whether the disassociation notification command should be sent indirectly.	uint8_t
security_level	The security level to be used. Supportes only Security level 0.	uint8_t
key_id_mode	The mode used to identify the key to be used. Not used in Security level 0.	uint8_t
key_index	The originator of the key to be used. Not used in Security level 0.	uint8_t.
a_key_source	Contains the originator of the key to be used for security. Not used in Security level 0.	uint8_t[8]

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.6.2. MLME-DISASSOCIATE.indication

This API is used to indicate the reception of a Disassociation Notification command.

MAC_Status_t APP_MAC_mlmeDisassociateIndCb( const  MAC_disassociateInd_t * pDisassociateInd )

The argument of this API:

pDisassociateInd: A pointer to a structure that contains the disassociate indication parameters.

MAC_disassociateInd_t structure parameters: The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.6.3. MLME-DISASSOCIATE.confirm

This API is used to report the results of an MLME-DISASSOCIATE.request primitive.

MAC_Status_t APP_MAC_mlmeDisassociateCnfCb( const  MAC_disassociateCnf_t * pDisassociateCnf );

The argument of this API:

pDisassociateCnf: A pointer to a structure that contains the disassociate confirm parameters.

MAC_disassociateCnf_t structure parameters:

Parameter	Description	Type	Valid range
device_addr_mode	The addressing mode of the device that has either requested disassociation or been instructed to disassociate by its coordinator.	uint8_t	SHORT, EXTENDED
a_device_PAN_id	The PAN ID of the device that has either requested disassociation or been instructed to disassociate by its coordinator.	uint8_t[2]	0x0000 - 0xFFFF
device_address	The address of the device that has either requested disassociation or been instructed to disassociate by its coordinator.	MAC_addr_t	As specified by the device_addr_mode parameter
status	The status of the disassociation attempt.	uint8_t	SUCCESS, or see annex list

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.7. MLME-GET / MLME-SET

The MLME-Get primitive is used by higher-layer protocols to retrieve information about the current state of the MAC layer, such as the current channel, the PAN identifier, the device address, …etc. By using the MLME-Get primitive, higher-layer protocols can obtain such information without having to directly access the MAC layer management entity.

The MLME-SET primitive is used by higher-layer protocols to configure the operation of the MAC layer, such as setting the current channel, the PAN identifier, the device address...etc. By using the MLME-SET primitive, higher-layer protocols can configure such settings without having to directly access the MAC layer management entity.

3.1.7.1. MLME-GET.request

This API is used to request information about a given PIB attribute.

MAC_Status_t MAC_MLMEGetReq( const  MAC_getReq_t * pGetReq );

The argument of this API:

pGetReq: A pointer to a structure that contains the PIB attribute to retrieve.

MAC_getReq_t structure contents:

Parameter	Description	Type
PIB_attribute	Specifies the name of the PIB attribute to be read from the MAC layer.	uint8_t

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.7.2. MLME-GET.confirm

This API is used to reports the results of an information request from the PIB.

MAC_Status_t APP_MAC_mlmeGetCnfCb( const  MAC_getCnf_t * pGetCnf );

The argument of this API:

pGetCnf: A pointer to a structure that contains the get confirm parameters.

MAC_getCnf_t structure parameters:

Parameter	Description	Type	Valid range
PIB_attribute	The name of the PIB attribute that was read.	uint8_t	-
PIB_attribute_valuePtr	The value of the indicated PIB attribute that was read. This parameter has zero length when the Status parameter is set to UNSUPPORTED_ATTRIBUTE.	uint8_t *	-
PIB_attribute_value_len	The length of the PIB attribute returned value.
status	The result of the request for PIB attribute information.	uint8_t	SUCCESS, UNSUPPORTED_ATTRIBUTE

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.7.3. MLME-SET.request

This API is used to set or modify a particular PIB (Protocol Information Base) attribute in the MAC layer

MAC_Status_t MAC_MLMESetReq( const  MAC_setReq_t * pSetReq);

The argument of this API:

pSetReq: A pointer to a structure that contains the PIB attribute to set.

MAC_setReq_t structure contents:

Parameter	Description	Type
PIB_attribute_valuePtr	Pointer to the value of the PIB attribute to be set in the MAC layer.	uint8_t *
PIB_attribute	Specifies the name of the PIB attribute to be set in the MAC layer.	uint8_t

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.7.4. MLME-SET.confirm

This API is used to reports the results of an attempt to write a value to a PIB attribute.

MAC_Status_t APP_MAC_mlmeSetCnfCb( const  MAC_setCnf_t * pSetCnf );

The argument of this API re:

pSetCnf: A pointer to a structure that contains the set confirm parameters.

MAC_setCnf_t structure parameters:

Parameter	Description	Type	Valid range
PIB_attribute	The name of the PIB attribute that was written.	uint8_t	-
status	The result of the request to write the PIB attribute.	uint8_t	SUCCESS, READ_ONLY, UNSUPPORTED_ATTRIBUTE, INVALID_INDEX, INVALID_PARAMETER

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.8. MLME-RESET

The MLME-RESET primitive is used by higher-layer protocols to reset the MAC layer. By using the MLME-RESET primitive, higher-layer protocols can ensure that the MAC layer is in a known state before starting a new communication session.

3.1.8.1. MLME-RESET.request

This API is used to request that the MLME performs a reset operation.

MAC_Status_t MAC_MLMEResetReq( const  MAC_resetReq_t * pResetReq );

The argument of this API:

pResetReq: A pointer to a structure that contains reset options.

MAC_resetReq_t structure contents:

Parameter	Description	Type
set_default_PIB	Determines whether the MAC PIB attributes should be set to their default values during a reset or not.	uint8_t

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.8.2. MLME-RESET.confirm

This API is used to reports the results of the reset operation.

MAC_Status_t APP_MAC_mlmeResetCnfCb( const  MAC_resetCnf_t * pResetCnf );

The argument of this API:

pResetCnf: A pointer to a structure that contains the reset confirm parameters.

MAC_resetCnf_t structure parameters:

Parameter	Description	Type	Valid range
status	The status of the data request.	uint8_t	SUCCESS

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.9. MLME-RX-ENABLE

3.1.9.1. MLME-RX-ENABLE.request

This API allows the next higher layer to request that the receiver is either enabled for a finite period of time or disabled. This primitive is also generated to cancel a previously generated request to enable the receiver. The receiver is enabled or disabled exactly once per primitive request.

MAC_Status_t MAC_MLMERxEnableReq( const  MAC_rxEnableReq_t * pRxEnableReq );

The argument of this API:

pRxEnableReq: A pointer to a structure that contains rxEnable options.

MAC_rxEnableReq_t structure contents:

Parameter	Description	Type	Valid range
defer_permit	This field indicates whether the requested operation can be deferred or not.	uint8_t	TRUE, FALSE
ranging_Rx_control	This field is used to configure the transceiver to receive data frames with ranging enabled or disabled.	uint8_t	RANGING_OFF, RANGING_ON
a_Rx_on_time	This field specifies the number of symbols measured before the receiver is enabled or disabled.	uint8_t[4]	0x000000–0xFFFFFF
a_Rx_on_duration	This field specifies the number of symbols for which the receiver is to be enabled.	uint8_t[4]	0x000000–0xFFFFFF

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.9.2. MLME-RX-ENABLE.confirm

This API is used to reports the results of the attempt to enable or disable the receiver.

MAC_Status_t APP_MAC_mlmeRxEnableCnfCb( const  MAC_rxEnableCnf_t * pRxEnableCnf );

The argument of this API:

pRxEnableCnf: A pointer to a structure that contains the rx enable confirm parameters.

MAC_rxEnableCnf_t structure parameters:

Parameter	Description	Type	Valid range
status	The result of the request to enable or disable the receiver.	uint8_t	SUCCESS, PAST_TIME, ON_TIME_TOO_LONG, RANGING_NOT_SUPPORTED

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.10. MLME-SCAN

The Scan primitives facilitate the process of scanning the environment around the device to determine if other PANs exist. There are five different types of scans available: ED, Active, Passive, Orphan, and Enhanced Active.
In the first scenario, active scan is illustrated. The scenario starts by MLME-SET.Request being issued to set macAutoRequest to False. If a Beacon frame is received when macAutoRequest is set to FALSE, each recorded PAN descriptor is sent to the next higher layer in a separate MLME-BEACON-NOTIFY.indication primitive. Following this, MLME-SCAN.Request with scanType set to ACTIVE issued. The MAC layer transmits Beacon Request on each selected channel and keeps the RX enabled for the period of the scanDuration parameter. For every received Beacon, the MAC layer will issue MLME-BEACON-NOTIFY.Indication. Finally, when the device has scanned all the requested channels, the MAC layer must issue MLME-SCAN.Confirm with the status set to SUCCESS.
If instead of setting macAutoRequest to False, it is set to True, if a Beacon frame is received, the list of PAN descriptor structures must be stored by the MAC sublayer until the scan is complete; at this time, the list must be sent to the next higher layer in the PANDescriptorList parameter of the MLME-SCAN.confirm primitive
It is important to note that the PanDescriptorList field is limited to 6 beacons. If this limit is reached, the status of MLME-SCAN.Confirm changes to LIMIT_REACHED.

In the second scenario, passive scan is illustrated. It is similar to an active scan, except that Beacon Request command is not transmitted. This mode is not very useful in non-beacon-PAN because the PAN coordinator sends a beacon only when a beacon request is received and does not send Beacons periodically.

In the third scenario, the process of conducting an orphan scan to relocate a Coordinator following a loss of synchronization is illustrated. An orphan scan is requested using the MLME-SCAN.Request with the scan_type parameter set to Orphan. For each scanned channel, the device transmits Orphan Notification command. When the Coordinator receives the command, it issues MLME-ORPHAN.Indication to the NWK layer. If the NWK layer finds a record of the device, it should send a Coordinator Realignment command to the orphaned device using the MLME�ORPHAN.response primitive. The device then responds with an Acknowledgement and issues the MLME-SCAN.Confirm with a status of SUCCESS to its NWK layer.

It is important to note that if multiple channels are being scanned, the scanning sequence will terminate once the device relocates the Coordinator or the specified set of channels has been scanned.

In the fourth scenario, conducting an enhanced active scan is illustrated. Enhanced active scan allows the device to specify filters to locate specific Coordinators based on parameters such as RSSI or ExtPANID...etc. Enhanced active scan is requested through the MLME-SCAN.Request primitive with the scan_type parameter set to EnhancedActive. The MAC layer of the device transmits Enhanced Beacon Request (EBR). If the filters are met, the Coordinator responds with an Enhanced Beacon (EB) that contains Information Elements (IEs). The MAC layer of the device issues MLME-BEACON-NOTIFY.Indication whenever a beacon is received. This sequence of events is repeated for all scanned channels. Finally, the MAC layer of the device issues MLME-SCAN.Confirm with a status of SUCCESS.

3.1.10.1. MLME-SCAN.request

This API is used to initiate a channel scan over a given set of channels.

MAC_Status_t MAC_MLMEScanReq( const  MAC_scanReq_t * pScanReq );

The argument of this API:

pScanReq: A pointer to a structure that contains scan request options.

MAC_scanReq_t structure contents:

Parameter	Description	Type
scan_type	The type of scan to be performed.	uint8_t
scan_duration	The time spent on scanning each channel.	uint8_t.
channel_page	The channel page on which to perform the scan.	uint8_t.
security_level	The security level to be used for the scan. Supports only Security level 0	uint8_t.
a_scan_channels	Indicates which channels are to be scanned. Each bit corresponds to a channel. A value of 1 indicates that the channel should be scanned, while a value of 0 indicates that it should not be scanned.	uint8_t[4].
a_key_source	The originator of the key to be used for the scan. Not used in Security level 0.	uint8_t[8].
key_id_mode	The mode used to identify the key to be used for the scan. Not used in Security level 0.	uint8_t.
key_index	The index of the key to be used for the scan. Not used in Security level 0.	uint8_t.

From the Zigbee specification annex D, for the 2.4GHz, a ScanDuration value of 3 is recommended. The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.10.2. MLME-SCAN.confirm

This API is used to reports the result of the channel scan request.

MAC_Status_t APP_MAC_mlmeScanCnfCb( const  MAC_scanCnf_t * pScanCnf );

The argument of this API:

pScanCnf: A pointer to a structure that contains the scan confirm parameters.

MAC_scanCnf_t structure parameters:

Parameter	Description	Type	Valid range
scan_type	The type of scan performed.	uint8_t	ED, ACTIVE, PASSIVE, ORPHAN, ENHANCED_ACTIVE_ SCAN
channel_page	The channel page on which the scan was performed, always 0 for non-beacon-PAN.	uint8_t	0
a_unscanned_channels	A list of the channels given in the request that were not scanned. This parameter is not valid for ED scans.	uint8_t[4]	Any list of valid channels
result_list_size	The number of elements returned in the appropriate result lists. This value is zero for the result of an orphan scan.	uint8_t	-
a_energy_detect_list	The list of energy measurements, one for each channel searched during an ED scan. This parameter is null for active, passive, and orphan scans.	uint8_t[g_MAX_ED_SCAN_RESULTS_SUPPORTED_c]	0x00–0xFF for each integer
a_PAN_descriptor_list	The list of PAN descriptors, one for each beacon found during an active or passive scan if macAutoRequest is set to TRUE. This parameter is null for ED and orphan scans or when macAutoRequest is set to FALSE during an active or passive scan.	MAC_PAN_Desc_t[g_MAX_PAN_DESC_SUPPORTED_c]	-
status	The status of the scan request.	uint8_t	SUCCESS, LIMIT_REACHED, NO_BEACON, SCAN_IN_PROGRESS, BAD_CHANNEL, or see result code list

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.10.3. MLME-ORPHAN.indication

This API is generated by the MLME of a coordinator and issued to its next higher layer on receipt of an Orphan Notification command

MAC_Status_t APP_MAC_mlmeOrphanIndCb( const  MAC_orphanInd_t * pOrphanInd )

The argument of this API:

pOrphanInd: A pointer to a structure that contains the orphan indication parameters.

MAC_orphanInd_t structure parameters:

Parameter	Description	Type	Valid range
a_orphan_address	The address of the orphaned device.	uint8_t[8]	Any valid extended address
security_level	The security level to be used. Supports only Security level 0.	uint8_t	TRUE, FALSE
key_id_mode	The mode used to identify the key to be used. Not used in Security level 0.	uint8_t	-
a_key_source	The originator of the key to be used. Not used in Security level 0.	uint8_t[8].	-
key_index	The index of the key to be used. Not used in Security level 0.	uint8_t	-

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.10.4. MLME-ORPHAN.response

This API is used to respond to the MLME-ORPHAN.indication primitive.

MAC_Status_t MAC_MLMEOrphanRes(const MAC_orphanRes_t * pOrphanRes);

The argument of this API:

pOrphanRes: A pointer to a structure that contains the orphan response parameters.

MAC_orphanRes_t structure parameters:

Parameter	Description	Type	Valid range
a_orphan_address	The address of the orphaned device.	Extended address	Any valid extended address
a_short_address	Short address allocated to the orphaned device	uint8_t[2]
associated_member	If the orphaned device is associated with the coordinator or not	uint8_t	TRUE, FALSE
security_level	The security level to be used. Supported only Security level 0.	uint8_t	TRUE, FALSE
key_id_mode	The mode used to identify the key to be used. Not used in Security level 0.	uint8_t	-
a_key_source	The originator of the key to be used. Not used in Security level 0.	uint8_t[8].	-
key_index	The index of the key to be used. Not used in Security level 0.	uint8_t	-

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.11. MLME-START

The MLME-START primitive is used by a device to start a new network formation process.

3.1.11.1. MLME-START.request

This API is sent from the higher layers of a PAN coordinator to the MAC layer of the coordinator to initiate a new PAN.

MAC_Status_t MAC_MLMEStartReq( const  MAC_startReq_t * pStartReq);

The argument of this API:

pStartReq: A pointer to a structure that contains start options.

MAC_startReq_t structure contents:

Parameter	Description	Type
a_PAN_id	PAN identifier to be used by the device	uint8_t[2]
channel_number	Logical channel on which to begin.	uint8_t.
channel_page	The channel page on which to begin.	uint8_t.
a_start_time	Time at which to begin transmitting beacons.	uint8_t.
beacon_order	Indicates how often the beacon is to be transmitted.	uint8_t.
superframe_order	the length of the active portion of the superframe.	uint8_t.
PAN_coordinator	Indicates whether the device is a PAN coordinator or not of a new PAN.	uint8_t.
battery_life_extension	Indicates if the receiver of the beaconing device is disabled or not.	uint8_t.
coord_realignment	Indicates if the coordinator realignment command is to be transmitted prior to changing the superframe configuration.	uint8_t.
coord_realign_security_level	The security level to be used for the coordinator realignment command. Supportes only Security level 0	uint8_t.
coord_realign_key_id_mode	The mode used to identify the key to be used for the coordinator realignment command. Not used in Security level 0	uint8_t.
coord_realign_key_index	Index of the key to be used. Not used in Security level 0.	uint8_t.
a_coord_realign_key_source	Originator of the key to be used. Not used in Security level 0.	uint8_t[8].
beacon_security_level	Security level to be used for beacon frames. Supportes only Security level 0.	uint8_t.
beacon_key_id_mode	Mode used to identify the key to be used. Not used in Security level 0.	uint8_t.
beacon_key_index	Index of the key to be used. Not used in Security level 0.	uint8_t.
a_beacon_key_source	Originator of the key to be used.Not used in Security level 0.	uint8_t[8].

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

Note: On the WB and the WBA, it is not possible to start a network with the PANID = 0xFFFF. According to the standard, It is possible to initiate the network, but not to send a frame with a short address in this case. Even when associating, it is recommended to remove this address from the PANID and return an INVALID_PARAMETER error.

3.1.11.2. MLME-START.confirm

This API is used to reports the results of the attempt to start using a new superframe configuration.

MAC_Status_t APP_MAC_mlmeStartCnfCb( const  MAC_startCnf_t * pStartCnf );

The argument of this API:

pStartCnf: A pointer to a structure that contains the start confirm parameters.

MAC_startCnf_t structure parameters:

Parameter	Description	Type	Valid range
status	The result of the attempt to start using an updated superframe configuration.	uint8_t	SUCCESS, NO_SHORT_ADDRESS, CHANNEL_ACCESS_FAILURE, FRAME_TOO_LONG, SUPERFRAME_OVERLAP, TRACKING_OFF, see result code retrun list

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.12. MLME-POLL

The Poll primitives enable a device to extract indirect data from the coordinator. Two scenarios are illustrated hereafter: In the first scenario, the coordinator does not have any pending data for the device. Whereas in the second scenario, the coordinator has pending data for the device.
In the first scenario, the device uses the MLME-POLL.Request primitive to send a MAC Data Request to the coordinator. The coordinator issues MLME-POLL.indication to the NWK layer. The IEEE-802-15-4 specification has no notification when a MAC data poll is received by a coordinator or any ability for the Zigbee layers to dictate the response to the MAC data poll. Therefore, the MLME-POLL.indication interface is defined for a MAC used by Zigbee network layers. The effect on receipt of the MLME-Poll.indication primitive is that the next higher layer is notified that a device is requesting to see if there is a pending MAC data frame. If an indirect frame is queued by the higher layer during the processing of an MLME-POLL.indication it must affect the pending bit in the ACK frame corresponding to the data request frame that caused the MLME-POLL.indication to be issued. In this scenario, which assumes that there is no pending data for the device, the coordinator responds with an Ack with the Frame Pending field set to 0 (indicating there is no pending data for the device) . When the device receives the ACK with the Frame Pending set to 0, the MAC layer issues a MLME-POLL.Confirm to the higher layer with the status set to NO_DATA.
In the second scenario, the coordinator requests data transmission using the MCPS-DATA.Request primitive with the indirect_tx parameter set to True. The coordinator must store the transaction. It is important to note that this data is kept only for the macTransactionPersistenceTime (default: 7.7s), after which the data is discarded. Following this, the same scenario as before for the device trying to extra the data follows. However, in this case as there is pending data for the device at the coordinator, the coordinator responds to the MAC Data Request with ACK that has the Frame Pending field set to 1. The coordinator transmits the MAC Data to the device. When the data is received, the MAC layer of the device issues MLME-POLL.Confirm with the status set to SUCCESS and issues the MCPS-DATA.Indication.

3.1.12.1. MLME-POLL.request

This API prompts the device to request data from the coordinator.

MAC_Status_t MAC_MLMEPollReq( const MAC_pollReq_t * pPollReq );

The argument of this API:

pPollReq: A pointer to a structure that contains poll request options.

MAC_pollReq_t structure contents:

Parameter	Description	Type
coord_addr_mode	Addressing mode of the coordinator.	uint8_t
a_coord_PAN_id	PAN identifier of the coordinator.	uint8_t[2].
coord_address	Coordinator address.	MAC_addr_t.
security_level	The security level to be used for the scan. Supports only Security level 0	uint8_t.
a_key_source	The originator of the key to be used for the scan. Not used in Security level 0.	uint8_t[8].
key_id_mode	The mode used to identify the key to be used for the scan. Not used in Security level 0.	uint8_t.
key_index	The index of the key to be used for the scan. Not used in Security level 0.	uint8_t.

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.12.2. MLME-POLL.indication

This API is used to notifies the next higher level that a request for data has been received.

MAC_Status_t APP_MAC_mlmePollIndCb( const  MAC_pollInd_t * pPollInd );

The arguments of this API are:

pPollInd: A pointer to a structure that contains the poll indicate parameters.

MAC_pollInd_t structure parameters:

Parameter	Description	Type	Valid range
addr_mode	Addressing mode of the device requesting pending data	uint8_t	0x02 - 0x03
request_address	The address of the device requesting pending data.	-	As specified by addr_mode parameter.

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.1.12.3. MLME-POLL.confirm

This API is used to reports the results of a request to poll the coordinator for data.

MAC_Status_t APP_MAC_mlmePollCnfCb( const  MAC_pollCnf_t * pPollCnf );

The argument of this API:

pPollCnf: A pointer to a structure that contains the poll confirm parameters.

MAC_pollCnf_t structure parameters:

Parameter	Description	Type	Valid range
status	The status of the data request.	uint8_t	SUCCESS, NO_DATA, or see return code list

The return value of this API is a MAC_Status_t enumeration that indicates the status of the operation.

3.2. PHY layer

The PHY (Physical) layer is another important component of the 802.15.4 protocol, responsible for transmitting and receiving data over the wireless medium.

The PHY layer in 802.15.4 protocol operates in the 2.4 GHz ISM (Industrial, Scientific, and Medical) band and supports multiple modulation schemes, including O-QPSK (Offset Quadrature Phase-Shift Keying) and BPSK (Binary Phase-Shift Keying). O-QPSK is the most commonly used modulation scheme in 802.15.4 protocol, as it provides a good balance between data rate and power consumption.

The PHY layer in 802.15.4 protocol also supports multiple data rates, ranging from 20 kbps to 250 kbps. The choice of data rate depends on the specific requirements of the application, with higher data rates providing faster communication but consuming more power.

Additionally, the PHY layer in 802.15.4 protocol supports various power management mechanisms, including sleep modes and power amplification control, to conserve power and extend battery life.

Overall, the PHY layer in 802.15.4 protocol plays a critical role in transmitting and receiving data over the wireless medium. Its support for multiple modulation schemes, data rates, and power management mechanisms makes it a versatile and widely used protocol in a variety of application domains.

4. Getting started with STM32

4.1. With STM32WB

From a hardware point of view, STMicroelectronics offers various boards to set up 802.15.4 connectivity solution on STM32 MCUs. The device architecture leverage state-of-the art STM32 ultra-low-power process node and is available from 256 KB up to 1 MB of flash memory and up to 256 KB of SRAM.

STM32WB 802.15.4 Sniffer allows you to monitor 802.15.4 / Zigbee / Thread protocols. Please refer to how to configurate sniffer wiki.

In the WB package, there are some examples that allow demonstrating MAC 802.15.4 operation:

MAC_802_15_4_Coordinator: Creates a MAC coordinator and have devices, created by the MAC_802_15_4_Node project described hereafter, associate with it. During startup, the coordinator selects the best channel using an ED scan, followed by two active scans to create a list of PAN IDs that may already be existing. A random PAN ID is then generated that is not in the list of existing PAN IDs, and the coordinator is ready to receive association requests from the Node. Press button 1 to display all associated nodes and button 2 to check if a node is still associated with the coordinator in order to send data with acknowledgement.

MAC_802_15_4_Node: Creates a MAC Node and associate it with the coordinator created by the MAC_802_15_4_Coordinator project. During startup, the node performs an active scan on all channels to locate the coordinator. To identify the correct coordinator with a random channel and PAN ID, a payload beacon is used. In the configuration project, the payload beacon and its length must be registered in both the Node and the Coordinator. If the coordinator is not found during the first scan, a second scan is initiated with an increased scan duration, and this process is repeated up to three times (configurable). Once the coordinator is found, the node associated with it and is given a short address. You can press button 1 to send a data poll, button 2 to send data in broadcast and button 3 to disassociate from the coordinator.

MAC_802_15_4_LPM_Periodic_Transmit: Creates a Low-power mode application sending frame every second. This application allows demonstrating two modes of low power: STOP1 and STANDBY that can be managed in configuration project.

In the WB package, as well as in the WBA package, Phy_Cli example is also existing.

4.2. With STM32WBA

From a hardware point of view, STMicroelectronics offers various boards to set up 802.15.4 connectivity solution on STM32 MCUs. The device architecture leverage state-of-the art STM32 ultra-low-power process node and is available up to 2 MB Flash and 256KB of SRAM

The nucleo evaluation boards are the NUCLEO-WBA55CG board with STM32WBA55CG QFN48' package , the NUCLEO-WBA65RI board with STM32WBA65RI QFN48 package and the NUCLEO-WBA25CE1 board with STM32WBA25CE1.

In the WBA package, available example that allow demonstrating 802.15.4 operation:

Phy_Cli: a number of commands are available on all WBA evaluation boards. Help, Version, Set_channel **<channel>**, Set_power **<power>**, Set_smps **<enable/disable>**, Set_CCA_threshold **<threshold>**, TX_start 0x0C,0x01,0x08,0x01,0x22,0x11,0xFF,0xFF,0xB5,0xB6,0xB7, TX_start 0x0C,0x01,0x08,0x01,0x22,0x11,0xFF,0xFF,0xB5,0xB6,0xB7 0, TX_stop, TX_start 0x0C,0x21,0x08,0x01,0x22,0x11,0xFF,0xFF,0xB5,0xB6,0xB7, RX_start, RX_start 1, RX_stop. The Phy_Cli application is inside the directory Phy_802_15_4.

5. Acronyms

Term	Definition
Ack	Acknowledgment
AIFS	Acknowledgment InterFrame Spacing
AR	Acknowledgment Request
API	Application Programming Interface / Access point identifier
BSP	Board Support Package
CCA	Clear Channel Assessment
CLI	Command-Line Interface
CSMA-CA	Carrier Sense Multiple Access with Collision Avoidance
ED	Energy Detection
FCF	Frame Control Field
FCS	Frame Check Sequence
FFD	Full Function Device
LIFS	Long InterFrame Spacing
LQI	Link Quality indication
IFS	InterFrame Spacing
MAC	Medium Access Control
MCPS	MAC Common Part Sublayer
MCPS-SAP	MAC Common Part Sublayer Service Access Point
MLME	MAC Sublayer Management Entity
MLME-SAP	MAC Sublayer Management Entity Service Access Point
NWK	Network
O-QPSK	Offset Quadrature Phase-Shift Keying
OSI	Open Systems Interconnection
PAN	Personnel Area Network
PHY	PHYsical layer
PIB	Personal area network Information Base
RF	Radio Frequency
RFD	Reduced Function Device
RSSI	Received Signal Strength Indication
RX	Receive or Receiver
SIFS	Short InterFrame Spacing
TX	Transmit or Transmitter
WPAN	Wireless Personnel Area Network

Introduction to 802 15 4

1. Introduction

2. 802.15.4 Network

2.1. Device type

2.2. Topology

2.3. Address type

2.4. PAN ID

2.5. CCA mode

2.6. CSMA-CA

2.7. Different Scans

2.8. Frame format

2.9. Information Element

2.10. ACK

2.11. IFS

2.12. Primitive categories

3. Architecture

3.1. MAC Layer & APIs

3.1.1. MCPS-DATA

3.1.1.1. MCPS-DATA.request

3.1.1.2. MCPS-DATA.indication

3.1.1.3. MCPS-DATA.confirm

3.1.2. MCPS-PURGE

3.1.2.1. MCPS-PURGE.request

3.1.2.2. MCPS-PURGE.confirm

3.1.3. MLME-ASSOCIATE

3.1.3.1. MLME-ASSOCIATE.request

3.1.3.2. MLME-ASSOCIATE.indication

3.1.3.3. MLME-ASSOCIATE.response

3.1.3.4. MLME-ASSOCIATE.confirm

3.1.4. MLME-COMM-STATUS.indication

3.1.5. MLME-BEACON

3.1.5.1. MLME-BEACON.request

3.1.5.2. MLME-BEACON.confirm

3.1.5.3. MLME-BEACON-NOTIFY.indication

3.1.5.4. MLME-BEACON-REQUEST.indication

3.1.5.5. MLME-SYNC-LOSS.indication

3.1.6. MLME-DISASSOCIATE

3.1.6.1. MLME-DISASSOCIATE.request

3.1.6.2. MLME-DISASSOCIATE.indication

3.1.6.3. MLME-DISASSOCIATE.confirm

3.1.7. MLME-GET / MLME-SET

3.1.7.1. MLME-GET.request

3.1.7.2. MLME-GET.confirm

3.1.7.3. MLME-SET.request

3.1.7.4. MLME-SET.confirm

3.1.8. MLME-RESET

3.1.8.1. MLME-RESET.request

3.1.8.2. MLME-RESET.confirm

3.1.9. MLME-RX-ENABLE

3.1.9.1. MLME-RX-ENABLE.request

3.1.9.2. MLME-RX-ENABLE.confirm

3.1.10. MLME-SCAN

3.1.10.1. MLME-SCAN.request

3.1.10.2. MLME-SCAN.confirm

3.1.10.3. MLME-ORPHAN.indication

3.1.10.4. MLME-ORPHAN.response

3.1.11. MLME-START

3.1.11.1. MLME-START.request

3.1.11.2. MLME-START.confirm

3.1.12. MLME-POLL

3.1.12.1. MLME-POLL.request

3.1.12.2. MLME-POLL.indication

3.1.12.3. MLME-POLL.confirm

3.2. PHY layer

4. Getting started with STM32

4.1. With STM32WB

4.2. With STM32WBA

5. Acronyms