satellite.tex

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

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{Routing }
\label{sec:satellite/usage/routing}

The current status of routing is that it is incomplete.  Ideally, one should
be able to run all existing \ns~routing protocols over satellite links.  
However,
many of the existing routing protocols implemented in OTcl require that
the conventional \ns~links be used.  The \ns~developers are working to
remedy this situation so that existing routing implementations are 
independent of the underlying link objects.

With that being said, the current routing implementation is similar to
Session routing described in Chapter \ref{chap:unicast}, except that it
is implemented entirely in C++.   Upon each topology change, a centralized
routing genie determines the global network topology, computes new routes
for all nodes, and uses the routes to build
a forwarding table on each node.  Currently,
the slot table is kept by a routing agent on each node, and packets 
not destined for agents on the node are sent by default to this routing 
agent.  For each destination for which the node has a route, the forwarding
table contains a pointer to the head of the corresponding outgoing link.
As noted in Chapter \ref{chap:unicast}, the user is cautioned that this type 
of centralized routing can lead to minor causality violations.

The routing genie is a \code{class SatRouteObject} and is created and
invoked with the following OTcl commands:
\begin{program}
set satrouteobject_ [new SatRouteObject]
$satrouteobject_ compute_routes
\end{program}
where the call to \code{compute_routes} is performed after all of the
links and nodes in the simulator have been instantiated.
Like the \code{Scheduler}, there is one instance of a SatRouteObject in the
simulation, and it is accessed by means of an instance variable in C++.
For example, the call to recompute routes after a topology change is:
\begin{program}
SatRouteObject::instance().recompute();
\end{program}

Despite the current use of centralized routing, the design of having
a routing agent on each node was mainly done with distributed routing 
in mind.  Routing packets can be sent to port 255 of each node.  The key
to distributed routing working correctly is for the routing agent to
be able to 
determine from which link a packet arrived.  This is accomplished by the
inclusion of a \code{class NetworkInterface} object in each link, which
uniquely labels the link on which the packet arrived.  A helper function
\code{NsObject* intf_to_target(int label)} can be used to return the head 
of the
link corresponding to a given label.  The use of routing agents parallels
that of the mobility extensions, and the interested reader can turn to
those examples to see how to implement distributed routing protocols in
this framework.

The shortest-path route computations use the current propagation delay of
a link as the cost metric.  It is possible to compute routes using only
the hop count and not the propagation delays; in order to do so, set
the following default variable to "false":
\begin{program}
SatRouteObject set metric_delay_ "true"
\end{program}

Finally, for very large topologies (such as the Teledesic example), the 
centralized routing code will produce a very slow runtime because it executes
an all-pairs shortest path algorithm upon each topology change even if
there is no data currently being sent.  To speed up simulations in which
there is not much data transfer but there are lots of satellites and
ISLs, one can disable {\em handoff-driven} and enable {\em data-driven} 
route computations.  With data-driven computations, routes are computed
only when there is a packet to send, and furthermore, a single-source
shortest-path algorithm (only for the node with a packet to send) is 
executed instead of an all-pairs shortest path algorithm.  The following
OTcl variable can configure this option (which is set to "false" by
default):
\begin{program}
SatRouteObject set data_driven_computation_ "false"
\end{program}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{Trace support}
\label{sec:satellite/usage/trace}

Tracefiles using satellite nodes and links are very similar to conventional
\ns~tracing described in Chapter \ref{chap:trace}.  Special SatTrace objects
(\code{class SatTrace} derives from \code{class Trace}) are used
to log the geographic latitude and longitude of the node logging the trace
(in the case of a satellite node, the latitude and longitude correspond
to the nadir point of the satellite).

For example, a packet on a link from node 66 to node 26 might normally be
logged as:  
\begin{program}
+ 1.0000 66 26 cbr 210 ------- 0 66.0 67.0 0 0 
\end{program}
but in the satellite simulation, the position information is appended:
\begin{program}
+ 1.0000 66 26 cbr 210 ------- 0 66.0 67.0 0 0 37.90 -122.30 48.90 -120.94
\end{program}
In this case, node 66 is at latitude 37.90 degrees, longitude -122.30
degrees, while node 26 is a LEO satellite whose subsatellite
point is at 48.90 degrees latitude, -120.94 degrees longitude (negative
latitude corresponds to south, while negative longitude corresponds to
west).

One addition is the \code{Class Trace/Sat/Error}, which traces any packets
that are errored by an error model.  The error trace logs packets dropped
due to errors as follows, for example:  
\begin{program}
e 1.2404 12 13 cbr 210 ------- 0 12.0 13.0 0 0 -0.00 10.20 -0.00 -10.00
\end{program}

