Re: [ns] adding multi-channel supporting based on aodv
Gello,
cmn is the common header of the packet, if it is not declared in the
method, you need to do this.
Cheers,
Ramón
At 03:58 28/05/2007, [EMAIL PROTECTED] wrote:
hi all,
I am working on Adding Multiple Interface Support in NS-2 available on
ttp://personales.unican.es/aguerocr/ based on AODV .My question is that
sending a unicast packet.which interface should send to ?
listing 5.4
if(nIfaces)
{ Scheduler::instance().scheduler(,targetlist[nIface],pkt,0,) }
else
{ Scheduler::instance().scheduler(,targetlist,pkt,0 }
listing 5.5
if(nIfaces)
{
Iface=cmn-iface()-((Mac *)ifqueuelist[0]-target())-addr();
}
else
{
Iface=-1;
}
I set nIface as a member of AODV::sendReply(),and add listing 5.4 ,5.5 in
AODV::sendReply,but when I make ns,
It gives me error information: cmn is not defined! why?
any help will be appreciation!
ÈËɽÈ˺£Ê¢¾°£¬¾¡ÔÚÃλÃÎ÷ÓÎ
Re: [ns] Multiple Interfaces in AODV [based on Ramon]
Hello Devu,
I think that the change is ok. The reason is that you should be able to
still use the previous scripts, and that's why we keep the original code;
note that in that sense you are using another command, because the number
of parameters is different (from the if-queue originally used by AODV and
the one which you need to use).
It would be possible also to add this code within the aodvonly condition,
but then the extension could be only applied to this routing protocol.
Anyhow, do you have any compile or execution error with this?
Cheers,
Ramón
At 23:50 25/05/2007, Devu ManikantanShila wrote:
-- Forwarded message --
From: Devu ManikantanShila [EMAIL PROTECTED]
Date: May 25, 2007 4:46 PM
Subject: Multiple Interfaces in AODV [based on Ramon]
To: ns-users@isi.edu
Hello,
I am simulating multiple interfaces according to Ramon's tutorial in AODV.
I have highlighted the problem in the document!!
# Special processing for AODV
MY DOUBT HERE. Should I change the $agent if-queue [$self set ifq_(0)] so as
to simulate multiple interfaces in AODV
set aodvonly [string first AODV [$agent info class]]
if {$aodvonly != -1 } {
$agent if-queue [$self set ifq_(0)] ;# ifq between LL and MAC
}
THEY HAVE CHANGED ONLY HERE!!!
if { $port == [Node set rtagent_port_] } {
*# Special Processing when multiple interfaces are suported*
*if {$numIfsSimulator != } {*
*for {set i 0} {$i [$self set nifs_]} {incr i} {*
*$agent if-queue $i [$self set ifq_($i)]*
*}*
*} *
# Ad hoc routing agent setup needs special handling
$self add-target-rtagent $agent $port
return
}
PLEASE HELP ME!!!
Thanks
Devu
Re: [ns] Multi-interface support howto
Hello Laurent, Nguyen, all, Thanks for the discussion. In my opinion, it's sort of difficult to compare both approaches. It seems that the work that Laurent has done is quite much more comprehensive and detailed, since it uses a different approach from what the current ns-2 architecture uses for wireless networks. I've read the document (more comments/feedback to come), but I do really find it an interesting piece of work. I'll upgrade our howto to cite it, and sorry for not having done it before. We were not aware of it; in fact in this new version I'll also cite the Miracle work; these two, which also address the multi-channel problematic, use different approaches than we do, and that's one of the reasons for not citing them. Now let me try to provide some inline comments about what Laurent said about our howto. I know that its scope is probably not too broad, but what we tried (as we had already said) is to make something to help people. I know that there were some other sources of information (and thus all of them are cited/referenced in our howto), but we still believed (due to the number of questions on the mailing list and our personal experience with such information), that there was something else that could be done. At 14:00 16/02/2007, Laurent Paquereau wrote: 1) R.Aguero et al., Adding Multiple Interface Support in NS-2 (document, http://personales.unican.es/aguerocr) This document describes changes to enable support of multiple interfaces. By to support multiple interfaces they mean to allow to have more than one wireless stack below a single routing agent on a MobileNode. All the wireless stacks are identical (same Mac/Phy). This is true, although my understanding is that this is due to the fact that there are not really many other choices, I'm pretty sure that this could be changed quite quickly. However, I fail to see a use case for this. In ad hoc routing environments (which were the main thing we had in mind), the typical case is to have different interfaces IEEE 802.11a/b/g, even bluetooth, under the same routing protocol, I think that this is achievable. In fact, something we can already do is to tweak the parameters of any of the PHY/MAC layers, so that we can mimic 802.11b and 802.11g working together (changing the energy, the transmission range, etc). On the other hand, if, e.g. you are using a WSN (with some dual 802.15.4/802.11 nodes), having more than one routing protocol would make sense to me. The routing agent code has to be modified to handle more than one wireless stack. This applies only to AODV-like routing agents, that is routing agents using the standard MobileNode, not the SRNode (DSR) or the AODVUUNode (AODV-UU) for example. Well, the main reason behind this was that most of the people developing new routing protocols for ns-2 are doing it using the MobileNode. There is more documentation, and I really believed (having personally worked with the SRNode one) that it's much simpler. This functionality is basically what is provided by Hyacinth (http://www.ecsl.cs.sunysb.edu/multichannel/), some flexibility added. To this respect their contribution is to me very similar to the resources available at http://www.cse.msu.edu/~wangbo1/ns2/nshowto8.html I can't completely agree with you here. As it is stated in the howto, we have undertaken different changes: - In the Hyacinth work, (and the corresponding updates), all nodes need to have the same number of interfaces, which is fixed. We provide a way to make this as flexible as the user wants, and in fact, we also maintain the original behavior of the simulator, so that people can still use their original scripts. - This flexibility allows, not only modifying the number of channels (either at the scenario or at the node level), but to establish to which channels the node needs to connect to. - One of the most important aspects is that the existing information didn't tackle how to modify existing routing routing protocols, and we also tackle this in the howto. Best regards, Ramón
Re: [ns] Multi-interface support howto, Ramon Submission
Hello,
Ok, I'm glad that you solved the problems related to the extension. I don't
really know how to address these warnings or whether they are relevant (at
least the virtual destructor one should not).
Cheers,
Ramón
At 13:25 13/02/2007, Nguyen Lan wrote:
Hello Ramon et al,
My problem is that I declared nIfaces, targetlist and ifqueuelist in the
aodv.h file but out of the class declaration. Now I can recompile ns but I
still had many many warnings like that
/usr/local/ns/mulf/ns-allinone-2.27/tclcl-1.15/tracedvar.h:49: warning:
class TracedVar has virtual functions but non-virtual destructor
/usr/local/ns/mulf/ns-allinone-2.27/tclcl-1.15/tracedvar.h:87: warning:
class TracedInt has virtual functions but non-virtual destructor
/usr/local/ns/mulf/ns-allinone-2.27/tclcl-1.15/tracedvar.h:130: warning:
class TracedDouble has virtual functions but non-virtual destructor
common/scheduler.h:71: warning: class Handler has virtual functions but
non-virtual destructor
common/ip.cc: In member function virtual void
IPHeaderClass::export_offsets():
common/ip.cc:53: warning: invalid access to non-static data member
hdr_ip::src_ of NULL object
common/ip.cc:53: warning: (perhaps the offsetof macro was used incorrectly)
common/ip.cc:54: warning: invalid access to non-static data member
hdr_ip::dst_ of NULL object
common/ip.cc:54: warning: (perhaps the offsetof macro was used incorrectly)
common/ip.cc:55: warning: invalid access to non-static data member
hdr_ip::ttl_ of NULL object
common/ip.cc:55: warning: (perhaps the offsetof macro was used incorrectly)
common/ip.cc:56: warning: invalid access to non-static data member
hdr_ip::fid_ of NULL object
common/ip.cc:56: warning: (perhaps the offsetof macro was used incorrectly)
common/ip.cc:57: warning: invalid access to non-static data member
hdr_ip::prio_ of NULL object
common/ip.cc:57: warning: (perhaps the offsetof macro was used incorrectly)
Any idea about this is welcome.
Cheers,
Nguyen.
Nguyen Lan wrote:
Hello,
I have not declared them in common/packet.h. The only place I put them in
is aodv.h (as in the document). I think this problem came from other
place and I should read the document carefully but now I don't know yet.
Thank you very much.
Cheers,
Nguyen
Ramon Aguero wrote:
Hello,
Why have you declared nIfaces, targetlist and ifqueuelist in
common/packet.h?
Cheers,
Ramón
At 07:34 06/02/2007, Nguyen Lan wrote:
Hi Ramon and all,
After following the document when I recompile ns I got this error.
Maybe I was wrong some where
aodv/aodv.o:/usr/local/ns/mulf/ns-allinone-2.27/tclcl-1.15/tclcl.h:60:
multiple definition of `nIfaces'
aodv/aodv_logs.o:./common/packet.h:413: first defined here
aodv/aodv.o:./aodv/aodv_packet.h:161: multiple definition of `targetlist'
aodv/aodv_logs.o:./common/packet.h:353: first defined here
aodv/aodv.o:aodv/aodv.cc:65: multiple definition of `ifqueuelist'
aodv/aodv_logs.o:./common/packet.h:423: first defined here
collect2: ld returned 1 exit status
make: *** [ns] Error 1
Could anyone help me.
Thanks
Ramon Aguero wrote:
Hi Anthony,
thanks for your feedback; I think that your proposal is perfectly fine.
I've sent an email previously, about the same changes. I think that
the problem was that in the first version of the document we did not
highlight a couple of lines (the ones that you've modified); in the
original ns-mobilenode.tcl file, these two lines started with
$arptable_ **Note the underscore**
In the modified procedure, however, it was $arptable **Without the
underscore**, which is, exactly what you propose, since the $arptable
variable is $arptable_($t).
Cheers,
Ramón
At 07:29 04/02/2007, Anthony Plummer wrote:
Ramon's submission (http://personales.unican.es/aguerocr/) of a
multiple-channel extension to ns2 works well after a slight
modification to the code in the pdf. In tcl/lib/ns-mobilenode.tcl the
arptable modification (pg. 24 25 of pdf) needs to change the
arptable in two additional lines.
#We also create one ARP table per interface
set arptable_($t) [new ARPTable $self $mac]
set arptable $arptable_($t)
# FOR backward compatibility sake, hack only
if {$imepflag != } {
set drpT [$self mobility-trace Drop IFQ]
} else {
set drpT [cmu-trace Drop IFQ $self]
}
$arptable_($t) drop-target $drpT // Should be changed to this here
if { $namfp != } {
$drpT namattach $namfp
}
#
# Link Layer
#
$ll arptable $arptable_($t) // Should be changed to this here
$ll mac $mac
$ll down-target $ifq
Re: [ns] Multi-interface support howto, Ramon Submission
Hello,
Why have you declared nIfaces, targetlist and ifqueuelist in common/packet.h?
Cheers,
Ramón
At 07:34 06/02/2007, Nguyen Lan wrote:
Hi Ramon and all,
After following the document when I recompile ns I got this error. Maybe I
was wrong some where
aodv/aodv.o:/usr/local/ns/mulf/ns-allinone-2.27/tclcl-1.15/tclcl.h:60:
multiple definition of `nIfaces'
aodv/aodv_logs.o:./common/packet.h:413: first defined here
aodv/aodv.o:./aodv/aodv_packet.h:161: multiple definition of `targetlist'
aodv/aodv_logs.o:./common/packet.h:353: first defined here
aodv/aodv.o:aodv/aodv.cc:65: multiple definition of `ifqueuelist'
aodv/aodv_logs.o:./common/packet.h:423: first defined here
collect2: ld returned 1 exit status
make: *** [ns] Error 1
Could anyone help me.
Thanks
Ramon Aguero wrote:
Hi Anthony,
thanks for your feedback; I think that your proposal is perfectly fine.
I've sent an email previously, about the same changes. I think that the
problem was that in the first version of the document we did not
highlight a couple of lines (the ones that you've modified); in the
original ns-mobilenode.tcl file, these two lines started with $arptable_
**Note the underscore**
In the modified procedure, however, it was $arptable **Without the
underscore**, which is, exactly what you propose, since the $arptable
variable is $arptable_($t).
Cheers,
Ramón
At 07:29 04/02/2007, Anthony Plummer wrote:
Ramon's submission (http://personales.unican.es/aguerocr/) of a
multiple-channel extension to ns2 works well after a slight
modification to the code in the pdf. In tcl/lib/ns-mobilenode.tcl the
arptable modification (pg. 24 25 of pdf) needs to change the
arptable in two additional lines.
#We also create one ARP table per interface
set arptable_($t) [new ARPTable $self $mac]
set arptable $arptable_($t)
# FOR backward compatibility sake, hack only
if {$imepflag != } {
set drpT [$self mobility-trace Drop IFQ]
} else {
set drpT [cmu-trace Drop IFQ $self]
}
$arptable_($t) drop-target $drpT // Should be changed to this here
if { $namfp != } {
$drpT namattach $namfp
}
#
# Link Layer
#
$ll arptable $arptable_($t) // Should be changed to this here
$ll mac $mac
$ll down-target $ifq
Re: [ns] Multi-interface support howto
Hello Tim,
I've not personally used the NoAH extension myself, so I cannot completely
figure out which would be your problem.
Nevertheless, why do you use the prev_hop? I don't see the difference here
between NoAH and any other routing protocol. If you have received a message
from a base station via an interface, you might want to use that interface
to contact to the base station in the future. In this sense, I think that
you may want to get the interface index in the same way as it is explained
in the document (see Listing 4.6), and use that in the map.
Hope that this can help you.
Ramón
At 14:15 06/02/2007, Tim Elschner wrote:
hi,
i'm still stuck on transfering data via different channels using NOAH (NO
AdHoc Routing). maybe you can figure out if there is something wrong with
my approach.
i use only one mobile node, and some basestations with foreign agents, an
home agent and a corresponding node.
as noah doesn't need a routing table, i use a map for storing the
interface. i use the prev_hop field in the common-header to associate
the interface.
in the forwardPacket function of NOAH - which is for unicast
transmissions - i use the information stored in the map to send the
packets through the correct interface. this works fine with interface 1,
but fails for interface 0. all packets are dropped. if i just flip the
channels between interface 0 and 1, still interface 1 is working and
interface 0 fails.
did i miss something?
thanks,
tim
Ramon Aguero schrieb:
Hello Tim,
thanks for pinpointing the error! Somehow I made a mistake when copying
and pasting the code to the file.
The correct procedure would be the following one (note that the arptable_
is now within the 'for' cycle). In this sense, I don't think you need to
change all arptable_ into arptable. Hope this helps.
Node/MobileNode instproc reset {} {
$self instvar arptable_ nifs_ netif_ mac_ ifq_ ll_ imep_
for {set i 0} {$i $nifs_} {incr i} {
$netif_($i) reset
$mac_($i) reset
$ll_($i) reset
$ifq_($i) reset
if { [info exists opt(imep)] $opt(imep) == ON } {
$imep_($i) reset
}
if { $arptable_($i) != } {
$arptable_($i) reset
}
}
}
Cheers,
Ramón
PS - I've already modified the document -- with the correct procedure --
in the web page:
http://personales.unican.es/aguerocr
At 16:39 18/01/2007, Tim Elschner wrote:
great job as far as i can see.
anyway i ran into problems with ns-mobilenode.tcl:
in Node/MobileNode instproc reset i couldn't find any differences to
the original.
i got an error, that arptable_ is an array. so i changed every arptable_
into arptable. now ns2 complains about the missing variable arptable :(
any hints out there?
cheers,
tim
Ramon Aguero schrieb:
Dear all,
We have seen a lot of requests about the possibility to extend the NS-2
framework to support multiple interfaces. Although there is some
information available, according to the messages that have been sent to
this list, it seems that a more thorough description may be required.
In this sense, after performing an analysis about existing activities
in this topic, we have created a document that tries to summarize which
are the required changes to be performed within the different pieces of
the simulator (tcl, c++) as well as how routing protocols can be
adapted to make use of the new feature. The howto is entitled Adding
Multiple Interface Support in NS-2 and it has been written by my
colleague Jesús Pérez and myself.
Ive uploaded the document, which can be retrieved from the following url:
http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr
We will be happy to receive any feedback, comments, so as to improve
the howto, since we would like to have it like a living document,
adding new features as they are available.
Best regards,
Ramón
Ramón Agüero Calvo
Dept. of Communications Engineering
Network Planning Mobile Communications
Laboratory
University of Cantabria
Avda Castros s/n
39005 - Santander
SPAIN
[EMAIL PROTECTED]
Tel: +34 942 201 392 (Ext 14)
Fax: +34 942 201 488
Re: [ns] Multi-interface support howto
Hi Tim,
I should have read this message before, sorry for the spam.
Can you clarify where did you add these two lines?
Cheers,
Ramón
At 10:49 09/02/2007, Tim Elschner wrote:
i got the wirless tracing back to business:
replaced:
set sndT [cmu-trace Send RTR $self] (see below)
with:
set sndT [$self mobility-trace Send RTR]
$sndT namattach $namfp
Tim Elschner schrieb:
i found out that a missing line in ns-mobilenode.tcl caused that strange
behaviour.
since i correctly added
set sndT [cmu-trace Send RTR $self]
the traffic seems to be fine, except that the wireless packets don't
appear in NAM anymore.
-tim
Tim Elschner schrieb:
hi,
i'm trying to user mutliple interfaces with the adhoc routing agent
noah - which stands for NO AdHoc routing. i use only one mobile
node, and some basestations with foreign agents, an home agent and a
corresponding node.
as noah doesn't need a routing table, i use a map for storing the
interface. i use the prev_hop field in the common-header to associate
the interface.
in the forwardPacket function - which is for unicast transmissions - i
use the information stored in the map to send the packets through the
correct interface. this works fine with interface 1, but fails vor
interface 0. all packets are dropped. if i just flip the channels
between interface 0 and 1, still interface 1 is working and interface 0
fails.
did i miss something?
hints anyone? :)
cheers,
tim
Ramon Aguero schrieb:
Hello Tim,
thanks for pinpointing the error! Somehow I made a mistake when
copying and pasting the code to the file.
The correct procedure would be the following one (note that the
arptable_ is now within the 'for' cycle). In this sense, I don't think
you need to change all arptable_ into arptable. Hope this helps.
Node/MobileNode instproc reset {} {
$self instvar arptable_ nifs_ netif_ mac_ ifq_ ll_ imep_
for {set i 0} {$i $nifs_} {incr i} {
$netif_($i) reset
$mac_($i) reset
$ll_($i) reset
$ifq_($i) reset
if { [info exists opt(imep)] $opt(imep) == ON } {
$imep_($i) reset
}
if { $arptable_($i) != } {
$arptable_($i) reset
}
}
}
Cheers,
Ramón
PS - I've already modified the document -- with the correct procedure
-- in the web page:
http://personales.unican.es/aguerocr
At 16:39 18/01/2007, Tim Elschner wrote:
great job as far as i can see.
anyway i ran into problems with ns-mobilenode.tcl:
in Node/MobileNode instproc reset i couldn't find any differences
to the original.
i got an error, that arptable_ is an array. so i changed every
arptable_ into arptable. now ns2 complains about the missing variable
arptable :(
any hints out there?
cheers,
tim
Ramon Aguero schrieb:
Dear all,
We have seen a lot of requests about the possibility to extend the
NS-2 framework to support multiple interfaces. Although there is
some information available, according to the messages that have been
sent to this list, it seems that a more thorough description may be
required.
In this sense, after performing an analysis about existing
activities in this topic, we have created a document that tries to
summarize which are the required changes to be performed within the
different pieces of the simulator (tcl, c++) as well as how routing
protocols can be adapted to make use of the new feature. The howto
is entitled Adding Multiple Interface Support in NS-2 and it has
been written by my colleague Jesús Pérez and myself.
Ive uploaded the document, which can be retrieved from the
following url:
http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr
We will be happy to receive any feedback, comments, so as to improve
the howto, since we would like to have it like a living document,
adding new features as they are available.
Best regards,
Ramón
Ramón Agüero Calvo
Dept. of Communications Engineering
Network Planning Mobile Communications
Laboratory
University of Cantabria
Avda Castros s/n
39005 - Santander
SPAIN
[EMAIL PROTECTED]
Tel: +34 942 201 392 (Ext 14)
Fax: +34 942 201 488
Re: [ns] [HELP] Adding Multiple Interface Support in NS-2
Hello Santhish,
I think that your problem is that you did not completely modify the
add-interface procedure. Maybe the problem was that there was two
additional lines that needed to be modified (changing $arptable_ with
$arptable), which were not highlighted in bold.
I've put these lines in bold font in a new version of the document. I guess
that changing these two lines would be enough to get rid of your error.
Cheers,
Ramón
At 00:13 30/01/2007, rsg wrote:
Hello SIr,
Thanks for your reply.Could you provide me with a sample tcl script so
that I could start off analyzing it before stepping into OLSR?
I attempted as per the guide but it fails with the following error
output.Hence if you could provide me with a working simple script, it
would be a great help.
Here's what I got when I tried it with a simple-wireless.tcl with
AODV.(attached fyi)
Many thanks once again for your time.
Regards,
Santhish.
---
num_nodes is set 12
can't read arptable_: variable is array
while executing
$arptable_ drop-target $drpT
(procedure _o16 line 58)
(Node/MobileNode add-interface line 58)
invoked from within
$node add-interface $chan($i) $propInstance_ $llType_ $macType_
$ifqType_ $ifqlen_ $phyType_ $antType_ $topoInstance_ $inerrProc_
$outerrProc_ $FECP...
(procedure _o3 line 70)
(Simulator create-wireless-node line 70)
invoked from within
_o3 create-wireless-node
(eval body line 1)
invoked from within
eval $self create-wireless-node $args
(procedure _o3 line 23)
(Simulator node line 23)
invoked from within
$ns_ node
(for body line 2)
invoked from within
for {set i 0} {$i $val(nn) } {incr i} {
set node_($i) [$ns_ node]
$node_($i) random-motion 0 ;# disable random
motion
}
(file simple-wireless.tcl line 68)
On 1/29/07, Ramon Aguero [EMAIL PROTECTED] wrote:
Hi Santhish,
I've not personally used the olsr implementation from University of Murcia.
My understanding is that they do not support multiple-interfaces yet:
Compliant with core-OLSR (but the use of multiple interfaces which is
currently not supported by NS2) as it is documented in RFC 3626.
I guess that you have to follow the procedures that I've already described
for AODV and DSDV, adpating them to the particular characteristics of this
OLSR implementation.
If you have sort of more specific question, come back to me.
Cheers,
Ramón
At 14:24 29/01/2007, you wrote:
Hello Sir,
Thanks for your valuable contribution of introducing multi
interface/channel for NS2.
Wonder whether this could be incorporated with OLSR where there's
multi interface support already.
http://masimum.dif.um.es/um-olsr/html/
Any hints in this regard would be highly appreciated.
Thanking you for your attention,
Santhish.
On 1/29/07, Ramon Aguero [EMAIL PROTECTED] wrote:
Hello Tua,
see some responses in-line.
At 06:37 22/01/2007, #LUONG TRUNG TUAN# wrote:
I'm a research student in field of MANET.I have been trying to add the
multiple interface support for Ns2 for a while but still not get any
results. And recently I'm very glad to see your released document about
Adding Multiple Interface Support in NS-2. First of all, I would
like to
thank you very much for your contribution for extending ns, which is a
great helps for student like me.
Thanks for your interest. This is really the aim we had when creating the
document.
Regarding your extension, I would like to ask few questions
How would you specify which interface will be used for sending data
packet? As I see that you need a variable interface for routing
entry, so
when we add or update an entry, this value will be modified, so by that
you mean this value will be manually specified when we create a new
data flow?
The idea is that this should be handled from the routing agent. This is to
say, the application (e.g. cbr) should not be aware of how the routing
agent sends the packet; it is even unaware of the number of interfaces a
node is managing.
Have you tried for DSDV routing? I trying as follow your guidelines, but
not so sure how to specify the interface value for new entry and
updating
existing routing entry
No, as we say in the text we worked with our own implementation; and we
took a look on AODV according to some request we get in the ns-users
mailing list. See:
http://mailman.isi.edu/pipermail/ns-users/2007-January/058433.html
I've taken a quick look on the dsdv code, and this is what I've found:
*** UNICAST TRANSMISSIONS
- It seems that all unicast transmissions are handled by the forwardPacket
method, with:
target_-recv(p, (Handler *)0);
This is different from the way aodv sends packets, but my guess would be
that you might need to change target_ in the code above for target_[Iface]
--- see Listing 5.4. As I said in the email referenced above, the Iface
index need to be gathered from
Re: [ns] Multi-interface support howto, by Ramon Aguero
Hello Nguyen, (see inline) At 02:11 30/01/2007, Nguyen Lan wrote: Hi Razmon, I have a question related to the multi-interface support in ns2 - In Listing 4.4: hdr-iface() = addr(), addr is index of the interface that received this packet. But how can I get that value (which variant or function) The addr() method is declared in the Mac class and, since Mac802_11 inherits from this, you can use it. It will return the index_, which is somehow mapped to the mac address. - And in struct hdr_cmn (packet.h) there is a field name iface_ to store received interface index. Can I use it in Listing 4.4 like hdr-iface_ = xxx Well, basically the hdr-iface() method, just returns (in-line) the iface_ field (see definition of struct hdr_cmn in packet.h); so you are saying the same thing. Best regards, Nguyen Cheers, Ramón Ramon Aguero wrote: Hi Shahatha, As we say in the report we didn't use aodv, so we really appreciate that you work on this, it would be good trying to extend the report with your own experience on AODV. We have been doing a quick overlook of the aodv code (which we have not personally used that much) and this is what we can tell for the listings of chapter 5: - Listing 5.3 has to be used whenever the AODV needs to send a broadcast packet, which happens, as far as we can tell, in the following methods of the aodv.cc file: sendRequest, sendError, sendHello and forward; in this latter case only when the destination address is broadcast. In all of this, you should have the following command: Scheduler::instance().schedule(target_,pkt,*); --- * means either 0 or JITTER and you should change it for listing 5.3. - Listing 5.4 has to be used instead of the unicast transmissions of aodv.cc, this time in sendReply and forward methods. In this case, the Iface variable has to be the appropriate interface index, which needs to be stored within the corresponding route table entry (see section 5.3 of the document). - Listing 5.5 is the one that allows you to get the correct interface. When you have to create a route table entry, you need to indicate the corresponding index for the output interface, which will be used afterwards to send packets (see previous answer). This means that the corresponding struct/class for your route table entry needs to be updated, so as to be able to keep this index. Thanks to the changes of the mac-802_11.cc file (listing 4.6), the required value is store on the common header of the packet, that's the cmnh variable of the listing. Iface will just hold the index that will be used for creating/updating the route table entry. After a quick overlook of the code, this seems to be needed in two methods: recvRequest and recvReply. Cheers, Ramón At 10:53 18/01/2007, Shahatha wrote: Hello, did any one implement the extension of ns-2 for multi-channel from Ramon Aguero at: http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr many thanks for Ramon Aguero for his Dokument. i have some problems at Chapter 5, where to add the listing 5.3 Listing 5.5 and Listing 5.6 in routingAgent.cc. (AODV.cc) i choice the AODV ad hoc routing agent to change. i think i can copy the Listing above 1 by 1 to the AODV.cc. thanks - NEU: Fragen stellen - Wissen, Meinungen und Erfahrungen teilen. Jetzt auf Yahoo! Clever.
Re: [ns] Multi-interface support howto, Ramon Submission
Hi Anthony,
thanks for your feedback; I think that your proposal is perfectly fine.
I've sent an email previously, about the same changes. I think that the
problem was that in the first version of the document we did not highlight
a couple of lines (the ones that you've modified); in the original
ns-mobilenode.tcl file, these two lines started with $arptable_ **Note the
underscore**
In the modified procedure, however, it was $arptable **Without the
underscore**, which is, exactly what you propose, since the $arptable
variable is $arptable_($t).
Cheers,
Ramón
At 07:29 04/02/2007, Anthony Plummer wrote:
Ramon's submission (http://personales.unican.es/aguerocr/) of a
multiple-channel extension to ns2 works well after a slight
modification to the code in the pdf. In tcl/lib/ns-mobilenode.tcl the
arptable modification (pg. 24 25 of pdf) needs to change the
arptable in two additional lines.
#We also create one ARP table per interface
set arptable_($t) [new ARPTable $self $mac]
set arptable $arptable_($t)
# FOR backward compatibility sake, hack only
if {$imepflag != } {
set drpT [$self mobility-trace Drop IFQ]
} else {
set drpT [cmu-trace Drop IFQ $self]
}
$arptable_($t) drop-target $drpT // Should be changed to this here
if { $namfp != } {
$drpT namattach $namfp
}
#
# Link Layer
#
$ll arptable $arptable_($t) // Should be changed to this here
$ll mac $mac
$ll down-target $ifq
Re: [ns] Multi-interface support howto
Hello, I already gave an answer regarding this (especially on Listings 5.3, 5.4 and 5.5. - Regarding Listing 5.1: you have to add that in the definition of the routing agent (i.e. the aodv.h file). - Regarding Listing 5.2: you have to modify the command method of the routing agent, which is within the aodv.cc file. HTH, Ramón At 10:06 21/01/2007, h sh wrote: Hello, Thank you very much for your Document. http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr As i understand i can extend one of the protocol agents: AODV, DSDV or TORA? i choice the AODV ad hoc routing agent to change. i have some problems at Chapter 5, In AODV.h i should add the Listing 5.1? In AODV.cc i should add the Listing 5.2, Listing 5.3, Listing 5.4 and Listing 5.5? Please help me Thanks Ramon Aguero [EMAIL PROTECTED] wrote: Dear all, We have seen a lot of requests about the possibility to extend the NS-2 framework to support multiple interfaces. Although there is some information available, according to the messages that have been sent to this list, it seems that a more thorough description may be required. In this sense, after performing an analysis about existing activities in this topic, we have created a document that tries to summarize which are the required changes to be performed within the different pieces of the simulator (tcl, c++) as well as how routing protocols can be adapted to make use of the new feature. The howto is entitled Adding Multiple Interface Support in NS-2 and it has been written by my colleague Jesús Pérez and myself. Ive uploaded the document, which can be retrieved from the following url: http://personales.unican.es/aguerocr We will be happy to receive any feedback, comments, so as to improve the howto, since we would like to have it like a living document, adding new features as they are available. Best regards, Ramón Ramón Agüero Calvo Dept. of Communications Engineering Network Planning Mobile Communications Laboratory University of Cantabria Avda Castros s/n 39005 - Santander SPAIN [EMAIL PROTECTED] Tel: +34 942 201 392 (Ext 14) Fax: +34 942 201 488 Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta.
Re: [ns] Multi-interface support howto
Hi, The mail I was referring to, when I gave the is: http://mailman.isi.edu/pipermail/ns-users/2007-January/058433.html Cheers, Ramón At 12:00 29/01/2007, Ramon Aguero wrote: Hello, I already gave an answer regarding this (especially on Listings 5.3, 5.4 and 5.5. - Regarding Listing 5.1: you have to add that in the definition of the routing agent (i.e. the aodv.h file). - Regarding Listing 5.2: you have to modify the command method of the routing agent, which is within the aodv.cc file. HTH, Ramón At 10:06 21/01/2007, h sh wrote: Hello, Thank you very much for your Document. http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr As i understand i can extend one of the protocol agents: AODV, DSDV or TORA? i choice the AODV ad hoc routing agent to change. i have some problems at Chapter 5, In AODV.h i should add the Listing 5.1? In AODV.cc i should add the Listing 5.2, Listing 5.3, Listing 5.4 and Listing 5.5? Please help me Thanks Ramon Aguero [EMAIL PROTECTED] wrote: Dear all, We have seen a lot of requests about the possibility to extend the NS-2 framework to support multiple interfaces. Although there is some information available, according to the messages that have been sent to this list, it seems that a more thorough description may be required. In this sense, after performing an analysis about existing activities in this topic, we have created a document that tries to summarize which are the required changes to be performed within the different pieces of the simulator (tcl, c++) as well as how routing protocols can be adapted to make use of the new feature. The howto is entitled Adding Multiple Interface Support in NS-2 and it has been written by my colleague Jesús Pérez and myself. Ive uploaded the document, which can be retrieved from the following url: http://personales.unican.es/aguerocr We will be happy to receive any feedback, comments, so as to improve the howto, since we would like to have it like a living document, adding new features as they are available. Best regards, Ramón Ramón Agüero Calvo Dept. of Communications Engineering Network Planning Mobile Communications Laboratory University of Cantabria Avda Castros s/n 39005 - Santander SPAIN [EMAIL PROTECTED] Tel: +34 942 201 392 (Ext 14) Fax: +34 942 201 488 Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta.
Re: [ns] [HELP] Adding Multiple Interface Support in NS-2
Hello Tua,
see some responses in-line.
At 06:37 22/01/2007, #LUONG TRUNG TUAN# wrote:
Im a research student in field of MANET.I have been trying to add the
multiple interface support for Ns2 for a while but still not get any
results. And recently Im very glad to see your released document about
Adding Multiple Interface Support in NS-2. First of all, I would like to
thank you very much for your contribution for extending ns, which is a
great helps for student like me.
Thanks for your interest. This is really the aim we had when creating the
document.
Regarding your extension, I would like to ask few questions
How would you specify which interface will be used for sending data
packet? As I see that you need a variable interface for routing entry, so
when we add or update an entry, this value will be modified, so by that
you mean this value will be manually specified when we create a new data flow?
The idea is that this should be handled from the routing agent. This is to
say, the application (e.g. cbr) should not be aware of how the routing
agent sends the packet; it is even unaware of the number of interfaces a
node is managing.
Have you tried for DSDV routing? I trying as follow your guidelines, but
not so sure how to specify the interface value for new entry and updating
existing routing entry
No, as we say in the text we worked with our own implementation; and we
took a look on AODV according to some request we get in the ns-users
mailing list. See:
http://mailman.isi.edu/pipermail/ns-users/2007-January/058433.html
I've taken a quick look on the dsdv code, and this is what I've found:
*** UNICAST TRANSMISSIONS
- It seems that all unicast transmissions are handled by the forwardPacket
method, with:
target_-recv(p, (Handler *)0);
This is different from the way aodv sends packets, but my guess would be
that you might need to change target_ in the code above for target_[Iface]
--- see Listing 5.4. As I said in the email referenced above, the Iface
index need to be gathered from the route table entry.
Not double-checked code
if(nIfaces) {
target_[Iface]-recv(p, (Handler *)0);
} else {
target_-recv(p, (Handler *)0);
}
*** BROADCAST TRANSMISSIONS
- All broadcast packets are handled by the sendOutBCastPkt method, so
instead of that one I guess you should use a modified version of Listing
5.3, e.g. see below:
--- Not double-checked code
Scheduler s = Scheduler::instance();
if (nIfaces) {
for (int i = 0 ; i nIfaces ; i++) {
Packet *p_copy = p-copy();
s.schedule(targetlist[i], p_copy,
jitter(DSDV_BROADCAST_JITTER, be_random_));
}
Packet::free(pkt);
} else {
s.schedule(target_,p,jitter(DSDV_BROADCAST_JITTER, be_random_));
}
*** CHANGES ON ROUTE TABLE ENTRY
- You need to add the index for the outgoing interface as a new member of
the rtable_ent class, and each time you add the routing table entry you may
also need to specify this --- see listing 5.5 and my answer on the mail
linked above. Note that this will be afterwards used to refer to the
appropriate interface when sending a unicast packet.
Can your extension work for multiple interfaces of different kinds such as
802_11, wimax, tdma, umts together?
Currently not, or at least we haven't addressed this so far. The idea was
to propose a flexible framework, so that extending it to support more
technologies shouldn't be too complicated. If you are going to work on
this, we will be happy to help/contribute to that.
Would be very much appreciate if you could kindly address my questions
Hope that my answers are somehow helpful for you.
Than you very much and best regards,
Tuan
Cheers,
Ramón
Re: [ns] Multi-interface support howto
Hello Shahatha, In addition to the answers we have given before, see some more answers inline... Cheers, Ramón At 12:00 17/01/2007, you wrote: chapter 4 4.2 Listing 4.1 the variable MAX_CHANNELS i have declared it like a follow in mobilenode.h : #define MAX_CHANNELS XXX but which value? or without value? you do need to specify a value, depending on your own interests. This will set the maximum number of interfaces per node; i guess that realistically, having more than 8 would be difficult. 4.3 in channel.cc Listing 4.4: nextX_ and prevX_ should changed to nextX_ [this-index()] and prevX_ [this-index()] in the whole channel.cc. right? Yes, as stated in the document, just before the listing: Note that this has to be changed throughout the whole channel.cc file. - chapter 5 5.1 as i understand i can extend one of the protokol agents: AODV, DSDV or TORA, right? i have choice AODV. Good, probably we can extend the document with this experience. I'm not sure about TORA, since we have not seen that code at all. 5.2 MAX_IF should be declared in AODV.h with #define MAX_IF but which value? See my previous answer. in AODV.h the AODV-class i found ifqueue i chnage it to ifqueuelist[MAX_IF], and i found Trace *logtarget; but not target. i add targetlist[MAX_IF] just like in Listing 5.1. I won't delete ifqueue, since this is needed if you want to keep the legacy behaviour of the simulator. Keep the logtarget, since you need it for tracing support and add targetlist, as stated in Listing 5.1. in which mothod in AODV.cc i should add the Listing 5.3, Listing 5.4 and Listing 5.5 ? in Listing 5.5 Iface and cmnh are not declared ! All these questions have been already answered in my previous email. ps. do you have the changes as a dokument? No, since the main ns is being updated quite frequently and different people make different changes to the core files, we decided not make any code/patch available, but rather provide an extensive discussion of the required modifications, so that people can do it by themselves.
Re: [ns] Multi-interface support howto, by Ramon Aguero
Hi Shahatha, As we say in the report we didn't use aodv, so we really appreciate that you work on this, it would be good trying to extend the report with your own experience on AODV. We have been doing a quick overlook of the aodv code (which we have not personally used that much) and this is what we can tell for the listings of chapter 5: - Listing 5.3 has to be used whenever the AODV needs to send a broadcast packet, which happens, as far as we can tell, in the following methods of the aodv.cc file: sendRequest, sendError, sendHello and forward; in this latter case only when the destination address is broadcast. In all of this, you should have the following command: Scheduler::instance().schedule(target_,pkt,*); --- * means either 0 or JITTER and you should change it for listing 5.3. - Listing 5.4 has to be used instead of the unicast transmissions of aodv.cc, this time in sendReply and forward methods. In this case, the Iface variable has to be the appropriate interface index, which needs to be stored within the corresponding route table entry (see section 5.3 of the document). - Listing 5.5 is the one that allows you to get the correct interface. When you have to create a route table entry, you need to indicate the corresponding index for the output interface, which will be used afterwards to send packets (see previous answer). This means that the corresponding struct/class for your route table entry needs to be updated, so as to be able to keep this index. Thanks to the changes of the mac-802_11.cc file (listing 4.6), the required value is store on the common header of the packet, that's the cmnh variable of the listing. Iface will just hold the index that will be used for creating/updating the route table entry. After a quick overlook of the code, this seems to be needed in two methods: recvRequest and recvReply. Cheers, Ramón At 10:53 18/01/2007, Shahatha wrote: Hello, did any one implement the extension of ns-2 for multi-channel from Ramon Aguero at: http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr many thanks for Ramon Aguero for his Dokument. i have some problems at Chapter 5, where to add the listing 5.3 Listing 5.5 and Listing 5.6 in routingAgent.cc. (AODV.cc) i choice the AODV ad hoc routing agent to change. i think i can copy the Listing above 1 by 1 to the AODV.cc. thanks - NEU: Fragen stellen - Wissen, Meinungen und Erfahrungen teilen. Jetzt auf Yahoo! Clever.
Re: [ns] Multi-interface support howto
Hello Tim,
thanks for pinpointing the error! Somehow I made a mistake when copying and
pasting the code to the file.
The correct procedure would be the following one (note that the arptable_
is now within the 'for' cycle). In this sense, I don't think you need to
change all arptable_ into arptable. Hope this helps.
Node/MobileNode instproc reset {} {
$self instvar arptable_ nifs_ netif_ mac_ ifq_ ll_ imep_
for {set i 0} {$i $nifs_} {incr i} {
$netif_($i) reset
$mac_($i) reset
$ll_($i) reset
$ifq_($i) reset
if { [info exists opt(imep)] $opt(imep) == ON } {
$imep_($i) reset
}
if { $arptable_($i) != } {
$arptable_($i) reset
}
}
}
Cheers,
Ramón
PS - I've already modified the document -- with the correct procedure -- in
the web page:
http://personales.unican.es/aguerocr
At 16:39 18/01/2007, Tim Elschner wrote:
great job as far as i can see.
anyway i ran into problems with ns-mobilenode.tcl:
in Node/MobileNode instproc reset i couldn't find any differences to the
original.
i got an error, that arptable_ is an array. so i changed every arptable_
into arptable. now ns2 complains about the missing variable arptable :(
any hints out there?
cheers,
tim
Ramon Aguero schrieb:
Dear all,
We have seen a lot of requests about the possibility to extend the NS-2
framework to support multiple interfaces. Although there is some
information available, according to the messages that have been sent to
this list, it seems that a more thorough description may be required.
In this sense, after performing an analysis about existing activities in
this topic, we have created a document that tries to summarize which are
the required changes to be performed within the different pieces of the
simulator (tcl, c++) as well as how routing protocols can be adapted to
make use of the new feature. The howto is entitled Adding Multiple
Interface Support in NS-2 and it has been written by my colleague Jesús
Pérez and myself.
Ive uploaded the document, which can be retrieved from the following url:
http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr
We will be happy to receive any feedback, comments, so as to improve the
howto, since we would like to have it like a living document, adding new
features as they are available.
Best regards,
Ramón
Ramón Agüero Calvo
Dept. of Communications Engineering
Network Planning Mobile Communications
Laboratory
University of Cantabria
Avda Castros s/n
39005 - Santander
SPAIN
[EMAIL PROTECTED]
Tel: +34 942 201 392 (Ext 14)
Fax: +34 942 201 488
[ns] Multi-interface support howto
Dear all, We have seen a lot of requests about the possibility to extend the NS-2 framework to support multiple interfaces. Although there is some information available, according to the messages that have been sent to this list, it seems that a more thorough description may be required. In this sense, after performing an analysis about existing activities in this topic, we have created a document that tries to summarize which are the required changes to be performed within the different pieces of the simulator (tcl, c++) as well as how routing protocols can be adapted to make use of the new feature. The howto is entitled Adding Multiple Interface Support in NS-2 and it has been written by my colleague Jesús Pérez and myself. Ive uploaded the document, which can be retrieved from the following url: http://personales.unican.es/aguerocrhttp://personales.unican.es/aguerocr We will be happy to receive any feedback, comments, so as to improve the howto, since we would like to have it like a living document, adding new features as they are available. Best regards, Ramón Ramón Agüero Calvo Dept. of Communications Engineering Network Planning Mobile Communications Laboratory University of Cantabria Avda Castros s/n 39005 - Santander SPAIN [EMAIL PROTECTED] Tel: +34 942 201 392 (Ext 14) Fax: +34 942 201 488
Re: [ns] static routing in ad hoc network
Was not this NOAH intended to do something like that? I've not tried it by myself, but it may be worth giving it a try. Regards, Ramón At 16:16 02/02/2006, Michael Lee wrote: Sara, ns2 doesn't support static routing for wireless nodes. There might be a 3rd party module that adds this, but I am not aware of any. Regards, Michael On Feb 2, 2006, at 3:31 AM, saradellaluna wrote: Dear all, I am a newbie in NS2, and I am working on wireless sensors network simulation using the 802.15.4 module developed by Zheng. The scripts that come with the module use AODV as the routing protocol. However, I would like to configure static routing tables for each node, so as to be able to control the exact path followed by my packets. Can anybody give suggestions on how to do this? Thanks in advance! Regards, Sara Della Luna
