NRTxPdcpEntity::deliverPdcpPdu - the destination is not a UE but Dual Connectivity is not enabled.

[christianquadri]

Hello,
I am still simulating a platooning scenario in which other vehicles that are not part of the platoon create some background traffic.
These vehicles travel alongside the platoon. Each vehicle generates traffic using 1 UPD application UdpBasicApp generating constant bit rate traffic and a remote host simply echoes the traffic (symmetric data rates UL/DL).

I am trying to saturate the gNodeB resources to create congestion conditions at the RAN level.
I create 20 background cars generating 3000B every 30 ms as shown in the following:

*.bgcar[*].numApps = 1
*.bgcar[*].app[0].typename = "UdpBasicApp"
*.bgcar[*].app[0].messageLength = 3000B
*.bgcar[*].app[0].sendInterval = 30ms
*.bgcar[*].app[0].destAddresses = "bgHostA"
*.bgcar[*].app[0].localPort = 80 + ancestorIndex(0) 
*.bgcar[*].app[0].destPort = 8000

This amount of traffic saturates the resources at the gNBs (25 RBs each) in the case of low CQI levels. Roughly the background traffic is about 150% of the available resources in uplink.

In a particular moment, which varies according to the seed, I got this error:
<!> NRTxPdcpEntity::deliverPdcpPdu - the destination is not a UE but Dual Connectivity is not enabled. -- in module (NRPdcpRrcEnb) MultiBSNetMultiPlatoon.gB2.cellularNic.pdcpRrc (id=294), at t=215.0500112184s, event #48233486
At that moment many vehicles are performing handovers and many of them are more or less in between two adjacent BS.

I have tried to reduce the handover time to 20ms, increase RLC um.queueSize, increase x2ppp mtu, but the error happened always at the same time (with a specific seed)

Here is the .ini file of my simulations (config MultiBsMultiPlatoonWithRANBG)
omnetpp.zip

Thank you in advance for your time.

Christian

[giovanninardini]

Hi Christian,

it is not easy to say what is going on. As you probably have noticed already, the problem lies in the value assigned to the destId field at the PDCP layer of the gNB when it wants to transmit the packet in the downlink to a UE.
I am trying to guess... is it likely that the UE went out of the coverage of every gNB?
This might occur when the received signal from every gNB is below a certain threshold, and in that case the masterId field for the UE is set to 0, which might be the cause for that exception

[christianquadri]

Hi Giovanni,
thank you for the quick answer.

I investigated a bit to test your hypothesis.
The distance between each pair of BS is 1500m and all BSs are deployed in a linear layout to simulate BS deployment along a straight highway.
I analyzed the SINR and the distance from the service cell:

SINR

DISTANCE

Honestly, I was not expecting this result, because the distance should be at most around 750m

SERVING CELL (ID)

Finally, I tried to reduce the spacing between BSs to 1000 m (was 1500m), but I got the same error.

Last but not least, since I have a linear deployment of the base stations I only connected adjacent BSs via X2, I did not create a full mesh among BSs.

Thank you again for your help.

Christian

[christianquadri]

Hi Giovanni,
here are some other details about what is going on just before the exception.

I just added a line to report the destination ID. ID = 3 shoud be gB2 (the third BS)

Here the message exchanges inside gB1.cellularNic.pdcpRrc (the sender)

Christian

[giovanninardini]

Hi Christian,

I'm trying to add some information, because the behavior looks weird...

So, the exception is generated by the NRTxPdcpEntity::deliverPdcpPdu() function, because the destId variable has value 3.
From the log I can see that when the packet was processed at the ip2Nic submodule, destId was correct (destId: 2075).
This means that the destId was changed by some function in between, and the guilty party is the LteTxPdcpEntity::handlePacketFromUpperLayer() function, which in turn invokes the setIds() function. The latter at some point calls NRPdcpRrcEnb::getDestId(), which does this:

    // master of this ue
    MacNodeId master = binder_->getNextHop(destId);
    if (master != nodeId_)
    {
        destId = master;
    }   

Here is where the destId is changed. And apparently this happens because the destination UE is "attached" to gNB2 (id=3) at the moment of the exception, whereas the packet is being processed by gNB1...
So, the packet is being processed at the wrong gNB and we should understand why... Probably, the UE just completed a handover a few microseconds before: do you know if this handover is from gNB1 to gNB2 or from gNB2 to gNB1?

[christianquadri]

Hi Giovanni,
the handover should be from gNB1 to gNB2.
I also notice that the behavior changes between release and debug mode. The exception has been raised in both cases but at different times (with the same seed).
I am trying to guess... could be some special case in which the information in binder_ is not correctly updated because of the handover and high load of the base station?

Please let me know if you need more information or logs.

Thank you again for your support.