Bug 2662 – Add ability to set the mobility bounding rectangle after mobility model has been installed

Bug 2662 - Add ability to set the mobility bounding rectangle after mobility model has been installed


Summary:	Add ability to set the mobility bounding rectangle after mobility model has b...

Status:	NEEDINFO

Product:	ns-3
Classification:	Unclassified
Component:	mobility models
Version:	ns-3-dev
Hardware:	All All

Importance:	P3 enhancement
Assigned To:	ns-bugs

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2017-02-26 09:50 EST by Robert Ammon
Modified:	2018-06-07 12:57 EDT (History)
CC List:	1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Robert Ammon 2017-02-26 09:50:36 EST

In the current implementation of the mobility models, it is not possible to change the bounding rectangle once the mobility model has been installed to the node.

For example, its not possible to install the mobility model so the position allocator function determines the initial positions and then update the bounding rectangle for the nodes to be based upon the initial positions.

This change adds a SetBounds function that can be called to update the bounding rectangle after the mobility model has been installed to the node.

Changes have been uploaded to http://codereview.appspot.com/314580043

Comment 1 Tom Henderson 2017-09-12 20:55:50 EDT

I see another possible alternative, which is to change the direct variable access in the attribute to an accessor method:

    .AddAttribute ("Bounds", "The 2d bounding area",
                   RectangleValue (Rectangle (-100, 100, -100, 100)),
                   MakeRectangleAccessor (&RandomDirection2dMobilityModel::m_bounds),
                   MakeRectangleChecker ())

which performs the m_helper.UpdateWithBounds (m_bounds).

Would that be acceptable?  I think the main issue you have is that while Bounds is changeable, you can't trigger the call to UpdateWithBounds().  If we use the attribute technique, we can avoid the new setter in the API.

Also, what happens in each of these models if the bounds are updated such that the current positions now fall outside of the new bounds-- will the models be able to correctly handle such occurrences?