HXGW Overview

HX System
System Overview
1037105-0001 Revision D February 8, 2008
Revision record
Revision
A B C D
Date of issue
May 31, 2006 October 6, 2006 January 8, 2007 February 8, 2008
Scope
Production release Updates for new features Updated to include nonredundant rack features Production Release to remove the special hold statement
Copyright 2008 Hughes Network Systems, LLC

All rights reserved. This publication and its contents are proprietary to Hughes Network Systems, LLC. No part of this publication may be reproduced in any form or by any means without the written permission of Hughes Network Systems, LLC, 11717 Exploration Lane, Germantown, Maryland 20876. Hughes Network Systems, LLC has made every effort to ensure the correctness and completeness of the material in this document. Hughes Network Systems, LLC shall not be liable for errors contained herein. The information in this document is subject to change without notice. Hughes Network Systems, LLC makes no warranty of any kind with regard to this material, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose.
Trademarks
Hughes and Hughes Network Systems are trademarks of Hughes Network Systems, LLC. All other trademarks are the property of their respective owners.
Contents
Chapter 1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 Audience. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 Whats new in this release . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 The HX System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 Innovative features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 Broadband applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 HX System architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Network segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 GTWY segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Remote terminal segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Space segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 Wide area network segment . . . . . . . . . . . . . . . . . . . . . . . . . . .8 HX System star topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 System management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8 Information flow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Chapter 2 Transmission features . . . . . . . . . . . . . . . . . . . . . . . . . . .11

Outbound channel: DVB-S and DVB-S2. . . . . . . . . . . . . . . . . .11 DVB scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11 DVB and multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 DVB-S2 spectral efficiency . . . . . . . . . . . . . . . . . . . . . . . . . .12 DVB-S2 outbound adaptive coding and modulation . . . . . . .12 Inbound channel: adaptive coding . . . . . . . . . . . . . . . . . . . . . . .14 Closed loop control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 Inroutes and outroutes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 Inroutes and inroute groups . . . . . . . . . . . . . . . . . . . . . . . . . .16 Inroute types and burst types . . . . . . . . . . . . . . . . . . . . . . .16 Inroute groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17
Chapter 3 Bandwidth management . . . . . . . . . . . . . . . . . . . . . . . . .19

Bandwidth management overview . . . . . . . . . . . . . . . . . . . . . . .19 Bandwidth assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20
Contents 1037105-0001 Revision D
iii
Inroute bandwidth pooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 Advanced bandwidth management techniques . . . . . . . . . . . . .22 Preassigned constant bit rate services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24 Adaptive CBR with step increments . . . . . . . . . . . . . . . . . . .25 CIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 Best effort services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 Traffic prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 Unlimited combination of service plans. . . . . . . . . . . . . . . . . . .28
Chapter 4 IP features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

Network layer features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 Bandwidth conservation features . . . . . . . . . . . . . . . . . . . . . .31 IP packet payload compression . . . . . . . . . . . . . . . . . . . . .32 Inbound header compression . . . . . . . . . . . . . . . . . . . . . . .32 PEP V3 and IP handshaking. . . . . . . . . . . . . . . . . . . . . . . .32 IP packet delivery prioritization . . . . . . . . . . . . . . . . . . . . . . .32 NAT/PAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33 Port mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33 Application layer network services . . . . . . . . . . . . . . . . . . . . . .34 DHCP server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34 DHCP relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34 DNS caching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
Chapter 5 Network security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

Data encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35 DES-encrypted outbound channel . . . . . . . . . . . . . . . . . . . . .35 Two-way IPSec encryption . . . . . . . . . . . . . . . . . . . . . . . . . .36 Network security features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36 Firewalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36 Fenced Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
Chapter 6 HX GTWY architecture . . . . . . . . . . . . . . . . . . . . . . . . .39

Top-level HX GTWY segment devices and functional components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39 Redundancy readiness levels . . . . . . . . . . . . . . . . . . . . . . . . .44 Functional subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45 Common subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48 Timing subsystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 Timing generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49 Dual timing unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
iv
Outroute subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 Satellite gateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 DVB modulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 IP gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50 Outroute redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51 Inroute subsystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .51 IF Subsystem-Turbo Code system . . . . . . . . . . . . . . . . . . .52 Dynamic network control cluster . . . . . . . . . . . . . . . . . . . . . .52 Control Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52 Local area networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53 GTWY LAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54 Management VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54 Multiplex (MUX) VLAN . . . . . . . . . . . . . . . . . . . . . . . . . .54 Return channel VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . .54 CP VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55 Enterprise LAN/VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55 System console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55
Chapter 7 Remote terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57 Antenna. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 Outdoor unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 Indoor unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59 Remote configuration and commissioning. . . . . . . . . . . . . . . . .60 Remote device support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61
Chapter 8 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . .63

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .63 NMSS server components . . . . . . . . . . . . . . . . . . . . . . . . . . .64 Configuration management . . . . . . . . . . . . . . . . . . . . . . . . . . . .65 GTWY component configuration. . . . . . . . . . . . . . . . . . . . . .65 Remote site component configuration . . . . . . . . . . . . . . . . . .65 Profiles and profile groups . . . . . . . . . . . . . . . . . . . . . . . . . . .65 Software configuration management . . . . . . . . . . . . . . . . . . .66 Configuration interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . .66 Fault management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 Status monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 Performance management . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 Real-time statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67 Historical statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68
Security management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68 Operator security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68 Network component security . . . . . . . . . . . . . . . . . . . . . . . . .68 Configuration NMDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . .68 Management NMDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69 Encryption key management . . . . . . . . . . . . . . . . . . . . . . . . .69 Component control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69 HX GTWY control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69 Remote site control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69
Chapter 9 Acceleration features . . . . . . . . . . . . . . . . . . . . . . . . . . . .71

Performance Enhancing Proxy (PEPV3) . . . . . . . . . . . . . . . . . .71 TCP spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71 PEP and TCP payload compression . . . . . . . . . . . . . . . . . . . .72 DNS caching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .72
Chapter 10 Multicast features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73

Multicast applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73 Broadcast applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73 Streaming media applications. . . . . . . . . . . . . . . . . . . . . . . . .74 HX GTWY multicast management . . . . . . . . . . . . . . . . . . . . . .74 Remote terminal multicast support. . . . . . . . . . . . . . . . . . . . . . .74
Chapter 11 HX options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75

Enterprise package delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . .75 Fenced Internet access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77 Firewall protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77 IPSec. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77 TurboPage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77 Voice over IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
Appendix A Technical specifications . . . . . . . . . . . . . . . . . . . . . . . . . .79

HX GTWY specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79 HX50/100 remote terminal mechanical and environmental specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .80 HX150 remote terminal specifications. . . . . . . . . . . . . . . . . . . .81
Acronyms and abbreviations . . . . . . . . . . . . . . . . . . . . .83 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85
vi
Figures
Chapter 1
1. HX System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 2. Traffic flow through the HX System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 3. HX System equipment data flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10
Chapter 2
4. Multiplexing DVB Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 5. Using ACM to optimize the link budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 6. Using ACM to dynamically change coding/modulation . . . . . . . . . . . . . . . . . .14 7. Multiple FECs within one TDMA frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 8. HX System closed loop power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15
Chapter 3
9. Multi-frequency inbound access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 10. Inbound pooling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 11. CBR services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 12. CIR services with best effort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 13. HX System traffic prioritization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 14. Multiple service plans. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
Chapter 6
15. Redundant HX System rack (HXGW-1R-RED 1036797-6010) . . . . . . . . . . . .40 16. Nonredundant HX System rack (HXGW-1R-NRED 1036797-6020) . . . . . . . .41 17. HX System expansion rack (HXGW-EXP-RACK 1036797-6050). . . . . . . . . .42 18. HX system subsystems and components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 19. GTWY components and how they connect through LANs . . . . . . . . . . . . . . . .54
Chapter 7
20. Typical HX100 remote site configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58
Chapter 8
21. Network management system architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . .64
Chapter 11
22. Enterprise package delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
Figures 1037105-0001 Revision D
vii
viii
Figures 1037105-0001 Revision D
Tables
Chapter 3
1. Inrbound bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23
Chapter 6
2. Rack model numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39 3. HX GTWY devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43 4. Examples of redundancy readiness levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44
Chapter 7
5. Features list for HX50, HX100, and HX150 remote terminals . . . . . . . . . . . . .59
Tables 1037105-0001 Revision D
ix
Tables 1037105-0001 Revision D
Chapter 1
Overview
The chapter provides a general overview of the HX System. It contains the following sections: Scope on page 1 The HX System on page 3 Innovative features on page 5 Broadband applications on page 6 HX System architecture on page 7 Information flow on page 9
Scope
This document provides a high-level overview of the HX broadband satellite system, including discussions of system concepts, features, and components.
Audience The primary audience for this document is enterprise customers

who are responsible for operating and managing their own HX System gateway (GTWY). The secondary audience is customers at any level who need to understand the operation of the HX System. This manual assumes that the reader understands: Telecommunications and computer networking technology Transmission Control Protocol/Internet Protocol (TCP/IP) Common computer networking services and protocols Satellite communications principles Satellite orbit characteristics Time and frequency division multiplexing Phase-shift keying Forward error correction Conditions that affect satellite communications
Organization This document is divided into the following chapters:

Chapter 1 Overview describes the features, applications, high-level system architecture, and data flows of the HX System. Chapter 2 Transmission features describes the features and advantages of the HX Systems approach to broadband satellite transmission.
Chapter 1 Overview 1037105-0001 Revision D
Chapter 3 Bandwidth management describes the dynamic bandwidth allocation and management technologies used in the HX system to maximize bandwidth while providing extremely flexible service levels and guaranteed quality of service. Chapter 4 IP features describes standard and specialized IP features designed to minimize space-segment latencies and support standard and advanced IP networking protocols and services. Chapter 5 Network security describes the HX System network and data security features. Chapter 6 HX GTWY architecture describes the devices that comprise the HX GTWY and provides a functional description of the HX GTWY software and hardware systems. Chapter 7 Remote terminals describes HX System remote terminals and the very small aperture terminals (VSATs) that are used at HX System remote locations. Chapter 8 Network management describes the functions provided by the Vision Unified Element Manager (UEM) to maintain and control network operations. Chapter 9 Acceleration features describes the techniques used within the HX System to reduce the overhead of TCP/IP connections and otherwise reduce the amount of data and latency across the space segment. Chapter 10 Multicast features describes how the multicast protocol is implemented in the HX System to provide multimedia and other services. Chapter 11 HX options describes optional features not included in the base HX System. Appendix A Technical specifications provides hardware technical specifications for the HX GTWY and HX remote terminals. A list of abbreviations and an index are provided at the back of the manual.
Related publications The following documents provide more detailed information

