Technical Reference Guide iDX Release 3.0

Technical Reference Guide
iDX Release 3.0
June 07, 2011
Copyright 2011 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 3.0_Rev A_06072011.pdf

Document Part Number: T0000353
ii

iDX Release 3.0
Revision History
The following table shows all revisions for this document. If you do not have the latest
revision for your release, or you are not sure, please check the TAC webpage at:
http://tac.idirect.net.
Revision
Date Released
Reason for Change(s)
Who Updated?
06/07/2011
First release of document for iDX 3.0
JVespoli

iDX Release 3.0
iii
Contents
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x
List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
About This Guide
Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Intended Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Contents Of This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
Related Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
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
iv

iDX Release 3.0
3 Modulation Modes and FEC Rates

iDirect Modulation Modes And FEC Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
TPC Modulation Modes and FEC Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
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
Supported Forward Error Correction (FEC) Rates . . . . . . . . . . . . . . . . . . . . . 27
iDirect iNFINITI Downstream Specifications . . . . . . . . . . . . . . . . . . . . . . . . . 27
TDMA Upstream Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
SCPC Upstream Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5 Multichannel Line Cards

Multichannel Line Card Model Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Multichannel Line Card Receive Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Multichannel Line Card Restrictions and Limits . . . . . . . . . . . . . . . . . . . . . . . 30
6 SCPC Return Channels

Hardware Support and License Requirements. . . . . . . . . . . . . . . . . . . . . . . . 33
Single Channel vs. Multichannel SCPC Return . . . . . . . . . . . . . . . . . . . . . . . . 34
SCPC Return Feature on Remotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
VNO for SCPC Return. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7 Multicast Fast Path

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Multicast Fast Path Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8 QoS Implementation Principles

