1596_Spaceway Overview Version 2.7 SPACEWAY White Paper

: Hughes Spaceway-White-Paper SPACEWAY-White-Paper 98e62fc0-48a3-0130-52b7-4040a5068ef5 uploads

Open the PDF directly: View PDF .
Page Count: 7

Download
Open PDF In Browser	View PDF

SPACEWAY NOW AND IN THE FUTURE:
ON-BOARD IP PACKET SWITCHING SATELLTE COMMUNICATION NETWORK
David Whitefield, Rajeev Gopal, and Steven Arnold
Hughes Network Systems, LLC
Germantown, MD
ABSTRACT

BROADBAND INTERNET OVER SATELLITE

Despite some predictions of the total demise of next
generation satellite systems, a working Ka-band
regenerative satellite system has been built and it is called
SPACEWAYTM*.
SPACEWAY provides a two-way
broadband “Internet in the Sky” IP network over satellite.
It utilizes on-board regenerative processing and on-board
packet switching with one-hop mesh connectivity between
satellite terminals in its spot beams.
This paper discusses the SPACEWAY system, its overall
architecture, its network services, and its capabilities as
built. It describes how the pieces of SPACEWAY are
layered together to provide a complete set of end-user IP
networking services. SPACEWAY has completed its
system design, system deployment, and system testing for
service availability in 2007. SPACEWAY implements the
internationally approved ESTI/TIA/ITU standard called
Regenerative Satellite Mesh – A (RSM-A) used for twoway single-hop regenerative mesh communications.
This paper further discusses how SPACEWAY can be
leveraged for a low-risk DoD-grade satellite system
providing
communications-on-the-move
(COTM),
information assurance (IA), virtual private networks
(VPNs), and policy management.

Current satellite system architectures that transport IPbased protocols generally use analog transponder satellites.
A major advancement in satellite technology includes
having digital processing on the satellite itself. This
satellite on-board processing takes the data packets it
receives on the uplink and routes or switches it to
particular downlink locations. It also demodulates the
uplink digital signal, digitally switches it, and then remodulates it to form the downlink signal ([1, 2, 4, 10]).
In the SPACEWAY next generation satellite system, the
downlink beam locations generally consist of narrow
beams (0.5 degrees) in order to provide dramatic increases
in system capacity due to frequency reuse among the
downlink spotbeams. On the uplink, focused areas from
the ground called uplink beams dramatically increase
system capacity due to frequency reuse among the narrow
uplink spotbeams. The uplink beam layout and frequency
reuse of the SPACEWAY system over North America is
shown in Figure 1.

SATELLITE COMMUNICATIONS
Up until now, satellites have been analog transponders
taking their uplink frequencies and shifting them to their
downlink frequencies in a “bent-pipe” fashion.
SPACEWAY is the next step forward in communication
satellites by being the first digital on-board
communications satellite. SPACEWAY takes uplink
frequencies and digitally processes them on-board the
satellite and switches the IP packets to their correct
destination to transmit them to the correct destination
downlink spot beams. SPACEWAY also provides other
advanced broadband IP networking services over satellite
including support for high performance guaranteed Quality
of Service (QoS) needed for voice and video applications
and also provides on-board Bandwidth-On-Demand (BoD)
needed for IP traffic that is often highly volatile. The
future of satellite communications is embodied in
SPACEWAY’s capabilities with its magnitude increase
beyond the capabilities of current bent-pipe satellites.
*

Figure 1 SPACEWAY Uplink Beam Layout

The use of on-board satellite processors provides
separation of the uplink from downlink by re-generating
the digital signal. This can save about 3 dB in the link
budget’s very important signal strength [9]. Satellite
demodulators on the uplink are assigned to particular
uplink spotbeams to listen to assigned uplink frequencies
called uplink sub-bands. The satellite’s uplink antennas
and demodulators are able to separate and differentiate

SPACEWAYTM is a trademark of Hughes Network Systems, LLC.

1 of 7

