IDIRECT Technical Reference Guide

Technical Reference Guide

iDX Release 2.0

June 24, 2010

Copyright © 2010 VT iDirect, Inc. All rights reserved. Reproduction in whole or in part without permission is prohibited. Information contained herein is subject to change without notice. The specifications and information regarding the products in this document are subject to change without notice. All statements, information, and recommendations in this document are believed to be accurate, but are presented without warranty of any kind, express, or implied. Users must take full responsibility for their application of any products. Trademarks, brand names and products mentioned in this document are the property of their respective owners. All such references are used strictly in an editorial fashion with no intent to convey any affiliation with the name or the product's rightful owner.

Document Name: REF_Technical Reference Guide iDX 2.0_Rev F_062410.pdf Document Part Number: T0000240

ii

Technical Reference Guide iDX Release 2.0

Contents

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x About This Guide Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Intended Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Contents Of This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

1 iDirect System Overview System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 IP Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 DVB-S2 in iDirect Networks DVB-S2 Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 DVB-S2 in iDirect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 DVB-S2 Downstream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 ACM Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Quality of Service in DVB-S2 ACM Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 DVB-S2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 DVB-S2 Performance Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20


iii

3 Modulation Modes and FEC Rates iDirect Modulation Modes And FEC Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2D 16-State Inbound Coding for DVB-S2 Networks . . . . . . . . . . . . . . . . . . . . . 23

4 iDirect Spread Spectrum Networks What is Spread Spectrum? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Spread Spectrum Hardware Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Downstream Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Supported Forward Error Correction (FEC) Rates . . . . . . . . . . . . . . . . . . . . . 28 Upstream Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 QoS Implementation Principles Quality of Service (QoS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 QoS Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 QoS Application, iSCPC and Filter Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Classification Profiles for Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Service Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Packet Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Group QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Group QoS Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Group QoS Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Application Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 QoS Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Packet Segmentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Application Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Maximum Channel Efficiency vs. Minimum Latency . . . . . . . . . . . . . . . . . . . . 52

6 Configuring Transmit Initial Power What is TX Initial Power? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 How To Determine The Correct TX Initial Power . . . . . . . . . . . . . . . . . . . . . . 53 All Remotes Need To Transmit Bursts in The Same C/N Range. . . . . . . . . . . . . 54 What Happens When TX Initial Power Is Set Incorrectly? . . . . . . . . . . . . . . . . 55 When TX Initial Power is Too High . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 When TX Initial Power is Too Low . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

iv


7 Global NMS Architecture How the Global NMS Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Sample Global NMS Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

8 Hub Network Security Recommendations Limited Remote Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Root Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

9 Global Protocol Processor Architecture Remote Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 De-coupling of NMS and Data Path Components . . . . . . . . . . . . . . . . . . . . . . 61

10 Distributed NMS Server Distributed NMS Server Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 iBuilder and iMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 dbBackup/dbRestore and the Distributed NMS . . . . . . . . . . . . . . . . . . . . . . . 65

11 Transmission Security (TRANSEC) What is TRANSEC? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 iDirect TRANSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 TRANSEC Downstream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 TRANSEC Upstream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 TRANSEC Key Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 TRANSEC Remote Admission Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Reconfiguring the Network for TRANSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

12 Fast Acquisition Feature Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

13 Remote Sleep Mode Feature Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Awakening Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Operator-Commanded Awakening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80


v

Activity Related Awakening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Enabling Remote Sleep Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Power Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

14 Automatic Beam Selection Automatic Beam Selection Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Theory of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Beam Characteristics: Visibility and Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Selecting a Beam without a Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Controlling the Antenna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 IP Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Operational Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Creating the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Adding a Vessel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Normal Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Mapless Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Blockages and Beam Outages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Error Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

15 Hub Geographic Redundancy Feature Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Configuring Wait Time Interval for an Out-of-Network Remote . . . . . . . . . . . . 92

16 Carrier Bandwidth Optimization Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Increasing User Data Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Decreasing Channel Spacing to Gain Additional Bandwidth . . . . . . . . . . . . . . . 95

17 Alternate Downstream Carrier Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Feature Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

18 Feature and Chassis Licensing Licensed Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 License Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

vi


19 Hub Line Card Failover Basic Failover Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Warm Standby versus Cold Standby Line Card Failover . . . . . . . . . . . . . . . . . 101 Failover Sequence of Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102


vii

List of Figures Figure 1. Sample iDirect Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Figure 2. iDirect IP Architecture – Multiple VLANs per Remote . . . . . . . . . . . . . . . . . . . . . 3 Figure 3. iDirect IP Architecture – VLAN Spanning Remotes . . . . . . . . . . . . . . . . . . . . . . . . 4 Figure 4. iDirect IP Architecture – Classic IP Configuration . . . . . . . . . . . . . . . . . . . . . . . . 5 Figure 5. Comparison of SCPC, Constant Coding, and Adaptive Coding Modes . . . . . . . . . . . . 9 Figure 6. Physical Layer Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Figure 7. SNR Threshold vs. MODCOD for Evolution X3 and X5 Remotes . . . . . . . . . . . . . . . 12 Figure 8. SNR Threshold vs. MODCOD for the Evolution e8350 Remote . . . . . . . . . . . . . . . 13 Figure 9. Feedback Loop from Remote to Protocol Processor . . . . . . . . . . . . . . . . . . . . . 14 Figure 10. Feedback Loop with Backoff from Line Card to Protocol Processor . . . . . . . . . . 14 Figure 11. Total Bandwidth vs. Information Rate in Fixed Bandwidth Operation . . . . . . . . . 16 Figure 12. EIR: Total Bandwidth vs. Information Rate as MODCOD Varies . . . . . . . . . . . . . . 17 Figure 13. Spread Spectrum Network Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Figure 14. Remote and QoS Profile Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Figure 15. iDirect Packet Scheduling Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Figure 16. Group QoS Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Figure 17. Physical Segregation Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Figure 18. CIR Per Application Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Figure 19. Tiered Service Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Figure 20. Third Level VLAN Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Figure 21. Shared Remote Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Figure 22. Scaled Aggregate CIRs Below Partition’s CIR . . . . . . . . . . . . . . . . . . . . . . . . . 45 Figure 23. Scaled Aggregate CIRs Exceed Partition’s CIR . . . . . . . . . . . . . . . . . . . . . . . . 46 Figure 24. Bandwidth Allocation Fairness Relative to CIR . . . . . . . . . . . . . . . . . . . . . . . . 47 Figure 25. Bandwidth Allocation Fairness Relative to MODCOD . . . . . . . . . . . . . . . . . . . . 48 Figure 26. C/N Nominal Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Figure 27. TX Initial Power Too High . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Figure 28. TX Initial Power Too Low . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Figure 29. Global NMS Database Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Figure 30. Sample Global NMS Network Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Figure 31. Protocol Processor Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Figure 32. Sample Distributed NMS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Figure 33. dbBackup and dbRestore with a Distributed NMS . . . . . . . . . . . . . . . . . . . . . . 65 Figure 34. Downstream Data Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Figure 35. SCPC TRANSEC Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Figure 36. Upstream Data Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Figure 37. TDMA TRANSEC Slot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Figure 38. Key Distribution Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

viii


Figure 39. Key Rolling and Key Ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Figure 40. Host Keying Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Figure 41. Overlay of Carrier Spectrums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Figure 42. Adding an Upstream Carrier By Reducing Carrier Spacing . . . . . . . . . . . . . . . . . 96 Figure 43. Line Card Failover Sequence of Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103


ix

List of Tables Table 1. DVB-S2 Modulation and Coding Schemes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Table 2. ACM MODCOD Scaling Factors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Table 3. Modulation Modes and FEC Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Table 4. Modulation Modes and FEC Rates for 2D 16-State Inbound Coding . . . . . . . . . . . . . 23 Table 5. Block Sizes and IP Payload Sizes for 2D 16-State Inbound Coding . . . . . . . . . . . . . 24 Table 6. Spread Spectrum: Downstream Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Table 7. Spread Spectrum: Upstream Specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Table 8. Power Consumption: Normal Operations vs. Remote Sleep Mode . . . . . . . . . . . . . 81

x


About This Guide

Purpose The Technical Reference Guide provides detailed technical information on iDirect technology and major features as implemented in iDX Release 2.0.

Intended Audience The intended audience for this guide includes network operators using the iDirect iDS system, network architects, and anyone upgrading to iDX Release 2.0. Note:

It is expected that the user of this material has attended the iDirect IOM training course and is familiar with the iDirect network solution and associated equipment.

Contents Of This Guide This document contains the following major sections: •

“iDirect System Overview”

•

“DVB-S2 in iDirect Networks”

•

“Modulation Modes and FEC Rates”

•

“iDirect Spread Spectrum Networks”

•

“QoS Implementation Principles”

•

“Configuring Transmit Initial Power”

•

“Global NMS Architecture”

•

“Hub Network Security Recommendations”

•

“Global Protocol Processor Architecture”

•

“Distributed NMS Server”

•

“Transmission Security (TRANSEC)”

•

“Fast Acquisition”

•

“Automatic Beam Selection”

•

“Hub Geographic Redundancy”

•

“Carrier Bandwidth Optimization”


xi

•

“Alternate Downstream Carrier”

•

“Feature and Chassis Licensing”

•

“Hub Line Card Failover”

Document Conventions This section illustrates and describes the conventions used throughout the manual. Take a look now, before you begin using this manual, so that you’ll know how to interpret the information presented. Convention Description Blue Courier font

Used when the user is required to enter a command at a command line prompt or in a console.

Enter the command:

Courier font

Used when showing resulting output from a command that was entered at a command line or on a console.

crc report all

Bold Trebuchet font

Used when referring to text that appears on the screen on a windows-type Graphical User Interface (GUI).

1. If you are adding a remote to an inroute group, right-click the Inroute Group and select Add Remote.

Used when specifying names of commands, menus, folders, tabs, dialogs, list boxes, and options.

xii

Example

cd /etc/snmp/

3100.3235 : DATA CRC [ 1] 3100.3502 : DATA CRC [5818] 3100.4382 : DATA CRC [ 20]

The Remote dialog box has a number of userselectable tabs across the top. The Information tab is visible when the dialog box opens.

Blue Trebuchet font

Used to show all hyperlinked text within a document.

For instructions on adding an iSCPC line card to the network tree and selecting a Hub RFT for the line card, see “Adding an iSCPC Line Card” on page 108.

Bold italic Trebuchet font

Used to emphasize information for the user, such as in notes.

Note:

Red italic Trebuchet font

Used when the user needs to strictly follow the instructions or have additional knowledge about a procedure or action.

Several remote model types can be configured as iSCPC remotes.

WARNING! The following procedure may cause a network outage.


Related Documents The following iDirect documents are available at http://tac.idirect.net and may also contain information relevant to this release. Please consult these documents for information about installing and using iDirect’s satellite network software and equipment. •

iDX Release Notes

•

iDX Software Installation Guide or Network Upgrade Procedure Guide

•

iDX iBuilder User Guide

•

iDX iMonitor User Guide

•

iDX Installation and Commissioning Guide for Remote Satellite Routers

•

iDX Features and Chassis Licensing Guide

•

iDX Software Installation Checklist/Software Upgrade Survey

•

iDX Link Budget Analysis Guide

Getting Help The iDirect Technical Assistance Center (TAC) is available to help you 24 hours a day, 365 days a year. Software user guides, installation procedures, a FAQ page, and other documentation that supports our products are available on the TAC webpage. Please access our TAC webpage at: http://tac.idirect.net. If you are unable to find the answers or information that you need, you can contact the TAC at (703) 648-8151. If you are interested in purchasing iDirect products, please contact iDirect Corporate Sales by telephone or email. Telephone: (703) 648-8000 Email: [email protected] iDirect strives to produce documentation that is technically accurate, easy to use, and helpful to our customers. Your feedback is welcomed! Send your comments to [email protected].


xiii

xiv


1 iDirect System Overview

This chapter presents a high-level overview of iDirect Networks. It provides a sample iDirect network and describes the IP network architectures supported by iDirect.

System Overview An iDirect network is a satellite based TCP/IP network with a Star topology in which a Time Division Multiplexed (TDM) broadcast downstream channel from a central hub location is shared by a number of remote nodes. iDX Release 2.0 supports both iDirect SCPC downstream carriers and DVB-S2 downstream carriers. An example iDirect network is shown in Figure 1. iDX 2.0 does not support iSCPC or Mesh networks.

Figure 1. Sample iDirect Network


1

System Overview

The iDirect Hub equipment consists of an iDirect Hub Chassis with Hub Line Cards, a Protocol Processor (PP), a Network Management System (NMS) and the appropriate RF equipment. Each remote node consists of an iDirect broadband router and the appropriate external VSAT equipment. The remotes transmit to the hub on one or more shared upstream carriers using Deterministic-Time Division Multiple Access (D-TDMA), based on dynamic timeplan slot assignment generated at the Protocol Processor. The selection of an upstream carrier by a remote is determined either at network acquisition time or dynamically at run-time, based on a network configuration setting. iDirect software has features and controls that allow the system to be configured to provide QoS and other traffic engineered solutions to remote users. All network configuration, control, and monitoring functions are provided via the integrated NMS. The iDirect software provides: •

Packet-based and network-based QoS, TCP acceleration

•

TCP acceleration

•

AES link encryption

•

Local DNS cache on the remote

•

End-to-end VLAN tagging

•

Dynamic routing protocol support via RIPv2 over the satellite link

•

Multicast support via IGMPv2

•

VoIP support via voice optimized features such as cRTP

An iDirect network interfaces to the external world through IP over Ethernet ports on the remote unit and the Protocol Processor at the hub.

2


IP Network Architecture

IP Network Architecture The following figures illustrate the basic iDirect IP network architectures. •

Figure 2, “iDirect IP Architecture – Multiple VLANs per Remote”

•

Figure 3, “iDirect IP Architecture – VLAN Spanning Remotes”

•

Figure 4, “iDirect IP Architecture – Classic IP Configuration”

Figure 2. iDirect IP Architecture – Multiple VLANs per Remote


3


Figure 3. iDirect IP Architecture – VLAN Spanning Remotes

4



Figure 4. iDirect IP Architecture – Classic IP Configuration iDirect allows you to mix traditional IP routing based networks with VLAN based configurations. This capability provides support for customers that have conflicting IP address ranges in a direct fashion, and multiple independent customers at a single remote site by configuring multiple VLANs directly on the remote. In addition to end-to-end VLAN connection, the system supports RIPv2 in an end-to-end manner including over the satellite link; RIPv2 can be configured on per-network interface.


5


6


2 DVB-S2 in iDirect Networks Digital Video Broadcasting (DVB) represents a set of open standards for satellite digital broadcasting. DVB-S2 is an extension to the widely-used DVB-S standard and was introduced in March 2005. It provides for: •

Improved inner coding: Low-Density Parity Coding

•

Greater variety of modulations: QPSK, 8PSK, 16APSK

•

Dynamic variation of the encoding on broadcast channel: Adaptive Coding and Modulation

These improvements lead to greater efficiencies and flexibility in the use of available bandwidth.

DVB-S2 Key Concepts A BBFRAME (Baseband Frame) is the basic unit of the DVB-S2 protocol. Two frame sizes are supported: short and long. Each frame type is defined in the DVB-S2 standard in terms of the number of coded bits: short frames contain 16200 coded bits; long frames contain 64800 coded bits. MODCOD refers to the combinations of Modulation Types and Error Coding schemes supported by the DVB-S2 standard. The higher the modulation the greater the number of bits per symbol (or bits per Hz). The modulation types specified by the standard are: •

QPSK (2 bits/Hz)

•

8PSK (3 bits/Hz)

•

16PSK (4 bits/Hz)

Coding refers to the error-correction coding schemes available. Low-Density Parity Coding (LDPC) and Bose-Chaudhuri-Hocquenghem (BCH) codes are used in DVB-S2. Effective rates are 1/4 through 9/10. The 9/10 coding rates are not supported for short BBFRAMEs. The DVB-S2 standard does not support every combination of modulation and coding. DVB-S2 specifies the MODCODs shown in Table 1 on page 8. In general, the lower the MODCOD, the more robust the error correction, and the lower the efficiency in bits per Hz. The higher the MODCOD, the less robust the error correction, and the greater the efficiency in bits per Hz.


7

DVB-S2 Key Concepts

Table 1. DVB-S2 Modulation and Coding Schemes #

Modulation

Code

Notes

1

QPSK

1/4

ACM or CCM

2

1/3

3

2/5

4

1/2

5

3/5

6

2/3

7

3/4

8

4/5

9

5/6

10

8/9

11

9/10

CCM only

3/5

ACM or CCM

12

8PSK

13

2/3

14

3/4

15

5/6

16

8/9

17

9/10

CCM only

2/3

ACM or CCM

18

16APSK

19

3/4

20

4/5

21

5/6

22

8/9

23

9/10

CCM only

DVB-S2 defines three methods of applying modulation and coding to a data stream: •

CCM (Constant Coding and Modulation) specifies that every BBFRAME is transmitted at the same MODCOD. Effectively, the iDirect SCPC system is a CCM system.

Note:

•

8

In iDX Release 2.0, you can simulate a CCM outbound carrier using short frames by selecting ACM and setting the Maximum and Minimum MODCODs to the same value. CCM using long frames will be supported in future releases. See the iBuilder User Guide for details on configuring your carriers.

ACM (Adaptive Coding and Modulation) specifies that every BBFRAME can be transmitted on a different MODCOD. Remotes receiving an ACM carrier cannot anticipate the MODCOD of the next BBFRAME. A DVB-S2 demodulator must be designed to handle dynamic MODCOD variation.


DVB-S2 in iDirect

•

VCM (Variable Coding and Modulation) specifies that MODCODs are assigned according to service type. As in ACM mode, the resulting downstream contains BBFRAMEs transmitted at different MODCODs. (IDirect does not support VCM on the downstream.)

Figure 5 compares iDirect’s SCPC Mode, CCM Mode and ACM Mode. SCPC Mode: All Frames: single Modulation (QPSK or BPSK ) All Frames: single coding (TPC 0 .793 , etc .) QPSK TPC .793

QPSK TPC .793

...

time

DVBS2 : CCM Mode: : single MODCOD (one of QPSK¼ , … , 16 PSK9/10 ) All BB Frames 8 PSK 9/10

8 PSK 9/10

8 PSK 9/10

8 PSK 9/10

...

time

DVBS2 : ACM Mode: Each BB Frame: potentially different MODCOD (any of QPSK1/4 , … , 16 PSK 9/ 10 )

16P 5/6

16P 4/5

8 PSK 2/3

16P 4/5

QPSK 2/3

8 PSK 8/9

8 PSK 8/9

16P 8/9

8 PSK 3/4

time

Figure 5. Comparison of SCPC, Constant Coding, and Adaptive Coding Modes

DVB-S2 in iDirect iDirect DVB-S2 networks support ACM on the downstream carrier with all modulations up to 16APSK. An iDirect DVB-S2 network uses short DVB-S2 BBFARMES for ACM. iDirect does not support VCM on the downstream carrier. iDX Release 2.0 supports the following DVB-S2 hardware: •

Evolution eM1D1 line card (Tx/Rx; SCPC or DVB-S2)

•

Evolution XLC-11 line card (Tx/Rx; SCPC or DVB-S2)

•

Evolution XLC-10 line card (Tx-only; DVB-S2 networks only)

•

Evolution XLC-M line card (Rx-only; one inbound channel; SCPC or DVB-S2 networks)

•

Evolution e8350 remote satellite router (SCPC or DVB-S2 networks)

•

Evolution iConnex e800/e850mp remote satellite routers (SCPC or DVB-S2 networks)

•

Evolution X3 remote satellite router (DVB-S2 networks only)

•

Evolution X5 remote satellite router (SCPC or DVB-S2 networks)

The eM1D1 line card and the XLC-11 line card are Tx/Rx line cards. Both line cards can transmit either an iDirect SCPC or a DVB-S2 downstream carrier while receiving a TDMA upstream carrier. An XLC-10 line card is a Tx-only line card that can only be deployed in DVB-


9

DVB-S2 in iDirect

S2 networks only. An XLC-M line card is multi-channel, Rx-only line card that can be deployed in either DVB-S2 or iDirect SCPC networks. Note:

In iDX Release 2.0, an XLC-M line card only supports a single inbound channel.

Note:

The eM1D1, XLC-11, and XLC-M line cards all require the correct corresponding hub firmware package to operate in a DVB-S2 or iDirect SCPC network. These line cards require the evo_d_hub firmware for a DVB-S2 network and the evo_l_hub firmware for an SCPC network. See the iBuilder User Guide chapter titled “Converting Between SCPC and DVB-S2 Networks” for details.

An Evolution e8350, e800, e850 or X5 remote satellite router can receive either an SCPC or a DVB-S2 downstream carrier while transmitting on the TDMA upstream carrier. An Evolution X3 remote satellite router can only operate in DVB-S2 networks.

DVB-S2 Downstream An iDirect SCPC network is effectively CCM on the downstream. At configuration time, a modulation (such as BPSK) and coding rate (such as TPC 0.79) are selected. These characteristics of the downstream are fixed for the duration of the operation of the network. A DVB-S2 downstream can be configured as CCM (future) or ACM. If you configure the downstream as ACM, it is not constrained to operate at a fixed modulation and coding. Instead, the modulation and coding of the downstream varies within a configurable range of MODCODs. An iDirect DVB-S2 downstream contains a continuous stream of Physical Layer Frames (PLFRAMEs). The PLHEADER indicates the type of modulation and error correction coding used on the subsequent data. It also indicates the data format and frame length. Refer to Figure 6.

PLHEADER: signals MODCOD and frame length (always /2 BPSK)

Pilot symbols: unmodulated carrier

Data symbols: QPSK, 8PSK, 16APSK, or 32APSK

Figure 6. Physical Layer Frames The PLHEADER always uses /2 BPSK modulation. Like most DVB-S2 systems, iDirect injects pilot symbols within the data stream. The overhead of the DVB-S2 downstream varies between 2.65% and 3.85%. The symbol rate remains fixed on the DVB-S2 downstream. Variation in throughput is realized through DVB-S2 support, and the variation of MODCODs in ACM Mode. The maximum possible throughput of the DVB-S2 carrier (calculated at 45 MSps and highest MODCOD 16APSK 8/9) is approximately 155 Mbps. As with iDirect SCPC networks, multiple protocol processors may be required to support high traffic to multiple remotes. iDirect uses DVB-S2 “Generic Streams” for encapsulation of downstream data between the DVB-S2 line cards and remotes. Although the DVB-S2 standard includes the provision for generic streams, it is silent on how to encapsulate data in this mode. iDirect uses the proprietary LEGS (Lightweight Encapsulation for Generic Streams) protocol for this purpose.

10


DVB-S2 in iDirect

LEGS maximizes the efficiency of data packing into BBFRAMES on the downstream. For example, if a timeplan only takes up 80% of a BBFRAME, the LEGS protocol allows the line card to include a portion of another packet that is ready for transmission in the same frame. This results in maximum use of the downstream bandwidth.

ACM Operation ACM mode allows remotes operating in better signal conditions to receive data on higher MODCODs. This is accomplished by varying the MODCODs of data targeted to specific remotes to match their current receive capabilities. Not all data is sent to a remote at its best MODCOD. Important system information (such as timeplan messages), as well as broadcast traffic, is transmitted at the minimum MODCOD configured for the outbound carrier. This allows all remotes in the network, even those operating at the worst MODCOD, to reliably receive this information. The protocol processor determines the maximum MODCOD for all data sent to the DVB-S2 line card for transmission over the outbound carrier. However, the line card does not necessarily respect these MODCOD assignments. In the interest of downstream efficiency, some data scheduled for a high MODCOD may be transmitted at a lower one as an alternative to inserting padding bytes into a BBFRAME. When assembling a BBFRAME for transmission, the line card first packs all available data for the chosen MODCOD into the frame. If there is space left in the BBFRAME, and no data left for transmission at that MODCOD, the line card attempts to pack the remainder of the frame with data for higher MODCODs. This takes advantage of the fact that a remote can demodulate any MODCOD in the range between the carrier’s minimum MODCOD and the remote’s current maximum MODCOD. The maximum MODCOD of a remote is based on the latest Signal-to-Noise Ratio (SNR) reported by the remote to the protocol processor. The table in Figure 7 shows the SNR thresholds per MODCOD for the Evolution X3 and X5 remotes. The table in Figure 8 shows the SNR thresholds per MODCOD for the Evolution e8350 remote.These values are determined during hardware qualification. The graph shows how spectral efficiency increases as the MODCOD changes.


11

DVB-S2 in iDirect

Figure 7. SNR Threshold vs. MODCOD for Evolution X3 and X5 Remotes

12


DVB-S2 in iDirect

Figure 8. SNR Threshold vs. MODCOD for the Evolution e8350 Remote The hub adjusts the MODCODs of the transmissions to the remotes by means of the feedback loop shown in Figure 9 on page 14. Each remote continually measures its downstream SNR and reports the current value to the protocol processor. When the protocol processor assigns data to an individual remote, it uses the last reported SNR value to determine the highest MODCOD on which that remote can receive data without exceeding a specified BER. The protocol processor includes this information when sending outbound data to the line card. The line card then adjusts the MODCOD of the BBFRAMES to the targeted remotes accordingly. Note:

The line card may adjust the MODCOD of the BBFRAMEs downward for reasons of downstream packing efficiency.


13

DVB-S2 in iDirect

Figure 9 and Figure 10 show the operation of the SNR feedback loop and the behavior of the line card and remote during fast fade conditions. Figure 9 shows the basic SNR reporting loop described above. The example shows an XLC-10 line card transmitting to an X3 remote. However, the feedback loop discussion applies to any Evolution line card that is transmitting a DVB-S2 carrier to any Evolution remote.

Figure 9. Feedback Loop from Remote to Protocol Processor Figure 10 shows the backoff mechanism that exists between the line card and protocol processor to prevent data loss. The protocol processor decreases the maximum data sent to the line card for transmission based on a measure of the number of remaining untransmitted bytes on the line card. These bytes are scaled according to the MODCOD on which they are to be transmitted, since bytes destined to be transmitted at lower MODCODs will take longer to transmit than bytes destined to be transmitted on a higher MODCODs.

Figure 10. Feedback Loop with Backoff from Line Card to Protocol Processor

14


DVB-S2 in iDirect

Quality of Service in DVB-S2 ACM Networks iDirect QoS for DVB-S2 downstream carriers is basically identical to QoS for SCPC downstream carriers. (See “QoS Implementation Principles” on page 29.) However, with DVB-S2 in ACM Mode, the same amount of user data (in bits per second) occupies more or less downstream bandwidth, depending on the MODCOD at which it is transmitted. This is true because user data transmitted at a higher MODCOD requires less bandwidth than it does at a lower MODCOD. When configuring QoS in iBuilder, you can define a Maximum Information Rate (MIR) and/or a Committed Information Rate (CIR) at various levels of the QoS tree. (See the iBuilder User Guide for definitions of CIR and MIR.) For an ACM outbound, the amount of bandwidth granted for a configured CIR or MIR is affected by both the MODCOD that the remote is currently receiving and a number of parameters configurable in iBuilder. The remainder of this section discusses the various parameters and options that affect DVB-S2 bandwidth allocation and how they affect the system performance.

Remote Nominal MODCOD Beginning with iDX Release 2.0, you can configure a Nominal MODCOD for DVB-S2 remotes operating in ACM mode. The Nominal MODCOD is the Reference Operating Point (ROP) for the remote. By default, a remote’s Nominal MODCOD is equal to the DVB-S2 carrier’s Maximum MODCOD. The Nominal MODCOD is typically determined by the link budget but may be adjusted after the remote is operational. In a fixed network environment, the Nominal MODCOD is typically chosen to be the Clear Sky MODCOD of the remote. In a maritime network where the Clear Sky MODCOD depends on the position of the ship, the Nominal MODCOD may be any point in the beam coverage at which the service provider chooses to guarantee the CIR. The CIR and MIR granted to the remote are limited by the Remote’s Nominal MODCOD. The remote is allowed to operate at MODCODs higher than the Nominal MODCOD (as long as it does not exceed the configured Remote Maximum MODCOD described below), but is not granted additional higher CIR or MIR when operating above the Nominal MODCOD.

Remote Maximum MODCOD Beginning with iDX Release 2.0, you can also configure a Maximum MODCOD for DVB-S2 remotes operating in ACM mode. By default, a remote’s Maximum MODCOD is equal to the DVB-S2 carrier’s Maximum MODOCD. iBuilder allows you to limit the Maximum MODCOD for a remote to a value lower than the DVB-S2 carrier’s Maximum MODCOD and higher than or equal to the remote’s Nominal MODCOD. This is important if your link budget supports higher MODCODs but your remotes are using LNBs that do not have the phase stability required for the higher MODCODs. For example, a DRO LNB cannot support 16APSK due to phase instability at higher MODCODs. Note that a remote’s Maximum MODCOD is not the same as a remote’s Nominal MODCOD. The remote is allowed to operate above its Nominal MODCOD as long as it does not exceed the remote’s Maximum MODCOD. A remote is never allowed to operate above its Maximum MODCOD.


15

DVB-S2 in iDirect

Fixed Bandwidth Operation During a rain fade, the CIR or MIR granted to a remote are scaled down based on the remote’s Nominal MODCOD. This provides a graceful degradation of CIR and MIR during the fade while consuming the same satellite bandwidth as at the Nominal MODCOD. Figure 11 shows the system behavior when operating in Fixed Bandwidth Mode. The remote’s Nominal MODCOD is labeled “Nominal @ ClearSky” in the figure. In the example the remote has been configured with 256 kbps of CIR and a Nominal MODCOD of 8PSK 3/5. If the remote operates at a higher MODCOD, it is not granted a higher CIR. When the remote enters a rain fade, the allocated bandwidth remains fixed at the Nominal MODCOD bandwidth. The degradation in throughput is gradual because the remote continues to use the same amount of satellite bandwidth that was allocated for its Nominal MODCOD.

Fixed Bandwidth 400

600

300

CIR

400 300 200

250 Nominal @ ClearSky

200 150 100

100 0

Relative Bandwidth

350

500

50 0

Figure 11. Total Bandwidth vs. Information Rate in Fixed Bandwidth Operation

Enhanced Information Rate As noted above, the occupied bandwidth for CIR or MIR varies per MODCOD. If, when allocating downstream bandwidth for a remote, the system always attempted to meet these rates regardless of MODCOD, then a remote in a deep rain fade may be granted a disproportionate share of bandwidth at the expense of other remotes in the network. On the other hand, if CIR and MIR settings were only honored at the remote’s Nominal MODCOD (Fixed Bandwidth Mode), then there would be no option to increase the bandwidth to satisfy the requested information rate when a remote dropped below its Nominal MODCOD. The “Enhanced Information Rate” (EIR) option allows you to configure the system to maintain CIR or MIR during rain fade for the physical remote (Remote-Based Group QoS) or critical applications (Application-Based Group QoS). EIR only applies to networks that use DVB-S2 with Adaptive Coding and Modulation (ACM). EIR can be enabled for a physical remote or at several levels of the Group QoS tree. For details on configuring EIR, see the iBuilder User Guide.

16


DVB-S2 in iDirect

EIR is only enabled in the range of MODCODs from the remote’s Nominal MODCOD down to the configured EIR Minimum MODCOD. Within this range, the system always attempts to allocate requested bandwidth in accordance with the CIR and MIR settings, regardless of the current MODCOD at which the remote is operating. Since higher MODCODs contain more information bits per second, as the remote’s MODCOD increases, so does the capacity of the outbound channel to carry additional information. As signal conditions worsen, and the MODCOD assigned to the remote drops, the system attempts to maintain CIR and MIR only down to the configured EIR Minimum MODCOD. If the remote drops below this EIR Minimum MODCOD, it is allocated bandwidth based on the remote’s Nominal MODCOD with the rate scaled to the MODCOD actually assigned to the remote. The net result is that the remote receives the CIR or MIR as long as the current MODCOD of the remote does not fall below the EIR Minimum MODCOD. Below the EIR minimum MODCOD, the information rate achieved by the remote falls below the configured settings. The system behavior in EIR mode is shown in Figure 12. The remote’s Nominal MODCOD is labeled “Nominal” in the figure. The system maintains the CIR and MIR down to the EIR Minimum MODCOD. Notice in the figure that when the remote is operating below EIR Minimum MODCOD, it is granted the same amount of satellite bandwidth as at the remote’s Nominal MODCOD.

EIR Mode 600

400

300

CIR

400 300 200

250 Nominal

EIR Min

200 150 100

100 0

Relative Bandwidth

350

500

50 0

Figure 12. EIR: Total Bandwidth vs. Information Rate as MODCOD Varies


17

DVB-S2 in iDirect

Scaling Factors for Fixed Bandwidth Allocation Table 2 shows the scaling factors that can be used to calculate the information rate at different MODCODs when the allocated bandwidth is held constant at the remote’s Nominal MODCOD. This happens both in Fixed Bandwidth Mode or in EIR Mode when the remote’s MODCOD falls below the EIR Minimum MODCOD. Table 2. ACM MODCOD Scaling Factors MODCOD

Scaling Factor

Comments

16APSK 8/9

1.2382

Best MODCOD

16APSK 5/6

1.3415

16APSK 4/5

1.4206

16APSK 3/4

1.5096

16APSK 2/3

1.6661

8PSK 8/9

1.6456

8PSK 5/6

1.7830

8PSK 3/4

2.0063

8PSK 2/3

2.2143

8PSK 3/5

2.4705

QPSK 8/9

2.4605

QPSK 5/6

2.6659

QPSK 4/5

2.8230

QPSK 3/4

2.9998

QPSK 2/3

3.3109

QPSK 3/5

3.6939

QPSK 1/2

5.0596

QPSK 2/5

5.6572

QPSK 1/3

6.8752

QPSK 1/4

12.0749

Worst MODCOD

The following formula can be used to determine the information rate at which data is sent when that data is scaled to the remote’s Nominal MODCOD: IRa = IRn x Sb / Sa where: • IRa is the actual information rate at which the data is sent • IRn is the nominal information rate (for example, the configured CIR)

18

•

Sb is the scaling factor for the remote’s Nominal MODCOD

•

Sa is the scaling factor for the MODCOD at which the data is sent


DVB-S2 in iDirect

For example, assume that a remote is configured with a CIR of 1024 kbps and a Nominal MODCOD of 16ASPK 8/9. If EIR is not in effect, and data is being sent to the remote at MODCOD QPSK 8/9, then the resulting information rate is: IRa = IRn x Sb / Sa IRa = 1024 kbps x 1.2382 / 2.4605 = 515 kbps For two scenarios showing how CIR and MIR are allocated for a DVB-S2 network in ACM mode, see page 44 and page 46. Note:

When bandwidth is allocated for a remote, the CIR and MIR are scaled to the remote’s Nominal MODCOD. At higher levels of the Group QoS tree (Bandwidth Group, Service Group, etc.) CIR and MIR are scaled to the network’s best MODCOD.)