Quality of Service (QoS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
QoS Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
iDirect QoS Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Classification and Scheduling of IP Packets. . . . . . . . . . . . . . . . . . . . . . . . . . 42

iDX Release 3.0
Service Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Packet Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Application Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Minimum Information Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Committed Information Rate (CIR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Maximum Information Rate (MIR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Free Slot Allocation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Compressed Real-Time Protocol (cRTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Sticky CIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Application Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Packet Segmentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Application Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Maximum Channel Efficiency vs. Minimum Latency . . . . . . . . . . . . . . . . . . . . 48
Group QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Group QoS Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Group QoS Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
9 Configuring Transmit Initial Power

What is TX Initial Power? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
How To Determine The Correct TX Initial Power . . . . . . . . . . . . . . . . . . . . . . 65
All Remotes Need To Transmit Bursts in the Same C/N Range . . . . . . . . . . . . . 66
What Happens When TX Initial Power Is Set Incorrectly? . . . . . . . . . . . . . . . . 67
When TX Initial Power is Too High . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
When TX Initial Power is Too Low . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
10 Global NMS Architecture

How the Global NMS Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Sample Global NMS Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
11 Hub Network Security Recommendations

Limited Remote Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Root Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
12 Global Protocol Processor Architecture

Remote Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
vi

iDX Release 3.0
De-coupling of NMS and Data Path Components . . . . . . . . . . . . . . . . . . . . . . 73
13 Distributed NMS Server

Distributed NMS Server Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
iBuilder and iMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
14 Transmission Security (TRANSEC)

What is TRANSEC? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
iDirect TRANSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
TRANSEC Key types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
DVB-S2 Downstream TRANSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Upstream TRANSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Disguising Remote Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Generating the TDMA Initialization Vector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Upstream TRANSEC Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
ACQ Burst Obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

TRANSEC Dynamic Key Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
TRANSEC Remote Admission Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
ACC Key Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
ACC Key Roll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Manual ACC Key Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Automatic Beam Selection (ABS) and TRANSEC . . . . . . . . . . . . . . . . . . . . . . . 89
15 Fast Acquisition
Feature Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
16 Remote Sleep Mode

Awakening Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Operator-Commanded Awakening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Activity Related Awakening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Enabling Remote Sleep Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Power Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

iDX Release 3.0
vii
17 Automatic Beam Selection

Automatic Beam Selection Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Theory of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
The Map Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Beam Characteristics: Visibility and Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Selecting a Beam without a Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Controlling the Antenna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
IP Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Calculation of Initial Transmit Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Receive-Only Mode for ABS Remotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Multiple Map Servers per Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Operational Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Creating the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Adding a Remote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Normal Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Mapless Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Blockages and Beam Outages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Error Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
18 Hub Geographic Redundancy

Configuring Wait Time Interval for an Out-of-Network Remote . . . . . . . . . . . . 108
19 Carrier Bandwidth Optimization

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Increasing User Data Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Decreasing Channel Spacing to Gain Additional Bandwidth . . . . . . . . . . . . . . . 111
20 Alternate Downstream Carrier

Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
21 Feature and Chassis Licensing

iDirect Licensing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
viii

iDX Release 3.0
22 Hub Line Card Failover

Basic Failover Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Warm Standby versus Cold Standby Line Card Failover . . . . . . . . . . . . . . . . . 117
Failover Sequence of Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

iDX Release 3.0
ix
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 iNFINITI, 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 Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Figure 15. iDirect Packet Scheduling Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figure 16. Group QoS Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figure 17. Physical Segregation Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Figure 18. CIR Per Application Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figure 19. Tiered Service Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figure 20. Third Level VLAN Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figure 21. Shared Remote Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figure 22. Remote Service Group Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Figure 23. Scaled Aggregate CIRs Below Partitions CIR . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figure 24. Scaled Aggregate CIRs Exceed Partitions CIR . . . . . . . . . . . . . . . . . . . . . . . . 62
Figure 25. Bandwidth Allocation Fairness Relative to CIR . . . . . . . . . . . . . . . . . . . . . . . . 63
Figure 26. Bandwidth Allocation Fairness Relative to MODCOD . . . . . . . . . . . . . . . . . . . . 64
Figure 27. C/N Nominal Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Figure 28. TX Initial Power Too High . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Figure 29. TX Initial Power Too Low . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Figure 30. Global NMS Database Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Figure 31. Sample Global NMS Network Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Figure 32. Protocol Processor Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Figure 33. Sample Distributed NMS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Figure 34. DVB-S2 TRANSEC Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Figure 35. Disguising Which Key is Used for a Burst . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Figure 36. Code Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Figure 37. Generating the Upstream Initialization Vector . . . . . . . . . . . . . . . . . . . . . . . . 83
Figure 38. Upstream ACQ Burst Obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

iDX Release 3.0
Figure 39. Key Distribution Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Figure 40. Key Roll Data Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Figure 41. Host Keying Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Figure 42. Overlay of Carrier Spectrums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Figure 43. Adding an Upstream Carrier By Reducing Carrier Spacing . . . . . . . . . . . . . . . . 112
Figure 44. Line Card Failover Sequence of Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

iDX Release 3.0
xi
List of Tables
Table 1. DVB-S2 Modulation and Coding Schemes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Table 2. ACM MODCOD Scaling Factors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Table 3. TPC Modulation Modes and FEC Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Table 4. Modulation Modes and FEC Rates for 2D 16-State Inbound Coding over TDMA . . . . . 23
Table 5. Modulation Modes and FEC Rates for 2D 16-State Inbound Coding over SCPC . . . . . . 24
Table 6. Block Sizes and IP Payload Sizes for 2D 16-State Inbound Coding . . . . . . . . . . . . . 24
Table 7. Spread Spectrum: Downstream Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Table 8. Spread Spectrum: TDMA Upstream Specifications . . . . . . . . . . . . . . . . . . . . . . . 28
Table 9. Spread Spectrum: SCPC Upstream Specifications . . . . . . . . . . . . . . . . . . . . . . . . 28
Table 10. Multichannel Receive Line Card Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Table 11. Single Channel vs. Multichannel SCPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Table 12. Power Consumption: Normal Operations vs. Remote Sleep Mode. . . . . . . . . . . . . 95
xii

iDX Release 3.0
About This Guide
Purpose
The Technical Reference Guide provides detailed technical information on iDirect technology
and major features as implemented in iDX Release 3.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 3.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

iDX Release 3.0
xiii
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 youll know how to interpret the
information presented.
Convention Description
Blue
Courier
font
Used when the user is

required to enter a
command at a command
line prompt or in a console.
Enter the command:
Courier
font
Used when showing

resulting output from a
command that was entered
at a command line or on a
console.
crc report all
Bold
Trebuchet
font
Used when referring to text

that appears on the screen
on a windows-type
Graphical User Interface
(GUI).
1. If you are adding a remote to an Inroute Group,

right-click the Inroute Group and select Add
Remote.
Used when specifying

names of commands,
menus, folders, tabs,
dialogs, list boxes, and
options.
xiv
Example
cd /etc/snmp/
3100.3235 : DATA CRC [

1]
3100.3502 : DATA CRC [5818]
3100.4382 : DATA CRC [ 20]
The Remote dialog box has a number of userselectable tabs across the top. The Information tab is
visible when the dialog box opens.
Blue
Trebuchet
font
Used to show all

hyperlinked text within a
document.
Refer to Quality of Service in DVB-S2 ACM Networks

on page15 for a detailed description of ACM operation
with EIR enabled.
Bold italic
Trebuchet
font
Used to emphasize
information for the user,
such as in notes.
Note:
Red italic
Trebuchet
font
Used when the user needs

to strictly follow the
instructions or have
additional knowledge about
a procedure or action.
It is important to set TX Initial Power on a

remote modem correctly to ensure optimal
Upstream channel performance.
WARNING! The following procedure may cause

a network outage.

iDX Release 3.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 iDirects 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: SALES@iDirect.net
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 techpubs@idirect.net.

iDX Release 3.0
xv
xvi

iDX Release 3.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 sites. Each remote transmits to the hub either on a shared
Deterministic-TDMA (D-TDMA) upstream channel with dynamic timeplan slot assignments or
on a dedicated SCPC return channel. A sample iDirect network is shown in Figure 1.
Satellite
Shared Downstream
Inroute Group 1
...
40 Mbps
iDirect Hub
Infrastructure
12 x 512 kbps
Inroute Group 2
SCPC Return Channels
...
10 x 256 kbps
800 Remotes
400 Remotes
Remote
Infrastructure
Remote
Infrastructure
512 kbps
1 Mbps
256 kbps
Remote
Infrastructure
Figure 1. Sample iDirect Network

iDX Release 3.0
System Overview
The iDirect Hub equipment consists of one or more iDirect Hub Chassis with Universal Line
Cards, one or more Protocol Processors (PP), a Network Management System (NMS) and the
appropriate RF equipment. Each remote site consists of an iDirect broadband router and the
appropriate external VSAT equipment.
The selection of an upstream TDMA 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
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 or IGMPv3
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.

iDX Release 3.0
IP Network Architecture
The following figures illustrate the basic iDirect IP network architectures.
Figure2, iDirect IP Architecture Multiple VLANs per Remote
Figure3, iDirect IP Architecture VLAN Spanning Remotes
Figure4, iDirect IP Architecture Classic IP Configuration
Figure 2. iDirect IP Architecture Multiple VLANs per Remote

iDX Release 3.0
Figure 3. iDirect IP Architecture VLAN Spanning Remotes

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

iDX Release 3.0

iDX Release 3.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.
Note:
Beginning with iDX Release 2.2, the iDirect TRANSEC feature is supported in
DVB-S2 networks. See Transmission Security (TRANSEC) on page77 for
details.
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 page8. 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.

iDX Release 3.0
DVB-S2 Key Concepts
Table 1. DVB-S2 Modulation and Coding Schemes

#
Modulation
Code
Notes
QPSK
1/4
ACM or CCM
1/3
2/5
1/2
3/5
2/3
3/4
4/5
5/6
10
8/9
11
9/10
CCM only
3/5
ACM or CCM
12
8PSK
13
2/3
14
3/4
15
5/6
16
8/9
17
9/10
CCM only
2/3
ACM or CCM
18
16APSK
19
3/4
20
4/5
21
5/6
22
8/9
23
9/10
CCM only
DVB-S2 defines three methods of applying modulation and coding to a data stream:
CCM (Constant Coding and Modulation) specifies that every BBFRAME is transmitted at the
same MODCOD. Effectively, an iDirect network transmitting an iNFINITI downstream
carrier is a CCM system.
Note:
CCM using long frames is not supported on iDirect DVB-S2 outbound carriers.
However, you can simulate a CCM outbound carrier using short frames by
selecting ACM and setting the Maximum and Minimum MODCODs to the same
value. 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.

iDX Release 3.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 iDirects iNFINITI Mode, CCM Mode and ACM Mode.
iNFINITI Mode:
All Frames: single Modulation (QPSK or BPSK)
All Frames: single coding (TPC 0.793, etc. )
QPSK
TPC .66
QPSK
TPC .66
...
time
DVBS2: CCM Mode:

All BB Frames: single MODCOD (one of QPSK, , 16PSK 9/10)
8PSK
9/10
8PSK
9/10
8PSK
9/10
8PSK
9/10
...
time
DVBS2: ACM Mode:

Each BB Frame: potentially different MODCOD (any of QPSK1/4, , 16PSK 9/10 )
16P
5/6
16P
4/5
8PSK
2/3
16P
4/5
QPSK
2/3
8PSK
8/9
8PSK
8/9
16P
8/9
8PSK
3/4
time
Figure 5. Comparison of iNFINITI, 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 BBFRAMES for ACM. iDirect does not
support VCM on the downstream carrier.
iDX Release 3.0 supports the following hardware in DVB-S2 networks:
Evolution eM1D1 line card (Tx/Rx; Rx-only for SCPC return channel)
Evolution XLC-11 line card (Tx/Rx)
Evolution XLC-10 line card (Tx-only)
Evolution eM0DM line card (Rx-only; single or multiple inbound channels; TDMA or SCPC
return channel)
Evolution XLC-M line card (Rx-only; single or multiple inbound channels; TDMA or SCPC
return channel)
Evolution e8350 remote satellite router (TDMA or SCPC return channel)
Evolution iConnex e800/e850mp remote satellite routers (TDMA or SCPC return channel)
Evolution X3 remote satellite router (TDMA or SCPC return channel)
Evolution X5 remote satellite router (TDMA or SCPC return channel)
Evolution eP100 remote satellite router (TDMA return channel only)

iDX Release 3.0
DVB-S2 in iDirect
The eM1D1 line card and the XLC-11 line card are Tx/Rx line cards. Both line cards can
transmit either an iDirect iNFINITI or a DVB-S2 downstream carrier while receiving a TDMA
upstream carrier. The eM1D1 can also receive an SCPC return channel but it must be
configured as Rx-only to do so. An XLC-10 line card is a Tx-only line card that can only be
deployed in DVB-S2 networks.
An eM0DM or XLC-M line card is a multi-channel, Rx-only line card that can be deployed in
either DVB-S2 or iNFINITI networks. However, in iNFINITI networks these line cards can only
receive a single TDMA upstream carrier. In DVB-S2 networks, an eM0DM or XLC-M line card can
receive either TDMA or SCPC return channels. However, it cannot receive both upstream
carrier types at the same time.
An Evolution e8350, e800, e850 or X5 remote satellite router can receive either an iNFINITI or
a DVB-S2 downstream carrier while transmitting on a TDMA upstream carrier. In DVB-S2
networks, an e8350, e800, e850, X3 or X5 can also be configured to transmit an SCPC return
carrier. An Evolution X3 remote satellite router can only operate in a DVB-S2 network and can
only transmit a TDMA upstream carrier.
The Evolution eP100 is a custom form-factor remote satellite router that is not generally
available for purchase. It can only receive a DVB-S2 downstream carrier and it can only
transmit a TDMA upstream carrier.
DVB-S2 Downstream
An iDirect iNFINITI downstream carrier is effectively CCM. At configuration time, a modulation
(such as BPSK) and coding rate (such as TPC 0.79) are selected. These characteristics of the
downstream are fixed for the duration of the operation of the network.
A DVB-S2 downstream can be configured as CCM (future) or ACM. If you configure the
downstream as ACM, it is not constrained to operate at a fixed modulation and coding.
Instead, the modulation and coding of the downstream varies within a configurable range of
MODCODs.
An iDirect DVB-S2 downstream contains a continuous stream of Physical Layer Frames
(PLFRAMEs). The PLHEADER indicates the type of modulation and error correction coding used
on the subsequent data. It also indicates the data format and frame length. Refer to Figure 6.
PLHEADER: signals
MODCOD and frame
length (always /2 BPSK)
Pilot symbols:
unmodulated
carrier
Data symbols:
QPSK, 8PSK,
16APSK, or 32APSK
Figure 6. Physical Layer Frames

The PLHEADER always uses /2 BPSK modulation. Like most DVB-S2 systems, iDirect injects
pilot symbols within the data stream. The overhead of the DVB-S2 downstream varies
between 2.65% and 3.85%.
The symbol rate remains fixed on the DVB-S2 downstream. Variation in throughput is realized
through DVB-S2 support, and the variation of MODCODs in ACM Mode. The maximum possible
throughput of the DVB-S2 carrier (calculated at 45 MSps and highest MODCOD 16APSK 8/9) is
10

iDX Release 3.0
DVB-S2 in iDirect
approximately 155 Mbps. As with iDirect iNFINITI 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.
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 carriers minimum
MODCOD and the remotes 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.

iDX Release 3.0
11
DVB-S2 in iDirect
Figure 7. SNR Threshold vs. MODCOD for Evolution X3 and X5 Remotes
12

iDX Release 3.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 page14. 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.

iDX Release 3.0
13
DVB-S2 in iDirect
Figure 9 and Figure 10 show the operation of the SNR feedback loop and the behavior of the
line card and remote during fast fade conditions. Figure 9 shows the basic SNR reporting loop
described above. The example shows an XLC-10 line card transmitting to an X3 remote.
However, the feedback loop discussion applies to any Evolution line card that is transmitting a
DVB-S2 carrier to any Evolution remote.
Figure 9. Feedback Loop from Remote to Protocol Processor

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

iDX Release 3.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 iNFINITI
downstream carriers. (See QoS Implementation Principles on page39.) However, with DVBS2 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

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
remotes Nominal MODCOD is equal to the DVB-S2 carriers 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 Remotes 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

You can also configure a Maximum MODCOD for DVB-S2 remotes operating in ACM mode. By
default, a remotes Maximum MODCOD is equal to the DVB-S2 carriers Maximum MODOCD.
iBuilder allows you to limit the Maximum MODCOD for a remote to a value lower than the DVBS2 carriers Maximum MODCOD and higher than or equal to the remotes 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 remotes Maximum MODCOD is not the same as a remotes Nominal MODCOD. The
remote is allowed to operate above its Nominal MODCOD as long as it does not exceed the
remotes Maximum MODCOD. A remote is never allowed to operate above its Maximum
MODCOD.

iDX Release 3.0
15
DVB-S2 in iDirect
Fixed Bandwidth Operation

During a rain fade, the CIR or MIR granted to a remote are scaled down based on the remotes
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 remotes
Nominal MODCOD is labeled Nominal @ ClearSky in the figure. In the example the remote
has been configured with 256 kbps of CIR and a Nominal MODCOD of 8PSK 3/5. If the remote
operates at a higher MODCOD, it is not granted a higher CIR. When the remote enters a rain
fade, the allocated bandwidth remains fixed at the Nominal MODCOD bandwidth. The
degradation in throughput is gradual because the remote continues to use the same amount of
satellite bandwidth that was allocated for its Nominal MODCOD.
Fixed Bandwidth
400
600
300
CIR
400
300
200
250
Nominal
@ ClearSky
200
150
100
100
0
Relative Bandwidth
350
500
50
0
Figure 11. Total Bandwidth vs. Information Rate in Fixed Bandwidth Operation
Enhanced Information Rate

As noted above, the occupied bandwidth for CIR or MIR varies per MODCOD. If, when
allocating downstream bandwidth for a remote, the system always attempted to meet these
rates regardless of MODCOD, then a remote in a deep rain fade may be granted a
disproportionate share of bandwidth at the expense of other remotes in the network. On the
other hand, if CIR and MIR settings were only honored at the remotes 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 Service Groups or 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

iDX Release 3.0
DVB-S2 in iDirect
EIR is only enabled in the range of MODCODs from the remotes 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 remotes 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
remotes 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 remotes 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 remotes Nominal
MODCOD.
EIR Mode
600
400
300
CIR
400
300
200
250
Nominal
EIR Min
200
150
100
100
0
Relative Bandwidth
350
500
50
0
Figure 12. EIR: Total Bandwidth vs. Information Rate as MODCOD Varies

iDX Release 3.0
17
DVB-S2 in iDirect
Scaling Factors for Fixed Bandwidth Allocation

Table 2 shows the scaling factors that can be used to calculate the information rate at
different MODCODs when the allocated bandwidth is held constant at the remotes Nominal
MODCOD. This happens both in Fixed Bandwidth Mode or in EIR Mode when the remotes
MODCOD falls below the EIR Minimum MODCOD.
Table 2. ACM MODCOD Scaling Factors
MODCOD
Scaling
Factor
Comments
16APSK 8/9
1.2382
Best MODCOD
16APSK 5/6
1.3415
16APSK 4/5
1.4206
16APSK 3/4
1.5096
16APSK 2/3
1.6661
8PSK 8/9
1.6456
8PSK 5/6
1.7830
8PSK 3/4
2.0063
8PSK 2/3
2.2143
8PSK 3/5
2.4705
QPSK 8/9
2.4605
QPSK 5/6
2.6659
QPSK 4/5
2.8230
QPSK 3/4
2.9998
QPSK 2/3
3.3109
QPSK 3/5
3.6939
QPSK 1/2
5.0596
QPSK 2/5
5.6572
QPSK 1/3
6.8752
QPSK 1/4
12.0749
Worst MODCOD
The following formula can be used to determine the information rate at which data is sent
when that data is scaled to the remotes Nominal MODCOD:
IRa = IRn x Sb / Sa
where:
IRa is the actual information rate at which the data is sent
IRn is the nominal information rate (for example, the configured CIR)
18
Sb is the scaling factor for the remotes Nominal MODCOD
Sa is the scaling factor for the MODCOD at which the data is sent

iDX Release 3.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 page60 and page62.
Note:
When bandwidth is allocated for a remote, the CIR and MIR are scaled to the
remotes Nominal MODCOD. At higher levels of the Group QoS tree (Bandwidth
Group, Service Group, etc.) CIR and MIR are scaled to the networks best
MODCOD.)
Bandwidth Allocation Fairness

There are two configurable options for bandwidth allocation fairness:
Allocation Fairness Relative To CIR
Allocation Fairness Relative to MODCOD
Enabling or disabling either or both of these options for your Group QoS nodes or for your
physical remotes affects how CIR and MIR bandwidth is apportioned during bandwidth
contention. Allocation Fairness Relative to MODCOD only affects bandwidth allocation on DVBS2 ACM outbound carriers. Allocation Fairness Relative to CIR affects bandwidth allocation in
general.
For a detailed explanation of these options, see the Quality of Service chapter in the iBuilder
User Guide. For sample scenarios illustrating the use of these options, see Bandwidth
Allocation Fairness Relative to CIR on page63 and Bandwidth Allocation Fairness Relative
to MODCOD on page64.
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, iBuilder provides a MODCOD Distribution Calculator that allows you to estimate
the overall Information 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.

iDX Release 3.0
19
DVB-S2 in iDirect
Multicast MODCOD: By default, all multicast data on an ACM downstream carrier is

transmitted at the lowest MODCOD of the carrier. You can configure different MODCODs
for your user multicast traffic by selecting Multicast MODCODs for your Multicast
Applications in iBuilder. See the Quality of Service chapter of the iBuilder User Guide for
details.
Remote Nominal MODCOD and Remote Maximum MODCOD. These remote parameters are
discussed in detail at the beginning of this section. You can configure these parameters on
the Remote QoS tab in iBuilder.
DVB-S2 Line Card Definition: When you add a DVB-S2 line card, you must configure a
second IP port (called the GIG0 port) in addition to the management IP port. All data to
be transmitted on the DVB-S2 downstream carrier is sent to this port.
DVB-S2 Network-Level Parameters: iBuilder allows you to configure the network-level

parameters that control how a DVB-S2 network behaves when ACM is enabled for your
downstream carrier. These parameters affect the behavior of the system during remote
fade conditions.
DVB-S2 Performance Monitoring

iMonitor allows you to monitor the following characteristics of your DVB-S2 outbound carriers:
ACM Gain represents the increase in performance achieved on a DVB-S2 outbound carrier
when the MODCOD used to transmit data is higher than the minimum MODCOD configured
for the carrier. ACM Gain can be monitored at the Network, Inroute Group, Remote and Tx
Line card levels of the iMonitor tree.
You can examine how the downstream data is distributed across the range of MODCODs
configured for an ACM carrier. MODCOD distribution can be monitored at the Network,
Remote and Tx Line Card levels of the iMonitor tree.
In an ACM network, each DVB-S2 remote periodically reports its current Signal-to-Noise
Ratio (SNR) to the protocol processor. Based on the remotes 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.
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 remotes actual operating point with its configured (or contractual)
operating point and make adjustments to your network in the case of discrepancies.
For details, see the iMonitor User Guide.
20

iDX Release 3.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 3.0.
iDirect Modulation Modes And FEC Rates

iDX Release 3.0 supports star networks with DVB-S2 or iDirect iNFINITI downstream carriers.
Remotes transmit to the hub on either TDMA upstream carriers or SCPC return channels. The
tables in this chapter show the modulation modes and FEC rates supported on iDirect
downstream and upstream carriers.
iNFINITI hardware can only be deployed in networks that transmit iDirect iNFINITI downstream
carriers. iNFINITI hardware cannot be used in DVB-S2 networks. Only TDMA upstream carriers
can be used in networks that transmit iDirect iNFINITI downstream carriers. SCPC return
channels can only be used in DVB-S2 networks.
Only Evolution hardware can transmit or receive DVB-S2 downstream carriers. In addition, a
multichannel line card can only be used to receive multiple upstream channels when deployed
in a DVB-S2 network.
Some Evolution line cards are also capable of transmitting an iDirect iNFINITI downstream
carrier and some Evolution remotes are capable of receiving an iNFINITI downstream carrier.
The types of downstream and upstream carriers that a specific Evolution line card or remote
can transmit and receive depends on the model type of the hardware and on the type of
network (DVB-S2 or iNFINITI) in which the hardware is deployed. In some cases it also depends
on licensing. Please see the iBuilder User Guide for further details.
TPC Modulation Modes and FEC Rates on page22 specifies the upstream and downstream
Modulation Modes and FEC Rates available when using Turbo Product Code (TPC) Error
Correction used in iNFINITI networks. In DVB-S2 networks, iDirect only supports 2D 16-State
Inbound Coding on upstream carriers. 2D 16-State Inbound Coding for DVB-S2 Networks on
page23 specifies the Modulation Modes and FEC rates available when using 2D 16-State
Inbound Coding.
TPC Error Correction is no longer supported on upstream carriers in DVB-S2 networks. In this
release, 2D 16-State Inbound Coding must be selected for your upstream carriers if you are
using a DVB-S2 downstream.
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.

iDX Release 3.0
21
TPC Modulation Modes and FEC Rates
TPC Modulation Modes and FEC Rates

Table 3 on page 22 shows the Modulation Modes and FEC Rates available for downstream
carriers and TDMA upstream carriers when using TPC Error Correction. SCPC return channels
can only use 2D 16-State coding; they cannot use TPC Error Correction.
Note:
Beginning with iDX Release 3.0, TPC Error Correction is no longer supported on
upstream carriers in DVB-S2 networks. 2D 16-State Inbound Coding must be
selected for your upstream carriers if you are using a DVB-S2 downstream.
Table 3. TPC Modulation Modes and FEC Rates
Hardware Support
DVB-S2
Downstream
Modulation and Coding
Tx
Rx
eM1D1, XLC-10, XLC-11
e8350, e800/e850mp,
X5, X3, eP100
Spread
Spectrum
X
Hardware Support
Star Networks
iNFINITI
Downstream
FEC
.533
.495
.793
.879
Modulation Mode
Rx
Spread
Spectrum
BPSK
BPSK
QPSK
8PSK
Block
Size
Payload
Bytes
eM1D1, XLC-11, M1D1
iNFINITI
Yes
Yes
1K
53
eM1D1, XLC-11, M1D1
iNFINITI, e8350,
e800/e850mp, X5
iNFINITI, e8350,
e800/e850mp, X5
iNFINITI, e8350,
e800/e850mp, X5
Yes
Yes
Yes
4K
251
Yes
Yes
Yes
Yes
4K
404
Yes
Yes
Yes
Yes
16K
1800
Tx
eM1D1, XLC-11, M1D1

eM1D1, XLC-11, M1D1
Hardware Support
TDMA
Upstream
FEC
.431
.533
.660
.793
QPSK, 8PSK, 16APSK

ACM or CCM
Modulation Mode
Tx
Rx
iNFINITI, e8350,
e800/e850mp, X5
iNFINITI, e8350,
e800/e850mp, X5
iNFINITI, e8350,
e800/e850mp, X5
iNFINITI, e8350
e800/e850mp, X5
MxD1, eM1D1,XLC-11,
eM0DM (SC mode)
MxD1, eM1D1, XLC-11,
eM0DM (SC mode)
eM0DM (SC mode)
eM0DM (SC mode)
Spread
Spectrum
BPSK
BPSK
QPSK
8PSK
Block
Size
Payload
Bytes
Yes
Yes
1K
43
Yes
Yes
Yes
1K
56
Yes
Yes
Yes
Yes
1K
72
Yes
Yes
Yes
4K
394
See the DVB-S2 chapter for supported MODCODs and block sizes.
iNFINITI channel framing uses a modified HDLC header, which requires bit-stuffing to prevent false end-of-frame detection. The
actual payload is variable, and always slightly less than the numbers indicated in the table.
The TDMA Payload Bytes value removes the TDMA header overhead of 10 bytes: Demand=2 + LL=6 + PAD=2. SAR, Encryption,
and VLAN features add additional overhead.
This FEC combination is not recommended for new designs. For new network designs, iDirect recommends using FEC 0.495. If
you have an existing network using FEC 0.533 operating at an information rate of 10 Msps or greater, the network may experience
errors due to an FEC decoding limitation.
Spread Spectrum: eM1D1, XLC-11, M1D1-TSS and e8350, iConnex e800/e850mp, X5, 8350 only
TDMA 8PSK Rate 0.793 requires Evolution Hub Line Card to receive the upstream carrier
Note:
22
For the list of supported DVB-S2 downstream MODCODs, see Table 1 on page 8.

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

iDirect supports 2D 16-State Inbound Coding on upstream TDMA and SCPC 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
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 Link Budget Analysis
Guide.
Table 4 shows the upstream Modulation and Coding rates available per payload size when
using 2D 16-State Inbound Coding over TDMA. Table 5 shows the upstream Modulation and
Coding rates available per payload size when using 2D 16-State Inbound Coding on an SCPC
return channel. Table 6 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 Link Budget Analysis Guide for this release.
Table 4. Modulation Modes and FEC Rates for 2D 16-State Inbound Coding over TDMA

iDX Release 3.0
23
Table 5. Modulation Modes and FEC Rates for 2D 16-State Inbound Coding over SCPC
Table 6. Block Sizes and IP Payload Sizes for 2D 16-State Inbound Coding
24

iDX Release 3.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 page25
iDirect iNFINITI Downstream Specifications on page27
TDMA Upstream Specifications on page28
What is Spread Spectrum?

Spread Spectrum 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 Spread Spectrum 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 on TDMA and SCPC upstream carriers and on
iDirect SCPC downstream carriers. Spread spectrum is not available on DVB-S2 downstream
carriers. Spread Spectrum is employed in iDirect networks to minimize adjacent satellite

iDX Release 3.0
25
What is Spread Spectrum?
interference (ASI). ASI can occur in applications such as Comms-On-The-Move (COTM) because
the small antennas (typically sub-meter) used on mobile vehicles have a small aperture size,
large beam width, and high pointing error which can combine to cause ASI. Enabling Spread
Spectrum reduces the spectral density of the transmission so that it is low enough to avoid
interfering with adjacent satellites. When receiving through a COTM antenna, Spread
Spectrum improves carrier performance in cases of ASI (channel/interference).
iDirect Spread Spectrum 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. For an iNFINITI downstream carrier or for an SCPC upstream carrier, you can
select No Spreading, 2, 4 or 8. You can select a TDMA upstream Spreading Factor of No
Spreading, 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 Evolution X5 and eP100 remotes; 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. The spread rate is the rate at which
chips are transmitted. For example, selecting No Spreading means that the spread rate is one
chip per symbol (which is equivalent to regular BPSK). Selecting a Spreading Factor of 4
means that the spread rate is four chips per symbol.
An additional Spreading Factor, COTM SF=1, can be selected for upstream TDMA carriers only.
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 ten 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, Spread Spectrum should not be confused with Code Division Multiple Access (CDMA),
which is the process of transmitting multiple Spread Spectrum 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 Spread Spectrum 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

iDX Release 3.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 and eP100 support upstream Spread
Spectrum if Spread Spectrum is licensed on the remote. Other remotes do not currently
support spread spectrum.
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 page21.
iDirect iNFINITI Downstream Specifications

The Spread Spectrum specifications for an iDirect iNFINITI downstream carrier are outlined in
Table 7.
Table 7. Spread Spectrum: Downstream Specifications
PARAMETERS
VALUES
ADDITIONAL INFORMATION
Modulation
BPSK
Other Modulations not supported
Spreading Factor
No Spreading, 2, 4, 8
SF=8 requires Evolution hardware
Symbol Rate
64 ksym/s - 15 Msym/s
Chip Rate
15 Mchip/s maximum
BER Performance
Refer to the iDirect Link Budget Analysis

Guide
Occupied BW
1.2 * Chip Rate
Spectral Mask
IESS-308/309, MIL-STD 188xxx
Carrier Suppression
> -30 dBc
Hardware Platforms
M1D1-TSS HLC; Evolution eM1D1, XLC-11

iDX Release 3.0
Plus hub downcoverter oscillator

stability factor
27
TDMA Upstream Specifications
TDMA Upstream Specifications

The specifications for the spread spectrum upstream channel are outlined in Table 8. The
Spreading Factor COTM 1, used in fast moving mobile applications, is described on page26.
Table 8. Spread Spectrum: TDMA Upstream Specifications
PARAMETERS
VALUES
Modulation
BPSK
Spreading Factor
No Spreading, COTM SF=1, 2, 4, 8 or 16
SF8 and 16 require Evolution hardware
Symbol Rate
64 ksym/s - 7.5 Msym/s
Chip Rate
7.5 Mchip maximum
BER Performance

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,

iConnex e800/e850mp, X5, eP100
SCPC Upstream Specifications

The Spread Spectrum specifications for an SCPC upstream carrier are outlined in Table 7.
Table 9. Spread Spectrum: SCPC Upstream Specifications
PARAMETERS
VALUES
Modulation
BPSK
Spreading Factor
No Spreading, 2, 4, 8
Symbol Rate
128 ksym/s - 15 Msym/s
Chip Rate
15 Mchip/s maximum
BER Performance

Guide
Occupied BW
1.2 * Chip Rate
Hardware Platforms
Evolution e8350, iConnex e800/e850mp,

Evolution X5
28
Evolution X5 requires licenses for

spread spectrum and SCPC return

iDX Release 3.0
5 Multichannel Line Cards
Introduced in iDX Release 3.0, Multichannel Line Cards are receive-only Evolution line cards
capable of receiving up to eight upstream carriers simultaneously. A Multichannel Line Card
can receive either TDMA upstream carriers or SCPC return channels with appropriate
licensing.
Multichannel Line Card Model Types

There are two iDirect Multichannel Line Card model types:
Evolution XLC-M
Evolution eM0DM
Note:
You must allow for 60 Watts of power for each Multichannel Line Card in a 20
slot chassis. Total available power for each 20 slot chassis model type is
specified in the Series 15100 Universal Satellite Hub (5IF/20-Slot) Installation
and Safety Manual.
Multichannel Line Card Receive Modes

When you configure a Multichannel Line Card in iBuilder, you must select one of the following
receive modes for the line card:
Single Channel TDMA
Multiple Channel TDMA
Multiple Channel SCPC
Note:
Single Channel SCPC Mode is only available for Evolution eM1D1 line cards.
Note:
Both the XLC-M and eM0DM line cards were available in earlier releases with
single channel TDMA support only. If you have deployed these model types in
your networks, they will automatically be set to Single Channel TDMA receive
mode when you upgrade from a pre-iDX 3.0 release.

iDX Release 3.0
29
Multichannel Line Card Restrictions and Limits

The following restrictions apply to Multichannel Line Cards:
All upstream carriers received by an Evolution XLC-M or eM0DM line card must be the
same carrier type. You cannot configure a Multichannel Line Card to receive both SCPC
and TDMA carriers at the same time.
All TDMA upstream carriers received by a Multichannel Line Card must be in the same
Inroute Group.
An Inroute Group can contain a maximum of 16 TDMA upstream carriers.
All TDMA upstream carriers received by a Multichannel Line Card must have the same
Modulation, FEC Rate, and Symbol Rate.
SCPC upstream carriers received by a Multichannel Line Card can have different
Modulations, FEC Rates, and Symbol Rates.
All TDMA upstream carriers received by a Multichannel Line Card must be on the same
transponder.
Multiple Channel TDMA, Multiple Channel SCPC, and Single Channel SCPC modes are only
supported in DVB-S2 networks. Since DVB-S2 networks require 2D 16-State Inbound
Coding, the upstream carriers cannot be configure to use TPC coding when any of these
modes are selected. (See Modulation Modes and FEC Rates on page21 for specifications
on all supported carrier types.)
Note: Single Channel TDMA is supported in both DVB-S2 and iNFINITI networks. You
can continue to use upstream TPC coding in this mode in iNFINITI networks.
All upstream carriers received by Multichannel Line Card must be completely within a 36
MHz operational band, including the roll off resulting from the 1.2 carrier spacing. The
operational band must fall between 950 MHz and 1700 MHz for an XLC-M line card and
between 950 MHz and 2000 MHz for an eM0DM line card. (See Table 10.)
Both per-carrier and composite symbol rate limits apply for TDMA and SCPC. (See Table
10.)
There is a 40 Mbps composite information rate limit on SCPC return channels on

Multichannel Line Cards. The total for all channels received by the line card cannot
exceed 40 Mbps.
Note: When approaching the 40 Mbps composite information rate limit for SCPC
return carriers on a multichannel line card, limits may apply to individual
high-rate carriers. For details, see the Release Notes for your version of iDX
Release 3.0.
Licenses are required to configure Multichannel Line Cards in TDMA and SCPC
multichannel modes for more than one channel. (See the iDirect Features and Chassis
Licensing Guide for details.) A license is not required for TDMA single channel receive
mode, or to configure a single channel in TDMA or SCPC multichannel mode.
Spread Spectrum is not supported on Multichannel Line Cards.
Note:
30
Unlike iDX Release 2.3, in iDX Release 3.0 TRANSEC is not supported on eM0DM
line cards in any receive mode.

iDX Release 3.0
Table Table 10 shows various parameters associated with the Multichannel Line Card.
Table 10. Multichannel Receive Line Card Parameters
Hardware Type
Operating Mode
XLC-M and eM0DM

Single Channel TDMA
Multichannel SCPC
Multichannel TDMA
950
1700 (XLC-M)
2000 (eM0DM)
36
950
1700 (XLC-M)
2000 (eM0DM)
36
N/A
40
7500
N/A
1 (default)
up to 4 (license)
up to 8 (license)
Analog limits
L-Band Frequency MIN (MHz)
L-Band Frequency MAX (MHz)
IF Bandwidth (MHz)
Max Composite Symbol Rate (ksym)
Max Composite Information Bit Rate (Mbps)
Channels per card
Max Symbol Rate (ksym) per carrier
Note:
950
1700 (XLC-M)
2000 (eM0DM)
N/A
Composite Limits
N/A
N/A
1
1 (default)
up to 8 (license required)
8PSK / QPSK / BPSK (non-spread)

7500
11750
5875
For Upstream TDMA and SCPC Modulation Modes and FEC Rates, see
Modulation Modes and FEC Rates on page21.
For details on how to configure Multichannel Line Cards and on how to add carriers to
Multichannel Line Cards, see the iBuilder User Guide.

iDX Release 3.0
31
32

iDX Release 3.0
6 SCPC Return Channels
Beginning with iDX Release 3.0, a remote in a DVB-S2 network can be configured to transmit
to the hub either on a TDMA upstream carrier or on an SCPC upstream carrier. An SCPC
upstream carrier provides a dedicated, high-bandwidth, return channel from a remote to the
hub without the additional overhead of TDMA.
Remotes that transmit SCPC return channels (called SCPC remotes) receive the same
outbound carrier as the TDMA remotes in the network. However, unlike TDMA remotes, SCPC
remotes are not associated with Inroute Groups. Instead, a dedicated SCPC upstream carrier
is assigned directly to the hub line card that receives the carrier.
Hardware Support and License Requirements

This section lists the iDirect remote and line card model types that can be used to transmit
and receive an SCPC return channel and the licenses required per unit.
The following remote model types can be configured to transmit a dedicated SCPC return
channel to the hub:
Evolution e8350, iConnex e800/e850mp (No license required)
Evolution X3 (SCPC Return license required)
Evolution X5 (SCPC Return license required)
The following line card model types can be configured to receive SCPC return channels:
Evolution eM1D1 (Single channel, Rx-only; No license required)
Evolution eM0DM (Multichannel, Rx-only; Up to eight channels; Multichannel SCPC license

required for more than one channel)
Evolution XLC-M (Multichannel, Rx-only; Up to eight channels; Multichannel SCPC license

required for more than one channel)
For more information on iDirect licensing, see the iDirect Features and Chassis Licensing
Guide.
Note:
Even though an Evolution M1D1 line card is capable of transmitting a

downstream carrier, the Line Card Type of an eM1D1 line that receives an SCPC
return channel must be set to receive-only. It cannot act as a Transmit and
Receive line card.

iDX Release 3.0
33
Single Channel vs. Multichannel SCPC Return
Single Channel vs. Multichannel SCPC Return

Table 11 shows the differences and similarities between single channel and multichannel SCPC
return modes. As shown in the table, single channel SCPC return mode is only available on
Evolution eM1D1 line cards. Single channel SCPC supports higher symbol rates per channel
than multichannel SCPC. In addition, single channel SCPC supports Spread Spectrum while
multichannel SCPC does not.
Table 11. Single Channel vs. Multichannel SCPC
Single Channel SCPC
Multichannel SCPC
Line Card Support
eM1D1
eM0DM, XLC-M
Line Card Type
Rx-only (No Tx/Rx)
Rx-only
Symbol Rate Limit (per channel)
128 ksym to 15 Msym
128 ksym - 11.75 Msym
Composite Information Rate
N/A
40 Mbps (maximum)
Spread Spectrum
Spreading Factors 2, 4, 8
15 Mchip/s (maximum)
Not supported
Outbound Type
DVB-S2 only
DVB-S2 only
Inbound Coding
2D 16-State only. (No TPC)
2D 16-State only. (No TPC)
Note:
SCPC upstream carriers received by a multichannel line card can have different
symbol rates, modulation modes and FEC rates. This differs from TDMA
multichannel mode in which all carriers must be uniform. For more information
on multichannel SCPC return, see Multichannel Line Cards on page29.
Note:
For supported 2D 16-State Inbound Coding Modulation Modes, FEC Rates and
Block sizes see Table 5, Modulation Modes and FEC Rates for 2D 16-State
Inbound Coding over SCPC on page 24.
SCPC Return Feature on Remotes

When you configure your remotes in an iDirect network, you must download to the remotes
the appropriate software packages for the remote model type. For remotes that support SCPC
return, the firmware images for both SCPC and TDMA are contained in the same download
package. Therefore, there is no need to reload the remote packages if you want to switch
remotes between TDMA and SCPC.
However, when you switch from one carrier type to another, after reconfiguring your remote
and applying the hub-side and remote-side options files, you must restart the software
application to switch modes by resetting the remote. Typically, the remote will be out of the
network for approximately 1.5 to 2 minutes when you switch between TDMA and SCPC.
Upstream QoS on an SCPC remote is configured by assigning a Remote Profile directly to the
remote. Because an SCPC remote has the full use of the upstream carrier, there is no
upstream bandwidth contention among SCPC remotes. Remote Profiles are used to allocate
the available bandwidth among the applications on the remotes. For details, see the section
titled Assigning an Upstream Profile to an SCPC Remote in the iBuilder User Guide.
34

iDX Release 3.0
VNO for SCPC Return
Note:
To conserve bandwidth, QoS Service Level statistics are only available in

iMonitor by custom key. See the section titled Viewing Service Level
Statistics in the iMonitor User Guide for details.
You can select the Move operation in the iBuilder tree to switch a remote between TDMA and
SCPC. During the move, you must select the SCPC line card and channel or the TDMA Inroute
Group to which you are moving the remote as well as the appropriate QoS profile for the new
configuration. For details, see Moving Remotes Between Networks, Inroute Groups, and Line
Cards in the iBuilder User Guide.
The initial transmit power and maximum transmit power configured for a remote depend on
the characteristics of the upstream carrier. Therefore, the values that you configure for these
parameters will be different for TDMA and SCPC, and they will vary for SCPC carriers that are
not similar.
TDMA maximum and initial power and SCPC maximum and initial power (per carrier) are
defined separately in iBuilder. This allows you to facilitate switching remotes between TDMA
and SCPC and between different SCPC carriers by preconfiguring these power parameters for
any SCPC carriers that the remote will transmit.
Note:
If you move a remote to an SCPC carrier that does not have the initial and
maximum power values preconfigured for that remote, the remote will become
incomplete in iBuilder. You must configure the power settings on the remote for
that carrier before the remote will become operational.
See Adding Remotes in the iBuilder User Guide for details on configuring TDMA and SCPC
initial and maximum power for a remote in iBuilder. See the Installation and Commissioning
Guide for iDirect Satellite Routers for details on determining a remotes initial and maximum
powers.
VNO for SCPC Return

An HNO can assign a VNO ownership of individual SCPC return channels on a line card in single
or multiple channel SCPC receive mode. For multichannel line cards, this allows more than
one VNO to share the line card.
A VNO can own an SCPC return channel even when no upstream carrier has been assigned to
the channel. This allows VNO users to assign SCPC upstream carriers to the VNOs return
channels without the assistance of the HNO.
The HNO must make an SCPC upstream carrier Visible to the VNO before the VNO can assign
that carrier to an SCPC return channel. A VNO cannot own an upstream carrier.
For details, see Configuring VNO Access Rights for SCPC Return Channels in the iBuilder
User Guide.

iDX Release 3.0
35
VNO for SCPC Return
36

iDX Release 3.0
7 Multicast Fast Path
Beginning with iDX Release 3.0, iDirect supports the Multicast Fast Path feature. Multicast
Fast Path improves multicast throughput, allowing service providers to offer more reliable
and higher performing services for organizations that want to expand their use of HD
broadcast, IPTV, distance learning, digital signage and other video applications.
The Multicast Fast Path feature is available on all remote model types and can be used in
networks that transmit either DVB-S2 or iNFINITI downstream carriers.
Overview
When Multicast Fast Path is enabled for a multicast stream, downstream multicast packets
received by a remote are forwarded directly to the Ethernet by the remote firmware. This
bypasses software processing on the remote resulting in improved throughput. Multicast
traffic that does not use the Fast Path feature is handled by the full software stack and
processed as regular data traffic. This limits the maximum aggregate throughput. Using the
Multicast Fast Path feature to bypass software processing on the remote results in multicast
throughput of up to 40 Mbps.
Multicast Fast Path has significantly less impact on total throughput than non-fast path
multicast. Therefore, the unicast performance of the remote is much less affected by
multicast traffic when Multicast Fast Path is enabled for the multicast stream.
You are not required to use the Multicast Fast Path feature to transmit your user multicast
traffic. iDirects pre-iDX Release 3.0 multicast implementation can still be used for your
downstream multicast traffic. As in prior releases, NMS multicast traffic continues to be
transmitted as regular multicast traffic.
Multicast Fast Path Streams

You configure Multicast Fast Path streams in iBuilder by adding downstream Multicast
Applications on the Group QoS tab for your network and selecting the Multicast Fast Path
check box. You can configure a maximum of 16 Multicast Fast Path Applications per network.
You can define different QoS Application Profiles for each of the 16 Multicast Fast Path
streams, allowing you to prioritize and better manage multicast traffic.
All downstream multicast packets that match the rules configured for a Multicast Fast Path
Application are forwarded to the Ethernet by the remote firmware. This bypasses IGMP
processing by the remote software, effectively acting like a persistent multicast group on the

iDX Release 3.0
37
Multicast Fast Path Streams
eth0 interface of the remote. Therefore, you do not need to explicitly configure a persistent
multicast group for this interface for Multicast Fast Path streams. However, you should
continue to configure persistent multicast groups on your Network for Multicast Fast Path
streams to ensure that the protocol processor forwards the multicast packets to the transmit
line card for transmission on the downstream carrier.
Multicast Fast Path packets sent on an iDirect downstream carrier are not encrypted whether
or not link encryption is enabled for any or all of the remotes in the network.
For details on configuring Multicast Fast Path, see the iBuilder User Guide chapter titled
Configuring Quality of Service for iDirect Networks.
38

iDX Release 3.0
8 QoS Implementation
Principles
This chapter describes Quality of Service and its general implementation in iDirect networks.
It also includes several Group QoS operational scenarios. For additional material on this topic,
see the chapter titled Configuring Quality of Service for iDirect Networks in the iBuilder
User Guide.
Quality of Service (QoS)

Quality of Service is defined as the way IP traffic is classified, filtered and prioritized as it
flows through the iDirect system.
QoS Measures
When discussing QoS, at least four interrelated measures are considered: Throughput,
Latency, Jitter, and Packet Loss. This section describes these parameters in general terms,
without specific regard to an iDirect network.
Throughput. Throughput measures 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 measures 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 Voice
Over IP (VoIP) applications for human factor reasons.
Jitter. Jitter measures 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

iDX Release 3.0
39
QoS Measures
equipment contains a jitter buffer that collects voice packets and forwards them at the
appropriate interval (20 ms in this example).
Packet Loss. Packet Loss measures the number of packets that are transmitted by a source,
but not received by the destination. The most common cause of packet loss is network
congestion. Congestion occurs whenever the volume of traffic exceeds the available
bandwidth causing packets to fill 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).
iDirect QoS Profiles

The iDirect system allows you to define various QoS profiles for your upstream and
downstream traffic. When they are assigned to remotes, these profiles specify how packets
are filtered, scheduled and prioritized as they flow through the network. All profile types are
applied to upstream and downstream traffic independently, so that upstream traffic may have
one set of QoS definitions, while downstream traffic may have a different set of QoS
definitions.
QoS Profile types include:
Application Profile: A group of service levels and rules, collected together and given a
user-defined name. Application Profiles are the building blocks for Service Profiles and
Remote Profiles used in Group QoS.
Filter Profile: A single filter definition, consisting of a set of rules rather than a set of
service levels. Filter Profiles are assigned directly to remotes.
Service Profile: A set of Applications selected from Application Profiles. Service Profiles
are assigned to remotes in Group QoS Application Service Groups.
Remote Profile: A set of Applications selected from Application Profiles. Remote Profiles
are assigned to remotes in Group QoS Remote Service Groups. Upstream Remote Profiles
are also assigned directly to remotes that transmit SCPC return channels.
The relationship between remotes and the various types of QoS Profiles is illustrated in Figure
14 on p. 41.
See Group QoS on page48 for a general discussion of Group QoS. For more details on how
these profiles are used in the iDirect system and for procedures for configuring QoS profiles,
see the chapter titled Configuring Quality of Service for iDirect Networks in the iBuilder
User Guide.
40

iDX Release 3.0
QoS Measures
Remote
Remote
Remote
Service Profile
Remote
Remote
Remote
Remote Profile
Application Profiles
Filter Profile
Service Level 1..n

Service Level 1..n
Service Level 1..n
Rule
Rule
Rule 1..n
Clause 1..n
Source/Destination IP Address
Source/Destination Port Number
Protocol
Type of Service (TOS/DSCP)
Figure 14. Remote and QoS Profile Relationships

iDX Release 3.0
41
Classification and Scheduling of IP Packets

This section describes how the iDirect system prioritizes and schedules IP packets for
transmission.
Service Levels
Each packet that enters the iDirect system is classified into one of the configured 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:
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 determines the order in which packets are transmitted according to
priority and classification.
When a remote always has sufficient bandwidth for all of its applications, packets are
transmitted in the order that they are received without significant delay. Priority makes little
difference since the remote never has to select which packet to transmit next.
However, when a remote does not have sufficient bandwidth to transmit all queued packets
the remote scheduling algorithm must determine which packet to transmit next from the set
of queued packets across a number of service levels.
For each service level you define in iBuilder, you can select any one of the following queue
types to determine how packets using that service level are to be selected for transmission:
Priority Queue, Class-Based Weighted Fair Queue (CBWFQ), and Best-Effort Queue.
Priority Queues are emptied before CBWFQ queues are serviced; CBWFQ queues are in turn
emptied before Best Effort queues are serviced. Figure 15 on p. 43 presents an overview of
the iDirect packet scheduling algorithm.
42

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

iDX Release 3.0
43
Application Throughput
Priority Queues
There are five levels of 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 queues 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 lowerpriority 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 have the opportunity to transmit at
least occasionally even in the presence of higher priority traffic. Assuming there is a
continuously-congested link with an equal amount of traffic at 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 in CBWFQ Queues.
Application throughput depends on proper classification and prioritization of packets and on
proper management of available bandwidth. 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.
In iDirect, 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 and 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 remotes downstream.
44

iDX Release 3.0
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.
For information on configuring these features and for a discussion of additional QoS
properties, see the chapter titled, Configuring Quality of Service for iDirect Networks of the
iBuilder User Guide.
Minimum Information Rate

You can configure a Minimum Information Rate (also called Static CIR) for any upstream
(TDMA) channel. Minimum Information Rate is bandwidth that is guaranteed even when the
remote does not need the capacity. By default, a remote is configured with a single slot per
TDMA frame. This value can be changed by defining a Minimum Information Rate for the
remote. Increasing this value is inefficient because slots are wasted if the remote is inactive.
No other remote can be granted these slots unless the remote with the Minimum Information
Rate has not acquired the network. Minimum Information Rate is the highest priority
bandwidth. It can only be configured in the upstream direction. The downstream does not
need or support the concept of a Minimum Information Rate.
It is possible to configure a remote upstream Minimum Information Rate to be less than one
burst per TDMA frame. This allows many remotes to be packed into a single upstream which
in turn increases the remotes ramp latency. (Ramp latency is the amount of time it takes a
remote to acquire the bandwidth necessary to begin transmitting incoming packets.) The
lower the Minimum Information Rate, the fewer TDMA time plans contain a burst dedicated to
that remote, and the greater the ramp latency. Some applications may be sensitive to ramp
latency resulting in a poor user experience if the delay is noticeable. 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.
Committed Information Rate (CIR)

You can configure Committed Information Rate for remotes in both the downstream and
upstream directions. Unlike Minimum Information Rate, 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. CIR can be configured for remotes and for most container nodes in the
Group QoS Tree.
By default, additional burst bandwidth is assigned evenly among all remotes requesting
bandwidth, regardless of CIR allocations that have already been made. As discussed in the
iBuilder User Guide, this default behavior can be changed by selecting Allocation Fairness
Relative to CIR.

iDX Release 3.0
45
In some early iDirect releases, 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.
Maximum Information Rate (MIR)

Maximum Information Rate (MIR) specifies the maximum amount of bandwidth that will be
allocated to a remote or Group QoS node, regardless of amount of bandwidth requested.
Allocated bandwidth never exceeds the configured MIR bit rate.
The QoS bandwidth allocation algorithm does not strictly enforce MIR for upstream traffic.
Therefore, it is possible that a remote may receive more bandwidth than the configured
maximum if free bandwidth is available. However, this does not affect bandwidth allocations
for competing remotes or QoS nodes. MIR is strictly enforced for outbound traffic.
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 configured MIR and CIR). Once demand is met, it is possible
that there are unused TDMA slots. In that case, Free Slot Allocation grants these extra slots to
remotes in a fair manner, respecting any remotes 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 using 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 mis-identified UDP streams. For example, G729 voice RTP
results in less than 12 Kbps (uncompressed is 24 Kbps). To enable cRTP, see the section titled
Enabling IP Packet Compression Types in the chapter titled Configuring Remotes of the
46

iDX Release 3.0
Application Jitter
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 in packet-by-packet latency for a specific application traffic flow. For
an application like Voice over IP (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 stores incoming packets in a jitter
buffer and attempts to play out the arriving packets at the interval at which they were
transmitted. To accomplish this, additional latency is introduced by buffering packets for a
certain amount of time before forwarding them at the fixed interval.
While jitter plays a role in both downstream and upstream directions, an iDirect network
tends to introduce more jitter in the upstream direction than in the downstream direction.
This is due to the discrete nature of the TDMA time plan which only allows a remote to
transmit data in assigned slots. Jitter is introduced when the inter-slot times assigned to a
particular remote do not match the desired play out rate.
Another source of jitter is additional traffic transmitted between (or in front of) successive
packets in the real-time stream. When a large packet needs to be transmitted in front of a
real-time packet, jitter is introduced because the remote must wait longer than desired
before transmitting the next real-time packet.
TDMA Slot Feathering

When TDMA Slot Feathering is enabled, the Protocol Processor bandwidth manager attempts
to feather or evenly spread the TDMA slots allocated to an individual remote across each
upstream frame. For Voice over IP, this is a desirable attribute because the remotes bursts
are distributed more uniformly in time, reducing TDMA jitter and improving the quality of the
voice call. You can enable this feature by selecting Reduce Jitter for an Applications
Service Level in iBuilder. For details, see the chapter titled Configuring Quality of Service for
iDirect Networks in the iBuilder User Guide.
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

iDX Release 3.0
47
Application Latency
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 that require a rapid completion time per transaction. For
applications like these, it is important that the priority traffic be expedited through the
system at the expense of the less important background traffic. This is especially important in
bandwidth-limited conditions where a remote may have a limited number of TDMA slots on
which to transmit its packets. In that case, it is important to minimize application latency as
much as possible after the distributors QoS decision. You can accomplish this by configuring a
higher-priority for your transaction-based applications, allowing those packets to be
transmitted immediately.
Maximum Channel Efficiency vs. Minimum Latency

Each TDMA burst carries a discrete number of payload bytes. The remote must divide higherlevel packets into TDMA-burst-sized parts to package 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.
Group QoS
Group QoS (GQoS), introduced in iDS Release 8.0, enhances the power and flexibility of
iDirects 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
48

iDX Release 3.0
Group QoS
customers or Service Providers, while also allowing oversubscription of one groups configured
capacity when bandwidth belonging to another group is available.
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:
Bandwidth
Pool
Bandwidth
Group 1
Application
Service
Group 1
Application 1
Bandwidth
Group 2
Application
Service
Group 2
Application
Service
Group n
Application 2
Remote 1
Remote 2
Remote
Service
Group 1
Remote
Service
Group n
Application 3
Remote 3
Remote A
Remote B
Application 4
Application 6
Application 7
Application 10
Application 11
Application 14
Figure 16. Group QoS Structure
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).

iDX Release 3.0
49
Group QoS
Bandwidth Groups can be configured with QoS properties such as:
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 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.
Beginning with iDX Release 2.1, there are two types of Service Groups, Application Service
Groups and Remote Service Groups. An Application Service Group contains multiple
Applications. Remotes assigned to an Application Service Group share the bandwidth assigned
to the various Applications in the group. When using Remote Service Groups, a remote
becomes a container node for its Applications. Each remote is configured with its own QoS
properties such as MIR and CIR and independently allocates that bandwidth to its
Applications. Remote Service Groups allow you to configure bandwidth for individual remotes
and then assign multiple Applications to the remotes. The bandwidth allocated to the
Applications under a remote is taken from bandwidth granted to the individual remote; it is
not shared with other remotes as it is with Application Service Groups. Note that this
structure allows remotes to retain their QoS configuration when moving between networks.
The use of and the differences between each type of Service Group are discussed in detail in
the iBuilder User Guide.
Application
An Application defines a specific service available to the end user. Applications are defined by
Application Profiles and associated with any Service Group. The following are examples:
VoIP
50
VLAN
Multicast
NMS Traffic
Default

iDX Release 3.0
Group QoS
Note:
Beginning with iDX Release 3.0, you can configure Multicast Fast Path
Applications for your remotes. Multicast Fast Path bypasses software
processing on the remote resulting in improved throughput. For details, see
Multicast Fast Path on page37.
Each Application can have one or more Service Levels with 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 can be configured with various QoS properties such as:
CIR/MIR
Priority
Cost
Service Profiles
Service Profiles are applicable only to Application Service Groups. A Service Profile is created
by selecting Applications from the associated Application Service Group and configuring the
Group QoS properties (such as CIR and MIR) of the Service Profile. While the Application
Service Group specifies the CIR and/or MIR by Application for the entire Application Service
Group, the Service Profile specifies the per-remote CIR and/or 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, remotes in an Application Service Group use the Default Profile for that Service
Group. In order to accommodate special cases, however, additional profiles (other than the
Default Profile) can be created by an operator with Group QoS Planning permissions. 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 Service Profiles to each
group of remotes.
Remote Profiles
Remote Profiles are applicable only to Remote Service Groups. Like Service Profiles, Remote
Profiles define the Applications that are used by the remotes. Unlike Service Profiles, the
Applications defined by Remote Profiles are subnodes of the Remotes in the Group QoS tree.
Each Application in a Remote Profile can be configured with its own CIR, MIR, etc. which
determine how bandwidth is shared on individual remotes that have the Remote Profile
assigned. The Applications are themselves built from Application Profiles, which contain the
QoS Service Levels and Rules governing the bandwidth usage of the remote.

iDX Release 3.0
51
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:
52
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.

iDX Release 3.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 Application Service Groups 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

iDX Release 3.0
53
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
54

iDX Release 3.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 Groups Applications 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.

iDX Release 3.0
55
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 Application 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
Application Service Groups:
56

iDX Release 3.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 Application 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

iDX Release 3.0
57
Group QoS
Remote Service Group Scenario

Example: A network operator provides service to ocean-going vessels. iDirects Global NMS
feature is used, allowing the ships to move from network to network as they travel the globe.
The network operator wants to be able to configure QoS to tailor the bandwidth allocations to
the needs of individual ships. In addition, the network operator wants each ship to keep its
QoS configuration when it moves from one network to another.
Some ships want to segregate traffic by subnet. For example, a cruise ship wants to assign one
subnet for its ship administration, another for on-board shops, and a third for passenger
internet service. Other ships want to assign QoS properties such as MIR and CIR by
Application. For example, a yacht wants to ensure that calls using Voice over IP (VoIP) have
sufficient bandwidth to ensure good voice quality but that other applications (such as web
browsing) are given maximum bandwidth in the absence of VoIP calls.
Configuration:
By using Remote Service Groups, each remote becomes a node in the Group QoS tree.
Therefore, each remote can be configured with its own MIR, CIR, Priority, etc. by the Network
Operator. Although the remotes in the Remote Service Group compete for overall bandwidth,
they do not compete for bandwidth for individual Applications as they would if they were in
an Application Service Group.
Once a remote in a Remote Service Group has been granted its overall bandwidth, the
network operator can divide that bandwidth among the various applications, subnets, VLANs,
etc. in any way that meets the needs of the individual remote by creating the appropriate
Remote Profile and assigning it to the remote.
Furthermore, the same Remote Profile can be easily assigned to the remote in each of its
iDirect networks. Therefore, when the remote moves to a new network, it can carry its Group
QoS configuration with it and the manner in which the remotes bandwidth is distributed to
the remote applications does not change.
Figure 22 shows an example of two remotes using Remote Service Groups. Remote 1 (based on
the cruise ship example discussed above) has divided its users by subnet and assigned
different QoS properties to each subnet. This is accomplished by creating Service Level rules
that filter based on IP addressing in Application Profiles. Those Application Profiles are then
used to build the upstream and downstream Remote Profiles for the remote.
In the example for Remote 1, both ship administration and on-board commerce are given a
higher priority (Priority 4) than passenger internet service (cost-based). Both Ship
Administration and On-Board commerce are capped at 1 Mbps. The full 1 Mbps is configured
as CIR for Ship Administration. On-board commerce is given 512 kbps of CIR to ensure that
transactions are granted sufficient bandwidth in most situations; it can also be granted up to
1 Mbps of bandwidth under heavy load. Since passenger internet service is cost based, it will
never be granted bandwidth at the expense of the other (higher-priority) subnets. It is
configured with the full MIR of 4 Mbps to allow it to use any bandwidth that is not currently
being used by the other subnets if necessary.
Note:
58
To segregate the traffic by subnet, an external router is required at the remote

site. The same objective could be met by segregating traffic by VLAN without
the additional router.

iDX Release 3.0
Group QoS
Remote 2 is on board a private vessel that requires bandwidth for VoIP as well as for more
general internet traffic such as web browsing. The VoIP application has a CIR of 64 kbps to
ensure sufficient bandwidth for high-quality voice calls. Limiting the CIR for other
applications to 448 kbps ensures that VoIP traffic will be granted the 64 kbps even if the
remotes demand for other bandwidth is greater than 448 kbps. The 512 kbps of MIR for other
applications is shown for clarity. It is not really necessary to configure the 512 kbps of MIR for
these applications since the remote itself is already limited to 512 kbps.
Outbound or
Inroute Group
BW Group
Remote
Service Group
Remote 1
MIR 4 Mbps
Remote Profile by Subnet

Ship Administration: Priority 4, CIR: 1 Mbps, MIR: 1 Mbps
- Service Level Rules filter for subnet 10.10.1.0
On-Board Commerce: Priority 4, CIR: 512 kbps MIR 1 Mbps
Passenger Internet Service: Cost Based, MIR 4 Mbps
Remote 2
MIR 512 kbps
Remote Profile by Application

Voice over IP: CIR: 64 kbps MIR: 64 kbps
Other Application: CIR: 448 MIR: 512 kbps
Figure 22. Remote Service Group Scenario

iDX Release 3.0
59
Group QoS
DVB-S2 ACM Scenario 1: Scaled Aggregate CIRs Below Partitions 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 page15 for a detailed description of ACM
operation with EIR enabled. The scenario shows three remotes in an Application Service
Group in Remote-Based Group QoS 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 Application Service Group
MIR set to 7.2 Mbps for the Application 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
Application 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 remotes Nominal
MODCOD Scaling Factor are needed and are shown in Figure 23 on page61.
Note:
When bandwidth is allocated for a remote, the CIR and MIR are scaled to the
remotes Nominal MODCOD. At higher levels of the Group QoS tree (Bandwidth
Group, Service Group, etc.) CIR and MIR are scaled to the networks best
MODCOD.)
Referring to Figure 23:
60
The Scaled CIR for Remote 1 = 1 Mbps * 1.6456 / 1.2382 = 1.33 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
Mbps
Mbps

