Subject: Issue Connecting to Trace Source: /NrRlc/TxDrop

[Guy Gabay]

Dear 5G-LENA developers,

I'm currently working with the 5G-LENA module in ns-3 and trying to connect a trace source to monitor RLC transmission drops using the following path:

/NodeList/*/DeviceList/*/$ns3::NrUeNetDevice/nrUeRrc/DataRadioBearerMap/*/NrRlc/TxDrop

However, I'm encountering a fatal error:

 msg="Could not connect callback to /NodeList/*/DeviceList/*/$ns3::NrUeNetDevice/nrUeRrc/DataRadioBearerMap/*/NrRlc/TxDrop",
file=/src/core/model/config.cc, line=972  
NS_FATAL, terminating  
terminate called without an active exception  
Aborted (core dumped)

It seems the path is either invalid at runtime or the object is not instantiated when the connection is attempted. 

Any guidance or working example would be greatly appreciated.

[Tom Henderson]

Yes, i believe that the RLC object will not be created until the time that the bearer is set up.  You will need to write a small function or lambda to schedule a future event, at at time that you believe it will be instantiated, to connect to the callback.  A similar problem arises with TCP sockets that are not yet instantiated at time zero.  There is an example TCP program (examples/tcp/tcp-validation.cc) that demonstrates how this kind of delayed trace source attachment can work (search for ScheduleFirstTcpCwndTraceConnection in that file).

- Tom

--
You received this message because you are subscribed to the Google Groups "5G-LENA-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to 5g-lena-user...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/5g-lena-users/d577e53c-20af-4fe2-a5fa-7267cce52dban%40googlegroups.com.

[Tom Henderson]

The way that I usually debug something like that (i.e., a trace source
never is triggered even though I expect it to) is to turn on logging in
the model and see if the code around that trace source is being called.

In this case, the TxDrop is linked to m_txDropTrace(p) and you can try
to turn on NS_LOG="NrRlcUm" log component and see if the log statements
preceding the two calls to the drop trace are being printed. If not,
that would explain the lack of output (and that your packet loss is
elsewhere).

The 'cttc-nr-demo' tutorial tries to identify, at each layer, whether a
packet drop could occur there and how to look for them.

- Tom


>
> However, while the connection to |TxDrop| no longer throws an error,
> it also doesn't seem to generate any output — even when I simulate
> clear packet loss scenarios. Do you know under what conditions the |
> TxDrop| trace source is triggered in the RLC implementation? Is it
> perhaps only activated in specific RLC modes or configurations?
>

[Guy Gabay]

Hi Tom,

Thanks again for your previous guidance. I wanted to give a quick update and also ask a couple of follow-up questions.

I scheduled the callback connection as you suggested and enabled the NrRlcUm logging component. However, I still don’t see the TxDrop trace source being triggered at all. When looking into the nr-rlc.cc code, it seems like the TxDrop trace source is defined, but not actually connected to any dropping logic (perhaps m_txDropTrace is not called anywhere relevant). Could you please clarify if this trace source is currently functional or if it needs explicit triggering that I might have missed?

Additionally, while using the TxPdu and RxPdu trace sources, I consistently see only LCIDs 4 and 5 when running examples like cttc-nr-demo. I expected to observe LCIDs 0 or 1 for the default DRBs typically associated with initial user traffic, but these never appear in my logs. Could you shed some light on why that might be the case? Is there perhaps a specific mapping or configuration in the 5G-LENA setup that assigns data to LCID 4 and 5 instead?

Really appreciate all your help and insights.

ב-יום שלישי, 24 ביוני 2025 בשעה 16:10:39 UTC-4, Tom Henderson כתב/ה:

[Rahul M.]

Hi,

I have attached here a sample example which can be executed as follows:

 ./ns3 run "simple --errorModelType=ns3::RateErrorModel" (enables the rate error model)

OR

./ns3 run "simple --errorModelType=ns3::BurstErrorModel" (enables the burst error model)

OR

./ns3 run simple

In the output trace file simple-error-model.tr, I am not able to see any change.

Can you please suggest why the following error insertion inputs are ineffective:

Config::SetDefault("ns3::RateErrorModel::ErrorRate", DoubleValue(0.01));

Config::SetDefault("ns3::BurstErrorModel::ErrorRate", DoubleValue(0.1));

I have installed ns-3.44 along with the 5G-LENAv4.0

Any leads will be immensely helpful.

Thanks and Best Regards

Rahul M.