REFTechnical Reference Guide IDX 33Rev B02102015

Technical Reference Guide

iDX Release 3.3

February 10, 2015Technical Reference Guide iiDX 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: T0000598ii Technical Reference GuideiDX 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

A 07/31/2014 First release of document for iDX 3.3

B 02/10/2015 Added Group Delay and Downstream Performance topic to the DVB-S2 Roll-off sectionTechnical Reference Guide iiiiDX Release 3.3

iv Technical Reference GuideiDX Release 3.3

ACM Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10Quality of Service in DVB-S2 ACM Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . .12Remote Nominal MODCOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12Remote Maximum MODCOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12Fixed Bandwidth Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13Enhanced Information Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13Scaling Factors for Fixed Bandwidth Allocation . . . . . . . . . . . . . . . . . . . . . . . .15Bandwidth Allocation Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16

DVB-S2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16Contents

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

About . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviiPurpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix

Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx

Document Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx

1 iDirect System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

IP Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

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

DVB-S2 in iDirect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9DVB-S2 Downstream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9Technical Reference Guide viDX Release 3.3

DVB-S2 Performance Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17

3 Modulation Modes and FEC Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19iDirect 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . .23Overview 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27Multichannel Line Card Model Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

Multichannel Line Card Receive Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

Multichannel Line Card Restrictions and Limits. . . . . . . . . . . . . . . . . . . . . . . . . .28

6 SCPC Return Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31Hardware 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35Theory of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

Short Term Adaptivity and Real-Time Resource Management . . . . . . . . . . . . . . . . .36Medium Term Adaptivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37Long Term Adaptivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38C/N0 and C/N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38

Adaptive TDMA Configuration and Constraints . . . . . . . . . . . . . . . . . . . . . . . . . .39Remote Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

Reference Carrier Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41Remote Carrier Constraint Parameters . . . . . . . . . . . . . . . . . . . . . . . . . .41vi Technical Reference GuideiDX Release 3.3

8 Multicast Fast Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43

Multicast Fast Path Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43

Multicast Fast Path Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .44Multicast Fast Path Encryption Key Management . . . . . . . . . . . . . . . . . . . . . . . . .44Enabling Multicast Fast Path Encryption. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46Multicast Fast Path Encryption Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46

