RDRN Network Control
In this section, we will present the RDRN adaptive protocols and the Network Control Program
(NCP) that manages those protocols.
RDRN Wireless ATM Protocols
The RDRN protocol stack is shown in the figure. This stack is implemented in the Edge Nodes (ENs)
and the Remote Nodes (RNs). On the other hand, radio link management is only implemented in the ENs.
A list of the networking protocols implemented in the RDRN prototype is listed in the following table:
| Protocol | Management |
|---|
| TCP/UDP | |
| IP | IP Routing |
| IP over ATM | Classical IP over ATM |
| AAL 5 | |
| ATM | Q.2931 and RDRN NCP |
| Adaptive HDLC | RDRN NCP |
| Radio Link | RDRN NCP |
RDRN protocols and management components have been implemented in the Linux operating system running
on Intel x86 compatible computers. Linux provides an open development system with many contributors
around the world running on a wide variety of computer architectures. The system supports applications
running over both native-mode ATM as well as TCP/IP over ATM. There has been considerable development
work done to support standard ATM on Linux by researchers at the Laboratoire de Reseaux de Communication
(LRC) at EPFL in Switzerland. In particular, they have developed a BSD-sockets based application
programming interface (API) to support native-mode ATM applications as well as support for Classical
IP over ATM for TCP/IP based ATM applications.
The RDRN NCP supports applications through the standard UNIX socket interface to the networking
protocols within the operating system kernel. The socket interface provides conventional TCP/IP
services and ATM services. Applications can interface to the ATM service either through a framing
protocol, such as AAL5, or raw ATM cells. Within the kernel, the network layer implements the
Internet Protocol (IP), whose primary purpose is to provide routing between subnetworks and service
for the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and other transport layers.
Classical IP (CLIP) and ATM Address Resolution Protocol (ATMARP) are initial standard solutions for
carrying IP traffic over the ATM links. However, it has several weak points such as requiring a
router to connect separate Logical IP Subnets (LIS), even when the subnets are directly connected
at the ATM level, and requiring an ATMARP server to provide address resolution for a single LIS.
The non-broadcast multiple access Next Hop Resolution Protocol (NHRP) provides a better solution
but it is still in draft form. The RDRN architecture implements CLIP and supports both Permanent
Virtual Circuits and Switched Virtual Circuits via ATMARP.
To this base system we have added four software components in our prototype system: (1) the
Bellcore Q.Port ATM signaling system, (2) an ATM driver for handling AAL5 protocols, (3) an
ATM cell switch, and (4) a driver for our wireless links. The Bellcore Q.Port system provides
a reference implementation of the ATM User-Network Interface (UNI). This software is used for
call setup and teardown, virtual circuit management, and interoperability with wired systems.
The ATM driver for AAL5 is a custom software componet that can interface to conventional ATM
interfaces and/or our wireless interface at the frame level and handles the encapsulation of
IP for the network layer. The ATM driver also distinguishes between virtual circuits (VCs)
that carry AAL5 frames and those that carry raw ATM cells. In the case of VCs carrying AAL5
frames, segmentation and reassembly functions are handled in hardware on conventional interfaces
and software for the RDRN wireless interface. Otherwise, for non-framed VCs, single ATM cells
are handed to the ATM cell switch for switching to other VCs and then passed to the appropriate
interface. The ATM cell switch is not present in Remote Nodes.
RDRN nodes implement an Adaptive HDLC link layer over the wireless link. ATM cells are
collected into a modified HDLC frame, called the Wireless ATM frame or WATM frame, for
transmission. In the case of Edge Node to Edge Node traffic, ATM cells from any VC can be
included in the WATM frame. In the case of Edge Node to Remote Node traffic, ATM cells must
be sorted into separate queues, one for each Remote Node. Only cells destined for a single
Remote are included in the WATM frame for transmission under the TDMA media access protocol.
The WATM frame consists of a Start-of-Frame flag (1 byte), a Link Identifier (1 byte),
a Control Byte (1 Byte), one to nine ATM cells (53-477 bytes), and a 16-bit CRC field
(2 bytes). Multiple ATM cells are included in each WATM frame to reduce the effect of
encapsulation overhead necessary for addressing in the TDMA access mechanism and error
control. No ATM header compression is used at this time. Likewise, we have not included
forward error correction in the WATM frame. The number of ATM cells in a frame is based
on resources at each end of the link and the link condition.
Radio link quality at the link level is estimated by counting the number of WATM frames
received in error. This information is communicated upstream to the transmitting node.
The HDLC link layer adapts to link quality in two ways. As the link quality goes down,
fewer ATM cells are included in each WATM Frame. Thus, any noise burst or fade over a
few tens of microseconds will cause fewer ATM cells to be dropped. The second technique,
used for loss-sensitive traffic, is to transmit multiple copies of the WATM frame, for
example two or three copies. Experiments have shown that WATM frame length adjustment
with up to two copies of each frame transmitted is sufficient for most situations. The
protocol uses a sliding window and go-back-N ARQ scheme.
Network Control Program (NCP)
The RDRN Network Control Program (NCP) is the primary control program for the system.
As such, it monitors the backbone topology, locations of Remote Nodes, computes antenna
beam patterns, and implements connection handoffs between antenna beams and between Edge
Nodes. The NCP executes on Edge Nodes. To perform these functions the NCP monitors Remote
Node locations and link quality to make decisions on configuration changes. The NCP causes
antenna beams to be adjusted as Remote Nodes move and re-routes ATM virtual circuits as
Remote Nodes move between beams and Edge Nodes.
Maintaining Backbone Topology
The current RDRN implementation assumes Edge Nodes remain stationary during operation
of the network. However, Edge Nodes can enter or exit the system causing backbone topology
changes. As mentioned above, our algorithms for determining backbone topology are based on
a consistent labeling approach. In consistent labeling, constraints are expressed as pair-wise
constraints, e.g. if node A transmits to node B on frequency F, then node B can transmit to
node A on any frequency except F. The consistent labeling algorithm considers all pair-wise
constraints and determines a consistent labeling of all links.
The consistent labeling problem is a generalization of the graph coloring problem, the
cellular frequency assignment problem, and many others. Suppose one has cellular
frequencies F1...F7. Further, suppose cells A and B are adjacent and cell A is assigned
frequency F1. Then cell B can only use frequencies F2...F7. This constraint can be
expressed as a list of 4-tuples: {<A, F1, B, F2>, <A, F1, B, F3>,...,<A, F1, B, F7>}
indicating the allowable combinations of cell A, the frequency assigned to cell A,
cell B and the frequencies assigned to cell B. The consistent labeling algorithm
takes such a list describing the allowable combinations for all cell pairs and
determines a consistent assignment of frequency to cells meeting all the constraints.
The advantage of the consistent labeling approach is that multiple criteria, such as
frequency, beam direction, and spread spectrum code, can easily be included in determining
the backbone topology. The disadvantage is that the labeling problem is equivalent to the
graph coloring problem and, hence, is NP-complete. However, we expect that due to the
limited number of Edge Nodes, the computational speed of available computers, and heurestics
that can be incorporated into the implementation, that this approach is sufficient for an
RDRN type system.
Monitoring Locations of Remote Nodes
The NCP at each Edge Node monitors the location of nearby Remote Nodes through either
the orderwire link or inband signaling. From this information the NCP determines whether
to adjust an antenna beam to accommodate Remote Node motion or to switch the Remote Node
to a different beam. In the former case, the Edge Node considers the locations of all the
Remote Nodes within a current beam and computes new antenna beam patterns to maximize the
minimum signal-to-interference ratio across all remote nodes. In the later case, the
Edge Node moves a Remote Node to a new antenna beam, re-calculates the antenna beams for
the "source" and "destination" beams, and re-routes all necessary ATM virtual circuits.
In the current system, the beams are re-calculated every five seconds.
We have considered a system that predicts the motion of Remote Nodes. Future positions
of Remote Nodes are predicted from recent positions and computing a simple velocity vector.
Using predicted positions, the RDRN system can pre-allocate resources to make smoother
handoffs between beams or nodes. The modified system is described in.
Last Update: November 03, 1999 03:00pm (GMT-0600)