The 802.11 Model¶
IEEE 802.11 a.k.a. WiFi is the most widely used and universal wireless networking standard. Specifications are updated every few years, adding more features and ever increasing bit rates.
In INET, nodes become WiFi-enabled by adding a Ieee80211Interface to them. (As mentioned earlier, WirelessHost and AdhocHost already contain one in their default configuration.) APs are represented with the AccessPoint node type. WiFi networks require a matching transmission medium module to be present in the network, which is usually a Ieee80211ScalarRadioMedium.
Operation mode (infrastructure vs ad hoc) is determined by the ingredients of the wireless interface. Ieee80211Interface has the following submodules (incomplete list):
management: performs association/disassociation with access points, channel scanning, beaconing
agent: initiates actions such as channel scanning and connecting to and disconnecting from access points
MAC: transmits and receives frames according to the IEEE 802.11 medium access procedure
PHY: represents the radio
The management component has several implementations which differ in their role and level of detail:
Ieee80211MgmtAdhoc: for ad hoc mode stations
The “simplified” ones assume that stations are statically associated to an access point for the entire duration of the simulation (the scan-authenticate-associate process is not simulated), so they cannot be used e.g. in experiments involving handover.
The following sections examine the above components.
The Ieee80211Mac module type represents the IEEE 802.11 MAC. The structure of the implementation closely follows the architecture described in the standard, IEEE 802.11-2012 Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications.
Ieee80211Mac performs transmission of frames according to the CSMA/CA protocol. It receives data and management frames from the upper layers, and transmits them.
The Ieee80211Mac was designed to be modular to facilitate experimenting with new policies, features and algorithms within the MAC layer. Users can easily replace individual components with their own implementations. Policies, which most likely to be experimented with, are extracted into their own modules.
The new model also separates the following components in the 802.11 standard into modules:
Channel access method as specified by the standard: Edca
MAC data services: OriginatorMacDataService, RecipientMacDataService, OriginatorQosMacDataService, RecipientQosMacDataService. The MAC data services are implemented as compound modules, which combine functions related to transforming data frames (sequence numbering, duplicate removal, frame reordering, fragmentation, aggregation).
Aggregation and deaggregation (C++ class in MAC data services): These classes implement aggregation and deaggregation according to the policy modules (see below).
Fragmentation and defragmentation (C++ classes in MAC data services): These classes carry out the task of fragmentation and defragmentation according to the policy modules (see below).
Block ACK agreements and frame reordering (C++ classes): These classes carry out the task according to the policy modules (see below).
Frame exchange sequences (implemented as C++ classes in coordination functions, like Hcf): These classes strictly follow the standard specifying the valid frame sequences.
TXOP procedure (TxopProcedure): This module implements the transmission opportunity behavior of the standard.
Duplicate removal (C++ class in RecipientMacDataService): This class removes duplicate received frames based on sequence numbers.
Rate selection: QosRateSelection. This module controls data rate for all kind of frames, including management and control frames.
Protection mechanism: OriginatorProtectionMechanism. This module provides channel allocation for frame exchange sequences.
Contention: Contention. The contention module implements contention-based channel access, using defer, backoff, etc.
PendingQueue: This module is a queue containing frames received from higher layers, waiting for transmission unchanged.
InProgressFrames: This modules is a queue containing frames waiting for transmission already processed by the MAC data service.
The MAC model has the following replaceable built-in policy submodules by default:
MSDU aggregation policy (e.g. BasicMsduAggregationPolicy): controls when and which frames are aggregated into an A-MSDU
Fragmentation policy (e.g. BasicFragmentationPolicy): controls when and how fragmentation happens
The physical layer modules (Ieee80211Radio) deal with modelling transmission and reception of frames. They model the characteristics of the radio channel, and determine if a frame was received correctly (that is, it did not suffer bit errors due to low signal power or interference in the radio channel). Frames received correctly are passed up to the MAC.
On the physical layer, one can choose from several radios with different levels of detail. The various radio types (with the matching transmission medium types in parentheses) are:
The management layer exchanges management frames via the MAC with its peer management entities in other STAs and APs. Beacon, Probe Request/Response, Authentication, Association Request/Response etc frames are generated and interpreted by management entities, and transmitted/received via the MAC layer. During scanning, it is the management entity that periodically switches channels, and collects information from received beacons and probe responses.
The management layer has several implementations which differ in their role (STA/AP/ad-hoc) and level of detail: Ieee80211MgmtAdhoc, Ieee80211MgmtAp, Ieee80211MgmtApSimplified, Ieee80211MgmtSta, Ieee80211MgmtStaSimplified. The ..Simplified ones differ from the others in that they do not model the scan-authenticate-associate process, so they cannot be used in experiments involving handover.
The agent is what instructs the management layer to perform scanning, authentication and association. The management layer itself just carries out these commands by performing the scanning, authentication and association procedures, and reports back the results to the agent.
The agent component is currently only needed with the Ieee80211MgmtSta module. The managament entities in other NIC variants do not have as much freedom as to need an agent to control them.
Ieee80211MgmtSta requires a Ieee80211AgentSta or a custom agent. By modifying or replacing the agent, one can alter the dynamic behaviour of STAs in the network, for example implement different handover strategies.