about HX system and GTWY components. HX System Gateway (GTWY)/Fixed Rack Model Installation Manual, Volume 1: Overview and Hardware Installation (1036936-0001)
HX System Gateway (GTWY)/Fixed Rack Model Installation Manual, Volume 2: Component Configuration (1036937-0001) HX System Gateway (GTWY)/Fixed Rack Model Operations and Troubleshooting Manual, Volume 1: Remote Terminal Operations (1036938-0001) HX System Gateway (GTWY)/Fixed Rack Model Operations and Troubleshooting Manual, Volume 2: GTWY Operations (1036939-0001) HX System Gateway (GTWY) Reference Manual, Volume 1: Vision Interface (1036940-0001) HX System Gateway (GTWY) Reference Manual, Volume 2: NOC Forms and Local Interfaces (1036941-0001) Remote Terminal Installation Guide, Models: HX50, HX100 (1037106-0001) Remote Terminal User Guide, Models: HX50, HX100 (1036942-0001) Remote Terminal User Guide, Model HX150 (1037194-0001) Remote Terminal Installation Guide, Model HX150, (1037125-0001)
Whats new in this release Since the previous release of this document, an expansion rack
option has been added to the HX System fixed rack model. This document had been updated to include RoHS information for all rack configurations.
The HX System
The HX System is an innovative IP broadband very small aperture terminal (VSAT) system created by Hughes. It is designed and optimized for smaller networks that require high-bandwidth, high-quality of service (QoS) links. The HX System leverages the best features and capabilities of the proven Hughes HN broadband VSAT systemwith over three quarters of a million terminals deployedwhile providing new features that support high-bandwidth, real-time applications such as telephony trunking, video conferencing, and so on. The HX Systems advanced bandwidth-management features enable operators to customize fine-grained QoS and SLAs (service level agreements) on a per-remote terminal basis. For example, HX System operators can guarantee both inbound and outbound bandwidth per remote terminal. In addition, the HX System can provide dynamic bandwidth allocation for time-division multiple access (TDMA) channels based on usage
and need, allowing development of a wide range of service plans fine-tuned to meet individual needs. By leveraging the DVB-S2 (or DVB-S) transmission standard for the outbound channel, the HX System achieves the best spectral efficiency of any TDM/TDMA network available today. The HX network architecture is based on the TDM/TDMA star topology. As shown in Figure 1, the system can provide high-speed Internet protocol satellite connectivity between the corporate headquarters and multiple remote sites. The HX System operates in the Ku, Ka, and C frequency bands.
Figure 1: HX System
Innovative features
The HX System provides these state-of-the-art features: Advanced bandwidth management capabilities The HX System allows operators to easily provision services like constant bit rate (similar to single channel per carrier or SCPC), minimum committed information rate (CIR) with maximum limits, and best effort services. Importantly, the HX System can provide these service offerings per-remote terminal, where other systems only provide a single QoS to remote terminals on a common inroute. DVB-S2 The HX System uses DVB-S2the latest generation satellite transmission standard. In its most basic form, DVB-S2 incorporates 8PSK modulation (in addition to the QPSK modulation of DVB-S) together with low-density parity checking (LDPC). The combination of 8PSK with LDPC produces approximately 30% more bandwidth than DVB-S for the same amount of satellite power/bandwidth. Adaptive coding and modulation The HX System implementation of DVB-S2 supports adaptive coding and modulation (ACM) in the outbound channel, allowing operators to optimize the outbound channel for each remote terminal. For example, remote terminals in low EiRP regions can be assigned robust coding and modulation combinations (QPSK, Rate ), while remote terminals in beam center can be assigned bandwidth-efficient coding and modulation combinations (8PSK, Rate 9/10). The application of ACM produces up to 30% more bandwidth than DVB-S2, for a total improvement of up to 60% over DVB-S. Most efficient TDMA return channel Because HX System TDMA return channels use Aloha for initial assignment request, operators can optionally utilize the bandwidth of remote terminals that are idle for some period of time while maintaining the QoS commitment to a customer. The HX System TDMA inbound channel also uses variable length bursts, allowing up to 85% efficiency on the return channel. Robust rain fade mitigation techniques Recognizing that high availability is a crucial element of enterprise SLAs, the HX System provides the industry's most extensive set of features for increasing overall system availability. These features include dynamic ACM on the DVB-S2 outbound carrier, dynamic coding of the TDMA return channel, and dynamic uplink power control for the remote terminal. Advanced IP features HX remote terminals support a number of built-in router functions, which are configured remotely at the HX System gateway (GTWY). These
functions generally eliminate the need for an external router at remote sites. Router functions include flexible addressing with support for routing information protocol (RIP), network address and port translation (NAPT), port forwarding, DHCP service and DHCP relay, DNS caching, and firewall capability. With the HX System, there is generally no need to purchase an additional router for the remote site. Data acceleration All HX remote terminals implement the Hughes PEP (performance enhancement proxy for TCP) feature, which includes bidirectional TCP spoofing, data and header compression, IP priority levels, ACK reduction, and message multiplexing. Built-in network security The HX System offers built-in network security as a standard feature. All data transmissions to remote terminals are encrypted to ensure that only authorized terminals access the transmission. Bidirectional encryption is available as an option. Adaptive inroute selection (AIS) - A remote terminal can select an optimal symbol and coding rate for its inroute transmission as a function of a configured trajectory table and information it learns about its transmission from a closed loop power control algorithm. See the bulleted description above for Robust rain fade mitigation techniques. Cost-effective gateway The HX GTWY is optimized to support small networks. It occupies a small physical space and provides a very cost-effective solution for small networks.
Broadband applications
HX Systems support the following services: Broadband IP connectivity The HX System offers a completely private high-speed network with performance-enhancing features that maximize performance and network efficiency. The performance of individual applications (interactive and file transfer) can be independently managed with Hughes performance-enhancing proxy parameters. GSM backhaul The HX system can be configured as an IP pipe and used as a global system for mobile communication (GSM) backhaul to replace T1/E1 and other ground-based base transceiver station-to-base station controller (BTS-toBSC) network elements. IP multicasts The HX GTWY supports IP multicasts to send multimedia or other traffic to multiple remote sites simultaneously, and HX remote terminals include IGMP
support to route IP multicast traffic to attached workstations. (Note that the HX QoS features do not apply to IP multicast.) Telephony With the Hughes voice appliance (VAP) connected to an HX remote terminal, toll-quality voice FAX services are available between remote sites and the public switched telephone network (PSTN).
HX System architecture
Network segments The HX network is divided into segments, each of which
represents a portion of the communications link. These segments include: GTWY segment Remote terminal segment Space segment Wide area network segment
GTWY segment The GTWY is the centralized earth station through which the
entire network is controlled. It contains transmit and receive communications equipment, a radio frequency terminal (RFT) consisting of RF equipment and a large antenna, and network management subsystems and infrastructure. The GTWY segment manages the entire HX System and any backend systems used for handling tasks such as billing, customer care, and provisioning. See Chapter 6 HX GTWY architecture for more information.
Remote terminal segment Remote terminals provide broadband TCP/IP communications to

remote sites. The remote terminal segment is the network segment located at the end-user terminals. Each remote terminal has an indoor unit (IDU), also called a satellite router, which contains the receive and transmit units; and an outdoor unit (ODU) consisting of RF equipment and an antenna. A remote local area network (LAN) host is a device at the remote site that communicates across the HX System via TCP/IP. See Chapter 7 Remote terminals, on page 57 for more information about remote terminals.
Space segment The space segment is the satellite portion of the link, and
connects all of the remote terminals in the network to the GTWY.
Wide area network segment The wide area network (WAN) segment includes the Internet and
various private independent IP networks with which HX remote terminals communicate using TCP/IP protocol, including their host computers. The WAN segment also includes the commercial, off-the-shelf (COTS) switches, routers, and other networking equipment within the GTWY that connect the GTWY to the independent IP networks.
HX System star topology The HX System star-topology network has the following major
elements: HX GTWY the central processing center of the network. The GTWY provides connectivity between HX remote terminals and customer data centers and/or the Internet. HX remote terminals HX remote terminals reside at the end user location and communicate with the HX GTWY via satellite link. The remote terminal consists of an outdoor unit (ODU) and an indoor unit (IDU). The ODU contains the satellite antenna and radio frequency equipment; the IDU contains the very small aperture terminal (VSAT).
Note: Although the term remote terminal technically refers to all of the equipment at the remote site, it is often used to refer just to the VSAT.
System management The Vision UEM system is the set of management tools for HX
GTWY components and interface equipment, including: IP gateway(s) Satellite gateway(s) DVB-S2 modulator Timing subsystem Management gateway (MGW)
All other network components and equipment are managed through their own interfaces. The components within the network management system server (NMSS) are: Element-management server Graphical user interface Backend database HP (Optionalother network management softwares can also be used)
See Chapter 8 Network management for more information about managing the HX System network.
Information flow
Figure 2 illustrates the general round-trip flow of user traffic through the HX System.
User Host PC
Remote Terminal
Outdoor Unit (ODU)

RX
TX
User Sites GTWY

SATGW
IPGW
DNCC
IFSS-TC
Enterprise network
T0150001 5/16/06
Figure 2: Traffic flow through the HX System
Figure 3 illustrates how information flows through the HX System GTWY equipment. Note the difference between the arrows used to represent inroutes and those used to represent outroutes. The differing widths of these arrows signify the different bandwidths for data traveling from the HX GTWY to the remote terminals (outroutes) and vice versa (inroutes).
RF equipment Remote terminal
GTWY Outroute components

Timing support components
Inroute components Remote terminal

d i g i t a l TM
d i g i t a l TM
VAXstation 3100
To/from enterprise network
Host User interface components Management components

d i g i t a l TM d i g i t a l TM d i g i t a l TM d i g i t a l TM d i g i t a l TM
VAXstation 3100
d i g i t a l TM
VAXstation 3100
d i g i t a l TM
VAXstation 3100
d i g i t a l TM
VAXstation 3100
Host INROUTE OUTROUTE
Host
Host
Host
T0150018 8/01/06
Figure 3: HX System equipment data flow
10
Chapter 2
Transmission features
This chapter introduces HX System transmission function elements and explains the features and advantages of the HX System transmission implementation. This chapter discusses the following topics: Outbound channel: DVB-S and DVB-S2 on page 11 Inbound channel: adaptive coding on page 14 Closed loop control on page 15 Inroutes and outroutes on page 16
Outbound channel: DVB-S and DVB-S2
All of the Hughes satellite IP broadband systems use the DVB standards for the outbound transmission channel. The use of DVB for the outbound channel provides these significant advantages for an operator: DVB scales efficiently DVB can be multiplexed The HX System also supports the DVB-S2 standard, which provides these additional advantages: Improved spectral efficiency Outbound adaptive coding and modulation (ACM) These features are described in the following sections.
DVB scaling DVB channels are designed to scale effectively to large

carriersthe HX System can support carriers as large as 45 Msps on the outbound channel. This contrasts sharply with non-DVB systems, in which the maximum outbound channel capacity in some instances is limited to 10 Msps. Uplinking multiple outbound channels incurs an efficiency penalty as each additional carrier requires channel spacing. In addition, the advantage of satellite multicast is reduced as each outbound carrier must replicate every multicast message. With the Hughes HX system, an operator can use a single outbound channel to support hundreds of remote terminals.
Chapter 2 Transmission features 1037105-0001 Revision D
11
DVB and multiplexing Another important advantage of DVB systems is their ability to
multiplex two or more DVB-S channels together into a single carrier. For operators who already broadcast a DVB video carrier, the addition of data capacity is easily achieved by multiplexing DVB video streams with a Hughes DVB data stream. With larger multiplexed DVB streams, the operator may be able to take advantage of single carrier mode across the transponder by operating the carrier in saturation. Figure 4 illustrates how two DVB streams can be multiplexed together.
HX Gateway
DVB ASI MUX