signals from satellite terminals transmitting from these
narrow uplink spot beams all the way from geosynchronous orbit.
Since the satellite is able to
differentiate these signals from these different uplink
beams, the satellite frequency plan is able to reuse the
same frequency in different uplinks gaining a major
increase in frequency efficiency.
Next generation systems that have been designed such as
SPACEWAY [4, 9], EuroSkyWay [1], and Astrolink [10]
and future generation systems such as TSAT [5, 6] make
use of these capabilities including regenerative digital
signals, packet switching or routing, frequency reuse, and
spotbeams.
SPACEWAY SYSTEM OVERVIEW

onboard via inband commanding from the NOCC with
combinations of channel rates of three 16 Mbps channels,
eight 2 Mbps channels for each 16 Mbps channel, or four
512 kbps channels for each 2 Mbps channel (i.e. up to 96
E1 carriers per subband) as shown in Figure 2. Using a
Time Division Multiple Access (TDMA) scheme for
uplink access, each channel is subdivided over time into
fixed sized uplink frames of 96 ms each. The uplink frame
is generally subdivided into 32 timeslots of 3 ms each.
Each timeslot is filled with an uplink burst that contains
one OQPSK modulated code block and is protected from
errors by robust Reed-Solomon forward error correction.
Each code block contains up to two 108 byte segmented IP
packets.
500 MHz

System Coverage: The SPACEWAY system consists of
multiple geo-synchronous (GEO) satellites with each
operating over a 500 MHz Ka-band frequency range for
uplink and for downlink. Its initial deployment will be for
the coverage area over the entire United States, major
population areas of Canada, and major South and Central
American cities. It would eventually expand to cover
Europe, Middle East, Africa, Asia Pacific, and Latin
America with the addition of satellites and orbital slots
based upon market demand.
System Segments: The SPACEWAY system consists of
the following major segments: the Space Segment (SS),
Satellite Terminal (ST) Segment, Network Operations
Control Center (NOCC) Segment, and the Service
Delivery System (SDS) Segment. The Space Segment was
designed and developed by Boeing Space Systems and the
rest of the system was architected, developed, tested,
integrated, and operated by Hughes Network Systems.
System Capabilities: The $1.8 Billion SPACEWAY
system is designed to support up to 1.65 million satellite
terminals with a gross capacity of 10 Gbps for each
satellite payload.
Satellite Terminal Capabilities: Satellite terminals are
capable of up to 512 kbps (aka ¼ E1), 2 Mbps (aka E1), or
16 Mbps (aka 8 E1) on the uplink depending upon their
antenna size and power. Terminals statistically share the
downlink burst rate of 30 Mbps in the same downlink
beam with fixed antennas starting as small as 74 cm.
SATELLITE TRANSMISSION LAYER
Uplink Frequency Plan: The 500 MHz Ka-band uplink
frequency range is subdivided into 16 subbands with 8 for
Left Hand Circularized Polarization (LHCP) and 8 for
Right Hand Circularized Polarization (RHCP) using
Frequency Division Multiple Access (FDMA). Each of
the 112 uplink beams can be reconfigured onboard to
utilize a subset of subbands depending upon its fixed
uplink polarization and frequency reuse constraints. Each
of these 62.5 MHz uplink subbands can be reconfigured

62.5 MHz
Subband

0

7
30.0
GHz

29.5
GHz

1

2

3

1

24

3

8E1 Channels per Subband

24

E1 Channels per Subband

96 E1/4 or E1/16 Channels
per Subband

MIXED CHANNELS/BURST RATE MODES ALLOWED WITHIN SUBBAND

Figure 2 Uplink Subband Channelization

