mobility.tex

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

As mentioned earlier, the original CMU wireless model allows
simulation of wireless LANs and ad-hoc networks. However in order to
use the wireless model for simulations using both wired and wireless
nodes we had to add certain extensions to cmu model. We 
call this wired-cum-wireless feature. Also SUN's MobileIP (implemented
for wired nodes) was integrated into the wireless model allowing
mobileIP to run over wireless mobilenodes. The following two
subsections describe these two extensions to the wireless 
model in \ns. 


\subsection{wired-cum-wireless scenarios}
\label{sec:wired-cum-wireless}

The mobilenodes described so far mainly supports simulation of
multi-hop ad-hoc networks or wireless LANs. But what if we need to
simulate a topology of multiple wireless LANs connected through wired
nodes, or may need to run mobileIP on top of these wireless nodes? The
extensions made to the CMU wireless model allows us to do that. 

The main problem facing the wired-cum-wireless scenario was the issue
of routing. In ns, routing information is generated based on the
connectivity of the topology, i.e how nodes are connected to one
another through \code{Links}. Mobilenodes on the other hand have no
concept of links. They route packets among themselves, within the
wireless topology, using their routing protocol. so how would packets
be exchanged between these two types of nodes? 

So a node called \code{BaseStationNode} is created which plays the
role of a gateway for the wired and wireless domains. The
\code{BaseStationNode} is essentially a hybrid between a Hierarchical
node\footnote{Refer to Chapter~\ref{chap:hier-rtg} for details on
  hierarchical routing and internals of \code{HierNode}.}
(\code{HierNode}) and a \code{MobileNode}. The basestation node is
responsible for delivering packets into and out of the wireless
domain. In order to achieve this we need Hierarchical routing. 

Each wireless domain along with its base-station would have an unique
domain address assigned to them. All packets destined to a wireless
node would reach the base-station attached to the domain of that
wireless node, who would eventually hand the packet
over to the destination (mobilenode). And mobilenodes route packets,
destined to outside their (wireless) domain, to their base-station
node. The base-station knows how to forward these packets towards the
(wired) destination.
\begin{figure}
    \centerline{\includegraphics{basestation}}
    \caption{Schematic of a baseStationNode}
    \label{fig:mobilenode-basestation}
\end{figure}
The schematic of a \code{BaseStationNode} is shown in
Figure~\ref{fig:mobilenode-basestation}.

The mobilenodes in wired-cum-wireless scenario are required to support
hierarchical addressing/routing. Thus the \code{MobileNode} looks
exactly like the \code{BaseStationNode}. The SRNode, however, simply
needs to have its own hier-address since it does not require any
address demuxes and thus is not required to support hier
routing\footnote{In order to do away with all these different
  variations of the definition of a node, we are planning to revise
  the node architecture that would allow a more flexible
  and modularised construction of a node without the necessity of having
  to define and be limited to certain Class definitions only.}.

The DSDV agent on having to forward a packet checks to see if the
destination is outside its (wireless) subnet. If so, it tries to
forward the packet to its base-station node. In case no route to
base-station is found the packet is dropped. Otherwise the
packet is forwarded to the next\_hop towards the base-station. Which
is then routed towards the wired network by base-station's
classifiers.

The DSR agent, on receiving a pkt destined outside its subnet, sends
out a route-query for its base-station in case the route to
base-station is not known. The data pkt is temporarily cached while it
waits to hear route replies from base-station. On getting a reply the
packet is provided with routing information in its header and send
away towards the base-station. The base-station address demuxes routes
it correctly toward the wired network.

The example script for a wired-cum-wireless simulation can be found at
\nsf{tcl/ex/wired-cum-wireless-sim.tcl}. The methods for
wired-cum-wireless implementations are defined in
\nsf{tcl/lib/ns-bsnode.tcl}, \nsf{tcl/mobility/\{com.tcl,dsr.tcl,
  dsdv.tcl\}}, \nsf{dsdv/dsdv.\{cc,h\}} and
\nsf{dsr/dsragent.\{cc,h\}}.


\subsection{MobileIP}
\label{sec:mobileip}

The wired-cum-wireless extensions for the wireless model paved the
path for supporting wireless MobileIP in \ns. Sun Microsystem's
(Charlie Perkins {\em et al}) MobileIP model was based on ns's wired model
(consisting of \code{Node}'s and \code{Link}'s) and thus didnot use
CMU's mobility model.

Here we briefly describe the wireless MobileIP implementation. We hope
that Sun would provide the detailed version of the documentation in
the future.

