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). This protocol offers a range of modulation options, but we will focus 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. The protocol offers two modes: beacon network and non-beacon network mode. We will primarily focus on 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. 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.

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 will depend 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 will depend 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, we can 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, we prefer to use this type of address 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 shall 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 shall 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.

2.7. 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.8. 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.9. 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.

When a device sends a frame and expects an ACK in return, it uses a Short Inter-Frame Spacing (SIFS) of 12 symbols (192 microseconds at 2.4 GHz). This allows the device to quickly send the ACK and reduce the overall delay in communication.

On the other hand, when a device sends a frame and does not require an ACK in return, it uses a Longer Inter-Frame Spacing (LIFS) of 40 symbols (640 microseconds at 2.4 GHz). This longer spacing gives other devices a chance to transmit their own frames before the original device sends another frame.

AIFS, LIFS, and SIFS are different types of interframe spacing used to manage the transmission of frames and acknowledgements between devices.

AIFS (Acknowledgement Inter-Frame Spacing): AIFS is the time interval between the end of a frame transmission and the beginning of the next frame transmission. It helps to ensure that the ACK is transmitted quickly and reduces the overall delay in communication.

LIFS (Long Inter-Frame Spacing): LIFS is the time interval between the end of a frame transmission and the beginning of the next frame transmission when no acknowledgement is expected.

SIFS (Short Inter-Frame Spacing): SIFS is the time interval between the end of a frame transmission and the beginning of the next frame transmission when an acknowledgement is expected.

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

2.11. Different Scans

In 802.15.4, there are four types of scans that can be performed by a device: active, passive, orphan, ED scans.

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

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 particularly useless in non-beacon-enabled networks where devices do not periodically broadcast beacon frames.

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.

Orphan scans are performed by a device that has lost its parent node in a network. The device will perform an orphan scan to search for a new parent node to join. The orphan scan involves the device transmitting a request to join the network and waiting for a response from a potential parent node.

Enhanced Active scans involve the device actively transmitting a scan request to the network coordinator and waiting for a response, 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.

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.12. 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 IE header/payload, apart from the 127-byte frame size (O-QPSK limitation). 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.
MAC primitive can used IEs:

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

Part in the MHR -> Header IEs of variable size
Part in MAC payload -> Payload IEs of variable size
If the IEs Present field is set to one, the IEs field will be present.

Format IE field

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

There's no set size for header and payload IEs, which are parsed when you're done with IEs termination. But in some cases, IEs termination are not present.

3. General Architecture

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

3.1. MAC layer and 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 15.4 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. Request APIs

Structure definition for short and extended address:

typedef union {
   /*! Short address */
   uint8_t a_short_addr[2];
   /*! Extended address */
   uint8_t a_extend_addr[8];
} MAC_addr_t;

The MAC sublayer provides two services:

MCPS (MAC Common Part Sublayer) allows to supports the transport of data, also call MAC data service .
MLME (MAC Sublayer Management Entity) allows to support all features except enables the TX and the RX, also call 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 APIs are extracted from WB, but there's not much difference between WB and WBA:

Each API begins with ST_. Example: WB-> MAC_MCPSDataReq, WBA->ST_MAC_MCPSDataReq.
Each API for request and response has another parameter: MAC_handle * st_mac_hndl, allows to define the MAC instance.
If WB adheres to the 802.15.4-2006 standard and WBA adheres to the 802.15.4-2020 standard, then some APIs and/or API parameters may differ.
Both products support only the MAC 802.15.4 non-beacon-enabled PAN mode.

Annex list for the most commons statuses 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 don't received any beacon.
NO_DATA: Returned when the data request is used but no indirect data is received.

3.1.1. MCPS-DATA

We have the option to request an acknowledgement or not when sending data through this API. The difference between the two can be observed in these sequences.

For unacknowledged data transmissions, we set the ack_Tx field in the MCPS-DATA.request primitive to False. This triggers the CSMA-CA algorithm in the MAC layer to check for channel availability. If the channel is free, we transmit a frame wirelessly with the Acknowledge Request (AR) field set to 0. The device 2 only receives the MCPS-DATA.Indication if macRxOnWhenIdle is True. Finally, the NWK layer receives the MCPS-DATA.Confirm primitive to indicate the transmission status.