Uplink Fallback: A dynamically assigned 128 kbps
channel rate is also available that occupies the same
frequency range size as a single 512 kbps channel. This
fallback mode provides for a more robust encoding scheme
such as during a Ka-band rainfade. This is dynamically
assigned to satellite terminals as needed for maintaining
link quality.
Uplink Power Control (ULPC): This is performed in a
closed-loop control system where the satellite payload
provides to satellite terminals the received Signal-to-Noise
Ratio (SNR) and timing correction information for each
burst. This allows a terminal to dynamically adjust its
power control to compensate for rainfades and interference
and to maintain synchronization.
Demand Assigned Multiple Access (DAMA): Satellite
terminals make Bandwidth-On-Demand uplink allocation
requests to the satellite’s on-board resource processor.
These can be in the form of rate requests (e.g. such as
requesting a number of timeslots from the system at a
constant data rate) or volume requests (e.g. such as
requesting a total number of timeslots for transmission).
Volume requests provide a normal priority volume traffic
class providing a best-effort service and also a high
priority volume traffic class providing better than best
effort service. The processor verifies that the allocation of

2 of 7

SATELLITE LINK LAYER
Terminal Authentication and Authorization: When a
satellite terminal is first introduced to the satellite network,
it must first register with the NOCC via special access
controlled channels in each uplink beam. Once it has
successfully been authenticated by the NOCC, it is given
derived authentication keys used to sign its data plane
packets and DAMA request packets sent to the satellite.
Data Admission Control, Classification, and Policing:
The satellite terminal provides admission control on data it
receives on its terrestrial Ethernet interface. The satellite
terminal provides classification of the IP packets,
segmentation and reassemble of the IP packets, and
association with the correct network resources such as data
queues to support the data’s QoS requirements. This

packet flow is shown in Figure 3. Classification of IP
packets may trigger a satellite connection setup request
such as due to receipt of an H.323 or RSVP packet by the
satellite terminal.
Satellite Terminal

NOCC
Connection
Management

Connection
Management

Connection
Management

Congestion
Management

Bandwidth
Control

DL Capacity
Allocations

CR 1

Bandwidth
Control

FPS Scheduler

DL x

FPS

B1 1

TP

Satellite
CAI

UP

SSTI

Bx4

Bx 1

DL 784

B14

PBP Scheduler

Demod

Flow
Control

Credits

PBP 1
PBP n

PEP Scheduler

TCP

PEP

PEP 1

Flow
Control

TP Scheduler

LVLL

Classifier

DL 1

CR n

RTP/UDP

PEP n

the request will not cause downlink congestion before
allocating.
Downlink Frequency Plan: Downlink transmissions
consist of 24 hoping Time Division Multiplex (TDM)
beams that service almost 800 downlink beams using a
phased array satellite antenna on the satellite. Twelve
transmissions are for LHCP and twelve are for RHCP
providing concurrent transmissions of each polarization.
Downlink Queuing: Each downlink beam has its own
downlink queue on the satellite that utilizes trail dropping
by packet traffic class priority when inserting data into the
queue.
Downlink Transmission Scheduling: For each downlink
timeslot, the downlink scheduler dynamically evaluates
which downlink beams have bursts ready to transmit,
which have increased downlink power due to rainfade, and
which other downlink beams have already been scheduled
to transmit in the same downlink timeslot that may
interfere. Frequency stay-out distance constraints are
enforced for all simultaneous transmissions of the same
polarization for each downlink timeslot. The 3 ms
downlink frame is subdivided into 138 timeslots. Each
downlink frame has downlink beams scheduled for
transmission in a round-robin fashion to provide fair
statistical queuing for each downlink spot beam. Each
downlink timeslot consists of twelve downlink QPSK
modulated code blocks for the same downlink beam. The
downlink frame is dynamically divided in a TDM fashion
between transmissions to large shaped beams and
individual narrow downlink beams.
Downlink Power Control: In order to overcome rainfade
for downlink transmissions, the system utilizes an adaptive
hybrid closed loop and open loop control mechanism. In
the closed loop mechanism, terminals can request for
increases in downlink power for their downlink beam. In
the open loop mechanism, ground-based radar is used to
pre-emptively predict where additional downlink power is
needed for each downlink beam.

Figure 3 Satellite Terminal Packet Processing and Interfaces