iDX Release 3.0
Group QoS
Remote-Based GQoS Mode

Networks Best MODCOD
16APSK 8/9
(Scale Factor 1.2382)
Nominal MODCOD (all Remotes)
16APSK 8/9
Remote 1
Service
Grp
CIR = 6.5M
MIR = 7.2M
App
Grp
Remote 2
Remote 3
CIR = 1M
MIR = 2M
EIR Min QPSK 1/4
CIR = 1M
MIR = 2M
EIR Min QPSK 1/4
CIR = 1M
MIR = 2M
EIR Min QPSK 1/4
Operating @ 8PSK 8/9

Operating @ QPSK 8/9


Demand = 1.5M
Demand = 1.5M
Demand = 1.5M
CIR Allocation = 1M
Best Effort Allocation = 226K
Total Allocation = 1.226M
CIR Allocation = 1M
CIR Allocation = 1M
Figure 23. Scaled Aggregate CIRs Below Partitions CIR

iDX Release 3.0
61
Group QoS
DVB-S2 ACM Scenario 2: Scaled Aggregate CIRs Exceeds Partitions CIR

This scenario uses the same configuration as the scenario on page60 with a change in CIR and
MIR for the Application Service Group. In this case, the Application Service Group is
oversubscribed as follows:
The CIR of the Application Service Group is set to 3 Mbps.
The MIR of the Application Service Group is set to 3 Mbps.
Assume for this example that the 3 Mbps CIR and 3 Mbps MIR are available for the Application
Service Group.
In the scenario (Figure 24), the Scaled Aggregate CIR for the three remotes (6.3 Mbps)
exceeds the Service Group CIR of 3 Mbps. Bandwidth is therefore distributed scaled to the
Nominal MODCODs of the remotes.
Remote 1 receives 1 Mbps * 1.2382 / 1.6456 = 752 Kbps
Remote-Based GQoS Mode
Service
Grp
CIR = 3M
MIR = 3M
Nominal MODCOD (all Remotes)

