sgalgano
commented
4 years ago Typically emane models do not delay on the transmit side prior to sending an over-the-air message. The goal is to get over-the-air messages to all nodes as fast as possible. At all receivers, the physical layer records spectral energy in one or more circular buffers based on the transmitter frequency(s) and bandwidth, and receiver frequencies of interest and bandwidth. The receiving physical layers record spectral energy starting at start-of-reception (SoR), where:
SoR = transmission timestamp + propagation delay
Receiving radio models must wait until end-of-reception (EoR) before calculating over-the-air message SINR in order to determine the probability of reception (PoR). This is where the first delay in processing occurs:
EoR = SoR + duration
The transmitter must wait after sending the over-the-air message until end-of-transmission (EoT) before it can send another message:
EoT = transmission timestamp + duration
transmission timestamp is start-of-transmission. It is the txTimeMicroseconds common phy header item.
hideogump
Depending upon which model is used, my general observation is that when monitoring the OTA EMANE bus interface, the time of transmit on this bus relative to reception by the EMANE NEM stack for downstream messages is less than 1 ms. When a TimeStamp message is provided with the downstream packet specifying some future time, say platform time plus a millisecond or so, the EMANE stack does not delay the message when observed on the OTA interface, it is simply an attribute carried in the EMANE Common Phy Header.
Conversely, when viewing the time of arrival for the upstream direction at the application emulation boundary, from a receiving NEM's perspective, this time of arrival does not reflect perhaps the future dated time of transmit, and the message could be received before the tx message timestamp.
Another way of stating this, the NEM stack in the upstream direction does not hold up an upstream message based on what could be a future time for the transmitted message relative to the platform time.
Likewise, if the timestamp message associated with transmit message are out of order relative to actual passing down the stack, the receive NEM stack will not then re-order the packets as sent to the emulation boundary based on the tx timestamp. For example, if a message is transmitted at time t0 with a timestamp specifying current platform time plus say 2 milliseconds, and then a following tx message at a tx time very close to time t0, specifies a tx time of current time plus 1 ms, then the upstream message will not be sorted so that the 2nd message is received before the 1st based on the transmit timestamp.
Are these observations correct?