Reliable Link Layer: Each terminal can provide a
terminal-to-terminal reliable link layer on an as-needed
basis that buffers and retransmits dropped IP packets based
upon IP packet classification.
Token Buckets: Each satellite terminal polices each of its
traffic class transmissions to downlink destinations with a
token bucket mechanism in order to shape and flow
control the traffic and determine its DAMA request sizes.
Address Resolution: A satellite terminal inserts the link
layer address of the destination downlink beam and
destination terminal into the satellite link layer header.
This can be based upon pre-configured address resolution
entries or dynamically learned and cached entries from the
NOCC address resolution server.
Quality of Service (QoS): Data packets are marked with
the corresponding traffic class based upon satellite
terminal packet classification with rate traffic receiving the
highest quality of service and volume traffic receiving
best-effort quality of service. The highest quality of
service consists of less than 10E-5 Packet Loss Rate (PLR)
depending upon antenna size, one-way terminal-toterminal latency of less than 380 ms, and less than 100 ms
jitter. The marking can be based upon IP packet
classification of IP DiffServ codepoints in the packets.
Connection Admission Control (CAC): Before a satellite
terminal can make a high QoS rate request, it must seek
admission control approval from a ground-based
connection admission controller at the NOCC. This
controller performs access control checks and edge-to-

3 of 7

edge capacity and congestion checks on the rate request to
support the virtual satellite connection. By performing
these capacity checks, it can provide guarantees on the
quality of service (QoS) for the end-to-end connection’s
data in order to support interactive voice and video
application transport requirements. The controller may
also pre-empt current connections based upon the
precedence of capacity allocations associated with each
satellite terminal’s service provider or enterprise.
Multicast Replication: Link layer multicast replication
groups are constructed dynamically based upon satellite
terminal signaling to the NOCC CAC server. The terminal
determines participation in these link layer multicast
replication groups based upon IP layer PIM-SM multicast
joins and leaves. The source terminal transmits a single
multicast packet which the satellite replicates to all
downlink beams which have destination terminals. The
NOCC dynamically determines the optimal replications for
the multicast group’s current membership and their
respective downlink beam and shaped beam locations.
Multiple Satellite Terminal Virtual Ports: In order to
segregate and enforce community of interest (COI) access
restrictions to support VPNs, a single terminal can be
associated with multiple virtual ports with each one having
its own COI and End User Group.
Destination Link Layer Address: Each satellite terminal
virtual port is associated with a link layer terminal virtual
port sub-address relative to its own downlink beam.
Whenever a satellite terminal is relocated to another
downlink beam, it needs to re-register with the NOCC’s
registration server to acquire a new link layer address.
On-board Switching: The satellite uses the destination
link layer address inserted by the satellite terminal into the
link layer header to switch and route its link layer code
blocks containing IP packets to the correct downlink beam
and destination terminal’s virtual port.
Satellite Next Hop Address (SNHA): Each virtual port is
assigned a unique Satellite Next Hop Address (SNHA)
which is translated into a destination link layer address for
satellite transmission using satellite address resolution.
The SNHA is configured as the address for the next hop in
IP routing tables.
Alias Satellite Next Hop Addresses: A terminal can also
be associated with an alias SNHA. This allows for
dynamic reassignment of the alias SNHA mapping to the
regular SNHA associated with a destination link layer
address due to redundant terminal site switchover or
terminal beam changes. The destination terminal
propagates its new mapping by multicasting it to the
terminals in its COI and to the NOCC in order to keep the
link layer address resolution caches up to date.
Performance Enhancing Proxy (PEP): The terminal
provides performance enhancing proxies for TCP

spoofing, HTTP pre-fetching, and DNS pre-loading and
caching.
High Volume Uplink (HVUL): In addition to the DAMA
transmissions, a single satellite terminal such as a gateway
or teleport can be configured with a dedicated uplink
channel without having to go through DAMA requests due
to its constant high volume uplink data rate.
Dedicated Contention Channels: This provides for aloha
contention access mechanisms by selected multiple
satellite terminals on dedicated groups of uplink
contention channels without the use of DAMA signaling.
USER DATA TRANSPORT SERVICES
Constant Rate (CR): This type of transport service is
applicable for transmissions that produce a constant rate of
data such as for an uncompressed video transmission.
Constant Rate with Burst (CRWB): This type of
transport service is applicable for transmissions that not
only have a constant rate component but also may have
occasional bursts above that rate such as with a
compressed voice transmission such as with VoIP.
High and Normal Priority Burst: This type of transport
service is applicable for transmissions that are bursty and
volatile such as with web browsing.
Queue
Management

