satellite.tex

柯老师网站上找到的

%\documentstyle[11pt,fullpage]{article}
%\setlength{\parindent}{0 in}
%\setlength{\parskip}{.1in}
%\setlength{\topmargin}{-0.5in}
%\setlength{\textheight}{8.5in}
%\begin{document}
\chapter{Satellite Networking in \ns}
\label{chap:satellite}

This chapter describes extensions that enable the simulation of satellite
networks in \ns.  In particular, these extensions enable \ns~to model
the following:  i) traditional geostationary ``bent-pipe'' satellites with 
multiple users per uplink/downlink and asymmetric links, ii) geostationary 
satellites with processing payloads (either regenerative payloads or full 
packet switching), and iii) polar orbiting LEO constellations such as 
Iridium and Teledesic.  These satellite models are principally aimed at 
using \ns~to study networking aspects of satellite systems; in particular, 
MAC, link layer, routing, and transport protocols.  

%\paragraph{Notice (caveat emptor)} 

%This code (including perhaps the APIs at OTcl level) is likely to change 
%over the next few months (as of this writing in June 1999) as the \ns~
%developers work on integrating the structure of satellite nodes, 
%wireless nodes, hierarchical nodes, etc.  In particular, we plan on
%modifying the code to support mixed-node topologies (e.g., simulations
%consisting of traditional \ns~nodes and satellite nodes) and running existing 
%unicast and multicast OTcl-based routing protocols.  \nam~~is 
%not currently supported with these extensions.

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

\section{Overview of satellite models}
\label{sec:satellite/overview}

Exact simulation of satellite networks requires a
detailed modelling of radio frequency characteristics (interference, fading),
protocol interactions (e.g., interactions of residual burst errors on the 
link with error checking codes), and second-order orbital effects (precession,
gravitational anomalies, etc.).  However, in order to study fundamental
characteristics of satellite networks from a {\em networking} perspective,
certain features may be abstracted out.  For example, the performance of
TCP over satellite links is impacted little by using an approximate rather than 
detailed channel model-- performance can be characterized to first order
by the overall packet loss probability.  This is the approach taken in this
simulation model-- to create a framework for studying transport, 
routing, and MAC protocols in a satellite environment consisting of
geostationary satellites or constellations of polar-orbiting 
low-earth-orbit (LEO) satellites.  Of course, users may extend these models
to provide more detail at a given layer.   

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

\subsection{Geostationary satellites}
\label{sec:satellite/overview/geo}

Geostationary satellites orbit the Earth at an altitude of 22,300 miles 
above the equator.  The position of the satellites is specified in terms
of the longitude of the nadir point (subsatellite point on the Earth's
surface).  In practice, geostationary satellites can drift from their
designated location due to gravitational perturbations-- these effects
are not modelled in \ns.   

Two kinds of geostationary satellites can be modelled.  Traditional
``bent-pipe'' geostationary satellites are merely repeaters in orbit--
all packets received by such satellites on an uplink channel are piped
through at RF frequencies to a corresponding downlink, and the satellite node
is not visible to routing protocols.   Newer satellites will
increasingly use baseband processing, both to regenerate the digital signal and
to perform fast packet switching on-board
the spacecraft.  In the simulations, these satellites can be modelled more like 
traditional \ns~nodes with classifiers and routing agents.  
  
Previously, users could simulate geostationary satellite links by simply
simulating a long delay link using traditional \ns~links and nodes.  The
key enhancement of these satellite extensions with respect to geostationary
satellites is the capability to simulate MAC protocols.  Users can now
define many terminals at different locations on the Earth's surface and
connect them to the same satellite uplink and downlink channels, and the
propagation delays in the system (which are slightly different for each
user) are accurately modelled.  In addition, the uplink and downlink channels
can be defined differently (perhaps with different bandwidths or error models).

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

\subsection{Low-earth-orbiting satellites}
\label{sec:satellite/overview/leo}