Video
G-28730 C 08/22/06
Figure 4: Multiplexing DVB Streams
DVB-S2 spectral efficiency The most recent enhancement to the DVB standards is DVB-S2,
which introduces several important new features that, together, provide significant spectral efficiencies over DVB-S and proprietary, non-DVB, channel formats. DVB-S2 provides for both 8 PSK as well as QPSK and uses a powerful FEC system based on the concatenation of Bose, Ray-Chaudhuri, Hocquenghem (BCH) codes with LDPC (low-density parity checking) inner coding. The result of the BCH/LDPC coding is only 0.7 dB from the Shannon limit. This is significantly better performance then any proprietary turbocodethe best of these appear to operate about 2 dB from the Shannon limit. The bottom line for operators is that the DVB-S2 can provide up to 2.25 bits per Hz or more (depending on the link budget), resulting in better bandwidth economics.
DVB-S2 outbound adaptive A very powerful feature of DVB-S2 is adaptive coding and coding and modulation modulation (ACM), which was designed specifically for
interactive services such as broadband IP over satellite. ACM allows an operator to vary the modulation and coding of the outbound channel on essentially a per-remote terminal basis. This feature can be applied in two waysfirst to optimize the link budget of the outbound channel, and second to make dynamic adjustments to compensate for atmospheric attenuation of the outbound channel.
12
In the first application of ACMoptimizing the link budgetan operator can predefine the outbound coding/modulation combinations for each remote terminal based on the satellite footprint or EiRP contour. As shown in Figure 5, the remote terminals that are at beam edge can be configured for the most robust coding/modulation combination (QPSK rate ), while the remote terminals at beam center can be configured for the most bandwidth efficient coding/modulation combination (8 PSK Rate 9/10). The ability to customize the outbound channel per remote terminal allows an operator to realize additional bandwidth efficiencies of up to 30% over and above the 30% gain from 8 PSK and BCH/LDPC coding. Thus, DVB-S2 with ACM can provide an operator up to 60% bandwidth gain over DVB-S.
Beam edge most robust coding/modulation QPSK rate 1/2
Beam edge
Beam center most bandwidth efficient coding/modulation 8PSK rate 9/10
Beam center
G-28732 C 08/22/06
Figure 5: Using ACM to optimize the link budget
In the second application of the ACM feature, the HX system can dynamically change the coding/modulation combination based on changing received signal conditions, as happens in the event of a rain fade. In this mode, there is a closed loop control feedback mechanism between the HX GTWY and the remote terminal, whereby the remote terminal can instruct the HX GTWY to change the coding/modulation combination to overcome rain fade. The benefit for an operator is the ability to provide higher availability to its customers. The ACM capability of the HX System is shown in Figure 6.
13
Figure 6: Using ACM to dynamically change coding/modulation
Inbound channel: adaptive coding
The Hughes system can dynamically change the coding rate of the inbound channel. This feature significantly improves link availability. As shown in Figure 7, this feature enables the return channel demodulators (RCD) at the HX GTWY to demodulate, decode, and process bursts of varying coding rates within the same TDMA frame. The GTWY demodulator does not need to know the coding of each burst in advance. It is determined spontaneously, allowing the remote terminal to dynamically change its coding rate based on link conditions, as affected by rain fade.
Figure 7: Multiple FECs within one TDMA frame
14
Closed loop control
The Hughes HX System has a closed loop power control between the HX GTWY and remote terminals so that there is a continuous monitoring of the outbound and inbound channels. As shown in Figure 8, the closed loop control provides for the HX GTWY to continuously monitor the received signal quality of transmissions from each remote terminal while each remote terminal continuously monitors the received signal quality of the transmission from the HX GTWY. As atmospheric conditions affect the link quality, each component is able to request changes to overcome fade conditions.
GTWY sends adjustments to HX remote
HX remote continually measures received signal quality
HX GTWY measures received signal strength and burst timing offset received from remote
G-28735 C 08/22/06
Figure 8: HX System closed loop power control
At the GTWY, the outbound channel coding and modulation can be varied dynamically, while at the remote terminal the forward error correction (FEC) coding can be varied dynamically to improve link availability. Should the remote terminal need even more robust link performance for the inbound transmissions, it also has the ability to shift to a different inroute group supporting a lower symbol rate. Note that the latter capability does not exist when operating with CBR IQoS plans. Additionally, the remote terminal can dynamically change its local uplink power control to overcome fade conditions. As part of the closed loop control implementation, the HX System also supports closed loop timing which allows for both mobility of operation as well as spot beam satellite operation.
15
Inroutes and outroutes
This section describes the technical aspects of the Hughes HX System implementation of inroutes and outroutes, and introduces the concepts of inroute groups and outroute groups, which are used in the HX System to bundle inroutes/outroutes and collectively assign them a bandwidth and other properties.
Inroutes and inroute groups The inroute portion of the space segment transmits data from the
remote terminals to the HX GTWY. The inroute transmission has the following parameters: Frequency-time division multiple access (F-TDMA). Each inroute is at an assigned frequency on the satellite (FDM), and each remote terminal accesses the inroute at its assigned time slot (TDM). Offset quadrature phase shift key (OQPSK) modulation Convolutional or turbo coding Viterbi forward error correction (FEC) The inroute is divided into units called superframes. Each superframe is divided into frames, and each frame is divided into slots. The slot is the basic unit of inroute capacity. The slot size and number of slots are determined by the inroute data rate. The remote terminal transmits a burst at the assigned time slots. This burst enables the burst channel demodulator to lock onto the incoming signal. Inroute types and burst types Inroutes use one of the following access methods to transmit user data to the HX GTWY: Aloha is immediate, contention-based user data transmission, and is not allocated. The remote terminal randomly transmits the bursts on an aloha channel. If another remote terminal is transmitting at the same time, a collision occurs. The HX System uses diversity ALOHA, which involves transmitting two copies of the packet, each in a different ALOHA slot. The HX GTWY will only use one of the packets received on the ALOHA channel. The remote terminal may be assigned to a stream depending on inroute configuration and network congestion. Stream allocation is a defined allocation at a defined time. The remote terminal is assigned and allocated the stream after the HX GTWY detects the ALOHA burst. Stream allocation provides transmission opportunities of variable sizes during each frame. The HX GTWY can be configured to deallocate the stream if there is no demand for bandwidth.
16
Inroute groups An inroute group is a configured collection of inroutes with the following characteristics: They operate at the same information rate The group includes at least one aloha inroute and one assigned inroute Bandwidth is assigned as a unit The maximum number of inroutes in a group depends on the inroute information rate: 64 ksps - 64 inroutes 128 ksps - 64 inroutes 256 ksps - 32 inroutes 512 ksps - 32 inroutes 1024 ksps - 16 inroutes 2048 ksps - 8 inroutes
Load-balancing across inroute groups is accomplished via advertised bandwidth metric (which is computed based on inroute load).
17
18
Chapter 3
Bandwidth management
Bandwidth management is the collection of techniques used in the HX system to manage available bandwidth to the greatest advantage. The HX system uses a variety of techniques to manage bandwidth to maximize flexibility and adapt to environmental conditions while providing guaranteed levels of throughput to meet service level agreements (SLAs) or demanding real-time media transport requirements. The following sections describe the bandwidth management techniques used in the HX system: Bandwidth management overview on page 19 Inroute bandwidth pooling on page 20 Advanced bandwidth management techniques on page 22 Unlimited combination of service plans on page 28
Bandwidth management overview
The HX System allows operators to customize bandwidth assignments for each remote terminal to meet individual QoS and SLA requirements (as compared with the HN System that is designed to provide a fair distribution of bandwidth across a broad set of remote terminals within a collective system). Additionally, the HX System uses variable burst length transmissions for the inbound route. This is an advantage over systems that use fixed burst length sizes. Such systems waste a significant amount of bandwidth because every inbound burst must be the same size, regardless of actual payload demands. The Hughes HX System allows the return channel burst size to be built optimally per remote terminal, based on demand. Extensive and repeated tests on the throughput of the Hughes inbound system demonstrate inbound efficiency up to 85 percent. In practical application, this means that the upstream performance typical of Hughes terminals easily reaches 85 percent of the inbound channel rate; for example 1.3 Mbps upstream throughput for a 1.6 Mbps return channel.
Chapter 3 Bandwidth management 1037105-0001 Revision D
19
Bandwidth assignments The HX System has the flexibility to provide two types of
bandwidth assignments: Nailed-up bandwidth - ensures that the bandwidth is guaranteed and has low latency on start-up, but inefficient use of the bandwidth may be experienced if the remote terminal is idle for long periods of time. Activity-based, nailed-up bandwidth - provides a more efficient use of the overall bandwidth, but causes delay at the initial start-up of traffic. The system can operate in a mixed mode, for example, it can provide some sites nailed-up bandwidth assignment while providing other sites with bandwidth based on activity. In both cases, there is the capability to dynamically adjust the assigned bandwidth based on real-time traffic requirements.
Inroute bandwidth pooling
To leverage the fact that all remote terminals within the HX System are fully frequency-agile across all inbound channels (as illustrated in Figure 9), the HX System bundles the inbound channels into a single large pool of resources. At any point in time, a remote terminal may be instructed to access virtually any inbound channel. Which channel is accessed is determined by the HX GTWY dynamic network control cluster (DNCC), which considers multiple factors, including the QoS commitments of each remote terminal. (See Chapter 6 HX GTWY architecture, for information on the DNCC.)
20
Figure 9: Multi-frequency inbound access
To achieve the efficiencies of pooling (that is, to realize the effects of the law of large numbers) while, at the same, providing the quality of service committed for each remote terminal, the HX System uses a number of techniques. One important element is the concept of inroute quality of service (IQoS) plans. An IQoS plan is simply the logical partition of inroute bandwidth together with the remote terminals that can access that logical bandwidth. The assigned logical inroute bandwidth is designated as Open and is typically used by remote terminals that are configured for dynamic stream (otherwise known as best effort access). Figure 10 illustrates the structuring of the inroute bandwidth.
21
Figure 10: Inbound pooling
An important element in the inbound allocation scheme is that bandwidth need not be dedicated (that is, assigned to a specific remote terminal or group of remote terminals) but can instead be guaranteed. The advantage of guaranteeing bandwidth is that when an IQoS plan does not fully utilize its assigned bandwidth, the HX System is free to reallocate this bandwidth to other IQoS plans (allowing over subscription of bandwidth), thus providing significant flexibilities to an operator.
Advanced bandwidth management techniques
In addition to the logical portioning of inbound bandwidth, the HX System provides the operator with different methods to access the inbound capacity (Table 1): Configured CBR On demand CBR CIR Best effort services
22
Table 1: Inrbound bandwidth Configured CBR

Nailed-up or Activity-based (1) Allocation based on Activity, Backlog or Pre-configuration(2) Nailed-up
On Demand CBR
Pseudo Nailed-up(6)
CIR
Best Effort Services
Nailed-up to Min CIR Activity Activity from Min to Max CIR Pre-configured up to Min CIR Backlog from Min to Max CIR(3) Service will attempt to satisfy Min rate [guaranteed]. If excess bandwidth is available, service will allow up to Max rate. Bandwidth allocation is determined by remote backlog. Bandwidth allocation is based upon advertised remote backlog(3) No guaranteed service requirements
Pre-configuration up to Min CIR Activity from Min to Max CIR [with Step-up/Step-down] (5)
Activity Remote sends explicit requests for CBR bandwidth 5)
Guaranteed Bandwidth(4)
Yes
Yes
Yes up to Min CIR; Excess CIR allocated as Best Effort priority Next priority after CBR up to Min level; Excess CIR allocated as Best Effort; Will under serve if cannot meet Minimum 2nd order in receiving slot assignment Does not affect amount of allocated bandwidth; Used by remote to determine best use of bandwidth Effective for SCPC replacement using TDMA to maximize bandwidth efficiency
No
Allocation Priority of Bandwidth
Highest; though remote may or may not be deactivated due to inactivity (configurable). First order in receiving slot assignment to reduce jitter.
Highest; though remote can explicitly request more bandwidth, less bandwidth or terminate session. First order in receiving slot assignment
As available Last order in receiving slot assignment
Soft QoS
Does not affect amount of allocated bandwidth; Used by remote to determine best use of bandwidth Low jitter, low latency (for nailed up) Effective for VoIP or SCPC replacement with relatively static traffic
Does not affect amount of allocated bandwidth; Used by remote to determine best use of bandwidth Low jitter, low latency (for nailed up) Effective for Video Conference or GSM backhaul with variable traffic
Does not affect amount of allocated bandwidth; Used by remote to determine best use of bandwidth Effective for a fair assignment of bandwidth, based on amount and type of traffic, across a broad pool of remote terminals
Typical Applications
23
Note: (1) Bandwidth is continuously allocated independent of any backlog advertised by the remote terminal (nailed-up) or bandwidth is only assigned when the remote terminal indicates traffic activity (2) Amount of bandwidth allocated is a fixed preconfigured value or variable depending on advertised backlog or adjusted based upon actual usage. Remote terminals with CBR do not advertise backlog. (3) Remote terminals that are obtaining backlog bandwidth are also eligible to also receive periodic and left-over bandwidth. (4) The system allows for oversubscription of guaranteed bandwidth. It is possible that sufficient bandwidth is not available to serve all requests. In this case there is no implied priority between CBR or min CIR (5) Bandwidth allocation is done exclusively without backlog. (6) Requires bandwidth broker capability in the SSGW.
The following terms can be defined as follow: Backlog - the estimated amount of data queued in a remote terminal that is awaiting to be sent to the hub. Periodic - bandwidth that is periodically assigned to remote terminals based upon configuration. Left-over - bandwidth that has not yet been assigned and is distributed evenly to active remote terminals. Nailed-up - bandwidth that is assigned by the DNCC to a remote terminal regardless of usage. Activity - bandwidth assigned solely on usage. The HX System includes network management tools that advise the operator how much outbound and inbound bandwidth has been consumed by various CBR and CIR services, as well as how much bandwidth is available for the best effort services. These tools, which provide a variety of statistical and status information, allow an operator to intelligently load the network and understand to what extent the network is over-subscribed. The CBR and CIR services have equal weight in bandwidth assignment, and both are serviced before assignment of bandwidth for best effort services.
Preassigned constant With this bandwidth management scheme, remote terminals can bit rate services be configured (preassigned) to consume a fixed amount constant
bit rate (CBR), and this bit rate can be configured independently for the outbound and inbound directions. For example, a remote terminal can be configured with a 512 kbps inbound CIR and a 256 kbps outbound CBR. Additionally, the remote terminal can
24
be configured to deallocate the bandwidth if the channel has been idle for a configurable period of time. CBR services operate similar to single channel per carrier (SCPC) links, as the assigned bandwidth per channel is fixed, based on the configuration of the link.
Note: The idle timeout feature can be disabled in order to configure nailed-up bandwidth assignment.
Adaptive CBR with step In this bandwidth assignment service, remote terminals are increments allocated bandwidth based on the following parameters:
Minimum CBR The amount of bandwidth that will be immediately allocated to a remote terminal at the initiation of a data session. This minimum CBR is low jitter, as the bandwidth is assigned to the remote terminal until the CBR session terminates. Termination of the CBR session is based on idle period. Figure 11 illustrates the CBR feature of the HX System. Maximum rate The maximum amount of bandwidth that the terminal will be allocated. Threshold level The level of usage at which the remote terminal will be allocated an additional fixed amount of bandwidth (described in the Step increment bullet item). The threshold level is defined as the following ratio:
Bandwidth Used by the Remote Terminal Bandwidth Assigned or Allocated
For example, if the threshold level is 80%, when the utilization level exceeds 80%, an additional step increment of bandwidth is allocated to the remote terminal. The utilization or load of the channel is evaluated every 500 ms. Step increment The fixed amount of bandwidth, in kbps, that will be allocated to a remote terminal as it requires more than the minimum CBR amount. The HX System uses the threshold level (defined above) to determine when to allocate additional step increments. The HX System continues to allocate step increments up to the maximum rate of the terminal or until the bandwidth of the inroute is exhausted.
25
Step down threshold - The channels utilization and load are updated every 540 ms. Session activity timeout The period of IP inactivity after which the session will be disconnected and the bandwidth freed for use by other remote terminals.
Note: The idle timeout feature can be disabled in order to configure nailed-up bandwidth assignment.
Figure 11: CBR services
Figure 12: CIR services with best effort
26
CIR In this bandwidth assignment service, remote terminals are

allocated bandwidth based on the following parameters: Minimum CIR rate The amount of bandwidth that will be immediately allocated to a remote terminal at the initiation of a data session. This minimum CIR is low jitter, as the bandwidth is assigned to the remote terminal until the CIR session terminates. Minimum CIR bandwidth is prioritized after configured CBR bandwidth. Termination of the CIR session is based on idle period. Guaranteed CIR rate The amount of bandwidth to be allocated to a remote terminal when the remote terminals bandwidth utilization exceeds the configured minimum. When this occurs, bandwidth allocation to the remote terminal continues until the configured guaranteed value is reached. Maximum CIR rate The maximum amount of bandwidth to be allocated to a remote terminal when the advertised backlog exceeds the configured guaranteed. Figure 12 illustrates the CIR with best effort service. In this access mode, the remote terminal is provided the guaranteed CIR the moment traffic activity is detected. A remote terminal is eligible to receive bandwidth in excess of its guaranteed CIR up to its maximum CIR based upon its advertised backlog, periodic, and left-over bandwidth. The DNCC (the bandwidth manager element in the HX GTWY) provides the requested (or excess) bandwidth in a best effort manner. If the bandwidth is available, it is granted up to the maximum rate defined for the remote terminal.
Best effort services A remote terminal that is configured for best effort services is
eligible to receive backlog, periodic, and left-over bandwidth. When a remote terminal is configured for best effort services, the amount of bandwidth it receives is based on the backlog amount. This is the remote terminals estimation of how much bandwidth it needs at any given amount. Best effort users can be assigned (optionally) to an IQoS plan. The IQoS plan defines the maximum amount of bandwidth available to a group of remote terminals as they access the dynamic stream bandwidth. The HX System supports multiple IQoS plans, allowing operators to provide different levels of best-effort services to different groups of customers.
Traffic prioritization Networks must be able to prioritize traffic to ensure that