Classifier

Meter/
Marking

SYN Segments
Spoofer

Spoofed Traffic
Traffic
to be
routed
over
space
link

Constant Rate

Queue Servicing

Queues

Retransmit queues
Data queued to below TS as
indicated in classification

( uflow)
Rate
Rate
Rate
Broadcast Rate
Multicast Rate

Constant Rate
Drop
Constant Rate
With Bursts

Drop Priority

Rate by DL congestion
mitigation region
Broadcast Rate

Rate limits
Volume

Volume Needs,
Drop

High and Normal Priority
Burst

Volume Needs,
Drop
“Internal (BoD, Mgmt) messages

Volume Needs
Volume by DL congestion
mitigation region
Broadcast Volume

BoD Grants
BoD Requests

“Message”, BoD, Mgmt data
Contention

Low Volume Low Latency
Connection Mgmt
On-demand Dial events

Classifier Rules

Contention Data
Volume Needs

Traffic Profile/Queue Mgmt

Contention Needs

Scheduling

Figure 4 Satellite Terminal Transport Service Mapping

Low Volume Low Latency: This type of transport relies
upon dedicated uplink channels with access controlled by
aloha contention mechanisms. This is used for data that
fits in a single uplink code block and that requires very
low latency where DAMA signaling would be too long
such as with credit card transactions.
ACK-Return: TCP PEP spoofers use this service over
dedicated uplink contention channels with special access
control mechanisms to efficiently match TCP packet
acknowledgements.
Transport Service Mapping: Each of the transport
services may map to one or more of the link layer packet

4 of 7

delivery services (PDS) such as DAMA rate, DAMA
volume, HUVL, or dedicated contention to efficiently map
to the traffic transport needs as shown in Figure 4. For
example a CRWB service will map to a DAMA rate PDS
for its constant rate part and to a DAMA volume PDS for
its excess burst portion.
NETWORK SECURITY
Security Access Module (SAM): The SAM is the trusted
security agent component resident within each satellite
terminal in a tamper resistant casing. It securely signs
each uplink burst and uplink DAMA request to provide
authentication of the sending satellite terminal.
Capacity Protection: Each satellite demodulator checks
the authentication and authorization of each uplink code
block to ensure the given terminal is DAMA allocated or
allowed to use the given channel.
Link Layer Data Confidentiality (LLDC): One option of
the VPN service is to have the satellite terminal’s SAM be
securely provided by the NOCC with symmetric keys for
terminal-to-terminal pair-wise link layer encryption of
end-user data.
Over-the-Air-Rekeying (OTAR): The NOCC provides
for periodic and as-needed over-the-network rekeying of
satellite terminals and SAMs.

updating the link layer multicast replication in order to
provide high QoS to multicast transmissions.
MANAGEMENT AND OPERATIONS
Resource Management: The NOCC segment provides
resource management servers that are highly reliable,
geographically redundant, and high performance. These
servers provide for control plane signaling of satellite
address resolution, connection admission control (CAC),
satellite terminal registration, and downlink power control.
Element Management: The NOCC segment provides
element management of all of the satellite terminals, each
of the satellite payloads, and each of the NOCC’s own
facilities. This includes redundancy switchovers between
the geographically distributed NOCC facilities and servers.
Service Assurance: The NOCC segment provides profilebased policy management translation of customer service
definitions into satellite terminal configurations via a web
Graphical User Interface (GUI) and/or XML interface.
Satellite Payload and Capacity Management: The
NOCC segment provides profile-based policy management
configuration of the satellite payload capacity resources
and for script-based policy management of payload fault
and configuration management.
Resource
Management

