Technical Reference Guide iDX Release 3.0

7/23/2019 Technical Reference Guide iDX Release 3.0

1/136

Technical Reference Guide

iDX Release 3.0

June 07, 2011


2/136

ii Technical Reference Guide

iDX Release 3.0

Copyright 2011 VT iDirect, Inc. All rights reserved. Reproduction in whole or in part without permission isprohibited. Information contained herein is subject to change without notice. The specifications and informationregarding the products in this document are subject to change without notice. All statements, information, andrecommendations 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 referencesare used strictly in an editorial fashion with no intent to convey any affiliation with the name or the product'srightful owner.

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

Document Part Number: T0000353
http://-/?-http://-/?-http://-/?-http://-/?-


3/136

Technical Reference Guide iii

iDX Release 3.0

Revision History

The following table shows all revisions for this document. If you do not have the latest

revision for your release, or you are not sure, please check the TAC webpage at:

http://tac.idirect.net.

Revision Date Released Reason for Change(s) Who Updated?

A 06/07/2011 First release of document for iDX 3.0 JVespoli


4/136

iv Technical Reference Guide

iDX Release 3.0

Contents

List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .x

List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xii

About This Guide

Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Intended Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Contents Of This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

Related Documents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

1 iDirect System Overview

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

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

2 DVB-S2 in iDirect Networks

DVB-S2 Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

DVB-S2 in iDirect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

DVB-S2 Downstream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

ACM Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Quality of Service in DVB-S2 ACM Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

DVB-S2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

DVB-S2 Performance Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20


5/136

Technical Reference Guide v

iDX Release 3.0

3 Modulation Modes and FEC Rates

iDirect Modulation Modes And FEC Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

TPC Modulation Modes and FEC Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

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

4 iDirect Spread Spectrum Networks

What is Spread Spectrum? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Spread Spectrum Hardware Components . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Supported Forward Error Correction (FEC) Rates . . . . . . . . . . . . . . . . . . . . . 27

iDirect iNFINITI Downstream Specifications . . . . . . . . . . . . . . . . . . . . . . . . . 27

TDMA Upstream Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

SCPC Upstream Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

5 Multichannel Line Cards

Multichannel Line Card Model Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Multichannel Line Card Receive Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Multichannel Line Card Restrictions and Limits. . . . . . . . . . . . . . . . . . . . . . . 30

6 SCPC Return Channels

Hardware Support and License Requirements. . . . . . . . . . . . . . . . . . . . . . . . 33

Single Channel vs. Multichannel SCPC Return . . . . . . . . . . . . . . . . . . . . . . . . 34

SCPC Return Feature on Remotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

VNO for SCPC Return. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7 Multicast Fast Path

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Multicast Fast Path Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