Initially, we use the MCPS-DATA.request primitive by setting the AckTx field to True. The CSMA-CA algorithm is then utilized and if the channel is available, an OTA frame is transmitted with the Acknowledge Request (AR) field set to 1, before the MacAckWaitDuration. Device 1 must receive an ACK from Device 2 and an MCPS-DATA.Indication is received on Device 2 if macRxOnWhenIdle=True. Finally, the MCPS-DATA.Confirm primitive is sent back to the NWK layer to indicate the success of the transmission.

However, if macRxOnWhenIdle=False on Device 2, then Device 1 will never receive an ACK. In this case, the MCPS-DATA.Confirm primitive is sent back 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 arguments of this API are:

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

MAC_dataReq_t structure parameters:

Parameter	Description	Type	Valid range
SrcAddrMode	The source addressing mode for this MPDU.	uint8_t	NONE, SHORT, EXTENDED
DstAddrMode	The destination addressing mode for this MPDU.	uint8_t	NONE, SHORT, EXTENDED
DstPanId	The PAN ID of the entity to which the MSDU is being transferred.	uint16_t	0x0000 - 0xFFFF
Msdu	The address of the entity to which the MSDU is being transferred.	-	As specified by the DstAddrMode parameter
MsduHandle	The handle associated with the MSDU to be transmitted by the MAC sublayer entity.	uint8_t	0x00 - 0xFF
HeaderIeList	The header IEs, excluding Termination IEs, that are to be included with the frame in addition to any header IEs added by the MAC. If empty, no additional header IEs are to be included.	-	-
HeaderIeIdList	The payload IEs, excluding Termination IEs, that are to be included with the frame in addition to any payload IEs added by the MAC. If empty, no additional payload IEs are to be included.	-	-
NestedIeSubIdList	The IDs of header IEs, excluding Termination IEs, to be added to the Data frame. The MAC will provide the content for the IE.	-	-
AckTx	TRUE if acknowledged transmission is used, FALSE otherwise.	uint8_t	TRUE, FALSE
GtsTx	Not used on non-beacon-PAN	uint8_t	FALSE
IndirectTx	TRUE if indirect transmission is to be used, FALSE otherwise.	uint8_t	TRUE, FALSE
security_level	The security level to be used. Supportes 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.	-	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 arguments of this API are:

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

MAC_dataInd_t structure parameters:

Parameter	Description	Type	Valid range
SrcAddrMode	The source addressing mode for this primitive corresponding to the received MPDU.	uint8_t	NONE, SHORT, EXTENDED
SrcPanId	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.	uint16_t	0x0000 - 0xFFFF
SrcAddr	The address of the entity from which the MSDU was received.	MAC_addr_t	As specified by the SrcAddrMode parameter
DstAddrMode	The destination addressing mode for this primitive corresponding to the received MPDU.	uint8_t	NONE, SHORT, EXTENDED
DstPanId	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.	uint16_t	0x0000 - 0xFFFF
DstAddr	The address of the entity to which the MSDU is being transferred.	MAC_addr_t	As specified by the DstAddrMode parameter
Msdu	The set of octets forming the MSDU being indicated by the MAC sublayer entity including payload IEs if present.	-	-
MpduLinkQuality	LQI value measured during reception of the MPDU.	uint8_t	0x00 - 0xFF
Dsn	The DSN of the received Data frame if one was present.	uint8_t	0x00 - 0xFF
Framepending	The value of the frame pending field of the received frame control field.	uint8_t	TRUE, FALSE
Timestamp	The time, in symbol periods, at which the data were received	uint32_t	0x00000000 - 0xFFFFFFFF
RSSI	The Received Signal Strength Indicator is a measure of the RF power level at the input of the transceiver measured during the SHR and is valid after the SFD is detected.	uint8_t	0x00 - 0xFF
security_level	The security level to be used. Supportes 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.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
MsduHandle	The handle associated with the MSDU being confirmed.	uint8_t	0x00 - 0xFF
Timestamp	The time, in symbol periods, at which the data were transmitted. The value of this parameter will be considered valid only if the value of the Status parameter is SUCCESS; if the Status parameter is not equal to SUCCESS, the value of the Timestamp parameter shall not be used for any other purpose.	uint32_t	0x000000 - 0xFFFFFFFF
Status	The status of the last MSDU transmission.	uint8_t	SUCCESS, INVALID_ADDRESS, 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.2. MCPS-PURGE

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