NETWORK LAYER
Routing: Satellite terminals are grouped into routing
domains that are associated with ground-based
geographically distributed route servers. The satellite
terminals participate in IP routing protocols (i.e. RIPv2) on
its terrestrial interfaces while aggregating and translating
them into the Internal Satellite Routing Protocol (ISRP).
The satellite terminal sends its route updates to the route
server who then efficiently redistributes them via multicast
to the satellite terminals. The route servers can also serve
as inter-satellite ground-based paths between different
satellite networks.
Route Redirect: Satellite terminals are generally
configured with their default route being their route server.
When the route server detects a data IP packet is sent to
the router server via two satellite hops even though a
shorter single satellite hop is possible, the router server
sends a route redirect to the terminal on the first packet so
that subsequent IP packets can be routed single satellite
hop. A single satellite hop is required by interactive voice
and video applications for high QoS needs.
Multicast: Satellite terminals participate in IP multicast
routing protocols (i.e. PIM-SM) on their terrestrial
interfaces while sending joins and leaves of the multicast
groups to the NOCC CAC server. The CAC server checks
access controls, current availability of needed capacity,
and downlink congestion before admitting the join and

Downlink
Power Control

Active NOCC
Business
Support

Capacity
Management

Service Assurance
Congestion
Management

Backup
NOCC

Connection
Admission
Control
Satellite
Address
Resolution

NOCC
Operator

ST
Registration &
Authentication

Network & Traffic Engineering
(OLAP Data W arehouse)
Network
Security

Network Service
Provider
Operations
Center

ST Service
Management

Network Management & SA/COP

Element Management
ST
Management

System STs
Satellite
Terminals (ST)

Network
Service
Provider
Interface

NOCC
Management

Payload
Management

Satellite
Control
Facility

Network Service
Provider
Operator

Payloads

Figure 5 Network Operations Control Center

Situational Awareness/Common Operating Picture
(SA/COP) and Network Management: The NOCC
segment provides an aggregated near-real time status and
overview of the entire system, its satellites, its facilities,
and the satellite network.
On Line Analytical Processing (OLAP): The NOCC
segment provides extremely sophisticated traffic analysis,
traffic usage auditing, operational reports, and anomaly
detection. This brings large amounts of alarms, events,
configuration, usage records, statistics, audit data, and
resource allocation data together into a data warehouse for
analysis and aggregation.

5 of 7

Satellite Control: The Space Segment provides traditional
telemetry, tracking, and control (TT&C) of the satellites to
ensure the satellite’s health and safe operations.
CUSTOMER SERVICES
Private IP: This type of customer service provides service
definitions of complex networks requiring extensive
customization to meet the customer’s needs and
requirements. This is generally used to supply a custom
satellite network for a distributed intra-net for a business
or enterprise.
Business Internet Access Service: This type of customer
service provides service definitions for normal Internet
access that is provided in standard flavors such that it can
be ordered via a simple web interface in an automated
ordering system with no other operator or network
engineering involvement. This is generally used for
remote telecommuters and consumers accessing the
Internet and specific enterprise services.
IP Plus: This type of customer service provides service
definitions for a mesh network between network peering
sites. This is generally used for mesh networks such as for
enterprise-to-enterprise peering networks.
Frame Plus: This type of customer service provides
service definitions for a high QoS service similar to those
provided by frame relay networks but over the satellite.
Satellite Direct Connect Service: This type of customer
service provides service definitions for point-to-point high
QoS links similar to that provided by dedicated T1 links.
Virtual Private Network: This type of customer service
option provides a service option that adds on virtual
private network mechanisms including link layer data
confidentiality (LLDC) encryption, multicast group access
control, and IPv4 network address translation (NAT). It
provides end-user services similar to those provided by
Multi-Protocol Label Switching (MPLS).
Combined Service Offering: Each of the various
customer services described above can be combined
together by the SDS segment to provide a single service
offering to meet each customer’s networking requirements.
The SDS also provides the automated ST configuration
from these high level service policies and offerings.
DOD-GRADE SPACEWAY
With SPACEWAY already developed, adjusting its
architecture to support Department of Defense (DoD)
requirements provides a very low risk approach with a
very cost-effective solution. Features can be added in a
low risk phased approach based upon their need, impact,
and cost. In order to make the existing SPACEWAY
system meet DoD needs, the following features would
need to be changed:
Communications-On-The-Move (COTM): In order to
support highly mobile satellite terminals, the satellite