16APSK 8/9
App
Grp
Remote 1
Remote 2
Remote 3
CIR = 1M
MIR = 2M
EIR Min QPSK 1/4
CIR = 1M
MIR = 2M
EIR Min QPSK 1/4
CIR = 1M
MIR = 2M
EIR Min QPSK 1/4
Operating @ 8PSK 8/9



Demand = 1.5M
Demand = 1.5M
Demand = 1.5M
CIR Allocation = 752K

Total Allocation = 752K


Figure 24. Scaled Aggregate CIRs Exceed Partitions CIR
62

iDX Release 3.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.
450K Available for

the Service Group
Service Group
Allocation Fairness
Relative to CIR Disabled
450K Available for

the Service Group
Service Group
Allocation Fairness
Relative to CIR Enabled
Remote 1
Remote 2
Remote 1
Remote 2
(CIR = 256K)
(CIR = 512K)
(CIR = 256K)
(CIR = 512K)
Allocation: 225K
Allocation: 225K
Allocation: 150K
Allocation: 300K
Figure 25. Bandwidth Allocation Fairness Relative to CIR

Figure 25 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 25 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 1s 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 25 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.

iDX Release 3.0
63
Group QoS
Bandwidth Allocation Fairness Relative to MODCOD

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

Figure 26 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 26 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 26 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.
64

