satellite.tex

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

{\em semi-major axis}, {\em eccentricity}, 
{\em right ascension of ascending node}, {\em inclination}, and
{\em time of perigee passage}.  The polar orbiting satellites in \ns~have
purely circular orbits, so we simplify the specification of the orbits to
include only three parameters: {\em altitude}, {\em inclination}, and
{\em longitude}, with a fourth parameter {\em alpha} specifying initial 
position of the satellite in the orbit, as described below.
{\bf Altitude} is specified in kilometers above the Earth's surface, and 
{\bf inclination} can range from $[0,180]$ degrees, with $90$ corresponding
to pure polar orbits and angles greater than $90$ degrees corresponding
to ``retrograde'' orbits.  The {\em ascending node} refers to the point
where the footprint of the satellite orbital track crosses the equator 
moving from south to north.  In this simulation model, the parameter 
{\bf longitude of ascending node} specifies the earth-centric longitude at 
which the satellite's nadir point crosses the equator moving south
to north.\footnote{Traditionally, the ``right ascension'' of the ascending
node is specified for satellite orbits-- the right ascension corresponds to the 
{\em celestial} longitude.  In our case, we do not care about the
orientation in a celestial coordinate system, so we specify the earth-centric
longitude instead.} {\em Longitude of ascending node} can range from 
$[-180,180]$ degrees.  The fourth parameter,
{\bf alpha}, specifies the initial position of the satellite along this
orbit, starting from the ascending node.  
For example, an {\em alpha} of $180$ degrees indicates that the
satellite is initially above the equator moving from north to south.
{\em Alpha} can range from $[0,360]$ degrees.
Finally, a fifth parameter, {\bf plane}, is specified when creating
polar satellite nodes-- all satellites in the same plane are given the
same plane index.
The Simulator instproc \code{satnode} can be 
used to create a polar satellite with an attached position object as 
follows:
\begin{program}
$ns satnode polar $alt $inc $lon $alpha $plane
\end{program}

Note that the above methods use the atomic \code{satnode} instproc.  In 
Section \ref{sec:satellite/usage/links}, we introduce wrapper methods
that may be more convenient for generating various types of satellite nodes:
\begin{program}
$ns satnode-terminal $latitude $longitude
$ns satnode-polar $alt $inc $lon $alpha $plane $linkargs $chan
$ns satnode-geo $longitude $linkargs $chan
$ns satnode-geo-repeater $longitude $chan
\end{program}
\end{itemize}

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

\subsection{Satellite links}
\label{sec:satellite/usage/links}

\begin{figure}
    \centerline{\includegraphics{sat-stack-basic}}
    \caption{Main components of a satellite network interface}
    \label{fig:sat-stack-basic}
\end{figure}

Satellite links resemble wireless links, which are described in Chapter
\ref{chap:mobility}.  Each satellite
node has one or more satellite network interface stacks, to which
channels are connected to the physical layer object in the stack.  Figure
\ref{fig:sat-stack-basic} illustrates the major components.  Satellite
links differ from \ns~wireless links in two major respects:  i) the
transmit and receive interfaces must be connected to different channels,
and ii) there is no ARP implementation.  Currently, the {\em
Radio Propagation Model} is a placeholder for users to add more detailed
error models if so desired; the current code does not use a propagation
model.

Network interfaces can be added with the following instproc of
\code{Class Node/SatNode}:
\begin{program}
$node add-interface $type $ll $qtype $qlim $mac $mac_bw $phy
\end{program}
The \code{add-interface} instproc returns an index value that can be used
to access the network interface stack later in the simulation.  By convention,
the first interface created on a node is attached to the uplink and downlink
channels of a satellite or terminal.  The
following parameters must be provided:

\begin{itemize} 
	\item {\bf type}:~~The following link types can be indicated:  
