Omnet++ Send wireless message to limited distance - omnet++

I develop simulator of mobile nodes, each one with transmission range of 100m for example. The communication between the nodes are wireless and TDMA based.
I have notice that if 2 nodes (not in the same range) broadcast message on the same time, it's cause to a problem.
How can i limit the distance of nessage that is sent from a node ? such that i can broadcast 2 or more messages on the same time, and just the nodes in the range of the sending node will hear the message ?

The code that processes the reception of the packet should calculate the distance from the sender and drop the packet if it's out of range.
A little less accurate solution: before sending the packets the broadcasting node should check the distance to the potential receiving node and not send the packet if it is out of range. This is a bit faster (as it generates less packets) and more clear (you will see the broadcast animation only for the packets that actually delivered)
A much easier solution: Use INET Framework, which already has the necessary implementation. You would only need to implement a MAC module that handles the TDMA protocol.

Related

How to change transmission range for specific nodes mixim (omnet++)

I am using mixim and built a network including 10 nodes based on MAC 802.11.
I intend to change the transmission range of two nodes with Tx range = 200, and the other 8 nodes have Tx range = 300. I know to change Tx range of nodes, I should change Tx power in Phy layer and connection manager.
But, If I change the values, the transmission range of all the nodes will change because all the nodes use the same connection manager. Moreover, because all the nodes should have connections with others, I think I cannot use different connection managers.
In brief, I intend to change the Tx range of specific nodes (not all) in the network with same configuration, while all the nodes have connections together.
Thank you for your response.
What you are trying to set in the connection manager is the maximum interference range which has almost nothing to do with the range where radios are actually can successfully receive each other's packet. That seems to be only an optimization parameter. PhyLayer modules are present in each node, so those power parameters can be set independently for each, but you will have a HARD time figuring out, what power you should set, to get a specific distance (like 200m).
I advise you NOT to use MiXiM (and let it rest in peace), as it is a long abandoned project and all the functionality in it was merged long ago into the INET Framework.
In INET framework, you can set up UnitDisc radios, where you actually can set a transmission range in meters.
Check the wireless tutorial: https://inet.omnetpp.org/docs/tutorials/wireless/doc/step3.html

XBee coordinator data package reception