iDX Release 3.0
9 Configuring Transmit
Initial Power
During acquisition, an iDirect 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.

iDX Release 3.0
65
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 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 27).
Ideal Case :
Optimal Detection R ange
6
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 27. C/N Nominal Range
66

iDX Release 3.0
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 (Figure28).
T X Initial P ow er T oo H igh:
S ke w ed D e tection R ange
6
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 28. 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.

iDX Release 3.0
67
Bursts can still be detected below threshold but the probability of detection and
demodulation reduces. This can lead to long acquisition times (Figure29).
T X In itial P ow er T o o Lo w :
S kew ed D etection R ange
6
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 29. TX Initial Power Too Low
68

iDX Release 3.0
10 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 30 illustrates the current and Global NMS database relationships.
Figure 30. Global NMS Database Relationships

iDX Release 3.0
69
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 31).
Figure 31. 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 31.) 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.
70

iDX Release 3.0
11 Hub Network Security

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

Access to the NMS and Protocol Processor servers should be protected behind a commercialgrade firewall. If remote access is necessary for support, the iDirect Technical Assistance
Center can help you set up appropriate VPN access. Contact the TAC for details (see Getting
Help on pagexv).
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.

iDX Release 3.0
71
Root Passwords
72

iDX Release 3.0
12 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

iDX Release 3.0
73
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 32.
PP Blade 1
N M S Server
sam nc
sarm t
spaw n
and
control
NM S Servers
sada
M onitor and C ontrol

sarouter
sana
pp_controller
PP Blade 2
sam nc
spaw n
and
control
sarm t
sarouter
Figure 32. Protocol Processor Architecture
74

iDX Release 3.0
13 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.
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.

iDX Release 3.0
75
iBuilder and iMonitor
The most common distribution scheme for larger networks is shown in Figure 33.
Figure 33. 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.
76

iDX Release 3.0
14 Transmission Security
(TRANSEC)
This chapter describes how TRANSEC is implemented in an iDirect Network. It includes the
following sections:
What is TRANSEC?"
iDirect TRANSEC"
TRANSEC Key types"
DVB-S2 Downstream TRANSEC"
Upstream TRANSEC"
ACQ Burst Obfuscation"
TRANSEC Dynamic Key Management "
TRANSEC Remote Admission Protocol"
ACC Key Management"
Automatic Beam Selection (ABS) and TRANSEC "
What is TRANSEC?
Transmission security prevents an adversary from exploiting information available in a
communications channel without necessarily having defeated the encryption inherent in the
channel. For example, even if an adversary cannot defeat the encryption placed on individual
packets, the adversary may be able to determine answers to questions such as:
What types of applications are currently active on the network?
Who is talking to whom?
Is the network or a particular remote site active now?
Based on traffic analysis, what is the correlation between network activity and real world
activity?
Is a particular remote site moving?
Is there significant acquisition activity?
iDirect supplies FIPS 140-2 certified TRANSEC-capable IP modems. iDirects TRANSEC feature,
as outlined in this chapter, makes answers to questions like those listed above theoretically
impossible for an adversary to determine.