To enable tracing of all satellite links in the simulator, use the following
commands {\em before} instantiating nodes and links:
\begin{program}
set f [open out.tr w]
$ns trace-all $f
\end{program}
Then use the following line after all node and link creation (and all
error model insertion, if any) to enable tracing of all satellite links:
\begin{program}
$ns trace-all-satlinks $f
\end{program}
Specifically, this will put tracing around the link layer queues in all
satellite links, and will put a receive trace between the mac and the
link layer for received packets.  To enable tracing only on a specific
link on a specific node, one may use the command:
\begin{program}
$node trace-inlink-queue $f $i
$node trace-outlink-queue $f $i
\end{program}
where $i$ is the index of the interface to be traced.  

The implementations of the satellite trace objects can be found in 
\nsf{tcl/lib/ns-sat.tcl} and \nsf{sattrace.\{cc,h\}}.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{Error models}
\label{sec:satellite/usage/error}

\ns~error models are described in Chapter \ref{chap:error_model}.  These
error models can be set to cause packets to be errored according to various
probability distributions.  These error models are simple and don't 
necessarily correspond to what would be experienced on an actual satellite
channel (particularly a LEO channel).  Users are 
free to define more sophisticated error models that more closely match a 
particular satellite environment.

The following code provides an example of how to add an error model to a
link:
\begin{program}
set em_ [new ErrorModel]
$em_ unit pkt
$em_ set rate_ 0.02
$em_ ranvar [new RandomVariable/Uniform]
$node interface-errormodel $em_ 
\end{program}
This will add an error model to the receive path of the first interface
created on node \code{$node} (specifically, between the MAC and link layer)--
this first interface generally corresponds to the uplink and downlink
interface for a satellite or a terminal (if only one uplink and/or downlink
exists).
To add the error model to a different stack (indexed by $i$), use the 
following code:
\begin{program}
$node interface-errormodel $em_ $i 
\end{program}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{Other configuration options}
\label{sec:satellite/usage/other}

Given an initial configuration of satellites specified for time $0$, 
it is possible to start the 
satellite configuration from any arbitrary point in time through the use of the
\code{time_advance_} parameter (this is really only useful for LEO
simulations). During the simulation run, this will set the position of 
the object to the position at time
\code{Scheduler::instance().clock + time_advance_} seconds.
\begin{program}
Position/Sat set time_advance_ 0; # seconds          
\end{program}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{\nam~~support}
\label{sec:satellite/usage/nam}
\nam~~is not currently supported.  Addition of \nam~~ for GEO satellite
topologies is an active work item.  \nam~~ support for LEO constellations is
not planned (interested users are encouraged to develop this component).

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{Integration with other modules}
\label{sec:satellite/usage/integration}
Currenty, these satellite extensions do not interoperate with the wireless
code, mobile-IP code, and OTcl routing protocols (in particular, multicast).
This is an active work item for the \ns~developers and more support along
these lines will be added later.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{Example scripts}
\label{sec:satellite/usage/example}

Example scripts can be found in the \nsf{tcl/ex} directory, including:
\begin{itemize}
\item \code{sat-mixed.tcl}  A simulation with a mixture of polar and
geostationary satellites.
\item \code{sat-repeater.tcl}  Demonstrates the use of a simple bent-pipe
geostationary satellite, and also error models.
\item \code{sat-aloha.tcl}  Simulates one hundred terminals in a mesh-VSAT
configuration using an unslotted Aloha MAC protocol 
with a ``bent-pipe'' geostationary satellite.  Terminals listen to their
own transmissions (after a delay), and if they do not successfully receive
their own packet within a timeout interval, they perform exponential 
backoff and then retransmit the packet. 
\item \code{sat-iridium.tcl}  Simulates a broadband LEO constellation with
parameters similar to that of the Iridium constellation (with supporting
scripts \code{sat-iridium-links.tcl}, \code{sat-iridium-linkswithcross.tcl}, 
and \code{sat-iridium-nodes.tcl}).
\item \code{sat-teledesic.tcl}  Simulates a broadband LEO constellation with
parameters similar to those proposed for the 288 satellite Teledesic
constellation (with supporting scripts \code{sat-teledesic-links.tcl} and 
\code{sat-teledesic-nodes.tcl}).
\end{itemize}
In addition, there is a test suite script that tries to exercise a lot
of features simultaneously, it can be found at \nsf{tcl/test/test-suite-sat.tcl}.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Implementation}
\label{sec:satellite/implementation}

The code for the implementation of satellite extensions can be found
in \nsf{\{sat.h, sathandoff.\{cc,h\}, satlink.\{cc,h\}, satnode.\{cc,h\}, 
satposition.\{cc,h\}, satroute.\{cc,h\}, sattrace.\{cc,h\}\}}, and
\nsf{tcl/lib/ns-sat.tcl}.  Almost all of the mechanism is implemented
in C++.

In this section, we focus on some of the key components of the implementation;
namely, the use of linked lists, the node structure, and a detailed look
at the satellite link structure.

\subsection{Use of linked lists}