分类： LINUX
2009-05-19 11:13:31
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: 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: > <> > > 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 > ========================================
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, >) > >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 >(), some flexibility added. To >this respect their contribution is to me very similar to the resources >available at 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
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 () 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
>>
>
>
>
>
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 () 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
>>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>
>