iDX Release 3.0
77
iDirect TRANSEC
iDirect TRANSEC
iDirect achieves full TRANSEC compliance by presenting to an adversary eavesdropping on the
RF link a constant wall of fixed-sized, strongly-encrypted (AES, 256 bit key, CBC Mode) traffic
segments, the frequency of which do not vary with network activity. All network messages,
including those that control the admission of a remote terminal into the TRANSEC network,
are encrypted and their original size is hidden. The content and size of all user traffic (Layer
3 and above), as well as all network link layer traffic (Layer 2), is completely indeterminate
from an adversarys perspective. In addition, no higher-layer information can be ascertained
by monitoring the physical layer (Layer 1) signal.
iDirect TRANSEC 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 adversarys remote from joining an iDirect TRANSEC
network. In a similar manner, it prevents an adversary from coercing a TRANSEC remote into
joining the adversarys network. While these types of attacks would be extremely difficult
even in a non-TRANSEC iDirect network, the mechanisms in place within a TRANSEC network
render them theoretically impossible.
All encryption in a TRANSEC network is done using the AES algorithm with a 256 bit key and
operates in CBC Mode.
TRANSEC Key types

iDirect TRANSEC is based on the following keys:
Host Private Keys/Public Keys. Each host in a TRANSEC network has a set of selfgenerated private keys and public keys. These keys are used for certificate exchange and
verification. Once generated, these keys are never changed. All Dynamic Network Key
exchanges are protected by these keys.
Dynamic Network Key (or Dynamic Key or DCC Key). The network-wide Dynamic Network
Key is used to encrypt all user traffic and traffic headers in both the upstream and
downstream directions. This key is updated frequently to preserve the key strength.
Because a remote receives the Dynamic Network Key after acquisition into the network, it
is possible for the remote to miss a key update (also called a key roll) and still join the
network. The Dynamic Network Key is not preserved across power cycles of a modem.
The channel encrypted with the Dynamic Key is referred to the Dynamic Ciphertext
Channel, or DCC. There is a separate DCC for the downstream and upstream channels.
Both the downstream and upstream DCC use the same Dynamic Network Key.
Network Acquisition Key (or ACC Key). The Network Acquisition Key is used to encrypt all
traffic and traffic headers that are required for a remote to acquire the network. This key
is rolled infrequently. If a remote misses two consecutive key updates, it is not able to reacquire the network until the key is provided to the remote. The Network Acquisition Key
is stored on the remote and is preserved across power cycles. The channel encrypted with
this key is referred to the Acquisition Ciphertext Channel, or ACC. There is an ACC for the
downstream and an ACC for the upstream. The same key is used for the upstream and
downstream.
The iDirect TRANSEC system is designed so that compromise of the ACC Key only reveals
which remotes are acquiring the network. Compromise of this key does not allow an
78

iDX Release 3.0
DVB-S2 Downstream TRANSEC
attacker to join the network or to perform traffic analysis on remotes that have already
acquired the TRANSEC network.

This section describes the TRANSEC feature as it relates to DVB-S2 carriers. TRANSEC on the
TDMA upstream is described in Upstream TRANSEC on page81.
iDirect supports two types of downstream carriers: DVB-S2 downstream carriers and iDirect
iNFINITI downstream carriers. iDX Release 3.0 supports TRANSEC on DVB-S2 downstream
carriers. iDX Release 3.0 does not support TRANSEC on iNFINITI downstream carriers.
With a deterministic TDMA upstream carrier such as iDirects, a Burst Timeplan (BTP) is
transmitted from the hub on the downstream carrier at a predetermined time interval. (This
predetermined interval, called a frame, is typically 125 ms in an iDirect Network.) The BTP
assigns each upstream time slot on each channel to the active remotes. This information must
be protected since it describes the return channel bandwidth usage for each remote.
A remote must use the upstream channel before it has the received the DCC Key in order to
authenticate itself. To accommodate this, the BTP is broken into two parts: the
acquisition/authentication slots are defined in the first part, and the traffic slots for
authenticated remotes are defined in the second part. The first part is encrypted with the
ACC Key, and the second part is encrypted with the DCC Key.
In addition to the BTP, the authentication process itself (described later) requires use of both
the downstream and the upstream channels. The authentication traffic is encrypted with the
ACC Key. Once the remote is authenticated, all traffic is encrypted with the DCC Key.
In both the upstream and downstream directions, the proportion of ACC and DCC traffic is
hidden by encrypting the headers with the ACC Key. The exact format differs for the
downstream carrier and the upstream carrier.
Note:
All downstream multicast traffic is also encrypted with the DCC Key.
Except as noted below, all downstream information is encrypted by either the ACC Key or the
DCC Key. Some of the ACC-encrypted traffic, such as the DVB-S2 NCR timestamps, is
generated by the line card firmware. Other ACC-encrypted traffic, such as authentication
traffic and acquisition invitations, is generated by software running on the hub servers. ACC
traffic generated by server software is specifically tagged as ACC traffic, so that the line card
firmware can store it in the appropriate queue.
The DVB-S2 downstream consists of a series of BBFRAMEs. Each BBFRAME is defined at the
physical layer. For TRANSEC operation, the outbound operates at a fixed MODCOD, meaning
that the modulation and FEC encoding for each DVB-S2 frame is the same.
Note:
Since DVB-S2 TRANSEC requires a fixed MODCOD, you must configure your
TRANSEC DVB-S2 carriers to simulate CCM by setting the Maximum and
Minimum MODCODs to the same value.
A DVB-S2 frame can contain both ACC and DCC data. The proportion of each type of data is
hidden from an attacker using the AES encryption. The definition of the DVB-S2 frame
structure and the type of key applied to the various fields within each frame are shown in
Figure 34. (The exact positions and lengths of the fields may be rearranged for

iDX Release 3.0
79
implementation purposes; however, that does not change which fields are encrypted by a
given key.)
1 byte ACC
Key ring
position
4 byte fixed
header
16 bytes IV
16 Bytes ACC encrypted
ACC
Len
DCC
Len
16 * N bytes ACC encrypted
16 * M bytes DCC encrypted
Beginning of ACC data
1 byte DCC
Key ring
position
Figure 34. DVB-S2 TRANSEC Frame Structure

The first 21 bytes of the DVB-S2 frame are sent in the clear. These initial 21 bytes consist of:
A four-byte fixed header, which never changes
A 16-byte Initialization Vector (IV) used by the encryption / decryption algorithm
A single byte containing the key ring position for the ACC Key. This allows for key rolls of
the ACC Key as described in ACC Key Management on page88.
The next 16 bytes are always encrypted with the ACC Key. They contain the following
information:
The length of the ACC-encrypted data
The length of the DCC-encrypted data
The key ring position of the DCC Key, required to allow key rolls.
Because these 16 bytes are encrypted, the proportion of the ACC to DCC data is hidden from
an attacker. Compromise of the ACC Key can only jeopardize the acquisition information (i.e.
who is acquiring). Once acquired, all traffic patterns are protected by the DCC Key. Because
the DCC Key is protected by the RSA public/private keys, possession of the ACC Key does not
allow an attacker to determine the DCC Key.
The total length of encrypted data is always the same. If there is unused space in a BBFRAME,
it is filled with random data and then encrypted. In some cases, the entire BBFRAME may
consist of encrypted random data.
The steps in the decryption process are:
1. The packet is recovered at the physical layer, including CRC checking.
2. The four-byte fixed header is checked. If it is not correct, the packet is discarded.
3. The 16 byte IV is loaded into the AES core.
4. The key ring position is used to select the correct ACC Key.
5. The first 16 bytes are decrypted and ACC and DCC lengths are extracted.
6. The AES core decrypts the ACC data (using CBC); the key is switched to the DCC Key; and
the DCC data is decrypted. (The DCC Key ring position is used to select the appropriate
key). The last 16 bytes of the ACC data serve as the IV of the DCC encrypted data.
80

iDX Release 3.0
Upstream TRANSEC
7. The decrypted packet is processed in the normal fashion to extract the IP packets.
At startup, the initial IV is the result of the Known Answer Test. For each subsequent
BBFRAME, the last 16 bytes of encrypted data are used as the IV for the following BBFRAME.
Upstream TRANSEC
All data for transmission on the upstream TDMA carrier starts as IP data packets. These
packets are segmented by software into fragments that fit into the fixed size payloads of the
TDMA bursts. This segmented data is segregated into two queues: one for ACC data and one
for DCC data. A given TDMA burst only contains ACC or DCC data.
All packets regardless of class are encrypted. The key used to encrypt the data varies
depending on the packets queue. Packets extracted from the DCC queue are encrypted using
the DCC Key. Packets extracted from the ACC queue are encrypted using the ACC Key.
Note:
TRANSEC is not supported on SCPC return channels.
Disguising Remote Acquisition

The number of ACC-encrypted slots in a burst varies depending on whether or not the remote
is acquiring the network. If unprotected, this variation would give an attacker the ability to
determine whether or not the remote is acquiring the network. To prevent that, the following
scheme (illustrated in Figure 35) is used to hide which key is used for any given burst.
Bytes
Bytes
16
Code
#2
Code
#1
IV#1
16
Code
#2
Code
#1
IV#1
16*N-2
2
Data Payload
16
16*N-18
Data Payload
CRC
(1)
2
CRC
(2)
IV #2
Encrypted
with IV #1
and ACC or
DCC key
Bytes
1
Code
#2
16
Enc w/ ACC
and IV # 2
IV #3
16
16*N-18
Data Payload
2
CRC
(3)
Last byte
of IV #1
Bytes
1
Code
#2
16
Enc w/ ACC
and IV # 2
IV #3
16
16*N-16
Encrypted with ACC or DCC key and IV#3
(4)
Figure 35. Disguising Which Key is Used for a Burst

iDX Release 3.0
81
Upstream TRANSEC
Each Code Field show in Figure 35 is an eight-bit (one byte) field with the following structure:
0
RESERVED
Key Sel
Key ID [1:0]
Figure 36. Code Field

The Code Field (Figure 36) is sub-divided as follows:
The Key Sel is a single bit indicating whether to use the ACC or DCC Key.
The Key ID is a two-bit key ring position identifier used in the key roll.
Referring to numbered steps (1) through (4) on the right side of Figure 35:
1. In step (1), the data is loaded into the firmware. Code #1 indicates whether the payload
is to be encrypted with the ACC Key or the DCC Key. A CRC is added to the data payload.
Because the CRC is encrypted, it detects both physical layer bit errors and the use of the
incorrect decryption key.
2. In step (2), the first block of the main payload is encrypted using AES-256 with CBC using
the appropriate key and IV #1.
3. After this first encryption, the output is used as IV #2. This is used with the ACC Key and
Code #2 to encrypt both Code #1 and the first 15 bytes of IV #1. The result is shown in
step (3).
Note: The encryption of the first 15 bytes of IV #1 is not intended to hide those
bytes; rather, it is intended to allow the single-byte of Code #1 to be AESencrypted in a robust manner.
4. The output of this encryption becomes IV #3, which is used with the key specified in Code
#1 to encrypt the remainder of the data payload. This is illustrated in step (4).
Code #2 always indicates the ACC Key (although the key ring position can change), while
Code #1 indicates either the ACC or the DCC Key. However, since Code #1 is encrypted, and
therefore not visible to an attacker, an attacker has no way of knowing whether a burst is ACC
or DCC.
Note:
Even if the ACC Key were compromised, only acquisition information would be
exposed. After acquisition, link layer information is still protected by the DCC
Key.
Packets exit the encryption process as shown in step (4). At this point the packet is ready for
transmission.
Generating the TDMA Initialization Vector

Generation of the Initialization Vector (IV) must be accomplished such that an adversary
cannot determine whether or not any two TDMA bursts were transmitted from the same
remote. Therefore, the approach used on the downstream carrier (using the final 128 bits of
the last burst from the remote) is unacceptable for the TDMA upstream channel. Instead, to
provide a robust IV for the TDMA burst, the last 256 bits of the previous TDMA burst are
82

iDX Release 3.0
Upstream TRANSEC
processed by the encryption engine with the DCC Key applied. This results in a new 128 bit
value which cannot be linked to the previous burst.
Figure 37 illustrates the generation of the upstream Initialization Vector.
Output
Data input
128
bits
IV
128
bits
IV input
AES Core
IV
Key Input
Encrypted burst
payload
Key
Burst N from Remote
Encrypted burst
payload
Burst N+1 from Remote
Figure 37. Generating the Upstream Initialization Vector

As illustrated in Figure 37, the following inputs are provided to the AES Core:
The first 128 bits are provided to the IV Input.
The second 128 bits are provided to the Data Input.
The Key used for burst N+1 is provided to the Key Input.
The 128 bit Output is used as the IV for the next burst.
While no logic is included to ensure that IVs do not repeat, the probability of repeating the
same IV within a two-hour period is extremely smallroughly estimated to be 1 in 297 for a
maximum data rate iDirect TDMA channel.
Note:
A random number from a FIPS-certified random number generator is used to

generate the first TDMA IV.
Upstream TRANSEC Segment

The upstream Segment is of fixed, configurable length and consists of the standard iDirect
TDMA frame. A detailed description of the standard TDMA frame is beyond the scope of this
discussion. In general, the iDirect TDMA frame consists of:
The Demand Header (indicating the amount of bandwidth requested by the remote)
The Link Layer (LL) Header
The Payload
This Segment is encrypted.

Once an encrypted packet exits the Encryption Engine it undergoes the normal processing
applied to any upstream packet. This includes things such as Forward Error Correction
encoding and unique word insertion. This processing is independent of TRANSEC and
completes the upstream transmission chain.
A remote in a TRANSEC network always bursts in its assigned slots even when traffic is not
present by generating encrypted fill payloads as needed. The iDirect Hub allocation
algorithm always allocates all available time slots within all timeplans. This ensures that all
time slots are filled.

iDX Release 3.0
83
ACQ Burst Obfuscation
ACQ Burst Obfuscation

In order to establish a TDMA return channel in an iDirect network, an initial measurement
must be made of the time delay offset, frequency offset, and power offset. This is
accomplished using a special Acquisition Slot, or ACQ slot. An ACQ Slot is a time slot at the
end of every TDMA frame with a wide timing window.
Because the hub has no way of knowing the state of a remote that is not in the network, it
continuously sends ACQ invitations to any remote that has been activated in the NMS and is
currently out-of-network. When a remote is ready to join the network, it bursts in its ACQ
slot.
If left unmodified for TRANSEC, this process would allow an adversary to observe the ACQ
slot. In a stable network, the adversary would see no bursts in the ACQ slot. Whenever a
remote attempted to join the network, the adversary would see bursts in the ACQ slot.
Therefore, the attacker could determine when remotes were acquiring the network. (Note,
however, that the encryption would prevent the attacker from knowing which remotes were
trying to join the network.)
To address this weakness, the iDirect system uses ACQ Burst Obfuscation. ACQ Burst
Obfuscation works as follows:
1. The hub Issues dummy invitations to remotes already in the network. Since remotes
always burst in response to dummy invitations, it always appears that there is acquisition
activity.
2. The hub deliberately does not issue invitations for some inroute slots, so the ACQ channel
never appears full.
3. The hub Issues normal invitations, in response to which some remotes will burst and
others will not.
An attacker observing the upstream always sees some acquisition activity, but never full
acquisition activity. The is illustrated in Figure 38.
Start of Frame
Inroute 1
Deliberately empty slot
Inroute 2
Assigned Real ACQ slot with no

