mobility.tex

对IEEE 802.11e里的分布式信道接入算法EDCA进行改进

The above function calls different format functions depending on the type
of the packet being traced. All traces are written to the buffer wrk\_. A
count of the offset for the buffer is kept and is passed along the
different trace functions. The most basic format is defined by
format\_mac() and is used to trace all pkt types. The other format
functions print additional information as defined by the packet types. The
mac format prints the following:   
\begin{program}
\#ifdef LOG_POSITION
        double x = 0.0, y = 0.0, z = 0.0;
        node_->getLoc(&x, &y, &z);
\#endif

        sprintf(wrk_ + offset,
\#ifdef LOG_POSITION
                "%c %.9f %d (%6.2f %6.2f) %3s %4s %d %s %d [%x %x %x %x] ",
\#else
                "%c %.9f _%d_ %3s %4s %d %s %d [%x %x %x %x] ",
\#endif
                op,                    // s, r, D or f
                Scheduler::instance().clock(),  // time stamp
                src_,                  // the nodeid for this node
\#ifdef LOG_POSITION
                x,                     // x co-ord 
                y,                     // y co-ord
\#endif
                tracename,             // name of object type tracing
                why,                   // reason, if any

                ch->uid(),             // identifier for this event
                packet_info.name(ch->ptype()), // packet type
                ch->size(),                    // size of cmn header
                mh->dh_duration,       // expected time to send data 
                ETHER_ADDR(mh->dh_da), // mac_destination address
                ETHER_ADDR(mh->dh_sa),         // mac_sender address
                GET_ETHER_TYPE(mh->dh_body));  // type - arp or IP
\end{program}

If the LOG\_POSITION is defined the x and y co-ordinates for the
mobilenode is also printed. The descriptions for different fields in the
mac trace are given in the comments above. For all IP packets additional
IP header fields are also added to the above trace. The IP trace is
described below:

\begin{program}
sprintf(wrk_ + offset, "------- [%d:%d %d:%d %d %d] ",
                src,          // IP src address
                ih->sport_,   // src port number
                dst,          // IP dest address
                ih->dport_,   // dest port number
                ih->ttl_,     // TTL value 
                (ch->next_hop_ < 0) ? 0 : ch->next_hop_); // next hopaddress, if any.
\end{program}

An example of a trace for a tcp packet is as follows:
\begin{program}
r 160.093884945 _6_ RTR  --- 5 tcp 1492 [a2 4 6 800] ------- [655
36:0 16777984:0 31 16777984] [1 0] 2 0
\end{program}
Here we see a TCP data packet being received by a node with id of 6. UID
of this pkt is 5 with a cmn hdr size of 1492. The mac details shows an IP
pkt (ETHERTYPE\_IP is defined as 0x0800, ETHERTYPE\_IP is 0x0806 ), mac-id
of this receiving node is 6. That of the sending node is 4 and expected
time to send this data pkt over the wireless channel is a2 (hex2dec
conversion: 160+2 sec). Additionally, IP traces information about IP src
and destination addresses. The src translates (using a 3 level
hier-address of 8/8/8) to a address string of 0.1.0 with port of 0. The
dest address is 1.0.3 with port address of 0. The TTL value is 31 and the
destination was a hop away from the src. Additionally TCP format prints
information about tcp seqno of 1, ackno of 0. See other formats described
in \nsf/cmu-trace.cc for DSR, UDP/MESSAGE, TCP/ACK and CBR packet types.

Other trace formats are also used by the routing agents (TORA and DSR) to
log certain special routing events like "originating" (adding a SR header
to a packet) or  "ran off the end of a source route" indicating some sort
of routing problem with the source route etc. These special event traces
begin with "S" for DSR and "T" for Tora and may
be found in \nsf{tora/tora.cc} for TORA and \nsf{dsr/dsrgent.cc} for DSR
routing agent.


\subsection{Revised format for wireless traces}
\label{sec:revtraceformat}

In an effort to merge wireless trace, using cmu-trace objects, with
ns tracing, a new, inproved trace format has been introduced. This revised
trace support is backwards compatible with the old trace formatting and
can be enabled by the following command:
\begin{program}
$ns use-newtrace
\end{program}
This command should be called before the universal trace command
\code{$ns trace-all <trace-fd>}. Primitive \code{use-newtrace} sets up new
format for wireless tracing by setting a simulator variable called
\code{newTraceFormat}. Currently this new trace support is available for
wireless simulations only and shall be extended to rest of \ns in the near
future.

