Lessons in Designing LEOs: Part 1
Low Earth orbit satellite systems promise prolific bandwidth on demand in virtually any part of the globe. Successful LEOs rely on a myriad of business model details and decisions, which must converge with engineering state-of-the-art reality. This first in a two-part article examines some of the difficult design trade-offs that must be made.
By Steven Leeland
LEOs represent ultimate challenges in business planning, program planning and execution, and cutting-edge
technology. LEOs are the projects of the millennium, equivalent to the exploration of the Moon, the building of the Panama Canal, and even the construction of the pyramids. Earth-bound fiber optics and both analog and digital cellular systems are rapidly spanning the globe. Fiber companies have announced that their completed projects will instantaneously triple worldwide bandwidth. Fierce competition makes for perilously short market windows of opportunity.
System and design engineers face daunting tasks of
their own. LEO system specifications demand the maximum bandwidth per dollar to justify the billions of dollars in business investments. Left with no other viable alternative, technology that has yet to be invented is drafted. More pins and gates per ASIC and higher clock frequencies than have ever been used before in radiation-hardened technology are just samples. This is not our fathers’ engineering, where off-the-shelf and lowest-cost are the rule. Although confidential and proprietary information
will not be disclosed, many LEO satellite payload concepts are general enough to be of interest.
Trade-offs
Because almost all the parameters are inter-related, the convergence of business and engineering is complicated. Question number one must be: What services are to be provided? The second question is: Who are the customers? Customers drive the coverage zones needed. Global coverage requires more satellite orbital planes and space vehicles. Fixed location businesses can achieve a
high percentage of coverage by limiting the LEO system to a range of 60º S to 72º N latitude, potentially decreasing the number of space vehicles.
A large percentage of the LEO business investment is determined by the number of space vehicles needed. The cost of both the vehicles and the launch can be astronomical. Two more factors affecting the space vehicle count are incidence angle and altitude. Lower allowable angles from the ground equipment to the space vehicle allow for a wider
cone of coverage and a larger field of view (FOV) per vehicle. Greater orbit altitudes also increase the FOV per vehicle, but with a penalty — greater altitudes incur greater radiation exposure.
Space-vehicle circuitry exposed to high levels of radiation incur two forms of phenomena. Single-event upsets (SEU) can occur when radiation particles cause a temporary change in a circuit’s state. These kinds of phenomena can be handled with triple mode redundancy (TMR) techniques, at the expense
of additional hardware. A far worse phenomenon is the continual accumulation of radiation deep in the solid state substrates that eventually renders them inoperative. Time-to-failure is a function of radiation intensity. Solving this problem usually requires designing ASICs, and having IC vendors build these ASICs with special radiation-hardened (rad-hard) technology. Because of the small volumes involved, this is quite expensive both in up-front costs and in per-ASIC costs. Space vehicle payload control
usually requires many on-board computers, and these parts must also be rad-hard. Design qualification for microprocessors is arduous and not a desirable addition to the LEO program burden. This task is best left to an IC vendor willing to purchase the intellectual property (IP) and manufacturing rights to build a rad-hard version of an existing microprocessor. When altitudes are low enough, certain techniques can be employed to use more commercial off-the-shelf parts. It is sometimes possible to package the
entire payload electronics in a radiation absorbing material. However, the added material consumes payload size and weight, which are at a premium.
In real estate sales, the watch-words are “location, location, location;” for stock markets its “earnings, earnings, earnings;” and for space vehicle payload design (LEO, GEO, or otherwise) it’s “SWAP, SWAP, SWAP.” Size, weight and power (SWAP) are everything. Virtually every system specification change affects the
payload design and impacts the SWAP. SWAP estimate refinements are made continually throughout the specification negotiations. While a space vehicle’s payload weight may be negligible, if it’s size is too large, a space vehicle won’t fit into any launch system. Conversely, payload size can be miniscule, but if the vehicle is too heavy, the launch system won’t be able to lift it. And finally, power is generally provided by solar panels which consume size and weight. The more power burned by
the payload the bigger the solar panels must be. Also, LEOs are expected to work on the dark side of the Earth, requiring the use of batteries, which consume still more size and weight. Additionally, batteries suffer a peculiar fate due to their special design — they cannot be allowed to drain below a certain power level, or death ensues. Ensuring that this does not occur requires sophisticated power management under both hardware and software control.
LEO space vehicle payload developers are
most likely to be communication powerhouses, so space vehicle infrastructure is probably not their primary area of expertise. For this, a bus provider must be selected. Basic space vehicle structures sans communication payloads are known as buses. Buses consist of the mechanical structures and panels on which everything else (such as attitude control thrusters and fuel, navigation gyroscopes, command and control telemetry systems, solar panels, and batteries) mounts. Careful analysis and trade-offs occur in
this arena as well. A batch of bad gyroscopes could turn half the fleet into exorbitant space junk, and more fuel adds more weight. Less fuel can reduce a space vehicle’s useful life to a handful of years. At the end of the space vehicles’ normally planned lifespan (about 5 to 8 years), they must have enough fuel remaining for decommissioning. At this point, more choices must be made. Remaining in its original orbit as space clutter is not an option. Only two choices exist: either blast the
vehicle to an orbit farther out of the way, or take it down into the atmosphere for a fiery extinction.
Another major LEO implementation factor concerns intersatellite communications. Will data packets be routed between space vehicles, or will they be downlinked to the closest local gateway? Will the payload be more complicated, placing more hardware, weight, and cost into orbit with less ground-based facilities, or vice versa? Which makes better business sense? It is up to LEO business planners to
answer these questions. If intervehicle routing is deemed best for LEO system performance, then other factors must be considered. Will the intervehicle links be between neighboring planes or will they cross planes as well? What happens at the poles? If the links must be resynchronized, how long will it take — seconds or minutes? Lost links can cause longer routes and potentially lost revenue on guaranteed delivery time traffic. How will the links be implemented? Broadband technology is a known quantity but
might not have the desired bandwidth-to-SWAP ratio. Lasers have outstanding data rates but might be more untried or have longer acquisition times.
Interference with existing systems is a real likelihood. No matter how early a LEO spectrum is allocated, some technologically advanced countries will already have their own geosynchronous orbit (GEO) satellite services already in place which cannot be easily accommodated. In these cases, it may be necessary to modify bandwidths by going to half or
quarter data rates over their boundaries. Competing LEOs must not interfere with previously placed LEO systems. This requires that they be completely aware of the competition’s ephemeris data, shutting off beams whenever it appears they would interfere.
Inter-box communications within the space vehicle payload offer more opportunities for trade-off analysis. For status and control, payload computers must communicate with all other modules such as modems, alignment, RF, IF, data packet and
communication switches, input and output data packet buffers, and uplink and downlink beam controllers. Many commercial standard communication buses exist, but strictly deterministic bandwidth is required (similar to token bus technology, IEEE-488, or avionics buses). Since it must be implemented in rad-hard technology it must be redesigned anyway. Therefore, the opportunity exists to make a proprietary bus and switching system. Some boxes may perform all calculations on the fly, while others may require massive
table processing and uploading from the payload computers. It is also possible that some of these links may need to be dedicated.
Bandwidth revenue is affected by the selected data packet sizes compared to the number of header bits required. Packets that are too small increase overhead ratio and eat into the profit stream. Packets that are too large can cause problems for the ground equipment data packing. Also, some traffic may inherently consist of small back and forth pings. One critical item
in the header is the packet’s destination address. A scheme must be devised to tile the surface of the Earth with fixed locations using a minimum number of address bits. This tiling scheme must also be compatible with whatever minimizes payload downlink complexity or risk. Numerous schemes exist such as graphical icosahedron subdivision, irregular triangular subdivision, fixed resolution latitude and longitude coordinates, various variable-sized hexagonal approaches, and fixed-sized square tiles with
latitude stripes of varied lengths. Some of these can be immensely complex to generate online and could require large look-up tables in payload hardware (memories that consume SWAP). Other approaches suffer from the phenomena that increases address aerial density in latitudes closer to the poles. This is undesirable for the look-up table approach, but would minimally impact compute-on-the-fly techniques. Another option for this case assumes the possibility of only storing nonoverlapping address areas in the
table. Unfortunately, for most of the globe, they do not overlap sufficiently to allow skipping every other address area.
Switch scheduling
The data packet switch lies at the core of a LEO space vehicle payload. Symbolic of the entire network, the space vehicle payload is simply a giant switch in the sky.
Figure 1
outlines a generalized switch. It performs the same basic function as its terrestrial brothers — ATM switches, TCP/IP switches,
and LAN bridges. Basically, the switch transports data packets from its input ports to the desired destination output ports. For the LEO application, these ports connect with space vehicle uplink channels, intersatellite input and output channels, and downlink channels. Basic switch technology is a somewhat mundane multiplexer, albeit blazingingly fast. A 60-Gbps specification is quite possible for a high-performance data rate LEO, and any output port can be connected to any input port. Although the actual
switch hardware can be commanded to simultaneously connect two output ports to the same input port, this is not the normal modus operandi. Switch input and output ports need not match in quantity. Every input port requires a data packet buffer, and while output ports usually require data packet buffers, they can be very small if the output channel rate exceeds the switch packet transport rate.
Switching theory has long shown that for FIFO-type input buffers, as the number of switch input and
output ports grow, switch efficiency approaches an abysmal 63%. Switch efficiency here is defined as the number of actual data packets transferred compared to the absolute maximum possible. Head-of-line blocking is the culprit behind this limitation. When two or more input buffers have packets destined for the same output buffer, the switch can only take one at a time. Two common techniques dramatically improve switch scheduling performance. One technique involves look-ahead buffers on the input side of the
switch, which can be employed to x-ray back through the input buffer FIFO to see the last several packets. Switch scheduling is thereby improved due to the greater number of routing options. Virtual output queuing (VOQ) yields the best performance-to-SWAP ratio by far. In VOQ, each input buffer maintains a separate queue for each destination port. Switch scheduling is thereby optimized due to the maximum number of routing options.
Another common switch throughput performance enhancement involves
over-speeding the switch packet transport rate. Actual switch design may not be impacted much, except for the power increase caused by the higher clock frequencies.
Complexity in a switch resides in the scheduling mechanism. Schedulers receive packet destination port data via each input buffer. From this input, they determine the highest possible traffic route through the switch for the next switch packet transport cycle. Switch configuration is commanded, and all input buffers are directed to send the
specific packets that are destined for the selected output ports. Three more hurdles hinder switch scheduler design. Fairness doctrines must be incorporated to allow input ports equal access opportunities to the same output port. LEO traffic revenue models generally provide for different levels of service. In actual practice, this implies prioritized traffic data packets. Schedulers must guarantee that all higher priority traffic is scheduled, as much as possible, before any lower priority traffic is
scheduled, and as a result timing constraints or gate count can skyrocket. For a 60-Gbps switch, the ultimate scheduling constraint allows only a meager couple hundred nanoseconds to conclude scheduler considerations. Of course, that’s not including the impact of any switch over-speeding.
Setting aside implementation details for the moment, what algorithm can accomplish these actions? Consider the 3 x 3 switch example-scheduler input matrix of
Table 1
. Three
priorities are assigned here, with the lowest value representing the highest priority. A 3 indicates that no packets from the input port are currently destined for this output port. Initially, priority 0 packets are scheduled — as many as possible, then priority 1, and so on until the schedule is as complete as possible. Once a matrix cell has been selected for scheduling, its row input port will be connected to its column output port in the next switch data packet transport cycle. This has the effect of
eliminating its row and column from the input matrix in further consideration rounds. For each cell picked, it is desirable that it have a minimum of alternative choices in its row and column, thereby maximizing the probability that choices will remain for other rows and columns. A scoring scheme can be invoked to enable this algorithm:
Cell score = P012CR
where:
P = packet priority requested in input matrix cell
0 = number of cells in the same row and column
containing priority 0 requests
1 = number of cells in the same row and column containing priority 1 requests
2 = number of cells in the same row and column containing priority 2 requests
C = column fairness generator (tie breaker), reset at next switch cycle to winning cell
R = row fairness generator (tie breaker), reset at next switch cycle to winning cell.
Row and column fairness generators ensure equal access to output ports from competing input ports.
Tables 2 through 4
tally the scores for this example. In each round, the lowest score is selected. Next, the other cells in the same row and column are marked unavailable and the input matrix is rescored to account for these changes. Subtle modifications to the algorithm can be made to reduce gate count and execution time. Eliminating rescoring between rounds would seem to violate the spirit of the algorithm, however, massive simulations on random traffic patterns
reveal little if any adverse effects on switch efficiency.
Is it possible to reduce such an algorithm into physical practice, and have it remain viable for a LEO space vehicle payload? Yes. For a 13 x 13 switch, a one-hot encoded arithmetic in a three-dimensional systolic array approach can be implemented in under a million gates, which is a bit too close to the rad-hard ASIC limit for comfort. Another undesirable feature is gate count which grows in accordance with the following function:
Gate count = f(I * O * max( I, O ))
where:
I = number of input ports
O = number of output ports.
For an acceptable solution, terrestrial switch literature contains an elegant, standard technique — iterative round robin matching with slip (IRRM-SLIP). Various modifications abound, but the basic algorithm operates in rounds as follows:
- Each input port sends a request to each output port for which it has available packets
destined.
- Each output port sends a grant to its highest priority request.
- Each input port selects its highest priority grant and sends an acknowledge to the output port. Once selected, both input and output ports set their next switch cycle port priorities to the port after the one selected. If more time or ports remain, then continue with as many rounds as necessary or possible (<= max (input ports, output ports)).
To handle the prioritized LEO traffic pattern,
the algorithm can be modified as follows:
- Set priority to highest.
- Execute IRRM-SLIP for only the current priority packet requests.
- If not finished, set priority to next lower value and repeat at step 2.
Hardware gate count is an order of magnitude smaller to implement. Technically, this approach does not necessarily yield the maximum possible switch throughput. However, simulations on random traffic patterns reveal switch efficiency to
be within a few percentage points of the theoretical maximum.
In Part 2…
So far, we’ve examined some of the engineering trade-off decisions that play a role in the development of LEO-based communication systems, and taken a look at switch scheduling plans. Next month, we’ll delve into antenna beam configurations, beam-steering calculations, and some trigonometric trickery that can aid the calculation process.
Steven Leeland has served as a systems
analyst/contractor on the Motorola/Teledesic project. He received his BSEE and MSEE from the University of South Florida as a magna cum laude graduate in 1976. He can be reached at
Steven.Leeland@worldnet.att.net
.
Return to the
Table of Contents
Puzzled by a network processing design issue?