business-critical applications do not suffer due to bandwidth
27
contention with less important applications. Traffic prioritization comprises the following: Hard QoS - Sets throughput limits for a particular remote terminal. Soft QoS - Provides an additional level of service delivery based upon specific applications. Traffic prioritization occurs in the soft QoS. The HX System can prioritize both inbound and outbound traffic (Figure 13) based on IP parameters. This prioritization can be based on either source or destination IP address and/or IP port numbers and Diffserv code point bits. This allows prioritization based on machine identity or application traffic.
Figure 13: HX System traffic prioritization
Unlimited combination of service plans
Because the HX System treats the inbound channels as a pool, and given that inbound TDMA bursts are of variable lengths, the HX System can efficiently provision a virtually unlimited combination of service plans. This contrasts significantly with some vendor solutions in which all the remote terminals on an inroute must have essentially the same (or similar) service plans with regard to minimum committed information rate (which is always consumed) and maximum rate. Figure 14 illustrates how an operator using the HX System can customize the service plan
28
per remote terminal, based on customer requirements rather than on limitations of the satellite system.
Figure 14: Multiple service plans
29
30
Chapter 4
IP features
The HX System provides a variety of standard and specialized IP features designed to minimize space segment latencies and support standard and advanced IP networking protocols and services. For the purpose of this discussion, the HX System IP features are broken down into the following two groups. Network layer features on page 31 Application layer network services on page 34
Network layer features
The network layer IP features provided in the HX system include: Bandwidth conservation features: IP header compression Payload compression PEP protocol implementation IP packet delivery prioritization NAT/PAT Port Mapping VLAN tagging
Each of these features is described in the following sections.

Note: The HX system also supports IPSec encryption. See Two-way IPSec encryption on page 36 for a discussion of IPSec support.
Bandwidth conservation The HX System implements a variety of mechanisms for features reducing the amount of data that must be transmitted across the
space segment, and for reducing transport latency. These techniques include: IP packet payload compression Inbound header compression The performance enhancement proxy (PEP)
Chapter 4 IP features 1037105-0001 Revision D
31
IP packet payload IP packet payload compression is a feature of the performance compression enhancing proxy (PEP). It compresses grouped packets to achieve compression ratios of up to 12;1. For more information, see PEP and TCP payload compression on page 72. Inbound header compression A standard TCP/IP header is 40 bytes per packet, and most of that information is redundant for a given session. Header compression suppresses any redundant information, reducing the bandwidth required for the header. This compression capability requires that a large number of the fields either do not change, or change only in expected ways. Inbound header compression: Compresses TCP/IP headers from 40 bytes to 10-12 bytes Reduces bandwidth by 15-20% Multiple types of IP headers can be compressed, including: IP headers UDP headers RTP headers PBP headers
PEP V3 and IP handshaking The TCP PEP improves the throughput and response time of network applications while minimizing the required bandwidth. All HX System remote terminals implement the PEP feature, which includes bidirectional TCP spoofing, data and header compression, IP priority levels, acknowledgement reduction, message multiplexing, and caching to improve network communication times. See Performance Enhancing Proxy (PEPV3) on page 71 for more information about PEP.
IP packet delivery Inroute prioritization uses five queues to which users can map prioritization traffic with special handling for constant bit rate (CBR) traffic,
such as real-time transport protocol (RTP) and facsimile. One queue is reserved for CBR traffic, and the other four queues carry PEP and non-PEP traffic, based on priority configurations. The packets from the CBR queue are transmitted before packets from any of the priority queues. Users can map PEP classes of service and non-PEP traffic to one of the four priority queues. Packet delivery prioritization is based on: Source IP address range Destination IP address range TCP /UDP port number Diffserv code point (DSCP) bits
32
NAT/PAT HX System remote terminals support network address translation

(NAT) and port address translation (PAT), allowing translation of IP addresses from the local LAN to global or external addresses. Note: PAT is sometimes referred to as NAPT, for Network Address Port Translation. The capability for NAT and PAT is assigned to remote terminals in their profiles, assigned to them at the HX GTWY. The following NAT/PAT modes are supported: Port Address Translation (PAT) allows users to send data traffic from multiple IP devices on the remote terminal LAN using a single address. Simple NAT enables enterprise customers to cut over to the network without changing their existing remote networks. By using static translation tables, it also makes servers on the remote terminal LAN accessible from the WAN side. Simple NAT provides two methods for configuring the translation tables: Auto-Map: The mapping from remote terminal LAN addresses to NAT addresses can be auto-generated, based on the address ranges configured. Manual-Map: The mapping table entries can be specified individually. This is especially useful if the remote terminal LAN has sparsely addressed IP devices, such as when the remote terminal LAN subnet size exceeds the NAT subnet size. NAT can be enabled only on one LAN port and for only one IP address range. Only one mode of NAT can be enabled at any time. No new software or new platforms are required for enabling NAT.
Port mapping If a remote terminal is configured for port address translation, it

can also be configured for port mapping. Port mapping (or port forwarding) is the mapping of traffic received by the remote terminal on a given port to a particular IP address/port number on the remote terminal LAN. Mappings can be specified as either TCP or UDP. Port mapping can be configured in a remote profile at the HX GTWY, or optionally in a Port Mapping configuration page on the remote terminals System Control Center interface. For more information, refer to the User Manual for the type of remote terminal you are using.
33
Application layer network services
Several HX System IP features relate to remote terminals. These capabilities are configured at the HX GTWY using the Vision UEM remote profiles feature and implemented in the remote terminal. The remote terminal IP features include the following: DHCP service/DHCP relay DNS caching
DHCP server The dynamic host configuration protocol (DHCP) service

running in the remote terminal manages the automatic assignment of IP addresses to devices on the remote LAN. When enabled, the DHCP service responds to a DHCP request by assigning an IP address, a subnet mask, up to two domain name server (DNS) IP addresses, and a default gateway IP address.
DHCP relay HX remote terminals implement a DHCP relay feature which

allows devices on remote LANs to obtain IP addresses and other information, such as an initial bootstrap program and DNS IP address, from an enterprise DHCP server. DHCP requests received by a remote terminal from devices on a connected LAN are forwarded through the spacelink to the HX GTWY, which in turn, forwards them to an enterprise DHCP server. The responses are carried over the spacelink to the remote terminal and sent out on the LAN port from which the requests were received. Note that DHCP requests cannot be relayed from one remote terminal to another, or from the enterprise network to a remote terminal. The DHCP relay feature allows relaying to multiple DHCP servers in the enterprise network.
Note: The DHCP service and DHCP relay features cannot operate simultaneously. The DHCP server feature is automatically disabled if DHCP relay is enabled.
DNS caching To reduce latency introduced by DNS query/response traffic

across the space segment, the remote terminal includes a DNS cache. If the DNS cache does not have the requested domain name, the remote terminal requests it from the enterprise DNS server(s) defined at the GTWY.
34
Chapter 5
Network security
This chapter describes the data security features in the HX System. These features guarantee data integrity and confidentiality, and protect the network from intrusion and external exploits. The following topics are presented: Data encryption on page 35 Network security features on page 36
Data encryption
The HX System can employ several information assurance techniques to safeguard the integrity and confidentiality of data transported through the system. These techniques include: DES-encrypted outbound channel Two-way IPSec encryption
DES-encrypted outbound The outbound channel is encrypted using the data encryption channel standard (DES) by the HX CAS (conditional access system)
feature. This CAS feature: Is hardware-based Ensures that traffic is received by remote terminals legally Prevents unauthorized eavesdropping The HX CAS feature assigns a unique key to each remote terminal. It is responsible for key management and for encrypting outbound data to remote terminals to ensure that remote terminals can only decrypt the data intended for them. When a remote terminal is commissioned, it requests its encrypted effective master key (EEMK) from the HX GTWY. This key is sent to the remote terminal, and then: Used at the HX GTWY to encrypt all data sent to the remote terminal Used by the remote terminal to decrypt all data received from the HX GTWY Because all data transmissions to remote terminals are uniquely keyed, a remote terminal can decrypt only the data sent to it. The EEMK is also used by remote terminals to authenticate themselves to the HX GTWY.
Chapter 5 Network security 1037105-0001 Revision D
35
Two-way IPSec encryption IPSec in the HX System has been submitted to NIST for FIPS
140-2 level 1 certification and has these characteristics: End-to-end encryption from remote terminal to the endpoint on the enterprise network using IPSec, Advanced encryption standard (AES), and Internet key exchange (IKE) protocols Rides over top of the encrypted outroute and clear inroutes AES implemented in software TCP proxy is outside of the IPSec tunnel, preserving satellite acceleration in a secure configuration The HX System provides standards-based IPSec/IKE support for encrypting user data traffic and managing encryption keys. The IKE protocol is used to automatically generate and maintain 128-bit session keys and to set up an IPSec tunnel between a remote terminal and an IP gateway in the enterprise network. This ensures that the data is encrypted end-to-end between the customer's remote site and the enterprise network. The HX System IPSec feature provides encryption without affecting the TCP acceleration and prioritization features. (See Network layer features on page 31 for information about the TCP acceleration and prioritization features.) The Hughes IPSec Kernel has been submitted for NIST certification.
Network security features
The HX System provides the following network safeguards to protect the HX GTWY and the LANs connected to remote terminals: Firewalling A packet filtering firewall to protect LANs connected to remote terminals Fenced Internet URL white lists can be defined to restrict web browsing from remote LANs to only permitted sites, IP addresses, and domains.
Note: The HX system supports network address translation (NAT) and port address translation (PAT)features that can hide the topology of LANs behind a remote terminal to prevent computers on those LANs from being directly addressed from the Internet. See NAT/PAT on page 33 for information about this feature
Firewalling Remote terminals have an embedded firewall. Firewall rules can

be defined in remote terminal profiles at the HX GTWY and forwarded to remote terminals. There are also firewall configuration and statistics web pages on the HX remote terminal System Control Center which, when enabled in HX GTWY
36
profiles, can be used to create firewall rules at the remote terminal, and view firewall statistics. The HX remote terminal firewall works on inbound (outroute) traffic only.
Fenced Internet The fenced Internet access (FIA) service is an option that requires
a TurboPage server. The FIA service provides a mechanism for enterprise customers to restrict remote site access to a limited number of specifically approved Internet sites. Different lists of approved sites can also be supported for multiple subsets of a customer's remote sites.
37
38
Chapter 6
HX GTWY architecture
This chapter describes the components that comprise the HX System gateway (GTWY) segment, including: Top-level HX GTWY segment devices and functional components on page 39 Common subsystem on page 48 Timing subsystem on page 49 Outroute subsystem on page 50 Inroute subsystem on page 51 Local area networks on page 53 System console on page 55
Top-level HX GTWY segment devices and functional components
The HX GTWY, fixed rack model is a 26-unit (26U) rack containing the HX GTWY components. Hughes offers the fixed rack in two configurations: one that provides redundancy for most of the components in the rack, including power supply redundancy, for four 9s (99.99%) failover availability, and one nonredundant configuration. Hughes also offers an expansion rack. Table 1 gives the product numbers for HX GTWY rack models.
Table 2: Rack model numbers Rack
Redundant (See Figure 15) Nonredundant (See Figure 16) Expansion (See Figure 17)
NonRoHS
1036797-0010 1036797-0020 N/A
RoHS
1036797-6010 1036797-6020 1036797-6050
Chapter 6 HX GTWY architecture 1037105-0001 Revision D
39
Figure 15: Redundant HX System rack (HXGW-1R-RED 1036797-6010)
40
..
Figure 16: Nonredundant HX System rack (HXGW-1R-NRED 1036797-6020)
41
Figure 17: HX System expansion rack (HXGW-EXP-RACK 1036797-6050)
42
Table 2 describes the HX GTWY devices and their roles in the fixed rack models.
Table 3: HX GTWY devices HNS Part Number
9012860-0002
Component
Dual GUM
Function
The dual gateway upconverter module (GUM) translates 70 MHz signals to L-band frequency. This translation is required for local timing units (LTUs) and echo timing units (ETUs) capable of receiving signals only at L-Band. The HX GTWY contains two GUMs in a single dual GUM chassis.
1036770-0010
DVB-S2 modulator
The Digital Video Broadcast-S2 (DVB-S2) modulator implements the DVB-S2 standard for transmission over satellite. The DVB-S2 modulator used in the HX GTWY supports symbol rates up to 30 Msps. It contains a LAN interface for monitoring and control purposes. The DVB-S2 modulator is connected to the PCI card present on the IPGW-SATGW server via a DVB Asynchronous Serial Interface (ASI).
1036983-6001 Timing generator (1033731-6001)
The timing generator is a Hughes-built subsystem that provides timing and frequency references to various components in the HX GTWY. Two timing generators are contained in the timing generator chassis.
1501259-0001 Dual timing unit (1500229-0001)
The dual timing unit (DTU) provides return channel timing for a specific outroute. The DTU generates accurate frame timing information to the remote terminals via the super frame numbering packet (SFNP) sent periodically on the outroute. The two timing units operate with hot redundancy. Both TUs send the SFNP and a remote terminal can receive the SFNP from either TU.
1037303-0013
NMSS server
The network management and support services (NMSS) server is the platform for these HX GTWY functional components: WebACS, CAC, MFS, Vision, and database. The IPGW-SATGW server houses the combined functionality of the IP gateway (IPGW) and satellite gateway (SATGW). The IPGW routes IP packets to/from the remote terminals, and performs TCP acceleration and outroute QoS. The SATGW multiplexes traffic and control information into an ASI MPEG transport stream. The nonredundant HX GTWY configuration contains one IPGW-SATGW server. The IPGW-SATGW server houses a Hughes-built, full length PCI card which performs encryption and conversion to DVB-S2 ASI format. Two IPGW-SATGW servers are required in a redundant HX GTWY configuration. IPGW-SATGW servers operate in 1:1 warm redundancy mode.
1037303-0012
IPGW-SATGW
9502155-0001
Keyboard/Monitor
The keyboard /monitor assembly contains a foldable LCD monitor and standard keyboard. It is connected to the active network management and support services (NMSS) server and switched between servers using Windows Remote Desktop.
43
Table 3: HX GTWY devices (Continued) HNS Part Number

