Standalone Access Point (AP)¶

The Standalone Access Point application for CPU High implements a standard 802.11 infrastructure AP. The AP design supports the standard association handshake and will associate with standard Wi-Fi clients as well as the STA design.

The Standalone AP application can only on a node which is not running Linux. Nodes running Linux must use the linux_dev application in CPU High.

Fig. 4.1 Typical AP Network

The AP supports the Ethernet portal behaviors described in the 802.11-2012 standard Annex P. Standard Wi-Fi clients may access the internet through the AP by connecting the AP’s bridged Ethernet interface to an Ethernet network with internet access.

BSS Configuration¶

An 802.11 wireless network is defined by a set of parameters called the Basic Service Set (BSS). BSS parameters are defined in the bss_config_t (see High MAC Framework BSS Configuration). AP-specific requirements for these fields are listed below:

Parameter	Description
`u8 bssid[6]`	Must be the wireless MAC address of the AP. Any other value will produce a `BSS_CONFIG_FAILURE_BSSID_INVALID` error in the return value from `configure_bss()`.
`u16 beacon_interval`	Must be >= 10. Otherwise will produce a `BSS_CONFIG_FAILURE_BEACON_INTERVAL_INVALID` error in the return value from `configure_bss()`.
`u8 dtim_period`	Must be >= 1. A value of zero will produce a `BSS_CONFIG_FAILURE_DTIM_PERIOD_INVALID` error in the return value from `configure_bss()`.

The configure_bss() function manages the state of the BSS in the AP application. This function has prototype:

u32 configure_bss(bss_config_t* bss_config, u32 update_mask);

The return value and function arguments are defined as follows:

Parameter	Description
Return value (`u32`)	0 if the function executes without error. Otherwise, a bitmask of error flags.
`bss_config_t* bss_config`	Pointer to a `bss_config_t` that contains updated parameters.
`u32 update_mask`	Bitmask for fields that must be updated. Valid values are combinations of `BSS_FIELD_MASK_BSSID`, `BSS_FIELD_MASK_CHAN`, `BSS_FIELD_MASK_SSID`, `BSS_FIELD_MASK_BEACON_INTERVAL`, `BSS_FIELD_MASK_HT_CAPABLE`, `BSS_FIELD_MASK_DTIM_PERIOD`

Ethernet Rx¶

When an Ethernet frame is received, the High MAC Framework encapsulates the payload and passes it to the AP for further processing. If the destination address of the received Ethernet frame is multicast, the packet is immediately enqueued in the MCAST_QID queue. If the destination address of the received Ethernet frame is unicast, the AP checks whether the destination addresses matches any associated stations. If so the AP enqueues the packet in the selected station’s queue, otherwise the packet is dropped.

Wireless Rx¶

When the AP receives a wireless 802.11 frame that is successfully decoded, it first sets a number of internal boolean variables used later in the processing:

Parameter	Description
`unicast_to_me`	Received frame has an `RA` that matches the MAC address of the AP
`to_multicast`	Received frame has an `RA` with the multicast bit set high
`sta_is_associated`	Received frame has a `TA` that matches an associated station
`sta_is_authenticated`	Received frame has a `TA` that matches an authenticated station

The AP also checks the sequence number of a received frame and compares it to the sequence number of the most recently received frame from the same transmitter. This check allows the AP to drop duplicate packets.

Next, the AP then examines the received 802.11 frame’s packet type and processes each differently:

QoS Data or Data¶

If unicast_to_me and sta_is_associated are both true, the received data frame is handed off to the High MAC framework for de-encapsulation and Ethernet transmission. The same packet might also be enqueued for wireless transmission, depending on the addr3 field:

If the addr3 field (i.e. the DA) is multicast, the packet is enqueued for wireless transmission in the MCAST_QID queue.
If the addr3 field (i.e. the DA) matches the MAC address of an associated station, the packet is enqueued for transmission to that station

If unicast_to_me is true but sta_is_associated is false, the AP creates and enqueues a de-authentication frame addressed to the TA of the received frame in the MANAGEMENT_QID queue. This can occur if a STA does not receive the de-authentication frame prior to be removed from the BSS for inactivity.

Probe Request¶

If addr3 (i.e. the BSSID) is either multicast or matches the MAC address of the AP, the SSID string is extracted from the frame and compared to the SSID of the BSS being hosted by the AP. If either the SSID string matches or the wildcard SSID string is used in the probe request, a probe response frame is enqueued in the MANAGEMENT_QID queue.

Authentication¶

The AP currently only supports the open authentication system. When receiving an authentication frame with both unicast_to_me true and addr3 (the BSSID) equal to the MAC address of the AP, the TA of the frame is checked against a MAC address filter. If the filter passes, an authentication frame is enqueued with success status in the MANAGEMENT_QID queue. Furthermore, the STA’s details are stored in a list of authenticated stations so that an association request can be honored.

Association Request or Reassociation Request¶

If both unicast_to_me is true and addr3 (the BSSID) is equal to the MAC address of the AP, the AP will search for the TA of the frame in its list of authenticated stations. If it finds the STA in that list, an association response with a success status is enqueued in the MANAGEMENT_QID queue. If not, an association response with a rejection status is enqueued in the MANAGEMENT_QID queue.

Disassociation¶

If both unicast_to_me is true and addr3 (the BSSID) is equal to the MAC address of the AP, the AP will remove the STA that matches the TA of the frame from the list of associated stations.

Wireless Tx Queue Handling¶

The AP application uses the High MAC Framework’s queueing subsystem to implement multiple transmit queues. The AP uses the following queues:

Management: for all Management transmissions, such as Probe Responses and Association Responses
Multicast Data: for all non-management packets addressed to a multicast MAC address
Per-Client Data: one queue for each associated client

A new data queue is created when a client associates; the queue is purged when the client disassociates.

The reference AP implementation uses a two-level round robin scheme for selecting which Tx queue is serviced whenever the lower MAC is ready to transmit a new packet. This scheme is implemented in the poll_tx_queues() function.

The first level round robin alternates between the Management queue and all other queues. This scheme prioritizes management transmissions to reduce latency during the association handshake with new clients.

The second level round robin rotates through the Per-Client Data queues. The Multicast Data queue is also included in this round robin polling when DTIM Multicast Buffering (described below) is disabled.

DTIM Multicast Buffering¶

The AP application supports the standard DTIM Multicast Buffering protocol. When multicast buffering is enabled all non-management packets addressed to multicast addresses are deferred until immediately after specific beacon transmissions. This deferral allows power-savings clients to doze between beacons, then wakeup at a specific time to receive multicast traffic.

When multicast buffering is enabled the AP dequeues packets from the Multicast Data queue into dedicated Tx packet buffers (the PKT_BUF_GROUP_DTIM_MCAST group). The DCF transmits these packets at the next DTIM boundary. When the DCF finishes transmitting one multicast packet, the AP immediately dequeues another multicast packet into a PKT_BUF_GROUP_DTIM_MCAST packet buffer. This process continues until the Multicast Data queue is empty.