-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFPipe PCR curve issue #238
Comments
The RF Pipe model is a very simplistic model that does not account for
interference due to in-band collisions from multiple transmitters. You
can update the model to add that feature or develop a new model that
supports the specific channel access effects and features you are
looking to emulate. Feel free to review existing opensource models
(TDMA, IEEE802.11abg, LTE) which account for in-band collisions with
their own unique implementations.
The linear PCR curve provided is simply as a place holder and can be
replaced with a curve which represents your waveform's behavior.
Also, the documentation for PCR states the following:
"Specifying a packet size (<table> attribute pktsize) in the curve file
will adjust the POR based on received packet size. Specifying a pktsize
of 0 disregards received packet size when computing the POR."
So, if you want completion rates to change based on packet size, you
have to set the packet size to a non-zero value and make sure the curve
is representative of that non-zero packet size you set.
kb
Kaushik B. Patel
Adjacent Link LLC
…On 6/13/23 02:41, ijamc756 wrote:
I used RF Pipe model and transmitted two radio links simultaneously to
see how they interfere with each other. Unfortunately, they did not
interfere with each other. The rx success rate was 100%.
For this test, all radios used similar parameters such as Bandwidth 8M,
NoiseFigure 4dB, tx power 0 dBm using emane-tutorial/demo 5.
I also realised the PCR curve for RF Pipe is a straight line slope and
based on packet size 0. It makes it difficult to estimate POR using
POR0^(s1/s0) formula.
What changes should I make to successfully test the interference between
two RF Pipe links and resolve the PCR issue?
—
Reply to this email directly, view it on GitHub
<#238>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABPLXMY4BMZ3CNYZWEOUNWDXLADRLANCNFSM6AAAAAAZELYX6A>.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Hi, I am new to EMANE, please correct me if I am wrong. You say, 'Specifying a pktsize of 0 disregards received packet size when computing the POR.' Why does tutorial 1 run with success rate of 100% with default pktsize 0 under /usr/share/emane/xml/models/mac/rfpipe/rfpipepcr.xml? or is the pktsize defined elsewhere? Grateful if you could clarify please? |
Disregarding packet size in this reference means the same PCR curve is
used regardless of the actual packet size that is received. So, when
"pktsize" is set to 0 in the curve file, you are basically telling the
receiving node to compute the PCR based on the received SINR only.
Again, if you look at the documentation, it states the following:
"The POR is obtained using the following calculation when a non-zero
pktsize is specified: POR = POR0^(S1/S0)"
So what that means is, if you specify a packet size of 0 in your curve
file, your POR will always be POR0 obtained from your curve file for the
received/computed SINR. Whether you send a 100 byte packet or a 1000
byte packet, the POR will be the same if the SINR is the same.
It might be worthwhile for you to try the following simple tests using 2
nodes:
Test-1:
1. Use the default curve file with "pktsize" set to 0.
2. Adjust the pathloss between two nodes so the SINR = 10.
3. Send a stream of 100 byte packets and see what your completion rate
looks like.
4. Send a stream of 1000 byte packets and see if the completion rate
changes. Hint: It should not.
Test-2:
1. Change the "pktsize" parameter in your curve file to 128 Bytes.
2. Keep the pathloss from above so the SINR = 10.
3. Send a stream of 100 byte packets and see what your completion rate
looks like.
4. Send a stream of 1000 byte packets and see if the completion rate
changes. Hint: It should based on the above POR formula.
kb
Kaushik B. Patel
Adjacent Link LLC
CEO, Director of Engineering
908.655.5079
***@***.***
…On 6/13/23 16:43, dax0922 wrote:
Hi, I am new to EMANE, please correct me if I am wrong. You say,
'Specifying a pktsize of 0 disregards received packet size when
computing the POR.' Why does tutorial 1 run with success rate of 100%
with default pktsize 0 under
/usr/share/emane/xml/models/mac/rfpipe/rfpipepcr.xml? or is the pktsize
defined elsewhere? Grateful if you could clarify please?
—
Reply to this email directly, view it on GitHub
<#238 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPLXM2XCQ3ZOODST6E2JA3XLDGFNANCNFSM6AAAAAAZELYX6A>.
You are receiving this because you commented.Message ID:
***@***.***>
|
Thank you very much for the quick response, appreciate it. I will give it a try. |
I have another question please if I may- the PCR curve xml files for TDMA and 802.11 have exactly same numbers (POR and SINR), are they supposed to be same or is there a reason for similar numbers for SINR and POR values? |
I used RF Pipe model and transmitted two radio links simultaneously to see how they interfere with each other. Unfortunately, they did not interfere with each other. The rx success rate was 100%.
For this test, all radios used similar parameters such as Bandwidth 8M, NoiseFigure 4dB, tx power 0 dBm using emane-tutorial/demo 5.
I also realised the PCR curve for RF Pipe is a straight line slope and based on packet size 0. It makes it difficult to estimate POR using POR0^(s1/s0) formula.
What changes should I make to successfully test the interference between two RF Pipe links and resolve the PCR issue?
The text was updated successfully, but these errors were encountered: