REFTechnical Reference Guide IDX 33rev B02102015

Technical Reference Guide
iDX Release 3.3
February 10, 2015

iDX Release 3.3
Copyright 2015 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.3_Rev B_02102015.pdf

Document Part Number: T0000598
ii

iDX Release 3.3
Revision History
The following table shows all revisions for this document. To determine if this is the latest
revision, check the TAC Web site at http://tac.idirect.net.
Revision
Date
Updates
07/31/2014
First release of document for iDX 3.3
02/10/2015
Added Group Delay and Downstream Performance topic to the DVB-S2

Roll-off section

iDX Release 3.3
iii
iv

iDX Release 3.3
Contents
List of Figures
About
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
Document Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx
1 iDirect System Overview
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
IP Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
2 DVB-S2 in iDirect Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

DVB-S2 Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7
DVB-S2 in iDirect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
DVB-S2 Downstream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
ACM Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Quality of Service in DVB-S2 ACM Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Remote Nominal MODCOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Remote Maximum MODCOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Fixed Bandwidth Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Enhanced Information Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Scaling Factors for Fixed Bandwidth Allocation . . . . . . . . . . . . . . . . . . . . . . . . 15
Bandwidth Allocation Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
DVB-S2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
DVB-S2 Performance Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
iDX Release 3.3
3 Modulation Modes and FEC Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

iDirect Modulation Modes And FEC Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
DVB-S2 Modulation Modes and FEC Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2D 16-State Inbound Coding for DVB-S2 Networks . . . . . . . . . . . . . . . . . . . . . . . . 19
TDMA Waveform Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4 iDirect Spread Spectrum Networks
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Overview of Spread Spectrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Spread Spectrum Hardware Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Supported Forward Error Correction (FEC) Rates . . . . . . . . . . . . . . . . . . . . . . . . 24
TDMA Upstream Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
SCPC Upstream Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5 Multichannel Line Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Multichannel Line Card Model Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Multichannel Line Card Receive Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Multichannel Line Card Restrictions and Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6 SCPC Return Channels
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Hardware Support and License Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Single Channel vs. Multichannel SCPC Return . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
SCPC Return Feature on Remotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
VNO for SCPC Return. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7 Adaptive TDMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Theory of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Short Term Adaptivity and Real-Time Resource Management .
Medium Term Adaptivity . . . . . . . . . . . . . . . . . . . . . . . .
Long Term Adaptivity . . . . . . . . . . . . . . . . . . . . . . . . . .
C/N0 and C/N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 35
. 36
. 37
. 38
. 38
Adaptive TDMA Configuration and Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Remote Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Reference Carrier Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Remote Carrier Constraint Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 41
vi

iDX Release 3.3
8 Multicast Fast Path
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Multicast Fast Path Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Multicast Fast Path Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Multicast Fast Path Encryption Key Management . . . . . . . . . . . . . . . . . . . . . . . . . 44
Enabling Multicast Fast Path Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Multicast Fast Path Encryption Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9 QoS Implementation Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Quality of Service (QoS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
QoS Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
iDirect QoS Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Classification and Scheduling of IP Packets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Service Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Packet Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Priority Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Class-Based Weighted Fair Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Best Effort Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Application Throughput . . . . . . . . . .
Minimum Information Rate . . . . . . .
Committed Information Rate (CIR) . .
Maximum Information Rate (MIR) . . .
Free Slot Allocation . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
Compressed Real-Time Protocol (cRTP) .
Sticky CIR . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 52
. 53
. 54
. 54
. 54
. 55
. 55
Application Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
TDMA Slot Feathering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Packet Segmentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Application Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Maximum Channel Efficiency vs. Minimum Latency . . . . . . . . . . . . . . . . . . . . . . . 56
Group QoS . . . . . . . . . . . .
Group QoS Structure . . . .
Bandwidth Pool . . . .
Bandwidth Group . . .
Service Group . . . . .
Application . . . . . . .
Service Profiles . . . .
Remote Profiles . . . .

iDX Release 3.3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 57
. 57
. 58
. 58
. 58
. 59
. 59
. 60
vii
Group QoS Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Physical Segregation Scenario . . . . . . . . . . . . . . . . . . . . . . . . . .
CIR Per Application Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tiered Service Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Third Level of Segregation by VLAN Scenario . . . . . . . . . . . . . . . . .
The Shared Remote Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . .
Remote Service Group Scenario . . . . . . . . . . . . . . . . . . . . . . . . .
DVB-S2 ACM Scenario 1: Scaled Aggregate CIRs Below Partitions CIR . .
DVB-S2 ACM Scenario 2: Scaled Aggregate CIRs Exceeds Partitions CIR .
Bandwidth Allocation Fairness Relative to CIR . . . . . . . . . . . . . . . .
Bandwidth Allocation Fairness Relative to MODCOD . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 60
. 60
. 61
. 62
. 63
. 65
. 66
. 68
. 70
. 71
. 72
10 TDMA Initial Transmit Power. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

All Remotes Need To Transmit Bursts in the Same C/N Range . . . . . . . . . . . . . . . . 76
What Happens When Initial Tx Power Is Set Incorrectly? . . . . . . . . . . . . . . . . . . . 76
When Initial Transmit Power is Too High . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
When Initial Transmit Power is Too Low . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
11 Uplink Control Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

TDMA Uplink Control . . . . . . . . . .
Acquisition . . . . . . . . . . . . . . .
Network Operation . . . . . . . . . .
UCP Correction Processing. . .
UCP Symbol Timing . . . . . . .
UCP Frequency Tracking . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
UCP Power Control and Fade Detection .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 79
. 79
. 81
. 81
. 81
. 82
. 82
SCPC Return Uplink Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

UCP Power Adjustment for SCPC Upstream Carriers . . . . . . . . . . . . . . . . . . . . . 85
Viewing UCP Statistics in iMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
12 Remote Idle and Dormant States
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Feature Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
13 Verifying Error Thresholds Using IP Packets
. . . . . . . . . . . . . . . . . . . 95
Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
TDMA Upstream Threshold Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Upstream Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Upstream Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
viii

iDX Release 3.3
DVB-S2 Downstream Threshold Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Downstream Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
14 Global NMS Architecture
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
How the Global NMS Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Sample Global NMS Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
15 Security Best Practices
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Hub and NMS Server Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Network Isolation and External Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Server Password Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Secure Server Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Encryption of Backup Files Before Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Clearing Data from Decommissioned Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
NMS Client Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
User Passwords and Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Client Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Remote Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Console Password Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Clearing Data from Decommissioned Remotes and Line Cards . . . . . . . . . . . . . . . 103
DNS Queries on Satellite (SAT0) Interface of Remote . . . . . . . . . . . . . . . . . . . . . 104
16 Global Protocol Processor Architecture
. . . . . . . . . . . . . . . . . . . . . . 105
Remote Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

De-coupling of NMS and Data Path Components. . . . . . . . . . . . . . . . . . . . . . . . . 105
17 Distributed NMS Server
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Distributed NMS Server Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

iBuilder and iMonitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
18 Transmission Security (TRANSEC)
. . . . . . . . . . . . . . . . . . . . . . . . . . . 109
What is TRANSEC? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

iDirect TRANSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
TRANSEC Key types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
DVB-S2 Downstream TRANSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Upstream TRANSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

iDX Release 3.3
ix
Disguising Remote Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Generating the TDMA Initialization Vector . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Upstream TRANSEC Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
ACQ Burst Obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

TRANSEC Dynamic Key Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
TRANSEC Remote Admission Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
ACC Key Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
ACC Key Roll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Manual ACC Key Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Automatic Beam Selection (ABS) and TRANSEC . . . . . . . . . . . . . . . . . . . . . . . . . 121
19 Remote Sleep Mode
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Feature Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Awakening Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Operator-Commanded Awakening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Activity Related Awakening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Enabling Remote Sleep Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Power Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
20 Remote Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Acquisition Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Acquisition Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Superburst Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Advantages of Superburst. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Considerations When Using Superburst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Acquisition Carrier Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Transmit Power Adjustment for Non-reference Carriers . . . . . . . . . . . . . . . . . 131
Ability to Acquire When No Traffic Carrier Is Available . . . . . . . . . . . . . . . . . . 131
21 Automatic Beam Selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Automatic Beam Selection Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Theory of Operation . . . . . . . . . . . . . .
Overview . . . . . . . . . . . . . . . . . . . .
iDirect Beam Map File and Map Server . .
Beam Selection . . . . . . . . . . . . . . . .
Conveyance Beam Map File. . . . . . . . .
Regulatory Considerations . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 134
. 134
. 134
. 135
. 136
. 136

iDX Release 3.3
Beam Characteristics: Visibility and Usability . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Selecting a Beam without a Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Controlling the Antenna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
IP Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Initial Transmit Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Calculation of Initial Transmit Power . . . . . . . . . . . . . . . . . . .
Setting the Initial Transmit Power Offset . . . . . . . . . . . . . . . . .
6. Determining the Initial Transmit Power Offset for Other Beams .
Receive-Only Mode for ABS Remotes . . . . . . . . . . . . . . . . . . . . . .
Multiple Map Servers per Network . . . . . . . . . . . . . . . . . . . . . . .
Operational Scenarios . .
Creating the Network .
Adding a Remote . . . .
Normal Operations . . .
Mapless Operations . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Blockages and Beam Outages .
Error Recovery . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22 Hub Geographic Redundancy
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 139
. 139
. 140
. 140
. 141
. 143
. 143
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 144
. 144
. 144
. 145
. 145
. 146
. 146
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Configuring Wait Time Interval for an Out-of-Network Remote . . . . . . . . . . . . . . 148
23 Carrier Occupied Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Considerations When Determining Guard Band . . . . . . . . . . . . . . . . . . . . . . . . . 150
DVB-S2 Roll-Off Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Group Delay and Downstream Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Improving Throughput by Reducing Guard Band . . . . . . . . . . . . . . . . . . . . . . . . 153
DVB-S2 Guard Band Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Adjacent Channel Interference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
24 Alternate Downstream Carrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
25 Transmit Key Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

iDX Release 3.3
xi
26 NMS Database Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Benefits of NMS Database Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Feature Description . . . . . . . . . . . . . . . . . . . .
NMS Database Replication Architecture . . . . . . .
Replicating iDirect NMS Databases . . . . . . . . . .
NMS Database Replication on a Distributed NMS . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 162
. 162
. 163
. 164
Setting Up NMS Database Replication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Enable Replication to a Single Backup Server . . . . . . . . . . . . . . . . . . . . . 167
Add Two Additional Backup NMS Servers as MySQL Slaves . . . . . . . . . . . . . . 168
Enable Replication to a Redundant NMS Server . . . . . . . . . . . . . . . . . . . . 168
Stop Replication to a Backup NMS Server . . . . . . . . . . . . . . . . . . . . . . . . 168
Force Recreation of an Existing MySQL Slave . . . . . . . . . . . . . . . . . . . . . . 169
Stop Replication on a Backup NMS Server . . . . . . . . . . . . . . . . . . . . . . . . 169
Monitoring NMS Database Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Events And Warnings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Viewing Replication Conditions in iMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Recovering from Replication Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
27 Feature and Chassis Licensing
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
iDirect Licensing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
28 Hub Line Card Failover
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Basic Failover Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Warm Standby versus Cold Standby Line Card Failover . . . . . . . . . . . . . . . . . . . 175
Failover Sequence of Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
29 NMS, PP and GKD Server Port Assignments
. . . . . . . . . . . . . . . . . . . 179
NMS Server Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

PP Controller Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
GKD Server Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Protocol Processor Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Port Assignments for NMS/Upstream Router Traffic Flow . . . . . . . . . . . . . . . . . . 182
30 VRRP and Remote LAN Port Monitoring. . . . . . . . . . . . . . . . . . . . . . . 183

Virtual Router Redundancy Protocol (VRRP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
xii

iDX Release 3.3
VRRP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

Configuring VRRP on iDirect Remotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
VRRP Route Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Remote LAN Port Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Monitoring VRRP Status and Remote LAN Status . . . . . . . . . . . . . . . . . . . . . . . . 193
Remote Console Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

iDX Release 3.3
xiii
List of Figures
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
xiv
1-1. Sample iDirect Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1-2. iDirect IP Architecture Multiple VLANs per Remote . . . . . . . . . . . . . . . . . . . . 3
1-3. iDirect IP Architecture VLAN Spanning Remotes . . . . . . . . . . . . . . . . . . . . . . 4
1-4. iDirect IP Architecture Classic IP Configuration . . . . . . . . . . . . . . . . . . . . . . . 5
2-1. Physical Layer Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2-2. Feedback Loop from Remote to Protocol Processor . . . . . . . . . . . . . . . . . . . . 11
2-3. Feedback Loop with Backoff from Line Card to Protocol Processor . . . . . . . . . . 11
2-4. Total Bandwidth vs. Information Rate in Fixed Bandwidth Operation . . . . . . . . 13
2-5. EIR: Total Bandwidth vs. Information Rate as MODCOD Varies . . . . . . . . . . . . . 14
3-1. TDMA Burst Format with Distributed Pilots . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4-1. Spread Spectrum Network Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7-1. Control Elements of iDirects ATDMA System . . . . . . . . . . . . . . . . . . . . . . . . 36
8-1. Enabling Multicast Fast Path Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9-1. Remote and QoS Profile Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
9-2. iDirect Packet Scheduling Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
9-3. Group QoS Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
9-4. Physical Segregation Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
9-5. CIR Per Application Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
9-6. Tiered Service Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
9-7. Third Level VLAN Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
9-8. Shared Remote Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
9-9. Remote Service Group Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
9-10. Scaled Aggregate CIRs Below Partitions CIR . . . . . . . . . . . . . . . . . . . . . . . . 69
9-11. Scaled Aggregate CIRs Exceed Partitions CIR . . . . . . . . . . . . . . . . . . . . . . . 70
9-12. Bandwidth Allocation Fairness Relative to CIR . . . . . . . . . . . . . . . . . . . . . . . 71
9-13. Bandwidth Allocation Fairness Relative to Nominal MODCOD . . . . . . . . . . . . . 72
10-1. Optimal C/N Detection Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
10-2. Skewed C/N Detection Range: Initial Transmit Power Too High . . . . . . . . . . . 77
10-3. Skewed Detection Range: Initial Transmit Power Too Low . . . . . . . . . . . . . . . 77
11-1. TDMA Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
11-2. iBuilder: Maximum Speed and Guard Interval for Inroute Group . . . . . . . . . . . 82
11-3. Uplink Power Control During Remote Fade . . . . . . . . . . . . . . . . . . . . . . . . . 84
11-4. iMonitor UCP Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
11-5. Remote Upstream Acquisition Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
12-1. Active, Idle and Dormant State Change Diagram . . . . . . . . . . . . . . . . . . . . . 90
12-2. Configuring Active, Idle and Dormant States . . . . . . . . . . . . . . . . . . . . . . . . 90
12-3. Upstream Service Level with Trigger State Change Selected . . . . . . . . . . . . . 92
14-1. Global NMS Database Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

iDX Release 3.3
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
14-2.
16-1.
17-1.
18-1.
18-2.
18-3.
18-4.
18-5.
18-6.
18-7.
18-8.
21-1.
21-2.
21-3.
23-1.
23-2.
26-1.
26-2.
26-3.
26-4.
26-5.
26-6.
28-1.
30-1.
30-2.
30-3.
30-4.
30-5.
30-6.
30-7.
Sample Global NMS Network Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . .

Protocol Processor Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sample Distributed NMS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . .
DVB-S2 TRANSEC Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Disguising Which Key is Used for a Burst . . . . . . . . . . . . . . . . . . . . . . . . . .
Code Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generating the Upstream Initialization Vector . . . . . . . . . . . . . . . . . . . . .
Upstream ACQ Burst Obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Key Distribution Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Key Roll Data Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Host Keying Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iMonitor Probe: Remote Power Section . . . . . . . . . . . . . . . . . . . . . . . . . .
Remote VSAT Tab: Entering the Initial Transmit Power Offset . . . . . . . . . . .
Absolute vs. Generated G/T Contours for Two Beams . . . . . . . . . . . . . . . . .
Spectral Mask Illustrating 20% and 5% Roll Off Factors . . . . . . . . . . . . . . . .
Adjacent Carrier Interference Example . . . . . . . . . . . . . . . . . . . . . . . . . .
NMS Database Replication Architecture . . . . . . . . . . . . . . . . . . . . . . . . . .
NMS Database Replication from a Single Primary NMS Server . . . . . . . . . . . .
NMS Database Replication on a Distributed NMS . . . . . . . . . . . . . . . . . . . .
Enabling NMS Database Replication to a Backup Server . . . . . . . . . . . . . . . .
Replication Conditions Viewed in iMonitor . . . . . . . . . . . . . . . . . . . . . . . .
Replication Error Resulting in Active Condition in iMonitor . . . . . . . . . . . . .
Line Card Failover Sequence of Events . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of a Virtual Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example VRRP Configuration in iBuilder . . . . . . . . . . . . . . . . . . . . . . . . . .
Changing the Frequency of Router Priority Messages . . . . . . . . . . . . . . . . .
Changing a Remotes Router Priority Message Timeout . . . . . . . . . . . . . . . .
Example of LAN Port Monitoring Configuration for Multiple Ports in iBuilder . .
Example LAN Port Monitoring Configuration for Single Port in iBuilder . . . . . .
VRRP and Remote LAN Status Events in iMonitor . . . . . . . . . . . . . . . . . . . .

iDX Release 3.3
100
106
107
112
113
114
115
116
117
118
119
141
141
142
151
154
162
163
165
168
171
171
177
185
187
190
191
192
193
193
xv
List of Tables
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
Table
xvi
2-1. DVB-S2 Modulation and Coding Schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2-2. ACM MODCOD Scaling Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4-1. Spread Spectrum: TDMA Upstream Specifications . . . . . . . . . . . . . . . . . . . . . . 25
4-2. Spread Spectrum: SCPC Upstream Specifications . . . . . . . . . . . . . . . . . . . . . . 25
5-1. Multichannel Receive Line Card Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . 29
6-1. Single Channel vs. Multichannel SCPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7-1. Sample Adaptive Inroute Group Configuration . . . . . . . . . . . . . . . . . . . . . . . . 40
19-1. Power Consumption: Normal Operations vs. Remote Sleep Mode . . . . . . . . . . 125
23-1. Increasing Information Rate by Reducing Guard Band . . . . . . . . . . . . . . . . . . 153
23-2. DVB-S2 Guard Band Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
29-1. NMS Server Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
29-2. pp_controller Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
29-3. GKD Server Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
29-4. samnc Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
29-5. Protocol Processor Port Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
29-6. Port Designations for NMS/Upstream Router Traffic . . . . . . . . . . . . . . . . . . . 182
30-1. PP Routing Table Operations: LAN Port Monitoring and VRRP . . . . . . . . . . . . . 192

iDX Release 3.3
About
Purpose
The Technical Reference Guide provides detailed technical information on iDirect technology
and major features as implemented in iDX Release 3.3.
Audience
The Technical Reference Guide is intended for iDirect Network Operators, network architects,
and anyone upgrading to iDX Release 3.3.
Contents
The Technical Reference Guide contains the following major sections:
iDirect System Overview
DVB-S2 in iDirect Networks
Modulation Modes and FEC Rates
iDirect Spread Spectrum Networks
Multichannel Line Cards
SCPC Return Channels
Adaptive TDMA
Multicast Fast Path
QoS Implementation Principles
TDMA Initial Transmit Power
Uplink Control Process
Remote Idle and Dormant States
Verifying Error Thresholds Using IP Packets
Global NMS Architecture
Security Best Practices
Global Protocol Processor Architecture
Distributed NMS Server

iDX Release 3.3
xvii
xviii
Transmission Security (TRANSEC)
Remote Sleep Mode
Automatic Beam Selection
Hub Geographic Redundancy
Carrier Occupied Bandwidth
Alternate Downstream Carrier
Transmit Key Line
NMS Database Replication
Feature and Chassis Licensing
Hub Line Card Failover
NMS, PP and GKD Server Port Assignments

iDX Release 3.3
Document Conventions
This section illustrates and describes the conventions used throughout this document.
Convention Description
Example
Used when the user is required to

enter a command at a command
line prompt or in a console.
Enter the command:
Terminal
Output
Used when showing resulting

output from a command that was
entered at a command line or on a
console.
crc report all
Screen
Reference
Used when referring to text that

appears on the screen on a
Graphical User Interface (GUI).
1. To add 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.
The Remote dialog box has a number of userselectable tabs across the top. The Information
tab is visible when the dialog box opens.
Used to show all hyperlinked text

within a document or external
links such as web page URLs.
For instructions on adding a line card to the

network tree, see Adding a Line Card on page 108.
Command
Hyperlink
cd /etc/snmp/
8350.3235 : DATA CRC [

1]
8350.3502 : DATA CRC [5818]
8350.4382 : DATA CRC [ 20]
NOTE: A Note is a statement or other notification that adds, emphasizes, or

clarifies essential information of special importance or interest.
CAUTION: A Caution highlights an essential operating or maintenance procedure,
practice, condition, or statement which, if not strictly observed, could result in
damage to, or destruction of, equipment or a condition that adversely affects
system operation.
WARNING: A Warning highlights an essential operating or maintenance
procedure, practice, condition or statement which, if not strictly observed, could
result in injury or death or long term health hazards.

iDX Release 3.3
xix
Getting Help
The iDirect Technical Assistance Center (TAC) is available to provide assistance 24 hours a day,
365 days a year. Software user guides, installation procedures, FAQs, and other documents
that support iDirect products are available on the TAC Web site. Access the TAC Web site at
http://tac.idirect.net.
The TAC may also be contacted by telephone or e-mail.
Telephone: (703) 648-8151
E-mail: tac@idirect.net
For sales or product purchasing information contact iDirect Corporate Sales at the following
telephone number or e-mail address:
Telephone: (70 3) 648-8000
E-mail: SALES@idirect.net
iDirect produces documentation that is technically accurate, easy to use, and helpful to our
customers. Please assist us in improving this document by providing feedback. Send comments
to techpubs@idirect.net.
Document Set
The following iDirect documents are available at http://tac.idirect.net and contain
information relevant to installing and using iDirect satellite network software and equipment.
xx
Release Notes
Software Installation Guide or Network Upgrade Procedure Guide
iBuilder User Guide
iMonitor User Guide
Installation and Commissioning Guide for Remote Satellite Routers
Features and Chassis Licensing Guide
Software Installation Checklist/Software Upgrade Survey
Link Budget Analysis Guide

iDX Release 3.3
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.
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 satellite router
and the appropriate external VSAT equipment.
TDMA upstream carriers are configured in groups called Inroute Groups. Multiple Inroute
Groups can be associated with one downstream carrier. Any remote configured to transmit to
the hub on a TDMA upstream carrier is part of an Inroute Group. The specific TDMA upstream
carrier on which the remote transmits at any given time is determined dynamically during
operation. A remote that transmits on a dedicated SCPC return channel is not associated with
an Inroute Group. Instead, the dedicated SCPC upstream carrier is directly assigned to the
remote and to the hub line card that receives the carrier.
Prior to iDX Release 3.2, all TDMA upstream carriers in an Inroute Group were required to
have the same symbol rate, modulation and error coding. With the introduction of Adaptive
TDMA in iDX Release 3.2, the symbol rate and MODCOD of the carriers in an Inroute Group may
vary from carrier to carrier. Remotes in an Inroute Group move from carrier to carrier in real
time based on network conditions. Furthermore, with Adaptive TDMA, the individual carrier
MODCODs can adjust over time to optimize network performance for changing network
conditions. Adaptive TDMA allows for significantly less fade margin in the network design and
optimal use of upstream bandwidth during operation.
Figure 1-1 on p. 2 shows an example an iDirect network. The network consists of one
downstream carrier; two Inroute Groups providing the TDMA return channels for a total of
1200 remotes; and three remotes transmitting dedicated SCPC return channels to the hub.

iDX Release 3.3
System Overview
Figure 1-1. Sample iDirect Network

iDirect software has flexible controls for configuring Quality of Service (QoS) and other
traffic-engineered solutions based on end-user requirements and operator service plans.
Network configuration, control, and monitoring functions are provided by the integrated NMS.
The iDirect software provides a long list of features, including:
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
For a complete list of available features in all iDirect releases, see the iDirect Software
Feature Matrix available on the TAC Web site.

iDX Release 3.3
IP Network Architecture
An iDirect network interfaces to the external world through IP over Ethernet ports on the
Remote Satellite Routers and the Protocol Processor servers at the hub. The examples in
Figure 1-2 on p. 3, Figure 1-3 on p. 4, and Figure 1-4 on p. 5 illustrate the IP level
configurations available to a Network Operator.
The iDirect system allows a mix of networks that use traditional IP routing and VLAN based
configurations. This provides support for customers with conflicting IP address ranges. It also
allows multiple independent customers at individual remote sites by configuring multiple
VLANs on the same remote.
Figure 1-2. iDirect IP Architecture Multiple VLANs per Remote

iDX Release 3.3
Figure 1-3. iDirect IP Architecture VLAN Spanning Remotes

iDX Release 3.3
Figure 1-4. iDirect IP Architecture Classic IP Configuration

iDX Release 3.3

iDX Release 3.3
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. iDirect supports DVB-S2 in both TRANSEC and non-TRANSEC networks.
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/s/Hz)
8PSK (3 bits/s/Hz)
16APSK (4 bits/s/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 only supported for long BBFRAMEs.
The DVB-S2 standard does not support every combination of modulation and coding. DVB-S2
specifies the MODCODs shown in Table 2-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.3
DVB-S2 Key Concepts
Table 2-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:
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 such as those used by iDirect remotes must
be designed to handle dynamic MODCOD variation.
CCM (Constant Coding and Modulation) specifies that every BBFRAME is transmitted at the
same MODCOD using long frames. Long BBFRAMEs are not used in iDirect. Instead, a
constant MODCOD can be achieved by setting the Maximum and Minimum MODCODs of the
outbound carrier to the same value. (See the iBuilder User Guide for details on
configuring DVB-S2 carriers.)

iDX Release 3.3
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. Although iDirect does not support VCM, it does allow configuration
of specific MODCODs for multicast streams.
DVB-S2 in iDirect
Beginning with iDX Release 3.2, iDirect only supports DVB-S2 downstream carriers. Networks
with iNFINITI downstream carriers are only supported in earlier releases. All iDirect hardware
supported in this release can operate in a DVB-S2 network. The iBuilder User Guide lists all
available line card and remote model types.
iDirect DVB-S2 networks support ACM on the downstream carrier with all modulations up to
16APSK. An iDirect DVB-S2 network always uses short DVB-S2 BBFRAMES. iDirect also allows
the Network Operator to configure multiple multicast streams and specify the multicast
MODCOD of each stream.
DVB-S2 Downstream
A DVB-S2 downstream can only be configured as ACM. An ACM downstream 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. In iDirect, CCM is configured by
limiting the MODCOD range to a single MODCOD.
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 21.
PLHEADER: signals
MODCOD and frame
length (always S/2 BPSK)
Pilot symbols:
unmodulated
carrier
Data symbols:
QPSK, 8PSK,
16APSK, or 32APSK
Figure 2-1. 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 Msym/s and highest MODCOD 16APSK 8/9)
is approximately 155 Mbps. Multiple protocol processors may be required to support high
traffic to multiple remotes.

iDX Release 3.3
DVB-S2 in iDirect
iDirect uses DVB-S2 Generic Streams with a proprietary variation of the LEGS (Lightweight
Encapsulation for Generic Streams) protocol for encapsulation of downstream data between
the DVB-S2 line cards and remotes. 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
Adaptive Coding and Modulation (ACM) allows remotes operating in better signal conditions to
receive data on higher MODCODs by varying the MODCOD of data targeted to each remote to
match its current receive capabilities.
Not all data is sent to each remote at its most efficient 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 receive this information reliably.
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 SNR thresholds per MODCOD are
determined during hardware qualification for each remote model type. The Spectral
Efficiency of iDirect remotes at the threshold SNR for each MODCOD is documented in the
iDirect Link Budget Analysis Guide.
The hub adjusts the MODCODs of the transmissions to the remotes by means of the feedback
loop shown in Figure 2-2 on page11. 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
downstream packing efficiency.
10

iDX Release 3.3
DVB-S2 in iDirect
Figure 2-2 and Figure 2-3 show the operation of the SNR feedback loop and the behavior of
the line card and remote during fast fade conditions. Figure 2-2 shows the basic SNR reporting
loop described above.
Protocol Processor
Incoming user
data
Tx Line Card
Downstream throughput
(varies based on
MODCOD assigned )
New MODCOD
Remote
internal queue
SNR compared to
SNR threshold:
new MODCOD
selected
Rx Line card
SNR measured and
reported to PP
Figure 2-2. Feedback Loop from Remote to Protocol Processor

Figure 2-3 page 11 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.
Protocol Processor
New MODCOD
Tx Line Card
Incoming user
data
Downstream throughput
(varies based on
MODCOD assigned)
Reduction in
downstream data
Tx ine card queue
too full? Allocate
less user data
SNR compared to
SNR threshold:
New MODCOD
selected
Tx line card reports

internal queue fullness
to PP
Remote
internal queue
Rx Line Card
SNR measured and
reported to PP
Figure 2-3. Feedback Loop with Backoff from Line Card to Protocol Processor

iDX Release 3.3
11
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 fixed MODCOD
downstream carriers. (See QoS Implementation Principles on page47.) However, with DVB-S2
in ACM Mode, the same amount of user data (in bits per second) occupies more or less
downstream bandwidth, depending on the MODCOD at which it is transmitted. This is true
because user data transmitted at a higher MODCOD requires less bandwidth than it does at a
lower MODCOD.
When configuring QoS in iBuilder, a Network Operator 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

The Network Operator 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 mobile network where the Clear Sky MODCOD depends on the
position of the remote terminal, 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

The Network Operator 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 the operator to limit the Maximum MODCOD for a remote
to a value lower than the DVB-S2 carriers Maximum MODCOD and higher than or equal to the
remotes Nominal MODCOD. This is important if the network link budget supports higher
MODCODs but some remote LNBs 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.
12

iDX Release 3.3
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 2-4 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.
Figure 2-4. 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 configuration of 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.

iDX Release 3.3
13
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 2-5. 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.
Figure 2-5. EIR: Total Bandwidth vs. Information Rate as MODCOD Varies
14

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

Table 2-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-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)
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.3
15
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 page68 and page70.
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 three configurable options for bandwidth allocation fairness:
Allocation Fairness Relative To CIR
Allocation Fairness Relative to Nominal MODCOD
Allocation Fairness Relative to Operating MODCOD
Enabling or disabling any of these options for a Group QoS node or for a physical remote
affects how CIR and MIR bandwidth is apportioned during bandwidth contention. Allocation
Fairness Relative to MODCOD only affects bandwidth allocation on DVB-S2 ACM outbound
carriers. Allocation Fairness Relative to CIR affects bandwidth allocation in general.
For a detailed explanation of these options, see the Quality of Service chapter in the iBuilder
User Guide. For sample scenarios illustrating the use of these options, see Bandwidth
Allocation Fairness Relative to CIR on page71 and Bandwidth Allocation Fairness Relative to
MODCOD on page72.
DVB-S2 Configuration
Various iBuilder settings affect the operation of DVB-S2 networks. For details on configuring
DVB-S2, see the iBuilder User Guide. The following areas are affected:
Downstream Carrier Definition: When adding an ACM DVB-S2 downstream carrier, the
Network Operator 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, iBuilder does not
allow selection of an information rate or transmission rate for a DVB-S2 carrier as an
alternative to the symbol rate, since these rates vary dynamically with changing
MODCODs.
However, iBuilder provides a MODCOD Distribution Calculator that estimates the overall
Information Rate for the carrier based on the distribution of the Nominal MODCODs of the
remotes in the network. Access this calculator by clicking the MODCOD Distribution
button on the DVB-S2 Downstream Carrier dialog box. A similar calculator allows
estimation of CIR and MIR bandwidth requirements at various levels of the Group QoS
tree.
16

iDX Release 3.3
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. The Network Operator can configure
different MODCODs for user multicast traffic by selecting Multicast MODCODs for 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. These parameters are configured on
the Remote QoS tab in iBuilder.
DVB-S2 Line Card Definition: When adding a DVB-S2 line card, the Network Operator 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: DVB-S2 network-level parameters control how a DVBS2 network reacts to fade conditions when ACM is enabled for the downstream carrier.
DVB-S2 Performance Monitoring

iMonitor allows a Network Operator to monitor the following characteristics of 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.
The Network Operator 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, these
statistics indicate the percentage of time a remote is operating at its Nominal MODCOD
and at other MODCODs. Although independent of traffic, this allows the comparison of a
remotes actual operating point with its configured (or contractual) operating point so
that adjustments can be made in the case of discrepancies.
For details, see the iMonitor User Guide.

iDX Release 3.3
17
DVB-S2 in iDirect
18

iDX Release 3.3
3 Modulation Modes and

FEC Rates
This chapter describes the carrier types, Modulation Modes and Forward Error Correction
(FEC) rates that are supported in iDX Release 3.3.
iDirect Modulation Modes And FEC Rates

iDX Release 3.3 supports star networks with DVB-S2 downstream carriers. Remotes transmit to
the hub on either TDMA upstream carriers or SCPC return channels. iDirect only supports 2D
16-State Inbound Coding on TDMA upstream carriers. TPC Error Correction is no longer
supported on upstream carriers in iDirect networks.
The Link Budget Analysis Guide (available at http://tac.idirect.net) specifies the Modulation
Modes and FEC rates available for DVB-S2 downstream carriers, SCPC return channels, and
TDMA upstream carriers using 2D 16-State Inbound Coding. The Link Budget Analysis Guide
also contains specific Eb/No threshold values for each FEC rate and Modulation combination
for all carrier types.
DVB-S2 Modulation Modes and FEC Rates

Beginning with iDX Release 3.2, all downstream carriers in iDirect networks conform to the
DVB-S2 standard. iNFINITI downstream carriers (and iNFINITI hardware) are no longer
supported. Therefore, in this release, only Evolution line cards in DVB-S2 mode can be used to
transmit downstream carriers. Similarly, only Evolution remotes in DVB-S2 mode can receive
downstream carriers.
iDirect supports QPSK, 8PSK and 16APSK modulation modes for DVB-S2 downstream carriers.
All supported DVB-S2 MODCODs (including FEC rates) are listed in Table2-1 on page8.
iDirects DVB-S2 implementation is described in DVB-S2 in iDirect Networks on page7.
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: 100 bytes (88 byte IP payload), 170 bytes
(158 byte IP payload), and 438 bytes (426 byte IP payload). The 100 byte payload size has a 16
byte larger payload than the QPSK .66 1K TPC block supported in earlier releases. This ensures
the same low latency at call connection for VoIP applications. The 438 byte payload size is

iDX Release 3.3
19
TDMA Waveform Enhancements
similar to the 4k TPC block and provides low TDMA overhead.The 170 byte payload size
provides an intermediate option when considering the trade off between bandwidth
granularity and minimizing TDMA overhead.
2D 16-State Coding has a number of benefits when compared to TPC and LDPC coding:
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 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.
NOTE: Because 2D 16-State coding is superior to TPC, TPC inbound coding is no
longer supported in iDirect networks.
The Link Budget Analysis Guide defines all upstream Modulation and Coding rates available
per payload size when using 2D 16-State Inbound Coding over TDMA and SCPC upstream
carriers. The LBA Guide also specifies EbN0 values and C/N thresholds for all upstream
MODCOD/block size combinations. See the LBA Guide sections Upstream TDMA Carrier
Performance Specifications and Upstream SCPC Carrier Performance Specifications for
details.

The iDirect TDMA burst formats are optimized on an ongoing basis in order to reduce
overhead, to increase the tolerance to imperfections and channel effects, and to improve
demodulation performance. Improvements in the state-of-the-art signal processing algorithms
and increases in processing power are exploited to provide performance improvements over
time.
The TDMA burst formats used prior to iDX Release 3.2 can be summarized as follows:
Non-spread BPSK and QPSK bursts consist of a known preamble followed by data-bearing
symbols.
8PSK bursts consist of a preamble, followed by three blocks of data-bearing symbols.

"Mid-ambles" of known symbols are present between the first and second data symbol
block, and between the second and third data symbol block.
Spread Spectrum bursts are similar to 8PSK non-spread bursts in terms of the distribution
of known symbols. Direct-sequence spreading is applied to the complete burst.
The payload of each burst consists of one code word of a 16-state, parallel-concatenated
code referred to as 2D 16-State Code as discussed on page 19. 2D 16-State is a very high
performance code. With perfect synchronization, it is generally within 0.6 dB to 0.7 dB of the
theoretical bounds specified by the block size, coding rate, and modulation type. The 2D 16State code performance has been optimized for all block sizes supported by iDirect: 100
bytes, 170 bytes, and 438 bytes.
Beginning in iDX Release 3.2 the waveform formats for BPSK, QPSK and 8PSK employ the
Distributed Pilot TDMA (DP-TDMA) scheme to improve demodulator synchronization accuracy.
20

iDX Release 3.3
This permits more coding rates to be supported for each block size; better LBA C/N
performance thresholds; and increased frequency offset tolerance across all modulation
types. Spread Spectrum still employs the same waveform formats as in pre-3.2 releases,
except that BPSK with a spreading factor of 1 is no longer required or supported. The regular
BPSK waveforms with distributed pilots perform better than BPSK with spreading factor of 1
used in earlier releases.
The overhead symbols used for synchronization in DP-TDMA non-spread modes are distributed
throughout the burst, rather than concentrated in one block or a small number of large blocks
as in prior releases. This arrangement, sometimes referred to as preamble-less distributed
pilots, is shown in Figure 3-1.
guard
Pilot Blk
1
Payload Blk 1
Pilot Blk
2
Payload Blk 2
Pilot Blk
3
Payload Blk Np
Pilot Blk
Np
Payload Blk n+1
Lgd
Lp
L1
Lp
L1
Lp
L1
Lp
L2
Figure 3-1. TDMA Burst Format with Distributed Pilots

Highlights of performance improvements that were introduced in iDX Release 3.2 with this
new waveform structure include:
Support for several 2D 16-State coding rates for each Modulation and Block size. This
provides more granularity in C/N dynamic range for both homogenous inroute groups of
static carriers and inroute groups using Adaptive TDMA.
C/N Performance improvement up to 1.5 dB or equivalent spectral efficiency in certain

combinations of modulation, coding rates and block sizes. Refer to the Link Budget
Analysis Guide for performance specifications.
Frequency tolerance of up to 1.5% of the symbol rate across all modulations
Improved TDMA burst detection performance

iDX Release 3.3
21
guard
22

iDX Release 3.3
4 iDirect Spread Spectrum

Networks
This chapter provides information about Spread Spectrum technology in iDirect networks. It
contains the following major sections:
Overview of Spread Spectrum on page23
Spread Spectrum Hardware Components on page24
Supported Forward Error Correction (FEC) Rates on page24
TDMA Upstream Specifications on page25
SCPC Upstream Specifications on page25
Overview of 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 power density is required. A sample Spread Spectrum network
diagram is shown in Figure 4-1.
Figure 4-1. 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).

iDX Release 3.3
23
Spread Spectrum Hardware Components
Spread Spectrum is employed in iDirect networks to minimize adjacent satellite 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.
iDirect designed the Spread Spectrum feature for COTM and ASI mitigation on very small
aperture terminals. Although this feature may be useful for other applications such as
overpowering interference or hiding carriers from hostile jammers, customers should consult
with iDirect sales engineering to ensure that their specific application is appropriate for this
technology.
iDirect Spread Spectrum is an extension of BPSK modulation. The feature is supported on
TDMA and SCPC upstream carriers. Spread spectrum is not available on DVB-S2 downstream
carriers. The signal is spread over wider bandwidth according to a Spreading Factor (SF)
selected for the carrier in iBuilder. For an SCPC upstream carrier, the Network Operator can
select No Spreading, 2, 4 or 8. For a TDMA upstream carrier, the Network Operator can select
No Spreading, 2, 4, 8 or 16. SF 16 is only supported for Evolution e8350, iConnex
e800/e850mp remotes.
NOTE: Only Spreading Factor 2 is supported for Evolution e150 remotes.
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.
NOTE: The following model types require an iDirect licence to use the upstream
Spread Spectrum feature: Evolution XLC-11 line cards; Evolution X5, and X7
remotes.
Spread Spectrum Hardware Components

The following iDirect line card model types can receive Spread Spectrum carriers:
Evolution eM1D1 (No license required; TDMA or SCPC return)
Evolution XLC-11 (License required; TDMA only)
The following iDirect remote model types can transmit Spread Spectrum carriers:
Evolution e8350, iConnex e800/e850mp (No license required; TDMA or SCPC return)
Evolution X5 (License required; TDMA only; Spreading Factors 2, 4 and 8)
Evolution X7 (License required; TDMA only; Spreading Factors 2, 4 and 8)
Evolution e150 (No license required; TDMA only; Spreading Factor 2 only)
Supported Forward Error Correction (FEC) Rates

The upstream FEC rates that can be used for Spread Spectrum carriers in this release are
specified in the Link Budget Analysis Guide.
24

iDX Release 3.3
TDMA Upstream Specifications
TDMA Upstream Specifications

The Spread Spectrum specifications for TDMA upstream transmissions are defined in Table 4-1.
Table 4-1. Spread Spectrum: TDMA Upstream Specifications
PARAMETERS
VALUES
ADDITIONAL INFORMATION
Modulation
BPSK
Other Modulations not supported
Spreading Factor
No Spreading, 2, 4, 8 or 16
SF = 2 only for e150 remotes

SF = 16 restricted to e8350, e800 and e850mp
Symbol Rate
64 ksym/s - 7.5 Msym/s
Chip Rate
7.5 Mchip maximum
BER Performance
Refer to the iDirect Link Budget

Analysis Guide
Maximum Frequency Offset
1.5% * Fsym
Unique Word Overhead
128 symbols
Occupied Bandwidth
1.2 * Chip Rate
Hardware Platforms
Evolution e8350, e800, e850mp,

X5, X7, e150
SCPC Upstream Specifications

The Spread Spectrum specifications for SCPC upstream transmissions are defined in Table 4-2.
Table 4-2. 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
Refer to the iDirect Link Budget Analysis

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

iDX Release 3.3
ADDITIONAL INFORMATION
Other Modulations not supported
25
SCPC Upstream Specifications
26

iDX Release 3.3
5 Multichannel Line Cards
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. Evolution XLC-M line cards are
capable of simultaneously receiving up to 16 narrowband TDMA upstream carriers of up to 128
ksym per carrier.
Beginning with iDX Release 3.2, TRANSEC is supported on eM0DM line cards in multichannel
mode.
Multichannel Line Card Model Types

There are two iDirect Multichannel Line Card model types:
Evolution XLC-M
Evolution eM0DM
Only XLC-M line cards support up to 16 narrowband TDMA receive carriers. Only eM0DM line
cards support TRANSEC.
NOTE: 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 configuring a Multichannel Line Card in iBuilder, 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 selectable for Evolution eM1D1 line
cards. It cannot be selected on multichannel line cards.

iDX Release 3.3
27
Multichannel Line Card Restrictions and Limits
NOTE: Prior to iDX Release 3.0, XLC-M and eM0DM line cards were available with
single channel TDMA support only. When upgrading from a pre-iDX 3.0 release,
these line cards are automatically set to Single Channel TDMA receive mode.

The following restrictions apply to Multichannel Line Cards:
28
All upstream carriers received by an Evolution XLC-M or eM0DM line card must be the
same carrier type. A Multichannel Line Card cannot 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 32 TDMA upstream carriers.
TDMA upstream carriers received by a Multichannel Line Card can have different
Modulations, FEC Rates, and Symbol Rates. However the Payload Size must be the same
for all carriers.
The center frequency and symbol rate of an adaptive carrier received by a Multichannel
Line Card must remain constant across all Inroute Group Compositions; only the MODCOD
of the carrier can change.
All TDMA upstream carriers received by a Multichannel Line Card must be on the same
transponder and within a 36 MHz window.
SCPC upstream carriers received by a Multichannel Line Card can have different
Modulations, FEC Rates, and Symbol Rates.
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 5-1.)
There are per-carrier symbol rate limits on Multichannel Line Cards for both TDMA and
SCPC. (See Table 5-1.)
There are composite symbol rate limits on Multichannel Line Cards for TDMA. (See Table
5-1.) The sum of the symbol rates of all return channels received by the line card cannot
exceed these limits.
There are composite information rate limits on Multichannel Line Cards for both TDMA
and SCPC. (See Table 5-1.) The sum of the information rates of all return channels
received by the line card cannot exceed these limits.
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.

iDX Release 3.3
Table 5-1 shows various parameters associated with the Multichannel Line Cards.
Table 5-1. Multichannel Receive Line Card Parameters
NOTE: For Upstream TDMA and SCPC Modulation Modes and FEC Rates, see
Modulation Modes and FEC Rates on page19.
The iBuilder User Guide contains procedures for configuring Multichannel Line Cards.

iDX Release 3.3
29
30

iDX Release 3.3
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 capable of transmitting and
receiving an SCPC return channel and the licenses required per unit.
The following remote model types can transmit a dedicated SCPC return channel to the hub:
Evolution e8350, iConnex e800/e850mp (No license required)
Evolution X3 (No license required)
Evolution X5 (No license required)
The following line card model types can 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: An Evolution eM1D1 line card cannot transmit a downstream carrier and
receive an SCPC return channel simultaneously. To configure an eM1D1 to receive
an SCPC return channel, the Line Card Type must be set to receive-only. See the
iBuilder User Guide for details.

iDX Release 3.3
31
Single Channel vs. Multichannel SCPC Return
Single Channel vs. Multichannel SCPC Return

Table 6-1 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 6-1. 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
NOTE: SCPC upstream carriers received by a multichannel line card can have
different symbol rates, modulation modes and FEC rates. For more information on
multichannel SCPC return, see Multichannel Line Cards on page27.
NOTE: For supported 2D 16-State Inbound Coding Modulation Modes, FEC Rates
and Block sizes see the Link Budget Analysis Guide.
SCPC Return Feature on Remotes

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 to switch remotes between TDMA and SCPC.
However, when switching from one carrier type to another, the remote must be reset after
the configuration changes are applied. Typically, the remote will be out of the network for
approximately 1.5 to 2 minutes when switching 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 apportion
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.
NOTE: To conserve bandwidth, QoS Service Level statistics are available in
iMonitor by custom key only. See the section titled Viewing Service Level
Statistics in the iMonitor User Guide for details.
The Move operation in the iBuilder tree allows the Network Operator to switch a remote
between TDMA and SCPC. During the move, select the SCPC line card and channel or the
32

iDX Release 3.3
VNO for SCPC Return
TDMA Inroute Group to which the remote is moving 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 configured 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 easy switching of 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: When a remote is moved to an SCPC carrier that does not have the initial
and maximum power values preconfigured for that carrier, the remote becomes
incomplete in iBuilder. If this happens, configure the power settings on the remote
for that carrier for the remote to 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.3
33
VNO for SCPC Return
34

iDX Release 3.3
7 Adaptive TDMA
Beginning with iDX Release 3.2, iDirect supports Adaptive TDMA. Adaptive TDMA (ATDMA)
allows remotes to dynamically adapt their transmissions to the hub to use the optimal symbol
rate and Modulation and Coding (MODCOD) for current conditions. This can reduce the amount
of rain margin that must be designed into the upstream link, significantly improving clear sky
throughput of the remotes when compared to non-adaptive TDMA networks. Eliminating the
extent to which system resources must be reserved for worst-case conditions allows
additional resources to be used for data transmission. This is the same principle that underlies
the use of Adaptive Coding and Modulation (ACM) for DVB-S2 outbound carriers. (See DVB-S2
in iDirect Networks on page7.)
Theory of Operation
The core element of iDirect's adaptive TDMA system is an inroute group of heterogeneous
TDMA carriers supporting different transmission rates and providing different levels of
protection against adverse channel effects such as rain fade. Individual remotes are assigned
time slots on upstream carriers based on their current demand and capability, as determined
by the channel state. The configuration of the inroute group automatically adapts over time
to maximize the system efficiency.
An inroute group can be regarded as a fixed portion of space segment bandwidth and power
partitioned into TDMA carriers with different properties. A collection of carrier definitions
that can be assigned to an inroute group is called an Inroute Group Composition (IGC). The
IGC currently assigned to an inroute group determines the MODCODs of each carrier in the
inroute group at the present time. Up to three IGCs can be configured for a single inroute
group but only one IGC is assigned to the inroute group at any time.
An inroute group can include carriers with different symbol rates and MODCODs. The IGC
currently assigned to the inroute group defines the MODCODs of the various carriers in the
group. An adaptive carrier can change MODCODs from one IGC to another. When a new IGC is
assigned to the Inroute Group, the MODCODs of the individual adaptive carriers change
according to the newly-applied IGC definition. Note however that the symbol rates and center
frequencies of the individual carriers remain the same in all IGCs.
The MODCODs of the upstream carriers do not vary frame by frame. The protocol processor
assigns TDMA slots on the upstream carriers based on the upstream link conditions of the
individual remotes. In the short term, remotes adapt to changing conditions by frequency
hopping among carriers with different properties. Over time, the protocol processor may also
adjust the configuration of the inroute group by selecting different IGCs as network conditions
change. Whenever a different IGC is assigned to the inroute group, the MODCODs of the

iDX Release 3.3
35
Theory of Operation
upstream carriers change to match the configuration of the newly-selected IGC. Thus the
system automatically adapts in two ways: frame-by-frame through remote frequency hopping,
and longer term by selecting the optimal IGC for the prevailing conditions.
Figure 7-1 shows how Adaptive TDMA operates in an iDirect network for a single inroute
group.
Remote
Terminals
Constraints
Real-time
Real-time resource
resource management:
management:
Assign
Assign slots
slots in
in current
current composition
composition to
to
remotes,
remotes, respecting
respecting constraints
constraints on
on
the
the carriers
carriers they
theyy can
can use
use
Contention
level
Short-term
Short-term adaptivity:
adaptivity:
Determine
Determine which
which remotes
remotes can
can use
use which
which
carriers
carriers in
in the
the current
current Inroute
Inroute Group
Group
Composition
Comp
position
Inroute Group Composition 1
Compositon
choice
Medium-term
Medium-term adaptivity:
adaptivity:
Select
Select best
best among
among defined
defined Inroute
Inroute
Group
Group Compositions
Compositions
Statistics
Long-term adaptivity:
adaptivity:
Long-term
Design most
most suitable
suitable set
set of
of Inroute
Inroute
Design
Group Compositions
Compositions
Group
Bandwidth
Requests
Power, signal quality
Figure 7-1. Control Elements of iDirects ATDMA System

The following sections discuss the Adaptive TDMA control elements shown in Figure 7-1.
Short Term Adaptivity and Real-Time Resource Management

Short-term adaptivity operates in real time and considers only the current Inroute Group
Composition (IGC). The Upstream Control Process monitors the C/N of each remotes
upstream carrier as measured at the hub to determine the remotes nominal carrier. A
remotes nominal carrier is the upstream carrier with the highest threshold C/N0 the remote
can currently sustain and is allowed to use.
NOTE: Beginning with iDX Release 3.2, iDirect networks support Inroute Groups
with different sized upstream carriers. Because of this, C/N0 has replaced C/N as
the measurement of signal quality used to monitor and control remote
transmissions on the upstream carriers. See C/N0 and C/N on page38 for details.
36

iDX Release 3.3
Theory of Operation
Each remote is assigned slots on carriers with symbol rates and MODCODs that are estimated
to be within the remotes capabilities for the current link conditions. The slot assignment
algorithm attempts to allocate slots on the remotes nominal carrier. However, this is not
always possible due to the overall demand for upstream traffic slots in the inroute group.
Therefore, during periods of contention for upstream bandwidth, a remote may be assigned
slots on carriers that are less efficient or have lower peak throughput than the remotes
current nominal carrier once all slots matching the nominal carrier parameters have been
assigned. This does not affect the overall bandwidth efficiency, which is determined by the
IGC currently being used.
As in earlier releases, the bandwidth allocation algorithm schedules bursts in TDMA frames for
each remote in accordance with the rules and priorities defined by the Group QoS settings for
the inroute group. However, for Adaptive TDMA, the algorithm must also account for the
dynamic nature of the total capacity available for each remote since the subset of carriers on
which a remote is able to transmit can change according to the current link conditions.
As an example of short-term adaptivity, consider a remote experiencing a rain fade. When the
remote enters the fade, the C/N of the remotes bursts as measured at the hub drops, limiting
the set of upstream carriers on which the remote can successfully transmit. This causes the
Uplink Control Process to change the remotes nominal carrier to a more protected carrier
once all power headroom available on the current nominal carrier has been exhausted.
When allocating new bandwidth to the remote during the fade, the bandwidth allocation
algorithm only considers available slots on the more limited subset of carriers. Since the
remotes nominal carrier is set to a more protected carrier with lower throughput, the remote
is able to stay in the network at the expense of bandwidth efficiency and/or peak rate. When
the fade passes, the remotes nominal carrier is changed back to the more efficient carrier.
For more information on how the hub selects a remotes nominal carrier, see Uplink Control
Process on page79.
Medium Term Adaptivity

Medium-term adaptivity is the automated process of selecting the best Inroute Group
Composition for current network conditions. The frequency with which the IGC selection
algorithm executes can be configured in iBuilder. By default, the IGC selection algorithm
executes once per minute.
The goal of the IGC selection algorithm is to determine the IGC that best matches the current
overall state of the system. At each invocation, the algorithm carries out a trial scheduling of
a single frame for each defined IGC using demand levels that are computed statistically over
the preceding interval. The algorithm takes into account the total number of slots assigned
(capacity) as well as the level of bandwidth contentionthe number of slots that could not be
allocated due to lack of capacity. If the IGC selected by the algorithm is different from the
current IGC, then the carrier configuration for the inroute group is changed to the new IGC.
When events affecting many remotes are in progress, IGC selection is a compromise between
total capacity and the accepted level of contention on the most protected carriers. Userconfigurable parameters for the inroute group help to guide the IGC selection process. These
parameters include:
Update Interval: The frequency (in seconds) with which the IGC selection algorithm is
executed. The default is 60 seconds.

iDX Release 3.3
37
Theory of Operation
Fixed IGC: If the Network Operator selects Enable Fixed IGC, then a specific IGC must be
selected as the Fixed IGC. In that case, the IGC selection algorithm is not executed.
Allowed Dropout Fraction: During the trial scheduling of an IGC executed as part of the
IGC selection process, the algorithm calculates the number of remotes that theoretically
would drop out of the network if that IGC is selected for the inroute group. If the
algorithm estimates that the percentage of remotes unable to sustain transmissions on
the most protected carrier of the IGC would exceed the configured Allowed Dropout
Fraction, then that IGC is not selected. If the Allowed Dropout Fraction is exceeded for all
IGCs, the default IGC is selected for the inroute group. Note that remotes are never
dropped explicitly as a result of this assessment. Remotes are only dropped if they fail to
maintain the link during operation.
Default IGC: The IGC that is selected if the Allowed Dropout Fraction is exceeded for all
IGCs defined for the inroute group.
NOTE: A severe downlink fade is observed at the hub as simultaneous fading of all
remotes. iDirect recommends including a very robust IGC among those defined for
the inroute group to allow the system to operate during a severe downlink fade.
Long Term Adaptivity

Long-term adaptivity is a manual process which uses feedback provided by the operational
system to refine the IGC configurations. iMonitor screens provide graphs and statistical data
that allow Network Operators to observe Adaptive TDMA performance. The statistics used to
present this information on the iMonitor screens are logged by the NMS in the NRD Archive
database.
Using iMonitor, Network Operators can observe system operational statistics such as IGC
usage, the distribution of signal quality, and the number of remotes logged off due to network
conditions. These statistics can be used by the system planner to review and revise the IGC
definitions and system parameters discussed in the previous section.
See the iMonitor User Guide for more information.
C/N0 and C/N

With the introduction of Adaptive TDMA in iDX Release 3.2, most upstream TDMA signal
quality metrics in iBuilder, iMonitor and in the documentation are now expressed in terms of
C/N0, or carrier power to noise density ratio. In previous (non-adaptive) releases, the signal
quality was expressed in terms of C/N, or carrier power to noise power ratio. This section
explains why this metric was changed and the relationship between C/N and C/N0.
C/N depends on the bandwidth of the upstream carrier. Using C/N as the signal quality metric
makes it difficult to view inroute groups of upstream carriers with different symbol rates in a
unified way. Since Adaptive TDMA allows carriers in the same inroute group to have different
symbol rates, it is necessary to use a measure such as C/N0 that is independent of the signal
characteristics.
C/N is always qualified by a corresponding measurement bandwidth. The received carrier
power C has a certain value, given the various system parameters and link conditions.
However, the additive noise is defined in terms of its spectral density (N0); it has a much
larger bandwidth than the signal. The total noise power N in a receiver is the product of N0
38

iDX Release 3.3
Adaptive TDMA Configuration and Constraints
and the measurement bandwidth B. In iDirect documentation that uses C/N such as the Link
Budget Analysis Guide, B is assumed to equal to the symbol rate of the carrier.
An adaptive system must constantly evaluate and compare the received C/N on one carrier
with what can be achieved on another carrier. For example, if a line card is receiving a
remote at a C/N of 11 dB on a carrier with a symbol rate of 1 Msps, what can be achieved on
a 2 Msps carrier? In this example, the corresponding C/N on the 2 Msps carrier is 8 dB.
Although the carrier power C is the same for both carriers, doubling the bandwidth doubles
the noise power. Therefore, the C/N is halved (lowered by 3 dB). Rather than making
comparisons with arbitrary references (and risking mistakes and confusion), the iDirect
system uses C/N0 as the common measure.
C/N0 can be thought of as the C/N achievable in a bandwidth of 1 Hz. The fact that this is a
stand-alone measure which does not need to be qualified by any signal properties is the
primary reason that the iDirect system now uses C/N0 extensively to measure and
characterize upstream performance.
C/N0 is equal to C/N + 10log10(Symbol Rate) and is expressed in dBHz. For this example,
C/N0 = 11 + 10log10(1x106) = 8 + 10log10(2x106) = 71 dBHz
Demodulation thresholds can also be expressed in terms of C/N0. The carrier MODCOD
(modulation and coding combination) corresponds to a certain threshold C/N. The C/N
threshold combined with the symbol rate is used during operation to compute the carrier
threshold C/N0.
A remote is allowed to transmit on a given upstream carrier when the C/N0 that can be
achieved is greater than or equal to the C/N threshold C/N0 of the carrier. The C/N0 is
therefore a direct and unified measure of the ability to use any of the available carriers in the
inroute group. This is another useful property of C/N0.
System designers who are familiar with link budget calculations will also already be familiar
with C/N0. This is usually the first signal quality metric computed in a receiver. It is typically
defined as:
C/N0 = EIRP (Path loss) + (Receiver G/T) (Boltzmanns Constant)

When configuring upstream carriers in iBuilder, the Network Operator can either select
specific Modulation and Error Correction settings (as in earlier releases) or designate the
carrier as Adaptive. A carrier configured with a fixed MODCOD is referred to as a Static
carrier.
The MODCODs of an Adaptive carrier are configured when the Inroute Group Compositions are
defined for the Inroute group. After adding an Adaptive carrier to an inroute group, the
operator can select a different MODCOD for the carrier in each IGC. (See the iBuilder User
Guide for details.)
Both Static and Adaptive carriers can be included in any inroute group. While the MODCOD of
an Adaptive carrier can change from one IGC to another, the MODCOD of a Static carrier must
be the same in all IGCs. An inroute group containing only static carriers can have one and only
one IGC since the MODCODs of static carriers cannot change.
Both multichannel line cards and single channel line cards can be included in the same inroute
group. However, only multichannel line cards and receive-only eM1D1 line cards can receive

iDX Release 3.3
39
Adaptive carriers. An upstream carrier assigned to any other type of single channel line card
must be static. That is, the MODCOD of the carrier received by the line card cannot change
from one IGC to another.
The following constraints apply to the configuration of inroute groups and TDMA upstream
carriers:
Only upstream carriers assigned to eM0DM, XLC-M, or receive-only eM1D1 line cards can
be configured as Adaptive. All other upstream carriers must be static.
The upstream carrier Payload Block Size configured in iBuilder must be the same for all
carriers defined for any inroute group and in all IGCs.
A maximum of three IGCs can be configured for an inroute group.
All inroute groups have at least one IGC even if no Adaptive carriers are included.
To define multiple IGCs, an inroute group must have at least one Adaptive carrier.
For each carrier, the center frequency and symbol rate must be the same for all IGCs.
A different MODCOD can be selected for each Adaptive carrier in each IGC.
Spread Spectrum carriers must be Static. (The MODCOD must be the same for all IGCs.)
NOTE: TRANSEC carriers can be adaptive.
Table 7-1 shows an example of an inroute group containing four upstream carriers and three
Inroute Group Compositions.
Table 7-1. Sample Adaptive Inroute Group Configuration
Carrier ID
Static /
Adaptive
Center
Frequency
(MHz)
Symbol
Rate
(ksym/s)
IGC1
IGC2
IGC3
A1
Adaptive
1300.000
1024
8PSK 2/3
8PSK 2/3
QPSK 3/4
A2
Adaptive
1301.229
1024
8PSK 2/3
8PSK 2/3
QPSK 2/3
A3
Adaptive
1302.150
512
8PSK 6/7
8PSK 2/3
8PSK 2/3
S1
Static
1302.611
256
QPSK 1/2
QPSK 1/2
QPSK 1/2
The first three carriers (A1, A2 and A3) in Table 7-1 are Adaptive; the fourth carrier (S1) is
Static. Notice that the center frequency and symbol rate of each carrier remain constant
across all compositions. The MODCODs of the Adaptive carriers vary from IGC to IGC. The
MODCOD of the Static carrier is the same for all IGCs. The example in Table 7-1 was designed
for Ku band in the Amazon rain forest.
40

iDX Release 3.3
Remote Configuration
A number of parameters affect Adaptive TDMA operations for individual remotes. These
parameters are described in this section.
Reference Carrier Parameters

Reference carrier parameters are configured on the iBuilder Remote Information tab. These
parameters include Symbol Rate, MODCOD, Spreading Factor, Payload Block Size and TDMA
Initial Power.
The TDMA Initial Power is the transmit power that the remote uses to acquire the network
when the acquisition carrier parameters are the same as the remotes reference carrier.
However, a remote joining an inroute group may be asked to acquire on a carrier with
parameters that do not match its configured reference carrier. In that case, the remote must
adjust the TDMA Initial Power so that the acquisition burst is received by the hub line card at
the correct C/N. Therefore, TDMA Initial Power must be defined in relation to the other
reference carrier parameters entered into iBuilder. (For more details on network acquisition,
see Remote Acquisition on page127.)
If no suitable reference carrier is defined explicitly during commissioning, reference carrier
parameters should be defined as part of the operational configuration. The properties of the
reference carrier should be similar to those normally used by the remote in clear sky
conditions.
When an iDirect system is upgraded from a pre-iDX 3.2 release, the reference carrier
parameters are automatically set to match those of the upstream carriers in the remote's
inroute group as defined in the earlier release. If the remote is later used in an inroute group
with non-uniform carriers, adjustments will be made to the acquisition burst power based on
the reference carrier parameters determined during the upgrade.
NOTE: There is no requirement that a remotes reference carrier parameters
match any of the carriers defined by the Inroute Group Compositions assigned to
the remotes inroute group.
In an Adaptive system, it is crucial to set each remotes TDMA Initial Power and TDMA
Maximum Power correctly. Incorrect settings that did not adversely affect system operations
in earlier releases may cause problems in an Adaptive system. iDirect strongly advises
reviewing the procedures for setting these parameters to ensure they are correct for all
remotes before updating an inroute group to use Adaptive TDMA. These procedures are
contained in the Installation and Commissioning Guide for iDirect Satellite Routers.
CAUTION: Adaptive TDMA allows remotes to operate much closer to the maximum
allowed Power Spectral Density. Care must be taken to ensure the TDMA Initial
Power and TDMA Maximum Power of each remote are set accurately. In addition,
the effects of downlink fade must be accounted for in the link design.
Remote Carrier Constraint Parameters

Carrier constraint parameters for individual remotes are configured on the iBuilder Remote
QoS tab. These parameters include:
Minimum Symbol Rate: The minimum symbol rate (in ksym/s) of any upstream carrier on
which this remote is allowed to transmit.

iDX Release 3.3
41
Maximum C/N: The maximum C/N at which a remote is allowed to be received by the hub
line card. This parameter is determined at network design. A remote will not be assigned
slots on an upstream carrier if transmitting on that carrier would cause it to violate this
constraint.
Maximum Link Impairment (dB): The maximum amount of fade by this remote that is
allowed to influence the IGC selection. If a remotes fade exceeds its configured
Maximum Link Impairment, then the IGC selection algorithm treats the remote as if it
were in clear sky conditions.
NOTE: Maximum Link Impairment only affects IGC selection. It does not affect
the amount of bandwidth allocated to the remote.
42

iDX Release 3.3
8 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. Beginning
with iDX Release 3.2, iDirect has added support for encryption of Multicast Fast Path traffic.
The Multicast Fast Path feature is available on all remote model types. The remote model
types that can receive encrypted Multicast Fast Path traffic are listed on page 44.
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 much
higher throughput of multicast traffic.
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.
There is no requirement to use the Multicast Fast Path feature to transmit user multicast
traffic. Multicast implementations from releases that do not support Multicast Fast Path can
still be used for downstream multicast traffic. As in prior releases, NMS multicast traffic
continues to be transmitted as regular multicast traffic.
Multicast Fast Path Streams

A Network Operator can configure Multicast Fast Path streams in iBuilder by adding
downstream Multicast Applications on the Group QoS tab for a network and selecting the
Multicast Fast Path check box. iDirect supports a maximum of 16 Multicast Fast Path
Applications per network. Different QoS Application Profiles can be added for each of the 16
Multicast Fast Path streams, allowing the operator 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

iDX Release 3.3
43
Multicast Fast Path Encryption
processing by the remote software, effectively acting like a persistent multicast group on the
eth0 interface of the remote. Therefore, it is not necessary to explicitly configure a
persistent multicast group for the remote LAN interface for Multicast Fast Path streams.
However, iDirect does recommend configuration of persistent multicast groups in iBuilder for
Networks using Multicast Fast Path streams. This ensures that the Protocol Processor forwards
the multicast packets to the transmit line card for transmission on the downstream carrier.
See the section titled Configuring Remotes for Multicast Fast Path in the iBuilder User
Guide for details on configuring Multicast Fast Path.

Multicast Fast Path traffic can be encrypted on a per-network basis. When enabled, Multicast
Fast Path Encryption provides 256 bit AES encryption for all Fast Path multicast packets
transmitted on the downstream carrier.
Multicast Fast Path Encryption can be enabled for multicast streams received by the following
remote model types:
Evolution X3
Evolution X5
Evolution X7
Evolution e8350/e850mp/e800
Evolution X1 and Evolution e150 remotes support the Multicast Fast Path feature. However,
these model types cannot receive encrypted Multicast Fast Path traffic.
Note the following points regarding Multicast Fast Path Encryption:
Link Encryption licenses are required on all Protocol Processor blades that process
encrypted Multicast Fast Path traffic.
Link Encryption licenses are required for all Evolution X3, X5 and X7 remotes that receive
encrypted Multicast Fast Path traffic.
Remotes configured as Receive-Only drop all encrypted Multicast Fast Path traffic.
NMS multicast and other non-Fast Path multicast packets are not encrypted.
If Multicast Fast Path Encryption is enabled for a network, then all non-encrypted
multicast traffic is transmitted as non-Fast Path traffic.
There is a single Multicast Fast Path Encryption domain per network. All encrypted
Multicast Fast Path traffic in a network uses the same encryption / decryption keys.
Multicast Fast Path Encryption Key Management

When Multicast Fast Path Encryption is enabled, the Protocol Processor uses a network-wide
encryption key to encrypt all Multicast Fast Path traffic. The Protocol Processor transmits this
key to each remote that is required to decrypt Multicast Fast Path traffic after the remote
acquires the network. The Multicast Fast Path encryption key is not preserved across power
cycles of a remote.
Distribution of the Multicast Fast Path encryption key by the Protocol Processor to the
remotes is secured using the standard X.509 protocol. Each remote configured to receive
encrypted Multicast Fast Path traffic generates a unique X.509 public/private key pair. The
44

iDX Release 3.3
Protocol Processor uses the remotes X.509 public key to individually encrypt the Multicast
Fast Path encryption key, ensuring secure transport of the encryption key to the remote.
By default, the Multicast Fast Path encryption key is updated every 28 days. Because a remote
receives the 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 and receive the latest key. To
change the frequency of the Multicast Fast Path encryption key roll, create a network-level
custom key in iBuilder as follows:
1. Right-click the network in the iBuilder Tree and select ModifyItem.
2. Click the Custom tab.
3. Enter the following Custom Key:
[FASTPATH]
dyn_key_update_time_sec = <Seconds>
where <Seconds> is the new key update frequency in seconds.
4. Click OK to save the changes.
5. Right-click the network in the iBuilder Tree and select Apply ConfigurationNetwork to
download the changes.
NOTE: To disable key rolls for the network, set dyn_key_update_time_sec to
0.
Multicast Fast Path encryption keys are generated by the samnc process that runs on the
Protocol Processor blade responsible for multicast traffic. If the samnc process that generates
the keys restarts, or if multicast responsibility moves to a different blade, the blade
generates and distributes new keys, and the time to the next key roll is reset.

iDX Release 3.3
45
Enabling Multicast Fast Path Encryption

A Network Operator can enable Multicast Fast Path Encryption by selecting Multicast
Encryption on the Information tab of the Network in iBuilder (Figure 8-1) and applying the
network changes.
Figure 8-1. Enabling Multicast Fast Path Encryption

Refer to the section titled Configuring Remotes for Multicast Fast Path in the iBuilder User
Guide for details on configuring Multicast Fast Path.
Multicast Fast Path Encryption Monitoring

Failures to decrypt encrypted Multicast Fast Path packets are reported in iMonitor. The
remote generates the Multicast Fast Path Decryption Failed alarm (MCFP_DECRYPT_FAIL)
when it drops encrypted Multicast Fast Path packets due to a failed integrity check caused by
a bad decryption key. The remote automatically clears this alarm after it successfully
decrypts two consecutive encrypted Multicast Fast Path packets.
Failure to decrypt Multicast Fast Path packets also results in the following SNMP trap:
46
rmtMCFPDecryptFail: Remote <Remote Name> unable to decrypt multicast fast path

traffic

iDX Release 3.3
9 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.3
47
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 the Network Operator to define various QoS profiles for 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
9-1 on p. 49.
See Group QoS on page57 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.
48

iDX Release 3.3
QoS Measures
Figure 9-1. Remote and QoS Profile Relationships

iDX Release 3.3
49
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 defined in iBuilder, the Network Operator 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 9-2 on p. 51 presents an overview of
the iDirect packet scheduling algorithm.
50

iDX Release 3.3
Figure 9-2. iDirect Packet Scheduling Algorithm

The packet scheduling algorithm (Figure 9-2) 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.
A Network Operator can define multiple service levels using any combination of the three
queue types. For example, the operator can define a combination of Priority and Best Effort
Queues only.

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

iDX Release 3.3
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 timeplan which assigns individual bursts to specific remotes. The burst
timeplan 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 timeplan 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

Minimum Information Rate is upstream bandwidth allocated to a remote that is guaranteed
even when the remote does not need the capacity. By default, a remote is granted a single
slot per TDMA frame. This value can be changed by defining a new Minimum Information Rate
for the remote on the iBuilder Remote QoS tab. 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.
Increasing this value above one slot per frame 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.
It is possible to configure a remotes upstream Minimum Information Rate to be less than one
burst per TDMA frame. This allows many remotes to be packed into a single upstream but
also 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 timeplans contain a burst dedicated to
the 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.
Beginning with iDX Release 3.1, iBuilder allows a Network Operator to configure Minimum
Information Rates for remotes below the limit of one slot every two seconds that was
supported in previous releases. However, if the configured Minimum Information Rate is not
supported by the network or the iDirect hardware, remotes may drop out of the network. See
page92 for more information and for recommendations on setting the Minimum Information
Rate for remotes.
Also beginning with iDX Release 3.1, iBuilder allows a Network Operator to enable the Idle and
Dormant States feature to dynamically reduce the remotes Minimum Information Rate based
on the length of time that the remote has no user traffic to transmit on the TDMA upstream
carrier. This feature is described in Remote Idle and Dormant States on page89.
For instructions for configuring Minimum Information Rate and Idle and Dormant States, see
the section titled Upstream and Downstream Rate Shaping in the chapter titled
Configuring Remotes of the iBuilder User Guide.

iDX Release 3.3
53
Committed Information Rate (CIR)

The Network Operator 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 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.
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, the Network Operator 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. Beginning with iDS Release 8.2, Free Slot Allocation is always
enabled. It is no longer configurable in iBuilder. Free Slot Allocation can be disabled with a
custom key.
54

iDX Release 3.3
Application Jitter
Compressed Real-Time Protocol (cRTP)

The Network Operator 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 RTPbased 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 iBuilder User Guide.
Sticky CIR
Sticky CIR is activated only when CIR is over-subscribed on the downstream or on the
upstream. When enabled, Sticky CIR favors remotes that have already received their CIR over
remotes that are currently asking for it. When disabled (the default setting), the Protocol
Processor reduces assigned bandwidth to all remotes to accommodate a new remote in the
network. Sticky CIR can be configured in the Bandwidth Group and Service Group level
interfaces in iBuilder.
Application Jitter
Jitter is the variation 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 timeplan 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. This feature is enabled by selecting Reduce Jitter for an Applications Service

iDX Release 3.3
55
Packet Segmentation
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. The Network
Operator can configure the downstream segment size in iBuilder. Beginning with iDX Release
3.0, the operator can also configure the SCPC upstream segment size. However, all TDMA
upstream packet segmentation is handled internally to optimize upstream packet
segmentation.
Some applications may require changing the downstream or SCPC upstream segment size on
small carriers to reduce jitter in the downstream or SCPC upstream packets. Typically, this is
not required. For details on configuring the downstream segment size, see the chapter on
Configuring Remotes in the iBuilder User Guide.
Application Latency
Application latency is typically a concern for transaction-based applications such as credit
card verification systems 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. Accomplish this by configuring a higherpriority for 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. The
Network Operator 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, in a typically-congested network with transaction-based (bursty) traffic that
requires a minimum round trip time, Minimum Latency may be the better choice. These
settings are configured in iBuilder in the QoS Service Level dialog box. For details, see the
chapter titled Configuring Quality of Service for iDirect Networks in the iBuilder User
Guide.
56

iDX Release 3.3
Group QoS
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
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 9-3:
Figure 9-3. Group QoS Structure

iDX Release 3.3
57
Group QoS
Bandwidth Pool
A Bandwidth Pool is the highest node in the Group QoS hierarchy. As such, all sub-nodes of a
Bandwidth Pool represent subdivisions of the bandwidth within that Bandwidth Pool. In the
iDirect network, a Bandwidth Pool consists of an outbound carrier or an Inroute Group.
Bandwidth Group
A Bandwidth Pool can be divided into multiple Bandwidth Groups. Bandwidth Groups allow a
Network Operator to subdivide the bandwidth of an outroute or Inroute Group. Different
Bandwidth Groups can then be assigned to different Service Providers or Virtual Network
Operators (VNO).
Bandwidth Groups can be configured with 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 the Network Operator 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.
58

iDX Release 3.3
Group QoS
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
VLAN
Multicast
NMS Traffic
Default
NOTE: Beginning with iDX Release 3.0, Multicast Fast Path Applications can be
configured for remotes in iBuilder. Multicast Fast Path bypasses software
processing on the remote resulting in improved throughput. For details, see
Multicast Fast Path on page43.
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.

iDX Release 3.3
59
Group QoS
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.
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
60

iDX Release 3.3
Group QoS
The sum of all CIR bandwidth should not exceed the total bandwidth. A scenario depicting
physical segregation is shown in Figure 9-4.
Figure 9-4. Physical Segregation Scenario

NOTE: Another solution would be to create a single Bandwidth Group with two
Service Groups. This solution would limit the flexibility, however, if the satellite
provider decides in the future to further split each group into sub-groups.
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:

iDX Release 3.3
61
Group QoS
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 9-5.
Figure 9-5. CIR Per Application Scenario

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
62

iDX Release 3.3
Group QoS
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 9-6.
Figure 9-6. Tiered Service Scenario

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

iDX Release 3.3
63
Group QoS
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 9-7.
Figure 9-7. Third Level VLAN Scenario
64

iDX Release 3.3
Group QoS
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:
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 9-8. Note that this is an
unusual configuration and is not recommended for the typical application
Figure 9-8. Shared Remote Scenario

iDX Release 3.3
65
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 9-9 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: 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.
66

iDX Release 3.3
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.
Figure 9-9. Remote Service Group Scenario

iDX Release 3.3
67
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 page12 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 9-10 on page69.
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 9-10:
68
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.3
Group QoS
Figure 9-10. Scaled Aggregate CIRs Below Partitions CIR

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

This scenario uses the same configuration as the scenario on page68 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 9-11), 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
Figure 9-11. Scaled Aggregate CIRs Exceed Partitions CIR
70

iDX Release 3.3
Group QoS
Bandwidth Allocation Fairness Relative to CIR

iBuilder allows a Network Operator to enable or disable Bandwidth Allocation Fairness
Relative to CIR at various nodes in the Group QoS tree. If this option is configured, 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.
Figure 9-12. Bandwidth Allocation Fairness Relative to CIR

Figure 9-12 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 9-12 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 9-12 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.3
71
Group QoS
Bandwidth Allocation Fairness Relative to MODCOD

Beginning with iDX Release 3.2, iDirect supports two types of Allocation Fairness Relative to
MODCOD:
Allocation Fairness Relative to Nominal MODCOD
Allocation Fairness Relative to Operating MODCOD
Bandwidth Allocation Fairness Relative to Nominal MODCOD only applies to networks that use
DVB-S2 with Adaptive Coding and Modulation (ACM). It allows the system to provide equal
information rates to remotes configured with the same CIR regardless of their configured
Nominal MODCODs.
NOTE: Allocation Fairness Relative to Nominal MODCOD was called Allocation
Fairness Relative to MODCOD in pre-iDX 3.2 releases.
If Bandwidth Allocation Fairness Relative to Nominal MODCOD is enabled, 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 Bandwidth Allocation
Fairness Relative to Nominal MODCOD is disabled, 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 Nominal 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 Nominal MODCOD is more appropriate.
Figure 9-13. Bandwidth Allocation Fairness Relative to Nominal MODCOD

Figure 9-13 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.
72

iDX Release 3.3
Group QoS
The tree on the left-hand side of Figure 9-13 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 9-13 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.
Allocation Fairness Relative to Operating MODCOD operates similarly to Allocation Fairness
Relative to Nominal MODCOD except that adjustments are made dynamically based on the
MODCOD at which the remote are currently operating rather than the remotes nominal
MODCOD. This favors remotes currently operating at lower MODCODs, since their satellite
bandwidth allocations must increase to achieve the same information rate as remotes
operating at higher MODCODs. For additional information, see the section titled Allocation
Fairness Relative to MODCOD in the iBuilder User Guide.

iDX Release 3.3
73
Group QoS
74

iDX Release 3.3
10 TDMA Initial Transmit

Power
A TDMA remote attempts to join an iDirect network by sending an acquisition burst to the hub
in an upstream carrier acquisition slot. The hub assigns upstream TDMA acquisition slots to
remotes in the burst timeplan, which is broadcast to all remotes on the downstream carrier.
To join the network, the remote must transmit the acquisition burst at a power level that
allows the burst to be successfully demodulated by the hub line card receiving the upstream
carrier. After the remote has joined the network, the Uplink Control Process at the hub takes
over to keep the remote in the network at the correct power.
TDMA initial transmit power is the power level at which the remote transmits acquisition
bursts. The initial transmit power is determined during remote commissioning and configured
in iBuilder. After the remote is commissioned, the value configured in iBuilder and contained
in the remote options file is used whenever the remote re-joins the network.
Beginning with iDX Release 3.2, each upstream carrier in an inroute group can have a
different MODCOD, symbol rate, and spreading factor. Specific values for these upstream
carrier parameters (collectively called the remotes Reference Carrier) are entered into
iBuilder along with the TDMA Initial Power. The value configured for TDMA Initial Power is
defined in relation to the configured Reference Carrier parameters.
A remote may be invited to acquire the network on any upstream carrier in the inroute group
that has acquisition enabled. When sending an acquisition burst on an upstream carrier with
characteristics that differ from the configured Reference Carrier, the remote uses its
Reference Carrier parameters to adjust the initial transmit power so that the acquisition burst
is received by the hub line card within the correct C/N range for that carrier.
This chapter describes why it is important to correctly configure the TDMA initial transmit
power for all remotes. Additional information is contained in the following iDirect
documentation:
The Installation and Commissioning Guide for iDirect Satellite Routers contains the
procedure for determining the correct TDMA Initial Power and Reference Carrier
parameters for a remote.
Remote Acquisition on page127 describes the process by which a remote joins an

iDirect network.
Uplink Control Process on page79 describes uplink power control in iDirect networks.

iDX Release 3.3
75
All Remotes Need To Transmit Bursts in the Same C/N Range
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 arrive at similar C/N levels, the average C/N is close to the optimal value for
all bursts. However, if many bursts arrive at varying C/N levels, the higher-level and lowerlevel bursts can skew the average such that the average is no longer optimal.
The nominal C/N range is 2 dB. The actual range at which bursts can be optimally detected is
approximately 8 dB, centered at the nominal gain point (Figure 10-1).
Figure 10-1. Optimal C/N Detection Range

As shown in Figure 10-1, under ideal circumstances, the average C/N of all remotes on the
upstream carrier is equal to the center of the UCP adjustment range. Notice that the optimal
detection range extends below the threshold C/N of the upstream carrier.
What Happens When Initial Tx Power Is Set Incorrectly?

If the TDMA transmit initial power of a remote is not set correctly, network performance can
be negatively affected. When a remote is acquired by the hub line card, the center point of
the 8 dB wide detection range is set at the C/N value at the time of acquisition. This section
described what happens if the Initial Power is too high or too low.
When Initial Transmit Power is Too High

Remotes acquiring the network with initial transmit power set too high skew the average C/N
to be above the center of the UCP adjustment range. Since UCP updates may occur as
infrequently as every 20 seconds, it can take a minute or more for remotes with too much
initial power to decrease their power to be within the nominal range. During this period the
optimal detection range does not include the threshold C/N and the performance of remotes
experiencing rain may degrade. Those remotes could drop out of the network because their
bursts no longer fall within the optimal detection range. In addition, remotes that are trying
76

iDX Release 3.3
to acquire using traditional acquisition (rather than Superburst) with a C/N value of less than
7 dB will not acquire the network.
Figure 10-2. Skewed C/N Detection Range: Initial Transmit Power Too High
When Initial Transmit Power is Too Low

Remotes acquiring the network with initial transmit power set too low skew the average C/N
to be below the center of the UCP Adjustment Range. This could cause remotes coming into
the network at the higher end (for example, 14 dB) to experience some distortion in the
demodulation process. Additionally, a remote acquiring at below the C/N threshold may
experience a large number of CRC errors after joining the network until its power is
sufficiently increased.
Since UCP updates may occur as infrequently as every 20 seconds, it may take a minute or
more for carriers with initial power set too low to increase their power to be within 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 may not acquire the
network. Bursts can still be detected below the threshold C/N but the probability of detection
and demodulation is reduced.
Figure 10-3. Skewed Detection Range: Initial Transmit Power Too Low

iDX Release 3.3
77
78

iDX Release 3.3
11 Uplink Control Process
The iDirect Uplink Control Process executes at the hub to bring remotes into the network and
to maintain the correct frequency, power and timing during operation. This is accomplished
by continuously monitoring each remotes upstream performance at the hub and instructing
the remote to adjust its transmission as required to remain within acceptable limits.
TDMA Uplink Control

TDMA Uplink Control is active while the remote is acquiring the network and after the remote
becomes operational in the network. This section discusses both phases of TDMA Uplink
Control.
Acquisition
Satellites drift through the station-keeping box, adding approximately 1.7 ms of uncertainty
to the symbol timing. The 1.7 ms timing uncertainty consists of 0.1o of satellite station
keeping uncertainty and approximately 50 miles of remote position uncertainty.
NOTE: Symbol timing uncertainty is higher than 1.7 ms for inclined orbit
applications. For those applications, the Acquisition Aperture for the upstream
TDMA carriers in iBuilder should be adjusted. Consult the iDirect TAC for advice.
This variation in symbol timing is accounted for during remote acquisition by providing a
larger guard interval in the TDMA frame for acquisition slots than for traffic slots. A larger
guard interval in the acquisition slot prevents the acquiring remote from bursting into the
traffic slots allocated to other remotes. This is illustrated in Figure 11-1.
Guard
Interval
Guard
Interval
Figure 11-1. TDMA Frame Format

iDX Release 3.3
79
TDMA Uplink Control
Frequency offset is the difference between the nominal frequency at which the remote
transmits and the frequency at which the hub demodulator receives the upstream carrier.
Frequency offset occurs even after the remotes clock is synchronized to the hub clock. The
hub downconverter equipment and the Doppler effect due to satellite and remote terminal
motion are major contributors to frequency offset.
iDX Release 3.3 supports two types of remote acquisition: Traditional (or Fast) Acquisition
and Superburst Acquisition. Superburst Acquisition greatly improves the time and bandwidth
required for remotes to join the network and should be used whenever possible. However, in
this release, Superburst Acquisition can only be used on upstream carriers being received by
multichannel line cards.
Once a remote that is ready to join the network has locked to the downstream carrier, it
begins to burst in its assigned acquisition slots at the frequency offsets indicated by the hub.
Once a burst from the remote is detected at the hub, the hub sends the frequency offset
correction to the remote.
When receiving a traditional acquisition burst, the TDMA demodulator at the hub has a narrow
tolerance for frequency offset (approximately 1.5% of the upstream carrier symbol rate).
Therefore, during traditional acquisition, the remote must burst at various frequencies until
the demodulator detects the upstream carrier. The hub sends invitations on the downstream
carrier to all remotes that are not in the network to transmit at different frequency offsets.
When receiving a Superburst, the hub demodulators tolerance for frequency offset improves
to approximately 7.5% of the symbol rate. A Superburst is also a much more robust waveform
that is independent of the traffic MODCOD. These advantages allow the hub to detect a
Superburst over a much wider frequency range and at a much lower C/N when compared to a
traditional acquisition burst. Therefore, in most cases, a remote must only transmit a single
Superburst to acquire the network. When using Superburst, frequency sweeping is typically
not required.
During remote commissioning, an initial transmit power is determined for the remote and
configured in iBuilder. The initial power is chosen so that the remote can enter the network in
rain fade conditions. During acquisition, the remote always transmits at the configured initial
power if acquiring on an upstream carrier with the same parameters as its configured
reference carrier. (See Reference Carrier Parameters on page41.) If a remote is acquiring on
a carrier that does not match the configured reference carrier, the remote adjusts its initial
power to maintain the spectral density of the transmission. For details on both Traditional
Acquisition and Superburst Acquisition, see Remote Acquisition on page127.
Once the remote has joined the network, the operational UCP algorithm takes over to
maintain optimal transmit power for the remote. For remotes in Adaptive Inroute Groups,
uplink control selects the initial nominal upstream carrier for the remote based on the C/N of
the acquisition burst. This initial selection is based on the Acquisition Margin (M3) configured
in iBuilder on the Uplink Control tab of the inroute group. The Acquisition Margin is separate
from the normal margins, due to the larger uncertainty of the C/N estimation on the
Superburst and to allow for other system uncertainties such as BUC aging and frequency
response variations. This margin is used both for Superburst and traditional burst acquisition.
For details on configuring this parameter, see the iBuilder User Guide.
80

iDX Release 3.3
TDMA Uplink Control
Network Operation
Once the remote has acquired the network, the Uplink Control Process continuously corrects
the frequency, symbol timing and power while the remote is in the network. For remotes in
Adaptive Inroute Groups, the UCP process is also responsible for switching remotes to new
nominal upstream carriers as required. A remotes nominal carrier is the upstream carrier
with the highest threshold C/N0 the remote can sustain and is allowed to use. All power
control and other real-time corrections are related to the nominal carrier. Power control is
described in UCP Power Control and Fade Detection on page82.
UCP Correction Processing

The hub periodically sends UCP correction information to the remote. By default, the hub
sends this information every 20 seconds to stationary remotes. The UCP update rate for
mobile remotes is determined by the COTM Type selected in iBuilder on the Remote Geo
Location tab. (See the iBuilder User Guide appendix COTM Settings and Custom Keys for
details.)
In order for the UCP algorithm to function correctly, the remote must periodically transmit
bursts on the TDMA upstream carrier even when idle. iDirect supports a minimum of 1 burst
every 4 seconds for stationary remotes in Ku Band, C Band and X Band, except when using
8PSK. High-speed mobile remotes must be configured to send a minimum of 1 burst per
second. The Minimum Information Rate configured on the remote QoS tab in iBuilder
determines the minimum number of bursts per second that the remote transmits when idle.
Beginning with iDX Release 3.2, an idle remote automatically increases the frequency with
which it transmits bursts to the hub when a fade condition is detected. For a remote in an
Adaptive Inroute Group, this allows the hub to monitor a fast fade and move the remote to a
more protected carrier before the hub can no longer detect the remotes bursts. See page83
for details.
UCP Symbol Timing

Remotes that transmit on the same TDMA carrier must time their transmissions so that all
bursts arrive at the hub in sequence and without collisions and thus are successfully received
by the hub modem burst demodulator. To arrive at correct burst timing synchronization, each
remote uses its own geographical coordinates, the geographical coordinates of the hub, and
the longitude of the satellite to calculate a Frame Start Delay (FSD). The different FSDs of the
remotes compensate for the variation in transmission delay between the individual remotes
and the hub. The remote adds the FSD to the frame start time received from the hub to
derive the remotes TDMA frame start time.
During network operation, the symbol timing changes as the satellite moves within the
station-keeping box. Symbol timing can also change due to timing Doppler shift in mobile
remotes. UCP at the hub adjusts the remotes symbol offset by averaging timing drifts every
UCP period and sending corrections to the remote.
The guard interval between bursts for TDMA upstream carriers is set automatically in iBuilder.
Beginning with iDX Release 3.2, the guard interval is configured for the entire inroute group,
rather than for each upstream carrier. The value is automatically calculated based on the
Maximum Speed configured for remotes in the inroute group, but can be overridden by the
Network Operator.

iDX Release 3.3
81
TDMA Uplink Control
The Guard Interval is no longer entered into iBuilder in symbols. It is now entered in units of
system time called NCR ticks. For clarity, the number of NCR ticks entered is translated to
microseconds and displayed on the screen (Figure 11-2).
Figure 11-2. iBuilder: Maximum Speed and Guard Interval for Inroute Group
UCP Frequency Tracking

Frequency drifts are caused by clock drifts in various components of the system. These drifts
are primarily due to variation in temperature and the age and quality of the oscillators. The
protocol processor averages frequency offsets over every UCP period and sends corrections to
the remotes. The remotes then adjust their transmit frequencies accordingly.
For mobile remotes, Doppler shifts also contribute to the frequency drift. These additional
frequency drifts in mobile remotes are primarily caused by variation in the remotes velocity.
In high-speed COTM applications, the protocol processor uses a predictive algorithm to
correct the frequency drifts.
UCP Power Control and Fade Detection

The demodulator at the hub functions optimally when the received power spectral density is
similar for all remotes transmitting on a given upstream carrier. Therefore, the goal of the
Uplink Control Process is to adjust the individual transmit powers of the remotes such that all
bursts transmitted on a TDMA upstream carrier are received at the same C/N as measured at
the hub. For a given remote, the C/N may vary due to fade conditions or as mobile remotes
move across the satellite footprint, requiring UCP to adjust the remotes transmit power to
keep the C/N within range.
To normalize the C/N across remotes, the C/N deviations detected by the line cards are
averaged by the protocol processor for each remote. If the deviations are within the
acceptable range of the target C/N, no corrections are sent to the remote. If the deviations
are outside the acceptable range, corrections are sent to the remote until the C/N is within
range.
In earlier releases, all TDMA carriers in any inroute group had the same MODCOD and symbol
rate. Therefore, if network conditions (such as a severe fade) did not allow a remotes power
to be increased to a sufficient level for the hub to demodulate the remotes burst, the remote
would drop out of the network and be forced to reacquire when conditions were favorable.
Since all upstream carriers were identical, there was no opportunity to move the remote to a
more protected carrier during the fade condition.
In iDX Release 3.2 the power control algorithm was redesigned to accommodate the
heterogeneous nature of the upstream carriers in adaptive inroute groups. The goal of the
power control algorithm is for each remote to be received at the target C/N on the remotes
nominal carrier. Therefore, the new algorithm is responsible not only for adjusting the
remotes power on the current nominal carrier, but also for selecting a new nominal carrier
when required.
82

iDX Release 3.3
TDMA Uplink Control
A remote may be assigned slots on an upstream carrier that does not match its current
nominal carrier. For example, during upstream bandwidth contention, a remote may be
granted slots on a less efficient carrier if there are no available slots on the nominal carrier. In
that case, the remote automatically adjusts its transmit power such that the power matches
what is required on the assigned carrier.
In earlier releases, the target C/N (or TDMA Nominal C/N) was an operator-entered value
determined by adding the C/N threshold for the inroute from the Link Budget Analysis Guide
to the additional operating margin determined by the Link Budget Analysis for the network.
Beginning in iDX Release 3.2, the target C/N is calculated using the C/N thresholds for the
inroutes from the Link Budget Analysis Guide and the following margins configured in
iBuilder:
The Fade Slope Margin (M1) allows for incremental fade that can occur during the
reaction time of the power control algorithm as well as the uncertainty in the C/N0
estimations.
The Hysteresis Margin (M2) is added to the Fade Slope Margin to prevent unnecessarily
frequent switching between carriers.
NOTE: The Acquisition Margin (M3) is used only to select the initial nominal
carrier when a remote acquires the network. This margin is discussed on page80.
The system adds the sum of the Fade Slope Margin and the Hysteresis Margin to the C/N
thresholds from the LBA Guide to determine the target C/Ns for each carrier in the inroute
group. iDirect provides a dimensioning tool to assist network designers in determining suitable
values for these parameters.
If a remotes C/N falls below the target C/N, the power control algorithm increases the
remotes transmit power if possible to bring the signal back up to the target level. If the
remotes power cannot be increased on the nominal carrier and a more protected carrier is
available, then the remotes nominal carrier is changed to the more robust carrier. This keeps
the remote in the network at the expense of diminished throughput. If the remote is
consistently below the threshold defined by the target C/N minus the Hysteresis Margin on the
most protected carrier in the inroute group, the remote is logged out of the network. A
remote that has been logged out must re-acquire the network before it can continue to
transmit user traffic.
If a remotes C/N is above the target C/N plus the hysteresis margin, the power control
algorithm looks for a more efficient carrier on which the remote can maintain the target C/N.
If such a carrier is found and if UCP estimates that remote is capable of transmitting on that
carrier, the remotes nominal carrier is changed to the new carrier. If the remote cannot
switch to a better carrier, the power control algorithm decreases the power as necessary to
return the remotes signal to the target C/N.
The power control algorithm reacts faster when the hub determines that a remote has
entered an upstream fade. When monitoring the remotes signal, the algorithm samples the
C/N periodically. The algorithm determines a fade slope for the remote based on analysis of
the C/N samples. The algorithm adjusts the measurement interval depending on the fade
slope, such that it is shorter when the fade varies rapidly. This tends to keep small and
constant the amount of margin required in order to account for the reaction time.
If a remote fade is detected, then the update interval is decreased based on the severity of
the fade. Decreasing the update interval may require the system to allocate additional

iDX Release 3.3
83
TDMA Uplink Control
upstream slots to the remote. For idle remotes, the configured Minimum Information Rate is
ignored and more slots allocated if additional burst measurements are required by the Uplink
Control Process.
The Measurement Spacing configured in iBuilder on the Uplink Control tab of the inroute
group defines the steady-state update interval. This parameter is set to 2 seconds by default
but can be modified by the Network Operator. The smaller update intervals used during fades
are set by the software and are not configurable.
In pre-iDX 3.2 releases, the power adjustment algorithm applied corrections to the remotes
power using coarse and fine step sizes configured in iBuilder. These parameters are no longer
used and have been removed from iBuilder. Beginning with iDX Release 3.2, the power
adjustment step size is automatically determined by the power control algorithm.
NOTE: Because iDX Release 3.2 supports Inroute Groups with different sized
upstream carriers, C/N0 has replaced C/N as the measurement of signal quality
used to monitor and control remote transmissions on the upstream carriers. See
C/N0 and C/N on page38 for details.
Figure 11-3 illustrates the application of uplink power control (UPC) to a fading remote in an
Adaptive system.
Correction aims for C3

of next carrier up
Out of UPC:
Drops below C2;
Switch down
UPC keeps C/N0

close to C3
UPC keeps C/N0

close to C3
Correction aims for C3

of next carrier down
C3
Hysteresis margin
C3
M2
M2
C2
Fade Slope margin
C2
M1
M1
C1
C1
Carrier 1
Carrier 1
C3
'
M2
Sufficient
headroom to
switch up
C2
M1
C1
Carrier 2
Increasing fade
UPC keeps C/N0

close to C3
Decreasing fade
Figure 11-3. Uplink Power Control During Remote Fade

In Figure 11-3:
84
C/N0 = C/N + 10log10 (Rs) : The C/N adjusted for the carrier symbol rate (Rs).

iDX Release 3.3
SCPC Return Uplink Control
C1 : The C/N threshold from Link Budget Analysis Guide.
C2 = C1 + M1 : The C/N threshold plus the Fade Slope Margin.
C3 = C2 + M2 : The C/N threshold plus the Fade Slope Margin plus the Hysteresis Margin.
: The C/N0 difference between Carrier 1 and Carrier 2.
H : Power Headroom; i.e. the amount that the remote can increase its transmit power
before reaching its configured TDMA maximum power.
Uplink power control continuously monitors the remotes C/N0 as measured at the hub and
adjusts the remotes transmit power as required to maintain the target C/N0 on the nominal
carrier. Referring to Figure 11-3, the system reacts to a remote fade as follows:
1. Prior to the fade, the remote is operating on Carrier 1. Uplink power control keeps the
C/N0 of the remote at approximately the target C/N0 represented by C3 of Carrier 1.
2. As the remote enters the fade, uplink power control increases the remotes transmit
power as necessary to maintain the target C/N0 on Carrier 1.
3. When the remotes power headroom is exhausted, the remotes C/N0 continues to drop on
Carrier 1 but the transmit power can no longer be increased to return the remote to C3.
4. When the remotes C/N0 falls below C2 on Carrier 1, the remote is moved to a more
protected carrier (Carrier 2) where the target C/N0 of the remote can be maintained.
5. As the fade decreases, uplink power control decreases the remotes transmit power to
maintain the target C/N0 on Carrier 2.
6. Once the fade has decreased to the point that the remote has sufficient power headroom
to meet the target C/N0 (C3) of Carrier 1, the remote is moved back to Carrier 1.
7. When the fade passes, uplink power control continues to operate to keep the remotes
C/N0 at C3 on Carrier 1 as it did prior to the fade.
SCPC Return Uplink Control

The Uplink Control Process at the hub corrects the power on remotes that transmit dedicated
SCPC return channels to the hub. The hub does not perform UCP frequency or symbol timing
corrections for SCPC upstream carriers.
Although frequency corrections are not made at the hub, the remote does execute a local
frequency oscillator correction algorithm. The frequency offset for an SCPC carrier as
measured at the hub is displayed in iMonitor.
NOTE: A remote-side custom key is required to select the correct local frequency
oscillator correction algorithm for high-speed SCPC remotes. See the iBuilder User
Guide appendix COTM Settings and Custom Keys and Settings for details.
UCP Power Adjustment for SCPC Upstream Carriers

Based on the C/N threshold determined during hardware qualification for an SCPC carrier and
the operating margin determined by the link budget analysis, the NMS determines a Nominal
C/N at which to receive the SCPC upstream carrier. The Nominal C/N is the target C/N value
of the SCPC upstream carrier as measured by the hub line card.

iDX Release 3.3
85
Viewing UCP Statistics in iMonitor
The Uplink Control Process adjusts the remotes transmit power as necessary to keep the C/N
of the carrier within a defined range of the Nominal C/N. A maximum power adjustment is
also defined at the hub that limits the size of the adjustment that the UCP algorithm will
make in a single step.
The Operating Margin, the operating range with respect to Nominal C/N, and the Maximum
Power Adjustment are all configurable in iBuilder. For more information, see the section
titled Adding SCPC Upstream Carriers in the iBuilder User Guide.

iMonitor provides both tabular and graphical monitoring of UCP statistics for the individual
remotes in the network. Figure 11-4 shows examples of the UCP statistics displays in iMonitor.
Figure 11-4. iMonitor UCP Statistics

The following information for the selected remote is displayed on the iMonitor UCP Info tab:
86
The remotes Upstream C/N0 as measured at the hub
The remotes UCP Power Adjustment
The remotes UCP Symbol Timing Offset (TDMA only)
The remotes UCP Frequency Offset

iDX Release 3.3
The top image in Figure 11-4 shows the UCP Info tab for an SCPC remote while the bottom
image shows the UCP Info Tab for a TDMA remote. Notice that the Symbol Offset is not
applicable to the SCPC remote.
In older releases, UCP only modified the power of a remote if the remote's bursts were
outside of a normal range defined in iBuilder. However, beginning with iDX Release 3.2, the
remote's power is adjusted if the received SNR differs from the target threshold by more than
+/-0.25 dBm. Each time a correction is sent, the remote adjusts its power by its minimum
step size (0.5 dB for most model types; 1 dB for Evolution X1 or e150 remotes). Because of
this, when viewed in iMonitor or on a spectrum analyzer, remote power may continuously vary
by +/-0.5 or +/-1 dBm. This is not an operational issue and should be ignored.
As discussed in Acquisition on page79, the Uplink Control Process also controls network
acquisition for TDMA remotes. Beginning with iDX 3.0, the Network Operator can view
upstream acquisition statistics (as well as other upstream performance statistics) per remote
in iMonitor. The Network Operator can view these statistics in both graphical and tabular
form.
Upstream acquisition performance statistics displayed in iMonitor for remotes transmitting on
a TDMA inroute include:
The number of valid acquisition bursts received from the remote
The number of CRC errors received in acquisition slots assigned to the remote
The number of missing acquisition bursts in acquisition slots assigned to the remote
Figure 11-5 shows the upstream acquisition statistics for a remote in the process of acquiring
the network. Notice that there are a high number of missing acquisition bursts and acquisition
CRC errors as the UCP algorithm adjusts the remotes frequency offset. When the hub detects
a burst from the remote, the hub sends the remote the correct frequency offset correction
and the missing bursts and CRC errors drop to zero.
Figure 11-5. Remote Upstream Acquisition Statistics

iDX Release 3.3
87
For details on viewing UCP and Upstream Performance statistics in iMonitor, see the iMonitor
User Guide.
88

iDX Release 3.3
12 Remote Idle and

Dormant States
Beginning with iDX Release 3.1, the Idle and Dormant States feature allows a remote to
dynamically reduce its Minimum Information Rate based on the length of time that the
remote has no user traffic to transmit on the TDMA upstream carrier.
Overview
Once it has acquired the network, a TDMA remote is always allocated a minimum number of
upstream TDMA slots even when it has no upstream bandwidth demand. The minimum number
of slots allocated to a remote depends on Minimum Information Rate defined on the Remote
QoS tab. If a Minimum Information Rate has been configured for the remote, then the number
of slots per frame is displayed on the screen. If no Minimum Information Rate is configured for
the remote, the remote is granted at least one slot per TDMA frame by default. The remote
requires this Minimum Information Rate for a number of reasons, including to request
additional bandwidth from the hub when needed for upstream packets, and to send periodic
bursts to the hub so that the Uplink Control Process (UCP) can keep the remote in the
network.
When the Idle and Dormant State feature is enabled, the Minimum Information Rate granted
to the remote is reduced over time if the remote continues to have no upstream user traffic
to transmit. In networks with large numbers of remotes with periods of no demand, enabling
this feature can save significant upstream bandwidth by minimizing the number of unused
upstream TDMA slots allocated to remotes.
However, the smaller the Minimum Information Rate allocated to a remote, the longer it takes
(on average) for that remote to request and to be granted additional bandwidth when the
remote receives upstream traffic for transmission. Therefore, when the Idle and Dormant
States feature is enabled, this additional ramp up delay after periods of inactivity may be
noticeable for interactive applications since it can take several seconds for the remotes
bandwidth allocation to be increased to meet the new demand. In addition, if the Minimum
Information Rate of the remote is set too low, the UCP process may not be able to keep the
remote in the network, and the remote may be force to reacquire.

iDX Release 3.3
89
Feature Description
Feature Description
A remote with the Idle and Dormant States feature enabled can be in one of three states:
Active, Idle or Dormant. Figure 12-1 shows how the remotes states change when this feature
is enabled.
Figure 12-1. Active, Idle and Dormant State Change Diagram

Figure 12-2 shows the fields on the iBuilder Remote QoS tab used to configure this feature.
The configuration of the remotes Minimum Information Rate fields determine the system
behavior in the Active State. The configuration of the Idle and Dormant States fields
determine the system behavior in the other two states.
Figure 12-2. Configuring Active, Idle and Dormant States

A remote that is in network and actively transmitting upstream user traffic is in the Active
State. If Minimum Information Rate is not enabled, a remote in the Active State is granted a
minimum of 1 slot per frame by default. If Minimum Information Rate is enabled, then the
minimum bandwidth granted to the remote is determined by the value in kbps entered on the
90

iDX Release 3.3
Feature Description
screen (Figure 12-2). Notice in Figure 12-2 that when a Minimum Information Rate is entered
into iBuilder, the equivalent number of slots per frame is automatically displayed.
NOTE: The Active State behavior is identical to the system behavior when the Idle
and Dormant States feature is not enabled.
When you select Enable Idle and Dormant States, then for each of those states you can
configure how frequently slots are allocated to the remote (in units of 1 slot per n frames)
and the Timeout that determines when the remote will change to that state from the
previous state.
If a remote in the Active State has no upstream user traffic to transmit for the time period
defined by the Idle State Timeout, then the remote changes from the Active State to the Idle
State. When the remote enters the Idle State, the remotes Minimum Information Rate
changes based on the Idle State configuration of 1 Slot / n Frames. Notice in Figure 12-2 that
when you configure the Idle State for 1 slot every n frames, the equivalent Idle Minimum
Information Rate is automatically displayed in kbps on the screen.
If the remote has been in the Idle State for the time period defined by the Dormant State
Timeout and the remote still has no upstream user traffic to transmit, then the remote
changes from the Idle State to the Dormant State. In the Dormant State, the remotes
Minimum Information Rate again changes based on the Dormant State configuration of 1 Slot /
n Frames. As with the Idle State, when you configure the Dormant State for 1 slot every n
frames, the equivalent Dormant Minimum Information Rate is automatically displayed in kbps
on the screen. A remote in the Dormant State remains in that state as long as it has no
upstream user traffic to transmit.
NOTE: Minimum Information Rate must be greater than or equal to the Idle
Minimum Information Rate. Similarly, the Idle Minimum Information Rate must be
greater than or equal to the Dormant Minimum Information Rate. iBuilder
enforces these constraints when the configuration is entered on the Remote QoS
tab.
If at any time a remote in Idle State or Dormant State receives upstream user traffic for
transmission, the remote returns to the Active State and the Idle State Timeout is reset. By
default, only upstream user traffic triggers a state change from Idle or Dormant State to
Active State. Upstream management traffic generated by the remote to the NMS does not
trigger a state change. To select which upstream QoS Service Levels trigger state changes,
select or clear the Trigger State Change check box for the Service Level defined for that
traffic. An example is shown in Figure 12-3. (See the section titled Adding an Application

iDX Release 3.3
91
Feature Description
Profile in the chapter Configuring Quality of Service for iDirect Networks in the iBuilder
User Guide for details.)
Figure 12-3. Upstream Service Level with Trigger State Change Selected
NOTE: When using the Idle and Dormant States feature in conjunction with
Remote Sleep Mode, the Sleep timeout should be longer than the Idle and
Dormant State timeouts. Otherwise, the remote will sleep before the Dormant
State timeout expires and the Idle and State feature will be ineffective. See
Remote Sleep Mode on page123.
Using the configuration in Figure 12-2 as an example, if the remote has been recently Active
but has no more user traffic to transmit, it will remain in the Active State for 120 seconds (the
Idle State timeout). During that time, the remote will be granted its configured Minimum
Information Rate of 27.264 kbps. If after 120 seconds the remote still has no user traffic to
transmit, it will enter the Idle State and the Minimum Information Rate granted to the remote
will change to 3.14 kbps (or 1 slot every 8 frames).
If after 180 seconds in the Idle State the remote still has no user traffic to transmit, it will
enter the Dormant State and its Minimum Information Rate will change to 0.85 kbps. The
remote will remain in the Dormant State until it receives upstream user traffic to transmit. If
at any time a remote in Idle State or Dormant State receives upstream user traffic for
transmission, it will to return to the Active State and the Minimum Information Rate will
return to 27.264 kbps.
To remain in the network, a remote should transmit at least 1 burst every 4 seconds. With a
typical frame length of 125 ms, this translates into a minimum allocation of 1 slot every 32
frames.
As in previous releases, the Minimum Information Rate for the Active State cannot be set
lower than one slot every 16 frames (the equivalent of one slot every 2 seconds.) Typically,
this minimum allocation is sufficient for any remote to stay in the network. For the Idle State
and the Dormant State, however, the Minimum Information Rate can be set as low as one slot
every 64 frames (one slot every 8 seconds). Note that based on the discussion in the previous
paragraph is unlikely that a remote with such a low Minimum Information Rate will remain in
the network except when all of the following conditions are met:
The remote is transmitting a BPSK or QPSK upstream carrier to an Evolution line card
under clear sky conditions.
The remote is a fixed-site (non-mobile) remote in a Ku Band, C Band or X Band network.
Therefore, configuring a rate below the recommended setting may cause the remote to drop
out of the network and be forced to reacquire if there is insufficient margin to handle rain
92

iDX Release 3.3
Feature Description
fade or if 8PSK upstream modulation is chosen. Because of these constraints, do not configure
a Minimum Information Rate for any state below the recommended settings unless the
network configuration and system design permit a lower rate.
Note also that in DVB-S2 networks with Adaptive Coding and Modulation (ACM) enabled, if a
remote enters a downstream fast fade condition the remote attempts to report its current
SNR to the hub every second. This allows the hub to quickly adjust the outbound MODCOD of
the remote to compensate for the fade. If the remote is in the Idle State or Dormant State,
the remote may not have sufficient TDMA slots to allow it to increase its inbound transmission
rate to report the fade. As a result, the hub may not adjust the remotes MODCOD quickly
enough to avoid the loss some downstream data by the remote.
Beginning with iDX Release 3.2, if the hub detects that a remotes upstream C/N is dropping
rapidly due to fade conditions, the Minimum Information Rate of the remote is automatically
increased so that the power control algorithm can react quickly to adjust the remotes
transmit power. If the remote requires additional slots, the currently-configured Minimum
Information Rate of the remote is ignored and the slot allocation rate is determined by the
software. For more information on power control see UCP Power Control and Fade Detection
on page82.

iDX Release 3.3
93
Feature Description
94

iDX Release 3.3
13 Verifying Error
Thresholds Using IP
Packets
This chapter provides instructions on testing iDirect equipment functioning in IP networks to
ensure that Layer 1 errors are seen at the specified rate at the C/N thresholds. The C/N
thresholds are published in the Link Budget Analysis Guide.
Introduction
In the early days of VSAT systems, data was input and output from satellite modems using
serial data protocols that allowed users direct access to the bit stream going over the air. This
enabled 3rd party test equipment to be used to inject test data containing pseudo-random
data patterns into a transmit stream and to synchronize to those patterns in the receive
stream. The Bit Error Rate (BER) was calculated by counting the bit errors in the receive
stream.
When the satellite industry standardized on IP networking protocols, access to the bit stream
was lost since user data is wrapped in various other packet formats (such as Ethernet) at
various points in the network. Although this low level access is no longer available, the
positive result of using IP packets is that there are many off-the-shelf methods for measuring
IP Packet Error Rate (PER). This includes free tools such as Iperf
(http://en.wikipedia.org/wiki/Iperf) and udpblast which is shipped with iDirect hub
software. These tools run on standard PCs and do not require special test hardware.
Many more sophisticated test platforms are available for high-throughput IP testing and for
modeling a mix of packet sizes to mimic user application or internet traffic. However, when
verifying error thresholds, a simple stream of fixed size packets is usually sufficient.
TDMA Upstream Threshold Testing

The upstream channel computes a CRC check on each TDMA Cell and discards any cells with
errors. Therefore, when measuring Layer 1 upstream channel quality there is no concept of
BER, only of Cell Loss Rate (CLR). The upstream thresholds iDirect publishes in the Link
Budget Analysis Guide reflect a CLR threshold of 1e-5, meaning that 1 cell out of 100,000 will
be in error at the published threshold (expressed in Eb/N0 and C/N). Since 2D 16-state coding
has steep waterfall curves, and since the TCP/IP protocol is very inefficient on channels with
any significant error rate, iDirect does not publish information about channel quality below
the thresholds. It is strongly recommended that link budgets and power control margins be
designed to avoid falling below the published thresholds.

iDX Release 3.3
95
TDMA Upstream Threshold Testing
When testing the upstream channel in a network by inserting IP test packets at the remote
and terminating them at the hub, the advertised CLR threshold must be adjusted to account
for the size of the IP packets being used in the test. For example, if it takes 10 TDMA cells to
transmit each IP packet, the IP PER will be 10 times worse than the CLR at the threshold
point; in other words, a PER of 1e-4 will be measured at the advertised threshold.
Use the following equations to find the expected upstream IP Packet Error Rate:
IP_PacketErrorRate = CellLossRate * (1 + IP_PacketSize) / (TDMA_CellSize)
Where,
TDMA_CellSize = TDMA_BlockSize 12
Upstream Example 1
Find the IP Packet Error Rate for:
512 byte IP test packets
8PSK modulation
2D 16-State/170 Byte-4/5 FEC
In this example:
TDMA_CellSize = 170 12 = 158 bytes
Therefore,
IP_PacketErrorRate = 1e-5 * (1 + 512) / 158 = 3.25e-5
Since this TDMA mode reaches its error threshold at a C/N of 11.7 dB, 3.25 IP Packets are
expected to be lost for every 100,000 transmitted at this C/N.
Upstream Example 2
QPSK modulation
2D 16-State/438 Byte-2/3 FEC
In this example:
TDMA_CellSize = 438 12 = 426 bytes
Therefore,
IP_PacketErrorRate = 1e-5 * (1 + 512) / 426 = 1.20e-5
Since this TDMA mode reaches its error threshold at a C/N of 5.0 dB, 1.20 IP Packets are
96

iDX Release 3.3
DVB-S2 Downstream Threshold Testing

In order to measure the threshold performance of ACM DVB-S2 downstream operation, a
specific MODCOD must be isolated. The easiest way to do this is to set the minimum MODCOD
and maximum MODCOD of the downstream carrier to the same value to emulate a CCM system
and test against the C/N threshold of that MODCOD. For details on configuring DVB-S2
downstream carriers, see the iBuilder User Guide.
The LEGS and Generic Stream protocols used by iDirect include a CRC check on every BB
Frame. The size of the FEC payload depends on the MODCOD of the BB frame. These payload
sizes are listed in the Link Budget Analysis Guide in the column Payload Bits Per Frame (Kb)
of the DVB-S2 Modem Performance Limit table.
It is possible to use the technique in TDMA Upstream Threshold Testing on page95 to
calculate a Frame Loss Rate (analogous to the Cell Loss Rate) and then use a similar equation
to determine the IP Packet Error Rate. The DVB-S2 C/N thresholds published in the Link
Budget Analysis Guide reflect a Bit Error Rate (BER) of 1e-8.
Use the following equations to find the expected downstream IP Packet Error Rate:
FrameLossRate = (PayloadBitsPerFrame + 112) * Threshold_BER
IP_PacketErrorRate = FrameLossRate * (1 + IP_PacketSize) / (DVB-S2_FrameSize 2)
Where,
DVB-S2_FrameSize = (PayloadBitsPerFrame / 8) 7
Downstream Example
8PSK Rate 3/4 MODCOD
In this example:
FrameLossRate = (11600 + 112) * 1e-8 = 1.17e-4
DVB-S2_FrameSize = (11600 / 8) 7 = 1443 bytes
Therefore,
IP_PacketErrorRate = 1.17e-4 * (1 + 1024) / (1443 2) = 8.32e-5
Since this DVB-S2 MODCOD reaches its error threshold at a C/N of 8.5 dB, 8.32 IP Packets are

iDX Release 3.3
97
98

iDX Release 3.3
14 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 the Network Operator 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 14-1 illustrates the current and Global NMS database relationships.
Figure 14-1. Global NMS Database Relationships

iDX Release 3.3
99
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 14-2).
Figure 14-2. 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 14-2.) 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.
100

iDX Release 3.3
15 Security Best Practices
This chapter recommends basic security practices to enhance the security of iDirect
networks. iDirect also recommends implementation of all additional security measures
required by your company security standards.
Hub and NMS Server Security

An iDirect installation includes a number of Linux servers used to configure and run the
networks. These servers include:
NMS servers for network configuration and monitoring
Protocol Processor Blade servers to manage network traffic at the hub
GKD servers to manage and distribute encryption keys
iDirect recommends securing all hub and NMS servers from unauthorized physical access.
In addition, iDirect strongly recommends implementing the security measures in the following
sections to protect the servers.
Network Isolation and External Access

In addition to limiting physical access to the servers, iDirect recommends isolation of all
networks from external access to the extent possible. Access to iDirect servers should be
protected behind a commercial-grade firewall.
If external access is required, iDirect recommends the use of secure private networks.
For Network Operators requiring remote access, including VNO operators, all connections
should be established through carefully managed Virtual Private Networks (VPNs).
All iBuilder and iMonitor clients connecting to the NMS over a Wide Area Network (WAN)
should do so over a private network or VPN.
Server Password Security

iDirect Servers are shipped with default passwords. At installation, the passwords should be
changed from the default on all servers for the following users:
root
idirect (iDX Release 2.1 and later)

iDX Release 3.3
101
NMS Client Security
Thereafter, these passwords should be changed periodically. When selecting new passwords,
iDirect recommends following common guidelines for constructing strong passwords.
Secure Server Connections

iDirect recommends using Secure Shell (SSH) for all remote connections to server machines.
SSH was designed as a secure replacement for Telnet and other remote shell protocols that do
not encrypt data by default. Once an SSH connection is established, Telnet can be safely used
to open sessions on the local host.
To further improve security, beginning with iDX Release 2.1, iDirect stopped allowing any
remote sessions (including SSH) to log on directly to the root account of any iDirect server.
Instead, use SSH to log on to a less privileged account such as the idirect account. Then enter
su - from the command line to log on as root if root access is required.
Encryption of Backup Files Before Archiving

iDirect provides a utility that Network Operators can use to back up the NMS databases. Some
operators archive the resulting backup files on external storage. iDirect recommends
encrypting backup files before copying them to external storage. The Linux gpg command,
which is available on the NMS server, is one method that can be used to encrypt the backup
files before archiving.
Clearing Data from Decommissioned Servers

When decommissioning a Linux server, iDirect recommends permanently erasing all data on
the servers hard disks and physically destroying the disks. If your company does not have
standards for decommissioning hard disks, numerous tools (such as DBAN) are available that
securely erase the data. There are also companies that shred hard drives as a service.
NMS Client Security

iDirect recommends the following measures to ensure secure access to iDirect networks from
the iBuilder and iMonitor clients.
User Passwords and Permissions

The NMS clients are preconfigured with the following users:
admin
guest
At installation, use iBuilder to change the passwords for these users from their default
settings. In addition, iDirect recommends creating NMS users with permissions tailored to the
access level requirements of the Network Operators. Create strong passwords for all such
accounts and change them periodically. See the iBuilder User Guide for details on creating
users.
102

iDX Release 3.3
Console Password Security
Client Access
Access to iBuilder and iMonitor sessions should be strictly controlled. Network Operators
should always log out of any NMS clients when leaving workstations to prevent unauthorized
access.
Remote Access
All remote access by NMS client applications to iDirect networks should be established over
secure private networks.
Console Password Security

The following iDirect network elements are pre-configured with a user account and an admin
account that allow access to the iDirect applications using a console terminal window.
Remotes
Line Cards
Protocol Processor Blades
At installation, these passwords should be changed from the default on each of these network
elements. Thereafter, these passwords should be changed periodically.
All of these passwords can be changed in iBuilder by right-clicking the network element;
selecting the Modify option from the menu; and applying the changes as required. (See the
iBuilder User Guide for details.)
NOTE: The user and admin console passwords for protocol processor blades are
configured at the Protocol Processor level of the iBuilder tree and shared by all
blades configured under that Protocol Processor.
Clearing Data from Decommissioned Remotes and Line

Cards
iDirect recommends executing the zeroize command to erase sensitive data on all
decommissioned remotes and line cards before discarding.
1. Open a console session to the remote modem or line card and log on to the admin
account.
2. At the command line prompt, enter the following command to remove all secure data:
zeroize all
If the zeroize command is unavailable, enter the command csp enable. Then execute
the zeroize command again. If the command is still unavailable, contact the iDirect
TAC.

iDX Release 3.3
103
DNS Queries on Satellite (SAT0) Interface of Remote
DNS Queries on Satellite (SAT0) Interface of Remote

iDirect Remotes with DNS Cache enabled respond to DNS queries coming from both the local
LAN port (ETH0) and the satellite port (SAT0). Ideally, remotes should only respond to such
queries coming from the local LAN port. Although there are some cases in which a remote may
be required to respond to DNS queries on the SAT0 port, this is not usually needed and could
create a security concern. All such DNS queries use UDP port number 53.
iDirect recommends implementing one of the following options to prevent DNS queries on the
SAT0 port of the remotes.
1. Prevent all such DNS queries from entering the iDirect system by configuring an
appropriate Access Control List (ACL) on the Upstream or Gateway Router.
NOTE: Option 1 is the preferred option because it prevents SAT0 DNS queries
from entering the iDirect system.
2. Configure a Downstream Filter in iBuilder to deny all UDP traffic with destination port 53.
See the iBuilder User Guide for details on creating and assigning QoS filters.
104

iDX Release 3.3
16 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 cannot be reconfigured. It
is possible to build process redundancy into the design by running duplicate processes over

iDX Release 3.3
105
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 16-1.
Figure 16-1. Protocol Processor Architecture
106

iDX Release 3.3
17 Distributed NMS Server
This chapter presents an overview of iDirects Distributed NMS Server feature. This feature
distributes the NMS server processes across multiple server machines. Distributing the NMS
processes can result in improved server performance and better use of disk space. The steps
for implementing a Distributed NMS Server are contained in the iBuilder User Guide.
Distributed NMS Server Architecture

By default, All NMS processes run on a single NMS server. In a distributed NMS, groups of NMS
processes are assigned to separate servers. The distributed NMS architecture matches the
NMS server processes to multiple server machines.
The most common distribution scheme for larger networks is shown in Figure 17-1.
Figure 17-1. Sample Distributed NMS Configuration

iDX Release 3.3
107
iBuilder and iMonitor
The configuration in Figure 17-1 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).
In the example, 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.
See the appendix Configuring a Distributed NMS Server in the iBuilder User Guide for
details.
108

iDX Release 3.3
18 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.3
109
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
110

iDX Release 3.3
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 page113.
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, configure all 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 18-1. (The exact positions and lengths of the fields may be rearranged for

iDX Release 3.3
111
implementation purposes; however, that does not change which fields are encrypted by a
given key.)
Figure 18-1. 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 page120.
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.
112

iDX Release 3.3
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 18-2) is used to hide which key is used for any given burst.
Figure 18-2. Disguising Which Key is Used for a Burst

iDX Release 3.3
113
Upstream TRANSEC
Each Code Field show in Figure 18-2 is an eight-bit (one byte) field with the following
structure:
Figure 18-3. Code Field

The Code Field (Figure 18-3) 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 18-2:
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
AES-encrypted 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
114

iDX Release 3.3
Upstream TRANSEC
provide a robust IV for the TDMA burst, the last 256 bits of the previous TDMA burst are
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 18-4 illustrates the generation of the upstream Initialization Vector.
Figure 18-4. Generating the Upstream Initialization Vector

As illustrated in Figure 18-4, 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.3
115

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 18-5.
Figure 18-5. Upstream ACQ Burst Obfuscation

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.
116

iDX Release 3.3
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.
NOTE: Beginning with iDX Release 3.2.3, the dead time required to
accommodate dummy ACQ bursts in TRANSEC networks was increased from 600 s
to 1500 s. This results in ~0.72% additional decrease in upstream bandwidth due
to ACQ burst obfuscation.

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 18-6 (Key Distribution Protocol), Figure 18-7 (Key
Rolling), and Figure 18-8 (Host Keying Protocol), are based on a standard techniques used in
an X.509-based PKI.
Figure 18-6. Key Distribution Protocol

iDX Release 3.3
117
Figure 18-6 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 18-6, 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 18-7.
Figure 18-7. Key Roll Data Structure

This data structure shown in Figure 18-7 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 Managing
TRANSEC Keys in the iBuilder User Guide.
118

iDX Release 3.3
Figure 18-8 describes the iDirect Host Keying Protocol.
Figure 18-8. 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 18-8, 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 page120. The Network Acquisition Key is encrypted
with the host public key before it is transmitted to the host.

iDX Release 3.3
119

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 18-6 on page 117 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.
120

iDX Release 3.3
ACC Key Roll

The ACC Key Roll is similar to the Dynamic Key Roll discussed in TRANSEC Dynamic Key
Management on page117.
NOTE: ACC Key Roll time is configurable. For details see the appendix Managing
TRANSEC Keys in the iBuilder User Guide.
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 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.3
121
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 the system to propagate the same ACC Keys to the remotes from multiple hub
servers, a network of GKDs is required 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 GKD Servers, see the appendix Global Key Distribution in the
122

iDX Release 3.3
19 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 page123
Awakening Methods on page124
Enabling Remote Sleep Mode on page124
Power Consumption on page125

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
The Remote Sleep Mode feature automatically powers down the BUC when the remote has no
data to transmit to conserve power. 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: The remote console commands powermgmt mode set sleep and
powermgmt mode set wakeup enable and disable remote sleep mode.
The stimulus for a remote to exit sleep mode is also configurable in iBuilder. The Network
Operator 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, the operator 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

iDX Release 3.3
123
Awakening Methods
remote receives traffic that triggers wakeup, the remote returns to the network and traffic
slots are allocated as normal by the protocol processor.
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, a Network Operator can manually force a remote into
Remote Sleep Mode and subsequently awake it from 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 timeplans 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 19-1 on page125.
Enabling Remote Sleep Mode

Remote Sleep Mode can be enabled or disabled in iBuilder on the Remote Information tab. The
service levels that trigger the remote to wake up are also configurable. 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.
With Sleep Mode enabled 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 some earlier releases that supported Sleep Mode, the SAT0 custom key was required to
force remotes to wake from sleep mode when packets arrived for transmission that matched a
124

iDX Release 3.3
Power Consumption
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 necessary.
NOTE: When Sleep Mode is enabled, a remote with RIP enabled will always
advertise the satellite route as available on the local LAN, even if the satellite link
is down. Therefore, the Sleep Mode feature is not compatible with configurations
that rely on the ability of the local router to detect loss of the satellite link.
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
Examples of the power consumed by typical remote terminals during both normal operation
and sleep mode is shown in Table 19-1.
Table 19-1. Power Consumption: Normal Operations vs. Remote Sleep Mode

iDX Release 3.3
125
Power Consumption
126

iDX Release 3.3
20 Remote Acquisition
This chapter describes how remotes join iDirect TDMA networks. The network acquisition
process requires the remote to transmit one or more acquisition bursts at various frequencies
on a dynamically assigned inroute until the hub line card successfully demodulates a burst. At
that point, the Uplink Control Process takes over to keep the remote in the network. The
protocol processor at the hub controls the acquisition process.
Acquisition Process
The protocol processor broadcasts timeplan messages on the downstream carrier that allocate
upstream traffic slots to the remotes in the network and acquisition slots to remotes that are
not in the network. When a remote is ready to join an iDirect network, it first locks to the
downstream carrier and waits for a timeplan message from the hub that invites the remote to
send an acquisition burst to the hub. The timeplan message identifies the upstream carrier,
acquisition slot, and frequency offset that the remote should use when transmitting the
acquisition burst. The remote may be assigned acquisition slots on any upstream carrier in the
inroute group.
Based on the timeplan message and configuration parameters, the remote calculates the
correct Frame Start Delay (FSD) and frequency for the acquisition burst. The remote
calculates the transmit power of the acquisition burst from the TDMA initial power and
reference carrier parameters configured in iBuilder.
The initial power must be set such that the hub receives acquisition bursts from the remote at
an acceptable C/N. Beginning in iDX Release 3.2, the characteristics (MODCOD, symbol rate,
etc.) of the upstream carriers in an inroute group may differ from carrier to carrier. If the
remote were to transmit at the same initial power on all inroutes, the C/N of the acquisition
bursts received at the hub would vary depending on the characteristics of the inroute on
which the remote was acquiring. This variation could cause interference on the upstream
carrier or missed acquisition bursts from the remote.
To prevent this variation in C/N, reference carrier parameters are configured in iBuilder along
with the TDMA initial power. If the remote is assigned an acquisition slot on a carrier that
differs from the configured reference carrier, the remote adjusts its initial transmit power to
compensate for the differences between the reference carrier and the assigned carrier. This
allows the C/N of the acquisition bursts to remain within the acceptable range regardless of
the inroute on which the remote acquires. For a description of the reference carrier
parameters, see Reference Carrier Parameters on page41. The Installation and
Commissioning Guide for iDirect Satellite Routers contains Instructions for setting the TDMA
initial power and reference carrier parameters for a remote.

iDX Release 3.3
127
Acquisition Process
If the hub fails to detect the acquisition burst from the remote in the assigned acquisition
slot, it allocates another upstream acquisition slot to the remote. The hub changes the
remotes frequency offset for the new burst if the acquisition step size for the carrier is
smaller than the total sweep range. The sweep range is mainly determined by the stability of
the hub downconverter.
This process continues until the hub detects an acquisition burst from the remote. Once the
hub detects an acquisition burst, the hub sends the frequency offset correction to the remote
and the Upstream Control Process takes over to keep the remote in the network at the correct
power, frequency and symbol timing. (For more information, see Uplink Control Process on
page79.)
The performance of the acquisition process is determined by the speed with which remotes
join the network and the number of acquisition bursts the remote must transmit before a
burst is successfully demodulated. If a remote can acquire the network more quickly by trying
fewer frequency offsets, the number of opportunities that other remotes have to acquire is
increased and the number of remotes that are out of the network at any one time is reduced.
Therefore optimization of the acquisition process involves reducing the number of acquisition
bursts that remotes must transmit to acquire the network.
iDX Release 3.3 supports two types of remote acquisition: Traditional Acquisition and
Superburst Acquisition. The type of acquisition is configured per upstream carrier in iBuilder.
Superburst Acquisition greatly improves the time and bandwidth required for remotes to join
the network and should be used whenever possible. However, in this release Superburst
Acquisition can be used only on upstream carriers being received by multichannel line cards
or by receive-only eM1D1 line cards.
When receiving a traditional acquisition burst, the TDMA demodulator at the hub has a narrow
tolerance for frequency offset (approximately 1.5% of the upstream carrier symbol rate for all
modulation types). Because of this, the hub may fail to demodulate an acquisition burst at the
assigned frequency offset. Therefore, the hub varies the frequency offset in the timeplan
messages causing the remote to burst at different frequencies within a defined frequency
range (or sweep range) until the demodulator at the hub detects the upstream burst.
When receiving a Superburst, the hub demodulators tolerance for frequency offset improves
to approximately 7.5% of the symbol rate. A Superburst is also a much more robust waveform
that is independent of the carrier MODCOD. These advantages allow the hub to detect a
Superburst over a much wider frequency range and at a much lower C/N when compared to a
traditional acquisition burst. Therefore, in most cases, a remote must only transmit a single
Superburst to acquire the network. When using Superburst, frequency sweeping is typically
not required since the sweep step size is generally larger than the instability of the hub
downconverter. In the rare cases when sweeping is required, the remote sweeps the
frequency range using the same fast acquisition method as a remote acquiring with
traditional acquisition bursts.
The frequency sweeping algorithm is described in the next section. For more on Superburst,
see Superburst Acquisition on page130.
In iDX Release 3.3, Traditional Acquisition is still required in the following cases:
128
Acquisition over Spread Spectrum upstream carriers
Acquisition in TRANSEC networks
Acquisition on upstream carriers received by single channel line cards except receive-only
eM1D1 line cards configured for Single Channel TDMA (Adaptive) Receive Mode.

iDX Release 3.3
Acquisition Algorithm
Acquisition on upstream carriers received by multichannel line cards in Single Channel

TDMA Receive Mode
Acquisition on upstream carriers received by Evolution XLC-M line cards with more than
eight assigned narrow-band carriers
NOTE: By default, Superburst Acquisition is used whenever possible. However, if
Superburst is disabled for the carrier in iBuilder, the remotes revert to Traditional
Acquisition.
Acquisition Algorithm
The acquisition algorithm determines how the protocol processor selects the various
frequency offsets at which the remote transmits acquisition bursts. In iDS Release 7.1,
changes were made to the acquisition algorithm that greatly improved the network
acquisition process used in prior releases. By using a common hub receive frequency offset,
the improved acquisition algorithm determines an anticipated frequency range smaller than
the complete frequency sweep range 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.
When a remote first attempts to acquire the network, the hub assigns frequency offsets using
the smaller frequency range based on the common frequency offset. For a given ratio x:y, the
remote sweeps the smaller frequency range x times. After x of sweeps over the smaller
frequency range, the remote sweeps the entire range y times before it sweeps the narrower
range again. The default ratio is 100:1. That is, the remote tries 100 frequency offsets within
the reduced (common) range before resorting to one full sweep of the remotes entire
frequency range.
The sweep algorithm is the same whether the remote is transmitting traditional acquisition
bursts or Superbursts. However, when using Superburst the remote is highly likely to acquire
the network on the first acquisition burst. The frequency step size is automatically
determined based on the acquisition types and symbol rates of the carriers in the inroute
group. The step size used for all remotes is the smallest of all step sizes calculated
independently for each carrier.
A Network Operator can configure the following custom keys to override the default ratio of
fast sweeps to full sweeps. These custom keys must be applied to the hub side for each
remote in the network.
[REMOTE_DEFINITION]
sweep_freq_fast = <x>
sweep_freq_entire_range = <y>
sweep_method = <0 or 1>
where: <x> is the number of times to sweep the common frequency range (Default: 100)
<y> is the number of times to sweep the full frequency range (Default: 1)
sweep_method = 1 uses the fast sweep algorithm described above
sweep_method = 0 uses pre-iDS 7.1 sweeping over the full frequency range
The NMS does not use the fast sweep algorithm for any remote that is enabled for an iDirect
Music Box; for any remote that is not configured to use the 10 MHz reference clock; or for any
remote with the sweep_method custom key set to 0. In those cases, the remote sweeps the

iDX Release 3.3
129
Superburst Acquisition
entire acquisition frequency range each time. In IF networks, such as those used in test
environments, the 10 MHz reference clock is not used.
Beginning with iDX Release 3.2, remotes can use Superburst Acquisition to acquire the
network on non-spread upstream carriers received by multichannel line cards or by receiveonly eM1D1 line cards. To use Superburst Acquisition, the Receive Mode of a multichannel line
card must be set to Multiple Channel TDMA Mode in iBuilder. The Receive Mode of a receiveonly eM1D1 line card must be set to Single Channel TDMA (Adaptive). Superburst is not
available for carriers received by any other Line Card Types in any other Receive Modes.
A maximum of eight TDMA upstream carriers with Superburst enabled can be assigned to one
multichannel line card. In addition, all carriers received by a multichannel line card must be
configured for the same type of acquisition bursts. Superbursts and traditional acquisition
bursts cannot be received simultaneously by the same line card.
An Evolution XLC-M line card can receive up to 16 narrowband carriers. Since a multichannel
line card cannot receive more than eight carriers with Superburst enabled, an XLC-M line card
receiving more than eight carriers must use iDirects Traditional Acquisition for all carriers.
Advantages of Superburst
Superburst Acquisition represents a significant improvement when compared to iDirects
Traditional Acquisition. Superburst allows a remote to quickly acquire the network under
clear sky or fade conditions in much less time than Traditional Acquisition. This improvement
is due to the robust nature of the Superburst waveform and the frequency tolerance of the
Superburst demodulator.
When using iDirects Traditional Acquisition, the frequency detection of the TDMA
demodulator at the hub is limited to a frequency offset of 1.5% of the symbol rate. Due to
frequency inaccuracies throughout the satellite system (mainly caused by the instability of
hub downconverter), the remote must sweep in discrete frequency steps until the
demodulator detects a burst. Because of the limited detection range, remotes typically
transmit a number of bursts during the sweep that are not detected. This results in a
significant number of allocated acquisition slots that do not result in remote acquisition.
Additionally, the traditional acquisition bursts are identical to traffic bursts. Therefore there
is no additional frequency tolerance or C/N performance that the demodulator can take
advantage of to detect a remotes burst more quickly.
Superburst Acquisition addresses both the narrow tolerance for frequency offset and the
disadvantages of transmitting the acquisition burst at the same MODCOD as the upstream
traffic bursts. Superbursts are transmitted using a unique, robust waveform that is
independent of the MODCOD of the upstream carrier. Superburst increases upstream symbol
rate frequency tolerance from 1.5% to 7.5% of the upstream symbol rate. In addition, the hub
can reliably detect a Superburst with receive C/N between 2.5 dB and +20 dB.
Because of these improvements, the hub usually detects a remotes first Superburst. In that
case the remote acquires the network on the first attempt and no frequency sweeping is
required. However, in rare cases (for example at low symbol rates with large hub
downconverter instability), a remote may need to transmit a small number of additional
Superbursts to acquire the network. Typically, a sweep requires no more than a few steps.
130

iDX Release 3.3
NOTE: More acquisition attempts may be required in the case of high-speed

mobile remotes due to the high Doppler shift.
Considerations When Using Superburst

This section contains details that network designers and Network Operators should consider
when using Superburst Acquisition. Many of these considerations concern Adaptive TDMA
networks. Special considerations are warranted for Adaptive TDMA networks due to the
heterogeneous characteristics of the upstream carriers.
Acquisition Carrier Selection

Each time an acquisition slot is allocated to a remote, the protocol processor selects a new
upstream carrier on which the remote is invited to acquire. An adaptive inroute group may
contain upstream carriers with different symbol rates and MODCODs. Larger carriers require
the remote to transmit at a higher power for the burst to be received by the hub at a given
C/N. Although it is possible that a remote terminal may have insufficient power to acquire on
a large upstream carrier, this is unlikely since the hub line card can reliably demodulate a
Superburst as low as 2.5 dB. In the rare case that Superburst acquisition fails due to
insufficient remote power, the next invitation will be on a different, randomly-selected
carrier.
Transmit Power Adjustment for Non-reference Carriers

When a new remote is commissioned in an adaptive inroute group, Reference Carrier
parameters are configured on the iBuilder Remote Information tab along with the TDMA Initial
Transmit Power determined during the commissioning procedure. When a previouslycommissioned remote is assigned to a new inroute group or the carriers in an inroute group
are modified, the remotes Reference Carrier parameters should not be changed. When
upgrading from an earlier iDirect release that does not support Adaptive TDMA, each remotes
Reference Carrier parameters are set automatically to match the carriers in the remotes
inroute group.
The demodulator at the hub functions optimally when the received power spectral density is
similar for all remotes. For a remote acquiring the network, the goal is to set the initial power
such that the remote transmits acquisition bursts at an operating point similar to the
operating point of the carrier on which it is transmitting. With Adaptive TDMA, a remote may
be instructed to acquire on a carrier that does not match its configured reference carrier. In
that case, the remote adjusts the initial transmit power to maintain the spectral density of
the transmission. The procedure for setting a remotes TDMA Initial Transmit Power is
contained in the Installation and Commissioning Guide for iDirect Satellite Routers.
Ability to Acquire When No Traffic Carrier Is Available

When a Superburst is received from a remote, the protocol processor determines the
appropriate nominal carrier for the remote in the inroute group. In making this selection, the
protocol processor considers measurements made on the Superburst; information sent in the
Superburst; and the remotes configuration.

iDX Release 3.3
131
Because of the robust nature of the Superburst waveform, the hub line card may successfully
demodulate a remotes Superburst even though the remote is incapable of joining the
network on any carrier in the inroute group. For example, this might occur during a rain fade
at the remote. If the remote cannot join the network on any carrier, the protocol processor
sends an event to the NMS and continues to allocate acquisition slots for the remote.
132

iDX Release 3.3
21 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. This chapter also uses the term beam to refer to an iDirect outroute and
its associated inroutes.
iDirect remotes can 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
global IP access.
The decision of which network (or beam) a particular remote joins is made by the remote.
When joining a new beam, the terminal must re-point its antenna and the remote modem
must tune to a new outroute. Selection of the new beam can be performed automatically
using ABS or manually by using remote modem console commands. 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
appendix Configuring Networks for Automatic Beam Selection in the iBuilder User Guide.
If using the iDirect TRANSEC feature for ABS networks, Global Key Distribution is required 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 Global Key Distribution in the iBuilder User Guide.
If the mobile remotes in an ABS network exceed 150 mph, they must be licensed for the HighSpeed COTM feature. In addition, high-speed remotes require special configuration. For
details, see the appendix COTM Settings and Custom Keys in the iBuilder User Guide.
Mobile remotes that exceed 150 mph must licensed for the High-Speed COTM feature. In
addition, high-speed remotes require special configuration. For details, see the appendix
COTM Settings and Custom Keys in the iBuilder User Guide.
NOTE: Automatic Beam Selection is not supported on Evolution X1, X3 or e150
remotes.

iDX Release 3.3
133
Theory of Operation
Theory of Operation
ABS is built on iDirects existing mobile remote functionality. When a remote is in a particular
beam, it operates as a traditional mobile remote in that beam.
Overview
In an ABS system, a roaming remote terminal consists of an iDirect remote modem and a
controllable, steerable, stabilized antenna. The ABS software in the remote modem can
command the antenna to find and lock to any satellite. Using iBuilder, a Network Operator
defines an instance of the remote in each beam that the remote is permitted to use. The
operator configures and monitors all instances of the remote as a single entity. The
consoldated remote options file (which conveys configuration parameters to the remote
from the NMS) contains the definition of each of the remotes beams. Consolidated options
files are described in the iBuilder User Guide.
As a remote moves from one beam to another, the remote must switch from its current 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 remote reads the current location from the antenna and decides
which beam will provide optimal performance for that location. The remote selects the new
beam based either on a beam map or, if no map is available, using a round-robin selection
algorithm. This selection 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 in any iDirect network.
iDirect Beam Map File and Map Server

Before joining a network, the remote must determine the best beam to use in its current
location. Once acquired, the remote may move to a higher-quality beam if one is available. In
both cases, the remote relies on a beam map file to determine the best beam.
The beam map file is a large data file containing beam quality transmit power information for
each point on the Earth's surface as computed by the Satellite Provider. Sections of the beam
map file (called beam maplets) are downloaded from the NMS to the remote and stored in
non-volatile memory on the remote.
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 responds to map requests
from remotes. A single map server may be deployed (for example, on the NMS server
machine) or multiple instances of the map server may be deployed on processors that are colocated with the remotes. Maritime applications typically use a map server at the hub, while
avionics applications typically require a local map server for each remote. The details depend
on the application.
Prior to iDX Release 3.0, when the iDirect NMS services started on an 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.
A remote has a limited amount of non-volatile storage, so it cannot save an entire map of all
beams. Instead, the remote asks the map server to send a map of a smaller area (called a
beam maplet) that encompasses its current location. When the remote nears the edge of its
current maplet, the remote sends a request to the map server for a new maplet centered on
134

iDX Release 3.3
Theory of Operation
its new location. The geographical size of the beam maplets varies in order to keep the file
size approximately constant. A typical beam maplet covers approximately 1000 km square
with 0.1 degree resolution. From the maplet, the remote determines the Beam Quality and Tx
Gain for each beam at its current location.
The Beam Quality depends on the geographic location of the remote. To decide which beam
to join, the remote looks up the Beam Quality for each beam at its current location. When
first acquiring a network, the remote uses the Beam Quality of the various beams as inputs to
a decision algorithm that selects the best beam. Once the remote has joined a beam, it
periodically compares the Beam Quality of other networks to the current Beam Quality. When
the Beam Quality on an alternate beam is higher than the current Beam Quality (plus an
additional hysteresis for stability), the remote automatically switches to the alternate beam.
By default, a remote 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 Beam Quality
value of zero for the remotes current location. However, selecting Inhibit Tx (when Beam
Quality = 0) in the iBuilder Network dialog box configures 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. For details
on configuring and running a map server, see the appendix Configuring Networks for
Automatic Beam Selection in the iBuilder User Guide.
Beam Selection
The remote uses the Beam Quality of its current location to determine which beam to use.
The following rules apply:
If the remote has not joined a network, it attempts to enter the beam with the highest
Beam Quality number. If it fails to do so after a configured timeout period, it cycles
through the lower Beam Quality beams in order.
If a remote is already in a network, it switches beams if there is a beam with a Beam

Quality that is higher than the current Beam Quality plus an offset known as the quality
hysteresis. The quality hysteresis is defined in the map file header.
A Beam Quality of 0 is a special value indicating that the beam is not usable at the current
location due to lack of coverage and/or geopolitical constraints. (See Regulatory
Considerations on page136.)
The Tx Gain values read by the remote from the beam map are used in two ways:
When the remote is attempting to acquire the network, it adjusts the initial transmit
power based on the Tx Gain of the current location. This allows the system to compensate
for G/T variations of the satellite. (See Initial Transmit Power on page139 for details.)
A Tx Gain of 0 indicates that the beam is receive-only at this location. The remote will
remain in the beam if it is locked on the downstream carrier. However, the remote will
not attempt to establish a return link. This feature can be used to designate receive-only
geographic areas. (See Regulatory Considerations on page136.)

iDX Release 3.3
135
Theory of Operation
Conveyance Beam Map File

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. The
conveyance file contains information on Beam Quality, Tx Gain, and (optionally) regulatory
restrictions for areas within the satellite footprint of the beam.
A conveyance beam map file must be in one of two formats:
The GXT format is an open standard developed by iDirect. The GXT format is specified in
the iDirect GXT Map Converter User Guide.
The Intelsat format is proprietary. Conveyance beam map files in this format can only be
provided by Intelsat Corporation.
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 supported
conveyance file format.
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. Instructions for
converting a conveyance beam map file into an iDirect beam map are contained in the
iBuilder User Guide appendix Configuring Networks for Automatic Beam Selection.
Beginning in iDX Release 3.2, the system uses the Tx Gain contours when calculating C/N
adjustments used to determine the maximum C/N at which a remote can be received at its
current location. Because of this, the minimum Tx Gain contour for all beams in the
generated beam map should be set to zero. When using the GXT format for conveyance beam
maps, this can be accomplished by setting the gain_offset in the GXT header file such that
the minimum Tx Gain of each beam as defined in the beams gain file plus the gain_offset
for that beam equals zero. The formats of the GXT header file and gain files are defined in
Regulatory Considerations
iDirect supports the use of separate GXT data files for reading Beam Quality and Tx Gain
information into the iDirect GXT Map Converter utility used for creating beam maps. The GXT
Map Converter also supports the input of geo-political or regulatory constraints. The
regulatory file input uses the same GXT data format as Beam Quality and Tx Gain data files.
The regulatory input creates regulatory contours in the resulting beam map file. A
regulatory contour restricts the service for all beams in the specified area. This avoids the
necessity of individually editing each conveyance beam map file. The GXT data file format
and its use are described in the iDirect GXT Map Converter User Guide.
The two types of regulatory contours are Do Not Operate and Do Not Transmit. A Tx Gain of 0
for a regulatory contour means Do Not Operate. A Tx Gain of 1 for a regulatory contour means
Do Not Transmit.
A Do Not Transmit contour defines a receive-only area for multicast traffic. This disables
remote transmissions in the specified area. Examples of when Do Not Transmit contours can
be useful include:
136
Some Ku band transmissions are prohibited near radio telescope installations.
Some regulatory restrictions limit transmissions over a specific country, even when the
satellite beam covers more than that country.

iDX Release 3.3
Theory of Operation
In either example, adding a Do Not Transmit regulatory contour prevents the remote from
transmitting in the specified location. When a remote receives GPS coordinates indicating
that it has entered a Do Not Transmit contour, it mutes its transmitter within approximately
100 ms.
A Do Not Operate contour disables remote operation. This includes muting transmissions and
disabling receive-only operation within the specified geographic area. For example, a country
may prohibit any operation within its national air space, including receive-only operation.
Do Not Transmit and Do Not Operate contours are added during the map conversion process
from the conveyance format to the map format. A Do Not Operate contour forces the Beam
Quality values to 0 within the contour for all beams. This sets all beams to an unusable state.
A Do Not Transmit contour forces the Tx Gain values to 0 within the contour for all beams.
This tells the terminal to operate in receive-only mode and to mute all transmissions.
If a remote is within a regulatory contour, then leaves the area covered by the current
maplet, and does not have a maplet that covers its new location, it switches to mapless mode
and no longer observes the regulatory restriction. Once it receives a new maplet covering its
current location, it will observe any regulatory contours defined for that location. Using a
local map server machine is the best way to ensure that the remote always has a maplet
covering the current location.
When using the GXT conveyance file format, a Network Operator can define Do Not Operate
and Do Not Transmit contours in a GXT data file and add these contours to the beam map. The
steps for adding regulatory data to the beam map are:
1. Create a GXT data file as specified in the section Geopolitical Constraint Data Files in
2. Update the GXT header file to point to the GXT data file as specified in the iDirect GXT
Map Converter User Guide.
3. Copy the files to the /etc/idirect/map/Beams directory of the NMS server.
4. Re-execute the GXT Map Converter Utility to add the regulatory data to the beam map
and restart the map server. See the appendix Configuring Networks for Automatic Beam
Selection in the iBuilder User Guide for details.
Do Not Operate and Do Not Transmit contours can also be implemented in the Intelsat format.
However, this requires the conveyance beam map files from the Satellite Provider to already
have the proper values set to zero for the beams in the affected locations.
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 the satellite in iBuilder
unless it is overridden for the remote on the Remote Geo Location tab. See the appendix
Configuring Networks for Automatic Beam Selection 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.

iDX Release 3.3
137
Theory of Operation
NOTE: A custom key is required to change the length of time that a remote
considers beams to be unusable. (See the appendix Configuring Networks for
Automatic Beam Selection in 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 events that can cause a beam to become unusable include:
The NMS operator disables the remote 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 remote.
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 remote, eventually causes Layer 3
to fail. The remote stops transmitting if it loses downstream lock. A mobile remote will also
stop transmitting under the following conditions:
The remote has not acquired the beam and no GPS information is available.
The remote antenna declares loss-of-lock.
The antenna declares a blockage.
Beam map data places the remote in receive-only mode.
The remote has been configured as Rx Only in iBuilder.
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:
138
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.

iDX Release 3.3
Theory of Operation
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, remotes continue to operate without a map as described
above. However, a remote custom key can be configured that tells the remote to
mute its transmitter when the remote does not have a maplet that covers its
current location. See the appendix Configuring Networks for Automatic Beam
Selection 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. The following antenna protocols are currently supported:
Open AMIP
Orbit-Marine AL-7104
Schlumberger SpaceTrack 4000
SeaTel DAC
OpenAMIP is an ASCII-based protocol developed by iDirect used to exchange information

between the remote modem and an antenna controller. It allows the remote modem and
controller to exchange the information necessary for the remote to initiate and maintain
satellite 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 requests the current location from the antenna controller.
IP Mobility
Communications to the customer intranet (or to the Internet) are automatically reestablished after a beam switch. 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.
Initial Transmit Power

The optimal initial transmit power that a remote should use for acquisition bursts transmitted
on the TDMA upstream carriers 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.

iDX Release 3.3
139
Theory of Operation
If the transmit power of the acquisition burst is too high, it may over-drive the satellite;
violate spectrum regulations; or adversely affect the Uplink Control processing at the hub. If
the transmit power of the acquisition burst is too low, the remote may be unable to acquire
the beam.
The beam maplet on the remote stores location-dependent Tx Gain (in a dB scale) for the
inbound for different locations for each beam. The remote uses this information along with
the configured Initial Transmit Power Offset to calculate the transmit power of the acquisition
bursts. The Tx Gain stored in the beam map represents the increase above the G/T for the
edge of the satellite footprint.
In addition, for some antenna designs, the beam gain varies with the satellite elevation. In
that case, the calculation of initial transmit power also considers the gain variation of the
antenna as a function of elevation if this information is configured in iBuilder.
Calculation of Initial Transmit Power

The remote considers the following values when calculating the initial transmit power:
The Tx Gain budgeted for the link at the current location as read from the beam map
The Initial Transmit Power Offset determined at commissioning and configured on the
iBuilder Remote VSAT tab. (See Setting the Initial Transmit Power Offset on page140.)
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 transmit power:
1. The remote retrieves the Tx Gain for the current location from the beam map.
2. The remote subtracts the Tx Gain for the current location from the configured Initial
Transmit Power Offset to determine the initial transmit power.
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 options file.
c. The remote adjusts the initial power computed in Step 2 to account for the gain
variation.
Once the remote has acquired the carrier, the UPC algorithm takes over to regulate the
transmit power during operation.
NOTE: If the beam map is not available, the remote uses the TDMA Initial Power
configured on the Remote Information Tab to acquire the beam rather than the
Initial Transmit Power Offset.
Setting the Initial Transmit Power Offset

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.
140

iDX Release 3.3
Theory of Operation
The procedure for determining and setting the Initial Transmit Power Offset during
commissioning involves both the Network Operator and the installer at the remote site. The
steps are:
1. When the remote first locks to the downstream carrier, the Network Operator uses the
iMonitor Probe to gradually increase the remote transmit power until the remote joins the
network. (See the iMonitor User Guide and the Satellite Router Commissioning Guide for
details.)
2. The Network Operator waits for the Transmit Power displayed in the Probe to stabilize.
Figure 21-1. iMonitor Probe: Remote Power Section

3. The installer verifies that the remote has requested and received the maplet for the
current location over the TCP/IP link to the map server by entering the console command:
map show
4. The installer enters the following console command to determine the Initial Transmit
Power Offset of the remote:
beamselector txpower offset <acquisition power>
Where <acquisition power> is the Transmit Power from the Probe (Figure 21-1) plus
any budgeted margin to ensure that the remote can acquire under all conditions.
5. On the iBuilder VSAT tab, the Network Operator enters the transmit power offset returned
by the console command in Step 4 as the Init Tx Power Offset (Figure 21-2).
Figure 21-2. Remote VSAT Tab: Entering the Initial Transmit Power Offset
6. The Network Operator saves and applies the iBuilder configuration changes.
Determining the Initial Transmit Power Offset for Other Beams

Configuring the Initial Transmit Power Offset value ensures that the remote will always use an
appropriate power level when acquiring the network anywhere in the beam where the
commissioning took place. In general, different values of this parameter are required for
different beams. Therefore, this parameter should be configured individually in iBuilder for
each of the roaming remotes networks.
These differences stem primarily from variations in the available link budget between the
beams. Furthermore, since the absolute reference for the map (the 0 dB contour) can also

iDX Release 3.3
141
Theory of Operation
differ between beams, it is not possible to infer the value for one beam automatically from
that used for the commissioning. The network designer or network operator must determine
an appropriate value for the additional beams and configure them separately in iBuilder.
Because the gain values retrieved from the map represent the receive sensitivity (G/T) of the
satellite, if the link budget is uplink-dominated, the necessary adjustment in the Initial
Transmit Power Offset value between beams is equal to the difference in absolute value of
the G/T between the beams. The following example illustrates this.
Absolute Contours
Generated Map
-3 dB/K
0 dB
+1 dB/K
+4 dB
Beam A:
X
+2 dB/K
0 dB
+4 dB/K
+2 dB
Beam B:
Figure 21-3. Absolute vs. Generated G/T Contours for Two Beams
Figure 21-3 shows two beams: Beam A and Beam B. The two diagrams on the left show the
absolute G/T contours for the beams, as obtained from the satellite operator. The generated
map defines the edge of coverage for each beam as the 0 dB contour. The G/T contours of the
generated map are shown on the right for each beam.
Assume the remote is commissioned in Beam A at point X and that the steady-state power
observed is 10 dBm. (All power levels used in this example are normalized to the reference
carrier). The beamselector txpower offset command used to determine the offset will
return a value of 6 dBm, corresponding to the power that would be needed if the acquisition
took place at the edge of coverage. During actual acquisition attempts in Beam A, the remote
automatically adjusts for the location so that the power used is appropriate.
If the same power setting were used to attempt to acquire in Beam B, the bursts would likely
arrive at a too high level, potentially causing interference or over-driving the satellite and/or
the demodulator. For example, if the remote attempted to acquire at location Y with the
same power setting as in Beam A, then the transmit power would be 8 dB, which is 2 dB
lower than the edge-of-beam value.
142

iDX Release 3.3
Theory of Operation
If the difference in G/T is the only difference between the link budgets for these two beams
(for example, if both beams are dominated by the uplink), then the bursts in beam B will
arrive at a level corresponding to the difference in the edge-of-beam G/T. In that case, the
network designer can conclude that the Initial Transmit Power Offset value for beam B should
be 5 dB lower than that used for beam A, or 11 dBm. At point Y the acquisition power used
would be 13 dBm.
If there are other factors influencing the inbound link budget, a more detailed assessment of
the differences between the beams may be appropriate for determining the Initial Transmit
Power Offset value, or the remote should be commissioned separately in each beam.
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 the 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. (See Regulatory Considerations on
page136 for more information.)
NOTE: This feature can be disabled on a remote by entering a custom key. See the
appendix Configuring Networks for Automatic Beam Selection in the iBuilder
User Guide for details.
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.
Multiple Map Servers per Network

Prior to iDX Release 3.0, an ABS network was limited to a single map server process running at
the NMS that supplied the beam map data to all remotes. This restriction has been removed.
To enable receive-only operations, and for general system robustness, the system supports
multiple map servers per network. This allows the deployment of a local map server for each
remote.
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 remotes in their
options files and used by the remote to communicate with the map server.
To run a local version of the map server, 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 appendix Configuring Networks for Automatic
Beam Selection in the iBuilder User Guide for the definition of this custom key.)

iDX Release 3.3
143
Operational Scenarios
This section presents a series of top-level operational scenarios that can be followed when
configuring and managing iDirect networks that contain roaming remotes using Automatic
Beam Selection. Steps for configuring network elements such as iDirect networks (beams) and
roaming remotes are documented in iBuilder User Guide. Steps specific to configuring ABS
functionality, such as adding an ABS-capable antenna or converting a conveyance beam map
file, are described in the appendix Configuring Networks for Automatic Beam Selection in
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 and Satellite Provider 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 or independently.
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 in one beam.
2. The NMS operator adds the remote to the remaining beams.
3. The NMS operator saves the remote's options file and delivers it to the installer.
4. The installer installs the remote.
5. The installer copies the options file to the remote using iSite.
6. The installer manually selects a beam for commissioning.
7. The remote commands the antenna to point to the satellite.
8. The remote receives the current location from antenna.
144

iDX Release 3.3
9. The installer commissions the remote in the initial beam.

10. The remote enters the network and requests a maplet from the NMS map server.
11. The remote checks the maplet. If the commissioning beam is not the best beam, the
remote switches to the best beam as indicated in the maplet. This beam is then assigned
a high preference rating by the remote to prevent the remote from switching between
overlapping beams of similar quality.
12. Assuming center beam in clear sky conditions:
a. The installer determines the Initial Transmit Power Offset as discussed in Setting the
Initial Transmit Power Offset on page140.
b. The Network Operator sets the Initial Transmit Power Offset in iBuilder on the Remote
VSAT tab.
c. The Network Operator sets the TDMA Maximum Power to 6 dB above the nominal
transmit power in iBuilder on the Remote Information tab.
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 remote is
receiving map information from the NMS.
1. As the remote moves, it 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, it 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. Commands the antenna to move to the correct satellite and beam.
d. Reboots.
e. Reads the new best beam from non-volatile storage.
f.
Again commands the antenna to move to the correct satellite and beam.
NOTE: This command is repeated after reboot because the remote is not
aware of the reason for restart. The antenna controller ignores the repeated
command since it has already been commanded to track this beam in Step c.
g. Joins the new beam.
Mapless Operations
This scenario describes the events that occur during operations when a remote is not
receiving beam mapping information from the NMS.

iDX Release 3.3
145
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 (by default), 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 remote 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 remote 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.
If the antenna is initializing, the remote waits for the initialization to complete. It will not
attempt to switch beams during this time.
146

iDX Release 3.3
22 Hub Geographic
Redundancy
This chapter describes how to establish a primary and back up hub that are geographically
diverse. It includes the following sections:
Section, Feature Description describes how geographic redundancy is accomplished.
Section, Configuring Wait Time Interval for an Out-of-Network Remote describes how to
set the wait period before switchover.
Feature Description
The Hub Geographic Redundancy feature builds on the Global NMS feature and the existing
Backup and Restore utilities. The Network Operator configures 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) the operator can manually enable the
downstream transmission on the Backup Teleport, allowing the remotes to automatically
acquire the downstream transmission through the Backup Teleport NMS. Re-acquisition occurs
after a wait period that defaults to five minutes.
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 the NMS configuration database between the
Primary and Backup Teleports. See the NMS Redundancy and Failover Technical Note for
complete NMS redundancy procedures.

iDX Release 3.3
147
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, to make the wait period 10 minutes, use the following custom key:
[REMOTE_DEFINITION]
net_state_timeout=600
NOTE: Roaming is not supported on Evolution X1 remotes. Therefore, X1 remotes
cannot automatically switch to a new downstream carrier.
For further configuration information, see the chapter Defining Network Components in the
148

iDX Release 3.3
23 Carrier Occupied
Bandwidth
This chapter discusses occupied bandwidth of iDirect carriers. Occupied bandwidth includes
the actual carrier size plus the guard band required to prevent interference with adjacent
carriers. Minimizing the guard band between adjacent carriers optimizes the use of the
available satellite bandwidth.
In earlier releases, iDirect required a minimum guard band of 20% of the carrier symbol rate
for both upstream and downstream carriers. Beginning with iDX Release 3.2, the minimum
guard band required for DVB-S2 downstream carriers has been reduced from 20% of the carrier
symbol rate to 5% of the carrier symbol rate by reducing the roll-off factor of these carriers.
This is discussed in detail in DVB-S2 Roll-Off Factors on page151.
This chapter includes the following sections:
Overview describes the relationships among occupied bandwidth, guard band and
information rate and factors to consider when setting the guard band.
DVB-S2 Roll-Off Factors describes the improvements to the iDirect downstream carrier
wave form that allow reduced guard bands beginning with iDX Release 3.2.
Improving Throughput by Reducing Guard Band provides an example of how to increase

the efficiency of the occupied bandwidth by reducing the guard band of DVB-S2 carriers.
DVB-S2 Guard Band Constraints specifies limitations of minimum symbol rates and
MODCODs for DVB-S2 carriers with small guard bands.
Adjacent Channel Interference discusses the relationship between DVB-S2 Roll Off factor
and interference on adjacent carriers.
Overview
A lower guard band 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.
Optimized digital filtering is used in the iDirect transmit firmware to minimize the amount of
satellite bandwidth required for an iDirect carrier. For upstream carriers, iDirect supports a
guard band as low as 20% of the carrier symbol rate. Beginning in iDX Release 3.2, iDirect
supports a guard band for DVB-S2 downstream carriers as low as 5% of the carrier symbol rate.
The amount of required guard band between carriers can also be expressed as the carrier
spacing requirement. For example, if the required guard band is 20%, the channel spacing

iDX Release 3.3
149
Considerations When Determining Guard Band
requirement is 1.2*Carrier Symbol Rate in Hz. Carrier spacing can be configured in iBuilder for
upstream and downstream carriers. This field can be used to document the total occupied
bandwidth of the carriers. It represents the carrier bandwidth plus the guard band normalized
by the symbol rate.
The Carrier Spacing configured in iBuilder is only enforced on multichannel receive line cards
to prevent overlap when assigning upstream carriers to a specific line card. Otherwise, it is
the responsibility of the Network Operator to ensure that adjacent carriers do not interfere
with each other.
Considerations When Determining Guard Band

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 guard
bands slightly greater than those specified in this chapter. iDirect complies with the adjacent
channel interference specification in IESS 308 which accounts for adjacent channels on either
side with +7 dB higher power.
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. For TDMA upstream carriers,
iDirect networks combat frequency offset using an automatic frequency control algorithm.
Any additional instability must be accommodated by additional guard band.
The frequency references to the hub transmitter and to the satellite itself are generally very
stable so a main source of upstream 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 remotes 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 have a finite frequency stability range.
Transient errors are a major risk for upstream TDMA carriers if there is insufficient guard
band. During remote acquisition, if there is frequency uncertainty due to remote mobility or
instability of the hub downconverter, it may take several UCP intervals for the hub to correct
the remotes frequency offset. During that time, bursts transmitted by the remote may cause
significant CRC errors on the upstream carrier and adjacent carriers. During operation, when
a mobile remote experiences Doppler shift or the ambient temperature at a remote site
changes suddenly, insufficient guard band may result in transient CRC errors while the UCP
algorithm is correcting for the frequency shift. Some customers may want to include
additional guard band to prevent such transient errors. Others may choose to tolerate these
errors if the transient conditions are relatively rare in order to optimize bandwidth usage.
Upstream CRC errors can be monitored using iMonitor. For details, see the section on viewing
Upstream Performance Statistics in the iMonitor User Guide.
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 possibility with the satellite link designer when determining the carrier parameters.
150

iDX Release 3.3
DVB-S2 Roll-Off Factors

Digital communication systems employ waveform pulse shaping using identical matched filters
at the transmit and receive sides to limit the occupied bandwidth required by a carrier and to
maximize received Signal to Noise Ratio (SNR). The matched filters used for linear modulation
signals belong to a class of Nyquist filters having Raised-Cosine filter shapes with different
carrier roll-off factors. The roll-off factor of a digital filter defines how much more bandwidth
the filter occupies than that of an ideal brick wall filter which defines the theoretical
minimum occupied bandwidth. This dictates the guard band requirement for the carrier.
The DVB-S2 standard specifies roll-off factors of 20%, 25% and 35%. In earlier releases, iDirect
used 20% for all waveforms for both upstream and downstream carriers. Beginning in iDX
Release 3.2, iDirect has reduced the DVB-S2 roll-off factor (and therefore the required carrier
guard band) to as low as low as 5% of the carrier symbol rate.
NOTE: Evolution e8000 Series remotes can only be used with downstream carriers
configured for a 20% roll off factor (carrier spacing 1.2). If an Evolution e8000
Series remote is added to a network with a smaller roll off factor, its iBuilder
status is set to Incomplete and the remote will not operate.
NOTE: Not all DVB-S2 downstream carriers support a 5% guard band. See DVB-S2
Guard Band Constraints on page153 for details.
Figure 23-1 illustrates the difference between a 20% and 5% roll of factor for a DVB-S2 carrier.
Figure 23-1. Spectral Mask Illustrating 20% and 5% Roll Off Factors

iDX Release 3.3
151
With a 5% roll-off factor (shown in blue in Figure 23-1), the transmitted spectrum more
closely resembles the ideal brick-wall spectrum with occupied bandwidth at 1.05 times the
carrier symbol rate. The spectral efficiency gain is approximately 14% for bandwidth-limited
link budgets. Note that for the same transmit power, the 5% roll-off factor has a Power
Spectral Density (PSD) differential of 0.58 dB when compared to a 20% roll-off factor.
Because of the improved roll-off factor for DVB-S2 carriers introduced in iDX Release 3.2,
iBuilder allows Network Operators to select one of four values for Carrier Spacing when
configuring a DVB-S2 downstream carrier:
1.20 (Guard band = 20% of carrier symbol rate)
Group Delay and Downstream Performance

DVB-S2 waveform performance is affected on remote platforms when operated under channel
conditions characterized by high transponder group delay. Such atypical channel conditions
are encountered in singe carrier per transponder applications with certain transponder model
types and to the extent symbol rate occupies the transponder bandwidth depending on
configured roll-off factor. When the symbol rate Fsym exceeds 75% of transponder bandwidth
(18/27/40.5 Msps for 24/36/54 MHz XPDRs), customers are encouraged to check the cascaded
IMUX and OMUX filter group delay of the transponder usually available from satellite operator.
These plots or specifications capture the peak-to-peak ripple (in nanoseconds) of the group
delay at different frequency offsets from the transponder center.
For group delay ripple that exceeds 0.5 symbol period across symbol rate bandwidth,
performance is severely degraded for the X3/X5 remote platforms to the point that the
channel becomes unusable. For example, a 34.285 Msps with 5% ROF DVB-S2 carrier on a 36
MHz transponder requires the cascaded group delay ripple to be less than 14.6 ns peak-topeak across the symbol rate bandwidth of 34.285 MHz.
0.5
--------------------------------- = 14.6
34.285 1e6
On X1/X7/e8x platforms, the demodulator handles the group delay levels better with robust
equalizers usually up to 1.5 symbol periods across symbol rate bandwidth with negligible SNR
degradation. Group delay exceeding 1.5 symbols periods (i.e. approximately 43.8 ns peak-topeak based on the 34.285 Msps with 5% ROF carrier example) will result in noticeable SNR
degradation and negatively affect link performance on these platforms. SNR degrades
significantly in excess of 3 dB as the group delay approaches 4 symbol periods and eventually
resulting in complete loss of channel performance.
Group delay exceeding limits identified above (0.5/Fsym over Fsym bandwidth for X3/X5
platforms or 1.5/Fsym over Fsym bandwidth for X1/X7/e8x platforms) usually requires Hub
side Tx Group delay equalizer (available COTS) to compensate for transponder effects or
symbol rate/roll-off factor reduction to keep away from group delay edges for satisfying
identified limits.
152

iDX Release 3.3
Improving Throughput by Reducing Guard Band
Improving Throughput by Reducing Guard Band

A lower bandwidth requirement between carriers makes it possible to fit a higher bit rate
carrier into the same occupied bandwidth or to fit additional carriers into the same overall
bandwidth. The example in this section shows how a lower guard band requirement can allow
a Network Operator to increase the information rate of a DVB-S2 carrier without changing the
occupied bandwidth and allotted power.
NOTE: Increasing the information rate of existing carriers may affect the link
budget of the satellite network. This is especially true for upstream carriers since
uplink power control will automatically increase the transmit power of the
remotes. Consult with the link budget provider prior to adjusting any carrier
configurations.
Table 23-1 illustrates the increase in information rate that can be achieved on a DVB-S2
downstream carrier by decreasing the guard band while holding the occupied bandwidth
constant. The calculations were performed using the 8PSK-8/9 MODCOD.
Table 23-1. Increasing Information Rate by Reducing Guard Band
Guard
Band
Occupied
Bandwidth (kHz)
Symbol Rate
(ksym/s)
Information Rate
(kbps)
20%
20000
16666.667
41729
15%
20000
17391.304
43543
10%
20000
18181.818
45522
05%
20000
19047.619
47690
In the example, reducing the guard band from 20% of the symbol rate to 5% of the symbol rate
results in a 14.29% increase in information rate.
DVB-S2 Guard Band Constraints

