[Ns-developers] 802.11 mobility/transmission bug

[Laurent Paquereau]

Michele,

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 
uncertainty range.

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 
http://mailman.isi.edu/pipermail/ns-users/2004-April/041344.html). There 
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.

-Laurent

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.
> 
> -Michele
> 
> 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 
>> Submitter
>> You can respond by visiting:
>> https://sourceforge.net/tracker/?func=detail&atid=775392&aid=1679890&group_id=149743 
>>
>>
>> Please note that this message will contain a full copy of the comment 
>> thread,
>> 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.
>>
>> http://mailman.isi.edu/pipermail/ns-users/2004-April/041344.html
>>
>> "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
>> neighborhood."
>>
>> I recently checked and the code mentioned in the email is still the 
>> same in ns-2.30.
>>
>>
>> ----------------------------------------------------------------------
>>
>> You can respond by visiting:
>> https://sourceforge.net/tracker/?func=detail&atid=775392&aid=1679890&group_id=149743 
>>