\code{geo} or 
\code{polar} for links from a terminal to a geo or polar satellite, 
respectively, \code{gsl} and \code{gsl-repeater} for links from a satellite
to a terminal, and \code{intraplane}, \code{interplane}, and \code{crossseam}
ISLs.  The type field is used internally in the simulator to identify the
different types of links, but structurally they are all very similar.
	\item {\bf ll}:~~The link layer type (\code{class LL/Sat} is currently
the only one defined).  
	\item {\bf qtype}:~~The queue type (e.g., \code{class Queue/DropTail}).
Any queue type may be used-- however, if additional parameters beyond the
length of the queue are needed, then this instproc may need to be modified
to include more arguments.
	\item {\bf qlim}:~~The length of the interface queue, in packets.
	\item {\bf mac}:~~The MAC type.  Currently, two types are defined:
\code{class Mac/Sat}-- a basic MAC for links with only one receiver (i.e.,
it does not do collision detection), and
\code{Class Mac/Sat/UnslottedAloha}-- an implementation of unslotted Aloha.
	\item {\bf mac\_bw}:~~The bandwidth of the link is set by this 
parameter, which controls the transmission time how fast the MAC sends. The
packet size used to calculate the transmission time is the sum of the
values \code{size()} in the common packet header and \code{LINK_HDRSIZE},
which is the size of any link layer headers.  The default value for
\code{LINK_HDRSIZE} is 16 bytes (settable in \code{satlink.h}).
The transmission time is encoded in the packet header for use at the
receive MAC (to simulate waiting for a whole packet to arrive).  
	\item {\bf phy}:~~The physical layer-- currently two Phys 
(\code{Class Phy/Sat} and \code{Class Phy/Repeater}) are defined.  
The class \code{Phy/Sat} just pass the information up and down the stack--
as in the wireless code described in Chapter \ref{chap:mobility}, 
a radio propagation model could be attached at this point.  The class
\code{Phy/Repeater} pipes any packets received on a receive interface
straight through to a transmit interface.
\end{itemize}

An ISL can be added between two nodes using the following instproc:
\begin{program}
$ns add-isl $ltype $node1 $node2 $bw $qtype $qlim
\end{program}
This creates two channels (of type \code{Channel/Sat}), and appropriate
network interfaces on both nodes, and attaches the channels to the 
network interfaces.  The bandwidth of the link is
set to \code{bw}.  The linktype (\code{ltype})
must be specified as either \code{intraplane}, \code{interplane}, or 
\code{crossseam}.


A GSL involves adding network interfaces and a channel on board the
satellite (this is typically done using the wrapper methods described
in the next paragraph), and then defining the correct interfaces on
the terrestrial node and attaching them to the satellite link, as 
follows:
\begin{program}
$node add-gsl $type $ll $qtype $qlim $mac $bw_up $phy \bs
   [$node_satellite set downlink_] [$node_satellite set uplink_]
\end{program}
Here, the \code{type} must be either \code{geo} or \code{polar}, 
and we make use
of the \code{downlink_} and \code{uplink_} instvars of the satellite;
therefore, the satellite's uplink and downlink must be created before
this instproc is called.

Finally, the following wrapper methods can be used to create nodes of a 
given type and, in the case of satellite nodes, give them an uplink and
downlink interface as well as create and attach an uplink and downlink
channel: 
\begin{program}
$ns satnode-terminal $latitude $longitude
$ns satnode-polar $alt $inc $lon $alpha $plane $linkargs $chan
$ns satnode-geo $longitude $linkargs $chan
$ns satnode-geo-repeater $longitude $chan
\end{program}
where \code{linkargs} is a list of link argument options for the 
network interfaces (i.e., \code{$ll $qtype $qlim $mac $mac_bw $phy}). 


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

\subsection{Handoffs }
\label{sec:satellite/usage/handoffs}

Satellite handoff modelling is a key component of LEO satellite network 
simulations.  It is difficult to predict exactly how handoffs will occur
in future LEO systems because the subject is not well treated in the
literature.  In these satellite extensions, we establish certain criteria for 
handoffs, and allow nodes to independently monitor for situations that 
require a handoff.  An alternative would be to have all handoff events
synchronized across the entire simulation-- it would not be difficult to 
change the simulator to work in such a manner.

