Running an LTED2D application and an ITS-G5 service at the same time

[BadreddineYACHEUR]

Hi @riebl, I created a LTED2D scenario using the artery.lte.car node and the artery.lte.world with an ITS-G5 service and an LTED2D application (UDP application). These two applications use the same defined message structure. the issue is that when I want to transmit a packet in the format of this message with the LTE application i receive the flowing error:

send()/sendDelayed(): Cannot send message ("Defined message"), it is currently contained/owned by (ItsG5App) World.node[0].middleware.ItsG5App -- in module (LteApp) World.node[0].udpApp[0] (id=183), at t=0.236632716004s, event #964

I tried to define another structure for LTE messages but the same error was prompted to me.

[riebl]

Are you trying to send the very same message object in both applications? You need to create a duplicate of the message then, e.g. send the original msg in ItsG5App and msg->dup() in udpApp[0] (or vice versa).

[BadreddineYACHEUR]

At first I tried to send the same message, now I'm not sending the same message, I even changed the structure of the message, I mean I'm sending a Defined_message via ITS-G5 and Defined_messageLTE via the UDPApp and I'm still having the same error.

[riebl]

Sorry, it is hard to say what is going wrong in your case. Can you share your code with me, e.g. by pushing it to GitHub?

[BadreddineYACHEUR]

Yeah, No problem I will share with you the scenario I'm creating

[BadreddineYACHEUR]

Here is the repo "LTE_ITS-G5-Scenario", it is public in my account. In this version of the code I'm using the same message structure and the msg->dup() in the ItsG5App. One replica of the message is sent by the request method in the ItsG5App and the other replica is sent embedded in a signal to the LteApp (udpApp[0]) and this UDP application will send the message received in the signal via a D2D link. Hope this will help you understand my issue.

[riebl]

Okay, thanks for sharing your scenario. I can reproduce your problem and have been able to fix it:

• ItsG5App.cc: replace request(req, packet->dup()); by request(req, packet)
• LteApp.cc: replace socket.sendTo(packet, mcastAddress, par("mcastPort")) by socket.sendTo(packet->dup(), mcastAddress, par("mcastPort"))

You "get" the PlatooningMessage in LteApp via a signal emitted by ItsG5App. These signals do not transfer the ownership of attached objects. This behaviour is just how OMNeT++ has implemented signals, it is not unique to Artery or SimuLTE. Hence, you have to duplicate the message in the LteApp, which can then own this duplicate of the original message.

[BadreddineYACHEUR]

Thanks for your help dear, it is so odd that it reproduced the same error when I tried to create a new message in the LteApp.

However, I lunched the simulation and after some seconds it stopped on an error: Segmentation fault (core dumped), I saw the issue #42 , and unfortunately I had nothing with the debug mode. I tried to run the simulation scenario in another machine but I'm getting the same error: Segmentation fault. Is it the same for you when you try to lunch my scenario?

PS: I'm lunching the scenario in the Qtenv and I think that the emitted signal is the cause of this issue, I tried to remove the signal logic from my code and I didn't have the Segmentation fault error

[riebl]

Yes, I also see a segmentation fault. It is occurring later at time 5.3s than the transmission of PlatooningMessage. Something odd seems to happen in LteCellInfo::lambdaInit.

Edit: The getCellInfo call in LtePhyUe.cc returns a null pointer. This empty LteCellInfo* pointer is then used without further checks and thus leading to the segmentation fault. I suppose the node launched at that time is out-of-coverage of any eNodeB.

[BadreddineYACHEUR]

Yes, I noticed that too. Before lunching the ItsG5App (without the signal logic) the segmentation fault used to occur at time 31s. But when I used the signal it occurs at time 5.3s. I solved that by adding a 2nd eNodeB. Thanks for your HELP dear.

[riebl]

You are welcome. I close this issue ticket then.