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.
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.
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 |
Pages in category "802 15 4"
The following 4 pages are in this category, out of 4 total.