Over subscription with RF-Pipe is not straight forward since the model itself does not implement any type of channel access protocol. Typically, for a CSMA type channel access, one can define a function that determines the probability of number of nodes trying to access the channel at the same time (i.e collision). In your case, it could be something simple based on datarate setting relative to the amount of traffic you are injecting at a given node. This would be done outside of the emulator and the loss effects based on probability of collision would have to be controlled via pathloss events and the PCR curve. So if both nodes are are sending minimal traffic relative to the available network bandwidth, the probability of collision would be low and as such, the operating point on the PCR curve would be at low loss. Once your probability of collision goes high, you would introduce higher loss. Delay can also be controlled accordingly based on probability of collision. You would have to make sure the actual RF effects due to pathloss are accounted for accordingly if that is of interest. This basically means the if your loss due to actual pathoss is at 20% and the collision introduces a loss of additional 10%, you would inject pathloss that would result in about 28% loss.
As stated above, this requires coordination outside of the emulator to inject the proper events and control when using RF-Pipe and is not a matter of simple model configuration. Hope this helps. Kaushik B. Patel Adjacent Link LLC On 04/11/2017 11:54 AM, Thomas Halwax wrote: > Kaushik, > > thank you for your detailed answer. I was not aware that it is possible to > oversubscribe the communication channel. Let my try to describe this behavior > in my own words: > > The nodes have a shared bandwidth of 57k. The communication pattern I use is > request-response. If the channel is over-subscribed and node A uses all the > available bandwidth, data sent by node B would get dropped because there is > no more bandwidth available. > > How can I introduce oversubscription? Here are my configuration files: > > <?xml version="1.0" encoding="UTF-8"?> > <!DOCTYPE nem SYSTEM "file:///usr/share/emane/dtd/nem.dtd"> > <nem> > <transport definition="transvirtual.xml"/> > <mac definition="rfpipemac.xml"/> > <phy> > <param name="fixedantennagain" value="3.0"/> > <param name="fixedantennagainenable" value="on"/> > <param name="bandwidth" value="25000"/> > <param name="noisemode" value="outofband"/> > <param name="propagationmodel" value="2ray"/> > <param name="systemnoisefigure" value="4.0"/> > <param name="subid" value="2"/> > <param name="txpower" value="46.99"/> > </phy> > </nem> > > <?xml version="1.0" encoding="UTF-8"?> > <!DOCTYPE mac SYSTEM "file:///usr/share/emane/dtd/mac.dtd"> > <mac library="rfpipemaclayer"> > <param name="enablepromiscuousmode" value="off"/> > <param name="datarate" value="57600"/> > <param name="jitter" value="0.10"/> > <param name="delay" value="0.7"/> > <param name="flowcontrolenable" value="off"/> > <param name="flowcontroltokens" value="10"/> > <param name="pcrcurveuri" > value="file:///usr/share/emane/xml/models/mac/rfpipe/rfpipepcr.xml"/> > </mac> > > > Thank you and best regards > Thomas > >> Am 11.04.2017 um 17:31 schrieb Kaushik B. Patel <[email protected]>: >> >> Thomas, either the RF-Pipe or TDMA model will support what you are tying >> to do. >> >> 1. For the RF-Pipe, a few items that are useful to understand: >> A. You can configure and dynamically control the transmit data rate >> allocated to each node via the "datarate" parameter. So if you have a >> total of 57kbps available between the two nodes, you can split the total >> available rate equally between the two nodes by setting datarate="27k". >> Since the "datarate" parameter is run time modifiable, you can also >> change the allocation during you experiment as required. Note: You can >> also oversubscribe by allocating more than 100% of total bandwidth which >> would introduce loss since in theory both nodes would be transmitting at >> the same time. The amount of loss experienced can be based on >> percentage of over subscription and manged via the PCR curves. >> >> B. Managing delay on the link is also configurable and run time >> modifiable via the "delay" and "jitter" parameters. >> >> C. Introducing loss on the link is controlled via the Packet Completion >> Rate curve. You can define your own curve or use the default curve file >> that comes with the model. >> >> 2. The TDMA model gives you similar ability as above but via the use of >> a TDMA schedule. The one thing the TDMA model supports that RF-Pipe >> does not is the concept of packet fragmentation which may be important >> to you given the size of the pipe you are emulating. >> >> >> Kaushik B. Patel >> Adjacent Link LLC >> >> > > > > _______________________________________________ emane-users mailing list [email protected] https://pf.itd.nrl.navy.mil/mailman/listinfo/emane-users