address resolution server and terminal mobility server
software would be deployed on-board the satellite [13].
Mobile satellite terminals would use alias SNHA addresses
and would update their address mapping due to an intrasatellite beam handover via a multicast message.
Information
Assurance
(IA)
and
Protected
Communications: In order to support DoD-grade
security, the system would need to upgrade its commercial
grade security systems to support NSA approved IA
architectures and technology. The system would also need
to provide for secure frequency hopping. The system
would need to support DoD-grade protected
communications and anti-jamming techniques.
Policy Management: The system would need additional
policy management to support IA intrusion detection and
mitigation at an additional DoD level of sophistication
utilizing the existing policy infrastructure.
DoD Terminal Platforms: In order to support DoD
terminals, severely disadvantaged terminal platforms such
as submarines would need to be supported. The system
would have to add additional modulation modes and
encodings to support them.
Networking: In order to support deployed and future DoD
networks, the SPACEWAY system would need to be
upgraded to support their networking protocols. This
includes items such as upgrading from IPv4 to IPv6,
adding OSFP and BGP support in ISRP, and adding
HAIPE management plane and discovery support.
Mission Planning: In order to support DoD Mission
Planning, additional variations of customer services would
need to be developed to cater to unique military needs and
scenarios.
Coverage and Capacity: In order to support concentrated
coverage and capacity requirements for various DoD
scenarios, the use of multiple gimbaled steerable antennas
may be needed on the uplink and downlink.
Network Services and Air Interfaces: In order to support
legacy DoD satellite terminals already deployed, the
system would need to be changed to support these legacy
air-interface data and control protocols. In order to
support very high data rates required by DoD UAV
surveillance platforms, the system would need to be
changed to support their required data rates and protocols.
Multi-Level Precedence and Preemption (MLPP): In
order to support precedence and pre-emption associated
with military chain of command structures and crisis
situations, the system would need to be changed to support
MLPP precedence levels in its CAC signaling and
admission control.
Inter-Satellite Links (ISL): In order to support highly
survivable satellite communications and high data rate
CONUS access, the system would need to be changed to
support inter-satellite links. This would also require

6 of 7

adding the Spanning Tree protocol between the satellites to
avoid link layer switching loops.
Survivability: The ground-based resource servers would
need to be geographically distributed with multiple servers
in each satellite’s footprint to provide better DoD-level
survivability.
The SPACEWAY system as-built supports many of the
networking needs of DoD end-users with its QoS features,
multicast features, networking features, routing features,
etc. So SPACEWAY can be used to meet the gap in
current DoD satellite capacity needs [3,7] since it already
meets the bulk of DoD satellite current networking
requirements. With the additional support for DoD-grade
features such as COTM, IA, survivability, ISLs, MLPP,
support for DoD severely link disadvantaged terminals,
etc. the commercial packet switching SPACEWAY system
can be leveraged to meet most future DoD satellite
networking needs and requirements in a short low risk
timeframe.

10. TRW Broadband Payloads for the Emerging Ka-Band
Market, Mark Bever, Scott Willoughby, Eric Wiswell,
Kenton Ho, and Stuart Linsky, International Astronautical
Federation, 2001.
11. On Managing Intelligent Satellite Networks – An
Evolutionary Approach in Policy Based Distributed
Management, Greg Totsline, Rajeev Gopal, MILCOM
2005, http://www.milcom.org/2005.
12. Capacity Enhancement with Dynamic Resource
Management for Next Generation Satellite Systems, David
Whitefield,
Rajeev
Gopal,
MILCOM
2005,
http://www.milcom.org/2005.
13. Mobile Communications in a Geosynchronous
Regenerative Satellite Mesh (RSM) System, Steven
Arnold, David Whitefield, and Rajeev Gopal, MILCOM
2006, http://www.milcom.org/2006.
14. Technology Readiness of Future Generation Networks
Leveraging Regenerative Satellite Mesh Architecture – A
SPACEWAY Perspective, Rajeev Gopal, David
Whitefield, and Steven Arnold, MILCOM 2006,
http://www.milcom.org/2006.

