1596_Spaceway Overview Version 2.7 SPACEWAY White Paper
2013-01-24
: 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 : dwhitefieldEXIF Metadata provided by EXIF.tools