17.3.3 Detailed look at satellite links

Figure 17.6: Detailed look at network interface stack.

Figure 17.6 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 ~ns/tcl/lib/ns-sat.tcl contains the various OTcl instprocs that assemble links according to Figure 17.6. We describe the composite structure herein as a ``network stack.'' Most of the code for the various link components is in ~ns/satlink.{cc,h}.

The entry point to a network stack is the SatLinkHead object. The SatLinkHead object derives from Class LinkHead; the aim of link head objects is to provide a uniform API for all network stacks. ^17.4 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 type_ field are currently found in ~ns/sat.h. Finally, the SatLinkHead stores a boolean variable 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 ~ns/satlink.{cc,h}.

Packets leaving a node pass through the SatLinkHead transparently to the 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 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 class LL derives from class LinkDelay, the 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 17.6. 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 satlink.h and the 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 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 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 SatChannel, which copies the packet to every receiving interface (of class 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 ErrorModel object, if it exists. If not, the packet moves through any receive tracing objects to the SatLL object. The SatLL object passes the packet up after a processing delay (again, by default, the value for delay_ is zero).

The final object that a received packet passes through is an object of class NetworkInterface. This object stamps the 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 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 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.