response from remote
Inroute 3
Inroute 4
Dummy ACQ bursts
Inroute 5
Real ACQ burst

Time
Data slots (ACC and DCC)
ACQ slot
Figure 38. Upstream ACQ Burst Obfuscation
84

iDX Release 3.0
TRANSEC Dynamic Key Management
A remote responding to dummy invitations sends filler data encrypted with the Network
Acquisition Key. The remote deliberately offsets the time, frequency, and transmit power of
the burst to mimic a real acquisition attempt.
The proportion of dummy ACQ bursts, deliberately-empty slots, and actual ACQ slots is
controlled by the hub side equipment. A random function provides significant short and long
term variation in activity, while also providing a minimum number of used and unused slots.
After a network restart, all the remotes are out of the network. ACQ burst obfuscation does
not operate until at least one remote per inroute has acquired the network. During this
startup period, all of the ACQ slots contain real ACQ invitations.

iDirects generic key management protocol meets FIPS 140-2 requirements for PKI (Public Key
Infrastructure) key management protocols that use X.509 certificate authentication. This
protocol is used in any operational scenario requiring key management. Examples include the
transfer of keying information between protocol processor blades and other blades; between
protocol processor blades and remotes; and between protocol processor blades and line
cards. These protocols, described by Figure 39 (Key Distribution Protocol), Figure 40 (Key
Rolling), and Figure 41 (Host Keying Protocol), are based on a standard techniques used in an
X.509-based PKI.
Key Distribution Protocol

Peer 2
Peer 1
C ertfica te
So licitation
C ertifica te
Solic ita tio n
Ce rt ificate
Certific ate
Mutual Trust Estabilished
Key Up da
te
Ac k
Key Up date
Key Distribution Complete
Figure 39. Key Distribution Protocol

iDX Release 3.0
85
Figure 39 assumes that upon the receipt of a certificate from a peer, the host is able to
validate and establish a chain of trust based on the contents of the certificate. iDirect uses
standard X.509 certificates and methodologies to verify the peers certificate.
After the completion of the sequence described in Figure 39, a peer may provide an
unsolicited key update message as required. The data structure used to complete the key
update (also called a Key Roll) is described in Figure 40.
Key Ring
Fallow
00
<Key>
Fallow
01
<Key>
Current
10
<Key>
Next
11
<Key>
Figure 40. Key Roll Data Structure

This data structure shown in Figure 40 consists of:
A set of pointers (Current, Next, Fallow)
A two-bit identification field used in the Encryption Headers
The Symmetric Keys
The following processing takes place during a key update:

1. A new key is generated and placed in the Fallow slot after the Next slot.
2. The Next and Current pointers are incremented. (Since this is a circular update, 11 rolls
to 00.)
3. A Key Update message is generated reflecting these changes.
The key roll mechanism allows for multiple keys to be in play simultaneously resulting in
seamless key rolls. By default, DCC Key updates occur every eight hours and ACC Key updates
occur every 28 days. These default time periods can be modified by using custom keys. For
details on changing the frequency of ACC and DCC Key Updates, see the appendix titled
Managing TRANSEC Keys in the iBuilder User Guide.
86

iDX Release 3.0
Figure 41 describes the iDirect Host Keying Protocol.
Host Keying Protocol

Host
CA Foundry
Q ue ry Me ss
ag e
n
Ce rtificatio
Key G ene
ort
Status Re p
ration C omm
and
quest
Signin g Re
Cer tific ate
Ho st Certi
ficate
Tru sted C
Set o f U nt
er tific ate
rus ted C ert
ifi
Ce rtific ate
R
ca te s
ev oc ation L
i
st
Figure 41. Host Keying Protocol

The Host Keying Protocol describes how a host receives an X.509 certificate from a Certificate
Authority (CA). iDirect provides a Certificate Authority (called the CA Foundry) with its
TRANSEC hub.
Note:
In all cases, Host Key Generation is done on the X.509 host. In the iDirect
system, hosts are NMS servers, protocol processor blades, line cards and
remote modems.
After the host has completed the exchange shown in Figure 41, the hub transmits the Network
Acquisition Key to the host. The initial generation of the Network Acquisition Key is described
in ACC Key Management on page88. The Network Acquisition Key is encrypted with the host
public key before it is transmitted to the host.

iDX Release 3.0
87
TRANSEC Remote Admission Protocol
TRANSEC Remote Admission Protocol

Remotes acquire the network over the control channel. Specifically, a single protocol
processor blade is designated to be in charge of controlling remote admission into the
network. When a remote is given the opportunity to acquire the network, the following
sequence of events occurs:
1. The system generates two timeplans per inroute. One timeplan is the normal timeplan
indicating to the remotes the inroute slots in which they are allowed to transmit. This
timeplan is always encrypted using the Dynamic Network Key.
The second timeplan is encrypted using the Network Acquisition Key. This timeplan
indicates the owner of the acquisition slot (i.e. which remote is allowed to acquire) and
which remote is allowed to burst on selected slots for authentication purposes. The union
of the two timeplans covers all slots in an inroute.
2. Both timeplans are broadcast to all remotes. Remotes that have not yet acquired the
network receive the timeplan over the control channel and wait for an invitation to join
the network via this control message.
3. The remote designated to use an acquisition slot acquires in the normal fashion by
sending a response in the acquisition slot of the specific inroute.
4. Once physical layer acquisition occurs, the remote uses the key distribution protocol
illustrated in Figure 39 on page 85 before it is trusted by the network and before it trusts
the network. This step must be carried out over the control channel. Therefore remotes
in this state request bandwidth normally and are granted TDMA slots as described in Step
1.
5. Once authentication is complete, the key update message must also complete in the
control channel. The actual symmetric keys are encrypted using the remotes public key
information obtained in the exchanged X.509 certificate.
6. Once the symmetric key is exchanged, the remote enters the network as a trusted entity
and begins normal (dynamically-encrypted) operation.
This admission procedure ensures that neither control nor normal traffic is ever allowed to
traverse the network unencrypted.
ACC Key Management

The Network Acquisition Key (ACC Key) is generated by the hub. It is never exposed in the
clear. The transfer the ACC Key to any host by any mechanism is always encrypted with the
hosts public key.
The ACC Key has a configurable key roll time. Because a remote cannot enter the network
without the current ACC Key, a remote that is out of the network for the time between the
time a new key is pushed and the time it is activated is unable to join the network until a new
key is entered on the remote using a remote console command. Because of this, the operator
must select a key roll time which balances the operational needs of the network against
preserving the strength of the ACC Key.
88

iDX Release 3.0
Automatic Beam Selection (ABS) and TRANSEC
ACC Key Roll

The ACC Key Roll is similar to the Dynamic Key Roll discussed in TRANSEC Dynamic Key
Management on page85.
Note:
ACC Key Roll time is configurable. For details see the appendix titled
1. When a modem first enters the network, it receives the Current ACC Key and the
Next ACC Key. The Next ACC Key is the one that will be used after the next Key Roll.
2. Remotes switch to the Next ACC Key based on the downstream key pointer.
3. Once a Key Roll occurs, the remote uses the Next ACC Key.
4. After the Key Roll, the Next ACC Key becomes the Current ACC Key, and a new Next ACC
Key is generated.
5. The new pair of ACC Keys is pushed to all the remotes.
Manual ACC Key Update

When commissioning a new remote, the installer must manually enter the ACC Key. The
current ACC key must also be manually entered on a remote that has missed two consecutive
ACC key rolls.
The ACC Key is protected by a user-generated passphrase of any length. The current ACC
Key must be determined at the hub and transferred to the remote modem. Transferring the
key to the remote is done outside of the iDirect system. It can be accomplished verbally (over
a secure phone line) or through a secure file transfer.
The procedures for determining the current ACC Key and for updating the ACC Key on a
remote are contained in the appendix titled Managing TRANSEC Keys in the iBuilder User
Guide.

iDirect supports Automatic Beam Selection (ABS), in which a single NMS manages multiple
hubs with multiple downstream carriers. Typically these hubs are in different geographic
locations, in order to provide connectivity across multiple satellite footprints. When using the
ABS feature, a remote can be configured in multiple networks in iBuilder. The remote
autonomously selects a network to join based on the remotes geographic location and map
data supplied by the NMS mapserver. The remote steps through a list of potentially-available
networks, searching for a downstream carrier, until it successfully joins a network.
In a TRANSEC environment, the remote needs a valid Network Acquisition Key to acquire the
downstream carrier. If each network had its own Network Acquisition Key, the remote would
not have the correct key when it attempted to join a new network.
In order to provide seamless operation for ABS, all of the downstream carriers that a remote
can switch between use the same Network Acquisition Key. To accomplish this, a single Master
Global Key Distributor (GKD) generates and updates the Network Acquisition Key for all of the
downstream carriers that a remote can switch between. This Master GKD sends the key to the
other hubs for distribution to the remotes that are currently in their networks.

iDX Release 3.0
89
Note:
Dynamic Network Keys continue to be generated independently at each hub.
Because the Network Acquisition Keys must be distributed by a single Master GKD, secure and
reliable terrestrial connectivity must be established between hubs in an ABS system. In
addition, the terrestrial network routing and security must be configured to allow the hub
equipment from one location to communicate with the hub equipment at the other locations.
iDirect can provide the identifying information for this traffic to allow for proper terrestrial
network configuration.
To configure your system to propagate the same ACC Keys to the remotes from multiple hub
servers, you must set a network of GKDs to forward the ACC Keys from the Master GKD to each
hub server that distributes the ACC keys. A GKD can reside on an existing Protocol Processor
blade, NMS server, or it can run on a dedicated GKD Server machine.
For details on setting up your GKD Servers, see the appendix titled Managing TRANSEC Keys
in the iBuilder User Guide.
90

iDX Release 3.0
15 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 remotes 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.

iDX Release 3.0
91
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.
92

iDX Release 3.0
16 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 page93
Awakening Methods on page94
Enabling Remote Sleep Mode on page94
Power Consumption on page95
Note:
Sleep Mode is intended for use by non-roaming remotes with occasional

transmissions. It is not compatible with the Roaming Remote or Alternate
Downstream Carrier features.
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.

iDX Release 3.0
93
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 remotes router that the interface is down, and therefore the packets
from the local LAN are still passed to the remotes 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 12 on page95.
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:
94
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.

iDX Release 3.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 12.
Table 12. Power Consumption: Normal Operations vs. Remote Sleep Mode

iDX Release 3.0
95
Power Consumption
96

iDX Release 3.0
17 Automatic Beam
Selection
This section contains information pertaining to Automatic Beam Selection (ABS) for roaming
remotes.
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 system.
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
Note:
If you are using the iDirect TRANSEC feature for your ABS networks, you must
set up Global Key Distribution to ensure that the Network Acquisition Keys are
the same for all networks. A remote cannot roam from one TRANSEC network to
another unless these keys are the same. For details, see the Appendix
Note:
If the mobile remotes in your ABS networks exceed 150 mph, they must be
licensed for the High-Speed COTM feature. In addition, high-speed remotes
require special configuration. For details, see the appendix titled High-Speed
COTM Custom Keys and Optimizations in the iBuilder User Guide.

iDX Release 3.0
97
Theory of Operation
Theory of Operation
Since the term network is used in many ways, this chapter uses the term beam rather
than the term network to refer to an outroute and its associated inroutes.
ABS is built on iDirects existing mobile remote functionality. When a modem is in a particular
beam, it operates as a traditional mobile remote in that beam.
In an ABS system, 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 remotes
beams. Options files for roaming remotes, called consolidated options files, are described
in detail in the iBuilder User Guide.
As a remote 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 to the new beam, and to perform the switch,
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 remotes current location. However, by selecting Inhibit Tx (when beam
quality = 0) in the iBuilder Network dialog box, you can configure the network so that
remotes never attempt to join a beam if the quality of the beam at the current location is
zero. See the iBuilder User Guide for instructions on configuring a network in iBuilder.
The Map Server

In an ABS system, a map server is responsible for managing the iDirect beam maps for the
remotes in its networks. The map server reads the beam maps and waits for map requests
from remote modems. A single map server may be deployed (for example, on your NMS server
machine) or multiple instances of the map server may be deployed on processors that are colocated with the 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
98

iDX Release 3.0
Theory of Operation
beam maplet) that encompasses its current location. When the remote 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 typical beam maplet covers approximately 1000 km square.
In prior releases, when you started the iDirect NMS services on you NMS server machine, the
map server was automatically started with the other NMS processes. Beginning with iDX
Release 3.0, the map server is no longer an NMS process. Now, the map server runs as a
separate, stand-alone application.
For details on configuring and running a map server, see the Automatic Beam Selection
appendix in the iBuilder User Guide.
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 angle to the satellite is greater than the minimum
look angle. (A remote uses the minimum look angle defined for your satellite in iBuilder
unless it is overridden for the remote on the Remote Geo Location tab. See the Automatic
Beam Selection appendix in the iBuilder User Guide for details.)
A beam is usable unless an attempt to use it fails. A beam is considered unusable for a
period of one hour after the failure, or until all visible beams are unusable.
Note:
You can change the length of time that a remote considers beams to be
unusable by entering a custom key. (See the ABS appendix of the iBuilder User
Guide for details.)
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
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 can result in a beam becoming unusable include:
The NMS operator disables the modem instance in iBuilder.
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.
Unless the remote is in receive-only mode, anything that causes the remote to stop
transmitting and the receive line card to stop receiving the modem, 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.

iDX Release 3.0
99
Theory of Operation
The remote antenna declares loss-of-lock.
The antenna declares a blockage.
Beam map data places the remote in receive-only mode.
An Evolution eP100 remote has its mute signal asserted.
The remote has been configured as Rx Only in iBuilder.
Note:
The Evolution eP100 is a custom form-factor remote satellite router that is not
generally available for purchase.
Selecting a Beam without a Map

Under certain circumstances the remote may not have a beam maplet that covers its current
location. When this occurs, the remote uses a round-robin selection algorithm, trying each
visible, usable beam defined in its options file in turn for five minutes until the remote joins a
network. This can occur under various conditions:
When a remote is being commissioned.
If the remote 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.
Note:
By default, a remote will continue to operate without a map as described

above. However, you can add a remote custom key that tells the remote to
mute its transmitter when the remote does not have a maplet that covers its
current location. See the Automatic Beam Selection appendix in the iBuilder
User Guide for details.
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 software must be
written specifically for each protocol. The following antenna protocols are currently
supported:
Orbit-Marine AL-7104
Schlumberger SpaceTrack 4000
SeaTel DAC
Open AMIP
OpenAMIP is an ASCII-based protocol developed by iDirect and used to exchange information