In the first case, we initiate with an MCPS-DATA.Request in indirect mode, where the MsduHandle is set to 0x00. This ID is used to identify the data. Subsequently, we use the MCPS-PURGE.Request primitive to eliminate the data from the queue with the ID of 0x00. We receive a successful response in the form of MCPS-PURGE.Confirm. It is important to note that in this sequence, we do not receive MCPS-DATA.Confirm.

In the second case, we attempt to use the MCPS-PURGE.Request primitive to remove the data from the queue with the ID of 0x00. However, since there is no data present in the queue, the MCPS-PURGE.Confirm returns the status of INVALID_HANDLE.

In the final case, we begin with an MCPS-DATA.Request in indirect mode, where the MsduHandle is set to 0x00. Following this, we attempt to use the MCPS-PURGE.Request primitive to remove the data from the queue with the ID of 0x01. However, since there is no data present with this specific ID in the queue, the MCPS-PURGE.Confirm returns the status of 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 arguments of this API are:

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

MAC_purgeReq_t structure parameters:

Parameter	Description	Type	Valid range
MsduHandle	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 arguments of this API are:

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

MAC_purgeCnf_t structure parameters:

Parameter	Description	Type	Valid range
MsduHandle	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 in a PAN. In the following analysis, we will examine two scenarios: one successful and one unsuccessful.
In the first case, the device uses the MLME-ASSOCIATE.Request primitive to send a MAC association Request over the air to the coordinator. The coordinator responds with an ACK, and the device receives an MLME-ASSOCIATE.Indication. Following this, the MLME-ASSOCIATE.Response is used to send the MAC Association Response over the air. The MAC Data Request with the ACK, with the frame pending set to 1 because macAssociationPermet is set to True, allows for the extraction of the MAC Association Response. Finally, the device receives an MLME-ASSOCIATE.Confirm with the status set to SUCCESS.

In the second case, we have the same sequence as the first scenario, but the macAssociationPermit parameter is set to False. As a result, the ACK to reply to the MAC Data Request has the frame pending set to 0. The association sequence concludes, and the device receives an MLME-ASSOCIATE.Confirm with the status set to PAN access denied.

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 arguments of this API are:

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 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
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
a_key_source	The originator of the key to be used.Not used in Security level 0.	uint8_t.
coord_address	The address of the coordinator.	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. 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 association with a coordinator in a PAN (Personal Area Network).

MAC_Status_t APP_MAC_mlmeAssociateIndCb( const  MAC_associateInd_t * pAssociateInd );

The arguments of this API are:

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

MAC_associateInd_t structure parameters:

Parameter	Description	Type	Valid range
DeviceAddress	The address of the device requesting association.	uint64_t	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. Supportes 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 arguments of this API are:

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

MAC_associateRes_t structure parameters:

Parameter	Description	Type	Valid range
DeviceAddress	The address of the device requesting association.	Extended address	Any valid extended address
AssocShortAddress	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. 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.	-
key_index	The index of the key to be used. Not used in Security level 0.	uint8_t	-
AssociationStatus	The association status of the association.	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 arguments of this API are:

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

MAC_associateCnf_t structure parameters:

Parameter	Description	Type	Valid range
AssocShortAddress	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	0x0000 - 0xFFFF
Status	The status of the association attempt.	uint8_t	SUCCESS, NO_DATA, or see annex list
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.	-
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.5. 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 arguments of this API are:

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

MAC_commStatusInd_t structure parameters:

Parameter	Description	Type	Valid range
PanId	The PAN ID of the device from which the frame was received or to which the frame was being sent.	uint16_t	0x0000 - 0xFFFF
SrcAddrMode	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
DstAddrMode	The destination addressing mode for this primitive.	uint8_t	NONE, SHORT, EXTENDED
DstAddr	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. Supportes 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	-
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.4. MLME-BEACON

3.1.4.1. MLME-BEACON.request

MLME-BEACON.request is supported on WBA. This API is used by a coordinator or PAN coordinator to request it's MAC sublayer to transmit a beacon frame. This beacon 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 MAC_handle_MLMEBeaconReq( const  MAC_beaconReq_t * pBeaconReq);

The arguments of this API are:

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

MAC_beaconReq_t structure parameters:

Parameter	Description	Type	Valid range
BeaconType	Indicates if the beacon request to be sent is a beacon or an enhanced beacon.	uint8_t	BEACON, ENHANCED BEACON
Channel	The channel number to use.	uint8_t	11 - 26
ChannelPage	The channel page to use, always 0 in non-beacon-PAN	uint8_t	0
SuperframeOrder	The length of the active portion of the superframe, including the beacon frame, always 15 in non-beacon-PAN	uint8_t	15
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.	-	-
HeaderIeIdList	The IDs of header IEs, excluding Termination IEs, to be added to the frame. The MAC will provide the content for the IE.	-	-
NestedIeSubIdList	The sub-IDs of nested IEs, excluding Termination IEs, to be added to the Data frame. The MAC will provide the content for the IE.	-	-
BeaconSecurityLevel	The security level to be used for beacon frames.	uint8_t	0x00 - 0x07
BeaconKeyIdMode	The mode used to identify the key to be used. This parameter is ignored if the BeaconSecurityLevel parameter is set to 0x00.	uint8_t	0x00 - 0x03
BeaconKeySource	The originator of the key to be used. This parameter is ignored if the BeaconKeyIdMode parameter is ignored or set to 0x00 or 0x01.	-	-
BeaconKeyIndex	The index of the key to be used. This parameter is ignored if the BeaconKeyIdMode parameter is ignored or set to 0x00.	uint8_t	0x01 - 0xFF
SrcAddrMode	The source addressing mode for this MPDU.	uint8_t	NONE, SHORT, EXTENDED
DstAddrMode	The destination addressing mode for this primitive and subsequent beacon.	uint8_t	NONE, SHORT, EXTENDED
DstAddr	If sent in response to an MLME-BEACON-REQUEST.indication, the device who sent the beacon request, otherwise the short broadcast address.	Short address or extended address	-
BsnSuppression	If BeaconType is ENHANCED_BEACON, then if BsnSuppression is TRUE, the EBSN 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.4.2. MLME-BEACON.confirm

This API is used to to inform the next higher layer of the initiating device whether its request to beacon was send.

MAC_Status_t APP_MAC_mlmeBeaconCnfCb( const ST_MAC_beaconCnf_t * pBeaconCnf )

The arguments of this API are:

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 annex list

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

3.1.4.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 arguments of this API are:

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
PanDescriptor	The PANDescriptor for the received Beacon frame.	PANDescriptor value	-
PendAddrSpec	The beacon pending address specification.	-	-
AddrList	The addresses of the devices for which the beacon source has data.	-	-
Ebsn	BSN used for Enhanced Beacon frames.	uint8_t	0x00 - 0xFF
BeaconType	Indicates a beacon or enhanced beacon was received.	uint8_t	BEACON, ENHANCED_BEACON
HeaderIeList	The header IEs, excluding Termination IEs, that were included in the Beacon frame. If empty, then no header IEs were included.	-	-
PayloadIeList	The payload IEs, excluding Termination IEs, that were included in the Beacon frame. If empty, then no payload IEs were included.	-	-
BeaconPayload	The set of octets comprising the Beacon Payload field, if present.	-	-
CoordAddrMode	The coordinator addressing mode corresponding to the received beacon frame	uint8_t	SHORT, EXTENDED
CoordPanId	The PAN ID of the coordinator as specified in the received beacon frame.	uint8_t	0x0000 - 0xFFFF
CoordAddress	The address of the coordinator as specified in the received beacon frame.	Short address or extended address	As specified by the CoordAddrMode parameter
ChannelNumber	The current channel number occupied by the network.	uint8_t	11 - 26
ChannelPage	The current channel page occupied by the network, in non-beacon-PAN always 0	uint8_t	0
security_level	The security level to be used. Supportes 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.4.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 only supported on WBA.

MAC_Status_t APP_MAC_mlmeBeaconReqIndCb( const  ST_MAC_beaconReqInd_t * pBeaconReqInd )

The arguments of this API are:

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.4.5. MLME-SYNC-LOSS.indication

This API is used to indicates the loss of synchronization with a coordinator. The MAC sublayer generates an MLME-SYNC-LOSS.indication primitive to inform the higher layers about the loss of synchronization.

MAC_Status_t APP_MAC_mlmeSyncLossIndCb( const ST_MAC_syncLoss_t * syncLossPtr )

The arguments of this API are:

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

MAC_orphanInd_t structure parameters:

Parameter	Description	Type	Valid range
LossReason	The reason that synchronization was lost.	uint8_t	PAN_ID_CONFLICT, REALIGNMENT
PanId	The PAN ID with which the device lost synchronization or to which it was real.	uint16_t	0x0000–0xFFFF
ChannelNumber	The channel number on which the device lost synchronization or to which it was realigned.	uint8_t	11 - 26
ChannelPage	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. 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.	-
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.5. MLME-DISASSOCIATE

