delay between UE's MAC layer and eNB's Phy layer

[Messaoudi Farouk]

Hi there,

I'm new to ns3, I'm trying to simulate the LTE + EPC model using one UE connected to a remote host (intenet) over an eNB.
 I generate a UDP traffic between the UE and the remote host.

I'm trying to calculate the delay between the Mac layer on the UE when a packet is sent and the time that packet is received on the eNB.
To do that I used a tag which, I add to the packets in the mac layer method:
void LteUeMac::DoTransmitPdu (LteMacSapProvider::TransmitPduParameters params) .
 
I tag a packet like this :

TimestampTag timestamp;
  timestamp.SetTimestamp (Simulator::Now ());
  params.pdu->AddPacketTag (timestamp);



and when  the packet is received on the eNB on the mac layer, method : void LteUeMac::DoTransmitPdu (LteMacSapProvider::TransmitPduParameters params).

 I check that tag :


TimestampTag timestamp;
 p->RemovePacketTag (timestamp);
 
and calculate the delay like this:

Time tx = timestamp.GetTimestamp ();
Time delay = Simulator::Now () - tx; 

I have three questions for this:
1. is it correct to do that?
2. I obtain as UL 4.7ms and for DL 2.99 ms, is these values relevant in ns3?
3. Incrementing the number of UEs, put them farther from the eNB, reducing the bandwith, reducing the interval between packets (1ms) and increasing the size of RLC buffer , I still obtain always the same values (4.7ms for the UL and 2.99ms for DL) so my question is: I'm doing something wrong? missing some parameters? or it's a bug in lena.



Thanks in advance for reviews.

[Messaoudi Farouk]

Updates!!!!
....
....
....

and when  the packet is received on the eNB on the mac layer, method : void LteEnbMac::DoReceivePhyPdu (Ptr<Packet> p).

[Marco Miozzo]

Hi,

it depends on which MAC delay you are interested on, actually with the approach you proposed you are calculating the PHY one.

I would suggest to use the RLC of PDCP one in order to consider the delay introduced by MAC algorithms (i.e., RLC retransmissions and MAC scheduling policy).

On this matter, you can use the standard output of the module, more info at the following link:
https://www.nsnam.org/docs/release/3.16/models/html/lte-user.html#simulation-output

Best,

marco.

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at https://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

[Messaoudi Farouk]

Hi Marco,

Thank you very much for your answer,

I would like to ask you some others questions about that if you agree:

1. The outputs shown differents files; lets focus on the layers PDCP and MAC
 
    * There are two files for PDCP statistics (DlPdcpStats.txt,  UlPdcpStats.txt). As I understood one is for Downlink and the other one for Uplink, However, what I don't understand is: there is only one layer PDCP that the eNB and the UE share (in lena project), so an Uplink from the UE is a Downlink for the eNB, and a Downlink from the UE is an Uplink for the eNB. Therefore, these two files are generated on the eNB or the UE? and when an infromation is wrote in DlPdcpStats.txt (respectively UlPdcpStats.txt) it should be wrotten in UlPdcpStats.txt (respectively DlPdcpStats.txt) . IS IT TRUE????

    * For the MAC layer, there are also two files, (the same questions here!). Add to that, the following one:
       - considering for example the UlPdcpStats.txt, lets chose one line from the file: the firs column is the start time, the second one is the end time: this is an epoch duration for the simulation, we keep in mind the IMSI and the delay in the same line. Now in the file UlMacStats.txt, we select all the lines starting from the  start time to the end time (the epoch duration for the line shoosen in the file UlPdcpStats.txt),  we seek for all the UE with the IMSI equal to that one obtained in the UlPdcpStats.txt (number of times the UE with IMSI was scheduled during the epoch duration). My question is: dividing the epoch duration on the  of times the UE with IMSI was scheduled during the epoch duration, we obtain a delay, comparing this delay with that one obtained in the UlPdcpStats.txt, is not the same, and there is a big difference (tens of milliseconds) why????


Thanks in advance.

[Biljana Bojović]

Hi Massaoudi,

please go again through the link that Marco shared the description of PDCP traces. This files are not generated neither per eNB, nor per UE, these are system level traces. Regarding the MAC traces, they are generated both at eNodeB, since the scheduling for DL/UL is performed at eNodeB MAC.

Regarding your last question about calculation of delay and epoch, I do not understand what are you asking. Please check again the description of traces, I think it will help understanding them and how to obtain necessary metrics.

Cheers,
Biljana

[Messaoudi Farouk]

Hi Bojović,

Thank you very much for the answer, it is more clear now. However, about my other question, I still have a concern on that. Hereafter, a better presentation of the problem:

We know that the transmission time interval (TTI) (or the smallest scheduling interval) in LTE is 1 ms . If we fix a period T to 1 s , then each period will include 1000 UL scheduling . If a UE has been scheduled X times during T , we can estimate the average access delay during the period T , noted by D , as T /X . Of course
this calculation represents an average, which may not lead to an exact estimation.
1. The X value is easily computed from the UlMacStats.txt, (sum the IMSI for the same UE), the result X will be the number of times the UE was scheduled during the whole simulation.Hence, to obtain the delay D, we multiplay T by the simulation time and after we get  (D = T/X).

2. From the file UlPDCPStats.txt, we compute the average of packet delay (lets call it D_avg).
If we compare D_avg with D, it is completly different, I don't understand why?  
 
Thanks in advance,

Farouk

[Biljana Bojovic]

Hi Farouk,

I understand now better. In calculation 1.,  there is no notion of the amount of data or at least to say what is assumed. So, I think 1. and  2. are different delays. Delay in 1.  seems to be an average time UE waits to be scheduled. In 2.  the delay is per PDCP PDU. This should be the main reason of completely different values. Is that right?

Best regards,

Biljana

--

[Messaoudi Farouk]

Some Updates:

Hi Biljana,

 

Yeah you right. However, it should give a correct approximations with a standard deviation of order of (6 ms), here more explanation:

 

1.
- The unit of time in the LTE module is the TTI, which is 1 ms long.

 

- The processing times are implemented for respecting the 3GPP guidelines in terms of RTT (of 7 ms).

 

- In detail the MAC to channel delay (i.e., The delay in TTI units that occurs between a scheduling decision in the MAC and the actual start of the transmission by the PHY, used to model the latency of real PHY and MAC implementations) is of 2 TTIs, while the uplink PUSCH TTIs delay is fixed  to 4 TTIs according to TS 36.213 section 8.

2.
The scheduling depends on different parameters, especially the channel conditions and the bandwidth. Hence, if the PDCP PDU delay change, the scheduling average time as computed (D = T/X) should change accordingly.

But it is not the case here (it looks like random change)!

cheers,
Farouk

[Biljana Bojovic]

Hi Farouk,

ok, I agree with your points, but as I do not know the number you are getting from traces and the values your are expecting, I am not convinced about comparison of these delays.

Can you e.g. give an example how much is the delay according to UL traces, and how much is in PDCP for the corresponding time epoch, and how much you expect PDCP delay to be (taking into account the delays of LTE protocol stack).

Best regards,

Biljana