Bandwidth Allocation Fairness Beginning with iDX Release 2.0, there are two configurable options for bandwidth allocation fairness: •

Allocation Fairness Relative To CIR

•

Allocation Fairness Relative to MODCOD

Enabling or disabling either or both of these options for your Group QoS nodes or for your physical remotes affects how CIR and MIR bandwidth is apportioned during bandwidth contention. Allocation Fairness Relative to MODCOD only affects bandwidth allocation on DVBS2 ACM outbound carriers. Allocation Fairness Relative to CIR affects bandwidth allocation in general. For a detailed explanation of these options, see the Quality of Service chapter in the iBuilder User Guide. For sample scenarios illustrating the use of these options, see “Bandwidth Allocation Fairness Relative to CIR ” on page 47 and “Bandwidth Allocation Fairness Relative to MODCOD” on page 48.

DVB-S2 Configuration The iBuilder GUI allows you to configure various parameters that affect the operation of your DVB-S2 networks. For details on configuring DVB-S2, see the iBuilder User Guide. The following areas are affected: •

Downstream Carrier Definition: When you add an ACM DVB-S2 downstream carrier, you must specify a range of MODCODs over which the carrier will operate. Error correction for the carrier is fixed to LDPC and BCH. In addition, you cannot select an information rate or transmission rate for a DVB-S2 carrier as an alternative to the symbol rate, since these rates will vary dynamically with changing MODCODs. However, beginning with iDX Release 2.0, iBuilder provides a MODCOD Distribution Calculator that allows you to estimate the overall IP Data Rate for your carrier based on the distribution of the Nominal MODCODs of the remotes in your network. You can access this calculator by clicking the MODCOD Distribution button on the DVB-S2 Downstream Carrier dialog box. A similar button allows you to estimate CIR and MIR bandwidth requirements at various levels of the Group QoS tree.


19

DVB-S2 in iDirect

•

Multicast MODCOD: By default, all multicast data on an ACM downstream carrier is transmitted at the lowest MODCOD of the carrier. You can configure different MODCODs for your user multicast traffic by selecting Multicast MODCODs for your Multicast Applications in iBuilder. See the Quality of Service chapter of the iBuilder User Guide for details.

•

Remote Nominal MODCOD and Remote Maximum MODCOD. These remote parameters are discussed in detail at the beginning of this section. You can configure these parameters on the Remote QoS tab in iBuilder.

•

DVB-S2 Line Card Definition: When you add a DVB-S2 line card, you must configure a second IP port (called the GIG0 port) in addition to the management IP port. All data to be transmitted on the DVB-S2 downstream carrier is sent to this port.

•

DVB-S2 Network-Level Parameters: iBuilder allows you to configure the network-level parameters that control how a DVB-S2 network behaves when ACM is enabled for your downstream carrier. These parameters affect the behavior of the system during remote fade conditions.

DVB-S2 Performance Monitoring iMonitor allows you to monitor the following characteristics of your DVB-S2 outbound carriers: •

ACM Gain represents the increase in performance achieved on a DVB-S2 outbound carrier when the MODCOD used to transmit data is higher than the minimum MODCOD configured for the carrier. ACM Gain can be monitored at the Network, Inroute Group, Remote and Tx Line card levels of the iMonitor tree.

•

You can examine how the downstream data is distributed across the range of MODCODs configured for an ACM carrier. MODCOD distribution can be monitored at the Network, Remote and Tx Line Card levels of the iMonitor tree.

•

In an ACM network, each DVB-S2 remote periodically reports its current Signal-to-Noise Ratio (SNR) to the protocol processor. Based on the remote’s last-reported SNR, the protocol processor determines the maximum MODCOD at which the remote can receive data. Remote SNR can be monitored at the Network, Inroute Group, and Remote levels of the iMonitor tree.

•

A DVB-S2 line card keeps detailed statistics for traffic that is sent from the protocol processor to the line card and then transmitted by the line card on the DVB-S2 outbound carrier. DVB-S2 hub line card debug statistics can be monitored at the Tx Line Card level of the iMonitor tree.

•

Beginning with iDX Release 2.0, the NMS provides statistics on the operating point of each remote. In iMonitor, you can use these statistics to determine the percentage of time a remote is operating at its Nominal MODCOD and at other MODCODs. Although independent of traffic, this allows you to compare a remote’s actual operating point with its configured (or contractual) operating point and make adjustments to your network in the case of descrepancies.

For details, see the iMonitor User Guide.

20


3 Modulation Modes and FEC Rates This chapter describes the modulation modes and Forward Error Correction (FEC) rates that are supported in iDX Release 2.0.

iDirect Modulation Modes And FEC Rates A complete set of modulation modes, channel types, and FEC rates are shown in the following tables. Cells marked with an “X” represent combinations of modulation and FEC rates that are not supported. iDX Release 2.0 supports star networks with DVB-S2 or iDirect SCPC downstream carriers. In this release, an Evolution eM1D1, XLC-11 or XLC-10 line card can transmit a DVB-S2 downstream carrier. Only Evolution remote satellite routers (e8350, iConnex e800/e850mp, X3 or X5) can receive DVB-S2 downstream carriers. You can configure some Evolution hardware in iBuilder to use either a DVB-S2 or an SCPC downstream carrier. Evolution eM1D1 and XLC-11 line cards can transmit either carrier type. Evolution e8350, X5, e800, and e850mp remotes can receive either carrier type. As always, iNFINITI hardware only supports SCPC downstream carriers. iNFINITI hardware does not support DVB-S2. Note:

For specific Eb/No values for each FEC rate and Modulation combination, refer to the iDX 2.0 Link Budget Analysis Guide, which is available for download from the TAC web page located at http://tac.idirect.net.

Table 3 on page 22 shows the upstream and downstream Modulation Modes and FEC Rates for Evolution and iNFINITI hardware. iDirect also supports 2D 16-State Inbound Coding on upstream TDMA carriers in DVB-S2 networks only. For details see “2D 16-State Inbound Coding for DVB-S2 Networks” on page 23. In addition to the advantages offered by 2D 16-State Inbound Coding, Evolution line cards have much greater FPGA resources than iNFINITI line cards, allowing improved demodulator performance for existing TCP FEC rates even for SCPC networks containing iNFINITI remotes. For example •

QPSK Rate 0.533 TPC has a 1 dB improvement in C/N and Ebi/No threshold on Evolution line cards when compared to iNFINITI line cards.

•

8PSK Rate 0.66 TPC has a 0.8 dB improvement in C/N and Ebi/No threshold on Evolution line cards when compared to iNFINITI line cards.


21

iDirect Modulation Modes And FEC Rates

Note:

For specific Eb/No values for each FEC rate and Modulation combination, refer to the iDirect Link Budget Analysis Guide, which is available for download from the TAC web page located at http://tac.idirect.net. Table 3. Modulation Modes and FEC Rates

Note:

22

For the list of DVB-S2 downstream MODCODs supported in iDX 2.0, see Table 1 on page 8.


2D 16-State Inbound Coding for DVB-S2 Networks

2D 16-State Inbound Coding for DVB-S2 Networks Beginning with iDX Release 2.0, iDirect supports 2D 16-State Inbound Coding on upstream TDMA carriers in DVB-S2 networks. 2D 16-State Coding is extremely efficient inbound coding that provides maximum flexibility to network designers. 2D 16-State Coding supports three payload sizes: a 100 byte payload (88 byte IP payload), a 170 byte payload (158 byte IP payload), and a 438 byte payload (426 byte IP payload). The new small payload size has a sixteen byte larger payload than the QPSK .66 1K TPC block, ensuring the same low latency at call connection for VOIP applications. The large payload size is similar to the 4k TPC block to allow the same low TDMA overhead performance. The new medium payload size provides an intermediate option when considering the trade off between bandwidth granularity and reducing the TDMA overhead. 2D 16-State Coding has a number of benefits: •

More granular FEC and payload size choices than turbo codes or LDPC

•

Efficiency gains on average of 1 dB

•

Cost savings from the use of smaller antenna and BUC sizes

•

Easy implementation since no new network design is required

2D 16-State Coding supports easy mapping of existing TPC to 2D 16-State configurations. For example, the QPSK 2D16S-100B-3/4 offers similar performance and better spectral efficiency than the TPC QPSK 1k block with .66 FEC. For detailed options, see the iDX 2.0 Link Budget Analysis Guide. Table 4 shows the upstream Modulation and Coding rates available per payload size when using 2D 16-State Inbound Coding. Table 5 shows the IP payload and block sizes for each supported payload size. Note:

For specific Eb/No values for each FEC rate and Modulation combination, refer to the iDX 2.0 Link Budget Analysis Guide. Table 4. Modulation Modes and FEC Rates for 2D 16-State Inbound Coding


23

2D 16-State Inbound Coding for DVB-S2 Networks

Table 5. Block Sizes and IP Payload Sizes for 2D 16-State Inbound Coding

24


4 iDirect Spread Spectrum Networks This section provides information about Spread Spectrum technology in an iDirect network. It discusses the following topics: •

“What is Spread Spectrum?” on page 25

•

“Downstream Specifications” on page 27

•

“Upstream Specifications” on page 28

What is Spread Spectrum? Spread Spectrum (SS) is a transmission technique in which a pseudo-noise (PN) code is employed as a modulation waveform to “spread” the signal energy over a bandwidth much greater than the signal information bandwidth. The signal is “despread” at the receiver by using a synchronized replica of the pseudo-noise code. By spreading the signal information over greater bandwidth, less transmit power is required. A sample SS network diagram is shown in Figure 13.

Figure 13. Spread Spectrum Network Diagram Spreading takes place when the input data (dt) is multiplied with the PN code (pnt) which results in the transmit baseband signal (txb). The baseband signal is then modulated and transmitted to the receiving station. Despreading takes place at the receiving station when the baseband signal is demodulated (rxb) and correlated with the replica PN (pnr) which results in the data output (dr). Spread Spectrum transmission is supported in both TDMA and SCPC configurations. Spread spectrum is not available on DVB-S2 downstream carriers. SS mode is employed in iDirect networks to minimize adjacent satellite interference (ASI). ASI can occur in applications such


25

What is Spread Spectrum?

as Comms-On-The-Move (COTM) because the small antenna (typically sub-meter) used on mobile vehicles has small aperture size, large beam width, and high pointing error which can combine to cause ASI. Enabling SS reduces the spectral density of the transmission so that it is low enough to avoid interfering with adjacent satellites. Conversely, when receiving through a COTM antenna, SS improves carrier performance in cases of ASI (channel/interference). The iDirect SS is an extension of BPSK modulation in both upstream and downstream. The signal is spread over wider bandwidth according to a Spreading Factor (SF) that you select. You can select a downstream Spreading Factor of 1, 2, 4 or 8. You can select an upstream Spreading Factor of 1, 2, 4, 8 or 16. Note:

A Downstream Spreading Factor of 8 is only available for Evolution hub line cards transmitting to Evolution Remotes. Upstream Spreading Factors of 8 and 16 are only available for Evolution Remotes transmitting to Evolution hub line cards.

Note:

The following uses of Spread Spectrum require a license from iDirect: Upstream Spread Spectrum for the Evolution X5 remote; Upstream Spread Spectrum for the XLC-11 line card; and Downstream Spread Spectrum for the XLC-11 line card.

Each symbol in the spreading code is called a “chip”, and the spread rate is the rate at which chips are transmitted. For example, selecting an SF of 1 means that the spread rate is one chip per symbol (which is equivalent to regular BPSK, and therefore, there is no spreading). Selecting an SF of 4 means that the spread rate is four chips per symbol. An additional Spreading Factor, COTM SF=1, is for upstream TDMA carriers only. Like an SF of 1, if you select COTM SF=1, there is no spreading. However, the size of the carrier unique word is increased, allowing mobile remotes to remain in the network when they might otherwise drop out. An advantage of this spreading factor is that you can receive error-free data at a slightly lower C/N compared to regular BPSK. However, carriers with COTM SF=1 transmit at a slightly lower information rate. COTM SF=1 is primarily intended for use by fast moving mobile remotes. The additional unique word overhead allows the remote to tolerate more than 10 times as much frequency offset as can be tolerated by regular BPSK. That makes COTM SF=1 the appropriate choice when the Doppler effect caused by vehicle speed and acceleration is significant even though the link budget does not require spreading. Examples include small maritime vessels, motor vehicles, trains, and aircraft. Slow moving, large maritime vessels generally do not require COTM SF=1. Spread Spectrum can also be used to hide a carrier in the noise of an empty transponder. However, SS should not be confused with Code Division Multiple Access (CDMA), which is the process of transmitting multiple SS channels simultaneously on the same bandwidth. Spread Spectrum may also be useful in situations where local or RF interference is unavoidable, such as hostile jamming. However, iDirect designed the Spread Spectrum feature primarily for COTM and ASI mitigation. iDirect SS may be a good solution for overcoming some instances of interference or jamming, but it is recommended that you discuss your particular application with iDirect sales engineering.

26


Spread Spectrum Hardware Components

Spread Spectrum Hardware Components The Hub Line Cards (HLC) that support Spread Spectrum are the iNFINITI M1D1-TSS line card, the Evolution eM1D1 line card, and the Evolution XLC-11 line card. (An XLC-11 line card must be licensed for upstream and/or downstream Spread Spectrum before this feature can be enabled on the line card.) The iNFINITI M1D1-TSS line card occupies two slots in the hub chassis. Therefore, you can have a maximum of 10 iNFINITI M1D1-TSS line cards in one 20 slot chassis. Also, you cannot install an M1D1-TSS line card in slot 20. Evolution eM1D1 and XLC-11 line cards only require a single slot. Note: You must install the M1D1-TSS HLC in a slot that has one empty slot to the right. For example, if you want to install the HLC in slot 4, slot 5 must be empty. Be sure that you also check chassis slot configuration in iBuilder to verify that you are not installing the HLC in a reserved slot. The remotes that support spread spectrum are the iNFINITI 8350, the Evolution e8350, and the iConnex e800 and e850mp. The Evolution X5 supports upstream Spread Spectrum if Spread Spectrum is licensed on the remote. Other remotes do not currently support spread spectrum.

Downstream Specifications The specifications for the spread spectrum downstream channel are outlined in Table 6. Table 6. Spread Spectrum: Downstream Specifications PARAMETERS

VALUES

ADDITIONAL INFORMATION

Modulation

BPSK

Other Modulations not supported in SS

Spreading Factor

1, 2, 4, 8

SF=1 results in no spreading SF=8 requires Evolution hardware

Symbol Rate

64 ksym/s - 15 Msym/s

Chip Rate

15 Mchip/s maximum

FEC Rate

0.879, 0.793, 0.495

BER Performance

Refer to the iDirect Link Budget Analysis Guide

Occupied BW

1.2 * Chip Rate

Spectral Mask

IESS-308/309, MIL-STD 188xxx

Carrier Suppression

> -30 dBc

Hardware Platforms

M1D1-TSS HLC; Evolution eM1D1, XLC-11


Plus hub downcoverter oscillator stability factor

27

Supported Forward Error Correction (FEC) Rates

Supported Forward Error Correction (FEC) Rates The upstream and downstream FEC rates that are supported for Spread Spectrum in this release are described in the tables in “Modulation Modes and FEC Rates” on page 21.

Upstream Specifications The specifications for the spread spectrum upstream channel are outlined in Table 7. The Spreading Factor COTM 1, used in fast moving mobile applications, is described on page 26. Table 7. Spread Spectrum: Upstream Specifications PARAMETERS

VALUES

Modulation

BPSK

Other Modulations not supported in SS

Spreading Factor

1, 2, 4, 8 or 16

SF=1 results in no spreading

SFs of 8 and16 require Evolution hardware

SF=8 and SF=16 require Evolution hardware

Symbol Rate

64 ksym/s - 7.5 Msym/s

Chip Rate

7.5 Mchip maximum

FEC Rate

.66, .431, .533, 1/2, 2/3

BER Performance

Refer to the iDirect Link Budget Analysis Guide

Maximum Frequency Offset

1.5% * Fsym

Unique Word Overhead

128 symbols

Occupied Bandwidth

1.2 * Chip Rate

Hardware Platforms

28

ADDITIONAL INFORMATION

Rates 1/2, 2/3 2D-16 coding available in DVB-S2 networks only

iNFINITI series 8350; Evolution e8350, X5


5 QoS Implementation Principles This chapter describes how you can configure Quality of Service definitions to achieve maximum efficiency by prioritizing traffic.

Quality of Service (QoS) Quality of Service is defined as the way IP traffic is classified and prioritized as it flows through the iDirect system.

QoS Measures When discussing QoS, at least four interrelated measures are considered. These are Throughput, Latency, Jitter, and Packet Loss. This section describes these parameters in general terms, without specific regard to an iDirect network. Throughput. Throughput is a measure of capacity and indicates the amount of user data that is received by the end user application. For example, a G729 voice call without additional compression (such as cRTP), or voice suppression, requires a constant 24 Kbps of application level RTP data to achieve acceptable voice quality for the duration of the call. Therefore this application requires 24 Kbps of throughput. When adequate throughput cannot be achieved on a continuous basis to support a particular application, Qos can be adversely affected. Latency. Latency is a measure of the amount of time between events. Unqualified latency is the amount of time between the transmission of a packet from its source and the receipt of that packet at the destination. If explicitly qualified, it may also mean the amount of time between a request for a network resource and the time when that resource is received. In general, latency accounts for the total delay between events and it includes transit time, queuing, and processing delays. Keeping latency to a minimum is very important for VoIP applications for human factor reasons. Jitter. Jitter is a measure of the variation of latency on a packet-by-packet basis. Referring to the G729 example again, if voice packets (containing two 10 ms voice samples) are transmitted every 20 ms from the source VoIP equipment, ideally those voice packets arrive at the destination every 20 ms; this is a jitter value of zero. When dealing with a packetswitched network, zero jitter is particularly difficult to guarantee. To compensate for this, all VoIP equipment contains a jitter buffer that collects voice packets and sends them at the appropriate interval (20 ms in this example).


29

QoS Measures

Packet Loss. Packet Loss is a measure of the number of packets that are transmitted by a source, but not received by the destination. The most common cause of packet loss on a network is network congestion. Congestion occurs whenever the volume of traffic exceeds the available bandwidth. In these cases, packets are filling queues internal to network devices at a rate faster than those packets can be transmitted from the device. When this condition exists, network devices drop packets to keep the network in a stable condition. Applications that are built on a TCP transport interpret the absence of these packets (and the absence of their related ACKs) as congestion and they invoke standard TCP slow-Start and congestion avoidance techniques. With real time applications, such as VoIP or streaming video, it is often impossible to gracefully recover these lost packets because there is not enough time to retransmit lost packets. Packet loss may affect the application in adverse ways. For example, parts of words in a voice call may be missing or there maybe an echo; video images may break up or become block-like (pixilation effects).

QoS Application, iSCPC and Filter Profiles QoS Profiles are defined by Application Profiles, iSCPC Profiles and Filter Profiles. An Application or iSCPC Profile is a group of service levels, collected together and given a userdefined name. A QoS Filter Profile encapsulates a single filter definition, and it consists of a set of rules rather than a set of service levels. Application, iSCPC and Filter Profiles are applied to downstream and upstream traffic independently, so that upstream traffic may have certain QoS definitions, whereas downstream traffic may have a different set of QoS definitions. (Figure 14 on page 31). iSCPC Profiles and Application Profiles are used differently in TDMA networks than they are in iSCPC connections. •

For TDMA networks, Application Profiles define the Group QoS Applications that you add to your Service Profiles. You then assign the Service Profile to your TDMA remotes using the Group QoS tab for your Bandwidth Pools.

•

iSCPC Profiles are assigned directly to iSCPC line cards on the QoS tab. The Line Card assignments of iSCPC Profiles are mirrored on the iSCPC remote.

Application Profiles are only used for Group QoS. iSCPC Profiles are used only by iSCPC line cards and remotes and are not associated with Group QoS. See “Group QoS” on page 35 for a general discussion of Group QoS. For details on configuring profiles, see the chapter titled “Configuring Quality of Service for iDirect Networks” in the iBuilder User Guide.

30


Classification Profiles for Applications

Figure 14. Remote and QoS Profile Relationship

Classification Profiles for Applications This section describes how the iDirect system distinguishes application IP packets from less important background traffic. Each packet that enters the iDirect system is classified into one of the configured Service Levels.

Service Levels A Service Level may represent a single application (such as VoIP traffic from a single IP address) or a broad class of applications (such as all TCP based applications). Each Service Level is defined by one or more packet-matching rules. The set of rules for a Service Level allows logical combinations of comparisons to be made between the following IP packet fields:


31


•

Source IP address

•

Destination IP address

•

Source port

•

Destination port

•

Protocol (such as DiffServ DSCP)

•

TOS priority

•

TOS precedence

•

VLAN ID

Packet Scheduling Packet Scheduling is a method used to transmit traffic according to priority and classification. In a network that has a remote that always has enough bandwidth for all of its applications, packets are transmitted in the order that they are received without significant delay. Application priority makes little difference since the remote never has to select which packet to transmit next. In a network where there are periods of time in which a remote does not have sufficient bandwidth to transmit all queued packets the remote scheduling algorithm must determine which packet from a set of queued packets across a number of service levels to transmit next. For each service level you define in iBuilder, you can select any one of three queue types to determine how packets using that service level are to be selected for transmission. These are Priority Queue, Class-Based Weighted Fair Queue (CBWFQ), and Best-Effort Queue. The procedures for defining profiles and service levels are detailed in the chapter titled “Configuring Quality of Service for iDirect Networks” of the iBuilder User Guide. Priority Queues are emptied before CBWFQ queues are serviced and CBWFQ queues are in turn emptied before Best Effort queues are serviced. Figure 15 on page 33 presents an overview of the iDirect packet scheduling algorithm.

32



Figure 15. iDirect Packet Scheduling Algorithm The packet scheduling algorithm (Figure 15) first services packets from Priority Queues in order of priority, P1 being the highest priority for non-multicast traffic. It selects CBWFQ packets only after all Priority Queues are empty. Similarly, packets are taken from Best Effort Queues only after all CBWFQ packets are serviced. You can define multiple service levels using any combination of the three queue types. For example, you can use a combination of Priority and Best Effort Queues only.


33


Priority Queues There are four levels of user Priority Queues: •

Multicast: (Highest priority. Only for downstream multicast traffic.)

•

Level 1: P1

•

Level 2: P2

•

Level 3: P3

•

Level 4: P4 (Lowest priority)

All queues of higher priority must be empty before any lower-priority queue are serviced. If two or more queues are set to the same priority level, then all queues of equal priority are emptied using a round-robin selection algorithm prior to selecting any packets from lower priority queues.

Class-Based Weighted Fair Queues Packets are selected from Class-Based Weighted Fair Queues for transmission based on the service level (or “class”) of the packet. Each service level is assigned a “cost”. Packet cost is defined as the cost of its service level multiplied by its length. Packets with the lowest cost are transmitted first, regardless of service level. The cost of a service level changes during operation. Each time a queue is passed over in favor of other service levels, the cost of the skipped queue is credited, which lowers the cost of the packets in that queue. Over time, all service levels get an opportunity to transmit occasionally even in the presence of higher priority traffic. Assuming there is a continuously congested link with an equal amount of traffic on each service level, the total bandwidth available is divided more evenly by deciding transmission priority based on each service level cost.

Best Effort Queues Packets in Best Effort queues do not have priority or cost. All packets in these queues are treated equally by applying a round-robin selection algorithm to the queues. Best Effort queues are only serviced if there are no packets waiting in Priority Queues and no packets waiting CBWFQ Queues.

34


Group QoS

Group QoS Group QoS (GQoS), introduced in iDS Release 8.0, enhances the power and flexibility of iDirect’s QoS feature for TDMA networks. It allows advanced network operators a high degree of flexibility in creating subnetworks and groups of remotes with various levels of service tailored to the characteristics of the user applications being supported. Group QoS is built on the Group QoS tree: a hierarchical construct within which containership and inheritance rules allow the iterative application of basic allocation methods across groups and subgroups. QoS properties configured at each level of the Group QoS tree determine how bandwidth is distributed when demand exceeds availability. Group QoS enables the construction of very sophisticated and complex allocation models. It allows network operators to create network subgroups with various levels of service on the same outbound carrier or inroute group. It allows bandwidth to be subdivided among customers or Service Providers, while also allowing oversubscription of one group’s configured capacity when bandwidth belonging to another group is available. Note:

Group QoS applies only to TDMA networks. It does not apply to iDirect iSCPC connections.

For details on using the Group QoS feature, see the chapter titled “Configuring Quality of Service for iDirect Networks” in the iBuilder User Guide.

Group QoS Structure The iDirect Group QoS model has the following structure as shown in Figure 16:

Figure 16. Group QoS Structure


35

Group QoS

Bandwidth Pool A Bandwidth Pool is the highest node in the Group QoS hierarchy. As such, all sub-nodes of a Bandwidth Pool represent subdivisions of the bandwidth within that Bandwidth Pool. In the iDirect network, a Bandwidth Pool consists of an outbound carrier or an inroute group.

Bandwidth Group A Bandwidth Pool can be divided into multiple Bandwidth Groups. Bandwidth Groups allow a network operator to subdivide the bandwidth of an outroute or inroute group. Different Bandwidth Groups can then be assigned to different Service Providers or Virtual Network Operators (VNO). Bandwidth Groups can be configured with any of the following: •

CIR and MIR: Typically, the sum of the CIR bandwidth of all Bandwidth Groups equals the total bandwidth. When MIR is larger than CIR, the Bandwidth Group is allowed to exceed its CIR when bandwidth is available.

•

Priority: A group with highest priority receives its bandwidth before lower-priority groups.

•

Cost: Cost allows bandwidth allocations to different groups to be unequally apportioned within the same priority. For equal requests, lower cost nodes are granted more bandwidth than higher cost nodes.

Bandwidth Groups are typically configured using CIR and MIR for a strict division of the total bandwidth among the groups. By default, any Bandwidth Pool is configured with a single Bandwidth Group.

Service Group A Service Provider or a Virtual Network Operator can further divide a Bandwidth Group into sub-groups called Service Groups. A Service Group can be used strictly to group remotes into sub-groups or, more typically, to differentiate groups by class of service. For example, a platinum, gold, silver and best effort service could be defined as Service Groups under the same Bandwidth Group. Like Bandwidth Groups, Service Groups can be configured with CIR, MIR, Priority and Cost. Service Groups are typically configured with either a CIR and MIR for a physical separation of the groups, or with a combination of Priority, Cost and CIR/MIR to create tiered service. By default, a single Service Group is created for each Bandwidth Group.

Application Group An Application defines a specific service available to the end user. Application Groups are associated with any Service Group. The following are examples: • VoIP

36

•

Video

•

Oracle

•

Citrix

•

VLAN

•

NMS Traffic


Group QoS

•

Default

Each Application List can have one or more matching rules such as: • Protocol: TCP, UDP, and ICMP •

Source and/or Destination IP or IP Subnet

•

Source and/or Destination Port Number

•

DSCP Value or DSCP Ranges

•

VLAN

Each Application List can be configured with any of the following: • CIR/MIR •

Priority

•

Cost

Service Profiles Service Profiles are derived from the Application Group by selecting Applications and matching rules and assigning per remote CIR and MIR when applicable. While the Application Group specifies the CIR/MIR by Application for the whole Service Group, the Service Profile specifies the per-remote CIR/MIR by Application. For example, the VoIP Application could be configured with a CIR of 1 Mbps for the Service Group in the Application Group and a CIR of 14 Kbps per-remote in the Service Profile. Typically, all remotes in a Service Group use the Default Profile for that Service Group. When a remote is created under an inroute group, the QoS Tab allows the operator to assign the remote to a Bandwidth Group and Service Group. The new remote automatically receives the default profile for the Service Group. The Group QoS interface can also be used to assign a remote to a Service Group or change the assignment of the remote from one Service Group to another. In order to accommodate special cases, however, additional profiles (other than the Default Profile) can be created. For example, profiles can be used by a specific remote to prioritize an Application that is not used by other remotes; to prioritize a specific VLAN on a remote; or to prioritize traffic to a specific IP address (such as a file server) connected to a specific remote in the Service Group. Or a Network Operator may want to configure some remotes for a single VoIP call and others for two VoIP calls. This can be accomplished by assigning different profiles to each group of remotes.


37

Group QoS

Group QoS Scenarios Physical Segregation Scenario Example: A satellite provider would like to split a network with a 10 Mbps outbound carrier for two Service Providers, allocating 6 Mbps for one and 4 Mbps for the other. The first group should be allowed to burst up to 8 Mbps when the bandwidth is not being used by the second group. Configuration: The satellite provider could configure two Bandwidth Groups as follows: •

The first group with: CIR/MIR of 6 Mbps/8 Mbps

•

The second group with: CIR/MIR of 4 Mbps/4 Mbps

The sum of all CIR bandwidth should not exceed the total bandwidth. A scenario depicting physical segregation is shown in Figure 17.

Figure 17. Physical Segregation Scenario Note:

38

Another solution would be to create a single Bandwidth Group with two Service Groups. This solution would limit the flexibility, however, if the satellite provider decides in the future to further split each group into sub-groups.


Group QoS

CIR Per Application Scenario Example: A Service Provider has a 1 Mbps outbound carrier and would like to make sure that half of it is dedicated to VoIP with up to two VoIP calls per remote. He also has a critical application with Citrix traffic that requires an average of 8 Kbps per remote requiring 128 Kbps. Configuration: The Service Group’s Application List could be configured as follows: •

VoIP – CIR 512 Kbps

•

Citrix – CIR 128 Kbps

•

NMS – Priority 1, MIR 16K (Set NMS MIR to 1% to 2% of total BW)

•

Default – Cost 1.0 (Default cost is 1.0)

The derived “Default Application Profile” could be configured as follows: •

VoIP – CIR 28 Kbps

•

Citrix – CIR 8 Kbps

•

NMS – Priority 1

•

Default – Cost 1.0

A scenario depicting CIR per application is shown in Figure 18.

Figure 18. CIR Per Application Scenario


39

Group QoS

VoIP could also be configured as priority 1 traffic. In that case, demand for VoIP must be fully satisfied before serving lower priority applications. Therefore, it is important to configure an MIR to avoid having VoIP consume all available bandwidth.

Tiered Service Scenario Example: A network operator with an 18 Mbps outbound carrier would like to provide different classes of service for customers. The Platinum service will have the highest priority and is designed for 50 remotes bursting up to an MIR of 256 Kbps. The Gold Service, sold to 200 customers, will have an MIR of 128 Kbps. The Silver Service will be a “best effort” service, and will allow bursting up to 128 Kbps when bandwidth is available. Configuration: There are several ways to configure tiered services. The operator should keep in mind that when priority is used for a Service Group, the Service Group is satisfied up to the MIR before lower priority Service Groups are served. Here is one example of how the tiered service could be configured: •

Platinum – Priority 1 – MIR 12 Mbps

•

Gold – Priority 2 – MIR 18 Mbps (Identical to no MIR, since the Bandwidth Pool is only 18 Mbps.)

•

Silver – Priority 3 – No MIR Defined (The same as an MIR of 18 Mbps)

A scenario depicting tiered service is shown in Figure 19.

Figure 19. Tiered Service Scenario

40


Group QoS

Note that cost could be used instead of priority if the intention were to have a fair allocation rather than to satisfy the Platinum service before any bandwidth is allocated to Gold; and then satisfy the Gold service before any bandwidth is allocated to Silver. For example: •

Platinum – Cost 0.1 - CIR 6 Mbps, MIR 12 Mbps

•

Gold – Cost 0.2 - CIR 6 Mbps, MIR 18 Mbps

•

Silver – Cost 0.3 - No CIR, No MIR Defined

Third Level of Segregation by VLAN Scenario The iDirect Group QoS model is designed for two levels of physical segregation of bandwidth. If the user has a need to split the bandwidth into a third level, this could be accomplished by using VLANs. Example: A satellite provider would like to divide an 18 Mbps carrier among six distributors, each with 3 Mbps of bandwidth. One of the distributors would like to offer service to three network operators, giving them 1 Mbps each. Another would like to provide a tiered service (Platinum, Gold and Silver), dedicating 256 Kbps for the Platinum VoIP service. This effectively provides a third level of physical segregation. It could be accomplished by using VLANs as shown in the example below. Configuration: The Service Group’s Application Group for the tiered service could be configured as follows: •

Platinum – VLAN-91 & VoIP - Priority 1 – CIR 256 Kbps, MIR 256 Kbps

•

Platinum – VLAN-91 & All Others - Priority 1 – CIR 256 Kbps, MIR 512 Kbps

•

Gold – VLAN 92 - Priority 2 – CIR 256 Kbps, MIR 1 Mbps

•

Silver – VLAN 93 - Priority 2 – CIR 0, MIR 1 Mbps

A scenario depicting a third level VLAN is shown in Figure 20.


41

Group QoS

Figure 20. Third Level VLAN Scenario

The Shared Remote Scenario Example: A network operator provides service to oil rigs for two companies. Many of the oil rigs have both companies present. Company A bought 8 Mbps of outbound bandwidth, while Company B bought 2 Mbps of outbound bandwidth. The network operator would like to use a single outbound carrier of 10 Mbps to provide service for both companies, while ensuring that each customer receives the bandwidth that they paid for. This scenario is complicated by the fact that, on oil rigs with both companies present, the network operator would like to use a single remote to provide service to both by separating their terminals into VLAN-51 for Company A and VLAN-52 for Company B. Both companies would also like to prioritize their VoIP. Configuration: If we had separate remotes for each company, this would be a simple “Physical Segregation” scenario. However, keeping both companies in the same Service Group and allocating bandwidth by VLAN and application would not provide the strict separation of 8 Mbps for Company A and 2 Mbps for Company B. Instead, the solution is to create two Service Groups:

42


Group QoS

•

Company A: CIR/MIR 8 Mbps/8 Mbps

•

Company B: CIR/MIR 2 Mbps /2 Mbps

Service Profiles for both companies would have VoIP and Default with the appropriate priority, cost, CIR and MIR. In order to allow the same remote to serve both companies, the remote is assigned to both Service Groups as shown in Figure 21. Note that this is an unusual configuration and is not recommended for the typical application.

Figure 21. Shared Remote Scenario


43

Group QoS

DVB-S2 ACM Scenario 1: Scaled Aggregate CIRs Below Partition’s CIR This scenario applies only to DVB-S2 ACM outbound carriers with EIR configured. Refer to “Quality of Service in DVB-S2 ACM Networks” on page 15 for a detailed description of ACM operation with EIR enabled. The scenario shows three remotes in a Service Group in RemoteBased GQoS Mode with the following QoS configuration for the Network: •

Remote Based QoS Mode

•

Committed Information Rate (CIR) set to 1 Mbps per remote

•

Maximum Information Rate (MIR) set to 2 Mbps per remote

•

CIR set to 6.5 Mbps for the Service Group

•

MIR set to 7.2 Mbps for the Service Group

•

Nominal MODCOD for each remote set to 16APSK 8/9

•

Networks best MODCOD set to 16APSK 8/9

Assume for this example that the 6.5 Mbps CIR and 7.2 Mbps MIR are available for the Service Group. Demand from each remote is at 1.5 Mbps and each remote is configured in EIR Mode down to a Minimum EIR MODCOD of QPSK 1/4. The only difference in the three remote configurations is their SNR and the corresponding MODCODs. Remote 1 is operating in 8PSK 8/9; Remote 2 is operating in QPSK 8/9; and Remote 3 is operating in QPSK 3/5. In order to calculate the allocated bandwidth for each remote, the Scaling Factor corresponding to the operating MODCOD of each remote as well as the remote’s Nominal MODCOD Scaling Factor are needed and are shown in Figure 22 on page 45. Note:

When bandwidth is allocated for a remote, the CIR and MIR are scaled to the remote’s Nominal MODCOD. At higher levels of the Group QoS tree (Bandwidth Group, Service Group, etc.) CIR and MIR are scaled to the network’s best MODCOD.)

Referring to Figure 22:

44

•

The Scaled CIR for Remote 1 = 1 Mbps * 1.6456 / 1.2382 = 1.33 Mbps

•

The Scaled CIR for Remote 2 = 1 Mbps * 2.4605 / 1.2382 = 1.99 Mbps

•

The Scaled CIR for Remote 3 = = 1 Mbps * 3.6939 / 1.2382 = 2.98 Mbps

•

The Scaled Aggregate CIR for the three remotes is 6.3 Mbps. Since the Scaled Aggregate CIR is less than the Service Group CIR (6.5 Mbps), all three remotes get their full CIR of 1 Mbps.

•

The remaining 900 Kbps (Service Group MIR of 7.2 Mbps minus 6.3 Mbps required for CIRs) are divided equally between the three remotes which gives each remote 300 Kbps based on the Nominal MODCODs.

•

Remote 1 receives 300 Kbps * 1.2382 / 1.6456 = 226 Kbps of Best Effort for a Total of 1.226 Mbps

•


•



Group QoS

Remote-Based GQoS Mode Network’s Best MODCOD 16APSK 8/9 (Scale Factor 1.2382) Nominal MODCOD (all Remotes) 16APSK 8/9 (Scale Factor 1.2382)

Remote 1

Service Grp

CIR = 6.5M MIR = 7.2M

App Grp

Remote 2

Remote 3

CIR = 1M MIR = 2M EIR Min QPSK 1/4



Operating @ 8PSK 8/9 (Scale Factor 1.6456)

Operating @ QPSK 8/9 (Scale Factor 2.4605)


Demand = 1.5M

Demand = 1.5M

Demand = 1.5M

CIR Allocation = 1M Best Effort Allocation = 226K Total Allocation = 1.226M



Figure 22. Scaled Aggregate CIRs Below Partition’s CIR


45

Group QoS

DVB-S2 ACM Scenario 2: Scaled Aggregate CIRs Exceeds Partition’s CIR This scenario uses the same configuration as the scenario on page 44 with a change in CIR and MIR for the Service Group. In this case, the Service Group is oversubscribed as follows: •

The CIR of the Service Group is set to 3 Mbps.

•

The MIR of the Service Group is set to 3 Mbps.

Assume for this example that the 3 Mbps CIR and 3 Mbps MIR are available for the Service Group. In the scenario (Figure 23 ), the Scaled Aggregate CIR for the three remotes (6.3 Mbps) exceeds the Service Group CIR of 3 Mbps. Bandwidth is therefore distributed scaled to the Nominal MODCODs of the remotes. •

Remote 1 receives 1 Mbps * 1.2382 / 1.6456 = 752 Kbps

•


•


Remote-Based GQoS Mode

Service Grp

CIR = 3M MIR = 3M

Nominal MODCOD (all Remotes) 16APSK 8/9 (Scale Factor 1.2382)

App Grp

Remote 1

Remote 2

Remote 3




Operating @ 8PSK 8/9 (Scale Factor 1.6456)



Demand = 1.5M

Demand = 1.5M

Demand = 1.5M

CIR Allocation = 752K Best Effort Allocation = 0K Total Allocation = 752K



Figure 23. Scaled Aggregate CIRs Exceed Partition’s CIR

46


Group QoS

Bandwidth Allocation Fairness Relative to CIR iBuilder allows you to enable or disable Bandwidth Allocation Fairness Relative to CIR at various nodes in the Group QoS tree. If you select this option then, during contention for bandwidth, bandwidth allocation is proportional to the configured CIR. If this option is not selected, bandwidth is allocated equally to competing nodes until available bandwidth is exhausted. If there is enough available bandwidth to satisfy all CIR demand, this option extends to the best effort round of bandwidth allocation. Whether or not to enable Bandwidth Allocation Fairness Relative to CIR depends on the requirements of the Service Provider or network. For example, some corporate networks may want to disable this option in order to satisfy remote sites with small CIRs during bandwidth contention. On the other hand, some Service Providers that price their services based on CIR may want to enable this option in order to allocate bandwidth in proportion to the configured CIRs.

450K Available for the Service Group

Service Group

Allocation Fairness Relative to CIR Disabled

450K Available for the Service Group

Service Group

Allocation Fairness Relative to CIR Enabled

Remote 1

Remote 2

Remote 1

Remote 2

(CIR = 256K)

(CIR = 512K)

(CIR = 256K)

(CIR = 512K)

Allocation: 225K

Allocation: 225K

Allocation: 150K

Allocation: 300K

Figure 24. Bandwidth Allocation Fairness Relative to CIR Figure 24 shows two remotes, Remote 1 and Remote 2. Remote 1 is configured with a CIR or 256 Kbps while Remote 2 is configured with a CIR of 512 Kbps. Both remotes are requesting their full CIR, but only 450 Kbps of bandwidth is available. The tree on the left-hand side of Figure 24 shows the result of disabling Bandwidth Allocation Fairness Relative to CIR for the Service Group. The bandwidth is split equally between Remote 1 and Remote 2 until the bandwidth is exhausted. Both remotes receive 225 Kbps of bandwidth. (If Remote 1’s CIR could be fully satisfied, any remaining bandwidth would be granted to Remote 2. For example, if Remote 1 had only 200 Kbps of configured CIR, Remote 1 would be granted 200 Kbps of bandwidth and Remote 2 would be granted 250 Kbps of bandwidth.) The tree on the right-hand side of Figure 24 shows the result of enabling Bandwidth Allocation Fairness Relative to CIR for the Service Group. In that case, Remote 1 receives 150 Kbps of bandwidth, half that of Remote 2, since Remote 1 has half the configured CIR of Remote 2.


47

Group QoS

Bandwidth Allocation Fairness Relative to MODCOD Bandwidth Allocation Fairness Relative to MODCOD only applies to networks that use DVB-S2 with Adaptive Coding and Modulation (ACM). It allows you to configure your network to provide equal information rates to remotes configured with the same CIR regardless of their configured Nominal MODCODs. If you enable Bandwidth Allocation Fairness Relative to MODCOD, bandwidth allocation is based on information rate rather than on raw satellite bandwidth. Therefore, remotes with lower nominal MODCODs receive more satellite bandwidth than remotes with higher nominal MODCODs to achieve the same information rate. If you disable Bandwidth Allocation Fairness Relative to MODCOD, satellite bandwidth is allocated without regard to MODCOD. If there is enough available bandwidth to satisfy all CIRs, this option extends to the best effort round of bandwidth allocation. Whether or not to enable Bandwidth Allocation Fairness Relative to MODCOD depends on the requirements of the Service Provider or network. For example, some corporate networks may elect to disable this option to favor remotes operating at more efficient MODCODs. On the other hand, Service Providers that want to encourage end-users to invest in larger antennas through their service pricing model may elect to enable this option. In that case, the pricing model reflects the additional bandwidth required at lower MODCODs and Bandwidth Allocation Fairness Relative to MODCOD is more appropriate.

1.65M @ 8PSK ¾ Available for the Service Group

Service Group

Allocation Fairness Relative to MODCOD - Disabled

1.65M @ 8PSK ¾ Available for the Service Group

Service Group

Allocation Fairness Relative to MODCOD - Enabled

Remote 1

Remote 2

Remote 1

Remote 2

(CIR = 1M) Nominal 8PSK 3/4

(CIR = 1M) Nominal QPSK 3/4

(CIR = 1M) Nominal 8PSK 3/4

(CIR = 1M) Nominal QPSK 3/4

Allocation: 825K

Allocation: 550K

Allocation: 660K

Allocation: 660K

Figure 25. Bandwidth Allocation Fairness Relative to MODCOD Figure 25 shows two remotes, Remote 1 and Remote 2, each configured with a CIR of 1 Mbps. Remote 1 is operating at a Nominal MODCOD of 8PSK 3/4. Remote 2 is operating at a Nominal MODCOD of QPSK 3/4. Both remotes are requesting their full CIR, but only enough bandwidth to satisfy 1.65 Mbps of CIR at 8PSK 3/4 is available. Note that QPSK 3/4 requires about 1.5 times the raw satellite bandwidth of 8PSK 3/4 to deliver the same CIR. The tree on the left-hand side of Figure 25 shows the result of disabling Bandwidth Allocation Fairness Relative to MODCOD for the Service Group. The satellite bandwidth is split equally between Remote 1 and Remote 2 until the bandwidth is exhausted. This results in Remote 1 receiving 825 Kbps of CIR and Remote 2 receiving 550 Kbps of CIR. The tree on the right-hand side of Figure 25 shows the result of enabling Bandwidth Allocation Fairness Relative to MODCOD for the Service Group. Each remote receives enough bandwidth to carry 660 Kbps CIR. To accomplish this, Remote 2 must be granted 1.5 times the satellite bandwidth of Remote 1.

48


Application Throughput

Application Throughput Application throughput depends on properly classified and prioritized QoS and on properly available bandwidth management. For example, if a VoIP application requires 16 Kbps and a remote is only given 10 Kbps the application fails regardless of priority, since there is not enough available bandwidth. Bandwidth assignment is controlled by the Protocol Processor. As a result of the various network topologies (for example, a shared TDM downstream with a deterministic TDMA upstream), the Protocol Processor has different mechanisms for downstream control versus upstream control. Downstream control of bandwidth is provided by continuously evaluating network traffic flow to assigning bandwidth to remotes as needed. The Protocol Processor assigns bandwidth and controls the transmission of packets for each remote according to the QoS parameters defined for the remote’s downstream. Upstream bandwidth is requested continuously with each TDMA burst from each remote. A centralized bandwidth manager integrates the information contained in each request and produces a TDMA burst time plan which assigns individual bursts to specific remotes. The burst time plan is produced once per TDMA frame (typically 125 ms or 8 times per second). Note: There is a 250 ms delay from the time that the remote makes a request for bandwidth and when the Protocol Processor transmits the burst time plan to it. iDirect has developed a number of features to address the challenges of providing adequate bandwidth for a given application. These features are discussed in the sections that follow.

QoS Properties There are several QoS properties that you can configure based on your traffic throughput requirements. These are discussed in the sections that follow. For information of configuring these properties, see the chapter titled, “Configuring Quality of Service for iDirect Networks” of the iBuilder User Guide.

Static CIR You can configure a static Committed Information Rate (CIR) or an upstream minimum information rate for any upstream (TDMA) channel. Static CIR is bandwidth that is guaranteed even if the remote does not need the capacity. By default, a remote is configured with a single slot per TDMA frame. Increasing this value is considered as an inefficient configuration because these slots are wasted if the remote is inactive. No other remote can be given these slots unless the remote with the static CIR has not been acquired into the network. A static CIR is considered as the highest priority upstream bandwidth. Static CIR only applies in the upstream direction. The downstream does not need or support the concept of a static CIR.

Dynamic CIR You can configure Dynamic CIR values for remotes in both the downstream and upstream directions. Dynamic CIR is not statically committed and is granted only when demand is actually present. This allows you to support CIR based service level agreements and, based on statistical analysis, oversubscribe networks with respect to CIR. If a remote has a CIR but demand is less than the CIR, only the actual demanded bandwidth is granted. It is also possible to indicate that only certain QoS service levels “trigger” a CIR request. In these


49


cases, traffic must be present in a triggering service level before the CIR is granted. Triggering is specified on a per-service level basis. By default, additional burst bandwidth is assigned evenly among all remotes requesting bandwidth. All available burstable bandwidth (BW) is equally divided between all remotes requesting additional BW, regardless of already allocated CIR. Previously, a remote in a highly congested network would often not get burst bandwidth above its CIR. For example, consider a network with a 3 Mbps upstream and three remotes, R1, R2, and R3. R1 and R2 are assigned a CIR of 1 Mbps each and R3 has no CIR. In older releases, if all remotes requested 2 Mbps each, 1 Mbps was given to R3, making the total used BW 3 Mbps. In that case, R1 and R2 received no additional BW. Using the same example network, the additional 1 Mbps BW is evenly distributed by giving each remote an additional 333 Kbps. The default configuration is to allow even bandwidth distribution. Using Group QoS, you can alter the “fairness” algorithm used to apportion both the CIR bandwidth and the best-effort bandwidth. “Allocation Fairness Relative to CIR” and “Allocation Fairness Relative to MODCOD” can be selected at various levels of the group QoS tree. Further information and QoS configuration procedures can be found in the chapter titled, “Configuring Quality of Service for iDirect Networks” of the iBuilder User Guide.

Free Slot Allocation Free slot allocation is a round-robin distribution of unused TDMA slots by the centralized bandwidth manager on a frame-by-frame basis. The bandwidth manager assigns TDMA slots to particular remotes for each TDMA allocation interval based on current demand and configuration constraints (such as minimum and maximum data rates, static CIR, dynamic CIR, and others). At the end of this process it is possible that there are unused TDMA slots. In this case, if Free Slot Allocation is enabled, the bandwidth manager gives these extra slots to remotes in a fair manner, respecting any remote’s maximum configured data rate. Beginning with iDS Release 8.2, Free Slot Allocation is always enabled. It is no longer configurable in iBuilder. You can disable Free Slot Allocation with a custom key.

Compressed Real-Time Protocol (cRTP) You can enable Compressed Real-Time Protocol (cRTP) to significantly reduce the bandwidth requirements of VoIP flows. cRTP is implemented via standard header compression techniques. It allows for better use of real-time bandwidth especially for RTP-based applications, which utilize large numbers of small packets since the 40-byte IP/UDP/RTP header often accounts for a significant fraction of the total packet length. iDirect has implemented a standard header compression scheme including heuristic-based RTP detection with negative cache support for misidentified UDP streams. For example, G729 voice RTP results in less than 12 Kbps (uncompressed is 24 Kbps). To enable cRTP, see the section titled “QoS Tab” in the chapter titled “Configuring Remotes” of the iBuilder User Guide.

Configurable Minimum CIR It is possible to configure a remote upstream minimum statically committed CIR to less than one burst in each TDMA frame. This feature allows many remotes to be “packed” into a single

50



upstream. Reducing a remote’s minimum statically committed CIR increases ramp latency. Ramp latency is the amount of time it takes a remote to acquire the necessary bandwidth. The lower the upstream static CIR, the fewer TDMA time plans contain a burst dedicated to that remote, and the greater the ramp latency. Some applications may be sensitive to this latency and may result in a poor user experience. iDirect recommends that this feature be used with care. The iBuilder GUI enforces a minimum of one slot per remote every two seconds. For more information, see the section titled “Upstream and Downstream Rate Shaping” in the chapter titled “Configuring Remotes” of the iBuilder User Guide.

Sticky CIR Sticky CIR is activated only when CIR is over-subscribed on the downstream or on the upstream. When enabled, Sticky CIR favors remotes that have already received their CIR over remotes that are currently asking for it. When disabled (the default setting), The Protocol Processor reduces assigned bandwidth to all remotes to accommodate a new remote in the network. Sticky CIR can be configured in the Bandwidth Group and Service Group level interfaces in iBuilder.

Application Jitter Jitter is the variation of latency on a packet-by-packet basis of application traffic. For an application like VoIP, the transmitting equipment spaces each packet at a known fixed interval (every 20 ms, for example). However, in a packet switched network, there is no guarantee that the packets will arrive at their destination with the same interval rate. To compensate for this, the receiving equipment employs a jitter buffer that attempts to play out the arriving packets at the desired perfect interval rate. To do this it must introduce latency by buffering packets for a certain amount of time and then playing them out at the fixed interval. While jitter plays a role in both downstream and upstream directions, a TDMA network tends to introduce more jitter in the upstream direction. This is due to the discrete nature of the TDMA time plan where a remote may only burst in an assigned slot. The inter-slot times assigned to a particular remote do not match the desired play out rate, which results in jitter. Another source of jitter is other traffic that a node transmits between (or in front of) successive packets in the real-time stream. In situations where a large packet needs to be transmitted in front of a real-time packet, jitter is introduced because the node must wait longer than normal before transmission. The iDirect system offers features that limit the effect of such problems; these features are described the sections that follow.

TDMA Slot Feathering The Protocol Processor bandwidth manager attempts to “feather” or spread out each individual remote TDMA slots across the upstream frame. This is a desirable attribute in that a particular remote’s bursts are spread out in time often reducing TDMA induced jitter. This feature is enabled by selecting “Reduce Jitter” for an Application’s Service Level in iBuilder. For details, see the chapter titled “Configuring Quality of Service for iDirect Networks” in the iBuilder User Guide.


51

Packet Segmentation

Packet Segmentation Beginning with iDS Release 8.2, Segmentation and Reassembly (SAR) and Packet Assembly and Disassembly (PAD) have been replaced by a more efficient iDirect application. Although you can continue to configure the downstream segment size in iBuilder, all upstream packet segmentation is handled internally to optimize upstream packet segmentation. You may wish to change the downstream segment size if you have a small outbound carrier and need to reduce jitter in your downstream packets. Typically, this is not required. For details on configuring the downstream segment size, see the chapter on “Configuring Remotes” in the iBuilder User Guide.

Application Latency Application latency is typically a concern for transaction-based applications such as credit card verification systems. For applications like these, it is important that the priority traffic be expedited through the system and sent, regardless of the less important background traffic. This is especially important in bandwidth-limited conditions where a remote may only have a single or a few TDMA slots. In this case, it is important to minimize latency as much as possible after the distributor’s QoS decision. This allows a highly prioritized packet to make its way immediately to the front of the transmit queue.

Maximum Channel Efficiency vs. Minimum Latency Each TDMA burst carries a discrete number of payload bytes. The remote must break higherlevel packets into TDMA-burst-sized chunks to pack these bursts for transmission. You can control how bursts are packaged for transmission by selecting between two options on the iBuilder Service level dialog box: Maximum Channel Efficiency (default) and Minimum Latency. Maximum Channel Efficiency delays the release of a partially filled TDMA burst to allow for the possibility that the next packet will fill the burst completely. In this configuration, the system waits for up to four TDMA transmission attempts before releasing a partial burst. Minimum Latency never delays partially filled TDMA bursts. Instead, it transmits them immediately. In general, Maximum Channel Efficiency is the desired choice, except in certain situations when it is vitally important to achieve minimum latency for a prioritized service level. For example, if your network is typically congested and you are configuring the system to work with a transaction-based application which is bursty in nature and requires a minimum round trip time, then Minimum Latency may be the better choice. You can configure these settings in iBuilder from the QoS Service Level dialog box. For details, see the chapter titled “Configuring Quality of Service for iDirect Networks” in the iBuilder User Guide.

52


6 Configuring Transmit Initial Power During acquisition, the iNFINITI remote attempts to join the network according to the burst plan assigned to the remote by the hub. The initial transmit power must be set correctly so that the remote can join the network and stay in the network. This chapter describes the best practices for setting Transmit (TX) Initial Power in an iDirect network. Note:

It is important to set TX Initial Power on a remote modem correctly to ensure optimal Upstream channel performance.

What is TX Initial Power? TX Initial Power is the power level at which a remote modem transmits when joining the network. You can set the Initial Power through iSite or iBuilder. When a remote modem is attempting to join the network the hub sends SWEEP commands to it. These tell the remote modem to burst in to the acquisition slot of the upstream channel. Each SWEEP command contains a different frequency offset which tells the remote modem to change its frequency slightly and then send a burst. During these acquisition bursts, the remote modem sets its output power to the TX Initial Power parameter. If TX Initial Power is not set correctly, the acquisition bursts may not be received and the remote modem cannot join the network.

How To Determine The Correct TX Initial Power There are two ways to determine the correct TX Initial power: •

Locally, by using iSite during site commissioning.

•

Remotely, by using iBuilder any time after site commissioning.

During site commissioning, the installer uses iSite to set TX Initial Power. This parameter is set at a low value and it is manually increased until the remote modem is acquired into the network. The hub then automatically adjusts the remote modem output power to a nominal setting. With the acq on command enabled, UCP messages are displayed at the console and the installer can observe the TX power adjustments being made by the hub. When the hub determines that the bursts are arriving in the nominal C/N range, power adjustments are stopped (displayed at the console as 0.0 dB adjustment). The installer can type tx power to read the current power setting. iDirect recommends that you set the TX Initial Power value to 3 dB above the tx power reading. For example, if the tx power is -17 dBm, set TX Initial Power to -14 dBm.


53

All Remotes Need To Transmit Bursts in The Same C/N Range

At any time after site commissioning, you can check the TX Initial Power setting by observing the Remote Status and UCP tabs in iMonitor. If the remote modem is in a “steady state” and no power adjustments are being made, you can compare the current TX Power to the TX Initial Power parameter to verify that TX Initial Power is 3 dB higher than the TX Power. For detailed information on how to set TX Initial Power, refer to the “Remote Installation and Commissioning Guide”. Note:

Best nominal Tx Power measurements are made during clear sky conditions at the hub and remote sites.

All Remotes Need To Transmit Bursts in The Same C/N Range In a burst mode demodulator, the gain must be set at some nominal point prior to the arrival of a data burst so that the burst is correctly detected and demodulated. Since a single Hub Line Card receives bursts from many different remote modems, it constantly calculates the optimal gain point by taking into account the average levels of all bursts arriving at that Hub Line Card. If all the bursts are arrive at similar C/N levels, the average is very near optimal for all of them. However, if many bursts arrive at a varying C/N levels, the highest and lowest level bursts can skew the average such that so that it is no longer optimal. The nominal range is 2 dB wide (the green range in the iBuilder Acquisition/Uplink Control tab). The actual range at which bursts can be optimally detected is approximately 8 dB wide centered at the nominal gain point (Figure 26).

Ideal Case : Optimal Detection R ange 6

7

8

9

10

11

12

13

14

C /N (dB )

Threshold C /N U nder ideal circumstances , the average C /N of all remotes on the upstream channel is equal to the center of the U CP adjustment range . Therefore the optimal detection range extends to below the threshold C /N. (This example illustrates the TPC R ate 0 .66 threshold )

Figure 26. C/N Nominal Range

54


What Happens When TX Initial Power Is Set Incorrectly?

What Happens When TX Initial Power Is Set Incorrectly? If the Initial Power is not set correctly, your network performance can me negatively impacted. When remote is acquired by the hub, the center point of the 8 dB wide detection range is set at the C/N value at the time that is acquired. This section described what happens if the Initial Power is too high or too low.

When TX Initial Power is Too High If the if TX Initial Power is set too high, and the C/N at the time of acquisition is 11.0 dB, The C/N detection window range is from 7 dB to 15 dB and the Hub Line Card gain approaches the upper limit of the nominal range. Since UCP updates occur every 20 seconds, it may take a minute or more for carriers with too much initial power to adjust lower into the nominal range. During this time, remotes that are operating under atmospheric fade conditions could drop out of the network because the bursts no longer fall within the optimal detection range. Remotes that are trying to acquire with a C/N value of less than 7 dB will not acquire the network (Figure 27).

T X Initial P ow er T oo H igh: S ke w ed D e tection R ange 6

7

8

9

10

11

12

13

14

C /N (dB )

T h re sh old C /N W h en the T X Initia l P ow e r is set too high , rem otes entering the netw o rk skew the average C /N to be above th e center o f the U C P A djustm ent R a nge . T herefore , durin g this period th e op tim al detection ra nge does no t inclu de the thresho ld C /N an d rem otes experiencing rain fad e m ay experie nce a perform an ce degrad ation .

Figure 27. TX Initial Power Too High

When TX Initial Power is Too Low If the if TX Initial Power is set too low, and the C/N at the time of acquisition is 9.0 dB, the C/N detection window range is from 5 dB to 13 dB and the Hub Line Card gain approaches the lower limit of the nominal range. Since UCP updates occur every 20 seconds, it may take a minute or more for carriers with initial power set too low to adjust higher into the nominal range. During this time, remotes that are operating under clear sky conditions could drop out of the network because the bursts no longer fall within the optimal detection range. Remotes that are trying to acquire with a C/N value of greater than 13 dB will not acquire the network.


55

What Happens When TX Initial Power Is Set Incorrectly?

Bursts can still be detected below threshold but the probability of detection and demodulation reduces. This can lead to long acquisition times (Figure 28).

T X In itial P ow er T o o Lo w : S kew ed D etection R ange 6

7

8

9

10

11

12

13

14

C /N (dB )

T hreshold C /N W hen the T x Initial P ow er is set too low , rem otes entering the netw ork skew the averag e C /N to be b elo w the center of the U C P A djustm ent R ange . T h is co u ld cau se rem o tes co m in g in at th e h ig h er en d (e.g . 14 d B ) to exp erie n ce so m e d isto rtio n in th e d em o d u latio n p ro cess . A dditionally, a rem ote acquiring at a low C /N (below threshold ) experiences a large num ber of C R C errors w hen it enters the netw ork until its pow er is increased .

Figure 28. TX Initial Power Too Low

56


7 Global NMS Architecture

This chapter describes how the Global NMS works in a global architecture and a sample Global NMS architecture.

How the Global NMS Works The Global NMS allows you to add a single physical remote, as identified by its Derived ID (DID), to multiple networks at the same time. A remote that is a member of multiple networks is called a “roaming remote.” For details on defining and managing roaming remotes, refer to the iBuilder User Guide. Figure 29 illustrates the current and Global NMS database relationships.

Figure 29. Global NMS Database Relationships


57

Sample Global NMS Network

Sample Global NMS Network This section illustrates a sample global NMS architecture, and it explains how the NMS works in this type of network (Figure 30).

Figure 30. Sample Global NMS Network Diagram In this example, there are 4 different networks connected to three different Regional Network Control Centers (RNCCs). A group of remote terminals has been configured to roam among the four networks. Note:

This diagram shows only one example from the set of possible network configurations. In practice, there may be any number RNCCs and any number of protocol processors at each RNCC.

On the left side of the diagram, a single NMS installed at the Global Network Control Center (GNCC) manages all the RNCC components and the group of roaming remotes. Network operators, both remote and local, can share the NMS server simultaneously with any number of VNOs. (Only one VNO is shown in the Figure 30.) All users can run iBuilder, iMonitor, or both on their PCs. The connection between the GNCC and each RNCC must be a dedicated high-speed link. Connections between NOC stations and the NMS server are typically standard Ethernet. Remote NMS connections are made either over the public Internet protected by a VPN, port forwarding, or a dedicated leased line.

58


8 Hub Network Security Recommendations This chapter describes basic recommended security measures to ensure that the NMS and Protocol Processor servers are secure when connected to the public Internet. iDirect recommends that you implement additional security measures over and above these minimal steps.

Limited Remote Access Access to the NMS and Protocol Processor servers should be protected behind a commercialgrade firewall. If remote access is necessary for support, the iDirect Technical Assistance Center can help you set up appropriate VPN access. Contact the TAC for details (see “Getting Help” on page xiii).

Root Passwords Root password access to the NMS and Protocol Processor servers should be reserved for only those you want to have administrator-level access to your network. Restrict the distribution of this password information. Servers are shipped with default passwords. Change the default passwords after the installation is complete and make sure these passwords are changed on a regular basis and when an employee leaves your company. When selecting your new passwords, iDirect recommends that you follow these practices for constructing difficult-to-guess passwords: •

Use passwords that are at least 8 characters in length.

•

Do not base passwords on dictionary words.

•

Use passwords that contain a mixture of letters, numbers, and symbols.


59

Root Passwords

60


9 Global Protocol Processor Architecture This chapter describes how the Protocol Processor works in a global architecture. Specifically it contains “Remote Distribution,” which describes how the Protocol Processor balances remote traffic loading and “De-coupling of NMS and Data Path Components,” which describes how the Protocol Processor Blades continue to function in the event of a Protocol Processor Controller failure.

Remote Distribution The actual distribution of remotes and processes across a blade set is determined by the Protocol Processor controller dynamically in the following situations: •

At system Startup, the Protocol Processor Controller determines the distribution of processes based on the number of remotes in the network(s).

•

When a new remote is added in iBuilder, the Protocol Processor Controller analyzes the current system load and adds the new remote to the blade with the least load.

•

When a blade fails, the Protocol Processor Controller re-distributes the load across the remaining blades, ensuring that each remaining blade takes a portion of the load.

The Protocol Processor controller does not perform dynamic load-balancing on remotes. Once a remote is assigned to a particular blade, it remains there unless it is moved due to one of the situations described above.

De-coupling of NMS and Data Path Components If the Protocol Processor Controller fails, the Protocol Processor Blades continue to function normally since the NMS and Protocol Processor Controller are independent. However, during a period of Controller failure, automatic failover does not occur and you cannot reconfigure it. You can build process redundancy into your design by running duplicate processes over


61

De-coupling of NMS and Data Path Components

multiple Protocol Processor Blades. A high-level architecture of the Protocol Processor, with one possible configuration of processes across two blades is shown in Figure 31. PP Blade 1 N M S Server

sam nc

sarm t spaw n and control

NM S Servers

sada

M onitor and C ontrol M onitor and C ontrol

sarouter

sana

pp_controller PP Blade 2 M onitor and C ontrol

sam nc spaw n and control

sarm t

sarouter

Figure 31. Protocol Processor Architecture

62


10 Distributed NMS Server

This chapter describes how you can design your network through a Distributed NMS server, manage it through iDS supporting software, and back up or restore the configuration. You can distribute your NMS server processes across multiple server machines. The primary benefits of machine distribution are improved server performance and better utilization of disk space. iDirect recommends a distributed NMS server configuration once the number of remotes being controlled by a single NMS exceeds 500-600. iDirect has tested the new distributed platform with over 3000 remotes with iDS 7.0.0. Future releases continue to push this number higher.

Distributed NMS Server Architecture The distributed NMS architecture allows you to match your NMS server processes to the server machines. For example, you can run all servers on a single platform (the current default) you can either assign each server process to its own server, or you can assign groups of processes to individual servers. Server configuration is performed one time using a special script distributed with the NMS servers installation package. Once configured, the distribution of server processes across the servers remains unchanged unless you reconfigure it. This is true even when you upgrade your system.


63

iBuilder and iMonitor

The most common distribution scheme for larger networks is shown in Figure 32.

Figure 32. Sample Distributed NMS Configuration This configuration has the following process distribution: •

NMS Server 1 runs the configuration server (nmssvr), latency server (latsvr), the chassis manager server (cmsvr) and the PP controller (cntrlsvr) process.

•

NMS Server 2 runs only the Statistics processes (nrdsvr).

•

NMS Server 3 runs only the Event processes (evtsvr).

The busiest NMS processes, nrdsvr and evtsvr, are placed on their own servers for maximum processing efficiency. All other NMS server processes are grouped on NMS Server 1.

iBuilder and iMonitor From the iBuilder or iMonitor user perspective, a distributed NMS server functions identically to a single NMS server. In both server configurations, users provide a user name, password, and the IP address or Host Name of the NMS configuration server at the time of login. The configuration server stores the location of all other NMS servers and provides this information to the iBuilder or iMonitor client. Using this information, the client automatically establishes connections to the server processes on the correct machines. To set up a D-NMS, refer to the iBuilder User Guide.

64


dbBackup/dbRestore and the Distributed NMS

dbBackup/dbRestore and the Distributed NMS The dbBackup and dbRestore scripts are completely compatible with the new distributed NMS. You can have 1:1 or 1:n redundancy for your NMS servers. 1:n redundancy means that one physical machine backs up all of your active servers. If you choose this form of redundancy, you must modify the dbBackup.ini file on each NMS server to ensure that the separate databases are copied to separate locations on the backup machine. The following diagram shows three servers, each copying its database to a single backup NMS. If NMS 1 fails, you do not need to run dbRestore prior to switch-over since the configuration data has already been sent to the backup NMS. If NMS 2 or NMS 3 fails, you need to run dbRestore prior to the switch-over if you want to preserve and add to the archive data in the failed server’s database. See Figure 33.

Figure 33. dbBackup and dbRestore with a Distributed NMS


65

dbBackup/dbRestore and the Distributed NMS

66


11 Transmission Security (TRANSEC) This section describes how TRANSEC and FIPS is implemented in an iDirect Network. It includes the following sections: •

“What is TRANSEC?" defines Transmission Security.

•

“iDirect TRANSEC" describes protocol implementation.

•

“TRANSEC Downstream" describes the data path from the hub to the remote.

•

“TRANSEC Upstream" describes the data path from the remote to the hub.

•

“TRANSEC Key Management" describes public and private key usage.

•

“TRANSEC Remote Admission Protocol" describes acquisition and authentication.

•

“Reconfiguring the Network for TRANSEC" describes conversion requirements.

What is TRANSEC? Transmission Security (TRANSEC) prevents an adversary from exploiting information available in a communications channel without necessarily having defeated the encryption inherent in the channel. Even if an encrypted wireless transmission is not compromised, information such as timing and traffic volumes can be determined by using basic signal processing techniques. This information could provide someone monitoring the network a variety of information on unit activity. For example, even if an adversary cannot defeat the encryption placed on individual packets, it might be able to determine answers to questions such as: •

What types of applications are active on the network currently?

•

Who is talking to whom?

•

Is the network or a particular remote site active now?

•

Is it possible to determine between network activity and real world activity, based on traffic analysis and correlation?

There are a number of components to TRANSEC, one of them being activity detection. With current VSAT systems an adversary can determine traffic volumes and communications activities with a simple spectrum analyzer. With a TRANSEC compliant VSAT system an adversary is presented with a strongly encrypted and constant wall of data. Other components of TRANSEC include remote and hub authentication. TRANSEC eliminates the ability of an adversary to bring a non-authorized remote into a secured network.


67

iDirect TRANSEC

iDirect TRANSEC iDirect achieves full TRANSEC compliance by presenting to an adversary who may be eavesdropping on the RF link a constant “wall” of fixed-size, strongly encrypted (such as Advanced Encryption Standard (AES) and 256 bit key Cipher Block Chaining (CBC) Mode) traffic segments, which do not vary in frequency in response to network utilization. Other than network messages that control the admission of a remote terminal into the network, all portions of all packets are encrypted, and their original size is hidden. The content and size of all user traffic (Layer 3 and above), as well as network link layer (Layer 2) traffic is completely indeterminate from an adversary’s perspective. Further, no higher layer information is revealed by monitoring the physical layer (Layer 1) signal. The solution includes a remote-to-hub and a hub-to-remote authentication protocol based on standard X.509 certificates designed to prevent man-in-the-middle attacks. This authentication mechanism prevents an adversary’s remote from joining an iDirect TRANSEC secured network. In a similar manner, it prevents an adversary from coercing a TRANSEC remote into joining the adversary’s network. While these types of attacks are extremely difficult to achieve even on a non-TRANSEC iDirect network, the mechanisms put in place for the TRANSEC feature render them completely impossible. Note:

In this release, HiFin encryption cards are no longer required on your protocol processor blades for TRANSEC key management.

All hub line cards and remote model types associated with a protocol processor must be TRANSEC compatible. The only iDirect hardware that operate in TRANSEC mode are the M1D1T, M1D1-TSS, and eM1D1 Hub Line Cards; the iNFINITI 7350, 8350 and Evolution e8350 remotes; and the iConnex 700 and iConnex e800/e850mp remotes. Therefore these are the only iDirect products that are capable of operating in a FIPS 140-2 Level 1 compliant mode. For more information, see the chapter “Converting an Existing Network to TRANSEC” of the iBuilder User Guide. Note:

68

TRANSEC is not supported on DVB-S2 outbound carriers. The eM1D1 line card only supports TRANSEC when transmitting an iDirect SCPC outbound carrier.


TRANSEC Downstream

TRANSEC Downstream A simplified block diagram for the iDirect TRANSEC downstream data path is shown in Figure 34. Each function represented in the diagram is implemented in software and firmware on a TRANSEC capable line card.

Figure 34. Downstream Data Path Consider the diagram from left to right with variable length packets arriving on the far left into the block named Packet Ingest. In this diagram, the encrypted path is shown as solid black, and the unencrypted (clear) path is shown in dashed red. The Packet Ingest function receives variable length packets which can belong to four logical classes: User Data, Bypass Burst Time plan (BTP), Encrypted BTP, and Bypass Queue. All packets arriving at the transmit Hub Line Card have this indication present as a pre-pended header placed there by the protocol processor (not shown). The Packet Ingest function determines the message type and places the packet in the appropriate queue. If the packet is not valid, it is not placed in any queue and it is dropped. Packets extracted from the Data Queue are always encrypted. Packets extracted from the Clear Queue are always sent unencrypted, and time-sensitive BTP messages from the BTP Queue can be sent in either mode. A BTP sent in the clear contains minimal traffic analysis information for an adversary and is only utilized to allow remotes attempting to exchange admission control messages with the hub to do so. Traffic sent in the clear bypasses the Segmentation Engine and the AES Encryption Engine, and precedes the physical framing and FEC engines for transmission. Clear, unencrypted packets are transmitted without regard to segmentation; they are allowed to exist on the RF link with variable sized framing. Encrypted traffic next enters the Segmentation Engine. The Segmentation Engine segments incoming packets based on a configured size and provides fill-packets when necessary. The Segmentation Engine allows the iDirect TRANSEC downstream to transmit a configurable, fixed size TDM packet segment on a continuous basis. After segmentation, fixed sized packets enter the Encryption Engine. The encryption algorithm utilizes the AES algorithm with a 256 bit key and operates in CBC Mode. Packets exit the Encryption Engine with a pre-pended header as shown in Figure 35.


69

TRANSEC Downstream

SCPC TRANSEC FRAME Encryption Header Code

Seq

Rsvd

Initialization Vector

Segment FH1

F1

FEC Coding FHn

Fn

Figure 35. SCPC TRANSEC Frame The Encryption Header consists of five 32 bit words with four fields. The fields are: •

Code. This field indicates if the frame is encrypted or not, and if encrypted indicates the entry within the key ring (described under the key management section later in this document) to be utilized for this frame. The Code field is one byte in length.

•

Seq. This field is a sequence number that increments with each segment. The Seq field is two bytes in length (16 bits, unsigned).

•

Rsvd. This field is 1 byte and is reserved for future use.

•

Initialization Vector (IV). IV is utilized by the encryption/decryption algorithm and contains random data. The IV field is 16 bytes in length (128 bits unsigned).

A new IV is generated for each segment. The first IV is generated from the cipher text of the initial Known Answer Test (KAT) conducted at system boot time. Subsequent IVs are taken from the last 128 bits of the cipher text of the previously encrypted segment. IVs are continuously updated regardless of key rotations and they are independent of the key rotation process. They are also continuously updated regardless of the presence of user traffic since the filler segments are encrypted. While no logic is included to ensure that IVs do not repeat, the chance of repetition is very small; estimates place the probability of an IV repeating at 1:2102 for a maximum iDirect downstream data rate. The Segment is of fixed, configurable length and consists of a series of fixed length Fragment Headers (FH) followed by variable length data Fragments (F). The entire Segment is encrypted in a single operation by the encryption engine. The FH contains sufficient information for the source packet stream, post decryption on the receiver, to be reconstructed. Each Fragment contains a portion of a source packet. The Encryption Header is transmitted unencrypted but contains only enough information for a receiver to decrypt the segment if it is in possession of the symmetric key. Once an encrypted packet exits the Encryption Engine it undergoes normal processing such as framing and forward error correction coding. These functions are essentially independent of TRANSEC but complete the downstream transmission chain and are thus depicted in figure 1.

70


TRANSEC Upstream

TRANSEC Upstream A simplified block diagram for the iDirect TRANSEC upstream data path is shown in Figure 36. The functions represented in this diagram are implemented in software and firmware on a TRANSEC capable remote.

Figure 36. Upstream Data Path The encrypted path is shown is solid black, and the unencrypted (clear) path is shown in dashed red. The Packet Ingest function determines the message type and places the packet in the appropriate queue or drops it if it is not valid. Consider the diagram from left to right with variable length packets arriving on the far left into the block named Packet Ingest. The upstream (remote to hub) path differs from the downstream (hub to remote) in that on the upstream is configured for TDMA. Variable length packets from a remote LAN are segmented in software, and can be considered as part of the Packet Ingest function. Therefore there is no need for the firmware level segmentation present in the downstream. Additionally, since the remote is not responsible for the generation of BTPs, there is no need for the additional queues present in the downstream. Packets extracted from the Data Queue are always encrypted. Packets exacted from the Clear Queue are always sent unencrypted. The overwhelming majority of traffic will be extracted from the Data Queue. Traffic sent in the clear bypasses the Encryption Engine and precedes the FEC engine for transmission. The encryption algorithm utilizes AES algorithm with a 256 bit key and will operate in CBC Mode. Packets exit the Encryption Engine with a pre-pended header as described in Figure 37.

Figure 37. TDMA TRANSEC Slot Note:

TRANSEC overhead reduces the payload size shown in Table 3 on page 22 by the following amounts for each FEC rate: .431: 7 bytes; .533: 4 bytes; . 660: 4 bytes; .793: 6 bytes.

The Encryption Header consists of a single 32 bit word with 3 fields. The fields are:


71

TRANSEC Key Management

IV Seed. This field is a 29 bit field utilized to generate an 128 bit IV. The IV Seed field starts at zero and increments for each transmitted burst. The full 128 bit IV is generated from the padded seed by passing it though the encryption engine. The IV is expanded into a 128-bit IV by encrypting it with the current AES key for the inroute. Remotes can therefore expand the same seed into the same full IV. However, this does not create any problems because due to addressing requirements, it is impossible for any two remotes within the same upstream to generate the same plain text data. While no logic is included to ensure that IVs do not repeat for a single terminal, repetition is impossible because the key rotates every two hours by default. Since the seed increments for each transmission burst, the number of total bursts prior to a seed wrapping around is 229 or 536,870,912. Given the two-hour key rotation period, a single terminal would need to send over 75,000 TDMA bursts per second to exhaust the range of the seed. This exceeds any possible iDirect upstream data rate by far. Key ID. This field indicates the entry within the key ring (described under the key management section later in this document) to be utilized for this frame. Enc. This field indicates if the frame is encrypted or not. The Segment is of fixed, configurable length and consists of what we might call the standard iDirect TDMA frame. A description of the details of the standard frame are beyond the scope of this document, but as a general description, consist of a Demand Header which indicates the amount of bandwidth a remote is requesting, the iDirect Link Layer (LL) Header, and ultimately the actual Payload. This Segment is encrypted. The Encryption Header is transmitted unencrypted but contains only enough information for a receiver to decrypt the segment if it is in possession of the symmetric key. Once an encrypted packet exits the Encryption Engine it undergoes normal processing such as forward error correction coding. This function is essentially independent of TRANSEC but completes the upstream transmission chain (as shown in figure 3). A remote will always burst in its assigned slots even when traffic is not present by generating encrypted fill payloads as needed. The iDirect Hub dynamic allocation algorithm will always operate in a mode whereby all available time slots within all time plans are filled.

TRANSEC Key Management All hosts in an iDirect Network must have X.509 public key certificates. Hosts include NMS servers, protocol processor blades, TRANSEC hub line cards, and TRANSEC remotes. Certificates are required to join an authenticated network. They serve to prevent man-in-themiddle attacks and unauthorized admission to the network. You must use the iDirect Certificate Authority (CA) utility (called the CA Foundry) to issue the certificates for your TRANSEC network. For more information on using and creating certificates, see “Appendix A, Using the iDirect CA Foundry” of the iBuilder User Guide. Key Distribution Protocol (Figure 38), Key Rolling (Figure 39), and Host Keying Protocol (Figure 40) are based on standard techniques utilized within an X.509 based PKI.

72


TRANSEC Key Management

Figure 38. Key Distribution Protocol Key Distribution Protocol assumes that upon the receipt of a certificate from a peer that the host is able to validate and establish a chain of trust based on the contents of the certificate. iDirect TRANSEC utilizes standard X.509 certificates and methodologies to verify the peer’s certificate. After the completion of the sequence shown in Figure 38, a peer may provide a key update message again in an unsolicited fashion as needed. The data structure utilized to complete key update (also called a key roll) is shown in Figure 39.

Figure 39. Key Rolling and Key Ring This data structure conceptually consists of a set of pointers (Current, Next, Fallow), a two bit identification field (utilized in the Encryption Headers described above), and the actual symmetric keys themselves. A key update consists of generating a new key, placing it in the


73

TRANSEC Remote Admission Protocol

last fallow slot just prior to the Current pointer, updating the next pointers (circular update so 11 rolls to 00) and current pointers and generating a Key Update message reflecting these changes. The key roll mechanism allows for multiple keys to be “in play” simultaneously so that seamless key rolls can be achieved. By default the iDirect TRANSEC solution rolls any symmetric key every two hours, but this is a user configurable parameter. The iDirect Host Keying Protocol is shown Figure 40.

Figure 40. Host Keying Protocol This protocol describes how hosts are originally provided an X.509 certificate from a Certificate Authority. iDirect provides a Certificate Authority Foundry module with its TRANSEC hub. Host key generation is done on the host in all cases.

TRANSEC Remote Admission Protocol Remotes acquire into the network over the clear channel. Specifically, a protocol processor blade is designated to be in charge of controlling remote admission into the network. The only time unencrypted traffic is permitted to traverse the network is during the remote admission sequence. When a remote is given the opportunity to acquire into the network, the acquisition sequence takes place as follows: First, the protocol processor generates two time plans per inroute. One is the normal time plan utilized to indicate to remotes which slots in which inroutes they may burst on. This time plan is always encrypted. The second time plan is not encrypted, and it indicates the owner of

74


Reconfiguring the Network for TRANSEC

the acquisition slot and which remotes may burst in the clear (unencrypted) on selected slots. The union of the two time plans covers all slots in all inroutes. The time plans are then forwarded and broadcast to all remotes in the normal method. Remotes that are not yet acquired receive the unencrypted time plan and wait for an invitation to join the network via this unencrypted message. The remote designated in the acquisition slot acquires in the normal fashion by sending an unencrypted response in the acquisition slot of a specific inroute. Once the physical layer acquisition occurs, the remote must follow the key distribution protocol before it is trusted by the network, and for it to trust the network it is a part of. This step must be carried out in the clear. Therefore remotes in this state will request bandwidth normally and they will be granted unencrypted TDMA slots. The hub and remotes exchange key negotiation messages in the cleartext channel. Three message types exist: •

Solicitations, which are used to synchronize, request, inform, and acknowledge a peer.

•

Certificate Presentations, which contain X.509 certificates.

•

Key Updates, which contain AES key information that is signed and RSA encrypted; the RSA encryption is accomplished by using the remote’s public key and the signature is created by using the hub’s private key.

After authentication, the key update message must also be completed in the clear. The actual symmetric keys are encrypted using the remote’s public key information obtained in the exchanged certificate. Once the symmetric key is exchanged, the remote enters the network as a trusted entity, and begins normal operation in an encrypted mode.

Reconfiguring the Network for TRANSEC Once you have ensured that all hardware is TRANSEC-compatible and you have issued certificates to all X.509 hosts, you can reconfigure your network to operate in TRANSEC mode. For detailed configuration procedures, see “Reconfiguring the Network for TRANSEC” section in the “Converting an Existing Network to TRANSEC” chapter of the iBuilder User Guide.


75

Reconfiguring the Network for TRANSEC

76


12 Fast Acquisition

The Fast Acquisition feature reduces the average acquisition time for remotes, particularly in large networks with hundreds or thousands of remotes. The acquisition messaging process used in prior versions is included in this release. However, the Protocol Processor now makes better use of the information available regarding hub receive frequency offsets common to all remotes to reduce the overall network acquisition time. No additional license requirements are required for this feature.

Feature Description Fast Acquisition is configured on a per-remote basis. When a remote is attempting to acquire the network, the Protocol Processor determines the frequency offset at which a remote should transmit and conveys it to the remote in a time plan message. From the time plan message, the remote learns when to transmit and at what frequency offset. The remote transmit power level is configured in the option file. Based on the time plan message, the remote calculates the correct Frame Start Delay (FSD). The fundamental aspects of acquisition are how often a remote gets an opportunity to come into the network, and how many frequency offsets need to be tried for each remote before it acquires the network. If a remote can acquire the network more quickly by trying fewer frequency offsets, the number of remotes that are out of the network at any one time can be reduced. This determines how often other remotes get a chance to acquire. This feature reduces the number of frequency offsets that need to be tried for each remote. By using a common hub receive frequency offset, the fast acquisition algorithm can determine an anticipated range smaller than the complete frequency sweep space configured for each remote. As the common receive frequency offset is updated and refined, the sweep window is reduced. If an acquisition attempt fails within the reduced sweep window, the sweep window is widened to include the entire sweep range. Fast Acquisition is enabled by default. You can disable it by applying a custom key. For a given ratio x:y, the hub informs the remote to acquire using the smaller frequency offset range calculated based on the Fast Acquisition scheme. After x number of attempts, the remote sweeps the entire range y times before it will sweep the narrower acquisition range. The default ratio is 100:1. That is, try 100 frequency offsets within the reduced (common) range before resorting to one full sweep of the remote’s frequency offsets. If you want to modify the ratio, you can use custom keys that follow to override the defaults. You must apply the custom key to the hub side for each remote in the network.


77

Feature Description

[REMOTE_DEFINITION] sweep_freq_fast = 100 sweep_freq_entire_range = 1 sweep_method = 1 (Fast Acquisition enabled) sweep_method = 0 (Fast Acquisition disabled) Fast Acquisition cannot be used on 3100 series remotes when the upstream symbol rate is less than 260 Ksym/s. This is because the FLL on 3100 series remotes is disabled for upstream rates less than 260 Ksym/s. The NMS disables Fast Acquisition for any remote that is enabled for an iDirect Music Box and for any remote that is not configured to utilize the 10 MHz reference clock. In IF-only networks, such as a test environment, the 10 MHz reference clock is not used.

78


13 Remote Sleep Mode

The Remote Sleep Mode feature conserves remote power consumption during periods of network inactivity. This chapter explains how Remote Sleep Mode is implemented. It includes the following sections: •

“Feature Description” on page 79

•

“Awakening Methods” on page 80

•

“Enabling Remote Sleep Mode” on page 80

•

“Power Consumption” on page 81

Note:

Not all versions of iDX 2.0 support Sleep Mode. This feature requires iDX 2.0.1 or later. Earlier versions of iDX 2.0 do not support Sleep Mode.

Feature Description Remote Sleep mode is supported on all iNFINITI and Evolution series remotes. In this mode, the BUC is powered down, thus saving power consumption. When Sleep Mode is enabled on the iBuilder GUI for a remote, the remote enters Remote Sleep Mode after a configurable period elapses with no data to transmit. By default, the remote exits Remote Sleep Mode whenever packets arrive on the local LAN for transmission on the inbound carrier. Note:

You can use the powermgmt mode set sleep console command to enable or powermgmt mode set wakeup to disable remote sleep mode.

The stimulus for a remote to exit sleep mode is also configurable in iBuilder. You can select which types of traffic automatically “trigger wakeup” on the remote by selecting or clearing a check box for the any of the QoS service levels used by the remote. If no service levels are configured to trigger wakeup the remote, you can manually force the remote to exit sleep mode by disabling sleep mode on the remote configuration screen. Before a remote enters sleep mode, the protocol processor continues to allocate traffic slots (including minimum CIR) to the remote. Before it enters sleep mode, the remote notifies the NMS and the real time state of the remote is updated in iMonitor. Once the remote enters sleep mode, as far as the protocol processor is concerned, the remote is out of the network. Therefore, no traffic slots are allocated to the remote while it is in sleep mode. When the remote receives traffic that triggers wakeup, the remote returns to the network and traffic slots are allocated as normal by the protocol processor.


79

Awakening Methods

Awakening Methods There are two methods by which a remote is “awakened” from Sleep Mode. They are “Operator-Commanded Awakening”, and “Activity-Related Awakening”.

Operator-Commanded Awakening

With Operator Command Awakening, you can manually force a remote into Remote Sleep Mode and subsequently “awake” it via the NMS. This can be done remotely from the Hub since the remote continues to receive the downstream while in sleep mode.

Activity Related Awakening With Activity-Related Sleep Awakening, the remote enters Remote Sleep Mode after a configurable period elapses with no data to transmit. The remote “wakes up” as soon as it receives traffic with these service level markings. When a remote is reset, the activity timer also resets. When the remote sees no traffic that triggers the wake up condition for the configured sleep time-out, it goes into Remote Sleep Mode. In this mode, all the IP traffic that does not trigger a wake up condition is dropped. When a packet with the service level marking that triggers a wakeup is detected, the remote resets the sleep timer and wakes up. In Remote Sleep Mode, the remote processes the burst time plans but it does not apply them to the firmware. No indication is sent to the remote’s router that the interface is down, and therefore the packets from the local LAN are still passed to the remote’s distributor queues. Packets that would wake up the interface will not be dropped by the router and are available to the layers that process this information. The protocol layer that manages the sleep function drops the packets that do not trigger the wakeup mode. Power consumed by the remote under normal and low power (Sleep Mode) is shown in Table Table 8 on page 81.

Enabling Remote Sleep Mode You can enable Remote Sleep Mode by using iBuilder. You can also configure the service levels that trigger the remote to wake up. A sleep time-out period is configurable for each remote. The sleep time-out is the period of inactivity after which the remote enters low power mode. When you enable Sleep Mode on the Remote QoS tab, the remote will conserve power by disabling the 10 MHz reference for the BUC after the specified number of seconds have elapsed with no remote upstream data transmissions. A remote should automatically wake from sleep mode when packets arrive for transmission on the upstream carrier, provided that Trigger Wakeup is selected for the service level associated with the packets. In earlier (iDS) releases that supported Sleep Mode, you were required to configure the SAT0 custom key to force remotes to wake from sleep mode when packets arrived for transmission that matched a service level with Trigger Wakeup selected. This is now the default behavior for remotes in Sleep Mode, so the SAT0 custom key is no longer required. Note:

80

When Sleep Mode is enabled, a remote with RIP enabled will always advertise the satellite route as available on the local LAN, even if the satellite link is down. Therefore, the Sleep Mode feature is not compatible with configurations that rely on the ability of the local router to detect loss of the satellite link.


Power Consumption

To enable Remote Sleep Mode, see the chapter on configuring remotes in the iBuilder User Guide. To configure service level based wake up, see the QoS Chapter in the iBuilder User Guide.

Power Consumption Power consumed by typical remote terminals during both normal operation and sleep mode is shown in Table 8. Table 8. Power Consumption: Normal Operations vs. Remote Sleep Mode


81

Power Consumption

82


14 Automatic Beam Selection This section contains information pertaining to Automatic Beam Selection (ABS) for roaming remotes in a maritime environment.

Automatic Beam Selection Overview An iDirect network is defined as a single outroute and one or more inroutes, all operating with one satellite and one hub. A Network Management System (NMS) can manage and control multiple networks. You can define remotes that “roam” from network to network around the globe. These roaming remotes are not constrained to a single location or limited to any geographic region. Instead, by using the capabilities provided by the iDirect “Global NMS” feature, remote terminals have true global IP access. The decision of which network a particular remote joins is made by the remote. When joining a new network, the remote must re-point its antenna to receive a new beam and tune to a new outroute. Selection of the new beam can be performed manually (by using remote modem console commands) or automatically. This chapter describes how automatic beam selection is implemented in an iDirect network. For detailed information on configuring and monitoring roaming remotes, see the iBuilder User Guide and iMonitor User Guide. For additional information on the ABS feature, see the iBuilder User Guide.

Theory of Operation Since the term “network” is used in many ways, the term “beam” is used rather than the term “network” to refer to an outroute and its associated inroutes. ABS is built on iDirect’s existing mobile remote functionality. When a modem is in a particular beam, it operates as a traditional mobile remote in that beam. In a maritime environment, a roaming remote terminal consists of an iDirect modem and a controllable, steerable, stabilized antenna. The ABS software in the modem can command the antenna to find and lock to any satellite. Using iBuilder, you can define an instance of the remote in each beam that the modem is permitted to use. You can also configure and monitor all instances of the remote as a single entity. The remote options file (which conveys configuration parameters to the remote from the NMS) contains the definition of each of the


83

Theory of Operation

remote’s beams. Options files for roaming remotes, called “consolidated” options files, are described in detail in the iBuilder User Guide. As a vessel moves from the footprint of one beam into the footprint of another, the remote must shift from the old beam to the new beam. Automatic Beam Selection enables the remote to select a new beam, decide when to switch, and to perform the switch-over, without human intervention. ABS logic in the modem reads the current location from the antenna and decides which beam will provide optimal performance for that location. This decision is made by the remote, rather than by the NMS, because the remote must be able to select a beam even if it is not communicating with the network. To determine the best beam for the current location, the remote relies on a beam map file that is downloaded from the NMS to the remote and stored in memory. The beam map file is a large data file containing beam quality information for each point on the Earth's surface as computed by the satellite provider. Whenever a new beam is required by remotes using ABS, the satellite provider must generate new map data in a pre-defined format referred to as a “conveyance beam map file.” iDirect provides a utility that converts the conveyance beam map file from the satellite provider into a beam map file that can be used by the iDirect system. Note:

In order to use the iDirect ABS feature, the satellite provider must enter into an agreement with iDirect to provide the beam map data in a specified format.

By default, a remote modem always attempts to join any beam included in the beam map file if that beam is determined to be the best choice available. This includes beams with a quality value of zero for the remote’s current location. Beginning with iDX Release 2.0.1, you can configure a custom key for your remotes so that they never attempt to join a beam if the quality of the beam at the current location is zero. See the Automatic Beam Selection appendix of the iBuilder User Guide for instructions on configuring the custom key. The iDirect NMS software consists of multiple server applications. One such server application, know as the map server, manages the iDirect beam maps for remotes in its networks. The map server reads the beam maps and waits for map requests from remote modems. A modem has a limited amount of non-volatile storage, so it cannot save an entire map of all beams. Instead, the remote asks the map server to send a map of a smaller area (called a beam “maplet”) that encompasses its current location. When the vessel nears the edge of its current maplet, the remote asks for another beam maplet centered on its new location. The geographical size of these beam maplets varies in order to keep the file size approximately constant. A beam maplet typically covers a 1000 km square.

Beam Characteristics: Visibility and Usability The remote can determine two characteristics of each beam even without the map: •

A beam is defined as visible if the look elevation to the satellite is greater than the minimum look elevation. The minimum look elevation defaults to ten degrees above the horizon.

•

A beam is usable unless an attempt to use it fails. The beam is considered unusable for a period of one hour after the failure, or until all visible beams are unusable.

If the selected beam is unusable, the remote attempts to use another beam, provided one or more usable beams are available. A beam can become unusable for many reasons, but each

84


Theory of Operation

reason ultimately results in the inability of the remote to communicate with the outside world using the beam. Therefore the only usability check is based on the “layer 3 state” of the satellite link, such as whether or not the remote can exchange IP data with the upstream router. Examples of causes that might result in a beam becoming unusable include: •

The NMS operator disables the modem instance.

•

A Hub Line Card fails with no available backup.

•

The Protocol Processor fails with no backup.

•

A component in the upstream or downstream RF chain fails.

•

The satellite fails.

•

The beam is reconfigured.

•

The remote cannot lock to the downstream carrier.

•

The receive line card stops receiving the modem.

Anything that causes the remote to inhibit its transmitter causes the receive line card to stop receiving the modem, which eventually causes Layer 3 to fail. The modem stops transmitting if it loses downstream lock. A mobile remote will also stop transmitting under the following conditions: •

The remote has not acquired and no GPS information is available.

•

The remote antenna declares loss-of-lock.

•

The antenna declares a blockage.

Selecting a Beam without a Map Under certain circumstances the remote will not have a beam maplet that covers its current location. When this occurs, remotes use a round-robin selection algorithm, attempting to use each visible, usable beam defined in its options file in turn for five minutes until the remote is acquired. This can occur under various conditions: •

When a remote is being commissioned.

•

If the vessel travels with the modem turned off and must locate a beam when returned to service.

•

If the remote cannot remain in the network for an extended period due to blockage or network outage.

•

If the map server is unreachable.

In all cases, after the remote establishes communications with the map server, it immediately asks for a new maplet. When a maplet becomes available, the remote uses the maplet to compute the optimal beam, and switches to that beam if it is not the current beam.

Controlling the Antenna To make the system work, the remote must be able to control the antenna. The remote software communicates with the antenna control unit supplied with the antenna over the local LAN. Since there is no standard antenna control protocol, the remote code must be written specifically for each protocol. The following antenna protocols are currently supported:


85

Operational Scenarios

•

Orbit-Marine AL-7104

•

Schlumberger SpaceTrack 4000

•

SeaTel DAC

•

Open AMIP

A steerable, stabilized antenna must know its geographical location in order to point to the antenna. The antenna includes a GPS receiver for this purpose. The remote must also know its geographical location to select the correct beam and to compute its distance from the satellite. The remote periodically commands the antenna controller to send the current location to the modem.

IP Mobility Communications to the customer intranet (or to the Internet) are automatically reestablished after a beam switch-over. The process of joining the network after a new beam is selected uses the same internet routing protocols that are already established in the iDirect system. When a remote joins a beam, the Protocol Processor for that beam begins advertising the remote's IP addresses to the upstream router using the RIP protocol. When a remote leaves a beam, the Protocol Processor for that beam withdraws the advertisement for the remote's IP addresses. When the upstream routers see these advertisements and withdrawals, they communicate with each other using the appropriate IP protocols to determine their routing tables. This permits other devices on the Internet to send data to the remote over the new path with no manual intervention.

Operational Scenarios This section presents a series of top-level operational scenarios that can be followed when configuring and managing iDirect networks that contain roaming remotes using Automatic Beam Selection. Steps for configuring network elements such as iDirect networks (beams) and roaming remotes are documented in iBuilder User Guide. Steps specific to configuring ABS functionality, such as adding an ABS-capable antenna or converting a conveyance beam map file, are described in “Appendix C, Configuring Networks for Automatic Beam Selection” of the iBuilder User Guide.

Creating the Network This scenario outlines the steps that must be performed by the customer, the satellite provider, and the network operator to create a network that uses ABS. 1. The customer determines the satellite provider and agree on the set of beams (satellites, transponders, frequencies and footprints) to be used by remotes using ABS. 2. The satellite provider enters into an agreement with iDirect specifying the format of the conveyance beam map file. 3. The satellite provider supplies the link budget for the hub and remotes. 4. iDirect delivers the map conversion program to the customer specific to the conveyance beam map file specification. 5. The satellite provider delivers to the customer one conveyance beam map file for each beam that the customer will use.

86



6. The customer orders and installs all required equipment and an NMS. 7. The NMS operator configures the beams (iDirect networks). 8. The NMS operator runs the conversion program to create the server beam map file from the conveyance beam map file or files. 9. The NMS operator runs the map server as part of the NMS.

Adding a Vessel This scenario outlines the steps required to add a roaming remote using ABS to all available beams. 1. The NMS operator configures the remote modem in one beam. 2. The NMS operator adds the remote to the remaining beams. 3. The NMS operator saves the modem's options file and delivers it to the installer. 4. The installer installs the modem aboard a ship. 5. The installer copies the options file to the modem using iSite. 6. The installer manually selects a beam for commissioning. 7. The modem commands the antenna to point to the satellite. 8. The modem receives the current location from antenna. 9. The installer commissions the remote in the initial beam. 10. The modem enters the network and requests a maplet from the NMS map server. 11. The modem checks the maplet. If the commissioning beam is not the best beam, the modem switches to the best beam as indicated in the maplet. This beam is then assigned a high preference rating by the modem to prevent the modem from switching between overlapping beams of similar quality. 12. Assuming center beam in clear sky conditions: 13. The installer sets the initial transmit power to 3 dB above the nominal transmit power. 14. The installer sets the maximum power to 6 dB above the nominal transmit power. Note:

