Standalone Ad-hoc (IBSS)¶
The Standalone Independent Basic Service Set (IBSS) application for CPU High implements a standard 802.11 independent ad-hoc client. The IBSS design supports the standard ad-hoc network discovery and creation protocols and will communicate with Wi-Fi devices operating in ad-hoc mode as well as other instances of the reference IBSS high MAC application.
The Standalone IBSS 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.3 Typical IBSS Network
The IBSS supports the Ethernet portal behaviors described in the 802.11-2012 standard Annex P. By connecting a device via Ethernet, it made use the IBSS design as an Ethernet bridge to the rest of the ad-hoc network.
BSS Configuration¶
Parameters used to configure a BSS are defined in bss_config_t (see High MAC Framework BSS Configuration). IBSS-specific requirements for these fields are listed below:
| Parameter | Description |
|---|---|
u8 bssid[6] |
Must be a locally administered address. If the MAC_ADDR_MSB_MASK_LOCAL bit is not asserted, a BSS_CONFIG_FAILURE_BSSID_INVALID error will be returned 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 |
DTIM not supported by IBSS. BSS_CONFIG_FAILURE_DTIM_PERIOD_INVALID will be returned from configure_bss() if this field is set. |
To change the current BSS configuration, the following function may be called:
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 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 IBSS 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 IBSS will enqueue the packet in a per-station queue with STATION_ID_TO_QUEUE_ID() according to the matching station information in the High MAC Framework. If the destination address has never been seen before, the IBSS will ask the High MAC Framework to create a new station information entry for it.
Joining a network¶
The process for the IBSS to join an existing ad-hoc network is simpler than the join process for the Infrastructure Client (STA) MAC application. An IBSS may unilaterally adopt the BSS configuration of an existing ad-hoc network and begin communicating with other devices in the network. After performing an active scan via the High MAC Framework Network Scanner, the IBSS will choose to either adopt existing BSS configuration parameters it discovers or it will create a new ad-hoc network for others to adopt.
Wireless Rx¶
When the IBSS 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 this AP |
to_multicast |
Received frame has an RA with the multicast bit set high |
Using the sequence number of the received frame, the IBSS skips further processing of duplicate packets. Next, the IBSS then examines the received 802.11 frame’s packet type and processes each differently:
QoS Data or Data¶
If either unicast_to_me or to_multicast is true and addr3 (i.e. the BSSID) matches the current BSS configuration, the received data frame is handed off to the High MAC framework for de-encapsulation and Ethernet transmission.
Probe Request¶
If addr3 (i.e. the BSSID) is the broadcast address, 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.
Wireless Tx Queue Handling¶
The IBSS application uses the High MAC Framework’s queueing subsystem to implement multiple transmit queues. The IBSS 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-member Data: one queue for each known member of the IBSS
A new data queue is created when an IBSS member is found.
The reference IBSS 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-member Data queues. The Multicast Data queue is also included in this round robin polling.