The Disassociate primitives facilitate the process of disassociating in a PAN. In the following analysis, we will examine two scenarios: one direct and the second indirect. It is important to note that the second method is only implemented on WB product.

In the first case, the device uses the MLME-DISASSOCIATE.Request with the parameter TxIndirect set to False. This sends the Disassociation Notification over the air, and the coordinator responds with an ACK. The coordinator also receives an MLME-DISASSOCIATE.Indication. Finally, the device receives an MLME-DISASSOCIATE.Confirm with a status set to SUCCESS. It is worth mentioning that all references to the PAN are removed.

In the second case, the coordinator uses the MLME-DISASSOCIATE.Request with the parameter TxIndirect set to True. This sends a beacon with a data pending inside to the device to disassociate. The device sends a MAC Data Request and replies with an ACK with the frame pending set to 1. With this method, the Dissociation Notification is sent over the air, and the coordinator responds with an ACK. The device receives an MLME-DISASSOCIATE.Indication, and finally, the coordinator receives an MLME-DISASSOCIATE.Confirm with a status set to SUCCESS. Once again, all references to the PAN are removed.

3.1.5.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 arguments of this API are:

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

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

3.1.5.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 arguments of this API are:

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

MAC_disassociateInd_t structure parameters:

Parameter	Description	Type	Valid range
DeviceAddress	The PAN ID of the device from which the frame was received or to which the frame was being sent.	uint64_t	Any valid extended address
DisassociateReason	The reason for the disassociation.	uint8_t	0x00 - 0xFF
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.	-
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.3. MLME-DISASSOCIATE.confirm

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

MAC_Status_t APP_MAC_mlmeDisassociateCnfCb( const  MAC_disassociateCnf_t * pDisassociateCnf );

The arguments of this API are:

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

MAC_disassociateCnf_t structure parameters:

Parameter	Description	Type	Valid range
DeviceAddrMode	The addressing mode of the device that has either requested disassociation or been instructed to disassociate by its coordinator.	uint8_t	SHORT, EXTENDED
DevicePanId	The PAN ID of the device that has either requested disassociation or been instructed to disassociate by its coordinator.	uint16_t	0x0000 - 0xFFFF
DeviceAddress	The address of the device that has either requested disassociation or been instructed to disassociate by its coordinator	Short address or extended address	As specified by the DeviceAddrMode 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.6. MLME-GET / MLME-SET / MLME-RESET

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, and the device address. By using the MLME-Get primitive, higher-layer protocols can obtain this information without having to directly access the MAC layer management entity.

Connectivity sequence charte get pib.jpg

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, and the device address. By using the MLME-SET primitive, higher-layer protocols can configure these settings without having to directly access the MAC layer management entity.

Connectivity sequence charte set pib.jpg

The MLME-RESET primitive is used by higher-layer protocols to reset the MAC layer to its default values. 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.6.1. MLME-GET.request

This API is used to retrieve information from the MAC layer such as PIB (Protocol Information Base) attributes.

MAC_Status_t MAC_MLMEGetReq( const  MAC_getReq_t * pGetReq );

The arguments of this API are:

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.6.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 arguments of this API are:

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

MAC_getCnf_t structure parameters:

Parameter	Description	Type	Valid range
PibAttribute	The name of the PIB attribute that was read.	uint8_t	-
PibAttributeValue	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 *	-
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.6.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 arguments of this API are:

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.6.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 arguments of this API are:

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

MAC_setCnf_t structure parameters:

Parameter	Description	Type	Valid range
PibAttribute	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.7. 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 arguments of this API are:

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.7.1. 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 arguments of this API are:

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.8. MLME-RX-ENABLE

3.1.8.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 arguments of this API are:

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.	a 24-bit value	0x000000–0xFFFFFF
a_Rx_on_duration	This field specifies the number of symbols for which the receiver is to be enabled.	a 24-bit value	0x000000–0xFFFFFF

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

3.1.8.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 arguments of this API are:

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, or see

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

