Radio-WAN Media Access Protocol

Buddenberg/Feb2003

Need for MAC attention, the problem.

A radio-WAN Media Access Control Protocol is needed. This protocol must perform these functions:
  1. tell network nodes when they can transmit. Necessary to avoid multiple simultaneous transmissions which collide. Since a radio network segment may have hundreds or thousands of nodes under its footprint, there is a substantial scale issue. Generically this is analogous to ethernet CSMA/CD and token ring token passing protocols.
  2. provide a means for new nodes to enter the network segment. This is a different problem than that encountered in the office ethernet which is largely stateless. Because all subscriber nodes must be managed by a controller, we necessarily have to accept some state in the MAC.

This MAC problem must account for the 'hidden node' problem. Coaxial cable ethernet functions as a big party line and the MAC protocol rests on the assumption that everybody can hear everybody else. It also rests on the assumption that propagation times over the LAN segment are negligibly short. Neither of these assumptions apply to the radio-WAN issue so we can't simply borrow a solution from the LAN protocols. But we can borrow part of the solution and the framework, to considerable profit.

Treat radio-WAN like LAN.

We need to discount some of the suggested solutions. Many radio data link engineering attempts try to borrow from the terrestrial WAN technology. But terrestrial WANs are designed to connect routers (or switches) with point-to-point connectivity such as T or OC lines (copper and fiber respectively) Because the connectivity is not shared, there is no need for a media access protocol at all and indeed the terrestrial WAN standards (X.25, frame relay, ATM, ...) all lack MACs entirely. Now a quick scan of LAN technology:
  1. Ethernet uses carrier sense (called CSMA/CD) -- everybody in collision domain can hear everyone else. This is a single queue model and that queue is a contention queue. Both network entry and data passing functions are handled by the contention queue. Qos: The construction of ethernet's MAC is such that it optimizes interactivity (and simplicity of implementation) and trades off bandwidth efficiency to get that interactivity.
  2. token systems (802.5, 802.4, FDDI) all assume nearest logical neighbors can hear each other -- also not the case here. Qos: Token systems are highly bandwidth efficient but trade off interactivity. And token systems are somewhat more complex in implementation.
Neither of these approaches meets the needs of a radio-WAN MAC, but the IEEE standards approach does hold considerable prior art and structure that can be reused. See Radio-WAN Building for the structural discussion.

Requirements for a radio-WAN MAC.

These requirements would pertain to any solution, not just a satellite communciations one. Therefore it makes sense to generate a general protocol framework and solution that can be ported to other radio-WANs beyond the programmatic scope a single satellite constellation to avoid the expense of reinvention and to gain a marginal improvement in interoperability through commonality:
  1. The primary requirement is to discipline network nodes so they transmit one at a time. The solution space becomes restricted to scheduling and polling algorithms by recognition of this requirement.
  2. Provide a means for new nodes to enter the network segment. Most prospective solutions envision a second queue for management of this problem. That queue can be either in-band or out-of-band. The solution sketched below uses the in-band approach but doesn't affect any out-of-band option options.
  3. Support multicast. This definition of multicast is slightly different than the layer 3 definition (delivery to multiple platforms for price of a single transit through each router). At the data link layer, the proper definition is delivery to multiple platforms for the price of a single transit through the radio-WAN. This requirement includes the need to map to IP multicast correctly (like IEEE 802.1p does for ethernet switches) to the data link layer.
  4. Support urgent access for priority traffic. This is one facet of the Quality of Service control problem.
  5. Synchronous access for those customers with requirements for determinism (often incorrectly stated as 'need a serial line'). A second facet of QoS control.

Constraining knowledge. Other considerations that our research has acknowledged: radio circuits involve transmitter 'spool-up times'. This is different than a baseband copper or fiber optic LED or laser diode emitter. Additionally modem and cryptographic synchronization overhead is part of the spool up that conventional wired networks don't have.

And the propagation times in satellite-based networks are very restrictive -- the option of polling networks becomes hard to envision, leaving us with scheduling ones.

Existing art.

Some existing satcom systems (Navy CUDIXS) have some radio-WAN protocols. The run-up to Navy FLTSATCOM included CPODA work at NRL which was on the right track but not used. Navy ADNS didn't rework any of the FLTSATCOM access protocols, but did reimplement them in the Channel Access Protocol renderings. These protocols tend to be unique for each satellite system ... indeed in the case of Navy fleet satellite commications (currently known as UFO for UHF Follow On), each user community (IXS) has a different access method.

