Subject: [manet] About IEEE802.11 model in OPNET

From: "danaus" <[email-masked]>
Date: Tue, 26 Mar 2002 12:43:23 +0800

Hi,

Is there anyone here familiar with the IEEE 802.11 model in OPNET 8.0.C ?
I encounter a strange problem when I make the following simulation using OPNET:
--------------
WLAN Scenarios 1:
Two wlan_station_adv(fix) nodes in a 500m X 500m rectangle area,
each node random selects a destination and transmits some packets.

WLAN Scenarios 2:
Same configured as the above Scenarios 1 except that the number of 
nodes is twenty.
--------------
I have expected that one node's throughput in Scenarios 2 should
much lower than that in Scenarios 1. But the simulation results
show that the throughput of each node is as same as that in 
Scenarios 1. The more eighteen nodes in Scenarios 2 seem do nothing.

Could any one tell me why the nodes in Scenarios 2 don't make 
interference to each other. 

Thanks a lot.

Sincerely, 
aaron

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Vikram Dham" <[email-masked]>
Date: Tue, 26 Mar 2002 16:28:35 -0500

Hi Aaaron,

I  have been using OPNET's 802.11 model for simulating manet scenarios. Make
sure that you are correctly setting the value of the range attribute.

Regards

Vikram Dham

---

From: "Vikram Dham" <[email-masked]>
Date: Tue, 26 Mar 2002 16:28:35 -0500

Hi Aaaron,

Regards

Vikram Dham

---

From: Leonard Miller <[email-masked]>
Date: Tue, 26 Mar 2002 16:36:25 -0500

Aaron,

You say nothing about the packet rate!!  It is entirely possible that 20
or more nodes can operate in a WLAN up to a certain level of traffic.

Regards,
L. E. Miller

-- 

._.. . _.   __ .. ._.. ._.. . ._.   ._ _   _. .. ... _

Leonard E. Miller, Wireless Commun. Technologies Group
    National Institute of Standards & Technology (NIST)
    100 Bureau Drive Stop 8920, Bldg. 820, Room 445
    Gaithersburg, Maryland 20899-8920
Phone: 301-975-8018        Fax: 301-590-0932
email: [email-masked], [email-masked]
http://w3.antd.nist.gov/wctg/
._ _. ._ ._.. _.__ ... .. ...   ._ _. _..  ... .. __ .._
._.. ._ _ .. ___ _. ___...   .__ .. ._. . ._.. . ... ...

---

From: Leonard Miller <[email-masked]>
Date: Tue, 26 Mar 2002 16:36:25 -0500

Aaron,

Regards,
L. E. Miller

--

---

From: Rajesh Bhairampally <[email-masked]>
Date: Tue, 26 Mar 2002 18:40:19 -0600 (CST)

if i am not wrong, Opnet WLAN defines throughput as "total number of bits
(in bits/sec) forwarded from wireless LAN layers to higher layers". so, it
is possible that all the stations eventually get access to media and
transfer their data. So, i think it is entairely possible that throughput
be same in both the cases.

to really look into the affect of additional stations, you can look into
other statistics such as  media access delay, number of backoffslots,
end-end dealy, -may be- control traffic exchanged b/n nodes. this may give
you a feel of how other stations are contending for media.

hth,
Rajesh

> I encounter a strange problem when I make the following simulation using OPNET:

Rajesh

---

From: Rajesh Bhairampally <[email-masked]>
Date: Tue, 26 Mar 2002 18:40:19 -0600 (CST)

hth,
Rajesh

Rajesh

---

From: John Stine <[email-masked]>
Date: Wed, 27 Mar 2002 09:12:11 -0500

Opnet's wlan_mac and the support pipeline stages take some liberty in
modeling the physical layer based on the assumption that in the intended
network all nodes should be within range of each other.  As a result,
the model does not model interference correctly, but uses collisions
only as the cause of failure.  This is a severe problem when one is
studying ad hoc networking and wants to evaluate spatial reuse of the
channel.  Two nodes in a network cannot successfully transmit
simultaneously, despite separation distance.  We addressed this problem
in our modifications to OPNET's models for Kevin Grace's MobileMesh
protocols.  You should have received a message from Kevin about the
release of these models.  If you did not receive it, the text of Kevin's
message follows.

The OPNET models are for version 7.0.B but they are well documented so
with a little effort one can apply the changes to the 8.0.C version.  We
provided these models to OPNET and they have given us the indication
that they will incorporate our recommendations into a future release of
their product.