Not all DVB-S2 carriers support a 5% or 10% guard band. Specifically, DVB-S2 carriers below
10 Msps require a guard band of a least 10%. Also, guard bands of 10% or 5% require a
minimum MODCOD of QPSK-1/2.
When configuring the Carrier Spacing field in iBuilder, the following minimum limits are
enforced:
Table 23-2. DVB-S2 Guard Band Constraints
Carrier
Spacing
Guard Band
Minimum Symbol Rate

(ksym/s)
Minimum
MODCOD
1.20
20%
1000
QPSK-1/4
1.15
15%
1000
QPSK-1/4
1.10
10%
1000
QPSK-1/2
1.05
05%
10000
QPSK-1/2

iDX Release 3.3
153
Adjacent Channel Interference

The channel spacing between carriers is generally dictated by the roll off factors of the
carriers although the satellite operator may mandate spacing higher than that allowed by the
carrier roll off. The occupied bandwidth of the carrier, with symbol rate Fsym and roll-off
factor a, is given as (1 + a)*Fsym. Figure 23-2 shows three carriers spaced by their occupied
bandwidth constraints with the planned DVB-S2 carrier (Fwanted) in the center. The
difference in power spectral density between the wanted carrier and the adjacent carriers is
denoted as the Adjacent Channel Interference (ACI) level in dBc.
Figure 23-2. Adjacent Carrier Interference Example

For DVB-S2 roll off factors of 10, 15 and 20%, the BER degradation of the wanted carrier does
not exceed 0.25 dB from LBA guide across all supported MODCODs for ACI levels of +7 dBc
(each) on either side independent of the symbol rate, roll off and waveform modulation type
of the adjacent carriers. However, for 5% roll off factor, the robustness to ACI levels is
degraded slightly.
Based on carrier arrangements robustness to ACI levels for 5% roll off factor vary from +4 dBc
to +7 dBc on either side. The worst case typically occurs at the highest operating MODCOD
(i.e. 16APSK-8/9) under the following conditions:
The wanted carrier is less than 15 Msps and the adjacent carriers have an identical symbol
rates shaped with 5% roll off factor
With strong, narrow-band adjacent carriers that occupy 5% to 10% of symbol rate of the
wanted carrier on either side
In most cases, the DVB-S2 downstream carrier operates at the highest power spectral density
in the transponder, maximizing the contracted equal power equal bandwidth (EPEBW) limit.
This makes ACI levels exceeding +4 dBc unlikely. In addition, adjacent carriers shaped at 5%
(bullet 1) or narrow-band carriers stronger than the DVB-S2 downstream carrier (bullet 2) that
are likely to violate the EPEBW mask are unusual.
Network designers can realize the benefit of 5% roll off by planning around the identified
constraints.
154

iDX Release 3.3

iDX Release 3.3
155
156

iDX Release 3.3
24 Alternate Downstream
Carrier
This chapter provides information about iDirects Alternate Downstream Carrier feature. It
contains the following sections:
Background on page157
Feature Description on page157
Background
The Alternate Downstream Carrier feature is intended to make it easier to move an 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, the
network must move to a larger downstream carrier, the Alternate Downstream Carrier feature
can facilitate the transition. Before this feature was available, if the downstream carrier
changed, 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 the NMS server is licensed for the
Global NMS feature. However, the Global NMS feature can accomplish the same goal by
creating an alternate network containing the new downstream carrier and configuring
roaming remotes instances in both the existing network and the new network. Like the
Alternate Downstream Carrier feature, this allows the Network Operator to verify 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 the 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. Configure the alternate carrier for a network well in advance of the
carrier change to ensure that all remotes have the alternate carrier definition when the
downstream change is implemented.
If a remote is not in the network at the time of the carrier change it will attempt to acquire
the old primary carrier unsuccessfully when it first tries to rejoin the network. Since the old
primary carrier is no longer being transmitted, the remote will then attempt to acquire its
configured alternate downstream carrier which is the new primary carrier. At that point the
remote will acquire the network on the new carrier.

iDX Release 3.3
157
Feature Description
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. A carrier selected as the Alternate Downstream Carrier for one Tx line card
cannot also be assigned to another line card, either as the primary or alternate carrier.
The procedure for moving a network to an 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.
158

iDX Release 3.3
25 Transmit Key Line
This chapter describes the iDirect Transmit Key Line Feature. It includes the following
sections:
Introduction
Feature Description
Introduction
The iDirect Transmit Key Line feature is supported on iConnex e850mp and Evolution e150
remotes. The feature uses a pair of differential hardware lines to indicate when the remote is
transmitting on a burst-by-burst basis. iDirect anticipates that this signal will be used by
terminal providers to conserve power on the remote terminal by powering on the Solid State
Power Amplifier (SSPA) on the Block Upconverter (BUC) only when the remote is required to
transmit on the upstream carrier.
NOTE: This feature is only available for remote terminals equipped with an
iConnex e850mp or Evolution e150 satellite router board that has been properly
integrated with a BUC that supports the transmit key line signal.
Feature Description
Maintaining satellite communications is often a critical requirement of deployments in which
the only power source available to the remote terminal consists of batteries or small
generators with limited fuel. This makes power conservation crucial to the success of the
mission. Since the biggest power requirement of a satellite terminal comes from the BUC, the
Transmit Key Line feature is designed to allow the terminal to conserve power by turning off
the BUCs Power Amplifier (PA) when the remote is not transmitting. This significantly
increases the amount of time the terminal is on line.
The Transmit Key Line feature uses a differential RS 422-compatible signal provided to the
BUC through a connector on the remote modem. Details of this interface are defined in the
integration guide for each model type. For the iConnex e850mp, see the e800 Series Satellite
Router Integration Guide. For the Evolution e150, see the e150 Satellite Router Integration
Guide.
By default, the Transmit Key Line feature is disabled for e850mp and e150 remotes. A
Network Operator can enable the feature on individual remotes by selecting a check box on
the Remote VSAT Tab in iBuilder. When Transmit Key Line is enabled, the operator must also

iDX Release 3.3
159
Feature Description
enter a BUC PA warm up time between 0 and 1700 microseconds (s). This represents the
minimum amount of time prior to transmitting that the modem will enable the Transmit Key
Line signal. See the chapter titled Configuring Remotes in the iBuilder User Guide for a
step-by-step procedure to enable the Transmit Key Line feature on remote modems.
160

iDX Release 3.3
26 NMS Database
Replication
Beginning with iDX Release 3.1, iDirect supports replication of NMS databases from the
Primary NMS Server to one or more Backup NMS Servers. This chapter describes the NMS
Database Replication feature and explains how to configure and monitor the feature on NMS
server machines.
Benefits of NMS Database Replication

When the NMS Database Replication feature is enabled, changes to the NMS databases on the
Primary NMS are automatically replicated to the backup server(s) using MySQLs master/slave
replication tools. The Primary NMS acts as a MySQL master while each backup server acts as a
MySQL slave. This feature provides the following benefits:
Near real-time backup of the Primary NMS Server databases. Since changes to the
database are replicated on a per-transaction basis, the databases on the backup server
are typically updated whenever the master databases change. If changes occur to the
database on the Primary NMS while the backup databases are locked, replication quickly
catches up to bring the backup databases up-to-date once the databases are unlocked.
Eliminates impact of idsBackup on the Primary NMS Server. When NMS Database
Replication is enabled, the idsBackup script used to archive the databases is run on the
backup databases rather than on the databases on the Primary NMS Server. This permits
idsBackup to lock the Backup NMS databases, with no impact on the Primary NMS Server.
This eliminates lost updates to the primary NRD database and improves NMS performance
while idsBackup is running.
Provides an alternate read-only set of NMS databases to other applications. Providing

near real-time databases on a backup server allows external applications such as
SatManage and custom applications to access the backup databases, thus off-loading this
burden from the Primary NMS Server.
NOTE: Great care must be taken not to permit such applications to update the
databases residing on the backup server. Doing so will cause replication from the
Primary NMS to the Backup NMS to stop. This may only be noticed when the MySQL
master attempts to update the same table and row that was inappropriately
updated in the MySQL slave database.
Allows replication of key server configuration files. By using the -b option when setting
up replication, key NMS server files are automatically replicated to the backup server.
This eliminates the need to manually backup these files to provide server redundancy.

iDX Release 3.3
161
Feature Description
Feature Description
The NMS Database Replication feature provides MySQL database replication from a Primary
NMS Server to one or more Backup NMS Servers. Replication in MySQL provides support for
one-way, asynchronous replication, in which one server acts as the master, while one or more
other servers act as slaves.
Because replication is asynchronous, updates can be made to the master databases even
when the slave servers are not connected to the master server. When a slave re-connects to
the master, any database updates logged on the master while the slave was disconnected are
applied on the slave to re-synchronize the databases.
When NMS Database Replication is enabled, the MySQL master running on the Primary NMS
writes database updates as events to a binary log. Slaves are configured to read the binary
log on the master and to execute the events in the binary log on the slave's local database.
Because it is the responsibility of each slave to keep track of which transactions have been
executed on its local databases, individual slaves can be connected and disconnected from
the server without affecting the master's operation.
NMS Database Replication Architecture

Figure 26-1 shows the basic MySQL database replication architecture described above.
Figure 26-1. NMS Database Replication Architecture

The example in Figure 26-1 shows a single NMS server with one backup server and an external
server that reads the replicated database. However, the NMS Database Replication feature
can be set up in a number of different configurations. Note the following:
162
NMS databases can be replicated from a single MySQL master to a single MySQL slave (as
shown in Figure 26-1) or from a single MySQL master to multiple MySQL slaves.
It is not possible to replicate the NMS databases from multiple MySQL masters to a single
MySQL slave. Each MySQL slave can only receive replicated databases from a single
master.

iDX Release 3.3
Feature Description
It is not possible to select which individual NMS databases that reside on an NMS server to
replicate. When NMS Database Replication is enabled, all databases are replicated.
idsBackup can be configured to run on any, all or none of the MySQL slave servers.
idsBackup can be configured to archive the NMS databases to its own server (as shown in
Figure 26-1) or to a different backup server.
On a distributed NMS, NMS Database Replication can run on any, all, or none of the NMS
servers on which databases are stored.
On a distributed NMS, it is not possible to replicate the NMS databases from multiple NMS
servers on which the databases are stored to a single backup server. Each NMS server with
replication enabled must replicate its database(s) to a different backup machine.
Key configuration files can be replicated to the Backup NMS Server by enabling replication
with the -b option (see page 168). This allows the Backup NMS Server to be easily brought
on line as the Primary NMS Server if the primary server fails. However, when using this
option, the backup server cannot act independently in another role (such as a GKD server)
since the configuration on the backup server will be overwritten by the configuration
from the Primary NMS Server.
Replicating iDirect NMS Databases

An iDirect NMS maintains two MySQL databases:
The nms database contains the system configuration defined in iBuilder and written to
the database by the NMS cfgsrvr process.
The nrd_archive database contains:

Statistics written to the database by the NMS nrdsvr process
Events and conditions written to the database by the NMS evtsvr and latsvr processes
Figure 26-2 shows a sample implementation of the NMS Database Replication feature with one
Primary NMS Server and one Backup NMS Server.
Figure 26-2. NMS Database Replication from a Single Primary NMS Server

iDX Release 3.3
163
Feature Description
In the example in Figure 26-2, the databases on the Primary NMS Server are replicated to the
Backup NMS Server. idsBackup runs on the backup server and stores the archived databases to
the local machine.
When you enable NMS Database Replication on a Primary NMS Server, the Primary NMS
becomes the MySQL master and the server(s) that you specify become the MySQL slave(s).
Enabling replication automatically creates a copy of all of the NMS databases on each slave
server. From then on, the master writes all changes made to its local databases to the binary
log (see Figure 26-1 on page 162).
When you enable NMS Database Replication on a Primary NMS Server, idsBackup is
automatically disabled on the Primary NMS and enabled on the backup server(s). Although you
can run idsBackup on a Primary NMS Server with database replication enabled, doing so
negates one of the main advantages of enabling replication as discussed on page 161. (See the
technical note NMS Redundancy and Failover for details on configuring idsBackup.)
Each slave is responsible for reading the MySQL binary log and updating its own copy of the
database. In the case of one master and multiple slaves, at any given time, database updates
that have been replicated on one slave may not have been replicated on another slave.
Therefore, the master must ensure that all slaves have processed an update before deleting it
from the log.
It is possible for replication to stop working on a MySQL slave. For example, if a change is
made directly to a slave database, replication on that slave will stop when the master
database is determined to be different from the slave database. In the case that replication
stops on a slave, the slave will stop processing the updates in the binary log and send a
warning to the NMS. An active condition will appear in iMonitor stating that a replication error
has been detected on the MySQL slave server.
If a replication error is detected, it is important that the Network Operator take action to
recover from the failure. If no action is taken, the log files on the master can no longer be
purged and it is possible to run out of disk space on the Primary NMS Server. To recover from
the failure, the operator should delete and recreate the MySQL slave. This will re-copy the
MySQL master databases to the MySQL slave server and restart replication on the slave. (See
Force Recreation of an Existing MySQL Slave on page169 for details.)
NMS Database Replication on a Distributed NMS

As discussed on page 163, four NMS process write to the NMS databases. With respect to these
processes, a typical Distributed NMS (DNMS) is set up on three NMS server machines as
follows:
The NMS Configuration Server process (cfgsvr) runs on NMS Server 1.
The NMS Statistics Server process (nrdsvr) runs on NMS Server 2.
The NMS Event Server process (evtsvr) and NMS Latency Server process (latsvr) run on NMS
Server 3.
All NMS databases are created on each of these three server machines. However, each of
these processes updates only its local database. Therefore:
164
The nms database on NMS Server 1 contains the configuration data.
The nrd_archive database on NMS Server 2 contains the statistics.
The nrd_archive database on NMS Server 3 contains the conditions (events and warnings).

iDX Release 3.3
Feature Description
Figure 26-3 shows a distributed NMS with NMS Database Replication enabled on all three NMS
server machines.
Figure 26-3. NMS Database Replication on a Distributed NMS

Notice in Figure 26-3 that both the nms and nrd_archive databases are created on all three
Primary NMS Servers. Each database is created on each server even if no process that writes
to that database runs on that server. When replication is enabled on a Primary NMS Server,
each database on that server is copied onto the Backup NMS Server even if the database
contains no data.
As discussed on page 163, you cannot replicate the NMS databases from multiple NMS servers
on which the databases are stored to a single backup server. Each NMS server with replication
enabled must replicate its database(s) to a different backup machine. Therefore, to replicate
the databases on all three NMS server machines, three backup machines are required to act as
MySQL slaves.

iDX Release 3.3
165
Setting Up NMS Database Replication
However, there is no requirement to replicate the databases on all Primary NMS Servers. For
example, it is possible to configure a DNMS to replicate only the nrd_archive databases on
NMS Server 2 and NMS Server 3, and run idsBackup locally on NMS Server 1 to back up the nms
database nightly. This would eliminate the need for NMS Backup Server 1 in Figure 26-3.
NOTE: See the Technical Note NMS Redundancy and Failover for instructions on
bringing a Backup NMS Server on line if the Primary NMS Server fails.

This section describes how to set up NMS Database Replication on the NMS servers. Before
enabling replication, ensure that:
The Primary NMS Server and the Backup NMS Server(s) have the same iDirect release
installed
There is IP connectivity between the Primary NMS Server and the Backup NMS Server(s)
The cr8DbMaster script is run from the root account of the Primary NMS Server to configure
replication on the NMS server machines. The script can be used configure the Primary NMS
Server as a MySQL master and one or more Backup NMS Servers as MySQL slaves. To create the
MySQL slaves, cr8DbMaster calls the cr8DbSlave script on the backup machine.
Run cr8DbMaster to perform the following tasks:
Create a MySQL master and one MySQL slave
Create a MySQL master and more than one MySQL slave
Add a MySQL slave to an exiting MySQL master
Delete a MySQL slave
Force recreation of existing MySQL slave
The full syntax and explanation of the cr8DbMaster script can be viewed on any NMS server by
entering the command:
perldoc cr8DbMaster
The synopsis is repeated here:
cr8DbMaster [-h] [-v] [-d] [-f] [-b] [-t temp_dir] -u replUser -p replPassword slave_host...
166
-h
Help, display this usage statement and exit.
-v
Display cr8DbMaster script version and exit.
-d
Delete an existing database slave host.
-f
Force recreation of specified existing slave servers.
-b
Backup mode, also replicate key NMS files.
-t temp_dir
Create the temporary working in \temp_dir\. Default is

/var/idirect/backup\
-u replUser
Replication user name for slave replication user.
-p replPassword
Replication user password for slave replication user.

iDX Release 3.3
slave_host
The IP address of one or more iDirect NMS servers to be

configured as a MySQL slave server.
The cr8DbMaster script calls the cr8DbSlave script on each of the specified slave servers to
properly configure and start replication to the slave. Generally, the cr8DbSlave script is only
run manually on a MySQL slave server when the master has failed to turn the slave server into
the new Primary NMS. See Stop Replication on a Backup NMS Server on page169.
MySQL slave servers must run the same iDX release with the same version of the MySQL as the
MySQL master server. The cr8DbMaster script enforces this requirement when the slave is
initially configured. Upgrading to a new release on the MySQL master server but not upgrading
the MySQL slave servers can lead to unpredictable results. Therefore, when upgrading to a
new iDX release on the Primary NMS Server, be sure to also upgrade all backup servers.
Examples
This section provides examples showing how to configure NMS Database Replication on NMS
Servers. With the exception of the cr8dBSlave command used to stop replication on a
MySQL slaves local machine to prepare for a failover, all commands should be run from the
root account of the Primary NMS containing the databases to be replicated.
If not previously done, enable remote access from the Primary NMS Server to a backup server
by executing the pushSSHKeys command. This command only needs to be executed one
time.
To enable remote access to a backup server:
1. Log on to the root account of the Primary NMS Server
2. Enter the command:
pushSSHKeys <backup server IP Address>
where <backup server IP Address> is the IP address of the backup server.
Enable Replication to a Single Backup Server

The following example enables replication from this Primary NMS Server to a Backup NMS
Server with IP Address 192.168.77.16. The example configures this server as a MySQL master
and 192.168.77.16 as a MySQL slave. To enable database access on the backup server, it
creates the MySQL user user1 with password user1pwrd.
cr8DbMaster -u user1 -p user1pwrd 192.168.77.16

iDX Release 3.3
167
Figure 26-4 shows sample output from this command.
Figure 26-4. Enabling NMS Database Replication to a Backup Server

NOTE: When replication is enabled, idsBackup is automatically disabled on the
Primary NMS Server and enabled on the Backup NMS Server.
NOTE: Enabling replication restarts iDirect NMS services on the Primary NMS
Server.
Add Two Additional Backup NMS Servers as MySQL Slaves

The following example adds two additional MySQL slaves (on backup servers 192.168.77.21
and 192.168.77.30) to the MySQL slave created in the previous example. The databases from
this Primary NMS will be replicated to all three backup servers. A different MySQL user /
password (user2 / user2pwrd) is created on the two additional backup servers.
cr8DbMaster -u user2 -p user2pwrd 192.168.77.21 192.168.77.30
Enable Replication to a Redundant NMS Server

This example is identical to the first example except that it uses the -b option. In addition to
setting up database replication, this example also causes key configuration files to be
replicated to the backup server, facilitating failover to the Backup NMS Server in the event
that the Primary NMS Server fails.
cr8DbMaster -b -u user1 -p user1pwrd 192.168.77.16
NOTE: When the -b option is used, the backup server cannot act independently in
another role (such as a GKD server) since the configuration on the backup server is
periodically overwritten by the configuration on the primary server.
Stop Replication to a Backup NMS Server

This example stops NMS Database Replication to Backup NMS Server 192.168.77.16.
cr8DbMaster -d 192.168.77.16
168

iDX Release 3.3
Monitoring NMS Database Replication
NOTE: If 192.168.77.16 is the only MySQL slave associated with this MySQL
master, this command also disables replication on this Primary NMS Server and this
NMS Server is no longer configured as a MySQL master.
Force Recreation of an Existing MySQL Slave

This example re-copies the databases from the Primary NMS Server to an existing MySQL slave
and restarts replication to that backup server. The command is equivalent to stopping
replication using the -d option followed by re-enabling replication to the backup server.
NOTE: If a problem occurs that causes replication to a MySQL slave to stop
working, use this command to restart replication. (See Recovering from
Replication Failures on page171.)
cr8DbMaster -f -u user1 -p user1pwrd 192.168.77.16
Stop Replication on a Backup NMS Server

This command can be used to re-configure a Backup NMS Server to no longer act as a MySQL
slave if the Primary NMS Server is not available. For example, if the Primary NMS Server has
failed, this command properly stops replication in preparation for making the slave the new
Primary NMS.
NOTE: Generally, cr8DbSlave should only be called by the cr8DbMaster script
from the Primary NMS Server. It should only be executed manually on the MySQL
slave to stop replication if the Primary NMS Server is not available.
Execute the following command on the Backup NMS Server to stop the server from being a
MySQL slave:
cr8DbSlave -d

The cr8DBMaster script may, depending on options, create up to three root cron jobs:
mysql-binlog-purge runs periodically to clean up master replication logs that have been
successfully processed by all slaves. By default this cronjob is set to run at 12:00 AM, 6:00
AM, 12:00 PM and 6:00 PM when replication is configured using the cr8DbMaster script.
When the last slave is deleted, the cr8DbMaster script removes this cronjob.
mysql-repl-monitor monitors the status of each of the slaves to ensure that replication is
occurring properly. A warning is sent to the NMS and displayed in iMonitor if replication is
not functioning properly. By default this cronjob is set to run on the hour and every five
minutes when replication is configured using the cr8DbMaster script. When the last slave
is deleted, the cr8DbMaster script removes this cronjob.
NOTE: This script can also be used to send e-mail to the root user if
replication is not functioning properly. The sendmail aliases file (/etc/aliases)
may be used to forward this e-mail to any user. See man 5 aliases and man
1 newaliases for details on forwarding roots e-mail to another user.

iDX Release 3.3
169
repl-file-send copies key NMS configuration files to the slave server. This option is
intended to facilitate the use of the Backup NMS Server as the primary in case the Primary
NMS Server fails. This cronjob is only setup if the -b option is specified when running
cr8DbMaster. By default this cronjob is set to run at two minutes after the hour and every
five minutes thereafter when replication is configured using the cr8DbMaster script. When
the last slave is deleted, the cr8DbMaster script removes this cronjob.
NOTE: These default settings can be changed by your Linux Systems Administrator
by editing the crontab file on the MySQL master server after replication is
enabled.
Events And Warnings

All of the scripts that make up the iDirect replication tool set: cr8DbMaster, cr8DBSlave,
mysql-binlog-purge, mysql-repl-monitor and repl-file-send send events and warnings to the
NMS Event Server. On successful completion of any task each of these scripts sends an event
listing the task and the fact that it was completed successfully. On any task failure each of
these scripts sends a warning listing the task and a brief description of the failure.
Viewing Replication Conditions in iMonitor

Events and warnings generated by the replication scripts are sent to the NMS and may be
displayed as conditions in iMonitor. View these conditions in iMonitor as follows:
1. Select Conditions from the iMonitor View menu to open the Conditions pane.
2. Click the Conditions Log tab.
Figure 26-5 shows examples of a number of replication conditions as viewed in iMonitor.
iMonitor will display similar conditions whenever something significant occurs with respect to
replication. For example:
170
When replication is initially set up on the Primary NMS
When new MySQL slaves are added or removed
When the MySQL binary log files are purged
When a replication error is detected

iDX Release 3.3
When a previously-detected replication error is cleared
Figure 26-5. Replication Conditions Viewed in iMonitor

NOTE: The repl-file-send condition is only generated when redundancy is set up
using the -b option. See Enable Replication to a Redundant NMS Server on
page168.
NOTE: When the cr8DbMaster script is executed on the Primary NMS Server, the
NMS processes are automatically restarted. Operators logged on to iMonitor when
this script is executed should select Log On from the File menu and log on again or
they may not see new Conditions.
Recovering from Replication Failures

Most of the conditions shown in Figure 26-5 are informational. However, if a replication error
occurs it may result in an Active Condition. To view Active Conditions, click the Active
Conditions tab as shown in Figure 26-6.
Figure 26-6. Replication Error Resulting in Active Condition in iMonitor

iDX Release 3.3
171
NOTE: Since replication (and therefore the Active Condition shown in Figure 26-6)
is not associated with any elements in the iMonitor tree view, no associated
alarms or warnings appear in the tree. NMS operators should check the Active
Conditions regularly to ensure that there are no active replication errors.
If iMonitor displays a persistent Active Condition indicating a replication error, first ensure
that the Primary NMS Server has IP connectivity to the MySQL slave server. If not, re-establish
the IP connection from the MySQL master server to the MySQL slave server and monitor the
Active Condition in iMonitor to see if it clears.
If the error condition does not clear and the Primary NMS Server can communicate with the
Backup NMS Server, force the Primary NMS Server to re-copy the database(s) to the Backup
NMS Server and restart replication as follows:
1. Log on to the root account of the Primary NMS Server acting as MySQL master.
2. Enter the command:
cr8DbMaster -f -u <User> -p <Password> <Slave IP Address>
where:
<User> is the MySQL User configured when enabling replication
<Password> is the MySQL User password
<Slave IP Address> is the IP Address of the MySQL slave server
3. Check the Active Conditions in iMonitor to make sure the condition clears.
NOTE: Alternatively, accomplish the same goal by running cr8DbMaster twice to
delete and re-create the MySQL slave.
NOTE: Operators logged on to iMonitor when the cr8DbMaster script executes
should log off and on again before checking to see if the Active Condition has
cleared.
172

iDX Release 3.3
27 Feature and Chassis

Licensing
Licenses are required for chassis slots and certain iDirect features before they can be enabled
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 iDirect networks. A Network Operator cannot
configure slots in a 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 X1 AES Link Encryption
Evolution X5 Upstream Spread Spectrum
Evolution X7 Upstream Spread Spectrum
Evolution e8350/e800/e850mp High-Speed COTM
Evolution XLC-11 Upstream Spread Spectrum
Evolution eM1D1 TRANSEC
Evolution eM0DM TRANSEC
Evolution eM0DM/XLC-M TDMA multichannel support
Evolution XLC-M TDMA Narrowband multichannel support
Evolution eM0DM/XLC-M SCPC return multichannel support

iDX Release 3.3
173
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 the NMS server.
NMS Server Feature Licenses include:
Global NMS
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 the 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
COTM Settings and Custom Keys in the iBuilder User Guide.
For information on importing Chassis Slot Licenses and Hardware-Specific Feature Licenses
into iBuilder and for validating Hub Slot Group Licenses in iBuilder, see the iBuilder User
Guide.
174

iDX Release 3.3
28 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 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 a Tx line card fails, or there is only one Rx line card and it fails, all
remotes must re-acquire 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 it is possible to 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 the Tx line card and as a cold standby for the Rx line cards. In a multiinroute, frequency hopping network, the most critical line card is the Tx (or Tx/Rx) line card.
If this card fails, all remotes drop out of the network. When an Rx-only card fails in a
frequency-hopping Inroute Group, all remotes automatically begin sharing the other inroutes.
While this may result in diminished bandwidth, remotes do not drop out of the network.
Ensuring that there is a warm standby configured for a Tx line card guarantees the fastest
failover possible for the most critical line cards. In that case, the warm standby line card is

iDX Release 3.3
175
Failover Sequence of Events
pre-configured with the parameters of the Tx card for that network, and has those
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 28-1. 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.
176

iDX Release 3.3
Figure 28-1. Line Card Failover Sequence of Events

iDX Release 3.3
177
178

iDX Release 3.3
29 NMS, PP and GKD Server

Port Assignments
This chapter defines the IP port numbers that are used by the various processes that run on
the NMS servers, Protocol Processor servers, and GKD servers. This information is provided to
assist iDirect Network Operators, iDirect network architects, and any other personnel
responsible for configuring and maintaining iDirect networks or for integrating iDirect
networks with other systems.
This chapter contains the following sections:
NMS Server Ports on page179 defines the port numbers for all ports used by the NMS
server processes that run on NMS server machines.
GKD Server Ports on page181 defines the port numbers used by the GKD servers to
manage TRANSEC keys. A GKD server can run on an NMS, protocol processor blade, or
standalone machine.
PP Controller Ports on page181 defines the port numbers used by the PP controller
process that runs on the NMS server machine.
Protocol Processor Ports on page181 defines the port numbers used by the processes that
run on the protocol processor blade machine.
Port Assignments for NMS/Upstream Router Traffic Flow on page182 defines the port
numbers and respective protocols for traffic flow between the NMS servers and the
upstream router.
NMS Server Ports

