| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In this section we are going to further expand our knowledge of ns-3
network devices and channels to cover an example of a wireless network.
Ns-3 provides a set of 802.11 models that attempt to provide an
accurate MAC-level implementation of the 802.11 specification and a
“not-so-slow” PHY-level model of the 802.11a specification.
Just as we have seen both point-to-point and CSMA topology helper objects when
constructing point-to-point topologies, we will see equivalent Wifi
topology helpers in this section. The appearance and operation of these
helpers should look quite familiar to you.
We provide an example script in our examples/tutorial directory. This script
builds on the second.cc script and adds a Wifi network. Go ahead and
open examples/tutorial/third.cc in your favorite editor. You will have already
seen enough ns-3 code to understand most of what is going on in
this example, but there are a few new things, so we will go over the entire
script and examine some of the output.
Just as in the second.cc example (and in all ns-3 examples)
the file begins with an emacs mode line and some GPL boilerplate.
Take a look at the ASCII art (reproduced below) that shows the default network
topology constructed in the example. You can see that we are going to
further extend our example by hanging a wireless network off of the left side.
Notice that this is a default network topology since you can actually vary the
number of nodes created on the wired and wireless networks. Just as in the
second.cc script case, if you change nCsma, it will give you a
number of “extra” CSMA nodes. Similarly, you can set nWifi to
control how many STA (station) nodes are created in the simulation.
There will always be one AP (access point) node on the wireless
network. By default there are three “extra” CSMA nodes and three wireless
STA nodes.
The code begins by loading module include files just as was done in the
second.cc example. There are a couple of new includes corresponding
to the Wifi module and the mobility module which we will discuss below.
#include "ns3/core-module.h" #include "ns3/simulator-module.h" #include "ns3/node-module.h" #include "ns3/helper-module.h" #include "ns3/wifi-module.h" #include "ns3/mobility-module.h"
The network topology illustration follows:
// Default Network Topology // // Wifi 10.1.3.0 // AP // * * * * // | | | | 10.1.1.0 // n5 n6 n7 n0 -------------- n1 n2 n3 n4 // point-to-point | | | | // ================ // LAN 10.1.2.0
You can see that we are adding a new network device to the node on the left side of the point-to-point link that becomes the access point for the wireless network. A number of wireless STA nodes are created to fill out the new 10.1.3.0 network as shown on the left side of the illustration.
After the illustration, the ns-3 namespace is used and a logging
component is defined. This should all be quite familiar by now.
using namespace ns3;
NS_LOG_COMPONENT_DEFINE ("ThirdScriptExample");
The main program begins just like second.cc by adding some command line
parameters for enabling or disabling logging components and for changing the
number of devices created.
bool verbose = true;
uint32_t nCsma = 3;
uint32_t nWifi = 3;
CommandLine cmd;
cmd.AddValue (``nCsma'', ``Number of \"extra\" CSMA nodes/devices'', nCsma);
cmd.AddValue (``nWifi'', ``Number of wifi STA devices'', nWifi);
cmd.AddValue (``verbose'', ``Tell echo applications to log if true'', verbose);
cmd.Parse (argc,argv);
if (verbose)
{
LogComponentEnable(``UdpEchoClientApplication'', LOG_LEVEL_INFO);
LogComponentEnable(``UdpEchoServerApplication'', LOG_LEVEL_INFO);
}
Just as in all of the previous examples, the next step is to create two nodes that we will connect via the point-to-point link.
NodeContainer p2pNodes; p2pNodes.Create (2);
Next, we see an old friend. We instantiate a PointToPointHelper and
set the associated default Attributes so that we create a five megabit
per second transmitter on devices created using the helper and a two millisecond
delay on channels created by the helper. We then Intall the devices
on the nodes and the channel between them.
PointToPointHelper pointToPoint;
pointToPoint.SetDeviceAttribute ("DataRate", StringValue ("5Mbps"));
pointToPoint.SetChannelAttribute ("Delay", StringValue ("2ms"));
NetDeviceContainer p2pDevices;
p2pDevices = pointToPoint.Install (p2pNodes);
Next, we declare another NodeContainer to hold the nodes that will be
part of the bus (CSMA) network.
NodeContainer csmaNodes; csmaNodes.Add (p2pNodes.Get (1)); csmaNodes.Create (nCsma);
The next line of code Gets the first node (as in having an index of one)
from the point-to-point node container and adds it to the container of nodes
that will get CSMA devices. The node in question is going to end up with a
point-to-point device and a CSMA device. We then create a number of “extra”
nodes that compose the remainder of the CSMA network.
We then instantiate a CsmaHelper and set its Attributes as we did
in the previous example. We create a NetDeviceContainer to keep track of
the created CSMA net devices and then we Install CSMA devices on the
selected nodes.
CsmaHelper csma;
csma.SetChannelAttribute ("DataRate", StringValue ("100Mbps"));
csma.SetChannelAttribute ("Delay", TimeValue (NanoSeconds (6560)));
NetDeviceContainer csmaDevices;
csmaDevices = csma.Install (csmaNodes);
Next, we are going to create the nodes that will be part of the Wifi network. We are going to create a number of “station” nodes as specified by the command line argument, and we are going to use the “leftmost” node of the point-to-point link as the node for the access point.
NodeContainer wifiStaNodes; wifiStaNodes.Create (nWifi); NodeContainer wifiApNode = p2pNodes.Get (0);
The next bit of code constructs the wifi devices and the interconnection channel between these wifi nodes. First, we configure the PHY and channel helpers:
YansWifiChannelHelper channel = YansWifiChannelHelper::Default (); YansWifiPhyHelper phy = YansWifiPhyHelper::Default ();
For simplicity, this code uses the default PHY layer configuration and
channel models which are documented in the API doxygen documentation for
the YansWifiChannelHelper::Default and YansWifiPhyHelper::Default
methods. Once these objects are created, we create a channel object
and associate it to our PHY layer object manager to make sure
that all the PHY layer objects created by the YansWifiPhyHelper
share the same underlying channel, that is, they share the same
wireless medium and can communication and interfere:
phy.SetChannel (channel.Create ());
Once the PHY helper is configured, we can focus on the MAC layer. Here we choose to work with non-Qos MACs so we use a NqosWifiMacHelper object to set MAC parameters.
WifiHelper wifi = WifiHelper::Default ();
wifi.SetRemoteStationManager ("ns3::AarfWifiManager");
NqosWifiMacHelper mac = NqosWifiMacHelper::Default ();
The SetRemoteStationManager method tells the helper the type of
rate control algorithm to use. Here, it is asking the helper to use the AARF
algorithm — details are, of course, available in Doxygen.
Next, we configure the type of MAC, the SSID of the infrastructure network we want to setup and make sure that our stations don’t perform active probing:
Ssid ssid = Ssid ("ns-3-ssid");
mac.SetType ("ns3::NqstaWifiMac",
"Ssid", SsidValue (ssid),
"ActiveProbing", BooleanValue (false));
This code first creates an 802.11 service set identifier (SSID) object that
will be used to set the value of the “Ssid” Attribute of the MAC
layer implementation. The particular kind of MAC layer is specified by
Attribute as being of the "ns3::NqstaWifiMac" type. This means that
the MAC will use a “non-QoS station” (nqsta) state machine. Finally, the
“ActiveProbing” Attribute is set to false. This means that probe
requests will not be sent by MACs created by this helper.
Once all the station-specific parameters are fully configured, both at the
MAC and PHY layers, we can invoke our now-familiar Install method to
create the wifi devices of these stations:
NetDeviceContainer staDevices; staDevices = wifi.Install (phy, mac, wifiStaNodes);
We have configured Wifi for all of our STA nodes, and now we need to
configure the AP (access point) node. We begin this process by changing
the default Attributes of the NqosWifiMacHelper to reflect the
requirements of the AP.
mac.SetType ("ns3::NqapWifiMac",
"Ssid", SsidValue (ssid),
"BeaconGeneration", BooleanValue (true),
"BeaconInterval", TimeValue (Seconds (2.5)));
In this case, the NqosWifiMacHelper is going to create MAC layers of the
“ns3::NqapWifiMac” (Non-Qos Access Point) type. We set the
“BeaconGeneration” Attribute to true and also set an interval between
beacons of 2.5 seconds.
The next lines create the single AP which shares the same set of PHY-level
Attributes (and channel) as the stations:
NetDeviceContainer apDevices; apDevices = wifi.Install (phy, mac, wifiApNode);
Now, we are going to add mobility models. We want the STA nodes to be mobile,
wandering around inside a bounding box, and we want to make the AP node
stationary. We use the MobilityHelper to make this easy for us.
First, we instantiate a MobilityHelper object and set some
Attributes controlling the “position allocator” functionality.
MobilityHelper mobility;
mobility.SetPositionAllocator ("ns3::GridPositionAllocator",
"MinX", DoubleValue (0.0),
"MinY", DoubleValue (0.0),
"DeltaX", DoubleValue (5.0),
"DeltaY", DoubleValue (10.0),
"GridWidth", UintegerValue (3),
"LayoutType", StringValue ("RowFirst"));
This code tells the mobility helper to use a two-dimensional grid to initially
place the STA nodes. Feel free to explore the Doxygen for class
ns3::GridPositionAllocator to see exactly what is being done.
We have arranged our nodes on an initial grid, but now we need to tell them
how to move. We choose the RandomWalk2dMobilityModel which has the
nodes move in a random direction at a random speed around inside a bounding
box.
mobility.SetMobilityModel ("ns3::RandomWalk2dMobilityModel",
"Bounds", RectangleValue (Rectangle (-50, 50, -50, 50)));
We now tell the MobilityHelper to install the mobility models on the
STA nodes.
mobility.Install (wifiStaNodes);
We want the access point to remain in a fixed position during the simulation.
We accomplish this by setting the mobility model for this node to be the
ns3::ConstantPositionMobilityModel:
mobility.SetMobilityModel ("ns3::ConstantPositionMobilityModel");
mobility.Install (wifiApNode);
We now have our nodes, devices and channels created, and mobility models
chosen for the Wifi nodes, but we have no protocol stacks present. Just as
we have done previously many times, we will use the InternetStackHelper
to install these stacks.
InternetStackHelper stack; stack.Install (csmaNodes); stack.Install (wifiApNode); stack.Install (wifiStaNodes);
Just as in the second.cc example script, we are going to use the
Ipv4AddressHelper to assign IP addresses to our device interfaces.
First we use the network 10.1.1.0 to create the two addresses needed for our
two point-to-point devices. Then we use network 10.1.2.0 to assign addresses
to the CSMA network and then we assign addresses from network 10.1.3.0 to
both the STA devices and the AP on the wireless network.
Ipv4AddressHelper address;
address.SetBase ("10.1.1.0", "255.255.255.0");
Ipv4InterfaceContainer p2pInterfaces;
p2pInterfaces = address.Assign (p2pDevices);
address.SetBase ("10.1.2.0", "255.255.255.0");
Ipv4InterfaceContainer csmaInterfaces;
csmaInterfaces = address.Assign (csmaDevices);
address.SetBase ("10.1.3.0", "255.255.255.0");
address.Assign (staDevices);
address.Assign (apDevices);
We put the echo server on the “rightmost” node in the illustration at the start of the file. We have done this before.
UdpEchoServerHelper echoServer (9); ApplicationContainer serverApps = echoServer.Install (csmaNodes.Get (nCsma)); serverApps.Start (Seconds (1.0)); serverApps.Stop (Seconds (10.0));
And we put the echo client on the last STA node we created, pointing it to the server on the CSMA network. We have also seen similar operations before.
UdpEchoClientHelper echoClient (csmaInterfaces.GetAddress (nCsma), 9);
echoClient.SetAttribute ("MaxPackets", UintegerValue (1));
echoClient.SetAttribute ("Interval", TimeValue (Seconds (1.)));
echoClient.SetAttribute ("PacketSize", UintegerValue (1024));
ApplicationContainer clientApps =
echoClient.Install (wifiStaNodes.Get (nWifi - 1));
clientApps.Start (Seconds (2.0));
clientApps.Stop (Seconds (10.0));
Since we have built an internetwork here, we need to enable internetwork routing
just as we did in the second.cc example script.
Ipv4GlobalRoutingHelper::PopulateRoutingTables ();
One thing that can surprise some users is the fact that the simulation we just created will never “naturally” stop. This is because we asked the wireless access point to generate beacons. It will generate beacons forever, and this will result in simulator events being scheduled into the future indefinitely, so we must tell the simulator to stop even though it may have beacon generation events scheduled. The following line of code tells the simulator to stop so that we don’t simulate beacons forever and enter what is essentially an endless loop.
Simulator::Stop (Seconds (10.0));
We create just enough tracing to cover all three networks:
pointToPoint.EnablePcapAll ("third");
phy.EnablePcap ("third", apDevices.Get (0));
csma.EnablePcap ("third", csmaDevices.Get (0), true);
These three lines of code will start pcap tracing on both of the point-to-point nodes that serves as our backbone, will start a promiscuous (monitor) mode trace on the Wifi network, and will start a promiscuous trace on the CSMA network. This will let us see all of the traffic with a minimum number of trace files.
Finally, we actually run the simulation, clean up and then exit the program.
Simulator::Run ();
Simulator::Destroy ();
return 0;
}
In order to run this example, you have to copy the third.cc example
script into the scratch directory and use Waf to build just as you did with
the second.cc example. If you are in the top-level directory of the
repository you would type,
cp examples/third.cc scratch/mythird.cc ./waf ./waf --run scratch/mythird
Again, since we have set up the UDP echo applications just as we did in the
second.cc script, you will see similar output.
Waf: Entering directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone/ns-3-dev/build' 'build' finished successfully (0.407s) Sent 1024 bytes to 10.1.2.4 Received 1024 bytes from 10.1.3.3 Received 1024 bytes from 10.1.2.4
Recall that the first message, “Sent 1024 bytes to 10.1.2.4,” is the
UDP echo client sending a packet to the server. In this case, the client
is on the wireless network (10.1.3.0). The second message,
“Received 1024 bytes from 10.1.3.3,” is from the UDP echo server,
generated when it receives the echo packet. The final message,
“Received 1024 bytes from 10.1.2.4,” is from the echo client, indicating
that it has received its echo back from the server.
If you now go and look in the top level directory, you will find four trace files from this simulation, two from node zero and two from node one:
third-0-0.pcap third-0-1.pcap third-1-0.pcap third-1-1.pcap
The file “third-0-0.pcap” corresponds to the point-to-point device on node zero – the left side of the “backbone”. The file “third-1-0.pcap” corresponds to the point-to-point device on node one – the right side of the “backbone”. The file “third-0-1.pcap” will be the promiscuous (monitor mode) trace from the Wifi network and the file “third-1-1.pcap” will be the promiscuous trace from the CSMA network. Can you verify this by inspecting the code?
Since the echo client is on the Wifi network, let’s start there. Let’s take a look at the promiscuous (monitor mode) trace we captured on that network.
tcpdump -nn -tt -r third-0-1.pcap
You should see some wifi-looking contents you haven’t seen here before:
reading from file third-0-1.pcap, link-type IEEE802_11 (802.11) 0.000025 Beacon () [6.0* 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] IBSS 0.000263 Assoc Request () [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] 0.000279 Acknowledgment RA:00:00:00:00:00:07 0.000357 Assoc Response AID(0) :: Succesful 0.000501 Acknowledgment RA:00:00:00:00:00:0a 0.000748 Assoc Request () [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] 0.000764 Acknowledgment RA:00:00:00:00:00:08 0.000842 Assoc Response AID(0) :: Succesful 0.000986 Acknowledgment RA:00:00:00:00:00:0a 0.001242 Assoc Request () [6.0 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] 0.001258 Acknowledgment RA:00:00:00:00:00:09 0.001336 Assoc Response AID(0) :: Succesful 0.001480 Acknowledgment RA:00:00:00:00:00:0a 2.000112 arp who-has 10.1.3.4 (ff:ff:ff:ff:ff:ff) tell 10.1.3.3 2.000128 Acknowledgment RA:00:00:00:00:00:09 2.000206 arp who-has 10.1.3.4 (ff:ff:ff:ff:ff:ff) tell 10.1.3.3 2.000487 arp reply 10.1.3.4 is-at 00:00:00:00:00:0a 2.000659 Acknowledgment RA:00:00:00:00:00:0a 2.002169 IP 10.1.3.3.49153 > 10.1.2.4.9: UDP, length 1024 2.002185 Acknowledgment RA:00:00:00:00:00:09 2.009771 arp who-has 10.1.3.3 (ff:ff:ff:ff:ff:ff) tell 10.1.3.4 2.010029 arp reply 10.1.3.3 is-at 00:00:00:00:00:09 2.010045 Acknowledgment RA:00:00:00:00:00:09 2.010231 IP 10.1.2.4.9 > 10.1.3.3.49153: UDP, length 1024 2.011767 Acknowledgment RA:00:00:00:00:00:0a 2.500000 Beacon () [6.0* 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] IBSS 5.000000 Beacon () [6.0* 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] IBSS 7.500000 Beacon () [6.0* 9.0 12.0 18.0 24.0 36.0 48.0 54.0 Mbit] IBSS
You can see that the link type is now 802.11 as you would expect. You can probably understand what is going on and find the IP echo request and response packets in this trace. We leave it as an exercise to completely parse the trace dump.
Now, look at the pcap file of the right side of the point-to-point link,
tcpdump -nn -tt -r third-0-0.pcap
Again, you should see some familiar looking contents:
reading from file third-0-0.pcap, link-type PPP (PPP) 2.002169 IP 10.1.3.3.49153 > 10.1.2.4.9: UDP, length 1024 2.009771 IP 10.1.2.4.9 > 10.1.3.3.49153: UDP, length 1024
This is the echo packet going from left to right (from Wifi to CSMA) and back again across the point-to-point link.
Now, look at the pcap file of the right side of the point-to-point link,
tcpdump -nn -tt -r third-1-0.pcap
Again, you should see some familiar looking contents:
reading from file third-1-0.pcap, link-type PPP (PPP) 2.005855 IP 10.1.3.3.49153 > 10.1.2.4.9: UDP, length 1024 2.006084 IP 10.1.2.4.9 > 10.1.3.3.49153: UDP, length 1024
This is also the echo packet going from left to right (from Wifi to CSMA) and back again across the point-to-point link with slightly different timings as you might expect.
The echo server is on the CSMA network, let’s look at the promiscuous trace there:
tcpdump -nn -tt -r third-1-1.pcap
You should see some familiar looking contents:
reading from file third-1-1.pcap, link-type EN10MB (Ethernet) 2.005855 arp who-has 10.1.2.4 (ff:ff:ff:ff:ff:ff) tell 10.1.2.1 2.005877 arp reply 10.1.2.4 is-at 00:00:00:00:00:06 2.005877 IP 10.1.3.3.49153 > 10.1.2.4.9: UDP, length 1024 2.005980 arp who-has 10.1.2.1 (ff:ff:ff:ff:ff:ff) tell 10.1.2.4 2.005980 arp reply 10.1.2.1 is-at 00:00:00:00:00:03 2.006084 IP 10.1.2.4.9 > 10.1.3.3.49153: UDP, length 1024
This should be easily understood. If you’ve forgotten, go back and look at
the discussion in second.cc. This is the same sequence.
Now, we spent a lot of time setting up mobility models for the wireless network
and so it would be a shame to finish up without even showing that the STA
nodes are actually moving around during the simulation. Let’s do this by hooking
into the MobilityModel course change trace source. This is just a sneak
peek into the detailed tracing section which is coming up, but this seems a very
nice place to get an example in.
As mentioned in the “Tweaking ns-3” section, the ns-3 tracing system
is divided into trace sources and trace sinks, and we provide functions to
connect the two. We will use the mobility model predefined course change
trace source to originate the trace events. We will need to write a trace
sink to connect to that source that will display some pretty information for
us. Despite its reputation as being difficult, it’s really quite simple.
Just before the main program of the scratch/mythird.cc script, add the
following function:
void
CourseChange (std::string context, Ptr<const MobilityModel> model)
{
Vector position = model->GetPosition ();
NS_LOG_UNCOND (context <<
" x = " << position.x << ", y = " << position.y);
}
This code just pulls the position information from the mobility model and
unconditionally logs the x and y position of the node. We are
going to arrange for this function to be called every time the wireless
node with the echo client changes its position. We do this using the
Config::Connect function. Add the following lines of code to the
script just before the Simulator::Run call.
std::ostringstream oss;
oss <<
"/NodeList/" << wifiStaNodes.Get (nWifi - 1)->GetId () <<
"/$ns3::MobilityModel/CourseChange";
Config::Connect (oss.str (), MakeCallback (&CourseChange));
What we do here is to create a string containing the tracing namespace path
of the event to which we want to connect. First, we have to figure out which
node it is we want using the GetId method as described earlier. In the
case of the default number of CSMA and wireless nodes, this turns out to be
node seven and the tracing namespace path to the mobility model would look
like,
/NodeList/7/$ns3::MobilityModel/CourseChange
Based on the discussion in the tracing section, you may infer that this trace
path references the seventh node in the global NodeList. It specifies
what is called an aggregated object of type ns3::MobilityModel. The
dollar sign prefix implies that the MobilityModel is aggregated to node seven.
The last component of the path means that we are hooking into the
“CourseChange” event of that model.
We make a connection between the trace source in node seven with our trace
sink by calling Config::Connect and passing this namespace path. Once
this is done, every course change event on node seven will be hooked into our
trace sink, which will in turn print out the new position.
If you now run the simulation, you will see the course changes displayed as they happen.
Build finished successfully (00:00:01) /NodeList/7/$ns3::MobilityModel/CourseChange x = 10, y = 0 /NodeList/7/$ns3::MobilityModel/CourseChange x = 9.41539, y = -0.811313 /NodeList/7/$ns3::MobilityModel/CourseChange x = 8.46199, y = -1.11303 /NodeList/7/$ns3::MobilityModel/CourseChange x = 7.52738, y = -1.46869 /NodeList/7/$ns3::MobilityModel/CourseChange x = 6.67099, y = -1.98503 /NodeList/7/$ns3::MobilityModel/CourseChange x = 5.6835, y = -2.14268 /NodeList/7/$ns3::MobilityModel/CourseChange x = 4.70932, y = -1.91689 Sent 1024 bytes to 10.1.2.4 Received 1024 bytes from 10.1.3.3 Received 1024 bytes from 10.1.2.4 /NodeList/7/$ns3::MobilityModel/CourseChange x = 5.53175, y = -2.48576 /NodeList/7/$ns3::MobilityModel/CourseChange x = 4.58021, y = -2.17821 /NodeList/7/$ns3::MobilityModel/CourseChange x = 4.18915, y = -1.25785 /NodeList/7/$ns3::MobilityModel/CourseChange x = 4.7572, y = -0.434856 /NodeList/7/$ns3::MobilityModel/CourseChange x = 4.62404, y = 0.556238 /NodeList/7/$ns3::MobilityModel/CourseChange x = 4.74127, y = 1.54934 /NodeList/7/$ns3::MobilityModel/CourseChange x = 5.73934, y = 1.48729 /NodeList/7/$ns3::MobilityModel/CourseChange x = 6.18521, y = 0.59219 /NodeList/7/$ns3::MobilityModel/CourseChange x = 6.58121, y = 1.51044 /NodeList/7/$ns3::MobilityModel/CourseChange x = 7.27897, y = 2.22677 /NodeList/7/$ns3::MobilityModel/CourseChange x = 6.42888, y = 1.70014 /NodeList/7/$ns3::MobilityModel/CourseChange x = 7.40519, y = 1.91654 /NodeList/7/$ns3::MobilityModel/CourseChange x = 6.51981, y = 1.45166 /NodeList/7/$ns3::MobilityModel/CourseChange x = 7.34588, y = 2.01523 /NodeList/7/$ns3::MobilityModel/CourseChange x = 7.81046, y = 2.90077 /NodeList/7/$ns3::MobilityModel/CourseChange x = 6.89186, y = 3.29596 /NodeList/7/$ns3::MobilityModel/CourseChange x = 7.46617, y = 2.47732 /NodeList/7/$ns3::MobilityModel/CourseChange x = 7.05492, y = 1.56579 /NodeList/7/$ns3::MobilityModel/CourseChange x = 8.00393, y = 1.25054 /NodeList/7/$ns3::MobilityModel/CourseChange x = 7.00968, y = 1.35768 /NodeList/7/$ns3::MobilityModel/CourseChange x = 7.33503, y = 2.30328 /NodeList/7/$ns3::MobilityModel/CourseChange x = 7.18682, y = 3.29223 /NodeList/7/$ns3::MobilityModel/CourseChange x = 7.96865, y = 2.66873
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] |
This document was generated on August 20, 2010 using texi2html 1.82.