9 QoS Implementation Principles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47Quality of Service (QoS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47

QoS Measures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47iDirect QoS Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48

Classification and Scheduling of IP Packets. . . . . . . . . . . . . . . . . . . . . . . . . . . . .50Service Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50Packet Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50

Priority Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52Class-Based Weighted Fair Queues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52Best Effort Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52

Application Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52Minimum Information Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .53Committed Information Rate (CIR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54Maximum Information Rate (MIR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54Free Slot Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54Compressed Real-Time Protocol (cRTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55Sticky CIR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55

Application Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55TDMA Slot Feathering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55

Packet Segmentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56

Application Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .56

Maximum Channel Efficiency vs. Minimum Latency . . . . . . . . . . . . . . . . . . . . . . .56

Group QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57Group QoS Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57

Bandwidth Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58Bandwidth Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58Service Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .58Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59Service Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .59Remote Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .60Technical Reference Guide viiiDX Release 3.3

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

10 TDMA Initial Transmit Power. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75All Remotes Need To Transmit Bursts in the Same C/N Range . . . . . . . . . . . . . . . .76

What Happens When Initial Tx Power Is Set Incorrectly? . . . . . . . . . . . . . . . . . . .76When Initial Transmit Power is Too High . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76When Initial Transmit Power is Too Low . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77

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

Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .79Network Operation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81

UCP Correction Processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81UCP Symbol Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .81UCP Frequency Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .82UCP Power Control and Fade Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . .82

SCPC Return Uplink Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85UCP Power Adjustment for SCPC Upstream Carriers . . . . . . . . . . . . . . . . . . . . .85

Viewing UCP Statistics in iMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .86

12 Remote Idle and Dormant States . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .89

Feature Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .90

13 Verifying Error Thresholds Using IP Packets . . . . . . . . . . . . . . . . . . .95Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95

TDMA Upstream Threshold Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .95Upstream Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96Upstream Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96viii Technical Reference GuideiDX Release 3.3

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

14 Global NMS Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99How the Global NMS Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .99

Sample Global NMS Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

15 Security Best Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Hub and NMS Server Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Network Isolation and External Access. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Server Password Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Secure Server Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Encryption of Backup Files Before Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Clearing Data from Decommissioned Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

NMS Client Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102User Passwords and Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Client Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Remote 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 . . . . . . . . . . . . . . . . . . . . . . 105Remote Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

De-coupling of NMS and Data Path Components. . . . . . . . . . . . . . . . . . . . . . . . . 105

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

iBuilder and iMonitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

18 Transmission Security (TRANSEC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 109What is TRANSEC?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

iDirect TRANSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

TRANSEC Key types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

DVB-S2 Downstream TRANSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Upstream TRANSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Technical Reference Guide ixiDX Release 3.3

Disguising Remote Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Generating the TDMA Initialization Vector . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Upstream TRANSEC Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

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

TRANSEC Dynamic Key Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

TRANSEC Remote Admission Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

ACC Key Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120ACC Key Roll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Manual ACC Key Update. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Automatic Beam Selection (ABS) and TRANSEC . . . . . . . . . . . . . . . . . . . . . . . . . 121

19 Remote Sleep Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Feature Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Awakening Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Operator-Commanded Awakening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Activity Related Awakening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Enabling Remote Sleep Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

Power Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

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

Acquisition Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Superburst Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Advantages of Superburst. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Considerations When Using Superburst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Acquisition Carrier Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Transmit Power Adjustment for Non-reference Carriers . . . . . . . . . . . . . . . . . 131Ability to Acquire When No Traffic Carrier Is Available . . . . . . . . . . . . . . . . . . 131

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

Theory of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134iDirect Beam Map File and Map Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Beam Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Conveyance Beam Map File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136Regulatory Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136x Technical Reference GuideiDX Release 3.3

Beam Characteristics: Visibility and Usability . . . . . . . . . . . . . . . . . . . . . . . . . . 137Selecting a Beam without a Map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Controlling the Antenna. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139IP Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Initial Transmit Power. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Calculation of Initial Transmit Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Setting the Initial Transmit Power Offset. . . . . . . . . . . . . . . . . . . . . . . . . . . 1406. Determining the Initial Transmit Power Offset for Other Beams. . . . . . . . . . . 141

Receive-Only Mode for ABS Remotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Multiple Map Servers per Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Operational Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Creating the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Adding a Remote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Normal Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Mapless Operations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Blockages and Beam Outages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146Error Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

22 Hub Geographic Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147Feature Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

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

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

Considerations When Determining Guard Band . . . . . . . . . . . . . . . . . . . . . . . . . 150

DVB-S2 Roll-Off Factors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151Group 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Feature Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

25 Transmit Key Line. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159Technical Reference Guide xiiDX Release 3.3

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

26 NMS Database Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161Benefits of NMS Database Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

Feature Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162NMS Database Replication Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162Replicating iDirect NMS Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163NMS Database Replication on a Distributed NMS . . . . . . . . . . . . . . . . . . . . . . . . . 164

Setting Up NMS Database Replication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

Enable Replication to a Single Backup Server . . . . . . . . . . . . . . . . . . . . . 167Add Two Additional Backup NMS Servers as MySQL Slaves . . . . . . . . . . . . . . 168Enable Replication to a Redundant NMS Server . . . . . . . . . . . . . . . . . . . . 168Stop Replication to a Backup NMS Server . . . . . . . . . . . . . . . . . . . . . . . . 168Force Recreation of an Existing MySQL Slave. . . . . . . . . . . . . . . . . . . . . . 169Stop Replication on a Backup NMS Server . . . . . . . . . . . . . . . . . . . . . . . . 169

Monitoring NMS Database Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169Events And Warnings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170Viewing Replication Conditions in iMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170Recovering from Replication Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

27 Feature and Chassis Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173iDirect Licensing Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

28 Hub Line Card Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175Basic 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 . . . . . . . . . . . . . . . . . . . 179NMS 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. . . . . . . . . . . . . . . . . . . . . . . 183Virtual Router Redundancy Protocol (VRRP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 183xii Technical Reference GuideiDX Release 3.3

VRRP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183Configuring VRRP on iDirect Remotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186VRRP Route Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Remote LAN Port Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Monitoring VRRP Status and Remote LAN Status . . . . . . . . . . . . . . . . . . . . . . . . 193Remote Console Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194Technical Reference Guide xiiiiDX Release 3.3

List of Figures

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

Figure 14-2. Sample Global NMS Network Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 100Figure 16-1. Protocol Processor Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106Figure 17-1. Sample Distributed NMS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Figure 18-1. DVB-S2 TRANSEC Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112Figure 18-2. Disguising Which Key is Used for a Burst . . . . . . . . . . . . . . . . . . . . . . . . . . 113Figure 18-3. Code Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Figure 18-4. Generating the Upstream Initialization Vector . . . . . . . . . . . . . . . . . . . . . 115Figure 18-5. Upstream ACQ Burst Obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Figure 18-6. Key Distribution Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Figure 18-7. Key Roll Data Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Figure 18-8. Host Keying Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Figure 21-1. iMonitor Probe: Remote Power Section . . . . . . . . . . . . . . . . . . . . . . . . . . 141Figure 21-2. Remote VSAT Tab: Entering the Initial Transmit Power Offset . . . . . . . . . . . 141Figure 21-3. Absolute vs. Generated G/T Contours for Two Beams . . . . . . . . . . . . . . . . . 142Figure 23-1. Spectral Mask Illustrating 20% and 5% Roll Off Factors . . . . . . . . . . . . . . . . 151Figure 23-2. Adjacent Carrier Interference Example . . . . . . . . . . . . . . . . . . . . . . . . . . 154Figure 26-1. NMS Database Replication Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 162Figure 26-2. NMS Database Replication from a Single Primary NMS Server . . . . . . . . . . . . 163Figure 26-3. NMS Database Replication on a Distributed NMS . . . . . . . . . . . . . . . . . . . . 165Figure 26-4. Enabling NMS Database Replication to a Backup Server . . . . . . . . . . . . . . . . 168Figure 26-5. Replication Conditions Viewed in iMonitor . . . . . . . . . . . . . . . . . . . . . . . . 171Figure 26-6. Replication Error Resulting in Active Condition in iMonitor . . . . . . . . . . . . . 171Figure 28-1. Line Card Failover Sequence of Events . . . . . . . . . . . . . . . . . . . . . . . . . . 177Figure 30-1. Example of a Virtual Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185Figure 30-2. Example VRRP Configuration in iBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . 187Figure 30-3. Changing the Frequency of Router Priority Messages . . . . . . . . . . . . . . . . . 190Figure 30-4. Changing a Remotes Router Priority Message Timeout . . . . . . . . . . . . . . . . 191Figure 30-5. Example of LAN Port Monitoring Configuration for Multiple Ports in iBuilder . . 192Figure 30-6. Example LAN Port Monitoring Configuration for Single Port in iBuilder . . . . . . 193Figure 30-7. VRRP and Remote LAN Status Events in iMonitor . . . . . . . . . . . . . . . . . . . . 193Technical Reference Guide xviDX Release 3.3

xvi Technical Reference GuideiDX Release 3.3

List of Tables

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

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 ServerAbout

PurposeThe Technical Reference Guide provides detailed technical information on iDirect technology and major features as implemented in iDX Release 3.3.

AudienceThe Technical Reference Guide is intended for iDirect Network Operators, network architects, and anyone upgrading to iDX Release 3.3.

ContentsThe 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 PathTechnical Reference Guide xviiiDX Release 3.3

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 Assignmentsxviii Technical Reference GuideiDX Release 3.3

Document ConventionsThis section illustrates and describes the conventions used throughout this document.

Convention Description Example

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

Enter the command:

cd /etc/snmp/

Terminal Output

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

crc report all8350.3235 : DATA CRC [ 1]8350.3502 : DATA CRC [5818]8350.4382 : DATA CRC [ 20]

Screen Reference

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

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

1. To add a remote to an inroute group, right-click the Inroute Group and select Add Remote.

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

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

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.Technical Reference Guide xixiDX Release 3.3

Getting HelpThe 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: [email protected]

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: [email protected]

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 [email protected].

Document SetThe following iDirect documents are available at http://tac.idirect.net and contain information relevant to installing and using iDirect satellite network software and equipment.

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 Guidexx Technical Reference GuideiDX Release 3.3

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.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 OverviewAn 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 Technical Reference Guide 1iDX Release 3.3

System OverviewFigure 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.2 Technical Reference GuideiDX Release 3.3

IP Network ArchitectureIP Network ArchitectureAn 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 RemoteTechnical Reference Guide 3iDX Release 3.3

IP Network ArchitectureFigure 1-3. iDirect IP Architecture VLAN Spanning Remotes4 Technical Reference GuideiDX Release 3.3

IP Network ArchitectureFigure 1-4. iDirect IP Architecture Classic IP ConfigurationTechnical Reference Guide 5iDX Release 3.3

IP Network Architecture6 Technical Reference GuideiDX Release 3.3

(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.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 ConceptsA 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 Technical Reference Guide 7iDX Release 3.3

DVB-S2 Key ConceptsDVB-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.)

Table 2-1. DVB-S2 Modulation and Coding Schemes

# Modulation Code Notes

1 QPSK 1/4 ACM or CCM

2 1/3

3 2/5

4 1/2

5 3/5

6 2/3

7 3/4

8 4/5

9 5/6

10 8/9

11 9/10 CCM only

12 8PSK 3/5 ACM or CCM

13 2/3

14 3/4

15 5/6

16 8/9

17 9/10 CCM only

18 16APSK 2/3 ACM or CCM

19 3/4

20 4/5

21 5/6

22 8/9

23 9/10 CCM only8 Technical Reference GuideiDX 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 iDirectBeginning 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 DownstreamA 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 2-1.

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.

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

Pilot symbols: unmodulated carrier

Data symbols: QPSK, 8PSK, 16APSK, or 32APSKTechnical Reference Guide 9iDX Release 3.3

DVB-S2 in iDirectiDirect 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 OperationAdaptive 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 Technical Reference GuideiDX Release 3.3

DVB-S2 in iDirect

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

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.

Figure 2-3. Feedback Loop with Backoff from Line Card to Protocol Processor

Protocol Processor Tx Line Card

Remote

Rx Line card

SNR measured andreported to PP

New MODCODIncoming userdata

internal queueSNR compared toSNR threshold:new MODCODselected

Downstream throughput(varies based onMODCOD assigned )

Protocol Processor Tx Line Card

Remot

Rx Line Card

SNR measured andreported to PP

New MODCODIncoming user

data

Tx ine card queuetoo full? Allocateless user data

internal queueSNR compared toSNR threshold:New MODCODselected

Tx line card reportsinternal queue fullness

to PP

Reduction indownstream data

Downstream throughput(varies based onMODCOD assigned)Technical Reference Guide 11iDX Release 3.3

DVB-S2 in iDirectQuality of Service in DVB-S2 ACM NetworksiDirect 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 MODCODThe 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 MODCODThe 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 Technical Reference GuideiDX Release 3.3

DVB-S2 in iDirectFixed Bandwidth OperationDuring 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 RateAs 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.Technical Reference Guide 13iDX Release 3.3

DVB-S2 in iDirectEIR 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 Varies14 Technical Reference GuideiDX Release 3.3

DVB-S2 in iDirectScaling Factors for Fixed Bandwidth AllocationTable 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.

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 / Sawhere:

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

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 MODCODTechnical Reference Guide 15iDX Release 3.3

DVB-S2 in iDirectFor 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 / SaIRa = 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.

Bandwidth Allocation FairnessThere 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 ConfigurationVarious 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.

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.)16 Technical Reference GuideiDX 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 DVB-S2 network reacts to fade conditions when ACM is enabled for the downstream carrier.

DVB-S2 Performance MonitoringiMonitor 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.Technical Reference Guide 17iDX Release 3.3

DVB-S2 in iDirect18 Technical Reference GuideiDX Release 3.3

iDirects DVB-S2 implementation is described in DVB-S2 in iDirect Networks on page7.2D 16-State Inbound Coding for DVB-S2 NetworksiDirect 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 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 RatesiDX 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 RatesBeginning 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. Technical Reference Guide 19iDX Release 3.3

TDMA Waveform Enhancementssimilar 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.

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.

TDMA Waveform EnhancementsThe 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 16-State 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.

NOTE: Because 2D 16-State coding is superior to TPC, TPC inbound coding is no longer supported in iDirect networks.20 Technical Reference GuideiDX Release 3.3

TDMA Waveform Enhancements

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

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

guard Payload Blk 1 Pilot Blk 2 Payload Blk 2Pilot Blk

3 Payload Blk NpPilot Blk

Np Payload Blk n+1

Lp L1 Lp L1 Lp L1 Lp L2Lgd

Pilot Blk 1Technical Reference Guide 21iDX Release 3.3

TDMA Waveform Enhancements22 Technical Reference GuideiDX Release 3.3

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).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 SpectrumSpread 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.Technical Reference Guide 23iDX Release 3.3

Spread Spectrum Hardware ComponentsSpread 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.

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.

Spread Spectrum Hardware ComponentsThe 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) RatesThe upstream FEC rates that can be used for Spread Spectrum carriers in this release are specified in the Link Budget Analysis Guide.

NOTE: Only Spreading Factor 2 is supported for Evolution e150 remotes.

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.24 Technical Reference GuideiDX Release 3.3

TDMA Upstream SpecificationsTDMA Upstream SpecificationsThe Spread Spectrum specifications for TDMA upstream transmissions are defined in Table 4-1.

SCPC Upstream SpecificationsThe Spread Spectrum specifications for SCPC upstream transmissions are defined in Table 4-2.

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 remotesSF = 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

Table 4-2. Spread Spectrum: SCPC Upstream Specifications

PARAMETERS VALUES ADDITIONAL INFORMATION

Modulation BPSK Other Modulations not supported

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/e850mpTechnical Reference Guide 25iDX Release 3.3

SCPC Upstream Specifications26 Technical Reference GuideiDX Release 3.3

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

Multichannel Line Card Receive Modes

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.Technical Reference Guide 27iDX Release 3.3

Multichannel Line Card Restrictions and LimitsMultichannel Line Card Restrictions and LimitsThe following restrictions apply to Multichannel Line Cards:

All upstream carriers received by an Evolution XLC-M or eM0DM line card must be the same carrier type. 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 ra

Documents

REFTechnical Reference Guide IDX 33Rev B02102015