LTE Propagation Delay

[Kevin Pham]

Hello all, first time on this forum.

I am using NS3 to simulate a simple LTE network. I want to move the UE's around and ping  a node, which will respond when the data is received. I have the pinging working properly, and the nodes are mobile. 

I am currently using  the following code to view my output.

LogComponentEnable ("UdpEchoClientApplication", LOG_LEVEL_INFO);

LogComponentEnable ("UdpEchoServerApplication", LOG_LEVEL_INFO);

When running the program, the ping time is always the same, despite the nodes moving.

ex: it will ping at 6.500s and get a response at 6.515s. The next ping will be at 7.5 with a response at 7.515s. This pattern repeats.

Is my propagation delay not set properly? I have been using

lteHelper->SetAttribute ("PathlossModel", StringValue ("ns3::RandomPropagationLossModel"));

I have also tried FriisPropagationLossModel but no change output. I figured with moving nodes, the values should be changing due to distance. I also used the RandomPropLoss model to see if that would change anything, but my output is the same.

Attached I have my source code.

Thanks for all the help!

[Tom Henderson]

On 7/14/21 3:59 PM, Kevin Pham wrote:

Hello all, first time on this forum.

I am using NS3 to simulate a simple LTE network. I want to move the UE's around and ping  a node, which will respond when the data is received. I have the pinging working properly, and the nodes are mobile. 

I am currently using  the following code to view my output.

LogComponentEnable ("UdpEchoClientApplication", LOG_LEVEL_INFO);

LogComponentEnable ("UdpEchoServerApplication", LOG_LEVEL_INFO);

When running the program, the ping time is always the same, despite the nodes moving.

ex: it will ping at 6.500s and get a response at 6.515s. The next ping will be at 7.5 with a response at 7.515s. This pattern repeats.

Hi Kevin, I think that it is probably the precision of the ping RTT reports (milliseconds) being too coarse to observe smaller distance-based propagation delay variations.  Keep in mind that 100 meters is only about 0.5 microseconds of propagation delay.

Is my propagation delay not set properly? I have been using

lteHelper->SetAttribute ("PathlossModel", StringValue ("ns3::RandomPropagationLossModel"));

The pathloss model does not affect propagation delay, but in any case, I would not use 'Random' (which I do not believe corresponds to anything real).  Friis may be a good first choice.

- Tom

I have also tried FriisPropagationLossModel but no change output. I figured with moving nodes, the values should be changing due to distance. I also used the RandomPropLoss model to see if that would change anything, but my output is the same.

Attached I have my source code.

Thanks for all the help!

--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ns-3-users/e44a3594-404b-4a8d-a3fd-ce4fae936cb2n%40googlegroups.com.

[Kevin Pham]

Hi Tom, thanks for the response.

How would I go about adding propagation delay to my simulation? I have been looking at the lena-pathloss-trace.cc file and trying to incorporate that into my code. Are there any other good example files or links that may help me?

-Kevin

[Tom Henderson]

On 7/15/21 11:19 AM, Kevin Pham wrote:
> Hi Tom, thanks for the response.
> How would I go about adding propagation delay to my simulation? I have
> been looking at the lena-pathloss-trace.cc file and trying to
> incorporate that into my code. Are there any other good example files
> or links that may help me?

To clarify, you already have propagation delay (your ping RTT reports
just are not showing the variation).  If you want to artificially add
more, you could try to change the "Speed" attribute value in
ConstantSpeedPropagationDelayModel to something slower than speed of
light (although I am not sure whether this will break LTE protocol
mechanisms that expect a sub-ms propagation delay).

- Tom