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

Technical Reference Guide iii

iDX Release 2.0
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 Technical Reference Guide

iDX Release 2.0
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

Technical Reference Guide v

iDX Release 2.0
 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 Technical Reference Guide

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

Technical Reference Guide vii

iDX Release 2.0
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 Technical Reference Guide

iDX Release 2.0
 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

Technical Reference Guide ix

iDX Release 2.0
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 Technical Reference Guide

iDX Release 2.0
 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”

Technical Reference Guide xi

iDX Release 2.0
 • “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 Example

Blue Used when the user is Enter the command:
Courier required to enter a cd /etc/snmp/
font command at a command
line prompt or in a console.
Courier Used when showing crc report all
font resulting output from a
3100.3235 : DATA CRC [ 1]
command that was entered
3100.3502 : DATA CRC [5818]
at a command line or on a
3100.4382 : DATA CRC [ 20]
console.
Bold Used when referring to text 1. If you are adding a remote to an inroute group,
Trebuchet that appears on the screen right-click the Inroute Group and select Add
font on a windows-type Remote.
Graphical User Interface
(GUI).
Used when specifying
The Remote dialog box has a number of user-
names of commands,
selectable tabs across the top. The Information tab is
menus, folders, tabs,
visible when the dialog box opens.
dialogs, list boxes, and
options.
Blue Used to show all For instructions on adding an iSCPC line card to the
Trebuchet hyperlinked text within a network tree and selecting a Hub RFT for the line card,
font document. see “Adding an iSCPC Line Card” on page 108.
Bold italic Used to emphasize Note: Several remote model types can be
Trebuchet information for the user, configured as iSCPC remotes.
font such as in notes.

Red italic Used when the user needs

Trebuchet to strictly follow the
WARNING! The following procedure may cause
font instructions or have
additional knowledge about
a network outage.
a procedure or action.

xii Technical Reference Guide

iDX Release 2.0
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].

Technical Reference Guide xiii

iDX Release 2.0
xiv Technical Reference Guide
iDX Release 2.0
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

Technical Reference Guide 1

iDX Release 2.0
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 Technical Reference Guide

iDX Release 2.0
 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

Technical Reference Guide 3

iDX Release 2.0
IP Network Architecture

Figure 3. iDirect IP Architecture – VLAN Spanning Remotes

4 Technical Reference Guide

iDX Release 2.0
 IP Network Architecture

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.

Technical Reference Guide 5

iDX Release 2.0
IP Network Architecture

6 Technical Reference Guide

iDX Release 2.0
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.

Technical Reference Guide 7

iDX Release 2.0
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
12 8PSK 3/5 ACM or CCM
13 2/3
14 3/4
15 5/6
16 8/9
17 9/10 CCM only
18 16APSK 2/3 ACM or CCM
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: 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.

8 Technical Reference Guide

iDX Release 2.0
 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 QPSK
...
TPC .793 TPC .793

time

DVBS2 : CCM Mode:

: single MODCOD (one of QPSK¼
All BB Frames , … , 16 PSK9/10 )

8 PSK 8 PSK 8 PSK 8 PSK

...
9/10 9/10 9/10 9/10

time

DVBS2 : ACM Mode:

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

16P 16P 8 PSK 16P QPSK 8 PSK 8 PSK 16P 8 PSK

5/6 4/5 2/3 4/5 2/3 8/9 8/9 8/9 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-

Technical Reference Guide 9

iDX Release 2.0
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 Pilot symbols: Data symbols:

MODCOD and frame unmodulated QPSK, 8PSK,
length (always /2 BPSK) carrier 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 Technical Reference Guide

iDX Release 2.0
 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.

Technical Reference Guide 11

iDX Release 2.0
DVB-S2 in iDirect

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

12 Technical Reference Guide

iDX Release 2.0
 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.

Technical Reference Guide 13

iDX Release 2.0
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 Technical Reference Guide

