대학원부터 시작한 첫번째 블로그

[펌] NS-2 유용한 site 모음

As mentioned in the overview section, NS is basically an OTcl interpreter with network simulation object libraries. It is very useful to know how to program in OTcl to use NS. This section shows an example Tcl and OTcl script, from which one can get the basic idea of programming in OTcl. These examples are from the 5th VINT/NS Simulation Tutorial/Workshop. This section and the sections after assumes that the reader installed NS, and is familiar with C and C++.

Example 1 is a general Tcl script that shows how to create a procedure and call it, how to assign values to variables, and how to make a loop. Knowing that OTcl is Object-orieneted extension of Tcl, it is obvious that all Tcl commands work on OTcl - the relationship between Tcl and Otcl is just same as C and C++. To run this script you should download ex-tcl.tcl, and type "ns ex-tcl.tcl" at your shell prompt - the command "ns" starts the NS (an OTcl interpreter). You will also get the same results if you type "tcl ex-tcl.tcl", if tcl8.0 is installed in your machine.

Example 1. A Sample Tcl Script

In Tcl, the keyword proc is used to define a procedure, followed by an procedure name and arguments in curly brackets. The keyword set is used to assign a value to a variable. [expr ...] is to make the interpreter calculate the value of expression within the bracket after the keyword. One thing to note is that to get the value assigned to a variable, $ is used with the variable name. The keyword puts prints out the following string within double quotation marks. The following shows the result of Example 1.

The next example is an object-oriented programming example in OTcl. This example is very simple, but shows the way which an object is created and used in OTcl. As an ordinary NS user, the chances that you will write your own object might be rare. However, since all of the NS objects that you will use in a NS simulation programming, whether or not they are written in C++ and made available to OTcl via the linkage or written only in OTcl, are essentially OTcl objects, understanding OTcl object is helpful.

Example 2. A Sample OTcl Script

Example 2 is an OTcl script that defines two object classes, "mom" and "kid", where "kid" is the child class of "mom", and a member function called "greet" for each class. After the class definitions, each object instance is declared, the "age" variable of each instance is set to 45 (for mom) and 15 (for kid), and the "greet" member function of each object instance is called. The keyword Class is to create an object class and instproc is to define a member function to an object class. Class inheritance is specified using the keyword -superclass. In defining member functions, $self acts same as the "this" pointer in C++, and instvar checks if the following variable name is already declared in its class or in its superclass. If the variable name given is already declared, the variable is referenced, if not a new one is declared. Finally, to create an object instance, the keyword new is used as shown in the example. Downloading ex-otcl.tcl and executing "ns ex-otcl.tcl" will give you the following result:

• To: ns-users@mash.CS.Berkeley.EDU, "'scao@lerc.nasa.gov'" <scao@lerc.nasa.gov>
• Subject: R:[ns] Route to base_stn not known: dropping pkt
• From: Bordes Marta <Marta.Bordes@CSELT.IT>
• Date: Thu, 01 Jun 2000 18:33:46 +0200
• Sender: owner-ns-users@mash.CS.Berkeley.EDU

Hello,

The message "warning:Route to base_stn not known: dropping pkt" is generated
by the mobile node's DSDV agent (see ns/dsdv/dsdv.cc). DSDV agent always
tries to send packets to the base station referred in the variable base_stn_
of the class MobileNode (see ns/mobilenode.cc). In wireless3.tcl, with the
instruction

set HAaddress [AddrParams set-hieraddr [$HA node-addr]]
[$MH set regagent_] set home_agent_ $HAaddress

we set base_stn_ with the address of the home agent.

When the mobile node performs a handoff, after receiving a new agent
advertisement (from the foreign agent), it modifies the value of base_stn_
with the address of the foreign agent (see mip-reg.cc).

The warning message is caused because the mobile node is trying to send a
packet (probably an acknowledgement to a received TCP packet) to the old
base station, but it is not under its coverage area and it has not updated
the value of base_stn_ yet. 

I hope it helps,

Making NS-2 simulate an 802.11b link
Last update: 4-29-05
Joshua Robinson
jpr -at- rice.edu

