Skip to content

Physical Layer Model

Jump to bottom
Steven Galgano edited this page Mar 28, 2017 · 15 revisions

Contents

Features

Propagation 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.

Receive Power Calculation

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

Antenna Gain Support

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.

Fixed Antenna Gain

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.

Antenna Profile

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:

  1. 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.

  2. 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.

Noise Processing

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.

Frequency Diversity

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:

  1. 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.

  2. 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.

  3. If noisemode is outofband and this is an in-band packet, no energy will be applied to the spectrum monitor.

  4. 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.

Collaborative Transmission

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:

  1. If noisemode is all, the summed energy will be applied to the spectrum monitor based on frequency of interest bandwidth overlap.

  2. 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.

  3. If noisemode is outofband and this is an in-band packet, no energy will be applied to the spectrum monitor.

  4. 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.

Configuration Parameters

The following configuration parameters are available to tailor layer functionality:

bandwidth

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

fixedantennagain

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

fixedantennagainenable

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

frequency

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

frequencyofinterest

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

noisebinsize

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

noisemaxclampenable

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

noisemaxmessagepropagation

Noise maximum message propagation in microseconds.

Type: uint64
Running-State Modifiable: no
Occurrence Range: [1,1]
Value Range: [1,18446744073709551615]
Default Value(s): 200000

noisemaxsegmentduration

Noise maximum segment duration in microseconds.

Type: uint64
Running-State Modifiable: no
Occurrence Range: [1,1]
Value Range: [1,18446744073709551615]
Default Value(s): 1000000

noisemaxsegmentoffset

Noise maximum segment offset in microseconds.

Type: uint64
Running-State Modifiable: no
Occurrence Range: [1,1]
Value Range: [1,18446744073709551615]
Default Value(s): 300000

noisemode

Defines the noise processing mode of operation: none, all or outofband.

Type: string
Running-State Modifiable: no
Occurrence Range: [1,1]
Default Value(s): all
Regex: ^(none|all|outofband)$

propagationmodel

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)$

subid

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]

systemnoisefigure

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

timesyncthreshold

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

txpower

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

Example XML

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>

Statistics

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

Statistic Tables

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
Clone this wiki locally