The mobileIP scenario consists of Home-Agents(HA) and
Foreign-Agents(FA) and have Mobile-Hosts(MH) moving between their HA
and FAs.
The HA and FA are essentially base-station nodes we have described
earlier. While MHs are basically the mobileNodes described in
section~\ref{sec:mobilenode-creation}.
The methods and procedures for MobileIP extensions are described in
\nsf{mip.\{cc,h\}}, \nsf{mip-reg.cc}, \nsf{tcl/lib/ns-mip.tcl} and
\nsf{tcl/lib/ns-wireless-mip.tcl}.

\begin{figure}
    \centerline{\includegraphics{wireless-mip}}
    \caption{Schematic of a Wireless MobileIP BaseStation Node}
    \label{fig:mobilenode-wireless-mip}
\end{figure}
The HA and FA nodes are defined as \code{MobileNode/MIPBS} having a
registering agent (regagent\_) that sends beacon out to the
mobilenodes, sets up encapsulator and decapsulator, as required and
replies to solicitations from MHs. 
The MH nodes are defined as \code{MobileNode/MIPMH} which too have a
regagent\_ that receives and responds to beacons and sends out
solicitations to HA or FAs. Figure~\ref{fig:mobilenode-wireless-mip}
illustrates the schematic of a \code{MobileNode/MIPBS} 
node. The \code{MobileNode/MIPMH} node is very similar to this except
for the fact that it doesnot have any encapsulator or decapsulator. As
for the SRNode version of a MH, it doesnot have the hierarchical
classifiers and the RA agent forms the entry point of the node. See
Figure~\ref{fig:mobilenode-dsr} for model of a SRNode. 

The \code{MobileNode/MIPBS} node routinely broadcasts beacon or
advertisement messages out to MHs. A solicitation from a mobilenode
generates an ad that is send directly to the requesting MH. The
address of the base-station sending out beacon is heard by 
MH and is used as the COA (care-of-address) of the MH. Thus as the MH
moves from its native to foreign domains, its COA changes. 
Upon receiving  reg\_request (as reply to ads) from a mobilehost the
base-station checks to see if it is the HA for the MH. If not, it sets
up its decapsulator and forwards the reg\_request towards the HA of
the MH. 

In case the base-station {\em is} the HA for the requesting MH but the
COA doesnot match its own, it sets up an encapsulator and sends
reg-request-reply back to the COA (address of the FA) who has
forwarded the reg\_request to it. so now all packets destined to the
MH reaching the HA would be tunneled through the encapsulator which
encapsulates the IP pkthdr with a IPinIP hdr, now destined to the COA
instead of MH. The FA's decapsulator recives this packet, removes the
encapsulation and sends it to the MH.

If the COA matches that of the HA, it just removes the encapsulator it
might have set up (when its mobilehost was roaming into foreign
networks) and sends the reply directly back to the MH, as the MH have
now returned to its native domain.

The mobilehost sends out solicitations if it doesnot hear any ads from the
base-stations. Upon receiving ads, it changes its COA to the address of
the HA/FA it has heard the ad from, and replies back to the COA with a
request for registration (\code{reg-request}).
Initially the MH maybe in the range of the HA and receives all pkts
directly from its COA which is HA in this case. 
Eventually as the MH moves out of range of its HA and into the a foreign
domain of a FA, the MH's COA changes from its HA to that of the FA. The HA
now sets up an encapsulator and tunnels all pkts destined for MH towards
the FA. The FA decapsulates the pkts and hands them over to the MH. The
data from MH destined for the wired world is always routed towards its
current COA.  
An example script for wireless mobileIP can be found at
\nsf{tcl/ex/wireless-mip-test.tcl}. The simulation consists of a MH moving
between its HA and a FA. The HA and FA are each connected to a wired
domain on one side and to their wireless domains on the other. TCP flows
are set up between the MH and a wired node. 

\section{Commands at a glance}
\label{sec:wirelesscommand}

