Re: [ns] Underwater Channel in basic NS2

2008-05-08 Thread Nicola Baldo

Hi Dewald,


Dewald Nolte wrote:
  In ns-miracle the documentation claims that the underwater channel
 works and that some basic MACs are provided, but in one of the mails
 in the mailing list I read that some of the routing protocols are not
 yet supported?  

Basically the underwater-miracle module provides only Channel, PHY and
MAC, and relies on nsmiracle for the rest of the protocol stack. The
current release of nsmiracle provides only static routing. The future
release will include support for routing protocols such as AODV.
However, the release date for this version of nsmiracle cannot be
predicted at this moment.


 Also if I go the basic ns way I have to fix the code
 myself. It has some errors at the moment. Doesnt seem too difficult to
 fix though.
 
 1. In the underwater-phy.cc of the unsupported underwater code, lambda
 is defined as:
 lambda_ = SPEED_OF_LIGHT / freq_;
 Considering that its an underwater channel, should it not then be
 the speed of sound??

I guess this value was not used in practice. What I remember of the ns2
underwater module is that is basically used the underwater-phy as an
entry point for some other external code. Most of the code copied from
the ns2 wireless-phy is not actually used. However, you need to read the
code yourself to really understand it. I guess it could be very
difficult to contact the original developers of that module.


  I want to implement my own MAC for the underwater environment. I am
 looking to use the RTS, CTS, DATA, ACK handshake to implement MACAW.
 Some of this is already implemented in the 802.11 MAC. So I will try
 to port that to MACAW. So basically I want to try and use the
 framework supplied by the 802.11 code and just change what is
 necessarry to implement my MAC (MACAW). The problem is I dont have
 enough experience with ns to write my own MAC
  from scratch, so im doing it this way.
 
 2. Now would it be easier to go with ns-miracle, or try to integrate
 the unsupported code for the
 basic ns and use that to keep the routing modules intact?

 3. And lastly, can the 802.11 MAC run on the underwater physical layer
 as it is? Just for
starters, I will try to port it eventually to the MACAW protocol...


What I can tell you (just my opinion of course) is that dealing with the
ns2 underwater module at the PHY and MAC layer is a real mess. This is
the main reason why we wrote the underwater-miracle module almost from
scratch.


Nicola



Re: [ns] access dei80211mr rate adapter rate

2007-12-13 Thread Nicola Baldo

ryan m wrote:
 I have an adhoc network, which I'm using dei80211mr-1.1.1 (with
 activating the included rate adaptation on each node) to simulate
 802.11g with rate adaptation.  Is there a way to determine the current
 rate being used (call RateAdapter::getCurrMode() ) from dsragent.cc?

That's cross-layer information exchange. Unfortunately there is no 
standard way of doing it in ns2. You need to develop an ad-hoc* 
solution, such as extending dsragent and allowing it to have a pointer 
to the rateadapter instance so that it can call its methods.

* here I mean ad-hoc in the sense of designed explicitly for this 
particular case

 
 I'm working with a modified version of DSR known as FRESH that uses a
 table of contact times on each node as a metric.  A node looking for a
 route will broadcast a request to it's neighbors asking when they last
 saw the destination, and each neighbor will respond to the source of
 the broadcast.  My question is, is the rate adapter sophisticated
 enough that each response will be sent at a rate appropriate for the
 communication conditions between the particular responding neighbor
 and the source?  Secondarily is there a way to determine the rate each
 particular response was sent at, from within dsragent.cc?

RateAdapter itself defines only an API and provides some convenience 
methods/variables, however it implements no actual rate adaptation 
scheme. So the answer is: it depends on the actual rate adapter you're 
using.

Each of the classes inheriting from RateAdapter implements a different 
rate adaptation scheme. The two distributed with dei80211mr are ARF and 
SNR. Both will work in ad-hoc mode, however with some caveats:

1) the ARF implementation we provide uses a single set of counters for 
all tx successful / failed events, so the behaviour in ad-hoc mode is 
not reasonable if the same STA sends often packets to different 
destinations, while it is more reasonable if the destination remains the 
same for a number of consecutive transmissions.