We should discount the IEEE 802.11 approaches to the problem -- they won't meet our needs. The wireless LAN solutions warp ethernet CSMA/CD solution by adding a beacon (often called CTS/RTS) at the access point that suppresses competitive transmitters until the reason for the beacon (a node sending data) is finished. This only works in situations with low propagation times. 802.11 still uses a single queue model and the single queue is contention-based. The IEEE 802.11 standard contains a point distribution control function specification which could potentially be used as an API to shim-insert a MAC algorithm. But none of the chipset manufacturers have apparently included this feature.

Both IEEE 802.5 token ring and ANSI FDDI token rings included provisions for priority traffic (four and 8 levels respectively) and FDDI supported early token release which partially met the priority access requirement. FDDI also supported synchronous service. In all these cases, the features were suppored in the standards and in the chipsets, but almost never used in practice.

I've poked at this problem off and on for 15 years (a chapter in my own masters thesis). I'm only to blackboard stage. Additionally, I know of one other researcher (Graham Campbell) who's done work that appears to scale into the problem but he's not yet to working prototype stage. The solution sketched below is drawn from my masters work which captured all the requirements noted above except for synchronous service; this version includes an approach to that requirement.

One example of a radio-WAN MAC.

There are two ways to centrally manage a net: polling and scheduling. Polling algorithms (example: Link 11) work in cases where propagation time can be ignored. But in cases, such as satellite hops, where propagation time is significant, polling algorithms become prohibitively inefficient, leaving us with schedules.

A. scheduling algorithm description

  1. Step 1. The commsta (synonym: net control) sets up a cycle. Initially this cycle is populated with two parts: 1) a time segment for a non-contention queue. Eventually this will be populated by all nodes but initially the commsta's traffic queue is the only traffic, and 2) a contention queue for customer nodes to request access. This cycle is advertised to all potential customers by transmitting this initial schedule in band as a Layer 2 overhead packet in the commsta queue.
  2. Step 2. Any customers with pending traffic (or need to get a reservation in the net while anticipating traffic) compete for the commsta's attention by sending Layer 2 setup request packets during the contention queue time. Because of the contention, some request packets will collide and fail; but others will succeed. A Layer 2 request packet is an overhead packet with the station's identity (e.g. 'MAC' address) and data on the nature of the request (buffer examination -- how much traffic of each priority level, need for synchronous service, etc).
  3. Step 3. The commsta receives the successful Layer 2 request packets and adds time allocations for those customers to the first (non-contention queue). This schedule is communicated to the entire population in the succeeding cycle. Note that the customer nodes that have allocated time slots disappear from the contention queue, increasing the likelihood that the remainder succeed in passing a request packet.
  4. Step 4. Each customer node sets its watch and transmits only when its time slot is available. Most of the time slot can be expected to be devoted to payload (Layer 3) traffic, but the last packet out is the Layer 2 request packet for the next cycle (i.e. what traffic remains in the send buffers). Whether the customer uses a strict priority system or some leaky bucket (fair queueing) arrangement is a local matter as long as that node remains within its time slot. The commsta collects all the Layer 2 request packets and uses the data therein to calculate the succeeding schedule. In the case of propagation delays exceeding the cycle time, interleaving can be inserted which renders the system bandwidth efficient.

Disengagement from the network can be done in a variety of fashions including simply stopping transmission. The commsta detects no traffic in the allocated time window and eventually times out the allocation. A more graceful MAC disconnect would result in a bit more efficiency (reclaiming the unused allocation). A halfway ground might be for the commsta to include a silent host in its schedule (non-contention queue) but with a very small allocation -- only large enough to get out an overhead packet so that node will get full service in the next cycle. This kind of approach can accomodate the intermittencies associated with moving communications nodes that are occasionally shaded or otherwise unable to communicate on the instant but need to remain 'in the system'. In any event, a non-transmitting station can passively receive.

Synchronous service is provided by the commsta making sure that a customer node needing it gets the same time slot (or set of time slots) each cycle. This 'time division multiplexing' would make the service look somewhat like a T1 allocation. If the requirement is simply for expedited service, then the MAC has done it's job and it's up to a priority queueing arrangement in the router (e.g. at Layer 3) to act. If the requirement is truly for deterministic service (i.e. bounded delay), then an interface that bypasses IP and reaches directly to Layer 2 is required. (The unpopularity of this approach is one of the reasons that the priority and synchronous features in token LANs were rarely used).

Benefits -- bandwidth efficient. The scheduling algorithm sketched is bandwidth efficient -- it maximizes the amount of time used for communications by minimizing overhead time:

Drawbacks -- not very interactive. A TCP three-way handshake requires 1+1/2 cycles to complete. Further, if a station has to negotiate entry into the noncontention queue as a prerequisite to sending any traffic, the startup latency could be increased even further. This makes this MAC approach quite suitable for bulk operations such as multicast file transfers or staging of web data onto local servers or for e-mail MTA operations. But it is a poorer fit for highly interactive applications (I shudder to think how telnet or ssh would operate over such a link).

My analysis of Graham Campbell's DQSA algorithm. Graham Campbell performed parallel research while on the faculty of Illinois Institute of Technology (ref http://www.iit.edu/~dqrap/):

  1. we agree on the dual queue structure. I have seen similar research (most much more naive) which always seems to get to the same dual queue conclusion.
  2. Campbell's algorithm is more interactive. But it requires fast transmitter spool-ups so if those 'taxes' are significant, will result in inefficiencies.

One size will probably not fit all.

There is a philosophy in IETF learned from the evolution of routers. The basic function of routers is packet forwarding and that function has not changed at least since IPv4 has been stable. The earliest and most recent routers do the same thing. But the algorithms for network convergence -- routing information protcols -- have undergone continuous evolution since. This partition of mechanism and algorithm approach makes sense in a radio-MAC.
  1. build a mechanism. An ability to 'shim' an algorithm into the protocol stack can be built. Currently LAN chips on NICs are monolithic and don't allow this kind of API access.
  2. algorithms -- try several, pick a couple. This allows us two features: 1) We can do some experimentation without having to change the framework and 2) since different communities may want to optimize different qos characteristics, the adaptability to change algorithms appears useful. (It appears that bandwidth efficiency and interactivity optimizations are always mutually exclusive).

HF-specific issues

Up to this point, the radio-WAN discussion applies equally to any part of the spectrum and, for the most part, cares not whether there's a relay (e.g. satellite). This section specifically addresses those issues pertinent to the HF (and low band VHF) part of the spectrum where ionospheric refraction is a key feature in gaining long distance.

Definitions. HF uses have tended to divide into three areas:

If we target the third (ELOS) as the appropriate niche for HF radio and ignore the other two, we can treat the HF network as a single segment one where all net members are on the same frequency. If we add more complexity in the form of different networks on different frequencies, then we simply have multiple HF segments that are best bridged together with a LAN switch (see previous discussion about Logical Link Control).

Spectrum allocation myths. HF bandwidth has traditionally been allocated in 5kHz slices of which 3kHz is used for communications with 1kHz on either side as guardband to minimize interference with adjacant channels (efficiency hacks such as single sideband and independent sideband are essentially tweaks to the old paradigm). Note that the 3kHz of 'talk capacity' is identical to the 3kHz that the circuit switched telephone system allocates to each telephone call. This 'way we've always done it' gives each link about 10kbps capacity that can be adjusted at the margins depending on atmospherics, burst noise, and how much money we put into the modems. But the 5kHz allocation is an administrative convenience based on the assumption of analog voice -- this is the way we've always done it. Not digital voice and certainly not router-to-router interconnect.

If we reallocate the spectrum in larger slices on a per-radio-WAN basis rather than a per-link basis, then we can use the spectrum much more efficiently.

Existence proof. The author once viewed an experiment at SPAWAR Systems Center San Diego where an HF data link was set up in extended line of sight circumstances. In this demonstration, several existing adjacent HF channels (9 if I remember correctly) were amalgamated into a single, 45kHz-wide channel and two radios were specially built to use the single wide channel. The modems used some forward error correction to clean up burst noise; after subtracting this overhead, the link operated at 56kbps with very few uncorrected bit errors. (Unfortunately, I've been unsuccessful in my attempts to unearth the writeup of this experiment).

Impelling reasons. In addition to efficiency issues, decreasing the number of HF emitters on a platform has a number of other benefits. There are a variety of interference issues in HF (intermodulation interference, rusty bolt syndrome, etc.) that tend not to be a problem in frequency bands above VHF. These tend to keep HF in the 'half duplex' mode -- if any HF transmitter on a ship is operating, none of the HF receivers on the same ship will work well. Reorganizing the HF transmitter on a ship on a wideband general purpose network basis, rather than the existing one-radio-for-one-application approach decreases the interference problem.

Conclusion.

This MAC research and development will need to be undertaken in any radio-WAN regardless of whether an internal routed or bridged architecture is developed. And the development must be done regardless of frequency band intended to be used.

The scheduling method illustrated above can be implemented wholly in band. If the contention queue is moved out of band -- which is entirely possible -- then the system resembles the existing 'orderwire' and 'DAMA' setups. The drawback to this approach is that terminals need two RF implementations where the in-band approach requires only one.

It would appear that an open standards body approach would yield better return on the development dollar than putting such a development into a single acquisition program which would tend to yield yet another acqusition-specific solution.