SWCU192 November 2021 CC1312R7 , CC1352P7 , CC2652P7 , CC2652R7
26.5.4.3 CSMA-CA Operation
The CSMA-CA operation is a foreground-level operation that runs on top of a receive or energy-detect scan operation. If run on top of an energy-detect scan operation, this does not perform the energy-detect scan procedure, but starts a receiver without having to receive packets. This operation starts with the CMD_IEEE_CSMA command, and uses the command structure given in Table 26-64.
At the start of a CSMA-CA operation, the radio CPU waits for the start trigger.
The radio CPU maintains a variable CW, which initializes to csmaConfig.initCW.
If remainingPeriods is nonzero at the start of the command, the radio CPU delays for that number of backoff periods (default 320 µs) measured from the start trigger before proceeding. Otherwise, the radio CPU draws a pseudo-random number in the range 0 to 2(BE)–1, where BE is listed in Table 26-64. The radio CPU then waits that number of backoff periods from the start trigger before proceeding.
After this wait time, the radio CPU checks the CCA state from the background-level operation, as described in Section 26.5.4.1.5. If the CCA state was INVALID, the radio CPU waits before trying again. If csmaConfig.bSlotted = 1, the wait is for one backoff period, otherwise it waits until an RSSI result is available. If the CCA state was IDLE, the radio CPU decrements CW by 1, and if this results in a value of zero, the CSMA-CA operation ends with success. If this results in a nonzero value, the radio CPU waits one backoff period timed from the end of the wait time, and then checks the CCA state again as described previously.
If the channel was BUSY when the CCA state was checked, the radio CPU updates the variables as follows:
CW = csmaConfig.initCW; NB + = 1; BE + = min (BE + 1, macMaxBE);
If NB after this update is greater than macMaxCSMABackoffs, the CSMA-CA operation ends with failure. Otherwise, the radio CPU draws a random number of backoff periods to wait as described previously, and proceeds as before. If csmaConfig.bSlotted = 1, the wait is from the next backoff period after the end of the previous wait time; otherwise, the wait is from a configurable time after the end of the previous wait time.
Figure 26-7 shows the flow chart for the CSMA-CA operation.
In addition to the CSMA-CA operation ending with success or failure as previously described, the operation can end as a result of the end trigger given by endTrigger and endTime, or by a command. The commands that can end the CSMA-CA operation are the immediate commands CMD_ABORT, CMD_STOP, CMD_IEEE_ABORT_FG, and CMD_IEEE_STOP_FG. When the CSMA-CA operation ends, the radio CPU writes lastTimeStamp with the timer value at the end of the most recent wait period before a CCA check was done, and lastRssi with the RSSI value at that time. If the operation ended because of a timeout or stop command, the radio CPU writes remainingPeriods with the number of backoff periods remaining of the wait time. Otherwise, the radio CPU writes remainingPeriods to 0.
The pseudo-random algorithm is based on a maximum-length 16-bit linear-feedback shift register (LFSR). The seed is as provided in randomState. When the operation ends, the radio CPU writes the current state back to this field. If randomState is 0, the radio CPU self-seeds by initializing the LFSR to the 16 LSBs of the radio timer. There is some randomness to this value, but this is limited, especially for slotted CSMA-CA, and seeding with a true-random number (or a pseudo-random number based on a true-random seed) by the system CPU is therefore recommended. If the 16 LSBs of the radio timer are all 0, another fixed value is substituted.
Depending on csmaConfig.rxOffMode, the underlying RX operation may be suspended during the backoff before another CCA check, if there is enough time for it. The different values have the following meaning:
- rxOffMode = 0: The radio stays on during CSMA backoffs.
- rxOffMode = 1: If a frame is being received, an ACK being transmitted, or in the transition between those, the radio stays on. Otherwise, the radio switches off until the end of the backoff period.
- rxOffMode = 2: If a frame is being received, an ACK being transmitted, or in the transition between those, the radio stays on until the packet is fully received and the ACK is transmitted if applicable. After that, the radio switches off until the end of the backoff period.
- rxOffMode = 3: The radio switches off immediately at the beginning of a backoff period. This aborts a frame being received or an ACK being transmitted. The radio remains switched off until the end of the backoff period.
If the radio switches off this way, the receiver restarts sufficiently early for the next CCA operation to be done, and the radio only switches off it there is sufficient time. This feature can be used for power saving in systems that do not always need to be in RX. All modes except mode 0 may cause frames to be lost, at increasing probability.
Figure 26-7 CSMA-CA OperationFor operation according to IEEE 802.15.4, the parameters must be initialized as follows before starting a new CSMA-CA operation:
- randomState must be set to a random value
- csmaConfig.initCW must be set to 2 for slotted CSMA-CA and 1 for unslotted CSMA-CA
- csmaConfig.bSlotted must be set to 1 for slotted CSMA-CA and 0 for unslotted CSMA-CA
- NB must be set to 0
- BE must be set to macMinBE, except for slotted CSMA-CA with battery-life extension, where BE must be set to min (2, macMinBE)
- remainingPeriods must be set to 0
- macMaxBE and macMaxCSMABackoffs must be set to their corresponding MAC PIB attribute
For slotted CSMA-CS, startTrigger must be set up to occur on a backoff-slot boundary. For slotted CSMA-CA, the endTrigger must be set up to occur at the latest time that the transaction can be completed within the superframe, as specified in the IEEE 802.15.4 standard. If the CSMA-CA ends due to timeout, the CSMA can be restarted without modifying the parameters (except possibly the end time) at the next superframe.
Table 26-85 lists the causes of a CSMA-CA operation end. The status field of the command structure after the command has ended indicates the reason why the operation ended. In all cases, an FG_COMMAND_DONE interrupt is raised. In each case, it is indicated if the result is TRUE, FALSE, or ABORT. This indicates whether to start the next command (if any) in pNextOp, or to return to an IDLE state.
| Condition | Status Code | Result |
|---|---|---|
| CSMA-CA operation finished with success | IEEE_DONE_OK | TRUE |
| CSMA-CA operation finished with failure | IEEE_DONE_BUSY | FALSE |
| End trigger occurred | IEEE_DONE_TIMEOUT | FALSE |
| Received CMD_STOP or CMD_IEEE_STOP_FG | IEEE_DONE_STOPPED | FALSE |
| Received CMD_ABORT or CMD_IEEE_ABORT_FG | IEEE_DONE_ABORT | ABORT |
| Background operation ended | IEEE_DONE_BGEND | ABORT |
| Observed illegal parameter | IEEE_ERROR_PAR | ABORT |
When the operation ends, the time of the last CCA check (that is, the time written into lastTimeStamp) is defined as event 1, and may be used for timing subsequent chained operations.