The 802.11 Application Framework provides a standard compliant 802.11a, 802.11g, and 802.11ac OFDM PHY layer thereby ensuring reliability of system measurements. The focus in the current version of the 802.11 Application Framework is to provide key infrastructure blocks in the FPGA required for MAC algorithm development. The following sections describe these features.
The MAC service data unit (MSDU) is provided by the host code as shown in Figure 4. The host can generate a random packet or connect to a user datagram protocol (UDP) source. Application traffic can be supported through UDP or natively by modifying the host code. The MSDU for transmission and the relevant PHY and MAC configuration parameters for the packet are provided to the FPGA which implements the lower MAC and PHY functionality, creating the MAC protocol data unit (MPDU) and the PHY protocol data unit (PPDU). The reverse process happens in the receiver. The received MSDU can be optionally forwarded to a UDP data sink. The lower MAC and PHY blocks in the FPGA communicate through the interface described in Section "PHY-MAC Interface".
Figure 4: Protocol Layering in LabVIEW Communications 802.11 Application Framework
To enhance the modifiability of the Application Framework, the interface between PHY and MAC follows the physical layer service access point (PHY-SAP) interface and the concept of PHY sublayer-to-sublayer service primitives defined in the standard . For the sake of simplicity, the content of those PHY service primitives is aligned with the implemented feature set. Figure 5 shows a sequence of PHY service primitives in use during a regular transmit and receive operation. In the current version of the application framework, only the following essential sublayer-to-sublayer primitives are implemented:
Figure 5: PHY Service Primitive Sequence Chart for Typical Tx and Rx
TXVECTOR represents a list of parameters that is provided by the TX-START.request. The list of parameters provided in the current framework are as follows:
- PPDU format (802.11a, 802.11ac)
- Packet length
- Modulation and coding scheme (MCS)
- TX power level
- Scrambler seed
The receiver implementation does not auto-detect PPDU format and bandwidth. Thus, these settings must be known at both nodes. The receiver can adapt to varying packet length and MCS from the appropriate header fields.
The PHY-DATA.request and PHY-DATA.confirm primitives are not explicitly implemented. Instead, LabVIEW FPGA FIFO is used to transfer the MPDU between the PHY and MAC.
The interface does not support early termination initiated by the MAC. The primitives PHY-TXEND.request and PHY-TXEND.confirm, which are meant to provide TX early termination support, are not implemented. Instead, a PHY-TXEND.indication is provided. This primitive is used by PHY to inform the MAC that the transmission request has been processed.
Interface Error Handling
The PHY implementation in the FPGA checks that the TXVECTOR provided by the PHY-TXSTART.request primitive indicates a valid configuration. If not, the request is ignored and a PHY-TXEND.indication is sent to the MAC. Otherwise, the request is processed normally. The TX MAC implementation ensures that the data bytes for a packet is available before sending the PHY-TXSTART.request; thus, the FPGA code is not expected to produce additional error conditions during the transmission. On the RX side, similarly, the PHY implementation does consistency checks on the signaling fields before generating the RX primitives to the MAC layer.
MAC Frame Formats
The application framework implements a compliant MAC frame and supports frame types data and ACK shown in Figure 6 and Figure 7, respectively. Hooks are provided in the FPGA code to create and recognize other frame types using the type and subtype information in the frame control field of MAC header, but the code does not process them.
Figure 6. Structure of MAC Data Frame
Figure 7. Structure of MAC ACK Frame
For data frames, the frame body carries the MSDU provided by the host code. The FCS field consists of 32-bit CRC as specified in the standard. At the receiver side, FCS check and address check are done on the FPGA, and MSDU extracted from valid data frames is provided to the host code. For debugging and logging purposes, invalid frames, such as frames with header errors or FCS errors, as well as frames directed at other users, can also be optionally forwarded to the host code from FPGA.
The following notes for the MAC header implementation in the code must be taken into account:
- In the Frame Control field (Figure 8), all bits are filled with 0 except for Type and Subtype.
- The Duration/ID field is set to 0.
- In the Sequence Control field, the Sequence Number is incremented for every packet sent. The Fragment Number is set to 0 since fragmentation is not implemented.
- HT Control and QoS Control fields are not implemented.
Figure 8: Structure of Frame Control Field in MAC Header
Support is provided in the code for users to develop these features. For example, the frame configuration cluster communicated between the modules includes a Duration/ID field, and the MAC frame header generation module packages that into the generated header.
As specified by the standard, all 802.11ac packets use aggregate MPDU (A-MPDU) format. However, support in this version is limited to A-MPDUs that consists of a single MPDU. Aggregation and fragmentation of MSDU are not supported. For fragmentation of MSDU, a simple extension of the host code can be created, and the Fragment Number field must be populated.
Address 1 and Address 2 fields in the MAC frame are utilized for destination and source MAC address, respectively. The destination MAC address is user-configurable from the host and can be programmatically changed on a per packet basis.
Address 3 and Address 4 fields are not used. By default, the Address 3 field is set to 0, and the data frame is sent using “To DS” and “From DS” subfields in the Frame Control field (Figure 8) when the MAC header is set to 0. This means that Address 4 field in the MAC header is not present in the transmitted MAC frame. Sufficient hooks are provided in the transmitter and receiver FPGA code to enable modifications that need these fields. For example, the receiver checks the “To DS” and “From DS” fields to ensure that it correctly processes packets with or without Address 4.
An FPGA-based timing infrastructure is used to meet the accuracy required by the timing specifications of the MAC. The timing parameters Slot Time, DIFS, SIFS and extended inter-frame space (EIFS) are provided. A global timestamp is used to track and schedule events. Time-stamped events on the FPGA are also passed to the host for debugging and logging purposes.
If a node receives a data frame with a valid FCS and with matching destination address, it responds to the source address with an ACK. The 802.11 Application Framework meets the SIFS requirement (Figure 2). The SIFS timing generated by the MAC timing module on the FPGA is calibrated for any delay through the up conversion, down conversion, RF paths, and so on. More details are provided in the 802.11 Application Framework white paper . The ACK transmission can be optionally disabled.
Energy detection-based (ED) and signal detection-based (SD) physical carrier sensing mechanisms are implemented in the PHY. CCA-ED is useful in detecting non-802.11 traffic and has a user configurable threshold. CCA-SD is 802.11 specific and depends on the fact that all 802.11 packets start with the same preamble. The PHY provides a CCA indication cluster to the MAC containing the status of energy detection and signal detection, which is used by the DCF MAC for its operation. The functionality provided by the PHY CCA can also be utilized to implement other LBT protocols and more general channel sensing based adaptation techniques (for example, LTE-U) .
Virtual Carrier Sensing
Virtual carrier sensing mechanisms such as network allocation vector (NAV) and RTS-CTS exchange are not implemented. The DATA-ACK exchange can be used as a template to develop RTS-CTS exchange if you require this feature.
EIFS is implemented, and the packet will defer using this period, if a frame is detected but not correctly received (for example, MAC FCS failure). The EIFS is defined by the following equation. It is demonstrated in Figure 9 where the transmission from Node A cannot reach Node C, but Node B and C can reach each other. This leads to a hidden node scenario, and the use of EIFS enables the ACK from Node A to avoid potential collision due to a transmission from Node C.
Figure 9. EIFS used by Node C
The carrier sense functionality required by CSMA is implemented as described in Section "Clear Channel Assessment". The MAC timing module provides support deferring for DIFS deferring and the slot timing required to count back-off. A back-off value can be sent along with each transmission request forwarded to the lower MAC layer in the FPGA. This value is loaded into a back-off counter which counts down as described in Section 2.1 "802.11 DCF MAC". In the application framework, the back-off value is set as constant from the host; thus, each transmission request uses this value. Variable back-off can be supported by adding an extension to the FPGA code to modify the back-off value in the transmission request.
One key feature not implemented in this version is re-transmission. To extend the application framework to support re-transmission, store the generated MPDU on the FPGA using Block RAM or DRAM and access the MPDU from this memory location if the ACK is not received within the expected time period.
Per-Packet Automatic Gain Control (AGC)
This is, strictly speaking, a PHY feature, but it is mentioned here since it is an important one for optimal operation in multi-node multiple access environment. As expected by the 802.11 specifications, the AGC level at the receiver is set for each received frame independent of other frames using the PHY training fields present at the beginning of each PHY frame. The settling time is fast enough that the signal detection and other operations can complete successfully.