[Ns-developers] 802.11 mobility/transmission bug
laurent.paquereau at q2s.ntnu.no
Wed Mar 14 03:40:29 PDT 2007
What you describe is not related to 802.11 but to WirelessChannel. Now
concerning the bug, I do not think there is any but rather that it is
about setting parameters correctly.
In WirelessChannel, X_LIST_POSITION_UPDATE_INTERVAL decides how often
the position of node far away from any communication area is updated
(“far away” depends on distCST_ which itself depends on the propagation
model used). It affects what I refer to in the following as the
Because the position of a node may not be up to date, a node at a
distance d in (range, range + 5 × X_LIST_POSITION_UPDATE_INTERVAL),
where 5 is the default maximal speed (MAX_SPEED), may actually be at a
distance d'<=range. The uncertainty range UR = range+
MAX_SPEED × X_LIST_POSITION_UPDATE_INTERVAL is the the minimal distance
such that d > UR implies d' > range. This corresponds to the “safety”
used in WirelessChannel::sendUp(). The larger
X_LIST_POSITION_UPDATE_INTERVAL the larger the uncertainty range.
Any node within the uncertainty range of a transmitting node must
receive a copy of the packet transmitted to ensure that any node
that actually detects the transmission (i.e. actually within carrier
sensing range i.e., as it is implemented, within a circle
of radius distCST_) receives a copy. The position of such a node is
updated at the time of transmission regardless the update interval (when
calculating the propagation delay). On the other hand, the position of a
node beyond the uncertainty range of any transmitting node is only
updated every X_LIST_POSITION_UPDATE_INTERVAL.
There is a trade-off between the number of unnecessary packet copies and
the processing time due to position updates.
XLIST_POSITION_UPDATE_INTERVAL or/and “safety” should be adjusted (in
C++) depending on the degree of mobility with
XLIST_POSITION_UPDATE_INTERVAL × maximal speed used <= safety.
Now in the code neither “safety” depends on MAX_SPEED or on
XLIST_POSITION_UPDATE_INTERVAL nor the condition speed <= MAX_SPEED is
enforced. Therefore if you use speeds larger than 5m/s and do not modify
XLIST_POSITION_UPDATE_INTERVAL or/and “safety” you may observe
differences compared to the case where you update the position of every
node at each packet transmission (“new stuff” in
should not be any problem when a node enters a communication area if the
speeds are less than 5m/s.
The solution proposed in “new stuff” consists in updating the position
of every node at each packet transmission. This may be quite inefficient
and at least in this case “safety” should be set to 0.
Note that updating the position of every node at each packet
transmission is what happens when distCST_=DBL_MAX and in this case it
is relevant to disable list sorting since every packet is copied and
sent to every node anyway; this is not done in ns2 now. Another point is
about position information written in trace files. The position of a
node may be updated at the channel level only. Therefore the position
information written in a trace may be inaccurate. Finally you might find
interesting reading http://www.q2s.ntnu.no/~paquerea/ns/mwnode-doc.pdf,
sections 3.1.2 and 3.2.2.
Michele Weigle wrote:
> I don't know who all this gets sent to, but I just added a tracker entry
> for a 802.11 bug that I came across on the ns-users list.
> Begin forwarded message:
>> From: "SourceForge.net" <noreply at sourceforge.net>
>> Date: March 13, 2007 10:46:26 AM EDT
>> To: noreply at sourceforge.net
>> Subject: [ nsnam-Bugs-1679890 ] 802.11 mobility/transmission bug
>> Bugs item #1679890, was opened at 2007-03-13 10:46
>> Message generated for change (Tracker Item Submitted) made by Item
>> You can respond by visiting:
>> Please note that this message will contain a full copy of the comment
>> including the initial issue submission, for this request,
>> not just the latest update.
>> Category: ns-2
>> Group: None
>> Status: Open
>> Resolution: None
>> Priority: 5
>> Private: No
>> Submitted By: Michele Weigle (mweigle)
>> Assigned to: Nobody/Anonymous (nobody)
>> Summary: 802.11 mobility/transmission bug
>> Initial Comment:
>> I happened upon this email to the ns-users list from a while back
>> describing a problem with 802.11.
>> "In 2.27 (not 2.26), the nodes are sorted according to their
>> coordinates so that when an event happens at a particular node, that
>> node updates its current coordinates and re-positions itself in the list.
>> When a node sends something, the wireless channel looks at the sorted
>> list and only sends the packets to nodes within the
>> transmission/interference range.
>> The problem is that the node's position is not updated unless there is
>> an event happening at that node. Thus, if you have an isolated node
>> (A) moving into range with other nodes, unless that node (A) sends
>> some traffic, it won't receive any traffic from other nodes in its new
>> I recently checked and the code mentioned in the email is still the
>> same in ns-2.30.
>> You can respond by visiting:
More information about the Ns-developers