Following is a list of commands used in wireless simulations:
\begin{program}
$ns_ node-config -addressingType <usually flat or hierarchical used for 
                                   wireless topologies>
                 -adhocRouting   <adhoc rotuing protocol like DSDV, DSR,
                                   TORA, AODV etc>
                 -llType         <LinkLayer>
                 -macType        <MAC type like Mac/802_11>
                 -propType       <Propagation model like
                                   Propagation/TwoRayGround>
                 -ifqType        <interface queue type like
                                   Queue/DropTail/PriQueue>
                 -ifqLen         <interface queue length like 50>
                 -phyType        <network inteface type like
                                   Phy/WirelessPhy>
                 -antType        <antenna type like Antenna/OmniAntenna>
                 -channelType    <Channel type like Channel/WirelessChannel>
                 -topoInstance   <the topography instance>
                 -wiredRouting   <turning wired routing ON or OFF>
                 -mobileIP       <setting the flag for mobileIP ON or OFF>
                 -energyModel    <EnergyModel type>
                 -initialEnergy  <specified in Joules>
                 -rxPower        <specified in W>
                 -txPower        <specified in W>
                 -agentTrace     <tracing at agent level turned ON or OFF>
                 -routerTrace    <tracing at router level turned ON or OFF>
                 -macTrace       <tracing at mac level turned ON or OFF>
                 -movementTrace  <mobilenode movement logging turned
                                   ON or OFF>
\end{program}
This command is used typically to configure for a mobilenode. For more info
about this command (part of new node APIs) see chapter titled "Restructuring
ns node and new Node APIs" in ns Notes and Documentation.

\begin{flushleft}
\code{$ns_ node <optional:hier address>}\\
This command is used to create a mobilenode after node configuration is done
as shown in the node-config command. Incase hierarchical addressing is being
used, the hier address of the node needs to be passed as well.


\code{$node log-movement}\\
This command previously used to enable logging of mobilenode's movement has now
been replaced by \code{$ns_ node-config -movementTrace <ON or OFF>}.


\code{create-god <num_nodes>}\\
This command is used to create a God instance. The number of mobilenodes
is passed as argument which is used by God to create a matrix to store
connectivity information of the topology.


\code{$topo load_flatgrid <X> <Y> <optional:res>}\\
This initializes the grid for the topography object. <X> and <Y> are the x-y
co-ordinates for the topology and are used for sizing the grid. The grid
resolution may be passed as <res>. A default value of 1 is normally used.


\code{$topo load_demfile <file-descrptor>}\\
For loading DEMFile objects into topography. See \ns/dem.{cc,.h} for details on
DEMFiles.


\code{$ns_ namtrace-all-wireless <namtrace> <X> <Y>}\\
This command is used to initialize a namtrace file for logging node movements
to be viewed in nam. The namtrace file descriptor, the X and Y 
co-ordinates of the wireless topology is passed as parameters with
this command.


\code{$ns_ nam-end-wireless <stop-time>}\\
This command is used to tell nam the simulation stop time given by <stop-time>.


\code{$ns_ initial_node_pos <node> <size>}\\
This command defines the node initial position in nam. <size> denotes the size
of node in nam. This function must be called after mobility model has been
defined.


\code{$mobilenode random-motion <0 or 1>}\\
Random-motion is used to turn on random movements for the mobilenode, in which
case random destinations are assigned to the node. 0 disables and 1 enables
random-motion.


\code{$mobilenode setdest <X> <Y> <s>}\\
This command is used to setup a destination for the mobilenode. The mobile
node starts moving towards destination given by <X> and <Y> at a speed of
<s> m/s.


\code{$mobilenode reset}\\
This command is used to reset all the objects in the nodes (network 
components like LL, MAC, phy etc).


Internal procedures\\
Following is a list of internal procedures used in wireless networking:

\code{$mobilenode base-station <BSnode-hier-addr>}\\
This is used for wired-cum-wireless scenarios. Here the mobilenode is provided
with the base-stationnode info for its domain. The address is hierarchical
since wired-cum-wireless scenarios typically use hierarchical addressing.


\code{$mobilenode log-target  <target-object>}\\
The <target-object>, which is normally a trace object, is used to log
mobilenode movements and their energy usage, if energy model is provided.


\code{$mobilenode topography <topoinstance>}\\
This command is used to provide the node with a handle to the topography
object.


\code{$mobilenode addif}\\
A mobilenode may have more than one network interface. This command is used
to pass handle for a network interface to the node.


\code{$mobilenode  namattach <namtracefd>}\\
This command is used to attach the namtrace file descriptor <namtracefd>
to the mobilenode. All nam traces for the node are then written into this
namtrace file.


\code{$mobilenode radius <r>}\\
The radius <r> denotes the node's range. All mobilenodes that fall within
the circle of radius <r> with the node at its center are considered as
neighbours. This info is typically used by the gridkeeper.


\code{$mobilenode start}\\
This command is used to start off the movement of the mobilenode.

\end{flushleft}

%\end{document}
\endinput