\begin{figure}
    \centerline{\includegraphics{sat-constellation}}
    \caption{Example of a polar-orbiting LEO constellation.  This figure
was generated using the SaVi software package from the geometry center at the
University of Minnesota.}
    \label{fig:constellation}
\end{figure}

Polar orbiting satellite systems, such as Iridium and the proposed Teledesic 
system, can
be modelled in \ns.   In particular, the simulator supports the specification
of satellites that orbit in purely circular planes, for which the neighboring 
planes are co-rotating.
There are other non-geostationary constellation configurations  
possible (e.g., Walker constellations)-- the interested user may develop new
constellation classes to simulate these other constellation types.  In
particular, this would mainly require defining new intersatellite link 
handoff procedures.

The following are the parameters of satellite constellations that can currently
be simulated:
\begin{itemize}
        \item {\bf Basic constellation definition} Includes satellite altitude,
number of satellites, number of planes, number of satellites per plane.
        \item {\bf Orbits} Orbit inclination can range continuously
from 0 to 180 degrees (inclination greater than 90 degrees corresponds to
retrograde orbits).  Orbit eccentricity is not modeled.  Nodal precession is 
not modeled.  Intersatellite spacing within a given plane is fixed.  Relative
phasing between planes is fixed (although some systems may not control phasing
between planes).
        \item {\bf Intersatellite (ISL) links} For polar orbiting 
constellations,
intraplane, interplane, and crossseam ISLs can be defined.  Intraplane ISLs
exist between satellites in the same plane and are never deactivated or 
handed off.  Interplane ISLs exist between satellites of neighboring 
co-rotating planes.  These links are deactivated near the poles (above
the ``ISL latitude threshold'' in the table) because the antenna pointing 
mechanism cannot track these links in the polar regions.  Like intraplane ISLs,
interplane ISLs are never handed off.  Crossseam ISLs may exist in a 
constellation between satellites in counter-rotating planes (where the 
planes form a so-called ``seam'' in the topology).   GEO ISLs can also be
defined for constellations of geostationary satellites.
        \item {\bf Ground to satellite (GSL) links}  Multiple terminals
can be connected to a single GSL satellite channel.  GSL links for GEO 
satellites are static, while GSL links for LEO channels are periodically 
handed off as described below.  
        \item {\bf Elevation mask} The elevation angle above which a GSL 
link can be operational.  Currently, if the (LEO) satellite serving a terminal
drops below the elevation mask, the terminal searches for a new satellite
above the elevation mask.  Satellite terminals check for handoff opportunities
according to a timeout interval specified by the user.  Each terminal
initiates handoffs asynchronously; it would be possible also to define
a system in which each handoff occurs synchronously in the system.
\end{itemize}

The following table lists parameters used for example simulation scripts
of the Iridium\footnote{Aside
from the link bandwidths (Iridium is a narrowband system only), these
parameters are very close to what a broadband version of the Iridium system
might look like.}  and Teledesic\footnote{These Teledesic constellation 
parameters are subject to change; 
thanks to Marie-Jose Montpetit of Teledesic for providing
tentative parameters as of January 1999.  The link bandwidths are not
necessarily accurate.} systems.