1037303-0010
Component
DNCC server
Function
The dynamic network control cluster (DNCC) server handles demodulated bursts from inroute subsystem components for one or more inroutes. The DNCC is responsible for bandwidth allocation on the inroutes. Inroute QoS functions are implemented on the DNCC. Two DNCC servers are required in a redundant HX GTWY configuration. DNCC servers operate in 1:1 warm redundancy mode. The nonredundant HX GTWY configuration uses one DNCC server.
1037177-6000
IF subsystems
The intermediate frequency subsystem-turbo code (IFSS-TC) handles inroute physical layer functions such as demodulation and channel decoding. The IFSS-TC transfers demodulated bursts to the DNCC for higher level protocol processing. The IFSS-TC is implemented on a 3-unit (3U) rack-mountable compact peripheral component interconnect (cPCI) chassis. The cPCI chassis houses one control processor (CP) and three return channel demodulator (RCD) units. Each RCD contains one software radio module (SRM) and one receive converter module (RCM). The nonredundant HX GTWY configuration uses a single IFSS-TC unit.
9012734-0001
LAN switch
The LAN switch is a Cisco 3750 24-port model that provides 24 10/100 Mbps LAN ports and two 1000Mbps SFP ports. It also supports VLAN tagging. The LAN switch redundant power supply (RPS) is a Cisco unit that provides backup power to the LAN switch.
9012808-0002
LAN switch RPS
Redundancy readiness Some examples of redundancy readiness levels are described in levels Table 4.
Table 4: Examples of redundancy readiness levels Level
None Description No redundancy, not even a shelf spare, is in place. Example: An antenna. A spare component must be brought from storage and manually installed in place of the failed primary component. Example: UEM A spare component is installed and connected but is not configured (and may not even be powered on). Example: MFS
Switch-in Time
Very, very slow (Weeks) Very slow (Days)
Switch-in Mechanism
Purchase order
Shelf Spare
Manual
Cold
Slow (Hours)
Usually manual
44
Table 4: Examples of redundancy readiness levels (Continued) Level

Warm Description A spare component is installed, connected and initialized. However, the backup component does not track any state information of the primary component and, therefore, must establish state (e.g. bring up PEP backbone connections) when it switches in. Example: IP Gateways and DNCCs A spare component is installed, connected and initialized. The backup component tracks enough state information of the primary component to switch in almost transparently. Example: Satellite Gateway Multiple components are installed with all of the components active. If a component fails, the remaining components of the pool take on the load of the failed component. Example: Inroutes Multiple components are installed with all of the components active. All components provide an identical service only one instance of which needs to be present for correct functionality. Example: Timing Units Multiple components which perform the same function are used so that a failure of one of the components only impacts those other system components connected to or associated with the failed component. Those other system components connected to or associated with the non-failed component continue to function. Example: LAN Switches
Switch-in Time
Fast (Minutes)
Switch-in Mechanism
Manual or automated
Hot
Very fast (Seconds)
Usually automated
Pooled
N/A
Automated
Active
N/A
N/A
Diversity
N/A
N/A
Functional subsystems The HX GTWY devices, interconnections, and software for both
redundant and nonredundant configurations collectively implement the system illustrated in the functional block diagram in Figure 18. The subsystems illustrated in Figure 18 are as follows: Outroute Subsystem contains the baseband equipment within the HX GTWY that carries traffic for a single outroute. Inroute Subsystem contains the IF and baseband equipment within the HX GTWY for the inroute groups supported by the DNCC(s). Common Subsystem contains the baseband equipment within an HX GTWY that is neither dedicated to a single outroute nor dedicated to a single inroute subsystem. An HX GTWY has a single common subsystem.
45
Timing Subsystem contains the equipment for providing the timing and frequency reference to the entire system. HX GTWY LAN This physical LAN carries traffic from different VLANs that are used by HX GTWY components.
46
PSTN
Enterprise Router
Private Intranet Public Internet
Outroute Subsystem
IPGW
IPGW-SATGW Server
Timing Generator
Dual Timing Unit
Timing Subsystem
SATGW
Dual GUM
DVB Modulator
System IF Distribution
RFT
TxSOSF
10MHz
MGMT VLAN MUX VLAN RC VLAN
MGMT VLAN
MGMT VLAN MUX VLAN
Legend
Inroute Subsystem
Outroute Subsystem
TxSOSF
Timing Subsystem
Common Subsystem
GTWY LAN
MGMT VLAN CP VLAN
TxSOSF
Timing/ Reference
MGMT VLAN MUX VLAN RC VLAN

MGMT VLAN MUX VLAN RC VLAN CP VLAN
IF Signals
LAN/VLAN cPCI Bus
NMSS Server
WebACS
CAC
MGW
CP
RCD
MFS
Database
DNCC
MGW
Figure 18: HX system subsystems and components

cPCI Bus
DNCC Server
RCD
Return Channel IF Distribution
Vision
HP OpenView
QMPC
Inroute Subsystem
RCD
IFSS-TC
Common Subsystem
T0150006 12/27/06
47
Common subsystem
The common subsystem is the name given to the functional elements running in the NMSS server. These elements are: WebACS Web-based auto-commissioning (WebACS) eliminates the need for intervention by the HX GTWY operator during remote terminal commissioning, thereby expediting remote terminal installations and reducing the number of configuration errors. Database Server stores GTWY configuration information, remote terminal information, and other information used to support data center operations. Conditional Access Controller (CAC) provides encryption key management for outroute traffic. The CAC receives transactions from WebACS and provides encryption keys to the outroute subsystem via periodic multicast, and to the system terminals via periodic multicast or unicast. Vision UEM is the HX System element management system. It incorporates four major network management components: Standalone network management server Graphical user interface (GUI) Back end or management database HP OpenView (optional. Other network management software can be also be used.) These components enable the operator to monitor, configure, and control HX network components. Vision UEM runs on the NMSS platform in the HX GTWY. Management Gateway (MGW) special-purpose IP gateway running on the DNCC server, the MGW routes management traffic between the Vision UEM and the remote terminals. Management traffic includes status and configuration files targeted to HX GTWY components. The MGW is also responsible for remote software downloads.
Note: The MGW is also referred to as the software download (SDL) server.
Management File Server (MFS) is both a repository and a component controller. It is a repository both for software downloads and HX GTWY component parameter files. The MFS also controls the enable/disable functions of HX GTWY components, notifies those components of the associated parameter files, and ensures that the correct versions of those files are being accessed.
48
The MFS, which runs on the NMSS platform, relies on the management gateway client (MGC) installed on each managed component. Quality Monitor PC (QMPC) Used in redundant systems only, the QMPC ensures that only one SATGW-DVB modulator chain passes traffic at any given time. The SATGW-DVB modulator chain to pass traffic can also be selected manually by the HX GTWY operator In the HX System, WebACS, the database server, CAC, Vision UEM, the MGW, and the MFS are implemented on a single high-performance server called the NMSS (network management and support services) server.
Timing subsystem
The timing subsystem provides the master timing and frequency reference for the entire system. It also maintains the timing synchronization between the HX GTWY and the remote terminals. This subsystem consists of a timing generator and a self-hosted dual timing unit (DTUs).
Timing generator The timing generator provides the reference frequency and timing
to several HX GTWY components, including the outroute modulator (one in the nonredundant system and two in the redundant system), the DTU, the DNCC(s), and the IFSS-TC(s). It also generates a superframe pulse for the DNCC(s) and DTU. The reference pulse is the transmit start of superframe (TxSOSF). The TxSOSF pulse is approximately 1 msec wide and occurs once every 360 msec. For the redundant configuration, the system is designed so that two timing generators share the same clock/reference signal lines. One of these timing generators (the master) actively drives the lines, while the other (the slave) is in high impedance mode.
Dual timing unit The dual timing unit (DTU) provides return channel timing for a
specific outroute. The DTU generates accurate frame timing information to the remote terminals. The frame timing is conveyed to the remote terminals via the super frame numbering packet (SFNP) that is sent periodically on the outroute (see TIA-1008, IPoS technical standard). With closed loop timing there is only one TU and a redundant TU. The two TUs operate with hot redundancy. Both TUs send the SFNP an a remote terminal can receive the SFNP from either TU.
49
Outroute subsystem
The outroute subsystem performs the multiplexing and transmission of all outbound IP traffic. All outbound traffic is formatted to conform to the digital video broadcast over satellite (DVB-S2) standard. The outroute subsystem consists of the satellite gateway(s), IP gateway(s), and DVB modulator. Satellite and IP gateways are implemented on a single high-performance server. The DVB modulator is a commercial off the shelf (COTS) product.
Satellite gateway The SATGW receives traffic from other HX GTWY components
over a VLAN segment, formats them into individual packets, encrypts them, and forwards them to the DVB modulator for transmission over the satellite. The SATGW receives this traffic over the satellite VLAN from the following components: IP gateway DNCC DTU Conditional access controller (CAC)
The SATGW can receive traffic using both unicast and/or multicast addressing.
DVB modulator The DVB modulator is paired to the SATGW. The DVB
modulator output is fed to the system IF distribution. The DVB modulator supports symbol rates from 1 to 30 Msps. With the combination of FEC and BCH/LDCP coding, the DVB-S/S2 carrier transmitted from the HX GTWY is virtually error free.
IP gateway The IP gateway provides the interface between the HX GTWY

and the enterprise intranet terrestrial data connections. The IP gateway performs the IP address mapping, packet transmission, compression, and other functions needed to support the HX remote terminals. Traffic between the IP gateway and the intranet host uses a standard IP packet format. However, the IP gateway implements an Hughes-proprietary protocol between itself and the remote terminals that is optimized for efficient, yet reliable communication over the satellite link. The IP gateway implements the performance-enhancing proxy (PEP) features. It also obtains the encryption information from the CAC and sends that information to the SATGW, where the traffic stream is encrypted. The IP gateway records statistics files containing data on the amount of traffic that has been processed for each IP subnet. In the redundant configuration, the IP gateways are designed as a
50
warm redundant pair with online and standby modes of operation. The IP gateway is SNMP-enabled and configured, controlled, and monitored by Vision UEM running on the NMSS. The IP gateway functionality also includes support for multicasting services. In this mode, the IP gateway forwards multicast data (such as multimedia, advertising content) and streams it out to the remote sites that are enabled to receive the multicast stream using the conditional access system. Additionally, the IP gateway can also be configured with committed information rate (CIR) thresholds for each remote terminal, as well as CIR for the entire gateway (based on the contracted grade of service). Depending on the size of the network, there may be many IP gateways within a single HX System GTWY. Typically, the HX GTWY contains at least one IP gateway for each inroute subsystem.
Outroute redundancy For the redundant configuration, outroute redundancy is

implemented to switch the SATGW/DVB modulator chain. The functionality of monitoring the outroute and commanding a switchover is implemented by the quality monitor PC (QMPC) software component. The QMPC runs on the NMSS server. The QMPC ensures that only one SATGW-DVB modulator chain passes traffic at any given time. The SATGW-DVB modulator chain to pass traffic can also be selected manually by the HX GTWY operator.
Note: The nonredundant HX system configuration does not contain a QMPC.
Inroute subsystem
The HX GTWY can be configured with one or more inroutes. Each inroute is a time-division multiple access (TDMA) return channel. The inroute subsystem manages the return channels associated with a group of remote terminals. The inroute subsystem consists of the return channel IF distribution module, either one or two DNCCs, depending on whether the system is redundant or nonredundant, and a number of RCDs. The return channel IF distribution module receives the IF output from the system IF distribution module and forwards it to the RCDs after amplification. The RCD demodulates and decodes the transmission from the remote terminals. The traffic is then forwarded to the DNCC.
51
IF Subsystem-Turbo Code The IF Subsystem-Turbo Code (IFSS-TC) is a modular system system that: Acts as the HX GTWY satellite radio receiver. Demodulates and decodes inroute signals received from remote user terminals via the satellite. A typical redundant configuration includes two independent compact peripheral component interconnect (cPCI) chassis, that contain storage media, power supplies, software radio modules (SRMs), control processors (CPs), CP transition boards, and receive converter modules (RCMs). A nonredundant system contains one cPCI chassis.
Dynamic network control The dynamic network control cluster (DNCC) performs all the cluster processing and control functions of the inroute subsystem. The
DNCC manages return channel bandwidth and the RCDs. The DNCC receives traffic bursts and control bursts from the RCDs. The traffic bursts contain terminal IP traffic as well as piggybacked bandwidth requests. The control bursts can contain terminal status, bandwidth requests, or ranging information. Ranging is used to adjust the operational parameters of a site and to fine-tune the remote terminal's timing and transmit power without the need for user intervention. If the DNCC requests that the remote terminal enter ranging mode, the remote terminal uses its assigned ranging burst. Based upon these measurements, the site chooses the proper settings to transmit traffic to the DNCC. The DNCC processes each type of burst and constructs IP packets, which are forwarded to the IP gateways. Different bandwidth allocation algorithms are implemented on the DNCC. The DNCC also generates and loads the burst time plans to the RCDs. Additionally, the DNCC generates the frame timing messages and forwards them to the timing components as well as the traffic RCDs. The DNCC is simple network management protocol (SNMP)-enabled. The DNCC maintains detailed logs on all events pertaining to the inroute subsystem. These include ranging/commissioning information, inroute packet statistics, and other relevant data. Redundant HX GTWYs contain two DNCCs configured as a warm redundant pair with primary (online) and secondary (standby) modes of operation. Control Processor To maximize efficiency when processing traffic, each inroute defined at the DNCC is assigned an inroute group. All inroutes in the same group are managed by the same CP.
52
Each CP can support the following: 12 inroutes, 256/512 ksps Turbo BCH at 1/2, 2/3, and 4/5 forward error correction (FEC) rate 6 inroutes, 1024 ksps Turbo BCH at 1/2 and 4/5 FEC rate 3 inroutes, 2048 ksps Turbo BCH at 1/2, 2/3, and 4/5 FEC rate RCDs are housed in a cPCI chassis. The HX GTWY rack can support either one or two cPCI chassis, with three RCDs per chassis. Each RCD can support a single inroute type (combination of symbol rate, FEC rate, and coding type).
Local area networks
The HX System GTWY uses LANs and VLANs to simplify connections and reduce cable clutter. The following list shows the configuration of the LAN/VLAN network. GTWY LAN Management VLAN Satellite or MUX VLAN Return channel VLAN Control processor (CP) VLAN Enterprise LAN/VLAN
53
Figure 19 illustrates the connectivity among the various GTWY components.
DNCC Server
IF Subsystem Turbo Code
DVB Modulator
Dual Timing Unit
GTWY LAN
LAN SWITCH
MGMT VLAN MUX VLAN RTN VLAN CP VLAN
NMSS Server
IPGW-SATGW Server
ENT LAN/VLAN
Router
Enterprise IP Network
Customer Data Center