An example of the new trace format is shown below:
\begin{program}
s -t 0.267662078 -Hs 0 -Hd -1 -Ni 0 -Nx 5.00 -Ny 2.00 -Nz 0.00 -Ne
-1.000000 -Nl RTR -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 0.255 -Id -1.255 -It
message -Il 32 -If 0 -Ii 0 -Iv 32
s -t 1.511681090 -Hs 1 -Hd -1 -Ni 1 -Nx 390.00 -Ny 385.00 -Nz 0.00 -Ne
-1.000000 -Nl RTR -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 1.255 -Id -1.255 -It
message -Il 32 -If 0 -Ii 1 -Iv 32
s -t 10.000000000 -Hs 0 -Hd -2 -Ni 0 -Nx 5.00 -Ny 2.00 -Nz 0.00 -Ne
-1.000000 -Nl AGT -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 0.0 -Id 1.0 -It tcp -Il 1000 -If
2 -Ii 2 -Iv 32 -Pn tcp -Ps 0 -Pa 0 -Pf 0 -Po 0
r -t 10.000000000 -Hs 0 -Hd -2 -Ni 0 -Nx 5.00 -Ny 2.00 -Nz 0.00 -Ne
-1.000000 -Nl RTR -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 0.0 -Id 1.0 -It tcp -Il 1000 -If
2 -Ii 2 -Iv 32 -Pn tcp -Ps 0 -Pa 0 -Pf 0 -Po 0
r -t 100.004776054 -Hs 1 -Hd 1 -Ni 1 -Nx 25.05 -Ny 20.05 -Nz 0.00 -Ne
-1.000000 -Nl AGT -Nw --- -Ma a2 -Md 1 -Ms 0 -Mt 800 -Is 0.0 -Id 1.0 -It
tcp -Il 1020 -If 2 -Ii 21 -Iv 32 -Pn tcp -Ps 0 -Pa 0 -Pf 1 -Po 0
s -t 100.004776054 -Hs 1 -Hd -2 -Ni 1 -Nx 25.05 -Ny 20.05 -Nz 0.00 -Ne
-1.000000 -Nl AGT -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 -Is 1.0 -Id 0.0 -It ack -Il 40
-If 2 -Ii 22 -Iv 32 -Pn tcp -Ps 0 -Pa 0 -Pf 0 -Po 0 
\end{program}

\subsubsection{Explanation of new trace format}
The new trace format as seen above can be can be divided into the
following fields :
\begin{description}
\item[Event type]
In the traces above, the first field (as in the older trace format)
describes the type of event taking place at the node and can be one of the 
four types:
\begin{description}
\item[s] send 
\item[r] receive 
]item[d] drop 
\item[f] forward
\end{description}

\item[General tag]
The second field starting with "-t" may stand for time or global setting
\begin{description}
\item[-t] time
\item[-t] * (global setting)
\end{description}

\item[Node property tags]
This field denotes the node properties like node-id, the level at
which tracing is being done like agent, router or MAC. The tags start
with a leading "-N" and are listed as below:
\begin{description}
\item[-Ni:] node id
\item[-Nx:] node's x-coordinate
\item[-Ny:] node's y-coordinate
\item[-Nz:] node's z-coordinate
\item[-Ne:] node energy level
\item[-Nl:] trace level, such as AGT, RTR, MAC
\item[-Nw:] reason for the event. The different reasons for dropping a
packet are given below:
\begin{description}
\item["END"] DROP\_END\_OF\_SIMULATION          
\item["COL"] DROP\_MAC\_COLLISION              
\item["DUP"] DROP\_MAC\_DUPLICATE 
\item["ERR"] DROP\_MAC\_PACKET\_ERROR  
\item["RET"] DROP\_MAC\_RETRY\_COUNT\_EXCEEDED
\item["STA"] DROP\_MAC\_INVALID\_STATE      
\item["BSY"] DROP\_MAC\_BUSY                 

\item["NRTE"] DROP\_RTR\_NO\_ROUTE i.e no route is available.
\item["LOOP"] DROP\_RTR\_ROUTE\_LOOP i.e there is a routing loop
\item["TTL"]  DROP\_RTR\_TTL i.e TTL has reached zero.
\item["TOUT"] DROP\_RTR\_QTIMEOUT i.e packet has expired.
\item["CBK"]  DROP\_RTR\_MAC\_CALLBACK

\item["IFQ"]  DROP\_IFQ\_QFULL i.e no buffer space in IFQ.
\item["ARP"]  DROP\_IFQ\_ARP\_FULL i.e dropped by ARP
\item["OUT"]  DROP\_OUTSIDE\_SUBNET i.e dropped by base stations on
receiving routing updates from nodes outside its domain.
\end{description}
\end{description}

\item[Packet information at IP level]
The tags for this field start with a leading "-I" and are listed along
with their explanations as following:
\begin{description}
\item[-Is:] source address.source port number
\item[-Id:] dest address.dest port number
\item[-It:] packet type
\item[-Il:] packet size
\item[-If:] flow id
\item[-Ii:] unique id
\item[-Iv:] ttl value  
\end{description}