2) the SNR implementation records for all nodes the received SRN of the 
last received transmission, and the rate is chosen per-destination using 
that SNR value. So this scheme should work fine in ad-hoc mode, of 
course the SNR information for a given node will be only as recent as 
the last received packet from that node.

If you have particular needs you can of course implement your own rate 
adaptation scheme by inheriting from the RateAdapter class.


Nicola







 
 thank you for your time,
 Ryan
 



Re: [ns] dei80211mr-1.1.1 Tabella non inizializzata 1

2007-12-09 Thread Nicola Baldo


ryan m wrote:
 hello,
 I'm using dei80211mr-1.1.1 and ns-allinone-2.31 and I want to simulate
 a typical 802.11g ad-hoc network, so I set the following parameters to
 that end.
 
 $mac($i) dataMode_ Mode54Mb
 $mac($i) basicMode_ Mode2Mb
 
 With these settings (and several others) I'm getting the error
 Tabella non inizializzata 1 repetatly to cerr, 


Ok I'll translate that error message to something more meaningful for 
english speakers in the next release ;-)

This error occurs when a Packet Error Rate value cannot be found for 
some PHYMode. The common reason for the error is that you did not load 
the correct Packet Error Rate table into an instance of a PER object.

In the adhoc_tcp.tcl script this is done using the following command:

set per [new PER]
$per loadPERTable80211gTrivellato

but that table is for 802.11g modes only. If you try, e.g., to use 
Mode1Mb in the same simluation script, you'll get the error you mentioned.

In dei80211mr we provide also a PER table for 802.11b, which is loaded 
using this command:

$per loadPERTable80211bIntersilHFA3861B

You can also define your own PER table if you wish. Just have a look at 
src/per_table_*.tcl to see how to do it. The last four values for each 
row are: PHYmode packetsize SNR(dB) PacketErrorRate

Regards,

Nicola





Re: [ns] dei80211mr MAC parameters

2007-12-06 Thread Nicola Baldo


Hi Ryan,


ryan m wrote:
 there is a parameter for the mac, $mac($i) dataMode_ $PHYDataRate ,
 and one possibility for PHYDataRate is Mode6Mb.  What are the other
 possibilities, in particular I'd like to know the option for 802.11g
 multirate, and if possible 11MB unirate.

The rates supported are listed in src/phymodes.h

 
 the other question is about the parameter $mac($i) basicMode_ Mode6Mb,
 is this the basic rate for the multirate beacons and broadcast
 packets?  

In the current version it is used for all control frames, i.e., RTS, CTS 
and ACK, as well as for all broadcast packets.

 Are the possibilities for this parameter the same as for the
 other parameter?  

Yes


 If my interpretation of the parameter is correct;
 2MB is the correct basic rate for 802.11g right?, what is the correct
 value for setting it to that?

I suggest checking the 802.11 standard for this matter.

Regards,

Nicola



[ns] dynamic libraries on cygwin

2007-10-09 Thread Nicola Baldo

Hi all,

I am glad to announce that support for dynamic libraries in ns is
finally available also on cygwin. Here are the relevant links:

The new patch by Federico Maguolo:
http://www.dei.unipd.it/~maguolof/new-patch-dl-ns-2.31

The installation procedure for cygwin:
http://www.dei.unipd.it/~baldo/ns_dl_patch/Installation.html

Updated information for developers:
http://www.dei.unipd.it/~baldo/ns_dl_patch/Developer_s_manual.html

Finally, some dynamic libraries which we updated to make them work on 
Cygwin:

TCP Veno and Eurane UMTS
http://www.dei.unipd.it/~baldo/ns_dl_patch/Sample_dynamic_ns_modules.html

dei80211mr version 1.1.1
http://www.dei.unipd.it/ricerca/signet/tools/dei80211mr


Feedback welcome!


Regards,

Nicola



