satellite.tex

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

\label{sec:satellite/implementation/list}

\begin{figure}
    \centerline{\includegraphics{linked-list}}
    \caption{Linked list implementation in \ns.}
    \label{fig:linked-list}
\end{figure}

There are a number of linked lists used heavily in the implementation:
\begin{itemize}

\item \code{class Node} maintains a (static) list of all objects of class
\code{Node} in the simulator.  The variable \code{Node::nodehead_} stores
the head of the list.  The linked list of nodes is used for centralized
routing, for finding satellites to hand off to, and for tracing.

\item \code{class Node} maintains a list of all (satellite) links on the
node.  Specifically, the list is a list of objects of class \code{LinkHead}. 
The variable \code{linklisthead_} stores the head of the list.  The
linked list of LinkHeads is used for checking whether or not to handoff
links, and to discover topology adjacencies.

\item \code{class Channel} maintains a list of all objects of class
\code{Phy} on the channel.  The head of the list is stored in the variable
\code{if_head_}.  This list is used to determine the set of interfaces on a
channel that should receive a copy of a packet.
\end{itemize}

Figure \ref{fig:linked-list} provides a schematic of how the linked list
is organized.  Each object in the list is linked through a ``LINK\_ENTRY''
that is a protected member of the class.  This entry contains a pointer
to the next item in the list and also a pointer to the address of the
previous ``next'' pointer in the preceding object.   Various macros
found in \nsf{list.h} can be used to manipulate the list; the 
implementation of linked-lists in \ns~is similar to the \code{queue} 
implementation found in some variants of BSD UNIX.

\subsection{Node structure}

\begin{figure}
    \centerline{\includegraphics{sat-node}}
    \caption{Structure of \code{class SatNode}.}
    \label{fig:sat-node}
\end{figure}

Figure \ref{fig:sat-node} is a schematic of the main components of a
\code{SatNode}.  The structure bears resemblance to the \code{MobileNode}
in the wireless extensions, but there are several differences.  Like all
\ns~nodes, the SatNode has an ``entry'' point to a series of classifiers.
The address classifier contains a slot table for forwarding packets to 
foreign nodes, but since OTcl routing is not used, all packets not destined
for this node (and hence forwarded to the port classifier), are sent to
the default target, which points to a routing agent.  Packets destined
on the node for port 255 are classified as routing packets and are also
forwarded to the routing agent.

Each node contains one or more ``network stacks'' that include a generic
\code{SatLinkHead} at the entry point of the link.  The \code{SatLinkHead}
is intended to serve as an API to get at other objects in the link structure,
so it contains a number of pointers (although the API here has not been
finalized).  Packets leaving the network stack are sent to the node's
entry.  An important feature is that each packet leaving a network stack
has its \code{iface_} field in the common packet header coded with the
unique \code{NetworkInterface} index corresponding to the link.  This value
can be used to support distributed routing as described below.

The base class routing agent is \code{class SatRouteAgent}; it can be used 
in conjunction with centralized routing.  SatRouteAgents contain
a forwarding table that resolves a packet's address to a particular 
LinkHead target-- it is the job of the \code{SatRouteObject} to populate this
table correctly.  The SatRouteAgent populates certain fields in the header
and then sends the packet down to the approprate link.  To implement
a distributed routing protocol, a new SatRouteAgent could be defined-- this
would learn about topology by noting the interface index marked in each 
packet as it came up the stack-- a helper function in the node 
\code{intf_to_target()} allows it to resolve an index value to
a particular LinkHead. 

There are pointers to three additional objects in a SatNode.  First,
each SatNode contains a position object, discussed in the previous section.
Second, each SatNode contains a \code{LinkHandoffMgr} that monitors
for opportunities to hand links off and coordinates the handoffs.  Satellite
nodes and terminal nodes each have their specialized version of a 
LinkHandoffMgr.

