[Ns-developers] ns3: Node position

[Gustavo Carneiro]

On 3/12/07, mathieu lacage <Mathieu.Lacage at sophia.inria.fr> wrote:
>
> On Mon, 2007-03-12 at 15:40 +0000, Gustavo Carneiro wrote:
> >   I notice that the Node class in ns-3-dev doesn't have position
> coordinates
> > yet, unless I missed something.  I need this for a personal project
> right
> > about now, so I'll make something up in my personal branch and later
> propose
> > it for ns-3 if you want.  Unless of course there is already some
> proposal on
> > the table for that, in which  case I would appreciate getting a glimpse
> of
> > such proposal, and that is why this email.
> >
> >   Some thoughts of what I need:
> >
> >     1. A couple of double x, y (optionally z) coordinates;
>
> z is not optional, please.


  I didn't mean to make optional, I meant it in the sense that I don't mind
either having z or not having z.

>     2. A SetPosition (double x, double y) method in the Node;
> >     3. A virtual PositionNotify (double oldX, double oldY, double newX,
> > double newY) method in NetDevice;
> >     4. Node::SetPosition would call PositionNotify on each NetDevice of
> the
> > Node.
> >
> >   About 1, we can assume all nodes have a position, right?  If so,
> there's
> > no point in creating a separate class to hold the position IMHO (maybe
> just
> > a simple structure is OK though).
>
> No. I think that we would like to make this a conditional property of a
> node. i.e., the idea we discussed previously was to add a GetLocation ()
> virtual method to the Node base class.


  OK, that's fine.

>   About 4, yes, NetDevices need to be notified of position changes, at
> least
> > for my case.  I need to maintain one list of NetDevices sorted by X
> > coordinate, and another sorted by Y coordinate.  This list would then be
> > used to efficiently determine a list of nodes that are in wireless range
> of
> > any given transmitting node.
>
> I am afraid that this is going to be hard since there are conflicting
> requirements here. Here are the other use-cases I think we need to
> support:
>
>   i) provide a way for a user to specify a given position for a node and
> change it at any later point in the future
>   ii) provide a way for a user to specify a given position and constant
> vector speed for a node and change it at any later point in the future
>   iii) provide a way for a user to specify a potentially complex
> movement calculation algorithm
>   iv) provide a way for a user to specify a set of positions and speeds
> in a text file.
>
> I think that iv) is a natural extension of i) and ii) so, I won't bother
> with it.
>
> However, the crux of the issue here is that if you specify a location
> calculation model based on ii), there is no way to implement a generic
> notification mechanism because ii) is based on the idea that you do not
> _notify_ a user when the position changes: the user asks for the current
> position which is calculated whenever it is requested.


  In my case I want to do simulations with thousands of nodes and I can't
afford to calculate the position of all nodes in existence every time a
packet is transmitted.  In the model I have in mind, nodes instantaneously
jump from one position to the next at predefined instants, at which point a
couple of sorted lists get re-sorted.  All this may not be 100% realistic
but I have to do it anyway for the sake of scalability.

  So my idea is to notify callbacks only when the position is manually set,
but not when it is calculated at an arbitrary point in time.  In order to
not induce programmers into assumptions that are not true, maybe
PositionNotify is not a good name; perhaps NotifySetPosition is a better
name.

The question then is: how can we ensure that we support both ? I do not
> know but this is certainly a question we need to answer before pushing
> code into the main repository. Maybe we could tie the notification
> mechanism to a max-change-in-distance property. What the API should look
> like is not very clear to me though.


Another thing: If your NetDevice subclass wants being notified, I think
> that it would make much more sense to make it register a callback with
> the position tracking code rather than make all NetDevice be notified by
> default.


  That would be fine _if_ ns-3 made that easy.  Right now, ns-3 doesn't even
have the notion of signal emission, with great regret on my part :|

  It would be rather easy to support signals IMHO.  We could define a Signal
class which could be just an object holding a list of callbacks, and an Emit
() method to call them.

-- 
Gustavo J. A. M. Carneiro
"The universe is always one step beyond logic."