Bug 2862 - Aggregate Node object in REM test points
Aggregate Node object in REM test points
Status: RESOLVED WONTFIX
Product: ns-3
Classification: Unclassified
Component: lte
ns-3-dev
All All
: P3 normal
Assigned To: Biljana Bojović
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-01-29 16:51 UTC by Zoraze Ali
Modified: 2019-06-13 10:13 UTC (History)
3 users (show)

See Also:


Attachments
patch (882 bytes, patch)
2018-01-29 16:53 UTC, Zoraze Ali
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Zoraze Ali 2018-01-29 16:51:51 UTC
REM tests points generated in RadioEnvironmentMapHelper::DelayedInstall () have mobility model aggregated with them but don't have a Node object. This could lead to a segmentation fault if a user needs to retrieve a Node object while generating REM. An example use case is when a user want to print a node id in GetLoss function of any pathloss model and also generates a REM, e.g.,  

Ptr<Node> nodeB = mobilityModel->GetObject<Node> ();
NS_LOG_DEBUG ("node B id :" << nodeB->GetId ());

We can overcome this problem by adding following code in RadioEnvironmentMapHelper::DelayedInstall () function: 

Ptr<Node> node = CreateObject<Node> ();
p.bmm->AggregateObject (node); // operation usually done by MobilityHelper::Install

Side effect: we will have very high number of nodes, which would depend on the REM resolution. 

Kind regards,
Zoraze
Comment 1 Zoraze Ali 2018-01-29 16:53:55 UTC
Created attachment 3021 [details]
patch

If my suggestion seems reasonable we can use the attached patch. 

Kind regards,
Zoraze
Comment 2 Tom Henderson 2018-02-01 20:59:09 UTC
I am not crazy about adding dummy nodes.  What is the implication of leaving it as is (outside of the psc issue that triggered this question)?
Comment 3 Zoraze Ali 2018-02-02 04:59:08 UTC
I am also not in favour of adding nodes. The patch can solve the problem but it is definitely not efficient. As per my experience, this is the first time I notice this so, I assume there would be no implication leaving it as it is. We can close this bug report and reòpen it if needed in future.
Comment 4 Biljana Bojović 2019-06-13 10:03:31 UTC
Since 1) this is not an issue related to the original functionality of RemHelper but is related to some specific cases when additional functionality is needed; and 2) taking into account that the proposed way of adding this additional feature is not convincing to be added to ns-3-dev as enhancement, I think that we can close this issue.