3.1.9. 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, we will examine an active scan. We begin with an MLME-SET.Request to set macAutoRequest to False. This allows us to receive an MLME-BEACON-NOTIFY.Indication even if the payload is empty. Following this, the device uses the MLME-SCAN.Request with scanType set to ACTIVE. This sends a beacon request on each selected channel, with the RX enabled for the scanDuration parameter. If one or more beacons reply to the beacon request, then an MLME-BEACON-NOTIFY.Indication is received for each beacon. Finally, the device receives an MLME-SCAN.Confirm with the status set to SUCCESS and with the beacons listed in the PanDescriptorList field.
If instead of setting macAutoRequest to False, it is set to True, then an MLME-BEACON-NOTIFY.Indication is received only if the beacon contains a payload. Similarly, at the end of the scan, an MLME-SCAN.Confirm is received with the status set to SUCCESS and with the beacons listed in the PanDescriptorList field.
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, we will examine a passive scan. It is similar to an active scan, but we do not send a beacon request. This mode is not very useful in Non-beacon-PAN because the PAN coordinator sends a beacon only when a beacon request is received.

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 third scenario, we will explore the process of conducting an orphan scan to locate a Coordinator. To begin, we initiate a MLME-SCAN.Request with the ScanType parameter set to Orphan, followed by an Orphan Notification transmitted over the air. When the Coordinator receives the MLME-ORPHAN.Indication, it responds with a MLME-ORPHAN.Response. If the NWK layer identifies a record of the device, the Coordinator sends a Coordinator Realignment with the parameter set to 1. The device then responds with an Acknowledgement and the MLME-SCAN.Confirm with a status of SUCCESS.

It is important to note that if multiple channels are being scanned, the scanning sequence will terminate once the device locates a Coordinator.

In the fourth scenario, we will explore the process of conducting an enhanced active scan, which allows us to apply filters to locate specific Coordinators based on parameters such as RSSI or ExtPANID. To begin, we initiate a MLME-SCAN.Request with the ScanType parameter set to EnhancedActive, followed by an Enhanced Beacon Request (EBR) transmitted over the air. If the filters are met, the Coordinator responds with an Enhanced Beacon (EB) that contains Information Elements (IEs). The device receives a MLME-BEACON-NOTIFY.Indication whenever a beacon is received. We apply this method for each selected channel. Finally, the device receives a MLME-SCAN.Confirm with a status of SUCCESS. This process allows us to locate specific Coordinators based on our desired filters, making the scan more targeted and efficient.

3.1.9.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 arguments of this API are:

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. Supportes 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.
a_key_source	The originator of the key to be used for the scan. Not used in Security level 0.	uint8_t.
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.9.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 arguments of this API are:

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

MAC_scanCnf_t structure parameters:

Parameter	Description	Type	Valid range
ScanType	The type of scan performed.	uint8_t	ED, ACTIVE, PASSIVE, ORPHAN, ENHANCED_ACTIVE_ SCAN
ChannelPage	The channel page on which the scan was performed, always 0 for non-beacon-PAN.	uint8_t	0
Unscanned Channels	A list of the channels given in the request that were not scanned. This parameter is not valid for ED scans.	uint32_t	Any list of valid channels
ResultListSize	The number of elements returned in the appropriate result lists. This value is zero for the result of an orphan scan.	uint8_t	-
EnergyDetectList	The list of energy measurements, one for each channel searched during an ED scan. This parameter is null for active, passive, and orphan scans.	List of integers	0x00–0xFF for each integer
PanDescriptorList	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.	List of PAN descriptor values	-
Status	The status of the scan request.	uint8_t	SUCCESS, LIMIT_REACHED, NO_BEACON, SCAN_IN_PROGRESS, BAD_CHANNEL, 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.9.3. MLME-ORPHAN.indication

This API is used to indicate 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 arguments of this API are:

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

MAC_orphanInd_t structure parameters:

Parameter	Description	Type	Valid range
OrphanAddress	The address of the orphaned device.	uint64_t	Any valid extended address
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.	-
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.9.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 arguments of this API are:

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

MAC_orphanRes_t structure parameters:

Parameter	Description	Type	Valid range
OrphanAddress	The address of the orphaned device.	Extended address	Any valid extended address
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.	-
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. MLME-START

The MLME-START primitive is used by a device to start a new network formation process or join an existing network. By using the MLME-START primitive, a device can become a coordinator or join an existing network as a device.

3.1.10.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 or to reconfigure the superframe structure of an existing PAN. When a new PAN is initiated, the MAC layer configures the superframe structure accordingly. If the network is reconfigured, the MAC layer of the coordinator will send out a Coordinator Realignment command with the new parameters. Devices already associated with the PAN will receive the updated superframe configuration and make the necessary adjustments.