Re: [ns] 802.11g in ns 2.28

2007-07-26 Thread Nicola Baldo

Will Spearman wrote:
 I would like to implement 802.11g in ns-2.28 

As announced some time ago, an 802.11g implementation for ns2 can be
found here:

http://www.dei.unipd.it/~rossi/dei80211mr.html

Regards,

Nicola



Re: [ns] Compute busy/idel period of mobile node in ad hoc network

2007-06-26 Thread Nicola Baldo


The dei80211mr 802.11 implementation just announced
http://mailman.isi.edu/pipermail/ns-users/2007-June/060526.html
provides a new idleSlot variable which counts the number of idle
timeslots which are observed by the MAC. This variable can be used for
your computations.

Nicola


Ana Turk wrote:
 
 Dear All,
 
  In order to estimate a bandwidth I need to compute a busy or idle 
 
 time of node in period of time. Please how can I do this? 
 
 I use ns-allinone-2.30 under fedora core 6.  
 Thanks in advance. 
 
   
 -
  Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! 
 Profitez des connaissances, des opinions et des expériences des internautes 
 sur Yahoo! Questions/Réponses.



[ns] dynamic libraries in ns2: how to develop ns extensions withouth recompiling ns

2007-06-20 Thread Nicola Baldo


Hi all,

at the SIGNET lab, Dept. of Information Engineering, University of
Padova, Italy, we've developed a patch for ns2 which enables effective
use of dynamic libraries in ns2. We believe that the introduction of
this feature substantially improves the current way of developing
extensions to ns2. A list of the offered advantages is reported below:

* People can develop add-ons for ns2 (e.g. introducing new agents,
packet types, protocols) without having to modify the core simulator.

* New packet headers and types, as well as packet tracers, could be
defined to assist debugging, collection of statistics and inter-module
communication. These can also be loaded on demand according to user's needs.

* Dynamic libraries can be loaded at simulation time, with no need to
recompile the whole ns2 distribution or to keep different ns2 binaries.

* The installation of third-party ns2 extensions is made easier, thereby
facilitating their dissemination.

* Dynamic libraries will make life easier for lab technicians and
students. In fact, an official ns2 version can be installed by
administrators, and students can just build and use their preferred
extensions independently.

* ns2 will become more modular and scalable, while at the same time
preserving backwad compatibility.


We observe that dynamic libraries are natively supported in ns2 (see Tcl
load functionality). However, the set of functionalities which can be
accounted for by means of this approach is severely limited by the
intrinsic structure of the simulator. As an example, new packet types
and headers cannot be added to the code. In order to remove these
limitations, the patch we developed enables dynamic definition of packet
types, headers and their corresponding tracers.

Special care has been taken to ensure backward compatibility: the patch
has been designed in order not to interfere with the existing
functionalities in ns2. We have been testing this patch on different
linux systems since summer 2006, and so far we did not encounter any issue.

The patch is available at this location:
http://www.dei.unipd.it/~rossi/ns2-patch.html

Also, a detailed documentation of the modifications introduced by the
patch, as well as a tutorial for building ns extensions as dynamic
libraries, can be found at this location:
http://www.dei.unipd.it/~baldo/ns_dl_patch

Finally, we also provide a few sample modules to allow a straightforward
evaluation of the benefits provided by our patch. In particular, we
provide dynamic library versions of the UMTS implementation by the
EURANE project and of the TCP Veno implementation by NTU. The relative
packages can be found at this location:
http://www.dei.unipd.it/~baldo/ns_dl_patch/Sample_dynamic_ns_modules.html


Of course, any feedback on our proposal is welcome!


Regards,

Nicola







Re: [ns] want information about assert() function

2006-07-10 Thread Nicola Baldo


Hai Nam wrote:
 assert() is usually used for debugging purpose. I think we can turn
 off this function in a released version but I don't know how :-(

 From the man page of assert():

If  the macro NDEBUG was defined at the moment assert.h was last
included, the macro assert() generates no code, and
hence does nothing at all

Regards,

Nicola