Table 29-1 defines the NMS port numbers used by each NMS server process.
Table 29-1. NMS Server Ports

iDX Release 3.3
NMS Server
Port Type
Port Number
config Server
ConfigServer
1493
MnCServer
1492
ProxyServer
14599
ConfigConsole
14123
UDPPush
14599
179
NMS Server Ports
Table 29-1. NMS Server Ports (continued)

NMS Server
Port Type
Port Number
nrd Server
NRD Server
2858
NRDListner
2859
NRDServiceMon
9001
NRDConsole
13257
EVTServer
2861
EVTListner
2860
EVTConsole
13259
REVServer
2865
REVListener
2866
REVConsole
13265
DMONServer
2867
DMONListener
2868
DMONConsole
13266
snmp Server
SNMPConsole
13263
control Server
ControlServer
1393
ControlConsole
13123
DMONConsole
13266
LATServer
2863
LATConsole
13261
map Server
MapServer
5003
oss Server
OSSServer
1593
OSSListener
1594
OSSConsole
15123
SKYServer
2869
SkyConsole
2870
CMServer
15261
CMConsole
15262
evt Server
rev Server
dmon Server
latency Server
sky Server
chassis manager Server
180

iDX Release 3.3
PP Controller Ports
PP Controller Ports
Table 29-2 defines the port numbers used by the pp_contoller process that executes on the
NMS server machine. These are internal port numbers used for communication between the
PP Controller and the PP blades. For each Port Type, the pp_controller uses the base port
number + index number to derive the port numbers on the NMS server machine. Each index is
specified by the corresponding protocol processor ID in the NMS configuration database.
Table 29-2. pp_controller Ports
Port Type
Port Number
Listen
3001[pp database ID]

5495
Console
15000[pp database ID]
GKD Server Ports

Table 29-3 defines port numbers used by the GKD server process to manage TRANSEC
acquisition keys. A GKD server can execute on its own machine; on an NMS server machine; or
on a Protocol Processor server machine.
Table 29-3. GKD Server Ports
Port Type
Port Number
GkdServer
45001
GkdCertificate
45010
GkdConsole
46002
Protocol Processor Ports

Table 29-4 and Table 29-5 define port numbers used by the protocol processor processes on
the Protocol Processor blade machines. Table 29-4 defines the ports used by the samnc
process.
Table 29-4. samnc Ports

iDX Release 3.3
Port Type
Port Number
MnC
1494
CA Handler
2494
Key Controller
8700, 8701 via udp
MultiCastPackageDownload
9000
Console
13255
181
Port Assignments for NMS/Upstream Router Traffic Flow
Table 29-5 defines the port ranges reserved for the remaining protocol processor processes,
such as sada, sarmt, sarouter, and sana. The number of ports used depends on the number of
networks assigned to each protocol processor and the number of processes running on each
blade.
Table 29-5. Protocol Processor Port Ranges
Port Type
Port Number Ranges
Inter-Process Communication
3000 and up
Tunnel between PP and HLC
8000 (8001 in 7.0)
Console
13456 and up, and is assigned a different port by the SAMNC process
Port Assignments for NMS/Upstream Router Traffic Flow

Table 29-6 defines the designated port numbers and the respective protocol for traffic flow to
and from NMS servers through the upstream router.
Table 29-6. Port Designations for NMS/Upstream Router Traffic
182
Source Host
Protocol/Port
Destination Host
Description
nmssvr eth0
TCP 2494
hlc eth0
configuration and control to hub line

cards and remote modems
nmssvr eth0
UDP 9090
pp eth1
unicast proxy multicast download

to remotes
nmssvr eth0
UDP 9000
multicast
multicast download to PP blades, hub

line cards, and remote modems
pp_controller eth0
TCP 2494
pp eth1
configuration and control to PP

blades
pp eth1
UDP 8000 + pp_id
pp_controller eth0
blade heartbeat
pp eth1
UDP 8500 + pp_id
pp_controller eth0
blade status
pp eth1
UDP 2859
nrdsvr eth0
network statistics
pp eth1, hlc eth0
UDP 2860
evtsvr eth0
network events

iDX Release 3.3
30 VRRP and Remote LAN

Port Monitoring
This chapter describes the iDirect Virtual Router Redundancy Protocol (VRRP) and Remote LAN
Port Monitoring features.
This chapter contains the following sections:
Virtual Router Redundancy Protocol (VRRP) on page183 describes the VRRP feature and
how to configure it in iDirect networks.
Remote LAN Port Monitoring on page191 describes the Remote LAN Port Monitoring
feature and how to configure it in iDirect networks.
Monitoring VRRP Status and Remote LAN Status on page193 describes how to monitor
VRRP and remote LAN port status in iDirect networks.
Virtual Router Redundancy Protocol (VRRP)

iDirect supports Virtual Router Redundancy Protocol (VRRP) version 2 for IPv4 as specified by
RFC 3768. Authentication as specified in the RFC is not supported. The iDirect
implementation also supports VRRP Accept Mode as defined in RFC 5798.
VRRP Overview
VRRP is an IP protocol that allows two or more physical routers on a subnetwork to be grouped
into a single Virtual Router. At any time, only one router in the VRRP group (called the
Master router) is responsible for routing IP traffic. The remaining routers, called Backup
routers, do not forward IP traffic.
VRRP provides router redundancy by dynamically electing a Backup router to serve as the
Master router in the case that the Master router fails. This increases the availability of the
default gateway for hosts on an IP subnetwork and therefore improves the reliability of
routing paths.
Each physical router in a VRRP group has a priority between 1 and 255. (The priority 0 is
reserved to allow the Master router to release responsibility for the Virtual Router.) The
routers use VRRP to elect the router with the highest priority as the Master router for the
group. If two or more routers have the same priority and that priority is the highest, then of
those routers, the one with the highest IP address is considered the highest-priority router.
In VRRP, a virtual IP address is assigned to the Virtual Router. One Virtual Router can be
defined per VLAN. If the VRRP virtual IP address is the same as the IP address of the VLAN of
one of the routers in the VRRP group, then the router with the IP address that is the same as

iDX Release 3.3
183
the virtual IP address is automatically given a priority of 255. Therefore, the router that
owns the Virtual IP address of the Virtual Router is the default VRRP Master for that VRRP
group.
The routers in a VRRP group communicate using a predefined multicast address. The Master
router sends periodic VRRP Advertisement messages every Advertisement Interval. The
Advertisement Interval defaults to one second but can be configured. If the Backup routers do
not receive any Advertisements from the Master for three Advertisement Intervals, then the
Backup routers elect a new Master.
Unless an election is in progress, Backup routers do not typically send VRRP messages.
However, if a Backup router is configured with a higher priority than the current Master and
preemption is enabled on the Backup router, then the Backup router uses the VRRP protocol
to preempt the Master.
The priorities of the routers in a VRRP group may change dynamically. Therefore, the current
priority of a router is not always identical to the configured priority. For example, if the
virtual IP address assigned to the Virtual Router is identical to the IP address of the routers
LAN interface, then the actual priority of that router is set to 255 rather than to the
configured value. In addition, if Route Tracking is enabled for a destination address and that
address becomes unreachable, the priority of the Master router is reduced by a pre-defined
value. (Route Tracking is a VRRP extension discussed in VRRP Route Tracking on page188.)
Any user-defined VLAN interface configured on an Evolution X5 or Evolution X7 remote can be
included in a VRRP group. Please note the following conditions:
Any VLAN can be included in only one VRRP group.
The default VLAN (VLAN 1) cannot be included in a VRRP group.
iDirect supports a maximum of seven VRRP groups per remote on separate VLANs.
Since iDirect does not support multiple remotes on a single subnet, two iDirect remotes
cannot be included in the same VRRP group.
NOTE: If the LAN cable is disconnected from an Evolution X7 remote and LAN Port
Monitoring is not enabled, the remote enters the Master state. If this occurs
without LAN Port Monitoring enabled, the X7 could incorrectly remain in the
Master state.
184

iDX Release 3.3
Figure 30-1 shows an example of a Virtual Router consisting of an iDirect remote and a router.
Per VLAN
VRID: 1
Virtual IP: 10.15.1.1
Virtual MAC:
00-00-5E-00-01-{VRID}
iDirect
Hub
IP Network
10.15.1.5
Remote
Backup
Priority 100
Host 1
Default gateway: 10.15.1.1
10.15.1.1
Host 2
Router
Master
Priority 255
Figure 30-1. Example of a Virtual Router

In Figure 30-1, an iDirect remote teams with a router (e.g. a Cisco router) to form a VRRP
group on the remote LAN. There is a terrestrial path (via the router) and a satellite path (via
the remote modem) to the remote site. In the figure, the Virtual Router has been assigned a
Virtual IP address of 10.15.1.1. The hosts in the remote routing domain are configured to use
10.15.1.1 as their default gateway.
Since the Virtual IP address of the Virtual Router is identical to the terrestrial routers IP
address, that router automatically becomes the default Master with a priority of 255. Because
the remote has a lower VRRP priority (100 by default), it acts as the Backup router in this
VRRP group as long as the Master router is available. As a Backup router, the remote does not
process IP traffic. Therefore, when both the terrestrial router and the remote are available,
IP traffic is routed over the terrestrial link.
NOTE: The Virtual MAC address shown in Figure 30-1 is automatically set to the
MAC address defined by the VRRP specification. VRRP uses the Virtual Router ID as
the final eight bits of a pre-determined Virtual MAC address. Identical Virtual
Router IDs result in identical Virtual MAC addresses. Do not use identical Virtual
Router IDs in situations that may cause addressing conflicts.
As long as the terrestrial router is on line it acts as the Master router, periodically sending
VRRP Advertisements to the VRRP multicast address. In its role as Backup router, the remote
listens to the VRRP multicast address and therefore receives the VRRP Advertisements sent by
the Master router. If the terrestrial router fails and the remote stops receiving VRRP
Advertisements, the remote elects itself as Master (since there are no other routers in the
VRRP group) and begins processing IP traffic on the remote LAN for transmission over the
satellite link. The remote also informs the protocol processor that it is available to route IP
traffic so that protocol processor can update its routing tables to enable the satellite path to
the remote.

iDX Release 3.3
185
When the terrestrial router comes back on line, it preempts the remote, taking back the role
of Master. The remote returns to the Backup role, stops routing IP traffic, and informs the
protocol processor so that the satellite path can be removed from hub routing tables.
Note that if an iDirect remote is acting as the Master router for a VRRP group and the satellite
link is lost, the remote stops sending VRRP Advertisements. Therefore, a Backup router will
be elected as Master if one is available. When the satellite link is restored, the remote
resumes its role as Master router for the group, provided it has the highest VRRP priority and
preemption is enabled on the remote.
Configuring VRRP on iDirect Remotes

All configuration of VRRP in iDirect is accomplished by entering hub-side custom keys on the
Remote Custom tab in iBuilder. This feature is only available for Evolution X5 and X7 remotes.
Any user-defined VLAN can be a member of a single VRRP group. (The default VLAN cannot be
part of a VRRP group.) Each remote can have as many as seven VLANs assigned to separate
VRRP groups. The same VRRP group cannot include multiple remote VLANs on the same
remote.
Before configuring a remote VLAN to be part of a VRRP group, you must have already
configured the corresponding VLAN in iBuilder on both the Protocol Processor VLAN tab and on
the Remote IP Config tab. For details on configuring VLANs, see the iBuilder User Guide.
NOTE: Ensure that RIPv2 is enabled in the Protocol Processor VLAN configuration.
To add a remote VLAN interface to a VRRP group in iBuilder:
1. Right-click the remote in the iBuilder tree and select ModifyItem.
2. When the Remote dialog box appears, click the Custom tab.
3. Under Hub-side Configuration, enter the following group and custom keys:
[RMT_VRRP_<VLAN ID>]
vrrp_enabled = 1
vrrp_addr = <Virtual IP Address>
vrrp_id = <Virtual Router ID>
where: <VLAN ID> is the VLAN ID of the VLAN that is a member of this VRRP group.
<Virtual IP Address> is the Virtual IP address of this VLANs Virtual Router.
<Virtual Router ID> is the Virtual Router Identifier of this VLANs Virtual
Router. This value can range from 1 to 255. vrrp_id must be set to a unique
value for each VLAN that uses VRRP on this remote.
Optionally, add the following custom keys to the [RMT_VRRP_<VLAN ID>] group:
vrrp_priority = <Configured Priority>
vrrp_adver_interval = <Advertisement Interval>
vrrp_premption_enabled = <Preemption Flag>
vrrp_accept_enabled = <Accept Mode Flag>
186

iDX Release 3.3
These optional parameters are defined as follows:

vrrp_priority is the configured priority of the remote in the VRRP group. If this
custom key is not included, vrrp_priority defaults to 100 unless this VLAN owns
the virtual IP address, in which case the priority is automatically set to 255.
NOTE: The remotes actual priority may differ from the configured priority if
Route Tracking is enabled. See VRRP Route Tracking on page188 for details.
vrrp_adver_interval is the Advertisement Interval in milliseconds at which this

remote sends Advertisements (if Master) or expects to receive Advertisements (if
Backup). If this custom key is not included, vrrp_adver_interval defaults to 1000
ms (1 second).
vrrp_premption_enabled determines whether or not this remote, when acting as
Backup router, can preempt the Master router if the Master router has a lower
priority. By default, vrrp_premption_enabled is set to 1 (enabled.) Set this value
to 0 to disable preemption by this remote.
NOTE: If the virtual IP address is set to this VLANs ETH0 Interface IP
address, then this remote will always preempt a lower-priority Master even if
vrrp_premption_enabled is disabled.
vrrp_accept_enabled determines whether or not this remote, when acting as

Master router, accepts packets addressed to the virtual IP address as its own if it is
not the IP address owner. By default, vrrp_accept_enabled is set to 0 (disabled).
Set this value to 1 to enable Accept Mode for this remote on this VLAN.
4. After entering all the VRRP custom keys, click OK to save the remote configuration.
5. Right-click the remote in the iBuilder tree.
6. Select Apply ConfigurationReliableHub-Side (TCP) to apply the configuration.
Figure 30-2 shows an example of a remote configured for VRRP.
Figure 30-2. Example VRRP Configuration in iBuilder

iDX Release 3.3
187
In Figure 30-2, three VLANs are configured in different VRRP groups. Note that:
For VLAN 2 and VLAN 4, the configured VRRP priorities are set to 113 and 200,
respectively. Since no VRRP priority is configured for VLAN 3, the remotes configured
priority on that VLAN is 100. (However, in all cases if the remotes ETH0 Interface IP
address for a VLAN is the same as the Virtual Router IP address, then the configured VRRP
priority is ignored and the priority is automatically set to 255).
For VLAN 2 and VLAN 4, the Advertising Interval is set to 2 seconds (2000 ms) and 3
seconds (3000 ms), respectively. Since no Advertising Interval is set for VLAN 3, the
remotes Advertising Interval on that VLAN is one second by default.
For VLAN 4, the default Preempt Mode setting of 1 (True) has been changed to 0 (False).
Therefore, even with a higher priority, the remote when acting as Backup router does not
preempt an existing Master router. (However, the remote will preempt if the remotes
ETH0 Interface IP address for VLAN 4 is set to the Virtual Router IP address of
160.100.4.1.)
For VLAN 4, the default Accept Mode setting 0 (False) has been changed to 1(True).
Therefore, in the Master state, the remote accepts packets addressed to 160.100.4.1
even if that is not the ETH0 Interface IP address for VLAN 4 configured on the remote.
When configuring another router for the same VRRP group, such as the terrestrial router in
Figure 30-1 on p. 185, ensure that the following settings are identical to those configured for
the remote VLAN:
VLAN ID
Virtual Router Identifier
Virtual Router IP address
Advertisement Interval
VRRP Route Tracking

The VRRP Route Tracking feature enables the protocol processor to track the availability of
selected upstream routes on behalf of remotes configured to use VRRP. If a tracked route
becomes unavailable, the protocol processor instructs the remote to reduce its VRRP priority
by a pre-configured value. If the route becomes available again, the amount by which the
priority was reduced is added back to the VRRP priority.
For each VLAN, the remote configuration specifies the set of routes to be tracked and the
value to be deducted from the VRRP priority if the route is unreachable. The protocol
processor is capable of tracking a maximum of 2000 routes.
Whenever the availability of any tracked route changes, the protocol processor sends a
message to each remote that is tracking that route. The message specifies the deduction
which the remote should subtract from its configured VRRP priority to determine its current
VRRP priority. The deduction is computed as the maximum of the configured priority
deductions for all the unreachable routes tracked by that remote.
You can configure Route Tracking by entering hub-side custom keys on the Remote Custom tab
in iBuilder. Configure the remote to use VRRP before setting up route tracking. (See
Configuring VRRP on iDirect Remotes on page186 for details.)
To add route tracking on a remote configured for VRRP, first define an OBJTRACK group for
each upstream route to be tracked. This custom key group is defined as follows:
188

iDX Release 3.3
[OBJTRACK_<ROUTE_ID>]
priority_deduct = <Priority Deduction>
obj_type = 1
dest_addr = <IP Address>
subnet_mask = <Subnet Mask>
where: <ROUTE_ID> is any integer used to identify this route.
<Priority Deduction> is the amount between 1 and 254 to deduct from the
VRRP priority if this route is unreachable.
obj_type is always set to 1.
<IP Address> is the IP address of this route.
<subnet_mask> is the subnet mask of this route.
For each VLAN for which you want to track routes, add the list of routes to the appropriate
ETH0 group as follows:
[ETH0_<VLAN ID>]
vrrp_enabled = <Route Tracking Enabled Flag>
vrrp_objtrack_ids = <Route List>
where: <VLAN ID> is the VLAN ID for which you want to track the routes.
<Route Tracking Enabled Flag> is 0 (disable route tracking) or 1 (enable
route tracking).
The vrrp_enabled custom key in this group only enables or disables route
tracking on this VLAN. It does not affect the VRRP configuration.
<Route List> is a comma-separated list of route IDs for which to track this
route.
The following remote hub-side custom keys configure route tracking on VLAN 2 for two
upstream routes. The protocol processor instructs the remote to reduce its VRRP priority on
VLAN 2 by 50 if route 1 is unavailable and by 40 if route 2 is unavailable. If both routes are
unavailable, the VRRP priority for VLAN 2 is reduced by 50 (the maximum value of all
configured deductions).
[ETH0_02]
vrrp_enabled=1
vrrp_objtrack_ids=1,2
[OBJTRACK_1]
priority_deduct=50
obj_type=1
dest_addr=10.160.0.0
subnet_mask=255.224.0.0
[OBJTRACK_2]
priority_deduct=40
obj_type=1
dest_addr=10.192.0.0
subnet_mask=255.224.0.0
Whenever the availability of a tracked route changes, the protocol processor sends a Router
Priority message to each remote that is tracking that route. This message contains the
maximum priority deductions for each of the remotes VRRP groups configured to track

iDX Release 3.3
189
routes. If the availability of tracked routes does not change, the protocol processor sends this
message periodically to the remotes to ensure that the remotes have the correct priority
deductions.
By default, the protocol processor sends the Router Priority message every two minutes to
each remote with routes to track. If a remote does not receive this message for five minutes,
the remote restores any decremented VRRP priorities to their configured values. Both the
time between messages and the timeout that the remote waits to receive the message can be
changed using custom keys.
To change the frequency with which the protocol processor sends the Router Priority message
to the remotes, add the following custom key on the Custom tab of the protocol processor in
iBuilder:
[STACK_MGR]
route_tracking_period_sec = <Message Interval>
where Message Interval is the frequency (in seconds) with which the protocol
processor sends the Router Priority message to all remotes.
The protocol processor custom key in Figure 30-3 changes the frequency with which the
protocol processor sends the Router Priority messages to the remotes to one minute.
Figure 30-3. Changing the Frequency of Router Priority Messages

To change the length of time a remote waits to receive a Router Priority message before
restoring any reduced VRRP priorities to their configured priorities, add the following hubside custom key on the Custom tab of the Remote in iBuilder:
[RMT_ROUTE_TRACKING]
msg_timeout = <Timeout>
where Timeout is the interval the remote waits (in tenths of seconds) to receive its next
Router Priority message before restoring all VRRP priorities to their configured values.
NOTE: If all tracked routes are deleted from the Remote Custom tab and
priorities have been reduced on the remote due to route tracking, the
remote will not restore the configured priorities until this timeout expires.
190

iDX Release 3.3
Remote LAN Port Monitoring
The remote hub-side custom key in Figure 30-4 changes the timeout that the remote waits for
the next Router Priority message before restoring the configured priorities. In the figure, the
timeout is set to three minutes.
Figure 30-4. Changing a Remotes Router Priority Message Timeout

An Evolution X5 or Evolution X7 remote can be configured to report the LAN connection status
per VLAN to the protocol processor. This information allows the protocol processor to update
its routing tables based on the availability of remote hosts. If the protocol processor detects
loss of connectivity to a remotes LAN, the protocol processor stops advertising routes to
destinations on each of that remote's affected VLANs. When connectivity to the remotes LAN
is restored, the protocol processor returns to advertising those routes.
When the LAN Port Monitoring feature is enabled, the remote reports the LAN status to the
protocol processor whenever the status has changed. The remote also reports the LAN status
periodically (once per minute) to ensure that the protocol processor information is up-todate.
When the protocol processor receives the LAN status for a remote, for each VLAN, if the LAN
status is down, the protocol processor removes from the RIP forwarding table the implied LAN
routes and any static routes explicitly configured for the remote. If the LAN status is up, the
protocol processor adds those routes to the RIP forwarding table.
Remote LAN Monitoring is independent of VRRP: you can enable either or both of these
features on the same remote. If VRRP and Remote LAN Monitoring are both enabled for the
remote, the entries in the routing table also depend on the VRRP status of the remote: Master
router or Backup router. If the remote is a VRRP Backup router then, even if the LAN is up, the
routes will not be added to the protocol processors routing table. Table 30-1 shows the
operations on the routing tables based on the LAN status and VRRP status when VRRP and/or
LAN Port Monitoring are enabled for a VLAN on a remote.

iDX Release 3.3
191
Table 30-1. PP Routing Table Operations: LAN Port Monitoring and VRRP
LAN Status
VRRP Status
Operation in RIP Forwarding Table
Up
Feature not enabled
Add routes
Down
Feature not enabled
Remove routes
Up
Master
Add routes
Down
Master
Remove routes
Up
Backup
Remove routes
Down
Backup
Remove routes
Feature not enabled
Master
Add routes
Feature not enabled
Backup
Remove routes
To add LAN Port Monitoring on a remote VLAN, configure the following hub-side custom key
group on the Remote Custom tab in iBuilder:
[RMT_LAN_PORT_MONITOR_<N>]
vid = <VLAN_ID>
port_mask = <Port Mask>
where: <N> is an integer from 0 to 7 unique to this custom key group for this VLAN.
<VLAN_ID> is the VLAN for which LAN port monitoring is enabled.
<Port Mask> is a bit mask indicating the remote LAN ports to which this VLAN is
assigned.
Since Evolution X5 remotes have a single LAN port, port_mask should always be set to 1 for
an X5 remote.
Evolution X7 remotes have eight LAN ports. For an X7, configure the port_mask such that all
bits representing ports to be monitored for this vid are set to one. Port 1 is the least
significant bit and port 8 is the most significant bit in the eight-bit port mask.
The example in Figure 30-5 enables LAN port monitoring for VLAN 2 on ports 7 and 8 for an
Evolution X7 remote by configuring a hub-side custom key group on the Remote Custom tab.
Notice that port_mask is set to 128 + 64 = 192 (C016, 110000002) to enable ports 8 and 7,
respectively
Figure 30-5. Example of LAN Port Monitoring Configuration for Multiple Ports in iBuilder
192

iDX Release 3.3
Monitoring VRRP Status and Remote LAN Status
The example in Figure 30-6 enables LAN port monitoring for VLAN 3 and VLAN 17 on port 1 by
configuring two hub-side custom key groups on the Remote Custom tab.
Figure 30-6. Example LAN Port Monitoring Configuration for Single Port in iBuilder
You can enable LAN Port Monitoring for up to eight VLANs per remote using groups
RMT_LAN_PORT_MONITOR_0 through RMT_LAN_PORT_MONITOR_7.

Remotes send events to the NMS to indicate changes to VRRP status or LAN Port Status when
these features are enabled.
To view these events in iMonitor:
1. Right-click a Network, Inroute Group or Remote in the iMonitor tree and select Events.
2. In the Select dialog box, select the check boxes of the remotes that you want to monitor.
3. Click OK to view the Remote Events.
Figure 30-7. VRRP and Remote LAN Status Events in iMonitor

Figure 30-7 shows both LAN Status events and VRRP Status events as viewed in iMonitor. LAN
status events are displayed whenever the LAN status changes for a VLAN enabled for Remote
LAN Monitoring. VRRP Status events are displayed when either the VRRP role (Master or
Backup) or the VRRP priority changes for a VLAN enabled for VRRP.
In iMonitor, the remote always reports a VRRP status of either Master or
Backup even if the remote is unable to join the VRRP group. In that case, the
remote sets the current priority to 0.
See the iMonitor User Guide for more information on viewing Events.

iDX Release 3.3
193
Remote Console Commands

If you create a console connection to the Admin account of a remote, you can view the VRRP
status and Remote LAN status by entering console commands.
The vrrp status console command displays the VRRP State and current Priority for all
remote VLANs enabled for VRRP. Sample output of the vrrp status command is shown
here:
vrrp status
VLAN
2
7
RtrID Address
2
112.100.2.3
7
168.10.10.4
State
Master
Backup
Running Priority
255
200
If the State is Initializing, the remote is unable to join the VRRP group.
The vrrp <vrrp_id> params console command displays the current VRRP parameters for
the Virtual Router ID specified in the command. Sample output of the vrrp params
command for Virtual Router ID 2 is shown here:
vrrp 2 params
vrrp_enabled = 7
vrrp_state = Backup
vrrp_mac_addr = 00005E-000102
vrrp_ip_addr = 168.10.10.4
vrrp_configured_priority = 190
vrrp_priority_configuration_override = 190
vrrp_route_tracking_priority_decrement = 0
vrrp_running_priority = 190
vlan_id = 2
vrrp_adver_interval_ms = 1000
vrrp_master_down_interval_ms = 3257
vrrp_premption_enabled = 1
vrrp_accept_enabled = 0
The lan_port_monitor status console command displays the LAN Port Monitoring status
for all remote VLANs enabled for LAN Port Monitoring. Sample output of the
lan_port_monitor status command is shown here:
lan_port_monitor status
VLAN_ID
------2
7
194
STATUS
------DOWN
DOWN

iDX Release 3.3

iDX Release 3.3
195

REFTechnical Reference Guide IDX 33rev B02102015

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

REFTechnical Reference Guide IDX 33rev B02102015

Uploaded by

Copyright:

Available Formats

Technical Reference Guide

iDX Release 3.3

February 10, 2015

Technical Reference Guide

Document Name: REF_Technical Reference Guide iDX 3.3_Rev B_02102015.pdf

Technical Reference Guide

First release of document for iDX 3.3

Added Group Delay and Downstream Performance topic to the DVB-S2

Technical Reference Guide

Technical Reference Guide

1 iDirect System Overview

2 DVB-S2 in iDirect Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

3 Modulation Modes and FEC Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 iDirect Spread Spectrum Networks

Overview of Spread Spectrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5 Multichannel Line Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6 SCPC Return Channels

Hardware Support and License Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Adaptive TDMA Configuration and Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Technical Reference Guide

8 Multicast Fast Path

9 QoS Implementation Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Technical Reference Guide

Group QoS Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10 TDMA Initial Transmit Power. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

11 Uplink Control Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

SCPC Return Uplink Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

12 Remote Idle and Dormant States

13 Verifying Error Thresholds Using IP Packets

Technical Reference Guide

DVB-S2 Downstream Threshold Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

14 Global NMS Architecture

How the Global NMS Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

15 Security Best Practices

Hub and NMS Server Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

16 Global Protocol Processor Architecture

Remote Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

17 Distributed NMS Server

Distributed NMS Server Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

18 Transmission Security (TRANSEC)

What is TRANSEC? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Technical Reference Guide

Disguising Remote Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

ACQ Burst Obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

19 Remote Sleep Mode

Feature Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

20 Remote Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

21 Automatic Beam Selection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

Technical Reference Guide

Beam Characteristics: Visibility and Usability . . . . . . . . . . . . . . . . . . . . . . . . . . 137

22 Hub Geographic Redundancy

Feature Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

23 Carrier Occupied Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

24 Alternate Downstream Carrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

25 Transmit Key Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Technical Reference Guide

Feature Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

26 NMS Database Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Setting Up NMS Database Replication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

27 Feature and Chassis Licensing

iDirect Licensing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

28 Hub Line Card Failover

Basic Failover Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175