I have some ambiguity in understanding the transmit time for a downstream 
packet, the reception time of a packet on a receiver, and how propagation 
delays are configured and implemented in the EMANE framework.  This discussion 
is for single platform emulation, so time synch between separate platforms is 
not an issue.

Per the documentation, a radio model can send a TimeStampControlMessage to 
specify the transmission time stamp used in the CommonPHYHeader. This time 
should be the start-of-transmission time for the message.
 
Presumably the actual platform time of transmit is the time stamp value 
provided plus the offset value in microseconds for a frequency segment.

Presumably if this optional message is not provided, the time of the actual 
transmission of host traffic and specified on the CommonPHYHeader used as the 
timestamp is the platform's current real time clock value?

Now is this the time that the host packet is actually passed over the OTA 
network at the specified transmit time, presumably representing a future time 
relative to the platform's current time when the processDownstream method is 
invoked? 

If not, would it be possible for a receiver to receive a message prior to the 
specified transmit time?
 
If the time of transmit is already past relative to the platform time, does the 
packet get transmitted anyway?

If the receiver uses the platform time stamp upon reception, does this 
represent the transmit time in the transmit packet's CommonPHYHeader plus some 
configured propagation delay?

The timing analysis shim embeds in a custom header the platform transmit time 
as the real time clock, then upon reception, uses the platforms real time clock 
to determine the reception time, and logs the packet delay.

Relative to the timing analysis shim, it logs the results after the stop() 
method of the shim layer is invoked?

How is this method invoked from say the command line.  Typically, I shut down 
EMANE by destroying the LXC that contains it, which does not appear to call 
stop().

What is the purpose of the timing analysis relative to this conversation and 
packet propagation delays?  It appears to log the actual delay time between 
transmit and reception of a message relative to the platforms time standard 
(and not the time value in the CommonPHYHeader).
_______________________________________________
emane-users mailing list
emane-users@nrl.navy.mil
https://publists.nrl.navy.mil/mailman/listinfo/emane-users

Reply via email to