This module describes all MCL Request API's.
Functions | |
| void | mcps_data_request (uint8_t *msg) |
| Builds the data frame for transmission. More... | |
| void | mcps_purge_request (uint8_t *msg) |
| Processes a MCPS-PURGE.request primitive. More... | |
| void | mlme_associate_request (uint8_t *m) |
| Handles the MLME associate request command from the NWK layer. More... | |
| void | mlme_disassociate_request (uint8_t *m) |
| Handles the MLME disassociate request command from the NWK layer. More... | |
| void | mlme_get_request (uint8_t *m) |
| Handles an MLME-GET.request. More... | |
| void | mlme_poll_request (uint8_t *m) |
| Implements MLME-POLL.request. More... | |
| void | mlme_reset_request (uint8_t *m) |
| Resets the MAC layer. More... | |
| void | mlme_rx_enable_request (uint8_t *m) |
| Implement the MLME-RX-ENABLE.request primitive. More... | |
| void | mlme_scan_request (uint8_t *m) |
| The MLME-SCAN.request primitive makes a request for a node to start a scan procedure. More... | |
| void | mlme_start_request (uint8_t *m) |
| The MLME-START.request primitive makes a request for the device to start using a new superframe configuration. More... | |
| void | mlme_sync_request (uint8_t *m) |
| Implements the MLME-SYNC request. More... | |
| void mcps_data_request | ( | uint8_t * | msg | ) |
Builds the data frame for transmission.
This function builds the data frame for transmission. The NWK layer has supplied the parameters. The frame_info_t data type is constructed and filled in. Also the FCF is constructed based on the parameters passed.
| msg | Pointer to the MCPS-DATA.request parameter |
| void mcps_purge_request | ( | uint8_t * | msg | ) |
Processes a MCPS-PURGE.request primitive.
This functions processes a MCPS-PURGE.request from the NHLE. The MCPS-PURGE.request primitive allows the next higher layer to purge an MSDU from the transaction queue. On receipt of the MCPS-PURGE.request primitive, the MAC sublayer attempts to find in its transaction queue the MSDU indicated by the msduHandle parameter. If an MSDU matching the given handle is found, the MSDU is discarded from the transaction queue, and the MAC sublayer issues the MCPSPURGE. confirm primitive with a status of MAC_SUCCESS. If an MSDU matching the given handle is not found, the MAC sublayer issues the MCPS-PURGE.confirm primitive with a status of INVALID_HANDLE.
| msg | Pointer to the MCPS-PURGE.request parameter |
| void mlme_associate_request | ( | uint8_t * | m | ) |
Handles the MLME associate request command from the NWK layer.
The MLME associate request primitive is generated by the next higher layer of an unassociated device and issued to its MAC to request an association with a coordinator.
| m | Pointer to MLME association request parameters |
| void mlme_disassociate_request | ( | uint8_t * | m | ) |
Handles the MLME disassociate request command from the NWK layer.
The MLME-DISASSOCIATE.request primitive is generated by the next higher layer of an associated device and issued to its MLME to request disassociation from the PAN. It is also generated by the next higher layer of the coordinator and issued to its MLME to instruct an associated device to leave the PAN.
| m | Pointer to the MLME-DISASSOCIATION.Request message passed by NHLE |
| void mlme_get_request | ( | uint8_t * | m | ) |
Handles an MLME-GET.request.
This function handles an MLME-GET.request. The MLME-GET.request primitive requests information about a given PIB attribute.
| m | Pointer to the request structure |
| void mlme_poll_request | ( | uint8_t * | m | ) |
Implements MLME-POLL.request.
This function handles an MLME-POLL.request primitive. The MLME-POLL.request primitive is generated by the next higher layer and issued to its MLME when data are to be requested from a coordinator.
| m | Pointer to the message |
| void mlme_reset_request | ( | uint8_t * | m | ) |
Resets the MAC layer.
The MLME-RESET.request primitive allows the next higher layer to request that the MLME performs a reset operation.
| m | Pointer to the MLME_RESET.request given by the NHLE |
| void mlme_rx_enable_request | ( | uint8_t * | m | ) |
Implement the MLME-RX-ENABLE.request primitive.
The MLME-RX-ENABLE.request primitive is generated by the next higher layer and issued to MAC to enable the receiver for a fixed duration, at a time relative to the start of the current or next superframe on a beacon-enabled PAN or immediately on a nonbeacon-enabled PAN. The receiver is enabled exactly once per primitive request.
| m | Pointer to the MLME-RX-ENABLE.request message |
| void mlme_scan_request | ( | uint8_t * | m | ) |
The MLME-SCAN.request primitive makes a request for a node to start a scan procedure.
802.15.4. Section 7.1.11.1.
The MLME-SCAN.request primitive is used to initiate a channel scan over a given list of channels. A device can use a channel scan to measure the energy on the channel, search for the coordinator with which it associated, or search for all coordinators transmitting beacon frames within the POS of the scanning device.
The MLME-SCAN.request primitive is generated by the next higher layer and issued to its MLME to initiate a channel scan to search for activity within the POS of the device. This primitive can be used to perform an ED scan to determine channel usage, an active or passive scan to locate beacon frames containing any PAN identifier, or an orphan scan to locate a PAN to which the device is currently associated.
ED or active scans can be performed before an FFD starts operation as a PAN coordinator. Active or passive scans can be performed prior to selecting a PAN for association. Orphan scans can be performed to attempt to locate a specific coordinator with which communication has been lost.
All devices shall be capable of performing passive scans and orphan scans; ED scans and active scans are optional for an RFD.
When the MLME receives the MLME-SCAN.request primitive, it initiates a scan in all channels specified in the ScanChannels parameter. The MLME suspends all beacon transmissions for the duration of the scan. During a scan, the MAC sublayer only accepts frames received over the PHY data service that are relevant to the scan being performed (see 7.5.2.1).
An ED scan allows a device to obtain a measure of the peak energy in each requested channel. The ED scan is performed on each channel by the MLMEs repeatedly issuing the PLME-ED.request primitive to the PHY until [aBaseSuperframeDuration * (2n + 1)] symbols, where n is the value of the ScanDuration parameter, have elapsed. The MLME notes the maximum energy measurement and moves on to the next channel in the channel list. A device will be able to store between one and an implementation-specified maximum number of channel ED measurements. The ED scan terminates when the number of channel ED measurements stored equals this implementation-specified maximum or when every channel specified in the channel list has been scanned.
An active scan is used by an FFD to locate all coordinators transmitting beacon frames within its POS. The active scan is performed on each channel by the MLMEs first sending a beacon request command (see 7.3.2.4). The MLME then enables the receiver and records the information contained in each received beacon in a PAN descriptor structure (see Table 41 in 7.1.5.1.1). A device will be able to store between one and an implementation-specified maximum number of PAN descriptors. The active scan on a particular channel terminates when the number of PAN descriptors stored equals this implementation-specified maximum or when [aBaseSuperframeDuration*(2n + 1)] symbols, where n is the value of the ScanDuration parameter, have elapsed. If the latter condition has been satisfied, the channel is considered to have been scanned. Where possible, the scan is repeated on each channel and terminates when the number of PAN descriptors stored equals the implementation-specified maximum or when every channel in the set of available channels has been scanned.
A passive scan, like an active scan, is used to locate all coordinators transmitting beacon frames within the POS of the scanning device; the difference is that the passive scan is a receive-only operation and does not transmit the beacon request command. The passive scan is performed on each channel by the MLMEs enabling its receiver and recording the information contained in each received beacon in a PAN descriptor structure (see Table 41 in 7.1.5.1.1). A device will be able to store between one and an implementation-specified maximum number of PAN descriptors. The passive scan on a particular channel terminates when the number of PAN descriptors stored equals this implementation-specified maximum or when [aBaseSuperframeDuration * (2n + 1)] symbols, where n is the value of the ScanDuration parameter, have elapsed. If the latter condition has been satisfied, the channel is considered to have been scanned. Where possible, the scan is repeated on each channel and terminates when the number of PAN descriptors stored equals the implementation-specified maximum or when every channel in the set of available channels has been scanned.
An orphan scan is used to locate the coordinator with which the scanning device had previously associated. The orphan scan is performed on each channel by the MLME first sending an orphan notification command (see 7.3.2.3). The MLME then enables its receiver for at most aResponseWaitTime symbols. If the device receives a coordinator realignment command within this time, the MLME will disable its receiver. Otherwise, the scan is repeated on the next channel in the channel list. The scan terminates when the device receives a coordinator realignment command (see 7.3.2.5) or when every channel in the set of available channels has been scanned.
The results of an ED scan are recorded in a list of ED values and reported to the next higher layer through the MLME-SCAN.confirm primitive with a status of MAC_SUCCESS. The results of an active or passive scan are recorded in a set of PAN descriptor values and reported to the next higher layer through the MLME-SCAN.confirm primitive. If no beacons were found, the MLME-SCAN.confirm primitive will contain a null set of PAN descriptor values and a status of NO_BEACON. Otherwise, the MLME-SCAN.confirm primitive will contain the set of PANDescriptor values found, a list of unscanned channels, and a status of MAC_SUCCESS.
The results of an orphan scan are reported to the next higher layer through the MLME-SCAN.confirm primitive. If successful, the MLME-SCAN.confirm primitive will contain a status of MAC_SUCCESS. If the device did not receive a coordinator realignment command, MLME-SCAN.confirm primitive will contain a status of NO_BEACON. In either case, the PANDescriptorList and EnergyDetectList parameters of the MLMESCAN.confirm primitive are null.
If any parameter in the MLME-SCAN.request primitive is not supported or is out of range, the MAC sublayer will issue the MLME-SCAN.confirm primitive with a status of MAC_INVALID_PARAMETER.
| m | The MLME_SCAN.request message |
| void mlme_start_request | ( | uint8_t * | m | ) |
The MLME-START.request primitive makes a request for the device to start using a new superframe configuration.
| m | Pointer to MLME_START.request message issued by the NHLE |
| void mlme_sync_request | ( | uint8_t * | m | ) |
Implements the MLME-SYNC request.
The MLME-SYNC.request primitive requests to synchronize with the coordinator by acquiring and, if specified, tracking its beacons. The MLME-SYNC.request primitive is generated by the next higher layer of a device on a beacon-enabled PAN and issued to its MLME to synchronize with the coordinator.
Enable receiver and search for beacons for at most an interval of [aBaseSuperframeDuration * ((2 ^ (n))+ 1)] symbols where n is the value of macBeaconOrder. If a beacon frame containing the current PAN identifier of the device is not received, the MLME shall repeat this search. Once the number of missed beacons reaches aMaxLostBeacons, the MLME shall notify the next higher layer by issuing the MLME-SYNC-LOSS.indication primitive with a loss reason of BEACON_LOSS.
| m | Pointer to the MLME sync request parameters. |
1.8.5