T0150011 5/28/06
Figure 19: GTWY components and how they connect through LANs
GTWY LAN The HX System GTWY LAN is used for internal

communications and consists of the following VLANs: Management VLAN Satellite VLAN Return channel VLAN CP VLAN
Management VLAN The management VLAN connects the network management subsystem to the other subsystems. Multiplex (MUX) VLAN The MUX VLAN connects the multicast broadcasters to the MUX subsystem. This VLAN is sometimes called the satellite or the backbone VLAN. Return channel VLAN The return channel VLAN is used by the DNCC to forward packets received from the remote terminals to the IP gateway. (See Dynamic network control cluster on page 52 for information about the DNCC.)
54
CP VLAN The CP VLAN is used for communication between the DNCC and the IFSS-TC.
Enterprise LAN/VLAN The enterprise LAN connects the HX System GTWY to the
customers enterprise network.
System console
The HX GTWY rack includes a slide-out flat-panel monitor/keyboard that is used as the console for the various Windows-based servers in the rack (the NMMS, DNCC, and IPGW-SATGW servers). Rather than use a keyboard, video, mouse (KVM) switch to share the system console between the servers, the HX GTWY uses Windows Remote Desktop.
55
56
Chapter 7
Remote terminals
This chapter describes HX remote terminals and the indoor units that can be used in them. It addresses the following topics: Overview on page 57 Features on page 59 Remote configuration and commissioning on page 60 Remote device support on page 61
Overview
The Hughes HX system is a spectrum effective solution for cellular backhaul.The Hughes HX sysem enables capacities up to 3 Mbps connections with E1 and IP interfaces. The services and applications that can be supported on the Hughes HX platform include the following: GSM voice with GPRS and Edge CDMA2000 1x CDMA wireless local loop VoIP Video-over-IP
The HX system also utilizes RAN optimization which provides a bandwidth and spectrum efficient solution for the lower traffic locations and provides a completely managed solution to Enterprise customers while addressing the specific requirements of the cellular market.
Chapter 7 Remote terminals 1037105-0001 Revision D
57
Figure 20: Typical HX100 remote site configuration
The HX System remote terminals can employ three different indoor units: the HX50, HX100, or HX150. HX50, HX100, and HX150 remote terminals are self-hosted, which means they do not require a PC to support operations. They download their software directly from the HX System gateway (GTWY). Their configuration parameters are also set by the GTWY, or in some cases, optionally at the remote terminal through its System Control Center interface.
Antenna HX remote terminals typically use a 1-meter rectangular linear

antenna. The size and shape of the antenna depends on the specific characteristics of the deployed system, particularly the link budget.
Outdoor unit Mounted on the antenna, the ODU includes the two-way radio,
which enables reception of signals from, and transmission of signals to the GTWY via the satellite.
Indoor unit The indoor unit is a standalone platform that communicates with
customer devices using Ethernet ports to provide access to HX outroutes and inroutes. HX indoor units include two Ethernet ports.
58
Features
The HX50, HX100, and HX150 remote terminals route IP traffic from the outroute onto remote site LANs and transmit data back on the inroute. Table 5 lists the remote terminal features.
Table 5: Features list for HX50, HX100, and HX150 remote terminals Features HX50
X X X X X X X
HX100
X X X X X X X
HX150
Two 10/100BaseT LAN ports to allow configuration of two independent LAN segments (subnets) at the customer site high bandwidth requirements and many simultaneous users Ku-, Ka-, and C-band transmission L-band interface Designed for enterprise and government networks Dual LAN ports High bandwidth availability DVB-S/S2 outroute Mobility support through doppler compensation Spreading Linear radio support Rack mounting kit Standard and custom IP network protocols and features DHCP server and DHCP relay support IGMP for multicast to LAN VLAN tagging ICMP support (pings, etc.) Embedded web server for remote status query and configuration NAT/PAT RIPv2 DNS caching Static and dynamic addressing Firewall support through integrated access control lists Supports unicast and multicast IP traffic Obtains software and configuration updates via download from the HX GTWY Implements dynamic, self-tuning PEP software to accelerate the throughput performance by optimizing the TCP transmission over the satellite Provides bidirectional data compression Provides configuration, status monitoring, and commissioning via the gateway Utilizes embedded Web interface for local status and troubleshooting Incorporates remote terminal management via UEM and SNMP Quality of service features On-demand constant CBR services Minimum CIR with fixed steps to maximum rate (rate limiting)
X X X
X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X
59
Table 5: Features list for HX50, HX100, and HX150 remote terminals (Continued) Features
Minimum CIR with best effort to maximum rate (rate limiting) Best effort services-weighed fair queueing Class-based weighted prioritization Multicast data delivery Four levels of IP traffic prioritization Bandwidth allocation features Supports both preassigned (static) and dynamic traffic assignment Idle remote terminals can be configured to release all network resources High availaillity features Closed-loop control between hub and remote terminal Dynamic outbound coding and modulation changes based on receive signal Dynamic inbound coding changes based on received signal Dynamic remote terminal uplink power control X X X X X X
HX50
HX100
HX150
X X X X X
Note:
While the HX50 and HX100 share a basic set of features and functionalities, the HX100 offers a rack mounting kit over the HX50. The HX100 is packaged in a thin horizontal enclosure and includes a mounting kit for optional rack installation. The HX50 has a smaller, more portable desktop form-factor and includes an attachable pedestal base for optional vertical mounting.
Remote configuration and commissioning
A key advantage of the HX system is the ability to centrally configure and commission remote terminals. Most of the networking features of satellite terminals can be configured centrally using the Vision UEM software. NAT, firewall rules, and many other parameters are assigned to remote terminals through preconfigured profiles created at the HX GTWY. Configuration of many of these items can be delegated to the satellite terminals, allowing, for instance, firewall rules to be defined remotely at the satellite terminal through it system control system interface and pushed out to individual or groups of remote terminals. This flexibility allows operators to design exactly the right combination of centralized and decentralized network management appropriate to their particular enterprise. Remote commissioning is another important HX feature. Remote commissioning allows configuration parameters for remote terminals to be automatically uploaded to remote terminals from the WebACS (Web-based auto commissioning) server in the HX
60
GTWY. Installers use an embedded web-based wizard served by the remote terminal to configure positional and other basic parameters; remaining data is provided by the WebACS system.
Remote device support
HX system remote terminals support connected: IP devices VoIP devices (optional) Connected IP devices must implement the standard IP stack and provide an Ethernet interface; otherwise there is no constraint to the platforms and operating systems of devices attached to the remote terminals. For example, PCs, MACs, SPARC and Alpha workstations, AS400 systems, and so on, can all be used with the HX remote terminals, running operating systems such as Windows, Linux, Solaris, MAC OS X, AIX, VMS and others.
61
62
Chapter 8
Network management
This chapter describes the network management functions provided by the Vision Unified Element Manager (UEM), including: Overview on page 63 Configuration management on page 65 Fault management on page 67 Performance management on page 67 Security management on page 68 Component control on page 69
Overview
The Vision UEM system provides management tools for HX System gateway (GTWY) components and interface equipment, including: IP gateway Dual timing unit Satellite gateway DVB modulator Management gateway (MGW)
All other network components and equipment are managed through their own interfaces. Figure 21 illustrates the network management system architecture and how it connects to other HX GTWY components.
Chapter 8 Network management 1037105-0001 Revision D
63
MGMT VLAN
IPGW-SATGW Server
IPGW
UEM Client
NMSS Server
SATGW
Vision UEM
CAC
DNCC Server Customer Access LAN
WebACS
MFS
DNCC
Database
QMPC
MGW
HP OpenView
IFSS-TCS
CP
T0150007 12/27/06
Figure 21: Network management system architecture
NMSS server components The HX GTWY incorporates four major network-management

components within a single high-performance server: Element-management server Graphical user interface (GUI) Back end database HP (optional. Other network management softwares may be used.)
These components enable the HX GTWY operator to perform both network operations (such as monitoring network status and statistics) and overall network management activities (such as configuration and control).
64
Configuration management
Vision UEM configures remote site components (satellite terminals and appliances) and some of the HX GTWY components. The network configuration is stored in the UEM database, and operators can maintain it either through the Vision graphical user interface (GUI) or provision components using a batch mode facility. In addition, Vision provides a commissioning interface to the Web-based auto commissioning system (WebACS) to support the auto-commissioning of remote terminals.
GTWY component Vision UEM generates configuration files for each configuration Vision-managed GTWY component as needed, and sends them to
the MFS component of the NMSS server. The MFS acts as a central repository for all configuration and software files for Vision-managed GTWY components. Each GTWY component managed by Vision contains a management gateway client (MGC). MGC is in constant communication with MFS using a proprietary protocol. the MGC downloads configuration files from MFS.
Remote site component Vision UEM also generates configuration files for remote site configuration components. It communicates with remote components through a
specialized mechanism called software download (SDL), which informs the components of changes in required files. The SDL protocol permits files to be delivered in both push (sent unilaterally by Vision UEM) and pull (requested explicitly by the remote component) modes. In addition, Vision UEM uses a multicast delivery mechanism to transmit shared files simultaneously to all remote components that need them, thereby conserving outroute bandwidth. Files that are not shared between components are sent via unicast delivery.
Profiles and profile groups To simplify the task of managing the many different
configuration parameters available in the HX System, Vision UEM provides conceptual groupings of related parameters called profiles. Profiles are generally organized by function or feature, and can be of two types: shared and unique. Shared profiles can contain such parameters as resource allocations and tuning parameters, which are often shareable. Operators can create shared profiles and manage them independently of any particular network component. Unique profiles contain parameters, such as interface addresses, whose values cannot be shared because they must be specific to a component.
65
Most shared profiles are optional profiles. Profiles containing parameters that must be configured on a device are considered mandatory profiles. Profiles containing critical values that should be changed only by a network administrator are considered restricted profiles. A network administrator can determine which profile types are considered restricted. Because the large number of optional features can make even the management of profiles tedious, Vision UEM provides an even higher level of conceptual grouping called the profile group. A profile group is simply a collection of shared profiles that can be associated with a component as a set. A remote site component can be associated with one core profile group, which is assigned by a network administrator, and optional customer profile groups, which can contain profiles that are not restricted.
Software configuration Vision UEM supports the ability to remotely install and upgrade management software images on both GTWY and remote site components.
Software profiles are used to manage software versions. Vision distributes software files to GTWY and remote components using the same mechanisms used to distribute configuration files. Software images for remote components are multicast via SDL.
Configuration interfaces Vision UEM provides a number of interfaces through which

network configuration can be defined and maintained. The Vision UEM graphical user interface (GUI) is the interactive interface that operators use to perform initial network definition and the creation of profiles, users, and hub components, as well as other administrative tasks. The GUI provides full manual control of all configuration parameters and system settings, subject to configured operator access policies and restrictions. HX GTWY personnel can use the GUI, as can customers at remote sites and customer support agents. Vision UEM also has a provisioning interface intended for batch-mode definitions of remote site components. The provisioning tool extracts a list of sites to be provisioned from an extensible markup language (XML) formatted file and updates the Vision UEM database with the site definitions and configurations. A typical use of this tool is the integration of a service provider's order-entry system. For better integration with desktop tools, there is also a utility to convert comma-separated value (CSV)-formatted files into XML. Finally, Vision UEM provides a commissioning interface that is used by the WebACS during the auto-commissioning process.
66
Fault management
Fault management functions provided by Vision UEM include status monitoring, reporting, and alarms.
Status monitoring Vision monitors the status of GTWY and remote site network
components through simple network management protocol (SNMP) and proprietary Hughes protocols. All managed HX network components have embedded SNMP agents that can report status and statistics information to a suitably configured SNMP manager. Vision uses SNMP to periodically obtain key status information from GTWY components. It can also query remote site components periodically for key status information, although this capability can be disabled to conserve network resources. Vision can use an alternate mechanismthe very small aperture terminal (VSAT) information protocol (VIP)when available, to get status information from remote sites more efficiently. Current status information is displayed on the Vision UEM GUI through color-coded icons. The GUI also provides fault-isolation capabilities that operators and customer support agents can use to troubleshoot and diagnose faults. The diagnosis functions use real-time SNMP queries to report up-to-date information from network components.
Alarms HX network components with SNMP agents generate SNMP