\item[Next hop info]
This field provides next hop info and the tag starts with a leading "-H".
\begin{description}
\item[-Hs:] id for this node
\item[-Hd:] id for next hop towards the destination.
\end{description}

\item[Packet info at MAC level]
This field gives MAC layer information and starts with a leading "-M" as
shown below:
\begin{description}
\item[-Ma:] duration
\item[-Md:] dst's ethernet address
\item[-Ms:] src's ethernet address
\item[-Mt:] ethernet type  
\end{description}     

\item[Packet info at "Application level"]
The packet information at application level consists of the type of
application like ARP, TCP, the type of adhoc routing protocol like
DSDV, DSR, AODV etc being traced. This field consists of a leading "-P"
and list of tags for different application is listed as below:
\begin{description}
\item[-P arp] Address Resolution Protocol. Details for ARP is given by the
following tags:
\begin{description}
\item[-Po:] ARP Request/Reply
\item[-Pm:] src mac address
\item[-Ps:] src address
\item[-Pa:] dst mac address
\item[-Pd:] dst address
\end{description}

\item[-P dsr] This denotes the adhoc routing protocol called Dynamic
source routing. Information on DSR is represented by the following tags:
\begin{description}
\item[-Pn:] how many nodes traversed
\item[-Pq:] routing request flag
\item[-Pi:] route request sequence number
\item[-Pp:] routing reply flag
\item[-Pl:] reply length
\item[-Pe:] src of srcrouting->dst of the source routing
\item[-Pw:] error report flag ?
\item[-Pm:] number of errors
\item[-Pc:] report to whom
\item[-Pb:] link error from linka->linkb
\end{description}

\item[-P cbr] Constant bit rate. Information about the CBR application is
represented by the following tags:

\begin{description}
\item[-Pi:] sequence number
\item[-Pf:] how many times this pkt was forwarded
\item[-Po:] optimal number of forwards 
\end{description}

\item[-P tcp] Information about TCP flow is given by the following
subtags:

\begin{description}
\item[-Ps:] seq number
\item[-Pa:] ack number
\item[-Pf:] how many times this pkt was forwarded
\item[-Po:] optimal number of forwards 
\end{description}
\end{description}

This field is still under development and new tags shall be added for
other applications as they get included along the way.
\end{description}


\subsection{Generation of node-movement and traffic-connection for
  wireless scenarios}
\label{sec:mobile-scen-generator}

Normally for large topologies, the node movement and traffic connection
patterns are defined in separate files for convinience. These movement and
traffic files may be generated using CMU's movement- and
connection-generators. In this section we shall describe both separately.

\subsubsection{MobileNode Movement}
\label{sec:mobile-movement-file}

Some examples of node movement files may be found in
\nsf{tcl/mobility/scene/scen-670x670-50-600-20-*}. These files
define a topology of 670 by 670m where 50 nodes move with a speed of 20m/s
with pause time of 600s. each node is assigned a starting position. The
information regarding number of hops between the nodes is fed to the
central object "GOD" (XXX but why/where is this information used??-answer
awaited from CMU.) Next each node is a speed and a direction to move to. 

The generator for creating node movement files are to be found under
\nsf{indep-utils/cmu-scen-gen/setdest/} directory. Compile the files
under setdest to create an executable. run setdest with arguments in
the following way:
\begin{program}
./setdest -n <num_of_nodes> -p <pausetime> -s <maxspeed> -t <simtime>
          -x <maxx> -y <maxy> > <outdir>/<scenario-file>
\end{program}
Note that the index used for nodes now start from 0 instead of 1 as
was in the original CMU version, to match with \ns's tradition of
assigning node indices from 0.


\subsubsection{Generating traffic pattern files}
\label{sec:mobile-traffic-file}

The examples for traffic patterns may be found in
\nsf{tcl/mobility/scene/cbr-50-\{10-4-512, 20-4-512\}}.

The traffic generator is located under \nsf{indep-utils/cmu-scen-gen/}
and are called cbrgen.tcl and tcpgen.tcl. They may be used for
generating CBR and TCP connections respectively.

To create CBR connecions, run
\begin{program}
ns cbrgen.tcl [-type cbr|tcp] [-nn nodes] [-seed seed] 
              [-mc connections] [-rate rate]
\end{program}
To create TCP connections, run
\begin{program}
ns tcpgen.tcl [-nn nodes] [-seed seed]
\end{program}
You will need to pipe the outputs from above to a cbr-* or a tcp-* file.


\section{Extensions made to CMU's wireless model}
\label{sec:wireless-extensions}