Finally, a number of pointers to objects are contained in a SatNode.  We
discussed \code{linklisthead_} and \code{nodehead_} in the previous 
subsection.  The \code{uplink_} and \code{downlink_} pointers are
used for convenience under the assumption that, in most simulations,
a satellite or a terminal has only one uplink and downlink channel.

\subsection{Detailed look at satellite links}
\begin{figure}
    \centerline{\includegraphics{sat-stack}}
    \caption{Detailed look at network interface stack.}
    \label{fig:sat-stack}
\end{figure}

Figure \ref{fig:sat-stack} provides a more detailed look at how satellite links
are composed.  In this section, we describe how packets move up and down
the stack, and the key things to note at each layer.  The file 
\nsf{tcl/lib/ns-sat.tcl} contains the various OTcl instprocs that assemble
links according to Figure \ref{fig:sat-stack}.  We describe the composite
structure herein as a ``network stack.''  Most of the code for the
various link components is in \nsf{satlink.\{cc,h\}}.

The entry point to a network stack is the \code{SatLinkHead} object.  The
SatLinkHead object derives from \code{Class LinkHead}; the aim of link
head objects is to provide a uniform API for all network stacks.
\footnote{In the author's opinion, all network stacks in \ns~ should 
eventually have a LinkHead object at the front-- the class SatLinkHead 
would then disappear.}  The SatLinkHead object contains pointers to
the LL, Queue, MAC, Error model, and both Phy objects.  The SatLinkHead
object can also be queried as to what type of network stack it is-- e.g.,
GSL, interplane ISL, crossseam ISL, etc..  Valid codes for the \code{type_} 
field are currently found in \nsf{sat.h}.  Finally, the SatLinkHead
stores a boolean variable \code{linkup_} that indicates whether
the link to at least one other node on the channel is up.  The C++
implementation of SatLinkHead is found in \nsf{satlink.\{cc,h\}}.

Packets leaving a node pass through the SatLinkHead transparently to the 
\code{class SatLL} object.  The SatLL class derives from LL (link layer).
Link layer protocols (like ARQ protocols) can be defined here.  The current
SatLL assigns a MAC address to the packet.  Note that in the satellite case,
we do not use an Address Resolution Protocol (ARP); instead, we simply use
the MAC \code{index_} variable as its address, and we use a helper function
to find the MAC address of the corresponding interface of the next-hop node.  
Since \code{class LL} derives from \code{class LinkDelay}, the \code{delay_}
parameter of LinkDelay can be used to model any processing delay in the
link layer; by default this delay is zero.

The next object an outgoing packet encounters is the interface queue.  
However, if tracing is enabled, tracing elements may surround the
queue, as shown in Figure \ref{fig:sat-stack}.  This part of a satellite
link functions like a conventional \ns~ link.

The next layer down is the MAC layer.  The MAC layer draws packets from
the queue (or deque trace) object-- a handshaking between the MAC and the 
queue allows the MAC to draw packets out of the queue as it needs them.  The
transmission time of a packet is modelled in the MAC also-- the MAC computes
the transmission delay of the packet (based on the sum of the 
LINK\_HDRSIZE field defined in \code{satlink.h} and the \code{size} field 
in the common packet header), and does not call up for another packet until
the current one has been ``sent'' to the next layer down.  Therefore, it
is important to set the bandwidth of the link correctly at this layer.
For convenience, the transmit time is encoded in the \code{mac} header; this
information can be used at the receiving MAC to calculate how long it must
wait to detect a collision on a packet, for example.

Next, the packet is sent to a transmitting interface (Phy\_tx) of class 
\code{SatPhy}.  This
object just sends the packet to the attached channel.  We noted earlier
in this chapter that all interfaces attached to a channel are part of the
linked list for that channel.  This is not true for transmit interfaces,
however.  Only receive interfaces attached to a channel comprise this linked
list, since only receive interfaces should get a copy of transmitted packets.
The use of separate transmit and receive interfaces mirrors the real world
where full-duplex satellite links are made up of RF channels at different
frequencies.

