Bug 2862

Summary: Aggregate Node object in REM test points
Product: ns-3 Reporter: Zoraze Ali <zorazeali>
Component: lteAssignee: Biljana Bojović <bbojovic>
Status: RESOLVED WONTFIX    
Severity: normal CC: ns-bugs, tomh, zorazeali
Priority: P3    
Version: ns-3-dev   
Hardware: All   
OS: All   
Attachments: patch

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.