traps when certain error conditions occur, and send them to a configurable trap IP address. The traps generated by network components are documented in the SNMP management information base (MIB) definitions for those components. To assist in the detection of failed sites or specific patterns of network failures, Vision UEM can generate certain alarms in the form of SNMP traps. For example, a component alarm can be generated when a remote site has been down for a configured period of time, and an aggregate alarm can be generated when the number or rate of failures of components in a specific group exceeds a configured threshold.
Performance management
Vision UEM provides both real-time and historical statistics on network components and traffic. These statistics are obtained by querying components through SNMP.
Real-time statistics Real-time performance reports are shown through the Vision
UEM GUI. Detailed statistics, which are updated periodically, can be displayed on every managed network component. The
67
display formats can be changed dynamically to show absolute values, relative values, deltas, or rates. Vision UEM also has an integrated graphing tool called FlexGraph that can be used to build an ad hoc graph of selected statistics to display trends in real time.
Historical statistics The historical statistics collection feature enables users to define
ad hoc sets of statistics to be sampled periodically and saved in a disk file. Vision UEM can run the sampling operations between a specific range of times, and save the results in a comma-separated variables- (CSV-)formatted file. This facility can be used for long-term trend analysis.
Security management
Vision UEM provides mechanisms for operator security, network component security, and encryption key management.
Operator security Vision UEM controls all access to network management features
by user-level authentication. All interfaces, whether interactive, batch-mode or programmatic, are protected by a user id/password login sequence. There are two classes of users defined. Privileged users have unrestricted rights. They can define other users, assign access rights for those users, and perform other supervisory and administrative functions. Unprivileged users can only perform actions for which access rights have been granted to them.
Network component The network is logically partitioned into network management security domains (NMDs):
Configuration NMDs Management NMDs Each operator can be associated with one or more NMDs, thus restricting that operators access to network devices only in the assigned NMDs. Configuration NMDs Vision supports logical partitioning of the network into non-overlapping domains called configuration NMDs. Partitioning is performed at the network device (remote terminal or HX GTWY component) level. When a network is installed, one NMD, called the default NMD, is automatically provided. Each device belongs to exactly one NMD.
68
Management NMDs To limit the number of service offerings that must be managed and maintained, all value-added resellers (VARs) are presented with the same set of service offerings (and therefore, profile groups). Because profile groups are linked to NMDs, all remote terminals belonging to VARs must reside in the same NMD in the Vision UEM system. To allow each individual VAR to monitor and control its own remote terminals, yet prevent them from accessing other VARs remote terminals, Vision UEM provides a management NMD that may be assigned to each remote terminal. Operators can then be assigned to a management NMD. Management NMDs differ from configuration NMDs in three important aspects: A management NMD is optional for a remote terminal. Any operator assigned to a management NMD may ONLY be granted monitor and control privileges to those remote terminals within the management NMD. No configuration privileges may be granted to any operator within a management NMD.
Encryption key The management of traffic encryption keys is performed by the management UEM/CAC. See For more information, see Chapter 5 Network
security.
Component control
Vision UEM can send commands to network components using SNMP for actions such as resets, reboots, and forced reloads of software configuration.
HX GTWY control You can send commands to the following HX GTWY

components: IPGW/SATGW Management file server (resides on the NMSS server)
Remote site control You can send commands to the following components at remote
sites: Voice appliances (VAPs) Remote terminals
69
70
Chapter 9
Acceleration features
The HX system provides several features to compensate for the latencies inherent to satellite systems. The inroute IP header and IP packet payload compression techniques discussed in Bandwidth conservation features on page 31 and the traffic prioritization mechanism described in IP packet delivery prioritization on page 32 are a few of the methods employed accelerate communication between the HX GTWY and remote terminals. In addition to these techniques, the HX System employs the performance-enhancing proxy (PEP) to compress data and reduce overhead caused by IP handshakes and acknowledgements, and domain name server (DNS) and web-caching features in the remote terminal to reduce DNS lookups and web page transmissions. These features are described in the following sections: Performance Enhancing Proxy (PEPV3) on page 71 DNS caching on page 72
Performance Enhancing Proxy (PEPV3)
The performance-enhancing proxy (PEP) feature improves the throughput and response time of Internet applications while minimizing required bandwidth. The HX remote terminals implement the PEP feature, which includes bidirectional TCP spoofing, data and header compression, IP prioritization, acknowledgement reduction, and message multiplexing. The PEP feature can be disabled if required.
TCP spoofing TCP spoofing uses local devices in place of devices on the other
side of the satellite link to respond to TCP overhead messages. For example, in the PEP TCP spoofing scheme, the HX GTWY acknowledges packets from the enterprise network, while remote terminals acknowledge packets sent to the enterprise network from the remote LAN. PEP also spoofs the three-way TCP connection handshake and connection terminations. The Hughes PBP (PEP backbone protocol) is used in the space segment. It multiplexes multiple TCP connections for transport across the satellite link, thus reducing delays and maximizing bandwidth efficiency.
Chapter 9 Acceleration features 1037105-0001 Revision D
71
PEP and TCP payload PEP can compress packet payloads to achieve savings in data compression transmission time. PEP uses the V.44 lossless compression
algorithm and stateful compression; that is, compression is applied across multiple packets at a time to take advantage of the greater data redundancy available across multiple packets, and consequent greater compression ratios. Compression ratios of up to 12:1 are achieved. PEP compression can be enabled on individual PEP connections.
DNS caching
DNS caching is optionally enabled at the HX GTWY using Vision UEM. The DNS caching feature employs a DNS-caching proxy on the remote terminal to cache resolved DNS requests. Requests for previously resolved addresses are provided from the cache, saving the delay and bandwidth required to send the DNS request across the satellite link for resolution. DNS caching is enabled on remote terminals using remote terminal profiles configured in the Vision software.
72
Chapter 9 Acceleration features 1037105-0001 Revision D
Chapter 10
Multicast features
The HX System supports IP multicasting services. In this mode of operation, the Internet protocol gateway (IPGW) forwards multicast data (bandwidth-intensive, timing sensitive rich-media data such as digital audio and video broadcasts) and streams it out to remote sites that are enabled, via the conditional access system (CAS) to receive the multicast stream. Additionally, the IPGW can be configured with minimum and maximum committed information rate (CIR) thresholds for each application, as well as CIR for the entire gateway (based on the contracted grade of service). This chapter describes the multicast applications supported by the HX system and the methods used in the HX GTWY and remote terminals to implement multicast support, addressed in the following sections: Multicast applications on page 73 HX GTWY multicast management on page 74 Remote terminal multicast support on page 74
Multicast applications
The HX System uses multicasts for a number of purposes, such as transmitting control information and configuration files generated by the Vision UEM system, and for transmitting IGMP protocol traffic such as conferencing, streaming media or other multicast media. Network time protocol messages are also multicast. From the end user perspective, the most important of these is IGMP protocol support.
Broadcast applications Broadcast enterprise file transfers can be sent to all members of
an enterprise network, with payloads that can provide piped-in music or advertisements used in retail locations. The Hughes system supports broadcast applications with the addition of an optional enterprise package delivery (EPD) server. You define the content and the package distribution to initiate the broadcast application.
Chapter 10 Multicast features 1037105-0001 Revision D
73
Streaming media Streaming media applications can be served by systems on the applications enterprise network and reliably received by systems on remote
LANS by simply configuring the IPGW to provide the required constant bandwidth, and the remote terminals to recognize and pass IGMP traffic. No special equipment or software is required to use the HX system as a pipe for video conferences, video and audio streams, and so on.
HX GTWY multicast management
The HX GTWY can support up to 10 simultaneous multicast streams. Each IPGW can be configured with minimum and maximum committed information rate (CIR) thresholds for each application, as well as CIR for the entire gateway (based on the contracted grade of service). Vision UEM provides a number of features for managing the multicast capability. These include a multicast gateway statistics screen in Vision UEM and SNMP MIBs that provide multicast statistics, including: Received multicast bytes Transmitted multicast bytes Multicast frame collisions
Remote terminal multicast support
Remote terminals can be configured, through their profiles, with a variety of multicast-related parameters, including: IGMP enabled IGMP broadcast advertisement enabled LAN interfaces that can route multicasts The Vision UEM interface also has screens for viewing per-remote terminal multicast statistics collected from the remote terminals. The HX multicast capability works transparently with multicast-enabled PC applications like NetMeeting and others, while minimizing latency and bandwidth required to transmit multicast content. Multicasts from the HX GTWY are also used to prepopulate DNS and web caches in remote terminals.
74
Chapter 10 Multicast features 1037105-0001 Revision D
Chapter 11
HX options
This chapter describes HX optional features that provide additional functionality to the HX System but which are not included in the base HX System. These features include: Enterprise package delivery on page 75 Fenced Internet access on page 77 Firewall protection on page 77 IPSec on page 77 TurboPage on page 77 Voice over IP on page 77
Enterprise package delivery
Enterprise package delivery (EPD) provides a reliable means of transferring large files from a centralized location to an unlimited number of receivers. Packages or files are enclosed in an envelope that is labelled with several parameters that define its source, destination, start/stop times, description, and so forth. Packages for delivery are posted to a customer-supplied server (which can be a simple Windows XP workstation) located at the HX GTWY and running the EPD server software. The server then broadcasts these packages to the remote terminals. The Enterprise Package Delivery software includes a client application that runs on target computers on the remote LAN. The client receives (or catches) the package files delivered with the EPD feature. Windows and Linux clients are available. The client can be configured to associate a process (for example, an executable file) with received packages meeting predefined criteria, and to launch the associated process automatically upon receipt of a package. Figure 22 illustrates the Enterprise Package Delivery feature.
Chapter 11 HX options 1037105-0001 Revision D
75
HX100
IP Multicast
Enterprise package delivery receivers
HX100 HX GTWY
Enterprise package delivery receivers

T0150023 9/13/06
Enterprise package delivery sender
Figure 22: Enterprise package delivery
76
Fenced Internet access
The Fenced Internet access (FIA) service is a broadband access service that provides a mechanism for enterprise customers to restrict remote site access to a limited number of specifically approved Internet sites. Different lists of approved sites can be supported for multiple subsets of a customer's chosen remote sites. The Fenced Internet Access feature requires the TurboPage server option.
Firewall protection
A firewall appliance can be added to protect the GTWY from security attacks originating from the HX backend systems while granting these systems limited access to the Web-based auto-commissioning system (WebACS) servers.
IPSec
IPSec support is provided with the addition of a VPN IPGW server, typically located at the customer premises. The Vision UEM software provides the configuration and management features used to manage the IPSec feature on both the VPN IPGW and IPGW-SATGW servers. No additional software is required. Communication between the HX GTWY and the VPN IPGW is over a secure link provided by the customer.
TurboPage
TurboPage web acceleration uses the HTTP performance enhancing proxy (HPEP) to increase the speed of web page loading. This feature consists of a TurboPage server at the GTWY and a TurboPage client in the remote terminal. The server and client maintain a persistent TCP connection across the satellite link, and all HTTP/TCP requests are multiplexed across this connection. The TurboPage feature parses HTML documents and HTTP responses, and fetches a subset of the referenced uniform resource locators (URLs), and forwards the information over the satellite link. The default behavior forwards embedded images, embedded HTML frames, cascading style sheets, and JavaScript URLs of moderate size, with the maximum prefetched size configurable for each kind of URL.
Voice over IP
Internet voice, also known as voice over IP (VoIP), is a technology that allows customers to make telephone calls using a broadband Internet connection instead of a standard analog phone
77
line. Some VoIP services may only allow calls to other people who use the same service, while others allow calls to anyone who has a telephone number including local, long distance, mobile, and international numbers. Also, while some services only work over a computer or a special VoIP phone, other services allow the use of a traditional phone through an adapter. The special services gateway is used to reserve bandwidth for VoIP. Using VoIP requires a voice appliance at the remote site and a Cisco VoIP gateway at the HX GTWY for public switched telephone network (PSTN) access.
78
Appendix A
Technical specifications
This appendix discusses the following topics: HX GTWY specifications on page 79 HX50/100 remote terminal mechanical and environmental specifications on page 80 HX150 remote terminal specifications on page 81
HX GTWY specifications
Listed below are technical specifications for the HX GTWY. This information includes: outbound and inbound channels, size and scalability, security, network management, and remote terminals and appliances supported in the HX GTWY.
HX GTWY Technical Specifications
Outbound channel DVB-S or DVB-S2 compliant Frequency: C-, Extended C-, Ku-, Extended Ku-, Ka-band Modulation: QPSK/8PSK Symbol Rates: 1-34 Msps (in steps of 1 Msps) Encoding DVB-S: Convolutional with concatenated Reed Solomon; Viterbi 7/8, 5/6, 3/4, 2/3, or 1/2 Encoding DVB-S2: BCH with LDPC 3/5, 2/3, 3/4, 5/6, 8/9, or 9/10 (8PSK); 1/2, 3/5, 2/3, 3/4, 4/5, 5/6, 8/9, 9/10 (QPSK) Bit Error Rate: 10-10 or better Inbound channel FDMA/TDMA Transmit modulation: OQPSK Transmit encoding: Rate 1/2, 2/3, 4/5 TurboCode Transmit bit rates: 256 kbps3.2 Mbps Size and Scalability Base Configuration: Single 26U rack Supports up to 500 terminals Supports up to 16 inbound channels or total inbound aggregate bandwidth of 12.8 Mbps Expansion capable via additional equipment rack
Appendix A Technical specifications 1037105-0001 Revision D
79
HX GTWY Technical Specifications (Continued)