In the mean time, I would recommend anyone using the OPNET wlan_mac
model to study ad hoc networks to look at our observations and
recommendations. (See Readme-MobileMeshOpnet.pdf.)  Many conclusions
based on modeling in OPNET may need to be re-evaluated.

John

Kevin's message follows:

Opnet simulation models of the MobileMesh Routing Protocol and
MobileMesh Link Discovery Protocol are now available from Opnet's
website:

 ftp://opguest:[email-masked]/433/

Included in this distribution are numerous modifications and bug fixes
to the 802.11 wireless LAN process model and related pipeline
stages. 

Please refer to the file "Readme-MobileMeshOpnet.pdf" in the
distribution for more details.

Information about the MobileMesh protocols and Open Source Linux
distribution 
is available at:

 http://www.mitre.org/tech_transfer/mobilemesh/

-Kevin

---

From: John Stine <[email-masked]>
Date: Wed, 27 Mar 2002 09:12:11 -0500

John

Kevin's message follows:

-Kevin

---

From: "Vikram Dham" <[email-masked]>
Date: Wed, 27 Mar 2002 15:40:07 -0500

Dear John & Kevin:

   I agree with your pointers regarding pipeline stage.I would like to add
that instead of setting value of signal lock  & packet status at
manta_power.ps.c, you can move it to manta_snr.ps.c stage to determine
whether signal lock should be set or not and whether the packet is to be
stamped as *noise* or *valid* packet. This would take into account
interference due to other nodes without need for maintaining any additional
data structure.  For doing this you will have to maintain an additional TDA
RCV_FLAG  which should be set during the first pass of the packet through
the manta_snr.ps.c stage.

I hope the above helps.

With Best Regards

Vikram Dham
Graduate Research Assistant
Alexandria Research Institute
Virginia Tech,USA

---

From: "Vikram Dham" <[email-masked]>
Date: Wed, 27 Mar 2002 15:40:07 -0500

Dear John & Kevin:

I hope the above helps.

With Best Regards

Vikram Dham

---

From: John Stine <[email-masked]>
Date: Wed, 27 Mar 2002 16:54:14 -0500

Dear Vikram,

	This was our first instinct but the OPNET kernel does not allow it. 
The issue is, when is the latest you can set a packet's status to
noise.  The answer is the power stage.  Below is the text of a message I
got from OPNET technical support when I asked this question.  I called
after I noticed my simulation didn't work when I waited until the SNR
stage to set the sig_lock attribute and the match status.

*** TEXT OF MESSAGE FROM OPNET
SUPPORT************************************

It sounds like you are setting OPC_TDA_RA_MATCH_STATUS to .._NOISE in
the 
SNR stage. The kernel expects the MATCH_STATUS TDA to be set at the
latest 
by the power stage, and therefore, modifying it in the SNR stage may
result 
in unexplained behaviour, including possibly the abort that you observe.
At 
any rate, changing the TDA in the SNR stage will not prevent the kernel 
from invoking the following stages (ber, etc.) because the kernel will 
still treat it as a valid packet. 

Therefore, we suggest that you try another approach to achieve the same 
goal. For example, you could mark all potential packets as VALID in the 
power stage and define your own TDA called "MY_MATCH_STATUS" and set
this 
to noise in the SNR stage if the conditions so dictate. However, since
the 
kernel does not know about this TDA, all the stages following the SNR 
stage, i.e., ber, error, ecc will still be invoked by the kernel for
this 
packet that has its MY_MATCH_STATUS TDA set to NOISE. Therefore, you
will 
have to access this TDA in the last few stages and immediately exit
using a 
FOUT if the MY_MATCH_STATUS is set to NOISE. 

*******************************************************************************

So it may be possible to use the SNR but not without an additional data
structure to keep track of which packets are valid.  Since I cannot see
what happens inside the kernel I decided not to circumvent OPNET's
plan.  Not modeling signal lock based on SNR has little effect in the
performance of the model.  If SNR is a factor, the newly arriving packet
that we lock onto is likely to have errors and not be accepted. If we
successfully account for SNR, the duration of this packet would be
sensed as a busy channel.   So, in both cases, the effect on the
receiving node is the same.

John

---

From: John Stine <[email-masked]>
Date: Wed, 27 Mar 2002 16:54:14 -0500

Dear Vikram,

John