-
Notifications
You must be signed in to change notification settings - Fork 39
Physical Layer Model
Pathloss within the physical layer model is based on location or pathloss events. Pathloss is dynamically calculated based on location events when the propagationmodel configuration parameter is set to either 2ray or freespace , which selects between the 2-ray flat earth or freespace propagation models, respectively.
Pathloss can be provided in realtime based on external propagation calculations using pathloss events. The propagationmodel configuration parameter should be set to precomputed in order to process inbound pathloss events.
For each received packet, the physical layer computes the receiver power associated with that packet using the following calculation:
rxPower = txPower + txAntennaGain + rxAntennaGain − pathloss
Where,
txPower is provided by the transmitter via the Common PHY Header
txAntennaGain is provided by the transmitter via the Common PHY Header or via an Antenna Profile event
rxAntennaGain is provided via the fixedantennagain and fixedantennagainenable configuration parameters or via an Antenna Profile event
pathloss is the pathloss between transmitter and receiver determined based on the propagationmodel configuration parameter
If the rxPower is less than the rxSensitivity, the packet is silently discarded.
rxSensitivity = −174 + noiseFigure + 10log(bandWidth)
Where,
bandWidth is defined by the configuration parameter bandwidth
noiseFigure is defined by the configuration parameter systemnoisefigure
For the emulator physical layer, antenna gain for a given NEM is defined via configuration using one of two methods: fixed gain or antenna profile.
The fixed antenna gain option provides the ability to specify the antenna gain for a given NEM to be utilized for all transmissions and receptions. To use a fixed antenna gain the fixedantennagainenable configuration parameter must be set to on and the fixedantennagain configuration parameter must be set to the floating point antenna gain in dBi. Both of these parameters are optional and the default configuration is to use a fixed antenna gain of 0 dBi. An NEM configured to use a fixed antenna gain utilizes the configured gain as the rxAntennaGain for all OTA received packets when computing rxPower. For all OTA transmissions, the NEM indicates the use of fixed antenna gain and the gain value within the Common PHY Header which in turn is used as the txAntennaGain by all NEMs receiving the OTA packets.
The antenna profile option provides the ability to utilize gain patterns, defined via XML, as a function of elevation and azimuth based on the transmitting and receiving NEM location and orientation (pitch, roll, yaw). Both EMANE antenna profile events and EMANE location events are required when using antenna patterns. To use antenna patterns the fixedantennagainenable configuration parameter must be set to off and the emulator's antennaprofilemanifesturi configuration parameter must be set accordingly.
If antenna profiles are being utilized by one or more NEMs within the emulation experiment, the antennaprofilemanifesturi configuration parameter must be configured for all emulator instances (including those instances hosting NEMs configured to use a fixed antenna gain). This is required to allow an NEM to determine the txAntennaGain when receiving an OTA packet from an NEM using an antenna profile.
Similarly, each NEM must be aware of the antenna profile and pointing information of all NEMs using antenna profiles. EMANE antenna profile events are used to sync the information across the emulation.
Radio Models can send the physical layer an antenna profile control message to change the antenna profile or to re-point the antenna. This control message can even be specified on a packet by packet basis in the downstream direction. When the physical layer receives an antenna profile control message from a radio model, it will create an antenna profile event and transmit the event in one of two ways:
-
If the antenna profile control message was sent as part of a downstream packet processing request, the antenna profile event will be attached to the OTA packet and transmitted as rider with the OTA message. All NEMs will process the antenna profile event prior to processing the OTA packet.
-
If the antenna profile control message was sent as part of a downstream control processing request, the antenna profile event will be sent using the event multicast channel.
The physical layer provides the ability to assess the impact of intentional and unintentional noise sources within the emulation by adjusting the noise floor. This is achieved by summing the energy of signals within the appropriate frequency of interest over a given time interval and reporting a spectrum window containing received signal energy to a requesting radio model. A radio model should wait until the transmission end-of-reception time before requesting a spectrum window over a desired time period.
The physical layer has the ability to record all signal energy, out-of-band signal energy, or no signal energy based on the noisemode configuration parameter. When no signal energy is being recorded or no signal energy occurred over a given request interval, the receiver sensitivity is used as the noise floor.
When recording all signal energy, it is the radio model's responsibility to remove the in-band signal from the spectrum window prior to computing the SINR.
The spectrum service can also be utilized by a radio model to support Dynamic Spectrum Access (DSA) by requesting a spectrum window over a valid time interval independent of an upstream packet reception.
The physical layer provides the ability to send multiple signals (of constant bandwidth) in frequency and/or time within a single OTA message. A radio model can utilize this feature by populating the frequency control message which accompanies a downstream packet processing request, with information for multiple frequency segments. Frequency segment information includes the segment center frequency, total time duration, and the offset from the transmission time stamp.
Depending on the current noise mode, one of four actions will be taken for all segments where the rxPower > rxSensitivity:
-
If noisemode is all, the signal energy for each frequency segment will be applied to the spectrum monitor based on frequency of interest bandwidth overlap.
-
If noisemode is outofband and this is an out-of-band packet, the signal energy for each frequency segment will be applied to the spectrum monitor based on frequency of interest bandwidth overlap.
-
If noisemode is outofband and this is an in-band packet, no energy will be applied to the spectrum monitor.
-
If noisemode is none, no energy will be applied to the spectrum monitor.
A radio model will only receive those frequency segments where rxPower > rxSensitivity. Any frequency segment that has a center frequency that is not in the physical layer's frequency of interest list will cause the entire message to be treated as out-of-band.
The physical layer provides the ability to send a single OTA message specifying multiple transmitters to minimize OTA traffic. A radio model can utilize this feature by populating the transmitter control message, which accompanies a downstream packet processing request, with information for multiple transmitters. Transmitter information includes the NEM Id of the transmitter and the transmission power.
Upon the reception of an OTA packet with multiple transmitters, the physical layer will calculate the rxPower from each transmitter and sum up the energy. Depending on the current noise mode, one of four actions will be taken, provided the summed rxPower > rxSensitivity:
-
If noisemode is all, the summed energy will be applied to the spectrum monitor based on frequency of interest bandwidth overlap.
-
If noisemode is outofband and this is an out-of-band packet, the summed energy will be applied to the spectrum monitor based on frequency of interest bandwidth overlap.
-
If noisemode is outofband and this is an in-band packet, no energy will be applied to the spectrum monitor.
-
If noisemode is none, no energy will be applied to the spectrum monitor.
Regardless of noisemode, the radio model will only receive the packet when the summed rxPower > rxSensitivity. The radio model will receive no indication that this packet was a collaborative transmission.
The physical layer supports per source fading model selection that can be modified via fading selection events. Fading selection is controlled by the fading.model configuration parameter and can be one of either none, event, nakagami, or lognormal. Specifying event requires fading selection events in order to determine the fading model to use per NEM source.
The Nakagami-m Fading model uses a gamma distribution to determine a fade loss value based on distance and power. Configuration parameters provide the ability to model various fading effects experienced in both indoor and outdoor environments based on empirical data. Parameters are used to specify two distance thresholds (meters) to establish three distance bounds: below, between, and above; and three shape factors corresponding to the three distance bounds.
The Lognormal Fading model models Free Space Optical (FSO) loss using a statistical mechanism. The Lognormal Fading model works by creating a constant series of fades, each having a constant fade depth that may contribute to over-the-air loss. The fading model keeps track of the time each fading period ends and generates a new fading period upon the arrival of the next over-ther-air frame after the conclusion of the current fading period. Fade depths are log normally distributed but constant during a given fading period. Fade lengths are normally distributed.
Lognormal Fading model configuration parameters are used to relate the fading depth to pathloss in order to cause a corresponding amount of over-the-air loss. There is an inverse relationship between fading depth and pathloss, where lower values for fading depth result in 100% loss, while higher values result in no loss. For values between no loss and full loss, linear interpolation is used to calculate the corresponding pathloss which may result in random loss during the fading period.
The physical layer supports MIMO by allowing simultaneous use of multiple transmit and receive antenna. Waveform implementation specifics are modeled within the radio model, with MIMO control messages conveying transmit and receive information between layers.
The MIMO capable physical layer is backward compatible with all radio models using with the emane 1.2.x non-MIMO API, allowing
over-the-air compatibility between MIMO (compatibility 2) and non-MIMO (compatibility 1) radio models. The physical layer compatibilitymode parameter is used to select between the non-MIMO API and the MIMO API. The compatibilitymode parameter defaults to 1 for the emane 1.2.x non-MIMO API. Radio models wishing to use the MIMO API should set compatibilitymode to 2. New radio models should use the compatibility 2 API, even if not modeling MIMO features. Note: Existing compatiblity 1 radio models will require a recompile.
Using MIMO API control messages, a radio model can define any number of receive antenna (ideal omni or antenna profile defined), and likewise, define multiple transmit antenna for each over-the-air transmission. Every received over-the-air message will be processed once for each receive path, where the total number of receive paths is equal to the number of transmit antenna multiplied by the number of receive antenna.
Receive antennas are added using the RxAntennaAddControlMessage, updated using the RxAntennaUpdateControlMessage, and removed using the RxAntennaRemoveControlMessage. When adding a receive antenna, a unique antenna index must be specified along with the frequency of interest information for the antenna and the antenna type: ideal omni (fixed gain) or antenna pattern defined (profile id and pointing). The unique index value supplied during RxAntennaAddControlMessage is how an antenna is referenced during an update or remove. It is also how per antenna receive power information is identified when communicating received over-the-air transmissions to the radio model via MIMOReceivePropertiesControlMessage.
When sending an over-the-transmission, a radio model specifies one or more transmit antenna along with one or more groups of frequency segments using MIMOTransmitPropertiesControlMessage. Each transmit antenna may be mapped to its own unique group of frequency segments or share a group with other transmit antennas. Each transmit antenna is specified using a unique antenna index value which is unrelated to indexes used when adding receive antennas via RxAntennaAddControlMessage.
A radio model is free to use the same index for receive and transmit antennas to create its own logical association of the same antenna being used for both receive and transmit. The physical layer does not store any transmit antenna information in the downstream direction. In the upstream (receive) direction, the physical layer caches computed gain information when using antenna profiles, so it is important to be consistent when indexing transmit antennas when sending over-the-air transmissions. For example, if NEM 1 has antenna A1 and antenna A2, where A1 is pointing at (Az1,El1) and A2 is pointing at (Az2,El2), sending over-the-air messages and alternating or changing transmit antenna indexes while not updating position and/or pointing, will defeat any possible receive side caching gains which are keyed off of transmit antenna index. Pick indexes for A1 and A2, then be consistent so receiving physical layers will not invalidate cached antenna gains unless actual position and/or pointing updates dictate so.
A radio model uses RxAntennaAddControlMessage to add receive antenna. Use one of the following methods to create antenna instances:
Antenna Antenna::createDefault();
Antenna Antenna::createIdealOmni(AntennaIndex antennaIndex,
double dFixedGaindBi);
Antenna Antenna::createProfileDefined(AntennaIndex antennaIndex,
const Pointing & pointing = {});
-
Antenna::createDefault(): Creates a default antenna which will either be an ideal omni with a fixed gain or a profile defined antenna, based on the physical layer fixedantennagainenable configuration parameter. -
Antenna::createIdealOmni(): Creates an ideal omni antenna with a specified fixed gain. -
Antenna::createProfileDefined(): Creates an antenna profile defined antenna with an optional initial pointing.
If the newly created receive antenna does not have it's bandwidth set, the physical layer will use the value from its bandwidth configuration parameter.
If the RxAntennaAddControlMessage contains an empty frequency of interest set, the physical layer will use the value(s) from its frequencyofinterest configuration parameter.
When sending a MIMOTransmitPropertiesControlMessage, use one of the following methods to create the transmit antenna:
Antenna Antenna::createIdealOmni(AntennaIndex antennaIndex,
double dFixedGaindBi);
Antenna Antenna::createProfileDefined(AntennaIndex antennaIndex,
const Pointing & pointing = {});
Use an empty antenna set when creating a MIMOTransmitPropertiesControlMessage to indicate use of the default antenna configuration, which follows the same assignment logic as Antenna::createDefault().
If the newly created antenna does not have it's bandwidth set, the physical layer will use the value from its bandwidth configuration parameter.
If any frequency segment has a 0 Hz frequency, the physical layer will use the value from its frequency configuration parameter.
If any frequency segment does not specify a transmit power, the physical layer will use the value from its txpower configuration parameter.
MIMO API radio models using antenna profiles must specify pointing information in every over-the-air transmission as part of MIMOTransmitPropertiesControlMessage. The MIMO compatible physical layer supports event compatibility with compatibility 1 radio models using external antenna profile events. Where, the AntennaProfileEvent allows for specifying profile and pointing information for a single antenna (always index 0) for each specified NEM.
When using the MIMO API to point and transmit simultaneously, and modeling a logical re-pointing of the same antenna for receive, you must specify both a MIMOTransmitPropertiesControlMessage and a RxAntennaUpdateControlMessage in order for the pointing to take effect for receive.
Each receive antenna has its own view of the spectrum, which internally maps to a unique spectrum monitor instance. When processing received over-the-air transmissions, radio models should wait for end-of-reception and then query for a spectrum window from each receive antenna using:
SpectrumWindow
SpectrumServiceProvider::requestAntenna(AntennaIndex antennaIndex,
std::uint64_t u64FrequencyHz,
const Microseconds & duration,
const TimePoint & startTime);
Using the requested SpectrumWindow(s), the MIMOReceivePropertiesControlMessage, and the contents of the radio model specific header, a radio model can perform its MIMO or non-MIMO receive processing.
The emulator physical layer calculates and applies Doppler shift when transmitter and receiver location and velocity are known at the receiver, and the dopplershiftenable configuration parameter is set to on. Doppler shift is applied when energy is added to spectrum monitor bins based on bandwidth overlap. Doppler shift information is communicated to compatibilitymode 2 radio models via the MIMOReceivePropertiesControlMessage as a mapping of center frequencies and their corresponding shift, both in Hz.
The following configuration parameters are available to tailor layer functionality:
- bandwidth
- compatibilitymode
- dopplershiftenable
- excludesamesubidfromfilterenable
- fading.lognormal.dlthresh
- fading.lognormal.dmu
- fading.lognormal.dsigma
- fading.lognormal.duthresh
- fading.lognormal.lmean
- fading.lognormal.lstddev
- fading.lognormal.maxpathloss
- fading.lognormal.minpathloss
- fading.model
- fading.nakagami.distance0
- fading.nakagami.distance1
- fading.nakagami.m0
- fading.nakagami.m1
- fading.nakagami.m2
- fixedantennagain
- fixedantennagainenable
- frequency
- frequencyofinterest
- noisebinsize
- noisemaxclampenable
- noisemaxmessagepropagation
- noisemaxsegmentduration
- noisemaxsegmentoffset
- noisemode
- processingpoolsize
- propagationmodel
- rxsensitivitypromiscuousmodeenable
- stats.receivepowertableenable
- subid
- systemnoisefigure
- timesyncthreshold
- txpower
Defines receiver bandwidth in Hz and also serves as the default bandwidth for OTA transmissions when not provided by the MAC.
Type: uint64
Running-State Modifiable: no
Occurrence Range: [1,1]
Value Range: [1,18446744073709551615]
Default Value(s): 1000000
Defines the physical layer compatibility mode.
Type: uint16
Running-State Modifiable: no
Occurrence Range: [1,1]
Value Range: [1,2]
Default Value(s): 1
Defines whether to perform Doppler shift processing when location and velocity information is known for both the transmitter and receiver.
Type: bool
Running-State Modifiable: no
Occurrence Range: [1,1]
Value Range: [no,yes]
Default Value(s): yes
Defines whether over-the-air (downstream) messages with a subid matching the emulator PHY subid (inband) should be processed for filter inclusion.
Type: bool
Running-State Modifiable: no
Occurrence Range: [1,1]
Value Range: [no,yes]
Default Value(s): no
Defines the lognormal fading depth lower threshold (below this threshold is 0% POR/100% loss).
Type: double
Running-State Modifiable: yes
Occurrence Range: [1,1]
Value Range: [-DOUBLE_MAX,DOUBLE_MAX]
Default Value(s): 0.250000
Defines the lognormal fading depth mu (mean of underlying normal distribution).
Type: double
Running-State Modifiable: yes
Occurrence Range: [1,1]
Value Range: [-DOUBLE_MAX,DOUBLE_MAX]
Default Value(s): 5.000000
Defines the lognormal fading depth sigma (standard deviation of underlying normal distribution).
Type: double
Running-State Modifiable: yes
Occurrence Range: [1,1]
Value Range: [-DOUBLE_MAX,DOUBLE_MAX]
Default Value(s): 1.000000
Defines the lognormal fading depth upper threshold (above this threshold is 100% POR/0% loss).
Type: double
Running-State Modifiable: yes
Occurrence Range: [1,1]
Value Range: [-DOUBLE_MAX,DOUBLE_MAX]
Default Value(s): 0.750000
Defines the lognormal fading length mean in seconds (normal distribution).
Type: double
Running-State Modifiable: yes
Occurrence Range: [1,1]
Value Range: [0.000000,DOUBLE_MAX]
Default Value(s): 0.005000
Defines the lognormal fading length standard deviation in seconds (normal distribution).
Type: double
Running-State Modifiable: yes
Occurrence Range: [1,1]
Value Range: [0.000000,DOUBLE_MAX]
Default Value(s): 0.001000
Defines the pathloss value (in dBm) corresponding to the fading depth lower threshold (0% POR/100% loss).
Type: double
Running-State Modifiable: yes
Occurrence Range: [1,1]
Value Range: [-DOUBLE_MAX,DOUBLE_MAX]
Default Value(s): 100.000000
Defines the pathloss value (in dBm) corresponding to the fading depth upper threshold (100% POR/0% loss).
Type: double
Running-State Modifiable: yes
Occurrence Range: [1,1]
Value Range: [-DOUBLE_MAX,DOUBLE_MAX]
Default Value(s): 0.000000
Defines the fading model: none, event, nakagami, lognormal.
Type: string
Running-State Modifiable: yes
Occurrence Range: [1,1]
Default Value(s): none
Regex: ^(none|event|nakagami)$
Defines the distance in meters used for lower bound shape selection.
Type: double
Running-State Modifiable: yes
Occurrence Range: [1,1]
Value Range: [-DOUBLE_MAX,DOUBLE_MAX]
Default Value(s): 100.000000
Defines the distance in meters used for upper bound shape selection.
Type: double
Running-State Modifiable: yes
Occurrence Range: [1,1]
Value Range: [-DOUBLE_MAX,DOUBLE_MAX]
Default Value(s): 250.000000
Defines the shape factor to use for distance < fading.nakagami.distance0.
Type: double
Running-State Modifiable: yes
Occurrence Range: [1,1]
Value Range: [0.500000,DOUBLE_MAX]
Default Value(s): 0.750000
Defines the shape factor to use for distance >= fading.nakagami.distance0 and < fading.nakagami.distance1.
Type: double
Running-State Modifiable: yes
Occurrence Range: [1,1]
Value Range: [0.500000,DOUBLE_MAX]
Default Value(s): 1.000000
Defines the shape factor to use for distance >= fading.nakagami.distance1.
Type: double
Running-State Modifiable: yes
Occurrence Range: [1,1]
Value Range: [0.500000,DOUBLE_MAX]
Default Value(s): 200.000000
Defines the antenna gain in dBi and is valid only when fixedantennagainenable is enabled.
Type: double
Running-State Modifiable: yes
Occurrence Range: [1,1]
Value Range: [-DOUBLE_MAX,DOUBLE_MAX]
Default Value(s): 0.000000
Defines whether fixed antenna gain is used or whether antenna profiles are in use.
Type: bool
Running-State Modifiable: no
Occurrence Range: [1,1]
Value Range: [no,yes]
Default Value(s): yes
Defines the default transmit center frequency in Hz when not provided by the MAC. This value is included in the Common PHY Header of all transmitted OTA packets.
Type: uint64
Running-State Modifiable: no
Occurrence Range: [1,1]
Value Range: [1,18446744073709551615]
Default Value(s): 2347000000
Defines a set of center frequencies in Hz that are monitored for reception as either in-band or out-of-band.
Type: uint64
Running-State Modifiable: no
Occurrence Range: [1,18446744073709551615]
Value Range: [0,18446744073709551615]
Default Value(s): 2347000000
Defines the noise bin size in microseconds and translates into timing accuracy associated with aligning the start and end of reception times of multiple packets for modeling of interference effects.
Type: uint64
Running-State Modifiable: no
Occurrence Range: [1,1]
Value Range: [1,18446744073709551615]
Default Value(s): 20
Defines whether segment offset, segment duration and message propagation associated with a received packet will be clamped to their respective maximums defined by noisemaxsegmentoffset, noisemaxsegmentduration and noisemaxmessagepropagation. When disabled, any packet with an above max value will be dropped.
Type: bool
Running-State Modifiable: no
Occurrence Range: [1,1]
Value Range: [no,yes]
Default Value(s): no
Noise maximum message propagation in microseconds.
Type: uint64
Running-State Modifiable: no
Occurrence Range: [1,1]
Value Range: [1,18446744073709551615]
Default Value(s): 200000
Noise maximum segment duration in microseconds.
Type: uint64
Running-State Modifiable: no
Occurrence Range: [1,1]
Value Range: [1,18446744073709551615]
Default Value(s): 1000000
Noise maximum segment offset in microseconds.
Type: uint64
Running-State Modifiable: no
Occurrence Range: [1,1]
Value Range: [1,18446744073709551615]
Default Value(s): 300000
Defines the noise processing mode of operation: none, all, outofband or passthrough.
Type: string
Running-State Modifiable: no
Occurrence Range: [1,1]
Default Value(s): all
Regex: ^(none|all|outofband|passthrough)$
Defines the number of processing pool threads. If > 2, pool threads are used to process receive paths per receive antenna. Using a processing pool does not guarantee increased performance. The processing pool can reduce the amount of processing time for an upstream message that contains a large number of frequency segments and/or a large number of transmit antenna (MIMO). Without a processing pool receive paths are calculated serially in a loop. There is a threshold where serial processing is faster than the context switching of the thread pool. Additionally, if the number of cores available to a running emane process is less than the processing pool size worse performance may be encountered.
Type: uint16
Running-State Modifiable: no
Occurrence Range: [1,1]
Value Range: [0,65535]
Default Value(s): 0
Regex: ^(0|[2-9]|[1-9]\d+)$
Defines the pathloss mode of operation: precomputed, 2ray or freespace.
Type: string
Running-State Modifiable: no
Occurrence Range: [1,1]
Default Value(s): precomputed
Regex: ^(precomputed|2ray|freespace)$
Defines whether over-the-air messages are sent upstream if below receiver sensitivity. Compatibility mode > 1 only. Messages sent upstream without a MIMOReceivePropertiesControlMessage.
Type: bool
Running-State Modifiable: no
Occurrence Range: [1,1]
Value Range: [no,yes]
Default Value(s): no
Defines whether the receive power table will be populated. Large number of antenna (MIMO) and/or frequency segments will increases processing load when populating.
Type: bool
Running-State Modifiable: no
Occurrence Range: [1,1]
Value Range: [no,yes]
Default Value(s): yes
Defines the emulator PHY subid used by multiple NEM definitions. Once instantiated, these NEMs may be using the same frequency. In order to differentiate between emulator PHY instances for different waveforms, the subid is used as part of the unique waveform identifying tuple: PHY Layer Registration Id, emulator PHY subid and packet center frequency.
Type: uint16
Running-State Modifiable: no
Value Required: yes
Occurrence Range: [1,1]
Value Range: [1,65535]
Defines the system noise figure in dB and is used to determine the receiver sensitivity.
Type: double
Running-State Modifiable: no
Occurrence Range: [1,1]
Value Range: [-DOUBLE_MAX,DOUBLE_MAX]
Default Value(s): 4.000000
Defines the time sync detection threshold in microseconds. If a received OTA message is more than this threshold, the message reception time will be used as the source transmission time instead of the time contained in the Common PHY Header. This allows the emulator to be used across distributed nodes without time sync.
Type: uint64
Running-State Modifiable: no
Occurrence Range: [1,1]
Value Range: [1,18446744073709551615]
Default Value(s): 10000
Defines the transmit power in dBm.
Type: double
Running-State Modifiable: yes
Occurrence Range: [1,1]
Value Range: [-DOUBLE_MAX,DOUBLE_MAX]
Default Value(s): 0.000000
Emulator physical layer configuration can be embedded directly in your NEM definition. There is no need to specify a definition attribute in this case.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE nem SYSTEM "file:///usr/share/emane/dtd/nem.dtd">
<nem>
<transport definition="transvirtual.xml"/>
<mac definition="rfpipemac.xml"/>
<phy>
<param name="fixedantennagain" value="0.0"/>
<param name="fixedantennagainenable" value="on"/>
<param name="bandwidth" value="1M"/>
<param name="noisemode" value="none"/>
<param name="propagationmodel" value="precomputed"/>
<param name="systemnoisefigure" value="4.0"/>
<param name="subid" value="2"/>
<param name="txpower" value="0.0"/>
</phy>
</nem>You can also specify physical layer configuration indirectly by pointing to a phy XML file.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE nem SYSTEM "file:///usr/share/emane/dtd/nem.dtd">
<nem>
<transport definition="transvirtual.xml"/>
<mac definition="rfpipemac.xml"/>
<phy definition="emanephy.xml"/>
</nem>This indirection allows you to reuse the bulk of your physical layer definition and override certain values where appropriate.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE phy SYSTEM "file:///usr/share/emane/dtd/phy.dtd">
<phy>
<param name="fixedantennagain" value="0.0"/>
<param name="fixedantennagainenable" value="on"/>
<param name="bandwidth" value="1M"/>
<param name="noisemode" value="none"/>
<param name="propagationmodel" value="precomputed"/>
<param name="systemnoisefigure" value="4.0"/>
<param name="subid" value="2"/>
<param name="txpower" value="0.0"/>
</phy>For example if you want another NEM defintion with a different systemnoisefigure you could do the following:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE nem SYSTEM "file:///usr/share/emane/dtd/nem.dtd">
<nem>
<transport definition="transvirtual.xml"/>
<mac definition="rfpipemac.xml"/>
<phy definition="emanephy.xml">
<param name="systemnoisefigure" value="4.9"/>
</phy>
</nem>The below statistics can be accessed using emanesh.
| Name | Type | Clearable | Description |
|---|---|---|---|
| avgDownstreamProcessingDelay0 | float | yes | Average downstream processing delay |
| avgProcessAPIQueueDepth | double | yes | Average API queue depth for a processUpstreamPacket, processUpstreamControl, processDownstreamPacket, processDownstreamControl, processEvent and processTimedEvent. |
| avgProcessAPIQueueWait | double | yes | Average API queue wait for a processUpstreamPacket, processUpstreamControl, processDownstreamPacket, processDownstreamControl, processEvent and processTimedEvent in microseconds. |
| avgTimedEventLatency | double | yes | |
| avgTimedEventLatencyRatio | double | yes | Average ratio of the delta between the scheduled timer expiration and the actual firing over the requested duration. An average ratio approaching 1 indicates that timer latencies are large in comparison to the requested durations. |
| avgUpstreamProcessingDelay0 | float | yes | Average upstream processing delay |
| numDownstreamBytesBroadcastGenerated0 | uint64 | yes | Number of layer generated downstream broadcast bytes |
| numDownstreamBytesBroadcastRx0 | uint64 | yes | Number of downstream broadcast bytes received |
| numDownstreamBytesBroadcastTx0 | uint64 | yes | Number of downstream broadcast bytes transmitted |
| numDownstreamBytesUnicastGenerated0 | uint64 | yes | Number of layer generated downstream unicast bytes |
| numDownstreamBytesUnicastRx0 | uint64 | yes | Number of downstream unicast bytes received |
| numDownstreamBytesUnicastTx0 | uint64 | yes | Number of downstream unicast bytes transmitted |
| numDownstreamPacketsBroadcastDrop0 | uint64 | yes | Number of downstream broadcast packets dropped |
| numDownstreamPacketsBroadcastGenerated0 | uint64 | yes | Number of layer generated downstream broadcast packets |
| numDownstreamPacketsBroadcastRx0 | uint64 | yes | Number of downstream broadcast packets received |
| numDownstreamPacketsBroadcastTx0 | uint64 | yes | Number of downstream broadcast packets transmitted |
| numDownstreamPacketsUnicastDrop0 | uint64 | yes | Number of downstream unicast packets dropped |
| numDownstreamPacketsUnicastGenerated0 | uint64 | yes | Number of layer generated downstream unicast packets |
| numDownstreamPacketsUnicastRx0 | uint64 | yes | Number of downstream unicast packets received |
| numDownstreamPacketsUnicastTx0 | uint64 | yes | Number of downstream unicast packets transmitted |
| numTimeSyncThresholdRewrite | uint64 | yes | Number of times Common PHY Header timestamp is overwritten with receive time due to timesyncthreshold setting. |
| numUpstreamBytesBroadcastRx0 | uint64 | yes | Number of upstream broadcast bytes received |
| numUpstreamBytesBroadcastTx0 | uint64 | yes | Number of updtream broadcast bytes transmitted |
| numUpstreamBytesUnicastRx0 | uint64 | yes | Number upstream unicast bytes received |
| numUpstreamBytesUnicastTx0 | uint64 | yes | Number of upstream unicast bytes transmitted |
| numUpstreamPacketsBroadcastDrop0 | uint64 | yes | Number of upstream broadcast packets dropped |
| numUpstreamPacketsBroadcastRx0 | uint64 | yes | Number of upstream broadcast packets received |
| numUpstreamPacketsBroadcastTx0 | uint64 | yes | Number of upstream broadcast packets transmitted |
| numUpstreamPacketsUnicastDrop0 | uint64 | yes | Number of upstream unicast packets dropped |
| numUpstreamPacketsUnicastRx0 | uint64 | yes | Number upstream unicast packets received |
| numUpstreamPacketsUnicastTx0 | uint64 | yes | Number of upstream unicast packets transmitted |
| processedConfiguration | uint64 | yes | |
| processedDownstreamControl | uint64 | yes | |
| processedDownstreamPackets | uint64 | yes | |
| processedEvents | uint64 | yes | |
| processedTimedEvents | uint64 | yes | |
| processedUpstreamControl | uint64 | yes | |
| processedUpstreamPackets | uint64 | yes |
The below statistics can be accessed using emanesh.
| Name | Clearable | Description |
|---|---|---|
| AntennaProfileEventInfoTable | no | Shows the antenna profile information received |
| BroadcastPacketAcceptTable0 | yes | Broadcast packets accepted |
| BroadcastPacketDropTable0 | yes | Broadcast packets dropped by reason code |
| EventReceptionTable | yes | Received event counts |
| LocationEventInfoTable | no | Shows the location event information received |
| PathlossEventInfoTable | no | Shows the precomputed pathloss information received |
| UnicastPacketAcceptTable0 | yes | Unicast packets accepted |
| UnicastPacketDropTable0 | yes | Unicast packets dropped by reason code |
- Home
- Introduction
- EMANE Shell
- Emulator Physical Layer
- Radio Models
- Utility Models
- Transports
- Event Generators
- Event Agents
- Building Packages
- Installing Packages
- Developer Documentation
- FAQ
- Copyright