\begin{table}[h]
\begin{center}
{\tt
\begin{tabular}{|c||c|c|}\hline
& {\bf Iridium} & {\bf Teledesic}\\\hline\hline
{\bf Altitude} & \rm 780 km& \rm 1375 km\\\hline
{\bf Planes} & \rm 6& \rm 12\\\hline
{\bf Satellites per plane} & \rm 11 & \rm 24\\\hline
{\bf Inclination (deg)} & \rm 86.4 & \rm 84.7\\\hline
{\bf Interplane separation (deg)} & \rm 31.6 & \rm 15\\\hline
{\bf Seam separation (deg)} & \rm 22 & \rm 15\\\hline
{\bf Elevation mask (deg)} & \rm 8.2 & \rm 40\\\hline
{\bf Intraplane phasing} & \rm yes & \rm yes\\\hline
{\bf Interplane phasing} & \rm yes & \rm no\\\hline
{\bf ISLs per satellite} & \rm 4  & \rm 8\\\hline
{\bf ISL bandwidth} & \rm 25 Mb/s  & \rm 155 Mb/s\\\hline
{\bf Up/downlink bandwidth} & \rm 1.5 Mb/s  & \rm 1.5 Mb/s\\\hline
{\bf Cross-seam ISLs} & \rm no & \rm yes\\\hline
{\bf ISL latitude threshold (deg)} & \rm 60 & \rm 60\\\hline
\end{tabular}
}
\end{center}
\caption{Simulation parameters used for modeling a broadband version of
the Iridium system and the proposed 288-satellite Teledesic system.
Both systems are examples of polar orbiting constellations.
}
\end{table}
\clearpage
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Using the satellite extensions}
\label{sec:satellite/usage}

\begin{figure}
    \centerline{\includegraphics{sat-spherical}}
    \caption{Spherical coordinate system used by satellite nodes}
    \label{fig:spherical}
\end{figure}

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

\subsection{Nodes and node positions}
\label{sec:satellite/usage/nodes}

There are two basic kinds of satellite nodes:  {\em geostationary}  
and {\em non-geostationary} satellite nodes.  In addition, {\em terminal} nodes
can be placed on the Earth's surface.  As is explained later in 
Section \ref{sec:satellite/implementation},
each of these three different types of nodes is actually implemented with 
the same \code{class SatNode} object, but with different position,
handoff manager,  and link objects attached.  
The position object keeps track of the satellite node's location 
in the coordinate system as a function of the elapsed simulation time.
This position information is used to determine link propagation delays and
appropriate times for link handoffs. 

Figure \ref{fig:spherical} illustrates the spherical coordinate system,
and the corresponding Cartesian coordinate system.
The coordinate system is centered at the 
Earth's center, and the $z$ axis coincides with the Earth's axis of rotation.  
$(R,\theta,\phi) = (6378 km, 90^o, 0^o)$ corresponds to $0^o$ longitude 
(prime meridian) on the equator.

Specifically, there is one class of satellite node \code{Class Node/SatNode},
to which one of three types of \code{Position} objects may be attached.  
Each \code{SatNode} and \code{Position} object is a split OTcl/C++ object,
but most of the code resides in C++.  The following types of position objects 
exist: 
\begin{itemize}
\item \code{Position/Sat/Term} A terminal is specified by its latitude and
longitude.  Latitude ranges from $[-90, 90]$ and longitude ranges from
$[-180, 180]$, with negative values corresponding to south and west, 
respectively.  As simulation time evolves, the terminals move along
with the Earth's surface.  The  Simulator instproc \code{satnode} can be used 
to create a terminal with an attached position object as follows:
\begin{program}
$ns satnode terminal $lat $lon
\end{program}
\item \code{Position/Sat/Geo} A geostationary satellite is specified by its 
longitude above the equator.  As simulation time evolves, the geostationary
satellite moves through the coordinate system with the same orbital period
as that of the Earth's rotation.  The longitude ranges from $[-180,180]$
degrees.  The Simulator instproc \code{satnode} can be 
used to create a geostationary satellite with an attached position object as 
follows:
\begin{program}
$ns satnode geo $lon
\end{program}
\item \code{Position/Sat/Polar} A polar orbiting satellite has a purely
circular orbit along a fixed plane in the coordinate system; the Earth
rotates underneath this orbital plane, so there is both an east-west and
a north-south component to the track of a polar satellite's footprint on
the Earth's surface.  Strictly speaking, the polar position object can
be used to model the movement of any circular orbit in a fixed plane;  
we use the term ``polar'' here because we later use such satellites to model 
polar-orbiting constellations.

Satellite orbits are usually specified by six parameters:  {\em altitude},