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