Check the levels the first time the remote enters each new beam and adjust the transmit power settings if necessary.

Normal Operations This scenario describes the events that occur during normal operations when a modem is receiving map information from the NMS. 1. The ship leaves port and travels to next destination. 2. The modem receives the current location from antenna every five minutes. 3. While in the beam, the antenna automatically tracks the satellite. 4. As the ship approaches the edge of the current maplet, the modem requests a new maplet from the map server.


87


5. When the ship reaches a location where the maplet shows a better beam, the remote switches by doing the following: a. a. Computes best beam. b. b. Saves best beam to non-volatile storage. c. c. Reboots. d. d. Reads the new best beam from non-volatile storage. e. e. Commands the antenna to move to the correct satellite and beam. f.

f. Joins the new beam.

Mapless Operations This scenario describes the events that occur during operations when a modem is not receiving beam mapping information from the NMS. 1. While operational in a beam, the remote periodically asks the map server for a maplet. The remote does not attempt to switch to a new beam unless one of the following conditions are true: a. a. The remote drops out of the network. b. b. The remote receives a maplet indicating that a better beam exists. c. c. The satellite drops below the minimum look elevation defined for that beam. 2. If not acquired, the remote selects a visible, usable beam based only on satellite longitude and attempts to switch to that beam. 3. After five minutes, if the remote is still not acquired, it marks the new beam as unusable and selects the best beam from the remaining visible, usable beams in the options file. This step is repeated until the remote is acquired in a beam, or all visible beams are marked as unusable. 4. If all visible beams are unusable, the remote marks them all as usable, and continues to attempt to use each beam in a round-robin fashion as described in step 3.

Blockages and Beam Outages This scenario describes the events that occur when a modem cannot join or loses the selected beam. 1. If the remote fails to join the selected beam after five minutes, it marks the beam as unusable and selects a new beam based on the maplet. 2. If the remote loses network connectivity for five minutes, it marks the current beam as unusable and selects a new beam based on the maplet. 3. Any beam marked as unusable remains unusable for an hour or until all beams are marked as unusable. 4. If only the current beam is visible, the remote will not attempt to switch from that beam, even after losing connectivity for five minutes.

88



Error Recovery This section describes the actions taken by the modem under certain error conditions. 1. If the remote cannot communicate with the antenna and is not acquired into the network, it will reboot after five minutes. 2. If the antenna is initializing, the remote waits for the initialization to complete. It will not attempt to switch beams during this time.


89


90


15 Hub Geographic Redundancy This chapter describes how you can establish a primary and back up hub that are geographically diverse. It includes the following sections: •

“Feature Description” describes how geographic redundancy is accomplished.

•

“Configuring Wait Time Interval for an Out-of-Network Remote” describes how you can set the wait period before switchover.

Feature Description The Hub Geographic Redundancy feature builds on the previously developed Global NMS feature and the existing dbBackup/dbRestore utility. You configure the Hub Geographic Redundancy feature by defining all the network information for both the Primary and Backup Teleports in the Primary NMS. All remotes are configured as roaming remotes and they are defined identically in both the Primary and Backup Teleport network configurations. During normal (non-failure) operations, carrier transmission is inhibited on the Backup Teleport. During failover conditions (when roaming network remotes fail to see the downstream carrier through the Primary Teleport NMS) you can manually enable the downstream transmission on the Backup Teleport, allowing the remotes to automatically (after the configured default wait period of five minutes) acquire the downstream transmission through the Backup Teleport NMS. iDirect recommends the following for most efficient switchover: •

A separate IP connection (at least 128 Kbps) between the Primary and Backup Teleport NMS for database backup and restore operations. A higher rate line can be employed to reduce this database archive time.

•

The downstream carrier characteristics for the Primary and Backup Teleports MUST be different. For example, either the FEC, frequency, frame length, or data rate values must be different.

•

On a periodic basis, backup and restore your NMS configuration database between your Primary and Backup Teleports. See the NMS Redundancy and Failover Technical Note for complete NMS redundancy procedures.


91

Configuring Wait Time Interval for an Out-of-Network Remote

Configuring Wait Time Interval for an Out-of-Network Remote If a roaming remote is configured at both a Primary and Backup Hub, and the remote loses the Downstream carrier from the Primary Hub, the remote attempts to lock to the Downstream carrier from the Backup Hub, after a configured interval in seconds. By default this “wait time” before attempting the switch is 300 seconds (5 minutes). This wait time for beam switchover can be changed by setting the net_state_timeout custom key value (in seconds) to the desired wait period. For example, if you want to make the wait period 10 minutes, use the following custom key: [REMOTE_DEFINITION] net_state_timeout=600 For further configuration information, see the chapter “Defining Network Components” in the iBuilder User Guide.

92


16 Carrier Bandwidth Optimization This chapter describes carrier bandwidth optimization and carrier spacing. It includes the following sections: •

“Overview" describes how reducing carrier spacing increases overall available bandwidth.

•

“Increasing User Data Rate" provides an example of how you can increase user data rates with out increasing occupied bandwidth.

•

“Decreasing Channel Spacing to Gain Additional Bandwidth" provides an example of how you can increase occupied bandwidth.

Overview The Field Programmable Gated Array (FPGA) firmware uses optimized digital filtering which reduces the amount of satellite bandwidth required for an iDirect carrier. Instead of using a 40% guard band between carriers, now the guard band may be reduced to as low as 20% on both the broadcast Downstream channel and the TDMA Upstream. Figure 41 shows an overlay of the original spectrum and the optimized spectrum.

Figure 41. Overlay of Carrier Spectrums This optimization translates directly into a cost savings for existing and future networks deployed with iDirect remote modems.


93

Increasing User Data Rate

The spectral shape of the carrier is not the only factor contributing to the guard band requirement. Frequency stability parameters of a system may result in the need for a guard band of slightly greater than 20% to be used. iDirect complies with the adjacent channel interference specification in IESS 308 which accounts for adjacent channels on either side with +7 dB higher power. Be sure to consult the designer of your satellite link prior to changing any carrier parameters to verify that they do not violate the policy of your satellite operator.

Increasing User Data Rate Since the amount of required guard band between carriers has been reduced, it is now possible to fit a higher bit rate carrier into the same satellite bandwidth that was required previously. Therefore, a network operator can increase the bit rate of existing carriers without purchasing additional bandwidth. A consequence of choosing this option is that increasing the bit rate of the carrier to fill the extra bandwidth requires slightly more power. Increasing the bit rate by 15% would result in an additional 0.5 dB of power. Be sure to consult the provider of your link budget prior to adjusting the bit rate of your carriers. Frequency stability in the system may limit the amount of bit rate increase by increasing the guard band requirement. The example that follows illustrates a scenario applicable to a system with negligible frequency stability concerns. It shows how the occupied bandwidth does not increase when the user data rate increases. In this example, FEC rate 0.793 with 4 kbit Turbo Product Code is used. Current Carrier Parameters: • User Bit (info) Rate:1000 kbps •

Carrier Bit Rate:1261.034 kbps

•

Carrier Symbol Rate:630.517 ksps

•

Occupied Bandwidth:882.724 kHz

•

Guard Band Between Carriers: 40% (Channel Spacing = 1.4)

New Carrier Parameters • User Bit (info) Rate: 1166.667 kbps •

Carrier Bit Rate: 1471.206 kbps

•

Carrier Symbol Rate: 735.603 ksps

•

Occupied Bandwidth: 882.724 kHz

•

Guard Band Between Carriers: 20% (Channel Spacing = 1.2)

A 16.67% improvement in user data rate is achieved at no additional cost. It is possible that due to instability of frequency references in a satellite network system, a carrier may not fall exactly on its assigned center frequency. iDirect networks combat frequency offset using an automatic frequency control algorithm. Any additional instability must be accommodated by additional guard band. The frequency references to the hub transmitter and to the satellite itself are generally very stable so the main source of frequency instability is the downconverter at the hub. This is

94


Decreasing Channel Spacing to Gain Additional Bandwidth

because the automatic frequency control algorithm uses the hub receiver’s estimate of frequency offset to adjust each remote transmitter frequency. Hub stations which use a feedback control system to lock their downconverter to an accurate reference may have negligible offsets. Hub stations using a locked LNB will have a finite frequency stability range. Another reason to add guard band is to account for frequency stability of other carriers directly adjacent on the satellite which are not part of an iDirect network. Be sure to review this situation with your satellite link designer before changing carrier parameters. The example that follows accounts for a frequency stability range for systems using equipment with more significant stability concerns. Given the “Current Carrier Parameters” the previous example and a total frequency stability of +/-5 kHz, compute the new carrier parameters: Solution: •

Subtract the total frequency uncertainty from the available bandwidth to determine the amount of bandwidth left for the carrier (882.724 kHz – 10 kHz = 872.724 kHz).

•

Divide this result by the minimum channel spacing (872.724 / 1.2 = 727.270 kHz).

•

Use the result as the carrier symbol rate and compute the remaining parameters.

New Carrier Parameters • User Bit (info) Rate: 1153.450 kbps •

Carrier Bit Rate: 1454.540 kbps

•

Carrier Symbol Rate: 727.270 ksps

•

Occupied Bandwidth: 882.724 kHz

•

Guard Band Between Carriers: 21.375% (Channel Spacing = 1.21375)

A 15.345% improvement in user bit rate was achieved at no additional cost.

Decreasing Channel Spacing to Gain Additional Bandwidth The amount of required guard band between carriers can also be expressed as the channel spacing requirement. For example, if the required guard band is 20%, the channel spacing requirement is 1.2*Carrier_Symbol_Rate (Hz). Therefore, a network operator may take advantage of the new carrier bandwidth optimization by reworking their frequency plan such that excess bandwidth is available for use by another carrier. For example, consider an iDirect network with a user data (information) rate of 5 Mbps on the downstream and three upstream carriers of 1 Mbps each. FEC rate 0.793 with 4 kbit TPC is used for all carriers in this example. Figure 42 shows that an additional Upstream carrier may be added by reducing the channel spacing of the existing carriers.


95

Decreasing Channel Spacing to Gain Additional Bandwidth

Figure 42. Adding an Upstream Carrier By Reducing Carrier Spacing

96


17 Alternate Downstream Carrier This chapter provides information about iDirect’s Alternate Downstream Carrier feature. It contains the following sections: •

“Background” on page 97

•

“Feature Description” on page 97

Background The Alternate Downstream Carrier feature is intended to make it easier to move your iDirect network to a new transmit carrier and to eliminate the danger of stranding remotes that have not received the new carrier definition when the carriers are switched. If, for example, you want to move your network to a larger transmit carrier, or you want to switch from SCPC to DVB-S2, you can use the Alternate Downstream Carrier feature to facilitate the transition. In earlier releases, if you changed your downstream carrier, a site visit was required to recover any remotes that were not in the network at the time that the carrier was changed. The Alternate Downstream Carrier feature is disabled if your NMS server is licensed for the Global NMS feature. However, the Global NMS feature allows you to accomplish the same goal by creating an alternate network containing the new downstream carrier and configuring instances of your roaming remotes in both the existing network and the new network. Like the Alternate Downstream Carrier feature, this allows you to ensure that all remotes have the new downstream carrier definition prior to the actual upgrade.

Feature Description Beginning in iDX Release 2.0, iBuilder provides the capability of selecting an alternate downstream carrier on the Line Card dialog box of your transmit line card. (See the chapter titled “Defining Networks, Line Cards, and Inroute Groups” in the iBuilder User Guide for details). The configuration includes all necessary parameters for the remote to acquire the alternate downstream. You should configure the alternate carrier for your network well in advance of the carrier change to ensure that all remotes have the alternate carrier definition when you change carriers. If a remote is not in the network at the time of the carrier change it will attempt to acquire the old primary carrier unsuccessfully when it first tries to rejoin the network. Since the old primary carrier is no longer being transmitted, the remote will then attempt to acquire its configured alternate downstream carrier which is the new primary carrier. At that point the remote will acquire the network on the new carrier.


97

Feature Description

iDirect supports two types of downstream carriers: DVB-S2 and SCPC. A DVB-S2 downstream carrier can serve as the alternate carrier for an SCPC primary carrier. Similarly, an SCPC downstream carrier can serve as the alternate carrier for a DVB-S2 primary carrier. However, this only works if your Tx line card and all remotes in your network support both downstream carrier types. For example, an Evolution XLC-11 line card can transmit either a DVB-S2 or an SCPC carrier and an Evolution X5 remote can receive either a DVB-S2 or an SCPC carrier. Therefore, you can configure a network containing an XLC-11 transmit line card and X5 remotes with one type of carrier as the primary downstream carrier and the other type of carrier as the alternate downstream carrier. Note:

An Evolution line card that is capable of transmitting either SCPC or DVB-S2 requires one firmware package for SCPC and another firmware package for DVB-S2. If you plan to use the Alternate Downstream Carrier feature to switch between SCPC and DVB-S2, you should load both packages onto your line card. See the chapter titled “Converting Between SCPC and DVB-S2 Networks” in the iBuilder User Guide for details.

When a remote joins a network with a configured Alternate Downstream Carrier, it first attempts to acquire the last downstream carrier to which it was locked before it attempts to acquire the other carrier. Therefore, if the remote was last locked to the primary carrier, it attempts to lock to the primary carrier again when it tries to rejoin the network. Similarly, if the remote was last locked to the alternate carrier, it attempts to lock to the alternate carrier again when it tries to rejoin the network. By default, a remote tries for five minutes (300 seconds) to find the last carrier before switching to the other carrier. However, this timeout can be changed by defining the net_state_timeout remote-side custom key on the Remote Custom tab in iBuilder as follows: [BEAMS] net_state_timeout = where is the number of seconds that the remote tries to acquire the primary carrier before switching to the alternate carrier. Note:

If a new remote has never locked to any carrier, it always attempts to lock to the primary downstream carrier first. Therefore, when commissioning a new remote, it will first look for the primary carrier even if an alternate carrier is configured.

Primary and alternate downstream carriers cannot co-exist as active carriers in an iDirect system. In addition, the Alternate Downstream Carrier feature is not intended to be used as a recovery channel. If you have selected an Alternate Downstream Carrier for one Tx line card, iBuilder does not allow you to assign that carrier to another line card, either as the primary or alternate carrier. The procedure for moving your network to the Alternate Downstream Carrier is documented in the iBuilder User Guide. See “Changing to an Alternate Downstream Carrier” in the chapter titled “Defining Networks, Line Cards, and Inroute Groups.”

98


18 Feature and Chassis Licensing Beginning with iDX Release 2.0, you must license your chassis slots and certain iDirect features before you can enable them in iBuilder.

Licensed Features In addition to requiring chassis slots to be licensed, iBuilder requires licenses for the following features: •

Evolution X3 AES Link Encryption

•

Evolution X5 AES Link Encryption

•

Evolution X5 Upstream Spread Spectrum

•

XLC-11 Upstream Spread Spectrum

•

XLC-11 Downstream Spread Spectrum

License Files When you license your chassis slots or any of the features listed above, iDirect will send you a license file. Using the iBuilder License Toolbar, you must then import the license file to enable the configuration of the chassis or feature on the iBuilder GUI. For information on importing your license files into iBuilder and for validating your chassis licences in iBuilder, see the iBuilder User Guide. For general information on licensing (including obtaining licenses from iDirect), see the iDirect Features and Chassis Licensing Guide.


99

License Files

100


19 Hub Line Card Failover

This chapter describes basic hub line card failover concepts, transmit/receive verses receiveonly line card failover, failover sequence of events, and failover operation from a user’s point of view. For information about configuring your line cards for failover, refer the “Networks, Line Cards, and Inroute Groups” chapter of the iBuilder User Guide.

Basic Failover Concepts Each second, every line card sends a diagnostic message to the NMS. This message contains the status of various onboard components. If the NMS fails to receive any diagnostic messages from a line card for 60 seconds, and all failover prerequisites are met, it considers that the line card may be in failed state. It takes another 15 seconds to ensure that line card has truly failed. It then starts the failover process. If the standby line card is acting as a warm standby for the failed line card, it assumes the failed card’s role immediately. If the standby is a cold standby for the failed line card, it needs to flash a new options file and reset. The estimated time to complete a line card failover to a warm standby is less than 10 seconds; the estimated time to complete a failover to a cold standby is less than 1 minute. Note:

If your Tx line card fails, or you only have a single Rx line card and it fails, all remotes must re-acquire into the network after failover is complete.

Warm Standby versus Cold Standby Line Card Failover A standby line card can act as a warm standby for one active line card and as a cold standby for multiple additional line cards. Although you can configure a standby line card as a warm standby for any active line card, it typically makes the most sense to configure it as a warm standby for your Tx line card and as a cold standby for your Rx line cards. In a multi-inroute, frequency hopping network, the most critical line card is the Tx (or Tx/Rx) line card. If this card fails, all remotes drop out of the network. When an Rx-only card fails in a frequencyhopping inroute group, all remotes automatically begin sharing the other inroutes. While this may result in diminished bandwidth, remotes do not drop out of the network. Ensuring that there is a warm standby configured for your Tx line card guarantees the fastest failover possible for the most critical line cards. In that case, the warm standby line card is pre-configured with the parameters of the Tx card for that network, and has those


101

Failover Sequence of Events

parameters loaded into memory. The only difference between the active Tx(Rx) card and the warm standby is that the standby mutes its transmitter (and receiver). When the NMS detects a Tx(Rx) line card failure, it sends a command to the warn standby to un-mute its transmitter (and receiver), and the standby immediately assumes the role of the Tx(Rx) card. Cold standby line cards take longer to failover than warm standby line cards because they need to receive a new options file, flash it, and reset.

Failover Sequence of Events The flow chart that shows the sequence of events performed on the NMS server to execute a complete failover is shown in Figure 43. Portions of the failover sequence of events are revealed in real-time. You may perform a historical condition query in iMonitor at any time to see the alarms and warnings that are generated and archived during the failover operation.

102


Failover Sequence of Events

Event Server determines line card has failed

Configuration Server is notified

Automatic failover selected ?

NO

DONE.

iMonitor will show the line card in the Alarm state . User may initiate manual failover if desired .

YES

User initiates manual failover

Prerequisites Met ?

NO

DONE.

User will have already been notified that failover cannot happen .

YES All subsequent operations are handled by the Configuration Server unless otherwise noted

Configuration Server powers down slot of failed card .

Send ACTIVE options file of failed card to spare and reset

NO

Warm Standby?

YES

Send command to spare to switch role from Standby to Primary ; send ACTIVE options file of failed card but DO NOT reset

Apply necessary changes to puma serial ( number )

Former spare gets role of failed card Tx ( TxRx , or , Rx ) and carrier inroute / group assignments

Configuration Server must grab exclusive write lock at this point. Any user with the lock will lose the lock and any unsaved changes .

Failed unit gets new role :Failed .

Figure 43. Line Card Failover Sequence of Events


103

IDIRECT Technical Reference Guide

Recommend Documents