MAC_Status_t MAC_MLMEStartReq( const  MAC_startReq_t * pStartReq);

The arguments of this API are:

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
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. If this value is FALSE, the device will begin using a new superframe configuration on the PAN with which it is associated.	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.
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.

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, we cannot start a network with the PANID = 0xFFFF. According to the standard, we can initiate the network, but we cannot send a frame with a short address in this case. Even if we associate, it is recommended to remove this address from the PANID and return an INVALID_PARAMETER error.

3.1.10.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 arguments of this API are:

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 annex list

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

3.1.11. MLME-POLL

The Poll primitives enable a device to extract indirect data from the coordinator. In the following analysis, we will examine two scenarios: one without indirect data in the coordinator and the second with indirect data inside the coordinator.
In the first case, the device uses the MLME-POLL.Request primitive to send a MAC Data Request to the coordinator over the air. The coordinator responds with an Ack with the frame pending set to 0 (indicating there is no pending data for the device) and receives an MLME-POLL.indication. When the device receives the ACK, it's MAC sends an MLME-POLL.Confirm to higher layer with the status set to NO_DATA.
In the second case, the coordinator prepares an indirect data with the MCPS-DATA.Request with the parameter IndirectTx set to True. 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, we have the same scenario as the first case, but in the ACK, the frame pending is set to 1. As a result, a MAC Data is sent to the device. Finally, the device receives an MLME-POLL.Confirm with the status set to SUCCESS and an MCPS-DATA.Indication.

3.1.11.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 arguments of this API are:

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.
coord_address	Coordinator address.	MAC_addr_t.
security_level	The security level to be used for the scan. Supportes 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.
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.11.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
AddrMode	Addressing mode of the device requesting pending data	uint8_t	0x02 - 0x03
DeviceAddress	The address of the device requesting pending data.	-	As specified by AddrMode parameter.

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

3.1.11.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 arguments of this API are:

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 annex list

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

3.1.12. MLME NOT IMPLEMENTED

3.1.12.1. MLME-CALIBRATE.request

MLME-CALIBRATE.request is not supported on both WB and WBA. This feature is useful for the RDEV(ranging-capable device). The MLME-CALIBRATE.request primitive attempts to have the PHY respond with RMARKER offset information.

What is RDEV: Ranging is an optional feature. It is used to obtain the frame time between sending the frame and receiving the ACK, in order to know the distance separating it from another device.

The return value of this API is MAC_NOT_SUPPORTED_STATUS

3.1.12.2. MLME-CALIBRATE.confirm

CALIBRATE confirm not supported on both WB and WBA.

The return value of this API is MAC_NOT_SUPPORTED_STATUS

3.1.12.3. MLME-DPS.request

DPS request is not supported on both WB and WBA. This feature is useful for the HRP UWB PHY. The MLME-DPS.request primitive allows the next higher layer to request that the PHY utilize a given pair of preamble codes for a single use pending expiration of the DpsIndexDuration.

The return value of this API is MAC_NOT_SUPPORTED_STATUS

3.1.12.4. MLME-DPS.confirm

DPS confirm is not supported on both WB and WBA.

The return value of this API is MAC_NOT_SUPPORTED_STATUS

3.1.12.5. MLME-SYNC.request

SYNC request is not supported on both WB and WBA. This feature is useful for beacon-PAN. The MLME-SYNC.request primitive requests to synchronize with the coordinator by acquiring and, if specified, tracking its beacons.

The return value of this API is MAC_NOT_SUPPORTED_STATUS

3.1.12.6. MLME-SYNC.confirm

SYNC confirm is not supported on both WB and WBA.

The return value of this API is MAC_NOT_SUPPORTED_STATUS

3.1.12.7. MLME-GTS.request

GTS request is not supported on both WB and WBA. This feature is useful for beacon-PAN. The MLME-GTS.request primitive allows a device to send a request to the PAN coordinator to allocate a new GTS or to deallocate an existing GTS. This primitive is also used by the PAN coordinator to initiate a GTS deallocation.

The return value of this API is MAC_NOT_SUPPORTED_STATUS

3.1.12.8. MLME-GTS.confirm

GTS confirm is not supported on both WB and WBA.

The return value of this API is MAC_NOT_SUPPORTED_STATUS

3.1.12.9. MLME-SOUNDING.request

SOUNDING request is not supported on both WB and WBA. This feature is useful for the RDEV(ranging-capable device). The MLME-SOUNDING.request primitive is used by the next higher layer to request that the PHY respond with channel sounding information.