The outgoing packet is next sent to a \code{SatChannel}, which copies the
packet to every receiving interface (of class \code{SatPhy}) on the channel. 
The Phy\_rx sends the packet to the MAC layer.  At the MAC layer, the packet
is held for the duration of its transmission time (and any appropriate
collision detection is performed if the MAC, such as the Aloha MAC,
supports it).  If the packet is determined to have arrived safely at the MAC,
it next passes to an \code{ErrorModel} object, if it exists.  If not, the
packet moves through any receive tracing objects to the \code{SatLL}
object.  The SatLL object passes the packet up after a processing delay
(again, by default, the value for \code{delay_} is zero).

The final object that a received packet passes through is an object of
\code{class NetworkInterface}.  This object stamps the \code{iface_} field
in the common header with the network stack's unique index value.  This
is used to keep track of which network stack a packet arrived on.  The
packet then goes to the \code{entry} of the SatNode (usually, an address
classifier).  

Finally, ``geo-repeater'' satellites exist, as described earlier in this
chapter.  Geo-repeater network stacks are very simple-- they only contain
a Phy\_tx and a Phy\_rx of \code{class RepeaterPhy}, and a SatLinkHead.  
Packets received by a Phy\_rx are sent to the Phy\_tx without delay.  The
geo-repeater satellite is a degenerate satellite node, in that it does not
contain things like tracing elements, handoff managers, routing agents, or 
any other link interfaces other than repeater interfaces.


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

Following is a list of commands related to satellite networking:
\begin{flushleft}
\code{$ns_ satnode-polar <alt> <inc> <lon> <alpha> <plane> <linkargs> <chan>}\\
This a simulator wrapper method for creating a polar satellite node. Two
links, uplink and downlink, are created along with two channels, uplink
channel and downlink channel. <alt> is the polar satellite altitude,
<inc> is orbit inclination w.r.t equator, <lon> is the longitude of 
ascending node, <alpha>
gives the initial position of the satellite along this orbit, <plane> 
defines the plane of
the polar satellite. <linkargs> is a list of link argument options that
defines the network interface (like LL, Qtype, Qlim, PHY, MAC etc).


\code{$ns_ satnode-geo <lon> <linkargs> <chan>}\\
This is a wrapper method for creating a geo satellite node that first
creates a satnode plus two link interfaces (uplink and downlink) plus two 
satellite channels (uplink and downlink). <chan> defines the type of
channel.


\code{$ns_ satnode-geo-repeater <lon> <chan>}\\
This is a wrapper method for making a geo satellite repeater node that 
first creates a satnode plus two link interfaces (uplink and downlink)
plus two satellite channels (uplink and downlink). 


\code{$ns_ satnode-terminal <lat> <lon>}\\
This is a wrapper method that simply creates a terminal node. The <lat>
and <lon> defines the latitude and longitude respectively of the terminal.


\code{$ns_ satnode <type> <args>}\\
This is a more primitive method for creating satnodes of type <type>
which can be polar, geo or terminal. 


\code{$satnode add-interface <type> <ll> <qtype> <qlim> <mac_bw> <phy>}\\
This is an internal method of Node/SatNode that sets up link layer, mac
layer, interface queue and physical layer structures for the satellite
nodes.


\code{$satnode add-isl <ltype> <node1> <node2> <bw> <qtype> <qlim>}\\
This method creates an ISL (inter-satellite link) between the two nodes.
The link type (inter, intra or cross-seam), BW of the link, the queue-type
and queue-limit are all specified.


\code{$satnode add-gsl <ltype> <opt_ll> <opt_ifq> <opt_qlim> <opt_mac> <opt_bw> <opt_phy> <opt_inlink> <opt_outlink>}\\
This method creates a GSL (ground to satellite link). First a network
stack is created that is defined by LL, IfQ, Qlim, MAC, BW and PHY layers.
Next the node is attached to the channel inlink and outlink.


\end{flushleft}

\endinput