between the remote modem and an antenna controller. It allows the modem and controller to
exchange the information necessary for the modem to initiate and maintain satellite
100

iDX Release 3.0
Theory of Operation
communications via the antenna. The OpenAMIP protocol is defined in the document titled
Open Antenna Modem Interface Protocol (AMIP) Specification.
A steerable, stabilized antenna must know its geographical location in order to point the
antenna. The antenna includes a GPS receiver for this purpose. The remote must also know its
geographical location to select the correct beam and to compute its distance from the
satellite. The remote periodically commands the antenna controller to send the current
location to the modem.
IP Mobility
Communications to the customer intranet (or to the Internet) are automatically reestablished after a beam switch-over. The process of joining the network after a new beam is
selected uses the same internet routing protocols that are already established in the iDirect
system. When a remote joins a beam, the Protocol Processor for that beam begins advertising
the remote's IP addresses to the upstream router using the RIP protocol. When a remote
leaves a beam, the Protocol Processor for that beam withdraws the advertisement for the
remote's IP addresses. When the upstream routers see these advertisements and withdrawals,
they communicate with each other using the appropriate IP protocols to update their routing
tables. This permits other devices on the Internet to send data to the remote over the new
path with no manual intervention.
Calculation of Initial Transmit Power

The optimal initial transmit power that a remote should use for upstream carrier acquisition
varies with geographic location. As the remote moves across the satellite footprint, or when it
switches to a new beam, the EIRP budgeted for the link changes. In addition, for flat plate
antennas with multiple plates, the beam gain varies with the satellite elevation. Therefore,
the initial transmit power should be calculated based on the EIRP of the current location and
(if applicable) the gain variation of the antenna as a function of elevation. Otherwise, the
power may be set too high, potentially over-driving the satellite and/or violating FAA
regulations; or the power may be set too low, preventing the modem from acquiring the
beam.
The remote modem considers the following values when calculating the initial transmit
power:
The EIRP budgeted for the link at the current location as received from the beam map
The Initial Transmit Power Offset determined at commissioning and configured on the
iBuilder Remote VSAT tab
If applicable, the variation in antenna gain for the satellite elevation at the remotes
current location. This value is interpolated from the set of discrete Elevation / Gain pairs
configured in the iBuilder Reflector dialog box.
During acquisition, the remote performs the following steps to determine the initial transmit
power:
1. The remote retrieves the EIRP for the current location from the map server.
2. The remote adds the Initial Transmit Power Offset from the configuration file.

iDX Release 3.0
101
Theory of Operation
3. If Elevation / Gain pairs are configured for the Reflector then:

a. The remote calculates the satellite elevation based on geographic location.
b. The remote calculates the gain variation of the antenna for the elevation using the
data points provided in the configuration file.
c. The remote adds the gain variation to the other two factors to arrive at the initial
transmit power.
Once the remote has acquired the carrier, the UPC algorithm takes over to regulate the Tx
power during operation.
Note:
If the beam map is not available, the remote uses the Initial Tx Power
configured on the Remote Information Tab to acquire the beam.
The Initial Transmit Power Offset is determined at remote commissioning after the remote has
acquired the downstream carrier using the standard commissioning procedure. The
commissioning options file should be pre-configured with an Initial Tx Power Offset of -30 dB.
Once the remote has locked onto the carrier, the UPC algorithm has stabilized, and the beam
map is available to the remote, the installer should enter the console command to determine
the Initial Transmit Power Offset. The network operator should then enter the value returned
by the command on the iBuilder Remote VSAT tab. (See the ABS appendix of the iBuilder User
Guide for details, including the console command syntax.)
Elevation / Gain pairs can be configured on the iBuilder Reflector dialog box. Each data point
represents the variation in antenna gain for a specific satellite elevation. During beam
acquisition, the remote modem uses these data points to interpolate the gain variation for
the satellite elevation at the remotes current location. It then adds the gain variation to the
Initial Transmit Power Offset determined at commissioning and the EIRP budgeted for the link
at the current location to arrive at the initial transmit power for acquisition.
Receive-Only Mode for ABS Remotes

If a remote is placed in receive-only mode, the remote stops transmitting on the upstream
TDMA carrier but continues to receive the downstream carrier and remains in network. A
remote in receive-only mode does not transmit, but it does receive and forward multicast
traffic.
Typically, remotes using the ABS feature are placed in receive-only mode based on data read
from the beam map. Specifically, if the Tx Gain of the remotes current location on the map is
zero, then the remote will not transmit. This allows the reception of broadcasts in geographic
regions where transmission is prohibited by regulation.
Note:
You can disable this feature on a remote by entering a custom key. (See the ABS
appendix of the iBuilder User Guide for details.)
An Evolution eP100 remote may also be placed in receive-only mode through assertion of a
hardware mute signal on the modem. This allows an external computer to determine that
transmission is prohibited for reasons such as aircraft take off and landing.
A remote may also be configured as Rx Only on the iBuilder Remote Information tab. This is a
general feature and is not restricted to remotes using the ABS feature. If a remote is
configured as Rx Only in iBuilder, the remote will never transmit.
102

iDX Release 3.0
Operational Scenarios
Multiple Map Servers per Network

In previous iDirect releases, an ABS network was limited to a single map server process
running at the NMS that supplied the beam map data to all remote modems. This restriction
has been removed. To enable receive-only operations, and for general system robustness, the
system now supports multiple map servers per network. This allows the deployment of a local
map server for each remote modem.
When the ABS feature is enabled at the NMS, a single IP address is configured for the map
server process running at the NMS. That IP address is then downloaded to the remote modems
in their options files and used by the remote modems to communicate with the map server.
To run a local version of the map server you must override the map server IP address in the
remotes option file by entering a remote-side custom key defining the local map servers IP
address within the private address space of the remote. This custom key must be applied to
each remote with a local map server. (See the ABS appendix of the iBuilder User Guide for the
definition of this custom key.)
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.
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.

iDX Release 3.0
103
Adding a Remote
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.
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. As the remote is moving, the modem periodically receives the current location from
antenna.
2. While in the beam, the antenna automatically tracks the satellite.
3. As the remote approaches the edge of the current maplet, the modem requests a new
maplet from the map server.
4. When the remote reaches a location where the maplet shows a better beam, the remote
switches by doing the following:
a. Computes best beam.
b. Saves best beam to non-volatile storage.
c. Reboots.
d. Reads the new best beam from non-volatile storage.
e. Commands the antenna to move to the correct satellite and beam.
104

iDX Release 3.0
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. The remote drops out of the network.
b. The remote receives a maplet indicating that a better beam exists.
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 (by default) 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.
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.

iDX Release 3.0
105
106

iDX Release 3.0
18 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 Backup and Restore utilities. 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
your release for complete NMS redundancy procedures.

iDX Release 3.0
107
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
108

iDX Release 3.0
19 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
without 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
minimizes the amount of satellite bandwidth required for an iDirect carrier. In iDirect
networks, the guard band may be set to as low as 20% on broadcast Downstream carriers and
on TDMA and SCPC upstream carriers. The smaller the guard band, the greater the cost
savings for networks deployed with iDirect remote modems.
In early versions of the iDirect firmware, a 40% guard band was required between carriers.
Figure 42 shows an overlay of the original spectrum and the optimized spectrum.
Figure 42. Overlay of Carrier Spectrums

iDX Release 3.0
109
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%. 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

A lower bandwidth requirement between carriers makes it possible to fit a higher bit rate
carrier into the same satellite bandwidth. Therefore, with a lower guard band requirement, a
network operator can increase the bit rate of existing carriers without purchasing additional
bandwidth.
A consequence of reducing the guard band is that increasing the bit rate of the carrier to fill
the extra bandwidth requires slightly more power. For example, 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 and the guard band is reduced from 40% to 20%. In this example,
FEC rate 0.793 with 4 kbit Turbo Product Code is used.
Carrier Parameters using 40% guard band:
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)
Carrier Parameters using 20% guard band

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)
Reducing the guard band from 40% to 20% achieves a 16.67% improvement in user data rate 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.
110

iDX Release 3.0
Decreasing Channel Spacing to Gain Additional Bandwidth
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
because the automatic frequency control algorithm uses the hub receivers 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 when determining the carrier parameters.
The example that follows accounts for a frequency stability range for systems using
equipment with more significant stability concerns. Using the second set of carrier
parameters (with 20% guard band) in the previous example and a total frequency stability of
+/-5 kHz, compute the new carrier parameters:
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)
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 carrier bandwidth optimization by
reworking the 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 TDMA upstream carriers of 1 Mbps each. FEC rate 0.793 with 4 kbit TPC
is used for all carriers in this example. Figure 43 shows that an additional Upstream carrier
may be added by reducing the channel spacing of the existing carriers from 1.4 to 1.2.

iDX Release 3.0
111
Decreasing Channel Spacing to Gain Additional Bandwidth
Figure 43. Adding an Upstream Carrier By Reducing Carrier Spacing
112

iDX Release 3.0
20 Alternate Downstream
Carrier
This chapter provides information about iDirects Alternate Downstream Carrier feature. It
contains the following sections:
Background on page113
Feature Description on page113
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 an iNFINITI
downstream 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

iDX Release 3.0
113
Feature Description
configured alternate downstream carrier which is the new primary carrier. At that point the
remote will acquire the network on the new carrier.
iDirect supports two types of downstream carriers: DVB-S2 and iNFINITI. A DVB-S2 downstream
carrier can serve as the alternate carrier for an iNFINITI primary carrier. Similarly, an iNFINITI
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
iNFINITI carrier and an Evolution X5 remote can receive either a DVB-S2 or an iNFINITI 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 iNFINITI or DVB-S2

requires one firmware package for iNFINITI and another firmware package for
DVB-S2. If you plan to use the Alternate Downstream Carrier feature to switch
between iNFINITI and DVB-S2, you should load both packages onto your line
card. See the chapter titled Converting Between iNFINITI 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_LOCAL]
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.
114

iDX Release 3.0
21 Feature and Chassis

Licensing
You must license your chassis slots and certain iDirect features before you can enable them in
iBuilder. Please see the iDirect Features and Chassis Licensing Guide for detailed information
on how to obtain, install and activate iDirect licenses.
iDirect Licensing Requirements

This section lists all licenses available for your iDirect networks. You cannot configure slots in
your hub chassis or enable the software features listed here without a valid license.
iDirect licenses fall into the following categories:
Chassis Slot Licences are required to enable the chassis slots on both 4-slot and 20-slot
hub chassis. These licenses must be imported using the iBuilder License Toolbar.
Hardware-Specific Feature Licenses are software feature licenses available for specific
remote modems or hub line cards. These licenses must be imported using the iBuilder
License Toolbar.
Hardware-Specific Feature Licenses include:
Evolution X3 AES Link Encryption
Evolution X5 AES Link Encryption
Evolution eP100 AES Link Encryption
Evolution X5 Upstream Spread Spectrum
Evolution eP100 Upstream Spread Spectrum
Evolution e8350/e800/e850mp High-Speed COTM
Evolution eP100 High-Speed COTM
Evolution X3 SCPC Return
Evolution X5 SCPC Return
Evolution XLC-11 Upstream Spread Spectrum
Evolution XLC-11 Downstream Spread Spectrum
Evolution eM1D1 TRANSEC
Evolution eM0DM/XLC-M TDMA multichannel support
Evolution eM0DM/XLC-M SCPC return multichannel support

iDX Release 3.0
115
iDirect Licensing Requirements
NMS Server Feature Licenses are software feature licenses that apply to all iDirect
networks managed by an NMS server. To enable these licenses, a valid license file must be
copied to a specific directory on your NMS server.
NMS Server Feature Licenses include:
Geographic Map
Global NMS
SkyMonitor
VNO User Groups
CNO User Groups
Protocol Processor Blade Feature Licenses are software feature licenses that apply to all
iDirect modems controlled by a Protocol Processor Blade server. To enable these licenses,
a valid license file must be copied to a specific directory on your PP blade server.
PP Blade Server Feature Licenses include:
Encryption License (for Link Encryption and TRANSEC)
High-speed COTM licenses are required for mobile remotes that exceed the speed of 150 mph.
A mobile remote determines its speed by monitoring its geographic location over time. If an
unlicensed remote calculates three consecutive times that it has exceeded 150 mph, the
remote issues the event COTM License Violated and all user traffic to the remote is
stopped. When the remotes speed falls below the 150 mph limit, the violation is reset and
the remote resumes carrying user traffic.
Note:
For more information on the High-Speed COTM feature, see the appendix titled
High-Speed COTM Custom Keys and Optimizations in the iBuilder User Guide.
For information on importing your Chassis Slot Licenses and your Hardware-Specific Feature
Licenses into iBuilder and for validating your Hub Slot Group Licenses in iBuilder, see the
116

iDX Release 3.0
22 Hub Line Card Failover
This chapter describes basic hub line card failover concepts, transmit/receive verses receiveonly line card failover, failover sequence of events, and failover operation from a users 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 cards role immediately. If the standby is a cold standby for the failed line card, it
needs to flash a new options file and reset. The estimated time to complete a line card
failover to a warm standby is less than 10 seconds; the estimated time to complete a failover
to a cold standby is less than 1 minute.
Note:
If your Tx line card fails, or you only have a single Rx line card and it fails, all
remotes must re-acquire into the network after failover is complete.
Warm Standby versus Cold Standby Line Card Failover

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

iDX Release 3.0
117
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.

The flow chart that shows the sequence of events performed on the NMS server to execute a
complete failover is shown in Figure 44. 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.
118

iDX Release 3.0
Event Server
determines line
card has failed
Configuration
Server is notified
Automatic
failover
selected ?
NO
DONE.
iMonitor will show the line

card in the Alarm state
.
User may initiate manual
failover if desired
.
YES
User initiates
manual failover
Prerequisites Met ?
NO
DONE.
User will have already

been notified that failover
cannot happen
.
YES
All subsequent operations are
handled by the Configuration
Server unless otherwise noted
Configuration
Server powers
down slot of failed
card .
Send ACTIVE
options file of
failed card to
spare and reset
NO
Warm
Standby?
YES
Send command to
spare to switch
role from Standby
to Primary ; send
ACTIVE options
file of failed card
but DO NOT reset
Apply necessary
changes to puma
serial
(
number )
Former spare gets

role of failed card
Tx
( TxRx
,
or
, Rx )
and carrier inroute
/
group assignments
Configuration Server must

grab exclusive write lock at
this point. Any user with the
lock will lose the lock and
any unsaved changes
.
Failed unit gets

new role :Failed .
Figure 44. Line Card Failover Sequence of Events

iDX Release 3.0
119

Technical Reference Guide iDX Release 3.0

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Technical Reference Guide iDX Release 3.0

Hochgeladen von

Copyright:

Verfügbare Formate

Technical Reference Guide

iDX Release 3.0

June 07, 2011

Document Name: REF_Technical Reference Guide iDX 3.0_Rev A_06072011.pdf