iDX Release 2.0
 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.

Technical Reference Guide 15

iDX Release 2.0
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
600 400

350
500

Relative Bandwidth
300
400
250
Nominal
CIR

300 @ ClearSky 200

150
200
100
100
50

0 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 Technical Reference Guide

iDX Release 2.0
 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

350
500

Relative Bandwidth
300
400
250
Nominal EIR Min
CIR

300 200

150
200
100
100
50

0 0

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

Technical Reference Guide 17

iDX Release 2.0
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

Scaling
MODCOD Comments
Factor
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)
• 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

18 Technical Reference Guide

iDX Release 2.0
 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 DVB-
S2 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.

Technical Reference Guide 19

iDX Release 2.0
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 Technical Reference Guide

iDX Release 2.0
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.

Technical Reference Guide 21

iDX Release 2.0
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: For the list of DVB-S2 downstream MODCODs supported in iDX 2.0, see Table 1
on page 8.

22 Technical Reference Guide

iDX Release 2.0
 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

Technical Reference Guide 23

iDX Release 2.0
2D 16-State Inbound Coding for DVB-S2 Networks

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

24 Technical Reference Guide

iDX Release 2.0
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

Technical Reference Guide 25

iDX Release 2.0
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 Technical Reference Guide

iDX Release 2.0
 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 Plus hub downcoverter oscillator
stability factor
Spectral Mask IESS-308/309, MIL-STD 188xxx
Carrier Suppression > -30 dBc
Hardware Platforms M1D1-TSS HLC; Evolution eM1D1, XLC-11

Technical Reference Guide 27

iDX Release 2.0
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 ADDITIONAL INFORMATION

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 Rates 1/2, 2/3 2D-16 coding
available in DVB-S2 networks only
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 iNFINITI series 8350; Evolution e8350, X5

28 Technical Reference Guide

iDX Release 2.0
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 packet-
switched 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).

Technical Reference Guide 29

iDX Release 2.0
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 user-
defined 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 Technical Reference Guide

iDX Release 2.0
 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:

Technical Reference Guide 31

iDX Release 2.0
Classification Profiles for Applications

• 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 Technical Reference Guide

iDX Release 2.0
 Classification Profiles for Applications

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.

Technical Reference Guide 33

iDX Release 2.0
Classification Profiles for Applications

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 Technical Reference Guide

iDX Release 2.0
 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

Technical Reference Guide 35

iDX Release 2.0
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
• Video
• Oracle
• Citrix
• VLAN
• NMS Traffic

36 Technical Reference Guide

iDX Release 2.0
 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.

Technical Reference Guide 37

iDX Release 2.0
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: 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.

38 Technical Reference Guide

iDX Release 2.0
 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

Technical Reference Guide 39

iDX Release 2.0
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 Technical Reference Guide

iDX Release 2.0
 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.

Technical Reference Guide 41

iDX Release 2.0
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 Technical Reference Guide

iDX Release 2.0
 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

Technical Reference Guide 43

iDX Release 2.0
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 Remote-
Based 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:
• 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
• Remote 2 receives 300 Kbps * 1.2382 / 2.4605 = 150 Kbps of Best Effort for a Total of 1.151
Mbps
• Remote 3 receives 300 Kbps * 1.2382 / 3.6939 = 101 Kbps of Best Effort for a Total of 1.101
Mbps

44 Technical Reference Guide

iDX Release 2.0
 Group QoS

Remote-Based GQoS Mode

Service CIR = 6.5M
Network’s Best MODCOD Grp MIR = 7.2M
16APSK 8/9
(Scale Factor 1.2382)

Nominal MODCOD (all Remotes)

16APSK 8/9
(Scale Factor 1.2382) App
Grp

Remote 1 Remote 2 Remote 3

CIR = 1M CIR = 1M CIR = 1M

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

Operating @ 8PSK 8/9 Operating @ QPSK 8/9 Operating @ QPSK 3/5

(Scale Factor 1.6456) (Scale Factor 2.4605) (Scale Factor 3.6939)
Demand = 1.5M Demand = 1.5M Demand = 1.5M

CIR Allocation = 1M CIR Allocation = 1M CIR Allocation = 1M

Best Effort Allocation = 226K Best Effort Allocation = 151K Best Effort Allocation = 101K
Total Allocation = 1.226M Total Allocation = 1.151M Total Allocation = 1.101M

Figure 22. Scaled Aggregate CIRs Below Partition’s CIR

Technical Reference Guide 45

iDX Release 2.0
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 2 receives 1 Mbps * 1.2382 / 2.4605 = 503 Kbps
• Remote 3 receives 1 Mbps * 1.2382 / 3.6939 = 335 Kbps

Remote-Based GQoS Mode Service CIR = 3M

Grp MIR = 3M
Nominal MODCOD (all Remotes)
16APSK 8/9
(Scale Factor 1.2382)

App
Grp

Remote 1 Remote 2 Remote 3

CIR = 1M CIR = 1M CIR = 1M

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

Operating @ 8PSK 8/9 Operating @ QPSK 8/9 Operating @ QPSK 3/5

(Scale Factor 1.6456) (Scale Factor 2.4605) (Scale Factor 3.6939)
Demand = 1.5M Demand = 1.5M Demand = 1.5M

CIR Allocation = 752K CIR Allocation = 503K CIR Allocation = 335K

Best Effort Allocation = 0K Best Effort Allocation = 0K Best Effort Allocation = 0K
Total Allocation = 752K Total Allocation = 503K Total Allocation = 335K

Figure 23. Scaled Aggregate CIRs Exceed Partition’s CIR

46 Technical Reference Guide

iDX Release 2.0
 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.

Allocation Fairness Allocation Fairness

450K Available for 450K Available for
the Service Group
Service Group Relative to CIR -
the Service Group
Service Group Relative to CIR -
Disabled 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.

Technical Reference Guide 47

iDX Release 2.0
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 ¾ Allocation Fairness 1.65M @ 8PSK ¾ Allocation Fairness

Available for the Service Group Relative to MODCOD Available for the Service Group Relative to MODCOD
Service Group - Disabled Service Group - Enabled

Remote 1 Remote 2 Remote 1 Remote 2

(CIR = 1M) (CIR = 1M) (CIR = 1M) (CIR = 1M)
Nominal 8PSK 3/4 Nominal QPSK 3/4 Nominal 8PSK 3/4 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 Technical Reference Guide

iDX Release 2.0
 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

Technical Reference Guide 49

iDX Release 2.0
Application Throughput

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 Technical Reference Guide

iDX Release 2.0
 Application Throughput

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.

Technical Reference Guide 51

iDX Release 2.0
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 higher-
level 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 Technical Reference Guide

iDX Release 2.0
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.

Technical Reference Guide 53

iDX Release 2.0
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 Technical Reference Guide

iDX Release 2.0
 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.

Technical Reference Guide 55

iDX Release 2.0
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 Technical Reference Guide

iDX Release 2.0
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

Technical Reference Guide 57

iDX Release 2.0
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 Technical Reference Guide

iDX Release 2.0
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 commercial-
grade 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.

Technical Reference Guide 59

iDX Release 2.0
Root Passwords

60 Technical Reference Guide

iDX Release 2.0
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

Technical Reference Guide 61

iDX Release 2.0
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
NM S Servers and
control

M onitor and C ontrol sada

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 Technical Reference Guide

iDX Release 2.0
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.

Technical Reference Guide 63

iDX Release 2.0
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 Technical Reference Guide

iDX Release 2.0
 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

Technical Reference Guide 65

iDX Release 2.0
dbBackup/dbRestore and the Distributed NMS

66 Technical Reference Guide

iDX Release 2.0
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.

Technical Reference Guide 67

iDX Release 2.0
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 M1D1-
T, 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: TRANSEC is not supported on DVB-S2 outbound carriers. The eM1D1 line card
only supports TRANSEC when transmitting an iDirect SCPC outbound carrier.

68 Technical Reference Guide

iDX Release 2.0
 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.

Technical Reference Guide 69

iDX Release 2.0
TRANSEC Downstream

SCPC TRANSEC FRAME

Encryption Header Segment FEC Coding

Code Seq Rsvd Initialization Vector FH1 F1 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 Technical Reference Guide

iDX Release 2.0
 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:

Technical Reference Guide 71

iDX Release 2.0
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-the-
middle 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 Technical Reference Guide

iDX Release 2.0
 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

Technical Reference Guide 73

iDX Release 2.0
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 Technical Reference Guide

iDX Release 2.0
 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.

Technical Reference Guide 75

iDX Release 2.0
Reconfiguring the Network for TRANSEC

76 Technical Reference Guide

iDX Release 2.0
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.

Technical Reference Guide 77

iDX Release 2.0
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 Technical Reference Guide

iDX Release 2.0
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.

Technical Reference Guide 79

iDX Release 2.0
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: 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.

80 Technical Reference Guide

iDX Release 2.0
 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

Technical Reference Guide 81

iDX Release 2.0
Power Consumption

82 Technical Reference Guide

iDX Release 2.0
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

Technical Reference Guide 83

iDX Release 2.0
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 Technical Reference Guide

iDX Release 2.0
 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:

Technical Reference Guide 85

iDX Release 2.0
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 re-
established 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 Technical Reference Guide

iDX Release 2.0
 Operational Scenarios

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.

Technical Reference Guide 87

iDX Release 2.0
Operational Scenarios

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 Technical Reference Guide

iDX Release 2.0
 Operational Scenarios

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.

Technical Reference Guide 89

iDX Release 2.0
Operational Scenarios

90 Technical Reference Guide

iDX Release 2.0
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.

Technical Reference Guide 91

iDX Release 2.0
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 Technical Reference Guide

iDX Release 2.0
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.

Technical Reference Guide 93

iDX Release 2.0
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 Technical Reference Guide

iDX Release 2.0
 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.

Technical Reference Guide 95

iDX Release 2.0
Decreasing Channel Spacing to Gain Additional Bandwidth

Figure 42. Adding an Upstream Carrier By Reducing Carrier Spacing

96 Technical Reference Guide

iDX Release 2.0
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.

Technical Reference Guide 97

iDX Release 2.0
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 = <timeout>
where <timeout> 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 Technical Reference Guide

iDX Release 2.0
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.

Technical Reference Guide 99

iDX Release 2.0
License Files

100 Technical Reference Guide

iDX Release 2.0
19 Hub Line Card Failover

This chapter describes basic hub line card failover concepts, transmit/receive verses receive-
only 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 frequency-
hopping 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

Technical Reference Guide 101

iDX Release 2.0
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 Technical Reference Guide

iDX Release 2.0
 Failover Sequence of Events

Event Server
determines line
card has failed

Configuration
Server is notified

iMonitor will show the line

Automatic card in the Alarm state
.
failover NO DONE. User may initiate manual
selected ? failover if desired
.

YES

User will have already

User initiates been notified that failover
Prerequisites Met ? NO DONE. cannot happen .
manual failover

YES

Configuration All subsequent operations are

Server powers handled by the Configuration
down slot of failed Server unless otherwise noted
card .

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

Apply necessary
changes to puma
serial
( number )

Configuration Server must

Former spare gets grab exclusive write lock at
role of failed card this point. Any user with the
Tx( TxRx
, or
, Rx ) lock will lose the lock and
and carrier inroute
/ any unsaved changes .
group assignments

Failed unit gets

new role :Failed .

Figure 43. Line Card Failover Sequence of Events

Technical Reference Guide 103

iDX Release 2.0