how to construct tree in ns2 and how to write routing protocol in ns2?
clustered nodes to be arranged in tree structure and code for deflection routing in ns2.
I also need to know how to increase the energy of a node and how to make a node inactive.
For simulating the energy of nodes the example in tcl/ex/wireless-newnode-energy.tcl
Also, to see the available command for changing the energy of a node during simulation, see see source files in mac/wireless-phy.cc, method int WirelessPhy::command(int argc, const char*const* argv)
To implement your own routing protocol in ns2, read this article
I did not fully understand the part about the tree structure and the deflection.
Related
I started (since about one week) using veins (4.4) under omnet++ (5.0).
My current task is to let vehicles adjust their transmission range according to a specific context. I did read a lot of asked questions like these ones (and in other topics/forums):
Dynamical transmission range in the ieee802.11p module
Vehicles Receive Beacon Messages outside RSU Range
How coverage distance and interference distance are affected by each other
Maximum transmission range vs maximum interference distance
Reduce the coverage area between vehicles
how to set the transmission range of a node under Veins 2.0?
My Question:
How to -really- change the transmission range of just some nodes?
From the links above, I knew that the term "transmission range", technically, is related to the received power, noise,sensitivity threshold, etc. which defines the probability of reception.
Since I am new to veins (and omnet++ as well), I did few tests and I concluded the following:
"TraCIMobility" module can adjust the nodes' parameters (for each vehicle, there is an instance) such as the ID, speed, etc.
I could, also, instantiate the "Mac1609_4" (for each vehicle) and changed some of its parameters like the "txPower" during simulation run-time but it had no effect on the real communication range.
I could not instantiate (because it was global) the "connection manager" module which was the only responsible of (and does override) the effective communication range. this module can be configured in the ".ini" file but I want different transmission powers and most importantly "can be changed during run-time".
The formula to calculate the transmission range is in the attached links, I got it, but it must be a way to define or change these parameters in one of the layers (even if it is in the phy layer, i.e., something like the attached signal strength...)
Again, maybe there is some wrong ideas in what I have said, I just want to know what/how to change this transmission range.
Best regards,
You were right to increase the mac1609_4.txPower parameter to have a node send with more power (hence, the signal being decodable further away). Note, however, that (for Veins 4.4) you will also need to increase connectionManager.pMax then, as this value is used to determine the maximum distance (away from a transmitting simulation module) that a receiving simulation module will be informed about an ongoing transmission. Any receiving simulation module further away will not be influenced by the transmission (in the sense of it being a candidate for decoding, but also in the sense of it contributing to interference).
Also note that transmissions on an (otherwise) perfectly idle channel will reach much further than transmissions on a typically-loaded channel. If you want to obtain a good measurement of how far a transmission reaches, have some nodes create interference (by transmitting broadcasts of their own), then look at how the Frame Delivery Rate (FDR) drops as distance between sender and receiver increases.
Finally, note that both 1) the noise floor and 2) the minimum power level necessary for the simulation module of a receiver to attempt decoding a frame need to be calibrated to the WLAN card you want to simulate. The values chosen in the Veins 4.4 tutorial example are very useful for demonstrating the concepts of Veins, whereas the values of more recent versions of Veins come closer to what you would expect from a "typical" WLAN card used in some of the more recent field tests. See the paper Bastian Bloessl and Aisling O'Driscoll, "A Case for Good Defaults: Pitfalls in VANET Physical Layer Simulations," Proceedings of IFIP Wireless Days Conference 2019, Manchester, UK, April 2019 for a more detailed discussion of these parameters.
I am just giving my opinion in case someone was already in my situation:
In veins (the old version that I am using is 4.4), the "connection manager" is the responsible for evaluating a "potential" exchange of packets, thus, its transmission power is almost always set to the upper-bound.
I was been confused after I changed the vehicles "Mac1609_4" transmission power and "graphically", the connection manager was still showing me that the packets are received by some far nodes which in fact was not the case, it was just evaluating whether it is properly received or not (via the formula discussed in the links above).
Thus: changing the "TxPower" of each vehicle had really an effect beside graphically (the messages were not mounted to the upper layers).
In sum, to make a transmission range aware scheme, this is what must be done:
In the sender node (vehicle), and similarly to the pointer "traci" which deals with the mobility features, a pointer to the "mac1609" must be created and pointed to it as follows:
In "tracidemo11p.h" add ->
#include "veins/modules/mac/ieee80211p/Mac1609_4.h"//added
#include "veins/base/utils/FindModule.h"//added
and as a protected variable in the class of "tracidemo11p" in the same ".h" file ->
Mac1609_4* mac;//added
In "tracidemo11p.cc" add ->
mac = FindModule<Mac1609_4*>::findSubModule(getParentModule());
now you can manipulate "mac" as in "traci", the appropriate methods are in the "modules/mac/ieee80211p/Mac1609_4.cc & .h"
for our work, the method will be:
mac->setTxPower(10);//for example
This will have an impact on the simulation in real-time for each node instance.
It may had described it with basic concepts because I am new to omnet-veins, these was done in less than one week (and will be provided for new users as well).
I hope it will be helpful (and correct)
I am trying to write a compiler/code editor.
To speed up the process I want a red and black tree that returns a node which I can then use to get the strings under it, and it's position value, and use it's parent node as a place to store a token (such as alphanumeric_word or left_parenthesis).
I am having trouble finding the best way to go about this.
I basically want something that can do the following:
tree.insert("01234567890123456789",0);
node = tree.at(10);
tree.insert("string",5);
node.index(); //should be 10+length("string")
node.value(); //should be '0'
node.tokenPtr.value; //should point to a token with the value of NUMBER
I am looking for the simplest implementation of such a tree that I could modify since these can be frustrating to build and debug from scratch.
The following code is sort of what I am looking for (it has parent nodes), but it lacks an indexing feature for index look up. This is needed because I want to create a map that uses the node as it's key and node.index() as it's sorting value so that I don't have to update the keys in that map.
[[archive.gamedev.net/archive/reference/programming/features/TStorage/page2.html]]
I have tried to look at sgi's rope implimentation, but the code is overwhelming and difficult to understand.
This tutorial seems to be helpfull, however it also doesn't provide a doubly linked tree which I think can be used to find the index of a node:
[[eternallyconfuzzled.com/tuts/datastructures/jsw_tut_rbtree.aspx]]
Update:
I have found an implementation that has a parent node, however it still lacks an index count property:
[[web.mit.edu/~emin/Desktop/ref_to_emin/www.old/source_code/red_black_tree/index.html]]
I have found one solution and another that might work.
You have to use the sgi stl rope mutable_begin()+(index) iterator.
There is also this function, however I am still having trouble analyzing the sgi rope code to see what it does:
mutable_reference_at(index)
I need to implement TDMA and FDMA based slot assignment protocol. I have written the code for TDMA slot assignment but very much confused about the FDMA part.
Will someone please help me in writing the code for FDMA for a simple scenario. In which two nodes are using full duplex radios and working on two different frequencies. If node1 needs to communicate to node 2 thn node 2 must shift its frequency to node 1 frequency.
I have not worked with the radios yet. In TDMA part i am using senddirect for sending messages.
Kindly help me with the code of FDMA?
You have to use multiple radios in a single host. A good starting point is the example in inet path examples/manetrouting/multiradio. Run the simulation configuration MultiRadio within omnetpp.ini.
How to find nodes IDs in communication range of another node? I set communication range of a node to r=100. I wanted to set all those nodes as one hop neighbors which are in its range. How should i do that in omnet++? Any help will be appreciated.
Module positions are set in OMNeT++ via display string tags. You are looking for the first two components of the p tag, which stores modules' positions in a parent module. From these positions, you can derive the modules' distances. For dynamically finding out which modules are in a parent module, refer to the user manual's chapter on exploring the module hierarchy.
I was wondering if someone could help me understand this problem. I prepared a small diagram because it is much easier to explain it visually.
alt text http://img179.imageshack.us/img179/4315/pon.jpg
Problem I am trying to solve:
1. Constructing the dependency graph
Given the connectivity of the graph and a metric that determines how well a node depends on the other, order the dependencies. For instance, I could put in a few rules saying that
node 3 depends on node 4
node 2 depends on node 3
node 3 depends on node 5
But because the final rule is not "valuable" (again based on the same metric), I will not add the rule to my system.
2. Execute the request order
Once I built a dependency graph, execute the list in an order that maximizes the final connectivity. I am not sure if this is a really a problem but I somehow have a feeling that there might exist more than one order in which case, it is required to choose the best order.
First and foremost, I am wondering if I constructed the problem correctly and if I should be aware of any corner cases. Secondly, is there a closely related algorithm that I can look at? Currently, I am thinking of something like Feedback Arc Set or the Secretary Problem but I am a little confused at the moment. Any suggestions?
PS: I am a little confused about the problem myself so please don't flame on me for that. If any clarifications are needed, I will try to update the question.
It looks like you are trying to determine an ordering on requests you send to nodes with dependencies (or "partial ordering" for google) between nodes.
If you google "partial order dependency graph", you get a link to here, which should give you enough information to figure out a good solution.
In general, you want to sort the nodes in such a way that nodes come after their dependencies; AKA topological sort.
I'm a bit confused by your ordering constraints vs. the graphs that you picture: nothing matches up. That said, it sounds like you have soft ordering constraints (A should come before B, but doesn't have to) with costs for violating the constraint. An optimal algorithm for scheduling that is NP-hard, but I bet you could get a pretty good schedule using a DFS biased towards large-weight edges, then deleting all the back edges.
If you know in advance the dependencies of each node, you can easily build layers.
It's amusing, but I faced the very same problem when organizing... the compilation of the different modules of my application :)
The idea is simple:
def buildLayers(nodes):
layers = []
n = nodes[:] # copy the list
while not len(n) == 0:
layer = _buildRec(layers, n)
if len(layer) == 0: raise RuntimeError('Cyclic Dependency')
for l in layer: n.remove(l)
layers.append(layer)
return layers
def _buildRec(layers, nodes):
"""Build the next layer by selecting nodes whose dependencies
already appear in `layers`
"""
result = []
for n in nodes:
if n.dependencies in flatten(layers): result.append(n) # not truly python
return result
Then you can pop the layers one at a time, and each time you'll be able to send the request to each of the nodes of this layer in parallel.
If you keep a set of the already selected nodes and the dependencies are also represented as a set the check is more efficient. Other implementations would use event propagations to avoid all those nested loops...
Notice in the worst case you have O(n3), but I only had some thirty components and there are not THAT related :p