doc: sphinx warnings
This commit is contained in:
Peter D. Barnes, Jr
@@ -111,7 +111,7 @@ fraction of the other ones, i.e., they should be "statistically irrelevant".
|
||||
References
|
||||
==========
|
||||
|
||||
.. [FlowMonitor] G. Carneiro, P. Fortuna, and M. Ricardo. 2009. FlowMonitor: a network monitoring framework for the network simulator 3 (NS-3). In Proceedings of the Fourth International ICST Conference on Performance Evaluation Methodologies and Tools (VALUETOOLS '09). http://dx.doi.org/10.4108/ICST.VALUETOOLS2009.7493
|
||||
.. [FlowMonitor] G. Carneiro, P. Fortuna, and M. Ricardo. 2009. FlowMonitor: a network monitoring framework for the network simulator 3 (NS-3). In Proceedings of the Fourth International ICST Conference on Performance Evaluation Methodologies and Tools (VALUETOOLS '09). http://dx.doi.org/10.4108/ICST.VALUETOOLS2009.7493 (Full text: https://dl.acm.org/doi/abs/10.4108/ICST.VALUETOOLS2009.7493)
|
||||
|
||||
Usage
|
||||
*****
|
||||
|
||||
@@ -794,13 +794,13 @@ window based on this estimate. This approach achieves high burst tolerance, low
|
||||
latency, and high throughput with shallow-buffered switches.
|
||||
|
||||
* Receiver functionality: If CE is set in IP header of incoming packet, send
|
||||
congestion notification to the sender by setting ECE in TCP header. This processing
|
||||
is different from standard ECN processing which sets ECE bit for every ACK untill
|
||||
it observes CWR
|
||||
congestion notification to the sender by setting ECE in TCP header.
|
||||
This processing is different from standard ECN processing
|
||||
which sets ECE bit for every ACK until it observes CWR
|
||||
|
||||
* Sender functionality: The sender makes use of the modified receiver ECE semantics
|
||||
to maintain an average of fraction of packets marked (α) by using the exponential
|
||||
weighted moving average as shown below:
|
||||
* Sender functionality: The sender makes use of the modified
|
||||
receiver ECE semantics to maintain an average of fraction of packets
|
||||
marked (α) by using the exponential weighted moving average as shown below:
|
||||
|
||||
::
|
||||
|
||||
|
||||
@@ -9,15 +9,15 @@ unicast routing protocol. It has been developed at the
|
||||
University of Murcia (Spain) by Francisco J. Ros for NS-2, and was
|
||||
ported to NS-3 by Gustavo Carneiro at INESC Porto (Portugal).
|
||||
|
||||
The implementation is based on OLSR Version 1 (:rfc:`3626`) and
|
||||
it is *not* compliant with OLSR Version 2 (:rfc:`7181`) or any
|
||||
The implementation is based on OLSR Version 1 (:rfc:`3626` [rfc3626]_) and
|
||||
it is *not* compliant with OLSR Version 2 (:rfc:`7181` [rfc7181]_) or any
|
||||
of the Version 2 extensions.
|
||||
|
||||
Model Description
|
||||
*****************
|
||||
|
||||
The source code for the OLSR model lives in the directory `src/olsr`.
|
||||
As stated before, the model is based on :rfc:`3626`. Moreover, many
|
||||
As stated before, the model is based on :rfc:`3626` ([rfc3626]_). Moreover, many
|
||||
design choices are based on the previous ns2 model.
|
||||
|
||||
Scope and Limitations
|
||||
@@ -25,10 +25,10 @@ Scope and Limitations
|
||||
|
||||
The model is for IPv4 only.
|
||||
|
||||
* Mostly compliant with OLSR as documented in :rfc:`3626`,
|
||||
* Mostly compliant with OLSR as documented in :rfc:`3626` ([rfc3626]_),
|
||||
* The use of multiple interfaces was not supported by the NS-2 version, but is supported in NS-3;
|
||||
* OLSR does not respond to the routing event notifications corresponding to dynamic interface up and down (``ns3::RoutingProtocol::NotifyInterfaceUp`` and ``ns3::RoutingProtocol::NotifyInterfaceDown``) or address insertion/removal ``ns3::RoutingProtocol::NotifyAddAddress`` and ``ns3::RoutingProtocol::NotifyRemoveAddress``).
|
||||
* Unlike the NS-2 version, does not yet support MAC layer feedback as described in :rfc:`3626`;
|
||||
* Unlike the NS-2 version, does not yet support MAC layer feedback as described in :rfc:`3626` ([rfc3626]_);
|
||||
|
||||
Host Network Association (HNA) is supported in this implementation
|
||||
of OLSR. Refer to ``examples/olsr-hna.cc`` to see how the API
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
|
||||
This chapter describes the implementation of |ns3| model for the
|
||||
compression of IPv6 packets over IEEE 802.15.4-Based Networks
|
||||
as specified by :rfc:`4944` and :rfc:`6282`.
|
||||
as specified by :rfc:`4944` ([RFC4944]_) and :rfc:`6282` ([RFC6282]_).
|
||||
|
||||
Model Description
|
||||
*****************
|
||||
@@ -30,7 +30,7 @@ following exceptions:
|
||||
The HC2 encoding is not supported, as it has been superseded by IPHC and NHC
|
||||
compression type (\ :rfc:`6282`).
|
||||
|
||||
IPHC SAC and DAC are not yet supported, as they do require :rfc:`6775` for full
|
||||
IPHC SAC and DAC are not yet supported, as they do require :rfc:`6775` ([RFC6775]_) for full
|
||||
compliance. It is planned to support them in the future.
|
||||
|
||||
NetDevice
|
||||
@@ -47,7 +47,7 @@ GetMtu behaviour. It will always return *at least* 1280 bytes, as is the minimum
|
||||
The module does provide some attributes and some tracesources.
|
||||
The attributes are:
|
||||
|
||||
* Rfc6282 (boolean, default true), used to activate HC1 (:rfc:`4944`) or IPHC (:rfc:`6282`) compression.
|
||||
* :rfc:`6282` (boolean, default true), used to activate HC1 (:rfc:`4944`) or IPHC (:rfc:`6282`) compression.
|
||||
* OmitUdpChecksum (boolean, default true), used to activate UDP checksum compression in IPHC.
|
||||
* FragmentReassemblyListSize (integer, default 0), indicating the number of packets that can be reassembled at the same time. If the limit is reached, the oldest packet is discarded. Zero means infinite.
|
||||
* FragmentExpirationTimeout (Time, default 60 seconds), being the timeout to wait for further fragments before discarding a partial packet.
|
||||
|
||||
@@ -468,7 +468,7 @@ create and transmit the signal on the channel.
|
||||
:align: center
|
||||
|
||||
8K COFDM signal spectrum generated from ``TvSpectrumTransmitter`` (Left) and
|
||||
theoretical COFDM signal spectrum [KoppCOFDM] (Right)
|
||||
theoretical COFDM signal spectrum [KoppCOFDM]_ (Right)
|
||||
|
||||
One of the user-configurable attributes is the type of modulation for the TV
|
||||
transmitter to use. The options are 8-VSB (Eight-Level Vestigial Sideband
|
||||
@@ -480,8 +480,8 @@ technology but is still being used by some countries today. To accomplish
|
||||
realistic PSD models for these modulation types, the signals’ PSDs were
|
||||
approximated from real standards and developed into models that are scalable by
|
||||
frequency and power. The COFDM PSD is approximated from Figure 12 (8k mode) of
|
||||
[KoppCOFDM], the 8-VSB PSD is approximated from Figure 3 of [Baron8VSB], and the
|
||||
analog PSD is approximated from Figure 4 of [QualcommAnalog]. Note that the
|
||||
[KoppCOFDM]_, the 8-VSB PSD is approximated from Figure 3 of [Baron8VSB]_, and the
|
||||
analog PSD is approximated from Figure 4 of [QualcommAnalog]_. Note that the
|
||||
analog model is approximated from the NTSC standard, but other analog modulation
|
||||
standards such as PAL have similar signals. The approximated COFDM PSD model is
|
||||
in 8K mode. The other configurable attributes are the start frequency,
|
||||
@@ -515,7 +515,7 @@ is also provided to easily simulate real-world scenarios.
|
||||
|
||||
North America ATSC channel 19 & 20 signals generated using
|
||||
``TvSpectrumTransmitterHelper`` (Left) and theoretical 8-VSB signal
|
||||
[Baron8VSB] (Right). Note that the theoretical signal is not shown in dB
|
||||
[Baron8VSB]_ (Right). Note that the theoretical signal is not shown in dB
|
||||
while the ns-3 generated signals are.
|
||||
|
||||
Using this helper class, users can easily set up TV transmitters right after
|
||||
@@ -580,7 +580,7 @@ correspond to TV transmitter positions. The first method converts Earth
|
||||
geographic coordinates to Earth-Centered Earth-Fixed (ECEF) Cartesian
|
||||
coordinates, and is tested in the ``geo-to-cartesian`` test suite by comparing
|
||||
(with 10 meter tolerance) its output with the output of the geographic to ECEF
|
||||
conversion function [MatlabGeo] of the MATLAB Mapping Toolbox for numerous
|
||||
conversion function [MatlabGeo]_ of the MATLAB Mapping Toolbox for numerous
|
||||
test cases. The other used method generates random ECEF Cartesian points around
|
||||
the given geographic origin point, and is tested in the ``rand-cart-around-geo``
|
||||
test suite by verifying that the generated points do not exceed the given
|
||||
@@ -623,18 +623,21 @@ ThreeGppChannelModel and ThreeGppSpectrumPropagationLossModel.
|
||||
**Note:**
|
||||
|
||||
* Currently, no error model is provided; a link-to-system campaign may be
|
||||
needed to incorporate it in existing modules.
|
||||
needed to incorporate it in existing modules.
|
||||
|
||||
* The model does not include any spatial consistency update procedure
|
||||
(see [TR38901]_, Sec. 7.6.1). The implementation of this feature is left
|
||||
as future work.
|
||||
(see [TR38901]_, Sec. 7.6.1). The implementation of this feature is left
|
||||
as future work.
|
||||
|
||||
* Issue regarding the blockage model: according to 3GPP TR 38.901 v15.0.0
|
||||
(2018-06) section 7.6.4.1, the blocking region for self-blocking is provided
|
||||
in LCS.
|
||||
However, here, clusterAOA and clusterZOA are in GCS and blocking check is
|
||||
performed for self-blocking similar to non-self blocking, that is in GCS.
|
||||
One would expect the angles to be transposed to LCS before checking self-blockage.
|
||||
(2018-06) section 7.6.4.1, the blocking region for self-blocking is provided
|
||||
in LCS.
|
||||
|
||||
However, here, clusterAOA and clusterZOA are in GCS and blocking check is
|
||||
performed for self-blocking similar to non-self blocking, that is in GCS.
|
||||
One would expect the angles to be transposed to LCS before checking
|
||||
self-blockage.
|
||||
|
||||
|
||||
ThreeGppSpectrumPropagationLossModel
|
||||
####################################
|
||||
@@ -739,17 +742,22 @@ Testing
|
||||
The test suite ThreeGppChannelTestSuite includes three test cases:
|
||||
|
||||
* ThreeGppChannelMatrixComputationTest checks if the channel matrix has the
|
||||
correct dimensions and if it correctly normalized
|
||||
correct dimensions and if it correctly normalized
|
||||
|
||||
* ThreeGppChannelMatrixUpdateTest, which checks if the channel matrix is correctly
|
||||
updated when the coherence time exceeds
|
||||
* ThreeGppChannelMatrixUpdateTest, which checks if the channel matrix
|
||||
is correctly updated when the coherence time exceeds
|
||||
|
||||
* ThreeGppSpectrumPropagationLossModelTest, which tests the functionalities
|
||||
of the class ThreeGppSpectrumPropagationLossModel. It builds a simple
|
||||
network composed of two nodes, computes the power spectral density
|
||||
received by the receiving node, and
|
||||
|
||||
1. Checks if the long term components for the direct and
|
||||
the reverse link are the same,
|
||||
2. Checks if the long term component is updated when changing
|
||||
the beamforming vectors,
|
||||
3. Checks if the long term is updated when changing the channel matrix
|
||||
|
||||
* ThreeGppSpectrumPropagationLossModelTest, which tests the functionalities of the
|
||||
class ThreeGppSpectrumPropagationLossModel. It builds a simple network composed of two
|
||||
nodes, computes the power spectral density received by the
|
||||
receiving node, and (i) checks if the long term components for the direct and the reverse link
|
||||
are the same, (ii) checks if the long term component is updated when changing the beamforming
|
||||
vectors, (iii) checks if the long term is updated when changing the channel matrix
|
||||
|
||||
**Note:** TR 38.901 includes a calibration procedure that can be used to validate
|
||||
the model, but it requires some additional features which are not currently
|
||||
|
||||
@@ -6,9 +6,9 @@ model a variety of underwater network scenarios. The UAN model
|
||||
is broken into four main parts: The channel, PHY, MAC and
|
||||
Autonomous Underwater Vehicle (AUV) models.
|
||||
|
||||
The need for underwater wireless communications exists in applications such as remote control in offshore oil industry [1]_, pollution monitoring in environmental systems, speech transmission between divers, mapping of the ocean floor, mine counter measures [4]_, seismic monitoring of ocean faults as well as climate changes monitoring. Unfortunately, making on-field measurements is very expensive and there are no commonly accepted standard to base on. Hence, the priority to make research work going on, it is to realize a complete simulation framework that researchers can use to experiment, make tests and make performance evaluation and comparison.
|
||||
The need for underwater wireless communications exists in applications such as remote control in offshore oil industry [1]_, pollution monitoring in environmental systems, speech transmission between divers, mapping of the ocean floor, mine counter measures [2]_ [4]_, seismic monitoring of ocean faults as well as climate changes monitoring. Unfortunately, making on-field measurements is very expensive and there are no commonly accepted standard to base on. Hence, the priority to make research work going on, it is to realize a complete simulation framework that researchers can use to experiment, make tests and make performance evaluation and comparison.
|
||||
|
||||
The NS-3 UAN module is a first step in this direction, trying to offer a reliable and realistic tool. In fact, the UAN module offers accurate modelling of the underwater acoustic channel, a model of the WHOI acoustic modem (one of the widely used acoustic modems)[6]_ and its communications performance, and some MAC protocols.
|
||||
The NS-3 UAN module is a first step in this direction, trying to offer a reliable and realistic tool. In fact, the UAN module offers accurate modelling of the underwater acoustic channel, a model of the WHOI acoustic modem (one of the widely used acoustic modems) [6]_ and its communications performance, and some MAC protocols.
|
||||
|
||||
|
||||
Model Description
|
||||
@@ -261,7 +261,7 @@ Acoustic modem energy model
|
||||
|
||||
Basing on the Device Energy Model interface, has been implemented a generic energy model for acoustic modem. The model allows to trace four modem's power-states: Sleep, Idle, Receiving, Transmitting. The default parameters for the energy model are set to fit those of the WHOI μmodem. The class follows pretty closely the RadioEnergyModel class as the transducer behaviour is pretty close to that of a Wi-Fi radio.
|
||||
|
||||
The default power consumption values implemented into the model are as follows [6]:
|
||||
The default power consumption values implemented into the model are as follows [6]_:
|
||||
|
||||
+--------------+---------------------+
|
||||
| Modem State | Power Consumption |
|
||||
@@ -290,7 +290,7 @@ Li-Ion batteries model
|
||||
A generic Li-Ion battery model has been implemented based on [7][8]. The model can be fitted to any type of Li-Ion battery simply changing the model's parameters The default values are fitted for the Panasonic CGR18650DA Li-Ion Battery [9].
|
||||
[TODO insert figure]
|
||||
As shown in figure the model approximates very well the Li-Ion cells.
|
||||
Regarding Seagliders, the batteries used into the AUV are Electrochem 3B36 Lithium / Sulfuryl Chloride cells [10]. Also with this cell type, the model seems to approximates the different discharge curves pretty well, as shown in the figure.
|
||||
Regarding Seagliders, the batteries used into the AUV are Electrochem 3B36 Lithium / Sulfuryl Chloride cells [10]_. Also with this cell type, the model seems to approximates the different discharge curves pretty well, as shown in the figure.
|
||||
|
||||
.. note::
|
||||
|
||||
|
||||
Reference in New Issue
Block a user