For a research project I worked on in 2004 (resulting paper here), I used two Netgear MA311 cards to create a simple ad hoc connection. These cards are 802.11b PCI cards, stuck in the back of brand new dell workstations. I did some simple throughput tests using netperf, and found that my results differed significantly from what NS told me.

So I set about to figure out why things were different and what needed to be done to sync the results. I'll quickly explain my findings as it wasn't a complex process. Skip to here if you want to see my actual results.

First, I'm assuming version 2.27 or newer here. If you're using older versions, some things will be different and I'll try to point them out if I can. If you're using a newer version, then things will likely also be different, but I've unfortunately stopped work on Ns-2 since 2005.

Data Rate
NS, by default, has the data rate for the MAC set at 2 Mbps. But cards are faster now. My cards are 802.11b, which means they're 11 Mbps, and so we need to change this. Add the following to the beginning of your simulation script:
Mac/802_11 set dataRate_ 11Mb

The card can send at 1, 2, 5.5, or 11 Mbps. Most cards support some kind of ARF (Auto-Rate Fallback) for automatic rate selection between these choices. ARF basically seems to be a slow-timescale feedback mechanism. If there are a lot of packet errors, ARF will step down the rate, and conversely, if there are no errors then the rate will be increased. I'm not explaining this in detail because NS doesn't support any multi-rate functionality by default. That means mobile nodes will always send their packets at dataRate_. So if you really want to be realistic, you need to support this somehow. I didn't.

RTS Threshold
Almost all commercial 802.11b cards have the RTS/CTS exchange turned off by default. This is not a bad decision since I think most people's home wlan networks are simple enough so that the RTS/CTS really is just unnecessary overhead. NS by default has this feature turned on, so we probably want to tell NS not to use this feature. Add this line to the beginning of your script:
Mac/802_11 set RTSThreshold_ 3000

This means that an RTS will only be sent for packets that are bigger than 3000 bytes, which should be never. Note: if you want RTS/CTS on, then set this value to zero.

Preamble
I think this is probably the least obvious modification so I'll try to be a little more detailed. Every packet is sent with a preamble, which is just a known pattern of bits at the beginning of the packet so that the receiver can sync up and be ready for the real data. This preamble must be sent at the basic rate (1 Mbps), according to the official standard. But there are two different kinds of preambles, short and long - referring to the length of the sync field. The long preamble has a field size of 128 bits, while the short preamble is only 56 bits. I would guess this short preamble option came about as hardware progressed and transceivers got better at locking on to a signal. NS is set by default to use the long preamble. My cards use the short preamble by default, and unfortunately, I don't know a good way to determine if your card is using long or short preambles. Email me if you have any ideas.

To support short preambles in NS, add the following line at the beginning of your script:
Mac/802_11 set PreambleLength_ 72
Note: there are 16 other bits in the preamble that aren't affected by the short/long distinction. To go back to long, change this value to 144.

The ChannelAbove is everything you need to simulate an 802.11b card accurately (at least more accurately than the default NS does), but there's still a big assumption in NS - that's the wireless channel model. Currently the received power of a packet only depends on the distance between sender and receiver. But in real life, there are a lot of other factors influencing received power. And if you want a realistic simulation, you need to simulate this. I would suggest going here to find out more information about a more realistic channel fading model.

Packet SizeThere is a slightly annoying default setting in many versions of ns that makes your packet size not what you think it is. The default setting is this:
Agent/UDP set packetSize_ 1000
Which means that if you try to set your UDP packet size to greater than this, it will actually split up each packet into two smaller ones. You really want this line:
Agent/UDP set packetSize_ 1500
If you are not sure if this is a problem, I would recommend checking the packet sizes in your trace file. If you see the wrong packet sizes, this is most likely the problem.

ResultsThe table below shows achieved UDP throughput in Mbps.

As you can see, the simulation results are very close to the real results I obtained. In fact, I believe that they are close enough so that the difference can be entirely accounted for by the randomness of the CSMA MAC.

Note that I have not actually worked on this project or Ns-2 for several years, so I'm sure things have changed and I can't guarantee that this will still work.

Back