Security Integrated Conditional Access and DES encryption of outbound channel Optional bidirectional 128 bit AES encryption Network Management Systems Hughes Vision NMS Remote Terminals & Appliances Supported HX50 HX100 HX150 Voice Appliance (HN1040)
HX50/100 remote terminal mechanical and environmental specifications
Listed below are the physical, satellite, and antenna specifications common to the HX50 and HX100 remote terminals. Also included are mechanical and environmental specifications for each remote terminal.
Remote Terminal(s) Technical Specifications
Physical Interfaces Two 10/100BaseT Ethernet LAN RJ45 ports One RS-232/RS-422 compatible serial port Satellite & Antenna Specifications Outbound transmission format: DVB-S or DVB-S2 DVB-S2 supports adaptive coding and modulation Information Rate (Receive or HX System Outbound Channel): up to 121 Mbps Information Rate (Transmit or HX Inbound Channel): up to 3.2 Mbps Symbol Rate (Receive): 1-34 Msps (in 1 Msps steps) Symbol Rate (Transmit): 256, 512, 1024, 2048 ksps Encoding DVB-S (Receive): Convolutional with concatenated Reed Solomon; Viterbi 7/8, 5/6, 3/4, 2/3, or 1/2 Encoding DVB-S2 (Receive): BCH with LDPC 3/5, 2/3, 3/4, 5/6, 8/9, or 9/10 (8PSK) 1/2, 3/5, 2/3, 3/4, 4/5, 5/6, 8/9, 9/10 (QPSK) Transmit encoding: Rate 1/2, 2/3, 4/5 TurboCode, Rate 1/2 Convolutional Frequency Range: C-. extended C-, Ku-, and Ka-band Modulation (Receive): QPSK or 8PSK Modulation (Transmit): OQPSK Bit Error Rate (Receive): 10-10 or better Bit Error Rate (Transmit): 10-7 or better
80
Remote Terminal(s) Technical Specifications (Continued)

Radio: 1 and 2 watt Ku-band 2 watt C-band 1, 2, and 3 1/2 watt Ka-band HX50 Mechanical and Environmental Specifications Weight (IDU): 4.8 lbs (2.18 kg) Dimensions (IDU): 11.5" W x 1.8" H x 11" D (29.21 cm W x 4.7 cm H x 27.94 cm D Operating temperature: IDU: 0 C to +40 C ODU: -30 C to +55 C Input power: 90264 VAC; 5060 Hz DC power supply (optional): 1224 VDC HX100 Mechanical and Environmental Specifications 1U enclosure for 19" rack Weight (IDU): 5.5 lbs (2.5 kg) Dimensions (IDU): 19" W x 1.75" H x 18" D (48.26 cm W x 4.45 cm H x 45.72 cm D) Operating temperature: IDU: 0 C to +50 C ODU: -30 C to +60 C Input power: 90264 VAC; 5060 Hz DC power supply (optional): 1224 VDC Input power: 90264 VAC; 5060 Hz
HX150 remote terminal specifications
Listed below are technical specifications for the HX150 remote terminal.
HX150 Technical Specifications
Physical Interfaces Two 10/100BaseT Ethernet LAN RJ45 ports Two RS-232/RS-422 compatible serial ports Satellite & Antenna Specifications Outbound transmission format: DVB-S or DVB-S2 DVB-S2 supports adaptive coding and modulation Information Rate (Receive or HX System Outbound Channel): up to 121 Mbps Information Rate (Transmit or HX Inbound Channel): up to 3.2 Mbps Symbol Rate (Receive): 1-34 Msps (in 1 Msps steps) Symbol Rate (Transmit): 256, 512, 1024, 2048 ksps Encoding DVB-S (Receive): Convolutional with concatenated Reed Solomon; Viterbi 7/8, 5/6, 3/4, 2/3, or 1/2
81
HX150 Technical Specifications (Continued)

Encoding DVB-S2 (Receive): BCH with LDPC 3/5, 2/3, 3/4, 5/6, 8/9, or 9/10 (8PSK) 1/2, 3/5, 2/3, 3/4, 4/5, 5/6, 8/9, 9/10 (QPSK) Transmit encoding: Rate 1/2, 2/3, 4/5 TurboCode, Rate 1/2 Convolutional Frequency Range: C-. extended C-, Ku-, and Ka-band Modulation (Receive): QPSK or 8PSK Modulation (Transmit): OQPSK Bit Error Rate (Receive): 10-10 or better Bit Error Rate (Transmit): 10-7 or better Radio TX IF: Type-TNC Female, 50 ohms, 950 to 1700 MHz, composite power -5 dBm/-35 dBm RX IF: Type-F, 50 ohms, 950 to 2150 MHz, -68 dBm (per carrier at 1 Mbps), -8 dBm (composite) Available LNB Power (IFC): +19.5 V (nominal) 10 Mhz reference available Mechanical and Environmental Specifications 1U enclosure for 19" rack Weight (IDU): 5.5 lbs (2.5 kg) Dimensions (IDU): 19" W x 1.75" H x 18" D (48.26 cm W x 4.45 cm H x 45.72 cm D) Operating temperature: IDU: 0 C to +50 C Input power: 90264 VAC; 5060 Hz
82
Acronyms and abbreviations

A
ACM Adaptive Coding and Modulation AES Advanced encryption standard AIS Adaptive inroute selection FIA Fenced Internet access F-TDMA Frequency-time division multiple access
G
GSM Global system for mobile communication GTWY HX System gateway
B
BSC Base station controller BTS Base transceiver station
GUI Graphical user interface GUM Gateway upconverter module
C
CAC Conditional access controller CBR Constant bit rate COTS Commercial, off-the-shelf CP Control processor cPCI Compact peripheral component interconnect CSV Comma-separated values
H
HPEP HTTP performance-enhancing proxy
I
ICMP Internet control message protocol IDU Indoor unit IFSS-TC IF Subsystem-Turbo Code IGMP Internet group management protocol IKE Internet key exchange IP Internet Protocol IPoS - IP over satellite IPSec Internet protocol security IQoS Inroute Quality of Service
D
DES Data encryption standard DFCP Differentiated services code point DHCP Dynamic host control protocol DNCC Dynamic network control cluster DNS Domain name server DTU Dual timing unit
K
KVM Keyboard, video, mouse
E
EiRP Effective Isotropic Radiated Power
L
LAN Local area network LDSP Low-density parity checking
F
FEC Forward error correction ,
Acronyms and abbreviations 1037105-0001 Revision D
83
M
MFS Management file server MGC Management gateway client MGW Management gateway MIB Management information base MUX Multiplex
S
SATGW Satellite gateway SCPC Single channel per carrier SDL Software download SFNP Super frame numbering packet SLA Service level agreement SNMP Simple network management protocol SRM Software radio module
N
NAPT Network address port translation NAT Network address translation NMD Network management domain NMSS Network Management and Support Services
T
TCP/IP Transmission control protocol/Internet protocol TDMA Time division multiple access TRCS TDMA return channel subsystem TxSOSF Transmit start of superframe
O
ODU Outdoor unit
P
PAT Port address translation PBP PEP backbone protocol PEP Performance-enhancing proxy PSTN Public switched telephone network
U
UDP User datagram protocol UEM Unified element manager URL Uniform resource locator
V
VAP Voice appliance VAR Value-added reseller VLAN Virtual local area network VSAT Very small aperture terminal
Q
QoS Quality of service QPSK Quadrature phase shift keying
R
RCD Return channel demodulator RCM Receive converter module RF Radio frequency RFT Radio frequency terminal RIP Routing information protocol RTP Real-time transport protocol
W
WAN Wide area network
X
XML Extensible markup language
84
Acronyms and abbreviations 1037105-0001 Revision D
Index
A
Adaptive inroute selection (AIS) 6 Alarm monitoring 67 Antennas 58
G
Gateway common equipment (GCE) 51 GSM backhaul 6 GTWY components control 69 GTWY LAN 54 GTWY rack layout 41 GTWY segment components overview 45
B
Backbone VLAN 54 Broadband applications 6 Broadband IP connectivity 6 Burst types, inroutes 16
H
Header compression 32 HX system features 5 overview 4 remote terminals 57 HX50/HX100 features 59
C
Common subsystem components 48 Configuration management 65 Configuration NMD 68 Constant bit rate (CBR) traffic prioritizing 32 Control processor (CP) 52 Controlling GTWY components 69 CP VLAN 55
I
IF subsystem-turbo code (IFSS-TC) system 52 Indoor units (IDUs) 58 INET VLAN 55 Information flow overview 9 Inroute header compression 32 Inroute prioritization 32 Inroutes groups 17 overview 16 types 16 IP addresses, automatic assignment 34 IP gateways 50
D
DHCP server 34 Domain name service (DNS) caching 34 Dual timing units 49 DVB modulators 50 Dynamic network control cluster (DNCC) 52
E
Encryption key management 69 Enterprise LAN 55 Enterprise system overview 8
L
Local area networks (LANs) GTWY 54 overview 53 return channel 54
F
Fault management 67 Features overview 5 Firewall protection 36, 77
M
Management file server (MFS)
Index 1037105-0001 Revision D
85
defined 65 Management NMD 69 Management VLAN 54 MUX VLAN 54
N
Network component security 68 Network management components 64 overview 63 Network management domains (NMD) overview 68
WAN 8 Software configuration 66 Space segment 7 Statistics 67 Status monitoring 67
T
TDMA return channel subsystems (TRCS) 51 Telephony 7 Timing generator 49 Timing subsystem 49
U
Uplink subsystem 50
O
Operator security 68 Outdoor units (ODUs) 58 Outroute redundancy 51
V
Virtual local area networks (VLANs) CP 55 enterprise 55 management 54 satellite 54 Vision overview 48 Voice over IP (VoIP) 77
P
PAT Port address translation 31 Performance management 67 Profile groups 65
R
Ranging 52 Remote terminal segment 7 Remote terminals overview 57 site configuration 65 site control 69 Return channel demodulator (RCD) 51 Return channel equipment 51 Return channel IF distribution module 51 Return channel LAN 54
W
WebACS overview 48 Wide area network (WAN) segment 8
S
Satellite gateway 50 Satellite VLAN 54 Security management 68 Segments GTWY 7 overview 7 remote terminal 7 space 7
86
Index 1037105-0001 Revision D

HXGW Overview

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

HXGW Overview

Загружено:

Авторское право:

Доступные форматы

HX System

1037105-0001 Revision D February 8, 2008

Copyright 2008 Hughes Network Systems, LLC

Chapter 2 Transmission features . . . . . . . . . . . . . . . . . . . . . . . . . . .11

Chapter 3 Bandwidth management . . . . . . . . . . . . . . . . . . . . . . . . .19

Contents 1037105-0001 Revision D

Chapter 4 IP features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

Chapter 5 Network security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

Chapter 6 HX GTWY architecture . . . . . . . . . . . . . . . . . . . . . . . . .39

Contents 1037105-0001 Revision D

Chapter 7 Remote terminals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57

Chapter 8 Network management . . . . . . . . . . . . . . . . . . . . . . . . . . .63

Contents 1037105-0001 Revision D

Chapter 9 Acceleration features . . . . . . . . . . . . . . . . . . . . . . . . . . . .71

Chapter 10 Multicast features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .73

Chapter 11 HX options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75

Appendix A Technical specifications . . . . . . . . . . . . . . . . . . . . . . . . . .79

Acronyms and abbreviations . . . . . . . . . . . . . . . . . . . . .83 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85

Contents 1037105-0001 Revision D

Figures 1037105-0001 Revision D

Figures 1037105-0001 Revision D

Tables 1037105-0001 Revision D

Tables 1037105-0001 Revision D

Audience The primary audience for this document is enterprise customers

Organization This document is divided into the following chapters:

Chapter 1 Overview 1037105-0001 Revision D

Related publications The following documents provide more detailed information

Chapter 1 Overview 1037105-0001 Revision D

Chapter 1 Overview 1037105-0001 Revision D

Chapter 1 Overview 1037105-0001 Revision D

Chapter 1 Overview 1037105-0001 Revision D

Chapter 1 Overview 1037105-0001 Revision D

Remote terminal segment Remote terminals provide broadband TCP/IP communications to

Chapter 1 Overview 1037105-0001 Revision D

Chapter 1 Overview 1037105-0001 Revision D

Outdoor Unit (ODU)

User Sites GTWY

Figure 2: Traffic flow through the HX System

Chapter 1 Overview 1037105-0001 Revision D

RF equipment Remote terminal

GTWY Outroute components

Inroute components Remote terminal

To/from enterprise network

Host User interface components Management components

Host INROUTE OUTROUTE

Figure 3: HX System equipment data flow

Chapter 1 Overview 1037105-0001 Revision D

Outbound channel: DVB-S and DVB-S2

DVB scaling DVB channels are designed to scale effectively to large

Chapter 2 Transmission features 1037105-0001 Revision D

DVB ASI MUX

Figure 4: Multiplexing DVB Streams

Chapter 2 Transmission features 1037105-0001 Revision D

Beam edge most robust coding/modulation QPSK rate 1/2

Beam center most bandwidth efficient coding/modulation 8PSK rate 9/10

Figure 5: Using ACM to optimize the link budget

Chapter 2 Transmission features 1037105-0001 Revision D

Figure 6: Using ACM to dynamically change coding/modulation

Inbound channel: adaptive coding

Figure 7: Multiple FECs within one TDMA frame

Chapter 2 Transmission features 1037105-0001 Revision D

Closed loop control

GTWY sends adjustments to HX remote

HX remote continually measures received signal quality