Hi I'm creating a xbee network with 1 coordinator and 20 end nodes transmitting data 8 times per second. (Currently i just made one of them talk to the coordinator).
I would like to know how many data packages the coordinator will be able to receive as I'll be transmitting in a high data rate. (20 end index x 8 times per second its 160 data packages per second).
Is that feasible ? Will I face any problems ? What should I be worried with ? For that data rate is there any other protocol I could use?
Thanks
I would say that it isn't feasible. The radio data rate of 802.15.4 networks is 250kbps. Once you're sending that many data packets per second, you'll be getting collisions and retransmissions. It might work if the packets are very small, but you'll still have a lot of overhead for packet headers. If this is a mesh network, you'll be using bandwidth for packet retransmission when a node can't communicate directly with the coordinator.
Is there a reason you need that data frequency? Can the end devices aggregate their data and send a single packet once/second with 8 data samples? Zigbee and 802.15.4 were designed for low data rates and low power.
If you're going to try this out, you'll want to configure the coordinator for at least 230kbps to keep up with the data flow. Do a proof of concept with a single end device (and configure it as a router, since you don't need "sleeping" capability of end devices), and then consider testing with 5 devices sending 4 times as much data (32 packets/second) to see if the coordinator can even keep up with that data flow.

send to the nearest node in a wireless network

In a wireless simulation with omnet++ inet 3.6, how can I manage sensor nodes to send the packets to the nearest mobile nodes? There are several sensor and mobile nodes in the field and thus cannot choose a specific destination like *.host[*].udpApp[0].destAddresses="host[0]"
Thanks for your answer.
If you have specific needs in the behavior of the application you are using, you need to implement that application. I assume you want to send UDP traffic (as TCP is connection oriented). Take a look at UdpBasicApp and modify it in a way that instead of reading the destination address once during the initialization, it must calculate the destination IP on each new packet (based on the position of nodes).

Aggregating results of vectors based on Omnet++ signals

I want to compute an overall delivery ratio in function of time using vectors based on Omnet++ signals ? How can i achieve it when there is a multiple source and only one sink.
For example, say that i have 10 mobiles nodes that send data to a fixed AP, the delivery ratio is equal to (received/sent packets), but the AP knows only the amount of received packets.
I declared the following signals and statistics:
For AP:
#signal[receivedBndl](type = "int");
#statistic[receivedBundle](title="ReceivedBundle";source=receivedBndl;record=count,mean,last,vector);
For Nodes:
#signal[sentBndl](type = "int");
#statistic[sentBundle](title="SentBundle";source=sentBndl;record=count,mean,last,vector);
Is it possible to create another #statistics that compute the Delivery Ratio in function of time with this 2 signals ?
Thanks,
This is more like a network wide statistic, than something related to a single node so you have to install your statistic listeners on the top-level network module itself instead of the actual nodes. OMNeT++ signals propagate up on the containment chain so any signal that was sent to a specific node will be delivered also to the containing network module. This makes it possible to install the statistics on the network and get the given signal there (too).
To achieve this I would rewrite the code to actually emit the sent/received cPacket objects (and not the count of them as an integer). You still can count the number of packets using the count() function in the statistics.
For AP:
#signal[receivedBndl](type = cPacket);
For nodes:
#signal[sentBndl](type = cPacket);
As each actual sent/received packet is now emitted to their sending/receiving module (and anything above them), you can install a statistic in the top-level module and combine them into a single statistic:
#statistic[deliveryratio](source=count(receivedBndl)/count(sentBndl); record=last);
This last line will install two signal listeners on the top level module and the statistics will calculate the value each and every time any module generates or receives a packet anywhere in the network.

Optimal retransmission algorithm for a broadcast channel

I have a number of microcontrollers which can communicate over a broadcast medium (in this case, IR). Each node wants to announce its presence to all the other nodes on a regular basis, but since it's a broadcast medium, two nodes transmitting at the same time will create a collision, and neither message will be transmitted correctly.
To further complicate things, when a node receives an invalid message, it doesn't seem practical to reliably determine if this is due to a collision or due to background noise or weak signal. Also, while node visibility will usually be reflexive (A seeing B means B can see A), it will usually be the case that not all nodes can see all other nodes.
Leaving aside external interference for a moment, it seems like a rational approach is to create timeslots, with each node transmitting in each time slot with a small (and ideally similar between nodes) probability. If there are n nodes that transmit with probability p, then no message will be transmitted (1 - p)n of the time; exactly one message will be transmitted n * p * (1 - p)n-1 of the time, and the remainder of the time there will be a collision. The maximum incidence of successful collisions occurs when each of the n nodes transmits 1/nth of the time, and this results in a fairly stable 38% successful transmissions and 24% collisions; this value changes only slightly with increasing numbers of nodes.
Given that, it would seem we could observe the rate of successful transmissions and/or collisions, and adjust our own transmission rate to try and force them towards their expected values. What I'm not sure about is what the best feedback mechanism to achieve this is, such that everyone ends up with similar probabilities. This also doesn't account for external interference, which will cause us to keep decreasing our transmission rate in a doomed effort to avoid collisions that don't exist.
What is the optimal algorithm - either a refinement of the above or a totally different approach - to maximize the proportion of announcement messages each node can receive without collision?
What you want is actually a wireless mesh network, which is a whole reseach field by itself. Apart from that acknowledgement messages are a good idea. You can piggyback them with the announcements themselves if packet overhead is a concern. They allow to distinguish between collisions and background noise by observing how many neighbors answered and allow basic rate limiting by waiting until (most) neighbors acknowledge each transmission (stop-and-go). This gets of course even more complicated if the controllers are very mobile.
It will be very hard (and probably not desirable) to maintain a equal update rate over the whole network, because transmission quality can vary wildly in different areas and points in time.

Resources