REFERENCES

BIOGRAPHIES

1. Broadband Satellite Communications for Internet
Access, Sastri L. Kota Kaveh Pahlavan and Pentti
Leppanen, 2004.
2. Digital Processing Options/Capabilities, web page,
Boeing Space System, www.boeing.com/defensespace/space/bss/dsp/options.html, May 2006.
3. Employing Commercial Satellite Communications:
Wideband Investment Options for DoD, Tim Bonds,
Michael Matlock, Thomas Hamilton, Carl Rhodes,
Michael Scheiern, Phillip Feldman, David Frelinger,
Robert Uy, www.rand.org/publications/MR/MR1192,
2000
4. European Telecommunications Standards Institute
(ETSI) Technical Specification (TS) 102 188, Satellite
Earth Stations and Systems (SES); Regenerative Satellite
Mesh – A (RSM-A) air interface, www.etsi.org, 2004.
5. MILSATCOM Transformation, Christine Anderson,
Ground System Architectures Workshop (GSAW)
conference, sunset.usc.edu/gsaw, March 2005.
6. Networking in the Transformational Communications
Architecture, Jeremy Mineweaser, NASA Third Space
Internet Workshop, scp.grc.nasa.gov/siw, June 2003.
7. Optimal Commercial Satellite Leasing Strategies,
Michael
Matlock,
www.rand.org/publications/MR/MR1402, 2002.
8. SPACEWAYTM A Vision for the Future, Dr. Arunas
Slekys, VSAT 2002, The Global Industry Conference, 1012 September 2002, London, U.K.
9. SPACEWAYTM System Summary, E. J. Fitzpatrick,
Space Communications, Vol. 13, No 1, 1995, pp. 7-23.

David Whitefield graduated from Virginia Polytechnic
Institute and State University with a B.S. degree in
Computer Science and gained a M.S. degree in Software
Engineering from Johns Hopkins University. He joined
Hughes Network Systems in 1990 and has worked
extensively on satellite communication systems and
networking. He has architected, designed, and developed
for systems including Transformational Communications
Satellite System (TSAT), SPACEWAY broadband satellite
system, and ICO satellite system.
Rajeev Gopal received a Ph.D. in Computer Science from
Vanderbilt University and a B.E. in Electrical Engineering
from BITS, Pilani. He has worked in satellite network
development, computing research, biomedical R&D, and
large scale information system deployment. Dr. Gopal
was one of the SPACEWAY system architects and the
chief architect and software manager for the SPACEWAY
Network Operations Control Center development.
Currently he is involved in the Transformational
Communications Satellite (TSAT) System project
Steven P. Arnold received his M.S. in Electrical
Engineering from Purdue University and his B.S in
Electrical Engineering from Virginia Polytechnic Institute
and State University. At Hughes Network Systems, he has
worked on several satellite communication systems,
including the SPACEWAY broadband satellite system,
ICO satellite system, and Thuraya satellite system.
Previous to joining HNS, he worked at IBM Corporation
on wireless technologies for Intelligent Transportation
Systems.

CONCLUSION

7 of 7



---

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.3
Linearized                      : No
Page Count                      : 7
Producer                        : AFPL Ghostscript 8.53
Create Date                     : 2006:09:01 12:35:55-04:00
Modify Date                     : 2006:09:01 12:35:55-04:00
Title                           : 1596_Spaceway Overview version 2.7
Creator                         : PDFCreator Version 0.9.1
Author                          : dwhitefield

EXIF Metadata provided by EXIF.tools