LTE NLOS > 5000

[rtobi]

Hi, I am facing some issues when using a network of multiple eNodeBs. Vehicles are in range (distance < 5000) of one, but not of all base stations. Tolerating the distance violation (tolerateMaxDistanceViolation=true, LteChannelModel.ned) stops throwing the distance error, but comes along with a segmentation fault in the setup of the LTE network which I am not able to isolate. The problem may be more related to the extern package simulte, but maybe someone faced similar issues and found a solution?

Many thanks in advance and best regards, rtobi

[riebl]

Hi @rtobi,

can you share your scenario with us, e.g. by pushing it to a branch on GitHub? Having the same setup helps a lot to track down the reason for this issue.

[rtobi]

Thanks for the quick reply @riebl! I tried to achieve the same behavior in your scenario lte-blackice. Therefore, one just needs to move the position of the eNodeBs, e.g. adding 6000 to both x and y. In fact I realized, that moving only one base station is okay, as long tolerateMaxDistanceViolation is set to true. However, having both base stations outside the range of 5000, the segmentation fault appears at the very begin of the simulation. Is communication out of coverage (D2D) not supported or wanted? Why at all is the range hardcoded limited to 5000? If still wished I can of course add a branch with the described modifications.

[riebl]

I can confirm that adding a position offset (of 6000m, for example) to each eNodeB in lte-blackice/omnetpp.ini triggers the following error message: "Error NLOS urban macrocell path loss model is valid for d <5000 m -- in module (LtePhyUeD2D)"

This is not a segmentation fault, but an error emitted deliberately by the SimuLTE model. I cannot say if SimuLTE supports out-of-coverage communication. Maybe @anupama1990 has some idea?

[rtobi]

I tried with the newest setup and can confirm your observations. Sorry for the confusion @riebl! So probably the segfault was solved somewhen in the past. Maybe the following error output may be helpful for others having a similar error, which I think is related to the eNodeB positioning:

Thread 1 "opp_run_dbg" received signal SIGSEGV, Segmentation fault.
0x00007fffec8a7eaa in std::_Rb_tree<unsigned short, std::pair<unsigned short const, Lambda>, std::_Select1st<std::pair<unsigned short const, Lambda> >, std::less<unsigned short>, std::allocator<std::pair<unsigned short const, Lambda> > >::_M_begin (this=0x1d0) at /usr/include/c++/7/bits/stl_tree.h:737
737           { return static_cast<_Link_type>(this->_M_impl._M_header._M_parent); }
(gdb) bt
#0  0x00007fffec8a7eaa in std::_Rb_tree<unsigned short, std::pair<unsigned short const, Lambda>, std::_Select1st<std::pair<unsigned short const, Lambda> >, std::less<unsigned short>, std::allocator<std::pair<unsigned short const, Lambda> > >::_M_begin() (this=0x1d0) at /usr/include/c++/7/bits/stl_tree.h:737
#1  0x00007fffec8a8544 in std::_Rb_tree<unsigned short, std::pair<unsigned short const, Lambda>, std::_Select1st<std::pair<unsigned short const, Lambda> >, std::less<unsigned short>, std::allocator<std::pair<unsigned short const, Lambda> > >::lower_bound(unsigned short const&) (this=0x1d0, __k=@0x7fffffffa7f4: 1027) at /usr/include/c++/7/bits/stl_tree.h:1187
#2  0x00007fffec8a7c4b in std::map<unsigned short, Lambda, std::less<unsigned short>, std::allocator<std::pair<unsigned short const, Lambda> > >::lower_bound(unsigned short const&) (this=0x1d0, __x=@0x7fffffffa7f4: 1027) at /usr/include/c++/7/bits/stl_map.h:1233
#3  0x00007fffec8a7645 in std::map<unsigned short, Lambda, std::less<unsigned short>, std::allocator<std::pair<unsigned short const, Lambda> > >::operator[](unsigned short const&) (this=0x1d0, __k=@0x7fffffffa7f4: 1027) at /usr/include/c++/7/bits/stl_map.h:489
#4  0x00007fffec8a730c in LteCellInfo::lambdaInit(unsigned short, unsigned int) (this=0x0, id=1027, i=1803) at corenetwork/lteCellInfo/LteCellInfo.h:252
#5  0x00007fffeca6feca in LtePhyUe::initialize(int) (this=0x555557d4d0b0, stage=7) at stack/phy/layer/LtePhyUe.cc:165
#6  0x00007fffeca78c96 in LtePhyUeD2D::initialize(int) (this=0x555557d4d0b0, stage=7) at stack/phy/layer/LtePhyUeD2D.cc:29
#7  0x00007ffff69012ac in omnetpp::cModule::initializeModules(int) (this=0x555557d4d0b0, stage=7) at cmodule.cc:1391
#8  0x00007ffff6901310 in omnetpp::cModule::initializeModules(int) (this=0x555558b93850, stage=7) at cmodule.cc:1404
#9  0x00007ffff6901310 in omnetpp::cModule::initializeModules(int) (this=0x55555a1310a0, stage=7) at cmodule.cc:1404
#10 0x00007ffff6900e71 in omnetpp::cModule::callInitialize() (this=0x55555a1310a0) at cmodule.cc:1335

Still, it would be interesting to know from where the 5000 limitation comes from. As it is hardcoded, it seems there is no intention to increase/decrease this value.

[riebl]

I don't know the reasoning behind the 5000m constant, but the SimuLTE developer @giovanninardini can probably give you details. I am not sure if he receives a notification when he is mentioned here, so you may ask directly on the SimuLTE project site.

[anupama1990]

Hi,

Your error arises from LteRealisticChannelModel.cc::computeUrbanMircro() method.

Using the distance value, the path loss is calculated.

Regards,

Anupama

---

From: Raphael Riebl notifications@github.com Sent: Monday, 22 February 2021 14:35:17 To: riebl/artery Cc: Hegde, Anupama; Mention Subject: Re: [riebl/artery] LTE NLOS > 5000 (#160)

I don't know the reasoning behind the 5000m constant, but the SimuLTE developer @giovanninardinihttps://github.com/giovanninardini can probably give you details. I am not sure if he receives a notification when he is mentioned here, so you may ask directly on the SimuLTE project site.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/riebl/artery/issues/160#issuecomment-783377899, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARV7JUFVZ2UJX2YIE5W57YTTAJMRLANCNFSM4X2EIK7A.

[giovanninardini]

Hi everyone,

thanks @riebl for tagging me in this conversation, I don't get notifications for this repository. I confirm that the default channel model within SimuLTE only supports distances smaller than 5000m. This is because the path loss is computed according to the 3GPP standard for LTE, and the standard says that the model is not valid for larger distances (I guess that's because that computation becomes inaccurate for larger distances and you would need another path loss formula).

Best regards. Giovanni

[riebl]

Thanks @giovanninardini for your clarification, much appreciated!

[rtobi]

Thanks for clarification @riebl, @giovanninardini , @anupama1990! @giovanninardini: is lte d2d out of coverage communication currently supported in simulte or do you plan it to support it in the future?

[giovanninardini]

@rtobi SimuLTE only supports network-controlled D2D and we have no plans of adding out-of-coverage D2D in SimuLTE.

To be fair, it is likely that SimuLTE will not be enhanced with new features at all, since we will probably migrate to the upcoming Simu5G. In that case, modeling out-of-coverage D2D would be of interest, but we made no plans about that so far.

[rtobi]

@giovanninardini thanks a lot for this information! Looking forward to Simu5G!