- 论坛徽章:
- 0
|
关于NS2中扩展多接口多信道的方案，从灵活性方面考虑，目前最流行的和最好应该就是Ramon的和Laurent的了。两者各有千秋，各自也就其方案有过很多讨论，现收集部分，同大家分享的同时也给自己作个备忘。看看两个作者的争论，还蛮有意思的……
（另外，这个站点有关于多接口主题的很多讨论：
http://mailman.isi.edu/pipermail/ns-users/2007-February/subject.html#58805
）
（1）[ns] Multi-interface support howtoLaurent Paquereau
[email=ns-users%40isi.edu?Subject=%5Bns%5D%20Multi-interface%20support%20howto&In-Reply-To=]laurent.paquereau at q2s.ntnu.no [/email]
Fri Feb 2 00:55:00 PST 2007
Ramón,
I have been reading your how-to and as your statements and concerns are
quite similar to a subset of those we presented last year in [1], you
might find interesting reading this paper.
[1] Laurent Paquereau and Bjarne E. Helvik, "A Module-based Wireless
Node for ns-2", in Proceedings of the first Workshop on NS2: the IP
network simulator (WNS2), Pisa, Italy, 2006.
A Module-based Wireless Node (MW-Node) is a Node with wireless and
mobile capabilities added by means of modules. It is not a new node
object derived from Node. Rather it is a new layout of mostly existing
components. The aim is to provide a flexible support for wireless and
mobile networking and in particular:
* support for multiple interfaces/multiple channels, and
* a common basis for the implementation of wireless routing protocols.
The code is distributed as a patch for ns-2.30 and is now available
online with the documentation at:
http://www.q2s.ntnu.no/~paquerea/ns.html
Feedback and comments are much appreciated.
Best regards,
Laurent Paquereau
Q2S Centre of Excellence, NTNU
Ramon Aguero 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.
>
> I’ve 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
> ramon at tlmat.unican.es
> Tel: +34 942 201 392 (Ext 14)
> Fax: +34 942 201 488
> ========================================
More information about the Ns-users mailing list
（2）[ns] Multi-interface support howtoRamon Aguero
[email=ns-users%40isi.edu?Subject=%5Bns%5D%20Multi-interface%20support%20howto&In-Reply-To=45D5AAD9.9060901%40q2s.ntnu.no]ramon at tlmat.unican.es [/email]
Wed Feb 21 08:46:03 PST 2007
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
More information about the Ns-users mailing list
（3）[ns] Multi-interface support howto, Ramon SubmissionNguyen Lan
[email=ns-users%40isi.edu?Subject=%5Bns%5D%20Multi-interface%20support%20howto%2C%20Ramon%20Submission&In-Reply-To=6.1.2.0.2.20070205161144.044b2448%40luna.tlmat.unican.es]nguyentienlan at gmail.com [/email]
Mon Feb 5 22:34:13 PST 2007
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
>>
>
>
>
>
More information about the Ns-users mailing list
（4）[ns] Multi-interface support howto, Ramon SubmissionNguyen Lan
[email=ns-users%40isi.edu?Subject=%5Bns%5D%20Multi-interface%20support%20howto%2C%20Ramon%20Submission&In-Reply-To=45CE6594.7060301%40gmail.com]nguyentienlan at gmail.com [/email]
Tue Feb 13 04:25:52 PST 2007
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
>>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>
>
More information about the Ns-users mailing list
本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u3/94593/showart_1932829.html |
|
免费注册
发表于 2009-05-19 11:13