There are no link handoffs involving geostationary satellites, but there 
are two types of links to polar orbiting satellites
that must be handed off:  GSLs to polar satellites, and crossseam ISLs.  
A third type of link, interplane ISLs, are not handed off but are deactivated
at high latitudes as we describe below.

Each terminal connected to a polar orbiting satellite runs a timer that,
upon expiry, causes the \code{HandoffManager} to check whether the current 
satellite has fallen below the
elevation mask of the terminal.  If so, the handoff manager detaches the
terminal from that satellite's up and down links, and searches
through the linked list of satellite nodes for another possible satellite.
First, the ``next'' satellite in the current orbital plane is checked-- a 
pointer to this satellite is stored in the Position object of each
polar satellite node and is set during simulation configuration using
the \code{Node/SatNode} instproc ``\code{$node set_next $next_node}.''
If the next satellite is not suitable, the handoff manager searches
through the remaining satellites.  If it finds a suitable polar
satelite, it connects its network interfaces to that satellite's uplink and 
downlink channels, and restarts the handoff timer.  If it does not find 
a suitable
satellite, it restarts the timer and tries again later.  If any link
changes occur, the routing agent is notified.

The elevation mask and handoff timer interval are settable via OTcl: 
\begin{program}
HandoffManager/Term set elevation_mask_ 10; # degrees
HandoffManager/Term set term_handoff_int_ 10; # seconds
\end{program}
In addition, handoffs may be randomized to avoid phase effects by setting
the following variable:
\begin{program}
HandoffManager set handoff_randomization_ 0; # 0 is false, 1 is true 
\end{program}
If \code{handoff_randomization_} is true, then the next handoff interval
is a random variate picked from a uniform distribution across
$(0.5 * term\_handoff\_int\_, 1.5 * term\_handoff\_int\_)$.  

Crossseam ISLs are the only type of ISLs that are handed off.  The criteria
for handing off a crossseam ISL is whether or not there exists a satellite
in the neighboring plane that is closer to the given satellite than the
one to which it is currently connected.  Again, a handoff timer running
within the handoff manager on the polar satellite determines when the
constellation is checked for handoff opportunities.  Crossseam ISL
handoffs are
initiated by satellites in the lower-numbered plane of the two.  It is
therefore possible for a transient condition to arise in which a polar
satellite has two crossseam ISLs (to different satellites).  The
satellite handoff interval is again settable from OTcl and may also be
randomized:
\begin{program}
HandoffManager/Sat set sat_handoff_int_ 10; # seconds
\end{program}

Interplane and crossseam ISLs are deactivated near the poles, because 
the pointing requirements for the links are too severe as the satellite
draw close to one another.  Shutdown of these links is governed by a parameter:
\begin{program}
HandoffManager/Sat set latitude_threshold_ 70; # degrees 
\end{program}
The values for this parameter in the example scripts are speculative;
the exact value is dependent upon the satellite hardware.  The handoff
manager checks the latitude of itself and its peer satellite upon a handoff
timeout; if either or both of the satellites is above 
\code{latitude_threshold_} degrees latitude (north or south), the link
is deactivated until both satellites drop below this threshold.

Finally, if crossseam ISLs exist, there are certain situations in which
the satellites draw too close to one another in the mid-latitudes (if
the orbits are not close to being pure polar orbits).  We check for
the occurence of this orbital overlap with the following parameter:
\begin{program}
HandoffManager/Sat set longitude_threshold_ 10; # degrees 
\end{program}
Again, the values for this parameter in the example scripts are speculative.
If the two satellites are closer together in longitude than 
\code{longitude_threshold_} degrees, the link between them is deactivated.
This parameter is disabled (set to $0$) by default-- all defaults for
satellite-related bound variables can be found in \nsf{tcl/lib/ns-sat.tcl}.