Home
In this Wiki page, we consolidate information regarding implementation details that are not explained in our publications.
For all the simulations that rely on the NIST Q-D channel, we store the relevant data in a special folder named “WigigFiles”. In this folder, we arrange all of the simulation data according to the following structure:
- Codebook Folder: Here we store all the codebook files that are used across all our simulations. We use the following naming convention to identifying each codebook:
CODEBOOK_ARRAY-NAME_DEVICE-TYPE_XY.txtWhere:
- ARRAY-NAME: The type of the phased antenna array (ULA, URA, UCA, etc.)
- DEVICE-TYPE: The type of mmWave device (AP or STA).
- XY: The antenna array geometry. For URA, the number of rows x the number of columns.
- Q-D Files: We store the Q-D scenarios that are generated by Q-D Channel Realization Software in this folder.
- Error-models: This folder contains SNR vs BER look-up tables (LUTS) for both IEEE 802.11ad DMG Control, SC, and OFDM PHY layers and IEEE 802.11ay EDMG Control, SC, and OFDM PHY layers.
We created a set of helper functions that facilitate manipulating simulation parameters and formatting output results. These functions are located in a header file named common-functions.h which can be found in the scratch folder. We briefly mention some of these functions here. For a complete list of the helper functions, please check the content of the common-functions.h file.
- ValidateFrameAggregationAttributes: This function validates the provided values of A-MSDU and A-MPDU aggregation size based on the simulated standard. Additionally, the user can simply request the maximum supported sizes of A-MSDU and A-MPDU and the function will automatically return these values based on the standard.
- ConfigureTcpOptions: This function is used to configure TCP options including Send and Receive buffer sizes, segment size, and other options that are TCP variant dependent.
The mmWave band has unique propagation characteristics compared to the sub-6-GHz band. This has an impact on the design of mmWave communication systems. Thus, accurate modeling of the mmWave propagation channel is essential for understanding and designing efficient mmWave communication protocols. We utilize the Spectrum model in ns-3 to model accurately the propagation behavior of the mmWave channel and thus obtain high fidelity results. We model the spectral transmit mask of each channel (1 - 8) in the IEEE 802.11ay standard. Additionally, we model the transmit spectrum mask for bonded channels (2, 3, and 4 bonded channels). We divide the mmWave spectrum into several subbands where the width of each subband corresponds to IEEE 802.11ad OFDM symbol bandwidth (5.156 25 MHz). As a result, the transmit mask of a single channel is divided into
2 * 3.06 GHz/5.156 25 MHz = 1187 subbands
Then. for each subband, we calculate the received power using equations listed in this paper [WNS3 2019]. After calculating the received power for each subband, we integrate the power spectral density to obtain the total received power. To speed up simulation time, we store the calculated channel gain between each pair of nodes using a particular set of beam patterns. This reduces computation overhead since we eliminate per packet channel gain calculation.
Based on the previous description, increasing both the number of MPCs in the Q-D (e.g. increasing the reflection order or enabling the diffuse components) and the size of the channel yields more accurate results but impacts vastly the simulation run time.
The Q-D realization software supports node mobility and generating different channel profiles based on node location and orientation. Because of that, a user does not need to utilize any mobility models inside ns-3 as they will not have any effect on the simulated scenario. The only parameter that needs to be set inside ns-3 is the interval between consecutive channel updates. You can set this parameter in the QdPropagationEngine class as following:
qdPropagationEngine->SetAttribute ("Interval", TimeValue (TIME_UNIT (VALUE)));
TIME_UNIT: Seconds, MilliSeconds, MicroSeconds, NanoSeconds
If the simulation time within ns-3 exceeds the limits of the Q-D trace file, then the last Q-D channel profile in the trace file will be utilized for the rest of the ns-3 simulation.
The Q-D software indices all the nodes in the simulated scenario starting from zero. It generates a separate CSV file between each pair of nodes to describe the channel profile. The number of the generated CSV files is equal to N*(N-1) where N is the number of simulated nodes in the network. So if you have a large scenario, e.g., 64 nodes then the software will generate 64*63 = 4,032 CSV files. In the future, we plan to switch to a more compact representation using JSON file format where all the channel profiles are encapsulated in a single file. ns-3 indices all the nodes in the scenario starting from zero and in the order of their creation in the simulation scripts. The default mode for the interface between the ns-3 IEEE 802.11ad/ay module and the Q-D Channel Realization Software assumes one-to-one mapping between ns-3 nodes IDs and Q-D software nodes IDs. This means that node (0) in ns-3 will correspond to node (0) in the Q-D software. Let's assume that the Q-D scenario is made of N nodes. Then, the first M nodes will be used for DMG/EDMG PCP/APs in ns-3 and the (N-M) remaining nodes will be considered as DMG/EDMG STAs.
Due to the decoupling design of the Parametric codebook and the Q-D ray-tracing software, users can analyze and assess the impact of phased antenna array geometries using the same simulated scenario. One can thus compare the impact of antenna array geometry on spatial reuse in the network.
By default, all the 2D phased antenna arrays e.g. URA, UCA in the Codebook Generator Application have their antenna normal set to the X-axis. This means that the boresight direction will be aligned with the X-axis while the antenna elements will be distributed in the Y-Z plane as depicted in the following figure.
To avoid generating multiple codebook instances for different rotations angles, the Q-D Realization software takes care of adjusting the angle of arrivals (AoAs) and the angle of departures (AoDs) based on the angles of rotation. This makes ns-3 agnostic to the angle of rotations and reduces computation requirements.
Our PHY layer implementation is abstracted but still provides highly accurate results. We do not implement the full signal processing chain which requires high computation and processing thus increasing simulation time. This is even more prominent in mmWave networks since mmWave devices generate more than ten thousand packets per second due to the high data rates. In our implementation, we model the power levels of different parts in the packets (Preamble, Header, Payload, AGC Subfields, Training Subfields). In addition, we generate an extensive set of SNR vs BER look-up tables for all the MCSs supported in IEEE 802.11ad/ay.
IEEE 802.11ad/ay organizes the wireless medium into beacon intervals (BIs) where each beacon interval is divided into various channel access periods (BTI, A-BFT, ATI, and DTI). Data transmission takes place within the data transmission interval (DTI). In this access period, a user can access the channel using one of the following two modes: Contention-based (CP) channel access utilizing the Enhanced Data Channel Access (EDCA) for QoS differentiation. The corresponding access period is called the contention-based access period (CBAP). Contention-free (CF) channel access where the channel is reserved for communication between two specific nodes in the network. The standard uses the term Service Period (SP) to refer to this access period.
DTI can be divided into several access periods of CBAPs and SPs. By default, a DMG/EDMG PCP/AP allocates the whole DTI as CBAP. The standards provide high flexibility to adjust communication in this period based on traffic characteristics and QoS requirements. In our implementation, a user can either inject the scheduling information of the access period into the AP, and then, the AP will disseminate this information within its DMG Beacons to all the STAs in the network. In addition, our implementation supports CBAPs and SPs allocation (Traffic stream allocation in the standard) using ADDTS Request/Response. Admission control and managing the resources are left to the user in this case. For more information, please refer to the “evaluate_trafficstream_allocation” example.
We assume that our phased antenna array is made of (N) Tx/Rx antenna paths. Each Tx/Rx antenna path is connected to an antenna element e.g. patch antenna element. The below Figure depicts the phased antenna array architecture both at the transmitting and receiving sides:
On the transmitting side, we assume that each Tx antenna path consists of a power amplifier (PA) followed by a phase shifter (PS). A user has control over the phase shifters to steer the beam towards any direction in space. Additionally, a user can apply custom antenna tapering to control the amplitude of the side lobes. Thus, we have two combined effects on the emitted power. The first one comes from combining the power of (N) PAs:
10 * log10(N)
The second effect is the result of the antenna array i.e. having N antenna elements:
10 * log10(N)
Thus, the maximum antenna array gain is:
GTx(dBi) = 10 * log10(N^2)
On the receiver side, we assume that each Rx antenna path contains a low-noise amplifier (LNA) followed by a phase shifter (PS). Each Rx antenna path generates AWGN noise and we assume noise sources are uncorrelated, thus the total noise power is:
Noise(dBm) = 10 * log10(N)
We also consider the signals of each Rx antenna path combines coherently, thus the power of the combined signal is:
Signal(dBm) = 10 * log10(N^2)
As a result, Rx antenna array gain on SNR is:
GRx(dB) = Signal(dBm) - Noise(dBm) = 10 * log10(N^2) - 10 * log10(N) = 10 * log10(N)
We’ve implemented a simple High MAC class named “DmgAdhocWifiMac” which is not a standard-compliant MAC layer. The main motivation behind this class is to get rid of all complexity associated with the scheduling of different access periods in the BI and the necessity to do frequent beamforming training. In this implementation, we assume that the whole BI is allocated for contention-based channel access only. A user can utilize this class to develop his/her own BI structure and beamforming protocol while still using the legacy CBAP channel access scheme. In our scripts, we use this class when we are interested in calculating application throughput without including the overhead associated with the scheduling of different access periods in the BI. To use this class, we must manually align the beam battens of the two communicating devices to achieve high SINR.
Using the parametric codebook class, each DMG/EDMG STA requires storing the steering matrix of each phased antenna array it uses. Then using this steering matrix, each STA calculates the array patterns for each sector and custom antenna weight vector (AWV) in its codebook. Calculating and storing these results during the simulation run-time would require both a high amount of computation and a large volume of memory. This mandates the availability of a large RAM in the simulation server for simulating large dense scenarios. In practice, most of the WiGig devices in the network will be identical and thus will utilize the same codebook. As a result, we’ve introduced the CodebookParametricHelper class in our implementation. This class creates a single instance of the CodebookParametric class in a device with all the array patterns calculated. Then for the rest of the devices, it uses pointers to refer to these array patterns matrices. In this way, memory and computation do not scale with the size of the simulated network. Here is an example of using CodebookParametricHelper:
/* Set Parametric Codebook for all the DMG PCPs/APs */
codebookParametricHelper codebookHelper;`
codebookHelper.SetCodebookParameters ("FileName", StringValue ("WigigFiles/Codebook/" + apCodebook + ".txt"));
codebookHelper.Install (apDevices);`
/* Set Parametric Codebook for all the DMG STAs */
codebookHelper.SetCodebookParameters ("FileName", StringValue ("WigigFiles/Codebook/" + staCodebook + ".txt"));
codebookHelper.Install (staDevices);
To build a unified interface with the Q-D visualizer software, we’ve built a set of classes that handles the generation of the beamforming results and arranges these results in a pre-defined structure that can be parsed by the Q-D visualizer software. This can simplify the generation of tracing results, as users just need to write a few lines of codes in their simulation scripts, and the corresponding beamforming trace helper class will take care of connecting the correct traces sources of each node in the simulation and generating trace files in the correct format. We use the following name convention for each trace file:
TRACE-FILE-NAME_SEED-NUMBER.csv
Where:
- TRACE-FILE-NAME: The name indicates the type of the trace file (SLS, Group Beamforming, SU-MIMO BFT, or MU-MIMO BFT) followed by the name of the trace source for a certain type of trace.
- SEED-NUMBER: This is the seed number of the random number generator (RngRun) specified in the command-line argument.
At the moment, we have four different types of beamforming traces:
- SLS Beamforming tracer: It contains IEEE 802.11ad/ay beamforming training results for the sector-level sweep (SLS) mechanism. All the results are consolidated in a single file.
- Group Beamforming Tracer: This helper aggregates all the beamforming results of IEEE 802.11ay group beamforming in a single file.
- SU-MIMO Beamforming Tracer: The helper generates a set of files for the initiator and responder of the SU-MIMO beamforming training protocol. Each file corresponds to the output of a unique phase in the SU-MIMO beamforming training protocol.
- MU-MIMO Beamforming Tracer: The helper generates a set of files for the initiator (EDMG PCP/AP) and responders (EDMG STAs) of the MU-MIMO beamforming training protocol. Each file corresponds to the output of a unique phase in the MU-MIMO beamforming training protocol.
Note: In ns-3, multiple trace sinks can be connected to a single trace source. Because of that, a user can still trigger something upon the completion of a certain phase of a beamforming trace source while using our TraceHelper class.
Disclaimer: Not all the features that we have developed have been tested in complex scenarios. In case, you run into a bug, feel free to report it.
We are progressively adding new features, improving our implementation, and fixing bugs reported by the WiGig users. Some features that have been developed in the past are crashing. This is due to the heavy changes that have been done to the core of the WiFi module which requires constant fixation and adaptation of our implementation. At the moment, the following features are not tested with the latest upgrade and might crash.
- Fast session transfer (FST) mechanism.
- Relay operation (Half-duplex and full-duplex operation modes).
- Dynamic allocation of service periods.
To test the previous features, we recommend that you resort to an older version of the WiGig module.
In addition, we have the following limitation in data communication during service period allocation:
- Data communication in SP allocation does not support A-MPDU aggregation and only A-MSDU aggregation. The reason is A-MPDU aggregation requires establishing a Block Acknowledgement agreement between the initiator and the responder, which requires a bi-directional transmission in the SP allocation. However, communication in SP is only allowed in a uni-directional way. To solve the previous problem, Reverse Directional Protocol is required.
The upgrade of the WiGig model to support IEEE 802.11ay MIMO represented a major implementation effort and we are currently in the process of adding support for its use in more complex scenarios. The current limitations of the MIMO implementation include:
- SU-MIMO simulations with more than two devices in the network do not have an accurate calculation of the additional interference during MIMO communication.
- MU-MIMO data transmission is not yet implemented. The duration of the MIMO BFT is limited to the duration of one Beacon Interval. If this duration is exceeded there might be crashes and errors in the simulations.
- SU-MIMO BFT has only been validated in scenarios where both devices are training the same number of antennas (i.e NxN MIMO and not NxM MIMO yet).
- MU-MIMO BFT has only been validated in scenarios where the Responders have a single antenna and the number of Responders that the Initiator trains with is equal to the number of antennas that it is training.
- MIMO BFT training of multiple antennas connected to the same RF Chain is not yet supported.
- Multiple MIMO BFT training over the course of one simulation have not yet been validated.