Hello,
I have recently set up a simulation envionment deploying dual connectivity, however upon observing it for an extended duration I realized that at some point a handover will be executed that connects the UE with an eNB instead of its secondary gNB. From this point onward the data in an Uplink scenario is not forwarded to the router or server anymore, due to setting the tos to 10. Afterwards no further handovers to gNBs are undertaken and the UE stays connected solely to eNBs instead.
Before the handover:
After the handover:
The airframe is send to the eNB, but due to the tos of 10 no data is send further:
I was actually capable of recreating the behavior in the NR/dualConnectivity_multicell scenario by changing the duration of the simulation and finishTime of the SingleConnection-CBR-UL configuration:
Line 4: sim-time-limit = 400s
LIne 212: .ue[*].app[\].finishTime = 399.9s
Letting the simulation continue even further leads to the following error message, which I have also received during my simulations numerous times:
Setting allow-object-stealing-on-deletion to true at the right point within the configuration can prevent this last error.
For all of these issues the following versions were used:
omnetpp: 6.0.1
inet: 4.4.1
simu5g: 1.2.1
Hello, I have recently set up a simulation envionment deploying dual connectivity, however upon observing it for an extended duration I realized that at some point a handover will be executed that connects the UE with an eNB instead of its secondary gNB. From this point onward the data in an Uplink scenario is not forwarded to the router or server anymore, due to setting the tos to 10. Afterwards no further handovers to gNBs are undertaken and the UE stays connected solely to eNBs instead.
Before the handover:![Before problematic handover](https://user-images.githubusercontent.com/116574064/218063404-0b223f88-d1a9-47f3-9f5d-087e688d891a.png)
After the handover:
The airframe is send to the eNB, but due to the tos of 10 no data is send further:![Airframe only](https://user-images.githubusercontent.com/116574064/218065536-dc80290f-f3e7-43e1-b67c-47ebe3b78f9e.png)
I was actually capable of recreating the behavior in the NR/dualConnectivity_multicell scenario by changing the duration of the simulation and finishTime of the SingleConnection-CBR-UL configuration:
Letting the simulation continue even further leads to the following error message, which I have also received during my simulations numerous times:
Setting allow-object-stealing-on-deletion to true at the right point within the configuration can prevent this last error.
For all of these issues the following versions were used: omnetpp: 6.0.1 inet: 4.4.1 simu5g: 1.2.1