The return value of this API is MAC_NOT_SUPPORTED_STATUS

3.1.12.10. MLME-SOUNDING.confirm

SOUNDING confirm is not supported on both WB and WBA.

The return value of this API is MAC_NOT_SUPPORTED_STATUS

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 start 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 sniffer 802.15.4 / Zigbee / Thread protocols how to configurate sniffer

In the WB package, we have some examples that allow you to demonstrate certain features:

MAC_802_15_4_Coordinator: You can create a MAC coordinator and have devices associate with it through the Node project. During startup, the coordinator selects the best channel using an energy detector scan, followed by two active scans to create a list of PANIDs. A random PANID is then generated that is not in the list, and the coordinator is ready to receive association requests from the Node. You can 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: You can create a MAC Node and associate it with the 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 PANID, 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 is associated with it and 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: You can create a Low Power Mode application sending frame every second. This application allows to demonstrate two modes on low power: STOP1 and STANDBY, can be manage in configuration project.

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 1 MB Flash and 128KB of SRAM

The first evaluation board is the NUCLEO-WBA52CG board with STM32WBA52CG UQFN48' package

In the WBA package, we have some examples that allow you to demonstrate certain features:

MAC_802_15_4_Coordinator: You can create a MAC coordinator and have devices associate with it through the Node project. During startup, the coordinator selects the best channel using an energy detector scan, followed by two active scans to create a list of PANIDs. A random PANID is then generated that is not in the list, and the coordinator is ready to receive association requests from the Node. You can 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: You can create a MAC Node and associate it with the 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 PANID, 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 is associated with it and 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: You can create a Low Power Mode application sending frame every second. This application allows to demonstrate two modes on low power: STOP1 and STANDBY, can be manage in configuration project.

4.1. Terms and definition

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
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. Frame format

2.8. ACK

2.9. IFS

2.10. Primitive categories

2.11. Different Scans

2.12. Information Element

3. General Architecture

3.1. MAC layer and 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.3.5. MLME-COMM-STATUS.indication

3.1.4. MLME-BEACON

3.1.4.1. MLME-BEACON.request

3.1.4.2. MLME-BEACON.confirm

3.1.4.3. MLME-BEACON-NOTIFY.indication

3.1.4.4. MLME-BEACON-REQUEST.indication

3.1.4.5. MLME-SYNC-LOSS.indication

3.1.5. MLME-DISASSOCIATE

3.1.5.1. MLME-DISASSOCIATE.request

3.1.5.2. MLME-DISASSOCIATE.indication

3.1.5.3. MLME-DISASSOCIATE.confirm

3.1.6. MLME-GET / MLME-SET / MLME-RESET

3.1.6.1. MLME-GET.request

3.1.6.2. MLME-GET.confirm

3.1.6.3. MLME-SET.request

3.1.6.4. MLME-SET.confirm

3.1.7. MLME-RESET.request

3.1.7.1. MLME-RESET.confirm

3.1.8. MLME-RX-ENABLE

3.1.8.1. MLME-RX-ENABLE.request

3.1.8.2. MLME-RX-ENABLE.confirm

3.1.9. MLME-SCAN

3.1.9.1. MLME-SCAN.request

3.1.9.2. MLME-SCAN.confirm

3.1.9.3. MLME-ORPHAN.indication

3.1.9.4. MLME-ORPHAN.response

3.1.10. MLME-START

3.1.10.1. MLME-START.request

3.1.10.2. MLME-START.confirm

3.1.11. MLME-POLL

3.1.11.1. MLME-POLL.request

3.1.11.2. MLME-POLL.indication

3.1.11.3. MLME-POLL.confirm

3.1.12. MLME NOT IMPLEMENTED

3.1.12.1. MLME-CALIBRATE.request

3.1.12.2. MLME-CALIBRATE.confirm

3.1.12.3. MLME-DPS.request

3.1.12.4. MLME-DPS.confirm

3.1.12.5. MLME-SYNC.request

3.1.12.6. MLME-SYNC.confirm

3.1.12.7. MLME-GTS.request

3.1.12.8. MLME-GTS.confirm

3.1.12.9. MLME-SOUNDING.request

3.1.12.10. MLME-SOUNDING.confirm

3.2. PHY layer

4. Getting start with STM32

4.1. With STM32WB

4.2. With STM32WBA

4.1. Terms and definition