8 QoS Implementation PrinciplesQuality of Service (QoS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

QoS Measures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

iDirect QoS Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Classification and Scheduling of IP Packets. . . . . . . . . . . . . . . . . . . . . . . . . . 42


6/136

vi Technical Reference Guide

iDX Release 3.0

Service Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Packet Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Application Throughput. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Minimum Information Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Committed Information Rate (CIR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Maximum Information Rate (MIR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Free Slot Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Compressed Real-Time Protocol (cRTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Sticky CIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Application Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Packet Segmentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Application Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Maximum Channel Efficiency vs. Minimum Latency . . . . . . . . . . . . . . . . . . . . 48

Group QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Group QoS Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

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

9 Configuring Transmit Initial Power

What is TX Initial Power? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

How To Determine The Correct TX Initial Power. . . . . . . . . . . . . . . . . . . . . . 65

All Remotes Need To Transmit Bursts in the Same C/N Range . . . . . . . . . . . . . 66

What Happens When TX Initial Power Is Set Incorrectly? . . . . . . . . . . . . . . . . 67When TX Initial Power is Too High . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

When TX Initial Power is Too Low . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

10 Global NMS Architecture

How the Global NMS Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Sample Global NMS Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

11 Hub Network Security Recommendations

Limited Remote Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Root Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

12 Global Protocol Processor Architecture

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


7/136

Technical Reference Guide vii

iDX Release 3.0

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

13 Distributed NMS Server

Distributed NMS Server Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75iBuilder and iMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

14 Transmission Security (TRANSEC)

What is TRANSEC?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

iDirect TRANSEC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

TRANSEC Key types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

DVB-S2 Downstream TRANSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Upstream TRANSEC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Disguising Remote Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Generating the TDMA Initialization Vector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Upstream TRANSEC Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

ACQ Burst Obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

TRANSEC Dynamic Key Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

TRANSEC Remote Admission Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

ACC Key Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

ACC Key Roll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Manual ACC Key Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

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

15 Fast Acquisition

Feature Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

16 Remote Sleep Mode


Awakening Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Operator-Commanded Awakening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Activity Related Awakening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Enabling Remote Sleep Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

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


8/136

viii Technical Reference Guide

iDX Release 3.0

17 Automatic Beam Selection

Automatic Beam Selection Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Theory of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

The Map Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Beam Characteristics: Visibility and Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Selecting a Beam without a Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Controlling the Antenna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

IP Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Calculation of Initial Transmit Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Receive-Only Mode for ABS Remotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Multiple Map Servers per Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Operational Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Creating the Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Adding a Remote . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Normal Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Mapless Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Blockages and Beam Outages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Error Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

18 Hub Geographic Redundancy


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

19 Carrier Bandwidth Optimization

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Increasing User Data Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Decreasing Channel Spacing to Gain Additional Bandwidth . . . . . . . . . . . . . . . 111

20 Alternate Downstream Carrier

Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113


21 Feature and Chassis Licensing

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


9/136

Technical Reference Guide ix

iDX Release 3.0

22 Hub Line Card Failover

Basic Failover Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Warm Standby versus Cold Standby Line Card Failover . . . . . . . . . . . . . . . . . 117

Failover Sequence of Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118


10/136

x Technical Reference Guide

iDX Release 3.0

List of Figures

Figure 1. Sample iDirect Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Figure 2. iDirect IP Architecture Multiple VLANs per Remote . . . . . . . . . . . . . . . . . . . . . 3

Figure 3. iDirect IP Architecture VLAN Spanning Remotes . . . . . . . . . . . . . . . . . . . . . . . . 4

Figure 4. iDirect IP Architecture Classic IP Configuration . . . . . . . . . . . . . . . . . . . . . . . . 5

Figure 5. Comparison of iNFINITI, Constant Coding, and Adaptive Coding Modes . . . . . . . . . . 9

Figure 6. Physical Layer Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

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

Figure 8. SNR Threshold vs. MODCOD for the Evolution e8350 Remote . . . . . . . . . . . . . . . 13

Figure 9. Feedback Loop from Remote to Protocol Processor . . . . . . . . . . . . . . . . . . . . . 14

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

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

Figure 12. EIR: Total Bandwidth vs. Information Rate as MODCOD Varies . . . . . . . . . . . . . . 17Figure 13. Spread Spectrum Network Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Figure 14. Remote and QoS Profile Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Figure 15. iDirect Packet Scheduling Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Figure 16. Group QoS Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Figure 17. Physical Segregation Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Figure 18. CIR Per Application Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Figure 19. Tiered Service Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Figure 20. Third Level VLAN Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Figure 21. Shared Remote Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Figure 22. Remote Service Group Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Figure 23. Scaled Aggregate CIRs Below Partitions CIR . . . . . . . . . . . . . . . . . . . . . . . . . 61

Figure 24. Scaled Aggregate CIRs Exceed Partitions CIR . . . . . . . . . . . . . . . . . . . . . . . . 62

Figure 25. Bandwidth Allocation Fairness Relative to CIR . . . . . . . . . . . . . . . . . . . . . . . . 63

Figure 26. Bandwidth Allocation Fairness Relative to MODCOD . . . . . . . . . . . . . . . . . . . . 64

Figure 27. C/N Nominal Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Figure 28. TX Initial Power Too High . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Figure 29. TX Initial Power Too Low . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Figure 30. Global NMS Database Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Figure 31. Sample Global NMS Network Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Figure 32. Protocol Processor Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Figure 33. Sample Distributed NMS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Figure 34. DVB-S2 TRANSEC Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Figure 35. Disguising Which Key is Used for a Burst . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Figure 36. Code Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Figure 37. Generating the Upstream Initialization Vector . . . . . . . . . . . . . . . . . . . . . . . . 83

Figure 38. Upstream ACQ Burst Obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84


11/136

Technical Reference Guide xi

iDX Release 3.0

Figure 39. Key Distribution Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Figure 40. Key Roll Data Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Figure 41. Host Keying Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Figure 42. Overlay of Carrier Spectrums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Figure 43. Adding an Upstream Carrier By Reducing Carrier Spacing . . . . . . . . . . . . . . . . 112

Figure 44. Line Card Failover Sequence of Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119


12/136

xii Technical Reference Guide

iDX Release 3.0

List of Tables

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

Table 2. ACM MODCOD Scaling Factors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Table 3. TPC Modulation Modes and FEC Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Table 4. Modulation Modes and FEC Rates for 2D 16-State Inbound Coding over TDMA . . . . . 23

Table 5. Modulation Modes and FEC Rates for 2D 16-State Inbound Coding over SCPC. . . . . . 24

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

Table 7. Spread Spectrum: Downstream Specifications. . . . . . . . . . . . . . . . . . . . . . . . . . 27

Table 8. Spread Spectrum: TDMA Upstream Specifications . . . . . . . . . . . . . . . . . . . . . . . 28

Table 9. Spread Spectrum: SCPC Upstream Specifications . . . . . . . . . . . . . . . . . . . . . . . . 28

Table 10. Multichannel Receive Line Card Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Table 11. Single Channel vs. Multichannel SCPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Table 12. Power Consumption: Normal Operations vs. Remote Sleep Mode. . . . . . . . . . . . . 95


13/136

Technical Reference Guide xiii

iDX Release 3.0

About This Guide

PurposeThe Technical Reference Guideprovides detailed technical information on iDirect technology

and major features as implemented in iDX Release 3.0.

Intended AudienceThe intended audience for this guide includes network operators using the iDirect iDS system,

network architects, and anyone upgrading to iDX Release 3.0.

Note: It is expected that the user of this material has attended the iDirect IOMtraining course and is familiar with the iDirect network solution and associatedequipment.

Contents Of This Guide

This document contains the following major sections: iDirect System Overview

DVB-S2 in iDirect Networks

Modulation Modes and FEC Rates

iDirect Spread Spectrum Networks

QoS Implementation Principles

Configuring Transmit Initial Power

Global NMS Architecture

Hub Network Security Recommendations

Global Protocol Processor Architecture

Distributed NMS Server

Transmission Security (TRANSEC)

Fast Acquisition

Automatic Beam Selection

Hub Geographic Redundancy

Carrier Bandwidth Optimization


14/136

xiv Technical Reference Guide

iDX Release 3.0

Alternate Downstream Carrier

Feature and Chassis Licensing

Hub Line Card Failover

Document ConventionsThis section illustrates and describes the conventions used throughout the manual. Take a

look now, before you begin using this manual, so that youll know how to interpret the

information presented.

Convention Description Example

Blue

Courier

font

Used when the user is

required to enter a

command at a command

line prompt or in a console.

Enter the command:

cd /etc/snmp/

Cour i erf ont

Used when showingresulting output from a

command that was entered

at a command line or on a

console.

crc report all

3100. 3235 : DATA CRC [ 1]3100. 3502 : DATA CRC [ 5818]3100. 4382 : DATA CRC [ 20]

BoldTrebuchetfont

Used when referring to text

that appears on the screen

on a windows-type

Graphical User Interface

(GUI).

Used when specifying

names of commands,

menus, folders, tabs,

dialogs, list boxes, andoptions.

1. If you are adding a remote to an Inroute Group,

right-click the Inroute Groupand select AddRemote.

The Remotedialog box has a number of user-selectable tabs across the top. The Informationtab is

visible when the dialog box opens.

Blue

Trebuchet

font

Used to show all

hyperlinked text within a

document.

Refer to Quality of Service in DVB-S2 ACM Networks

on page

15for a detailed description of ACM operation

with EIR enabled.

Bold italicTrebuchetfont

Used to emphasize

information for the user,

such as in notes.

Note: It is important to set TX Initial Power on aremote modem correctly to ensure optimalUpstream channel performance.

Red italic

Trebuchet

font

Used when the user needs

to strictlyfollow the

instructions or have

additional knowledge abouta procedure or action.

WARNING! The following procedure may cause

a network outage.


15/136

Technical Reference Guide xv

iDX Release 3.0

Related DocumentsThe following iDirect documents are available at http://tac.idirect.netand may also contain

information relevant to this release. Please consult these documents for information about

installing and using iDirects satellite network software and equipment.

iDX Release Notes

iDX Software Installation Guideor Network Upgrade Procedure Guide

iDX iBuilder User Guide

iDX iMonitor User Guide

iDX Installation and Commissioning Guide for Remote Satellite Routers

iDX Features and Chassis Licensing Guide

iDX Software Installation Checklist/Software Upgrade Survey

iDX Link Budget Analysis Guide

Getting HelpThe iDirect Technical Assistance Center (TAC) is available to help you 24 hours a day, 365 days

a year. Software user guides, installation procedures, a FAQ page, and other documentation

that supports our products are available on the TAC webpage. Please access our TAC webpage

at: http://tac.idirect.net.

If you are unable to find the answers or information that you need, you can contact the TAC at

(703) 648-8151.

If you are interested in purchasing iDirect products, please contact iDirect Corporate Sales by

telephone or email.

Telephone: (703) 648-8000

Email: [email protected]

iDirect strives to produce documentation that is technically accurate, easy to use, and helpful

to our customers. Your feedback is welcomed! Send your comments to [email protected].


16/136

xvi Technical Reference Guide

iDX Release 3.0


17/136

Technical Reference Guide 1

iDX Release 3.0

1 iDirect System Overview

This chapter presents a high-level overview of iDirect Networks. It provides a sample iDirect

network and describes the IP network architectures supported by iDirect.

System 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. A sample iDirect network is shown in Figure 1.

Figure 1. Sample iDirect Network

RemoteInfrastructure


iDirect HubInfrastructure

Inroute Group 1 Inroute Group 2Shared Downstream

800 Remotes 400 Remotes

Satellite

40 Mbps 12 x 512 kbps 10 x 256 kbps


SCPC Return Channels

1 Mbps 256 kbps512 kbps

... ...


18/136

2 Technical Reference Guide

iDX Release 3.0

System Overview

The iDirect Hub equipment consists of one or more iDirect Hub Chassis with Universal Line

Cards, one or more Protocol Processors (PP), a Network Management System (NMS) and the

appropriate RF equipment. Each remote site consists of an iDirect broadband router and the

appropriate external VSAT equipment.

The selection of an upstream TDMA carrier by a remote is determined either at networkacquisition time or dynamically at run-time, based on a network configuration setting. iDirect

software has features and controls that allow the system to be configured to provide QoS and

other traffic engineered solutions to remote users. All network configuration, control, and

monitoring functions are provided via the integrated NMS.

The iDirect software provides:

Packet-based and network-based QoS

TCP acceleration

AES link encryption

Local DNS cache on the remote

End-to-end VLAN tagging

Dynamic routing protocol support via RIPv2 over the satellite link

Multicast support via IGMPv2 or IGMPv3

VoIP support via voice optimized features such as cRTP

An iDirect network interfaces to the external world through IP over Ethernet ports on the

remote unit and the Protocol Processor at the hub.


19/136


iDX Release 3.0

IP Network Architecture

IP Network ArchitectureThe following figures illustrate the basic iDirect IP network architectures.

Figure2, iDirect IP Architecture Multiple VLANs per Remote

Figure

3, iDirect IP Architecture VLAN Spanning Remotes Figure

4, iDirect IP Architecture Classic IP Configuration

Figure 2. iDirect IP Architecture Multiple VLANs per Remote


20/136


iDX Release 3.0


Figure 3. iDirect IP Architecture VLAN Spanning Remotes


21/136


iDX Release 3.0


Figure 4. iDirect IP Architecture Classic IP Configuration

iDirect allows you to mix traditional IP routing based networks with VLAN based

configurations. This capability provides support for customers that have conflicting IP address

ranges in a direct fashion, and multiple independent customers at a single remote site by

configuring multiple VLANs directly on the remote.

In addition to end-to-end VLAN connection, the system supports RIPv2 in an end-to-end

manner including over the satellite link; RIPv2 can be configured on per-network interface.


22/136


iDX Release 3.0



23/136


iDX Release 3.0

2 DVB-S2 in iDirect

Networks

Digital Video Broadcasting (DVB) represents a set of open standards for satellite digital

broadcasting. DVB-S2 is an extension to the widely-used DVB-S standard and was introduced in

March 2005. It provides for:

Improved inner coding: Low-Density Parity Coding

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

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

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

bandwidth.

Note: Beginning with iDX Release 2.2, the iDirect TRANSEC feature is supported inDVB-S2 networks. See Transmission Security (TRANSEC) on page77fordetails.

DVB-S2 Key ConceptsA BBFRAME(Baseband Frame) is the basic unit of the DVB-S2 protocol. Two frame sizes are

supported: shortand 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.

MODCODrefers to the combinations of Modulation Types and Error Coding schemes supported

by the DVB-S2 standard. The higher the modulation the greater the number of bits per symbol

(or bits per Hz). The modulation types specified by the standard are:

QPSK (2 bits/Hz)

8PSK (3 bits/Hz)

16PSK (4 bits/Hz)

Coding refers to the error-correction coding schemes available. Low-Density Parity Coding

(LDPC) and Bose-Chaudhuri-Hocquenghem (BCH) codes are used in DVB-S2. Effective rates are1/4 through 9/10. The 9/10 coding rates are not supported for short BBFRAMEs.

The DVB-S2 standard does not support every combination of modulation and coding. DVB-S2

specifies the MODCODs shown in Table 1on page

8. In general, the lower the MODCOD, the

more robust the error correction, and the lower the efficiency in bits per Hz. The higher the

MODCOD, the less robust the error correction, and the greater the efficiency in bits per Hz.


24/136


iDX Release 3.0

DVB-S2 Key Concepts

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

CCM(Constant Coding and Modulation) specifies that every BBFRAME is transmitted at the

same MODCOD. Effectively, an iDirect network transmitting an iNFINITI downstream

carrier is a CCM system.

Note: CCM using long frames is not supported on iDirect DVB-S2 outbound carriers.

However, you can simulate a CCM outbound carrier using short frames byselecting ACM and setting the Maximum and Minimum MODCODs to the samevalue. See the iBuilder User Guide for details on configuring your carriers.

ACM(Adaptive Coding and Modulation) specifies that every BBFRAME can be transmitted

on a different MODCOD. Remotes receiving an ACM carrier cannot anticipate the MODCOD

of the next BBFRAME. A DVB-S2 demodulator must be designed to handle dynamic

MODCOD variation.

Table 1. DVB-S2 Modulation and Coding Schemes

# Modulation Code Notes

1 QPSK 1/4 ACM or CCM

2 1/3

3 2/5

4 1/2

5 3/5

6 2/3

7 3/4

8 4/5

9 5/6

10 8/9

11 9/10 CCM only

12 8PSK 3/5 ACM or CCM

13 2/3

14 3/4

15 5/6

16 8/9

17 9/10 CCM only

18 16APSK 2/3 ACM or CCM

19 3/4

20 4/5

21 5/6

22 8/9

23 9/10 CCM only


25/136


iDX Release 3.0

DVB-S2 in iDirect

VCM(Variable Coding and Modulation) specifies that MODCODs are assigned according to

service type. As in ACM mode, the resulting downstream contains BBFRAMEs transmitted

at different MODCODs. (iDirect does not support VCM on the downstream.)

Figure 5compares iDirects iNFINITI Mode, CCM Mode and ACM Mode.

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

DVB-S2 in iDirect

iDirect DVB-S2 networks support ACM on the downstream carrier with all modulations up to16APSK. An iDirect DVB-S2 network uses short DVB-S2 BBFRAMES for ACM. iDirect does not

support VCM on the downstream carrier.

iDX Release 3.0 supports the following hardware in DVB-S2 networks:

Evolution eM1D1 line card (Tx/Rx; Rx-only for SCPC return channel)

Evolution XLC-11 line card (Tx/Rx)

Evolution XLC-10 line card (Tx-only)

Evolution eM0DM line card (Rx-only; single or multiple inbound channels; TDMA or SCPC

return channel)

Evolution XLC-M line card (Rx-only; single or multiple inbound channels; TDMA or SCPC

return channel)

Evolution e8350 remote satellite router (TDMA or SCPC return channel)

Evolution iConnex e800/e850mp remote satellite routers (TDMA or SCPC return channel)

Evolution X3 remote satellite router (TDMA or SCPC return channel)

Evolution X5 remote satellite router (TDMA or SCPC return channel)

Evolution eP100 remote satellite router (TDMA return channel only)

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

QPSKTPC .66

QPSKTPC .66

...

time

time

time

8PSK

9/10

8PSK

9/10

8PSK

9/10

8PSK

9/10...

16P5/6

16P4/5

8PSK

2/316P4/5

QPSK

2/3

8PSK

8/9

8PSK

8/916P8/9

8PSK

3/4

iNFINITI Mode:All Frames: single Modulation (QPSK or BPSK)

All Frames: single coding (TPC 0.793, etc. )

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


26/136


iDX Release 3.0

DVB-S2 in iDirect

The eM1D1 line card and the XLC-11 line card are Tx/Rx line cards. Both line cards can

transmit either an iDirect iNFINITI or a DVB-S2 downstream carrier while receiving a TDMA

upstream carrier. The eM1D1 can also receive an SCPC return channel but it must be

configured as Rx-only to do so. An XLC-10 line card is a Tx-only line card that can only be

deployed in DVB-S2 networks.

An eM0DM or XLC-M line card is a multi-channel, Rx-only line card that can be deployed in

either DVB-S2 or iNFINITI networks. However, in iNFINITI networks these line cards can only

receive a single TDMA upstream carrier. In DVB-S2 networks, an eM0DM or XLC-M line card can

receive either TDMA or SCPC return channels. However, it cannot receive both upstream

carrier types at the same time.

An Evolution e8350, e800, e850 or X5 remote satellite router can receive either an iNFINITI or

a DVB-S2 downstream carrier while transmitting on a TDMA upstream carrier. In DVB-S2

networks, an e8350, e800, e850, X3 or X5 can also be configured to transmit an SCPC return

carrier. An Evolution X3 remote satellite router can only operate in a DVB-S2 network and can

only transmit a TDMA upstream carrier.

The Evolution eP100 is a custom form-factor remote satellite router that is not generally

available for purchase. It can only receive a DVB-S2 downstream carrier and it can onlytransmit a TDMA upstream carrier.

DVB-S2 Downstream

An iDirect iNFINITI downstream carrier is effectively CCM. At configuration time, a modulation

(such as BPSK) and coding rate (such as TPC 0.79) are selected. These characteristics of the

downstream are fixed for the duration of the operation of the network.

A DVB-S2 downstream can be configured as CCM (future) or ACM. If you configure the

downstream as ACM, it is not constrained to operate at a fixed modulation and coding.

Instead, the modulation and coding of the downstream varies within a configurable range of

MODCODs.

An iDirect DVB-S2 downstream contains a continuous stream of Physical Layer Frames

(PLFRAMEs). The PLHEADER indicates the type of modulation and error correction coding used

on the subsequent data. It also indicates the data format and frame length. Refer to Figure 6.

Figure 6. Physical Layer Frames

The PLHEADER always uses /2 BPSK modulation. Like most DVB-S2 systems, iDirect injects

pilot symbols within the data stream. The overhead of the DVB-S2 downstream varies

between 2.65% and 3.85%.

The symbol rate remains fixed on the DVB-S2 downstream. Variation in throughput is realized

through DVB-S2 support, and the variation of MODCODs in ACM Mode. The maximum possible

throughput of the DVB-S2 carrier (calculated at 45 MSps and highest MODCOD 16APSK 8/9) is

PLHEADER: signalsMODCOD and frame

length (always /2 BPSK)

Pilot symbols:

unmodulatedcarrier

Data symbols:

QPSK, 8PSK,16APSK, or 32APSK


27/136


iDX Release 3.0

DVB-S2 in iDirect

approximately 155 Mbps. As with iDirect iNFINITI networks, multiple protocol processors may

be required to support high traffic to multiple remotes.

iDirect uses DVB-S2 Generic Streams for encapsulation of downstream data between the

DVB-S2 line cards and remotes. Although the DVB-S2 standard includes the provision for

generic streams, it is silent on how to encapsulate data in this mode. iDirect uses theproprietary LEGS (Lightweight Encapsulation for Generic Streams) protocol for this purpose.

LEGS maximizes the efficiency of data packing into BBFRAMES on the downstream. For

example, if a timeplan only takes up 80% of a BBFRAME, the LEGS protocol allows the line

card to include a portion of another packet that is ready for transmission in the same frame.

This results in maximum use of the downstream bandwidth.

ACM Operation

ACM mode allows remotes operating in better signal conditions to receive data on higher

MODCODs. This is accomplished by varying the MODCODs of data targeted to specific remotes

to match their current receive capabilities.

Not all data is sent to a remote at its best MODCOD. Important system information (such astimeplan messages), as well as broadcast traffic, is transmitted at the minimum MODCOD

configured for the outbound carrier. This allows all remotes in the network, even those

operating at the worst MODCOD, to reliably receive this information.

The protocol processor determines the maximum MODCOD for all data sent to the DVB-S2 line

card for transmission over the outbound carrier. However, the line card does not necessarily

respect these MODCOD assignments. In the interest of downstream efficiency, some data

scheduled for a high MODCOD may be transmitted at a lower one as an alternative to inserting

padding bytes into a BBFRAME. When assembling a BBFRAME for transmission, the line card

first packs all available data for the chosen MODCOD into the frame. If there is space left in

the BBFRAME, and no data left for transmission at that MODCOD, the line card attempts to

pack the remainder of the frame with data for higher MODCODs. This takes advantage of the

fact that a remote can demodulate any MODCOD in the range between the carriers minimumMODCOD and the remotes current maximum MODCOD.

The maximum MODCOD of a remote is based on the latest Signal-to-Noise Ratio (SNR)

reported by the remote to the protocol processor. The table in Figure 7shows the SNR

thresholds per MODCOD for the Evolution X3 and X5 remotes. The table in Figure 8shows the

SNR thresholds per MODCOD for the Evolution e8350 remote.These values are determined

during hardware qualification. The graph shows how spectral efficiency increases as the

MODCOD changes.


28/136


iDX Release 3.0

DVB-S2 in iDirect

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


29/136


iDX Release 3.0

DVB-S2 in iDirect

Figure 8. SNR Threshold vs. MODCOD for the Evolution e8350 Remote

The hub adjusts the MODCODs of the transmissions to the remotes by means of the feedback

loop shown in Figure 9on page

14. Each remote continually measures its downstream SNR and

reports the current value to the protocol processor. When the protocol processor assigns datato 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 reasonsof downstream packing efficiency.


30/136


iDX Release 3.0

DVB-S2 in iDirect

Figure 9and Figure 10show the operation of the SNR feedback loop and the behavior of the

line card and remote during fast fade conditions. Figure 9shows the basic SNR reporting loop

described above. The example shows an XLC-10 line card transmitting to an X3 remote.

However, the feedback loop discussion applies to any Evolution line card that is transmitting a

DVB-S2 carrier to any Evolution remote.

Figure 9. Feedback Loop from Remote to Protocol Processor

Figure 10shows the backoff mechanism that exists between the line card and protocol

processor to prevent data loss. The protocol processor decreases the maximum data sent to

the line card for transmission based on a measure of the number of remaining untransmitted

bytes on the line card. These bytes are scaled according to the MODCOD on which they are to

be transmitted, since bytes destined to be transmitted at lower MODCODs will take longer to

transmit than bytes destined to be transmitted on a higher MODCODs.

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


31/136


iDX Release 3.0

DVB-S2 in iDirect

Quality of Service in DVB-S2 ACM Networks

iDirect QoS for DVB-S2 downstream carriers is basically identical to QoS for iNFINITI

downstream carriers. (See QoS Implementation Principles on page

39.) 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 truebecause user data transmitted at a higher MODCOD requires less bandwidth than it does at a

lower MODCOD.

When configuring QoS in iBuilder, you can define a Maximum Information Rate (MIR) and/or a

Committed Information Rate (CIR) at various levels of the QoS tree. (See the iBuilder User

Guidefor definitions of CIR and MIR.) For an ACM outbound, the amount of bandwidth granted

for a configured CIR or MIR is affected by both the MODCOD that the remote is currently

receiving and a number of parameters configurable in iBuilder. The remainder of this section

discusses the various parameters and options that affect DVB-S2 bandwidth allocation and

how they affect the system performance.

Remote Nominal MODCOD

You can configure a Nominal MODCOD for DVB-S2 remotes operating in ACM mode. The

Nominal MODCOD is the Reference Operating Point (ROP) for the remote. By default, a

remotes Nominal MODCOD is equal to the DVB-S2 carriers Maximum MODCOD. The Nominal

MODCOD is typically determined by the link budget but may be adjusted after the remote is

operational.

In a fixed network environment, the Nominal MODCOD is typically chosen to be the Clear Sky

MODCOD of the remote. In a maritime network where the Clear Sky MODCOD depends on the

position of the ship, the Nominal MODCOD may be any point in the beam coverage at which

the service provider chooses to guarantee the CIR.

The CIR and MIR granted to the remote are limited by the Remotes Nominal MODCOD. The

remote is allowed to operate at MODCODs higher than the Nominal MODCOD (as long as it does

not exceed the configured Remote Maximum MODCOD described below), but is not grantedadditional higher CIR or MIR when operating above the Nominal MODCOD.

Remote Maximum MODCOD

You can also configure a Maximum MODCOD for DVB-S2 remotes operating in ACM mode. By

default, a remotes Maximum MODCOD is equal to the DVB-S2 carriers Maximum MODOCD.

iBuilder allows you to limit the Maximum MODCOD for a remote to a value lower than the DVB-

S2 carriers Maximum MODCOD and higher than or equal to the remotes Nominal MODCOD.

This is important if your link budget supports higher MODCODs but your remotes are using

LNBs that do not have the phase stability required for the higher MODCODs. For example, a

DRO LNB cannot support 16APSK due to phase instability at higher MODCODs.

Note that a remotes Maximum MODCOD is not the same as a remotes Nominal MODCOD. Theremote 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.


32/136


iDX Release 3.0

DVB-S2 in iDirect

Fixed Bandwidth Operation

During a rain fade, the CIR or MIR granted to a remote are scaled down based on the 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 11shows the system behavior when operating in Fixed Bandwidth Mode. The remotesNominal 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 11. Total Bandwidth vs. Information Rate in Fixed Bandwidth Operation

Enhanced Information Rate

As noted above, the occupied bandwidth for CIR or MIR varies per MODCOD. If, when

allocating downstream bandwidth for a remote, the system always attempted to meet these

rates regardless of MODCOD, then a remote in a deep rain fade may be granted a

disproportionate share of bandwidth at the expense of other remotes in the network. On the

other hand, if CIR and MIR settings were only honored at the remotes Nominal MODCOD

(Fixed Bandwidth Mode), then there would be no option to increase the bandwidth to satisfy

the requested information rate when a remote dropped below its Nominal MODCOD.

The Enhanced Information Rate (EIR) option allows you to configure the system to maintain

CIR or MIR during rain fade for the physical remote (Remote Service Groups or Remote-Based

Group QoS) or critical applications (Application-Based Group QoS). EIR only applies to

networks that use DVB-S2 with Adaptive Coding and Modulation (ACM). EIR can be enabled for

a physical remote or at several levels of the Group QoS tree. For details on configuring EIR,

see the iBuilder User Guide.

Nominal@ ClearSky

0

50

100

150

200

250

300

350

400

0

100

200

300

400

500

600

RelativeBandwidth

CIR

Fixed Bandwidth


33/136


iDX Release 3.0

DVB-S2 in iDirect

EIR is only enabled in the range of MODCODs from the remotes Nominal MODCOD down to the

configured EIR Minimum MODCOD. Within this range, the system always attempts to allocate

requested bandwidth in accordance with the CIR and MIR settings, regardless of the current

MODCOD at which the remote is operating. Since higher MODCODs contain more information

bits per second, as the remotes MODCOD increases, so does the capacity of the outbound

channel to carry additional information.

As signal conditions worsen, and the MODCOD assigned to the remote drops, the system

attempts to maintain CIR and MIR onlydown to the configured EIR Minimum MODCOD. If the

remote drops below this EIR Minimum MODCOD, it is allocated bandwidth based on the

remotes Nominal MODCOD with the rate scaled to the MODCOD actually assigned to the

remote. The net result is that the remote receives the CIR or MIR as long as the current

MODCOD of the remote does not fall below the EIR Minimum MODCOD. Below the EIR

minimum MODCOD, the information rate achieved by the remote falls below the configured

settings.

The system behavior in EIR mode is shown in Figure 12. The remotes Nominal MODCOD is

labeled Nominal in the figure. The system maintains the CIR and MIR down to the EIR

Minimum MODCOD. Notice in the figure that when the remote is operating below EIR Minimum

MODCOD, it is granted the same amount of satellite bandwidth as at the remotes Nominal

MODCOD.

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

Nominal EIR Min

0

50

100

150

200

250

300

350

400

0

100

200

300

400

500

600

Relative

Bandwidth

C

IR

EIR Mode


34/136


iDX Release 3.0

DVB-S2 in iDirect

Scaling Factors for Fixed Bandwidth Allocation

Table 2shows 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= IRnx 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

Table 2. ACM MODCOD Scaling Factors

MODCODScalingFactor

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


35/136


iDX Release 3.0

DVB-S2 in iDirect

For example, assume that a remote is configured with a CIR of 1024 kbps and a Nominal

MODCOD of 16ASPK 8/9. If EIR is not in effect, and data is being sent to the remote at

MODCOD QPSK 8/9, then the resulting information rate is:

IRa= IRnx Sb/ Sa

IRa= 1024 kbps x 1.2382 / 2.4605 = 515 kbpsFor two scenarios showing how CIR and MIR are allocated for a DVB-S2 network in ACM mode,

see page

60and page

62.

Note: When bandwidth is allocated for a remote, the CIR and MIR are scaled to theremotes Nominal MODCOD. At higher levels of the Group QoS tree (BandwidthGroup, Service Group, etc.) CIR and MIR are scaled to the networks bestMODCOD.)

Bandwidth Allocation Fairness

There are two configurable options for bandwidth allocation fairness:

Allocation Fairness Relative To CIR

Allocation Fairness Relative to MODCOD

Enabling or disabling either or both of these options for your Group QoS nodes or for your

physical remotes affects how CIR and MIR bandwidth is apportioned during bandwidth

contention. Allocation Fairness Relative to MODCOD only affects bandwidth allocation on DVB-

S2 ACM outbound carriers. Allocation Fairness Relative to CIR affects bandwidth allocation in

general.

For a detailed explanation of these options, see the Quality of Service chapter in the iBuilder

User Guide. For sample scenarios illustrating the use of these options, see Bandwidth

Allocation Fairness Relative to CIR on page

63and Bandwidth Allocation Fairness Relative

to MODCOD on page

64.

DVB-S2 Configuration

The iBuilder GUI allows you to configure various parameters that affect the operation of your

DVB-S2 networks. For details on configuring DVB-S2, see the iBuilder User Guide. The

following areas are affected:

Downstream Carrier Definition: When you add an ACM DVB-S2 downstream carrier, you

must specify a range of MODCODs over which the carrier will operate. Error correction for

the carrier is fixed to LDPC and BCH. In addition, you cannot select an information rate or

transmission rate for a DVB-S2 carrier as an alternative to the symbol rate, since these

rates will vary dynamically with changing MODCODs.

However, iBuilder provides a MODCOD Distribution Calculator that allows you to estimate

the overall Information Rate for your carrier based on the distribution of the Nominal

MODCODs of the remotes in your network. You can access this calculator by clicking theMODCOD Distribution button on the DVB-S2 Downstream Carrier dialog box. A similar

button allows you to estimate CIR and MIR bandwidth requirements at various levels of

the Group QoS tree.


36/136


iDX Release 3.0

DVB-S2 in iDirect

Multicast MODCOD: By default, all multicast data on an ACM downstream carrier is

transmitted at the lowest MODCOD of the carrier. You can configure different MODCODs

for your user multicast traffic by selecting Multicast MODCODs for your Multicast

Applications in iBuilder. See the Quality of Service chapter of the iBuilder User Guidefor

details.

Remote Nominal MODCOD and Remote Maximum MODCOD. These remote parameters are

discussed in detail at the beginning of this section. You can configure these parameters on

the Remote QoS tab in iBuilder.

DVB-S2 Line Card Definition: When you add a DVB-S2 line card, you must configure a

second IP port (called the GIG0 port) in addition to the management IP port. All data to

be transmitted on the DVB-S2 downstream carrier is sent to this port.

DVB-S2 Network-Level Parameters: iBuilder allows you to configure the network-level

parameters that control how a DVB-S2 network behaves when ACM is enabled for your

downstream carrier. These parameters affect the behavior of the system during remote

fade conditions.

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

ACM Gain represents the increase in performance achieved on a DVB-S2 outbound carrier

when the MODCOD used to transmit data is higher than the minimum MODCOD configured

for the carrier. ACM Gain can be monitored at the Network, Inroute Group, Remote and Tx

Line card levels of the iMonitor tree.

You can examine how the downstream data is distributed across the range of MODCODs

configured for an ACM carrier. MODCOD distribution can be monitored at the Network,

Remote and Tx Line Card levels of the iMonitor tree.

In an ACM network, each DVB-S2 remote periodically reports its current Signal-to-Noise

Ratio (SNR) to the protocol processor. Based on the remotes last-reported SNR, the

protocol processor determines the maximum MODCOD at which the remote can receivedata. Remote SNR can be monitored at the Network, Inroute Group, and Remote levels of

the iMonitor tree.

A DVB-S2 line card keeps detailed statistics for traffic that is sent from the protocol

processor to the line card and then transmitted by the line card on the DVB-S2 outbound

carrier. DVB-S2 hub line card debug statistics can be monitored at the Tx Line Card level

of the iMonitor tree.

The NMS provides statistics on the operating point of each remote. In iMonitor, you can

use these statistics to determine the percentage of time a remote is operating at its

Nominal MODCOD and at other MODCODs. Although independent of traffic, this allows you

to compare a remotes actual operating point with its configured (or contractual)

operating point and make adjustments to your network in the case of discrepancies.

For details, see the iMonitor User Guide.


37/136


iDX Release 3.0

3 Modulation Modes and

FEC Rates

This chapter describes the Modulation Modes and Forward Error Correction (FEC) rates that

are supported in iDX Release 3.0.

iDirect Modulation Modes And FEC RatesiDX Release 3.0 supports star networks with DVB-S2 or iDirect iNFINITI downstream carriers.

Remotes transmit to the hub on either TDMA upstream carriers or SCPC return channels. The

tables in this chapter show the modulation modes and FEC rates supported on iDirect

downstream and upstream carriers.

iNFINITI hardware can only be deployed in networks that transmit iDirect iNFINITI downstream

carriers. iNFINITI hardware cannot be used in DVB-S2 networks. Only TDMA upstream carriers

can be used in networks that transmit iDirect iNFINITI downstream carriers. SCPC return

channels can only be used in DVB-S2 networks.

Only Evolution hardware can transmit or receive DVB-S2 downstream carriers. In addition, a

multichannel line card can only be used to receive multiple upstream channels when deployed

in a DVB-S2 network.

Some Evolution line cards are also capable of transmitting an iDirect iNFINITI downstream

carrier and some Evolution remotes are capable of receiving an iNFINITI downstream carrier.

The types of downstream and upstream carriers that a specific Evolution line card or remote

can transmit and receive depends on the model type of the hardware and on the type of

network (DVB-S2 or iNFINITI) in which the hardware is deployed. In some cases it also depends

on licensing. Please see the iBuilder User Guidefor further details.

TPC Modulation Modes and FEC Rates on page

22specifies the upstream and downstream

Modulation Modes and FEC Rates available when using Turbo Product Code (TPC) Error

Correction used in iNFINITI networks. In DVB-S2 networks, iDirect only supports 2D 16-State

Inbound Coding on upstream carriers. 2D 16-State Inbound Coding for DVB-S2 Networks on

page

23specifies the Modulation Modes and FEC rates available when using 2D 16-State

Inbound Coding.

TPC Error Correction is no longer supported on upstream carriers in DVB-S2 networks. In this

release, 2D 16-State Inbound Coding must be selected for your upstream carriers if you are

using a DVB-S2 downstream.

Note: For specific Eb/No values for each FEC rate and Modulation combination, referto the iDirect Link Budget Analysis Guide, which is available for download fromthe TAC web page located at http://tac.idirect.net.


38/136


iDX Release 3.0

TPC Modulation Modes and FEC Rates

TPC Modulation Modes and FEC RatesTable 3on page 22shows the Modulation Modes and FEC Rates available for downstream

carriers and TDMA upstream carriers when using TPC Error Correction. SCPC return channels

can only use 2D 16-State coding; they cannot use TPC Error Correction.

Note: Beginning with iDX Release 3.0, TPC Error Correction is no longer supported onupstream carriers in DVB-S2 networks. 2D 16-State Inbound Coding must beselected for your upstream carriers if you are using a DVB-S2 downstream.

Table 3. TPC Modulation Modes and FEC Rates

Note: For the list of supported DVB-S2 downstream MODCODs, see Table 1onpage 8.

Tx RxSpread

Spectrum

eM1D1, XLC-10, XLC-11 e8350, e800/e850mp,

X5, X3, eP100

X

Tx RxSpread

Spectrum

BPSKBPSK QPSK 8PSK

Block

Size

Payload

Bytes

.533 eM1D1, XLC-11, M1D1 iNFINITI X Yes Yes X 1K 53

.495eM1D1, XLC-11, M1D1 iNFINITI, e8350,

e800/e850mp, X5Yes Yes Yes X 4K 251


e800/e850mp, X5Yes Yes Yes Yes 4K 404


e800/e850mp, X5Yes Yes Yes Yes 16K 1800

Tx Rx

Spread

Spectrum

BPSKBPSK QPSK 8PSK

Block

Size

Payload

Bytes

.431 iNFINITI, e8350,e800/e850mp, X5

MxD1, eM1D1,XLC-11,eM0DM (SC mode)

Yes Yes X X 1K 43

.533iNFINITI, e8350,

e800/e850mp, X5

MxD1, eM1D1, XLC-11,

eM0DM (SC mode)Yes Yes Yes X 1K 56

.660iNFINITI, e8350,

e800/e850mp, X5


eM0DM (SC mode)Yes Yes Yes Yes 1K 72

.793iNFINITI, e8350

e800/e850mp, X5


eM0DM (SC mode)X Yes Yes Yes 4K 394

This FEC combination is not recommended for new designs. For new network designs, iDirect recommends using FEC 0.495. If

you have an existing network using FEC 0.533 operating at an information rate of 10 Msps or greater, the network may experienceerrors due to an FEC decoding limitation.

Spread Spectrum: eM1D1, XLC-11, M1D1-TSS and e8350, iConnex e800/e850mp, X5, 8350 only

TDMA 8PSK Rate 0.793 requires Evolution Hub Line Card to receive the upstream carrier

See the DVB-S2 chapter for supported MODCODs and block sizes.

The TDMA Payload Bytes value removes the TDMA header overhead of 10 bytes: Demand=2 + LL=6 + PAD=2. SAR, Encryption,

and VLAN features add additional overhead.

iNFINITI channel framing uses a modified HDLC header, which requires bit-stuffing to prevent false end-of-frame detection. The

actual payload is variable, and always s lightly less than the numbers indicated in the table.

StarNetworks

DVB-S2

Downstream

Hardware Support Modulation and Coding

QPSK, 8PSK, 16APSK

ACM or CCM

Modulation Mode

iNFINITI

DownstreamFEC

TDMA

Upstream

FEC

Modulation Mode

Hardware Support

Hardware Support


39/136


iDX Release 3.0

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

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: a 100 byte payload (88 byte IP payload), a

170 byte payload (158 byte IP payload), and a 438 byte payload (426 byte IP payload). The

new small payload size has a sixteen byte larger payload than the QPSK .66 1K TPC block,

ensuring the same low latency at call connection for VOIP applications. The large payload size

is similar to the 4k TPC block to allow the same low TDMA overhead performance.The

medium payload size provides an intermediate option when considering the trade off between

bandwidth granularity and reducing the TDMA overhead.

2D 16-State Coding has a number of benefits:

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

Efficiency gains on average of 1 dB

Cost savings from the use of smaller antenna and BUC sizes Easy implementation since no new network design is required

2D 16-State Coding supports easy mapping of existing TPC to 2D 16-State configurations. For

example, the QPSK 2D16S-100B-3/4 offers similar performance and better spectral efficiency

than the TPC QPSK 1k block with .66 FEC. For detailed options, see the Link Budget Analysis

Guide.

Table 4shows the upstream Modulation and Coding rates available per payload size when

using 2D 16-State Inbound Coding over TDMA. Table 5shows the upstream Modulation and

Coding rates available per payload size when using 2D 16-State Inbound Coding on an SCPC

return channel. Table 6shows the IP payload and block sizes for each supported payload size.

Note: For specific Eb/No values for each FEC rate and Modulation combination, refer

to the Link Budget Analysis Guide for this release.

Table 4. Modulation Modes and FEC Rates for 2D 16-State Inbound Coding over TDMA


40/136


iDX Release 3.0

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

Table 5. Modulation Modes and FEC Rates for 2D 16-State Inbound Coding over SCPC

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


41/136


iDX Release 3.0

4 iDirect Spread Spectrum

Networks

This section provides information about Spread Spectrum technology in an iDirect network. It

discusses the following topics:

What is Spread Spectrum? on page

25

iDirect iNFINITI Downstream Specifications on page27

TDMA Upstream Specifications on page

28

What is Spread Spectrum?Spread Spectrum is a transmission technique in which a pseudo-noise (PN) code is employed

as a modulation waveform to spread the signal energy over a bandwidth much greater than

the signal information bandwidth. The signal is despread at the receiver by using a

synchronized replica of the pseudo-noise code. By spreading the signal information over

greater bandwidth, less transmit power is required. A sample Spread Spectrum network

diagram is shown in Figure 13.

Figure 13. Spread Spectrum Network Diagram

Spreading takes place when the input data (dt) is multiplied with the PN code (pn

t) which

results in the transmit baseband signal (txb). The baseband signal is then modulated and

transmitted to the receiving station. Despreading takes place at the receiving station when

the baseband signal is demodulated (rxb) and correlated with the replica PN (pnr) which

results in the data output (dr).

Spread

Spectrum transmission is supported on TDMA and SCPC upstream carriers and on

iDirect SCPC downstream carriers. Spread spectrum is not available on DVB-S2 downstream

carriers. Spread Spectrum is employed in iDirect networks to minimize adjacent satellite


42/136


iDX Release 3.0

What is Spread Spectrum?

interference (ASI). ASI can occur in applications such as Comms-On-The-Move (COTM) because

the small antennas (typically sub-meter) used on mobile vehicles have a small aperture size,

large beam width, and high pointing error which can combine to cause ASI. Enabling Spread

Spectrum reduces the spectral density of the transmission so that it is low enough to avoid

interfering with adjacent satellites. When receiving through a COTM antenna, Spread

Spectrum improves carrier performance in cases of ASI (channel/interference).

iDirect Spread Spectrum is an extension of BPSK modulation in both upstream and

downstream. The signal is spread over wider bandwidth according to a Spreading Factor (SF)

that you select. For an iNFINITI downstream carrier or for an SCPC upstream carrier, you can

select No Spreading, 2, 4 or 8. You can select a TDMA upstream Spreading Factor of No

Spreading, 2, 4, 8 or 16.

Note: A Downstream Spreading Factor of 8 is only available for Evolution hub linecards transmitting to Evolution Remotes. Upstream Spreading Factors of 8 and16 are only available for Evolution Remotes transmitting to Evolution hub linecards.

Note: The following uses of Spread Spectrum require a license from iDirect: Upstream

Spread Spectrum for Evolution X5 and eP100 remotes; Upstream SpreadSpectrum for the XLC-11 line card; and Downstream Spread Spectrum for theXLC-11 line card.

Each symbol in the spreading code is called a chip. The spread rate is the rate at which

chips are transmitted. For example, selecting No Spreading means that the spread rate is one

chip per symbol (which is equivalent to regular BPSK). Selecting a Spreading Factor of 4

means that the spread rate is four chips per symbol.

An additional Spreading Factor, COTM SF=1, can be selected for upstream TDMA carriers only.

If you select COTM SF=1, there is no spreading. However, the size of the carrier unique word is

increased, allowing mobile remotes to remain in the network when they might otherwise drop

out. An advantage of this spreading factor is that you can receive error-free data at a slightly

lower C/N compared to regular BPSK. However, carriers with COTM SF=1 transmit at a slightly

lower information rate.

COTM SF=1 is primarily intended for use by fast moving mobile remotes. The additional unique

word overhead allows the remote to tolerate more than ten times as much frequency offset

as can be tolerated by regular BPSK.

That makes COTM SF=1 the appropriate choice when the

Doppler effect caused by vehicle speed and acceleration is significant even though the link

budget does not require spreading. Examples include small maritime vessels, motor vehicles,

trains, and aircraft. Slow moving, large maritime vessels generally do not require COTM SF=1.

Spread Spectrum can also be used to hide a carrier in the noise of an empty transponder.

However, Spread Spectrum should not be confused with Code Division Multiple Access (CDMA),

which is the process of transmitting multiple Spread Spectrum channels simultaneously on the

same bandwidth.

Spread Spectrum may also be useful in situations where local or RF interference isunavoidable, such as hostile jamming. However, iDirect designed the Spread Spectrum feature

primarily for COTM and ASI mitigation. iDirect Spread Spectrum may be a good solution for

overcoming some instances of interference or jamming, but it is recommended that you

discuss your particular application with iDirect sales engineering.


43/136


iDX Release 3.0

Spread Spectrum Hardware Components

Spread Spectrum Hardware ComponentsThe Hub Line Cards (HLC) that support Spread Spectrum are the iNFINITI M1D1-TSS line card,

the Evolution eM1D1 line card, and the Evolution XLC-11 line card. (An XLC-11 line card must

be licensed for upstream and/or downstream Spread Spectrum before this feature can be

enabled on the line card.)

The iNFINITI M1D1-TSS line card occupies two slots in the hub chassis. Therefore, you can

have a maximum of 10 iNFINITI M1D1-TSS line cards in one 20 slot chassis. Also, you cannot

install an M1D1-TSS line card in slot 20. Evolution eM1D1 and XLC-11 line cards only require a

single slot.

Note: You must install the M1D1-TSS HLC in a slot that has one empty slot to the right.For example, if you want to install the HLC in slot 4, slot 5 must be empty. Be surethat you also check chassis slot configuration in iBuilder to verify that you are notinstalling the HLC in a reserved slot.

The remotes that support spread spectrum are the iNFINITI 8350, the Evolution e8350, and

the iConnex e800 and e850mp. The Evolution X5 and eP100 support upstream SpreadSpectrum if Spread Spectrum is licensed on the remote. Other remotes do not currently

support spread spectrum.

Supported Forward Error Correction (FEC) RatesThe upstream and downstream FEC rates that are supported for Spread Spectrum in this

release are described in the tables in Modulation Modes and FEC Rates on page

21.

iDirect iNFINITI Downstream SpecificationsThe Spread Spectrum specifications for an iDirect iNFINITI downstream carrier are outlined in

Table 7.

Table 7. Spread Spectrum: Downstream Specifications

PARAMETERS VALUES ADDITIONAL INFORMATION

Modulation BPSK Other Modulations not supported

Spreading Factor No Spreading, 2, 4, 8 SF=8 requires Evolution hardware

Symbol Rate 64 ksym/s - 15 Msym/s

Chip Rate 15 Mchip/s maximum

BER Performance Refer to the iDirect Link Budget Analysis

Guide

Occupied BW 1.2 * Chip Rate Plus hub downcoverter oscillator

stability factor

Spectral Mask IESS-308/309, MIL-STD 188xxx

Carrier Suppression > -30 dBc

Hardware Platforms M1D1-TSS HLC; Evolution eM1D1, XLC-11


44/136


iDX Release 3.0

TDMA Upstream Specifications

TDMA Upstream SpecificationsThe specifications for the spread spectrum upstream channel are outlined in Table 8. The

Spreading Factor COTM 1, used in fast moving mobile applications, is described on page

26.

SCPC Upstream SpecificationsThe Spread Spectrum specifications for an SCPC upstream carrier are outlined in Table 7.

Table 8. Spread Spectrum: TDMA Upstream Specifications



Spreading Factor No Spreading, COTM SF=1, 2, 4, 8 or 16 SF8 and 16 require Evolution hardware

Symbol Rate 64 ksym/s - 7.5 Msym/s

Chip Rate 7.5 Mchip maximum


Guide

Maximum Frequency Offset 1.5% * Fsym

Unique Word Overhead 128 symbols

Occupied Bandwidth 1.2 * Chip Rate

Hardware Platforms iNFINITI series 8350; Evolution e8350,

iConnex e800/e850mp, X5, eP100

Table 9. Spread Spectrum: SCPC Upstream Specifications



Spreading Factor No Spreading, 2, 4, 8

Symbol Rate 128 ksym/s - 15 Msym/s

Chip Rate 15 Mchip/s maximum


Guide

Occupied BW 1.2 * Chip Rate

Hardware Platforms Evolution e8350, iConnex e800/e850mp,

Evolution X5

Evolution X5 requires licenses for

spread spectrum and SCPC return
http://-/?-http://-/?-http://-/?-http://-/?-http://-/?-http://-/?-http://-/?-http://-/?-


45/136


iDX Release 3.0

5 Multichannel Line Cards

Introduced in iDX Release 3.0, Multichannel Line Cards are receive-only Evolution line cards

capable of receiving up to eight upstream carriers simultaneously. A Multichannel Line Card

can receive either TDMA upstream carriers or SCPC return channels with appropriate

licensing.

Multichannel Line Card Model TypesThere are two iDirect Multichannel Line Card model types:

Evolution XLC-M

Evolution eM0DM

Note: You must allow for 60 Watts of power for each Multichannel Line Card in a 20slot chassis. Total available power for each 20 slot chassis model type isspecified in the Series 15100 Universal Satellite Hub (5IF/20-Slot) Installationand Safety Manual.

Multichannel Line Card Receive ModesWhen you configure a Multichannel Line Card in iBuilder, you must select one of the following

receive modes for the line card:

Single Channel TDMA

Multiple Channel TDMA

Multiple Channel SCPC

Note: Single Channel SCPC Mode is only available for Evolution eM1D1 line cards.

Note: Both the XLC-M and eM0DM line cards were available in earlier releases withsingle channel TDMA support only. If you have deployed these model types in

your networks, they will automatically be set to Single Channel TDMA receivemode when you upgrade from a pre-iDX 3.0 release.


46/136


iDX Release 3.0

Multichannel Line Card Restrictions and Limits

Multichannel 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. You cannot configure a Multichannel Line Card to receive both SCPCand TDMA carriers at the same time.

All TDMA upstream carriers received by a Multichannel Line Card must be in the same

Inroute Group.

An Inroute Group can contain a maximum of 16 TDMA upstream carriers.

All TDMA upstream carriers received by a Multichannel Line Card must have the same

Modulation, FEC Rate, and Symbol Rate.

SCPC upstream carriers received by a Multichannel Line Card can have different

Modulations, FEC Rates, and Symbol Rates.

All TDMA upstream carriers received by a Multichannel Line Card must be on the same

transponder.

Multiple Channel TDMA, Multiple Channel SCPC, and Single Channel SCPC modes are onlysupported in DVB-S2 networks. Since DVB-S2 networks require 2D 16-State Inbound

Coding, the upstream carriers cannot be configure to use TPC coding when any of these

modes are selected. (See Modulation Modes and FEC Rates on page

21for specifications

on all supported carrier types.)

Note: Single Channel TDMA is supported in both DVB-S2 and iNFINITI networks. Youcan continue to use upstream TPC coding in this mode in iNFINITI networks.

All upstream carriers received by Multichannel Line Card must be completely within a 36

MHz operational band, including the roll off resulting from the 1.2 carrier spacing. The

operational band must fall between 950 MHz and 1700 MHz for an XLC-M line card and

between 950 MHz and 2000 MHz for an eM0DM line card. (See Table 10.)

Both per-carrier and composite symbol rate limits apply for TDMA and SCPC. (See Table10.)

There is a 40 Mbps composite information rate limit on SCPC return channels on

Multichannel Line Cards. The total for all channels received by the line card cannot

exceed 40 Mbps.

Note: When approaching the 40 Mbps composite information rate limit for SCPCreturn carriers on a multichannel line card, limits may apply to individualhigh-rate carriers. For details, see the Release Notes for your version of iDXRelease 3.0.

Licenses are required to configure Multichannel Line Cards in TDMA and SCPC

multichannel modes for more than one channel. (See the iDirect Features and Chassis

Licensing Guidefor details.) A license is not required for TDMA single channel receive

mode, or to configure a single channel in TDMA or SCPC multichannel mode.

Spread Spectrum is not supported on Multichannel Line Cards.

Note: Unlike iDX Release 2.3, in iDX Release 3.0 TRANSEC is not supported on eM0DMline cards in any receive mode.


47/136


iDX Release 3.0

Multichannel Line Card Restrictions and Limits

Table Table 10shows various parameters associated with the Multichannel Line Card.

Table 10. Multichannel Receive Line Card Parameters

Note: For Upstream TDMA and SCPC Modulation Modes and FEC Rates, see

Modulation Modes and FEC Rates on page

21.For details on how to configure Multichannel Line Cards and on how to add carriers to

Multichannel Line Cards, see the iBuilder User Guide.

Hardware TypeOperating Mode Single Channel TDMA Multichannel SCPC Multichannel TDMA

L-Band Frequency MIN (MHz) 950 950 950

L-Band Frequency MAX (MHz)1700 (XLC-M)

2000 (eM0DM)

1700 (XLC-M)

2000 (eM0DM)

1700 (XLC-M)

2000 (eM0DM)

IF Bandwidth (MHz) N/A 36 36

Max Composite Symbol Rate (ksym) N/A N/A 7500

Max Composite Information Bit Rate (Mbps) N/A 40 N/A

Channels per card 11 (default)

up to 8 (license required)

1 (default)

up to 4 (license)

up to 8 (license)

Max Symbol Rate (ksym) per carrier 750