REFTechnical Reference Guide IDX 33Rev B02102015

Technical Reference Guide

iDX Release 3.3

February 10, 2015

Technical Reference Guide iDX Release 3.3

i

Copyright © 2015 VT iDirect, Inc. All rights reserved. Reproduction in whole or in part without permission is prohibited. Information contained herein is subject to change without notice. The specifications and information regarding the products in this document are subject to change without notice. All statements, information, and recommendations in this document are believed to be accurate, but are presented without warranty of any kind, express, or implied. Users must take full responsibility for their application of any products. Trademarks, brand names and products mentioned in this document are the property of their respective owners. All such references are used strictly in an editorial fashion with no intent to convey any affiliation with the name or the product's rightful owner.

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

ii

Technical Reference Guide iDX Release 3.3

Revision History

The following table shows all revisions for this document. To determine if this is the latest revision, check the TAC Web site at http://tac.idirect.net. Revision

Date

Updates

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 section

Technical Reference Guide iDX Release 3.3

iii

iv

Technical Reference Guide iDX Release 3.3

Contents

List of Figures About

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix Getting Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx Document Set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx

1 iDirect System Overview

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 IP Network Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

2 DVB-S2 in iDirect Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 DVB-S2 Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7 DVB-S2 in iDirect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 DVB-S2 Downstream . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 ACM Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Quality of Service in DVB-S2 ACM Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Remote Nominal MODCOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Remote Maximum MODCOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Fixed Bandwidth Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Enhanced Information Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Scaling Factors for Fixed Bandwidth Allocation . . . . . . . . . . . . . . . . . . . . . . . . 15 Bandwidth Allocation Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 DVB-S2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 DVB-S2 Performance Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Technical Reference Guide iDX Release 3.3

v

3 Modulation Modes and FEC Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 iDirect Modulation Modes And FEC Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 DVB-S2 Modulation Modes and FEC Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2D 16-State Inbound Coding for DVB-S2 Networks . . . . . . . . . . . . . . . . . . . . . . . . 19 TDMA Waveform Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 iDirect Spread Spectrum Networks

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Overview of Spread Spectrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Spread Spectrum Hardware Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Supported Forward Error Correction (FEC) Rates . . . . . . . . . . . . . . . . . . . . . . . . 24 TDMA Upstream Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 SCPC Upstream Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5 Multichannel Line Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Multichannel Line Card Model Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Multichannel Line Card Receive Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Multichannel Line Card Restrictions and Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 28

6 SCPC Return Channels

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Hardware Support and License Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Single Channel vs. Multichannel SCPC Return . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 SCPC Return Feature on Remotes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 VNO for SCPC Return. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

7 Adaptive TDMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Theory of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . Short Term Adaptivity and Real-Time Resource Management . Medium Term Adaptivity . . . . . . . . . . . . . . . . . . . . . . . . Long Term Adaptivity . . . . . . . . . . . . . . . . . . . . . . . . . . C/N0 and C/N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. 35 . 36 . 37 . 38 . 38

Adaptive TDMA Configuration and Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Remote Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Reference Carrier Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Remote Carrier Constraint Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 41

vi

Technical Reference Guide iDX Release 3.3

8 Multicast Fast Path

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Multicast Fast Path Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Multicast Fast Path Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Multicast Fast Path Encryption Key Management . . . . . . . . . . . . . . . . . . . . . . . . . 44 Enabling Multicast Fast Path Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Multicast Fast Path Encryption Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

9 QoS Implementation Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Quality of Service (QoS). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 QoS Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 iDirect QoS Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Classification and Scheduling of IP Packets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Service Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Packet Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Priority Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Class-Based Weighted Fair Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Best Effort Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Application Throughput . . . . . . . . . . Minimum Information Rate . . . . . . . Committed Information Rate (CIR) . . Maximum Information Rate (MIR) . . . Free Slot Allocation . . . . . . . . . . .

. . . . .

. . . . . Compressed Real-Time Protocol (cRTP) . Sticky CIR . . . . . . . . . . . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. 52 . 53 . 54 . 54 . 54 . 55 . 55

Application Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 TDMA Slot Feathering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Packet Segmentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Application Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Maximum Channel Efficiency vs. Minimum Latency . . . . . . . . . . . . . . . . . . . . . . . 56 Group QoS . . . . . . . . . . . . Group QoS Structure . . . . Bandwidth Pool . . . . Bandwidth Group . . . Service Group . . . . . Application . . . . . . . Service Profiles . . . . Remote Profiles . . . .

Technical Reference Guide iDX Release 3.3

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. 57 . 57 . 58 . 58 . 58 . 59 . 59 . 60

vii

Group QoS Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Physical Segregation Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . CIR Per Application Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . Tiered Service Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Third Level of Segregation by VLAN Scenario . . . . . . . . . . . . . . . . . The Shared Remote Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . Remote Service Group Scenario . . . . . . . . . . . . . . . . . . . . . . . . . DVB-S2 ACM Scenario 1: Scaled Aggregate CIRs Below Partition’s CIR . . DVB-S2 ACM Scenario 2: Scaled Aggregate CIRs Exceeds Partition’s CIR . Bandwidth Allocation Fairness Relative to CIR . . . . . . . . . . . . . . . . Bandwidth Allocation Fairness Relative to MODCOD . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. 60 . 60 . 61 . 62 . 63 . 65 . 66 . 68 . 70 . 71 . 72

10 TDMA Initial Transmit Power. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 All Remotes Need To Transmit Bursts in the Same C/N Range . . . . . . . . . . . . . . . . 76 What Happens When Initial Tx Power Is Set Incorrectly? . . . . . . . . . . . . . . . . . . . 76 When Initial Transmit Power is Too High . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 When Initial Transmit Power is Too Low . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

11 Uplink Control Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 TDMA Uplink Control . . . . . . . . . . Acquisition . . . . . . . . . . . . . . . Network Operation . . . . . . . . . . UCP Correction Processing. . . UCP Symbol Timing . . . . . . . UCP Frequency Tracking . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . . UCP Power Control and Fade Detection .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. 79 . 79 . 81 . 81 . 81 . 82 . 82

SCPC Return Uplink Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 UCP Power Adjustment for SCPC Upstream Carriers . . . . . . . . . . . . . . . . . . . . . 85 Viewing UCP Statistics in iMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

12 Remote Idle and Dormant States

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Feature Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

13 Verifying Error Thresholds Using IP Packets

. . . . . . . . . . . . . . . . . . . 95

Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 TDMA Upstream Threshold Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Upstream Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Upstream Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

viii

Technical Reference Guide iDX Release 3.3

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

14 Global NMS Architecture

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

How the Global NMS Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Sample Global NMS Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

15 Security Best Practices

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

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

16 Global Protocol Processor Architecture

. . . . . . . . . . . . . . . . . . . . . . 105

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

17 Distributed NMS Server

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Distributed NMS Server Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 iBuilder and iMonitor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

18 Transmission Security (TRANSEC)

. . . . . . . . . . . . . . . . . . . . . . . . . . . 109

What is TRANSEC? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 iDirect TRANSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 TRANSEC Key types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 DVB-S2 Downstream TRANSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Upstream TRANSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Technical Reference Guide iDX Release 3.3

ix

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

ACQ Burst Obfuscation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 TRANSEC Dynamic Key Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 TRANSEC Remote Admission Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 ACC Key Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 ACC Key Roll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Manual ACC Key Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Automatic Beam Selection (ABS) and TRANSEC . . . . . . . . . . . . . . . . . . . . . . . . . 121

19 Remote Sleep Mode

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Feature Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Awakening Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Operator-Commanded Awakening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Activity Related Awakening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Enabling Remote Sleep Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Power Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

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

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

x

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. 134 . 134 . 134 . 135 . 136 . 136

Technical Reference Guide iDX Release 3.3

Beam Characteristics: Visibility and Usability . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Selecting a Beam without a Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Controlling the Antenna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 IP Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Initial Transmit Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Calculation of Initial Transmit Power . . . . . . . . . . . . . . . . . . . Setting the Initial Transmit Power Offset . . . . . . . . . . . . . . . . . 6. Determining the Initial Transmit Power Offset for Other Beams . Receive-Only Mode for ABS Remotes . . . . . . . . . . . . . . . . . . . . . . Multiple Map Servers per Network . . . . . . . . . . . . . . . . . . . . . . .

Operational Scenarios . . Creating the Network . Adding a Remote . . . . Normal Operations . . . Mapless Operations . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . Blockages and Beam Outages . Error Recovery . . . . . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

22 Hub Geographic Redundancy

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. 139 . 139 . 140 . 140 . 141 . 143 . 143

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. 144 . 144 . 144 . 145 . 145 . 146 . 146

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

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

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

24 Alternate Downstream Carrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Feature Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

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

Technical Reference Guide iDX Release 3.3

xi

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

26 NMS Database Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Benefits of NMS Database Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Feature Description . . . . . . . . . . . . . . . . . . . . NMS Database Replication Architecture . . . . . . . Replicating iDirect NMS Databases . . . . . . . . . . NMS Database Replication on a Distributed NMS . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. 162 . 162 . 163 . 164

Setting Up NMS Database Replication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Enable Replication to a Single Backup Server . . . . . . . . . . . . . . . . . . . . . 167 Add Two Additional Backup NMS Servers as MySQL Slaves . . . . . . . . . . . . . . 168 Enable Replication to a Redundant NMS Server . . . . . . . . . . . . . . . . . . . . 168 Stop Replication to a Backup NMS Server . . . . . . . . . . . . . . . . . . . . . . . . 168 Force Recreation of an Existing MySQL Slave . . . . . . . . . . . . . . . . . . . . . . 169 Stop Replication on a Backup NMS Server . . . . . . . . . . . . . . . . . . . . . . . . 169 Monitoring NMS Database Replication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Events And Warnings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Viewing Replication Conditions in iMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Recovering from Replication Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

27 Feature and Chassis Licensing

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

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

28 Hub Line Card Failover

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Basic Failover Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Warm Standby versus Cold Standby Line Card Failover . . . . . . . . . . . . . . . . . . . 175 Failover Sequence of Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

29 NMS, PP and GKD Server Port Assignments

. . . . . . . . . . . . . . . . . . . 179

NMS Server Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 PP Controller Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 GKD Server Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Protocol Processor Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Port Assignments for NMS/Upstream Router Traffic Flow . . . . . . . . . . . . . . . . . . 182

30 VRRP and Remote LAN Port Monitoring. . . . . . . . . . . . . . . . . . . . . . . 183 Virtual Router Redundancy Protocol (VRRP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

xii

Technical Reference Guide iDX Release 3.3

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

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

Technical Reference Guide iDX Release 3.3

xiii

List of Figures Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure

xiv

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

Technical Reference Guide iDX Release 3.3

Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure

14-2. 16-1. 17-1. 18-1. 18-2. 18-3. 18-4. 18-5. 18-6. 18-7. 18-8. 21-1. 21-2. 21-3. 23-1. 23-2. 26-1. 26-2. 26-3. 26-4. 26-5. 26-6. 28-1. 30-1. 30-2. 30-3. 30-4. 30-5. 30-6. 30-7.

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

Technical Reference Guide iDX Release 3.3

100 106 107 112 113 114 115 116 117 118 119 141 141 142 151 154 162 163 165 168 171 171 177 185 187 190 191 192 193 193

xv

List of Tables Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table

xvi

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

Technical Reference Guide iDX Release 3.3

About

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

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

Contents The Technical Reference Guide contains the following major sections: •

iDirect System Overview

•

DVB-S2 in iDirect Networks

•

Modulation Modes and FEC Rates

•

iDirect Spread Spectrum Networks

•

Multichannel Line Cards

•

SCPC Return Channels

•

Adaptive TDMA

•

Multicast Fast Path

•

QoS Implementation Principles

•

TDMA Initial Transmit Power

•

Uplink Control Process

•

Remote Idle and Dormant States

•

Verifying Error Thresholds Using IP Packets

•

Global NMS Architecture

•

Security Best Practices

•

Global Protocol Processor Architecture

•

Distributed NMS Server

Technical Reference Guide iDX Release 3.3

xvii

xviii

•

Transmission Security (TRANSEC)

•

Remote Sleep Mode

•

Automatic Beam Selection

•

Hub Geographic Redundancy

•

Carrier Occupied Bandwidth

•

Alternate Downstream Carrier

•

Transmit Key Line

•

NMS Database Replication

•

Feature and Chassis Licensing

•

Hub Line Card Failover

•

NMS, PP and GKD Server Port Assignments

Technical Reference Guide iDX Release 3.3

Document Conventions This section illustrates and describes the conventions used throughout this document. Convention Description

Example

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

Enter the command:

Terminal Output

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

crc report all

Screen Reference

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

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

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

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

Used to show all hyperlinked text within a document or external links such as web page URLs.

For instructions on adding a line card to the network tree, see Adding a Line Card on page 108.

Command

Hyperlink

cd /etc/snmp/

8350.3235 : DATA CRC [ 1] 8350.3502 : DATA CRC [5818] 8350.4382 : DATA CRC [ 20]

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

Technical Reference Guide iDX Release 3.3

xix

Getting Help The iDirect Technical Assistance Center (TAC) is available to provide assistance 24 hours a day, 365 days a year. Software user guides, installation procedures, FAQs, and other documents that support iDirect products are available on the TAC Web site. Access the TAC Web site at http://tac.idirect.net. The TAC may also be contacted by telephone or e-mail. •

Telephone: (703) 648-8151

•

E-mail: [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 Set The following iDirect documents are available at http://tac.idirect.net and contain information relevant to installing and using iDirect satellite network software and equipment.

xx

•

Release Notes

•

Software Installation Guide or Network Upgrade Procedure Guide

•

iBuilder User Guide

•

iMonitor User Guide

•

Installation and Commissioning Guide for Remote Satellite Routers

•

Features and Chassis Licensing Guide

•

Software Installation Checklist/Software Upgrade Survey

•

Link Budget Analysis Guide

Technical Reference Guide iDX Release 3.3

1 iDirect System Overview

This chapter presents a high-level overview of iDirect Networks. It provides a sample iDirect network and describes the IP network architectures supported by iDirect.

System Overview An iDirect network is a satellite based TCP/IP network with a Star topology in which a Time Division Multiplexed (TDM) broadcast downstream channel from a central hub location is shared by a number of remote sites. Each remote transmits to the hub either on a shared Deterministic-TDMA (D-TDMA) upstream channel with dynamic timeplan slot assignments or on a dedicated SCPC return channel. The iDirect Hub equipment consists of one or more iDirect Hub Chassis with Universal Line Cards, one or more Protocol Processors (PP), a Network Management System (NMS) and the appropriate RF equipment. Each remote site consists of an iDirect broadband satellite router and the appropriate external VSAT equipment. TDMA upstream carriers are configured in groups called Inroute Groups. Multiple Inroute Groups can be associated with one downstream carrier. Any remote configured to transmit to the hub on a TDMA upstream carrier is part of an Inroute Group. The specific TDMA upstream carrier on which the remote transmits at any given time is determined dynamically during operation. A remote that transmits on a dedicated SCPC return channel is not associated with an Inroute Group. Instead, the dedicated SCPC upstream carrier is directly assigned to the remote and to the hub line card that receives the carrier. Prior to iDX Release 3.2, all TDMA upstream carriers in an Inroute Group were required to have the same symbol rate, modulation and error coding. With the introduction of Adaptive TDMA in iDX Release 3.2, the symbol rate and MODCOD of the carriers in an Inroute Group may vary from carrier to carrier. Remotes in an Inroute Group move from carrier to carrier in real time based on network conditions. Furthermore, with Adaptive TDMA, the individual carrier MODCODs can adjust over time to optimize network performance for changing network conditions. Adaptive TDMA allows for significantly less fade margin in the network design and optimal use of upstream bandwidth during operation. Figure 1-1 on p. 2 shows an example an iDirect network. The network consists of one downstream carrier; two Inroute Groups providing the TDMA return channels for a total of 1200 remotes; and three remotes transmitting dedicated SCPC return channels to the hub.

Technical Reference Guide iDX Release 3.3

1

System Overview

Figure 1-1. Sample iDirect Network iDirect software has flexible controls for configuring Quality of Service (QoS) and other traffic-engineered solutions based on end-user requirements and operator service plans. Network configuration, control, and monitoring functions are provided by the integrated NMS. The iDirect software provides a long list of features, including: •

Packet-based and network-based QoS

•

TCP acceleration

•

AES link encryption

•

Local DNS cache on the remote

•

End-to-end VLAN tagging

•

Dynamic routing protocol support via RIPv2 over the satellite link

•

Multicast support via IGMPv2 or IGMPv3

•

VoIP support via voice optimized features such as cRTP

For a complete list of available features in all iDirect releases, see the iDirect Software Feature Matrix available on the TAC Web site.

2

Technical Reference Guide iDX Release 3.3

IP Network Architecture

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

Figure 1-2. iDirect IP Architecture – Multiple VLANs per Remote

Technical Reference Guide iDX Release 3.3

3

IP Network Architecture

Figure 1-3. iDirect IP Architecture – VLAN Spanning Remotes

4

Technical Reference Guide iDX Release 3.3

IP Network Architecture

Figure 1-4. iDirect IP Architecture – Classic IP Configuration

Technical Reference Guide iDX Release 3.3

5

IP Network Architecture

6

Technical Reference Guide iDX Release 3.3

2 DVB-S2 in iDirect Networks Digital Video Broadcasting (DVB) represents a set of open standards for satellite digital broadcasting. DVB-S2 is an extension to the widely-used DVB-S standard and was introduced in March 2005. It provides for: •

Improved inner coding: Low-Density Parity Coding

•

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

•

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

These improvements lead to greater efficiencies and flexibility in the use of available bandwidth. iDirect supports DVB-S2 in both TRANSEC and non-TRANSEC networks.

DVB-S2 Key Concepts A BBFRAME (Baseband Frame) is the basic unit of the DVB-S2 protocol. Two frame sizes are supported: short and long. Each frame type is defined in the DVB-S2 standard in terms of the number of coded bits: short frames contain 16200 coded bits; long frames contain 64800 coded bits. MODCOD refers to the combinations of Modulation Types and Error Coding schemes supported by the DVB-S2 standard. The higher the modulation the greater the number of bits per symbol (or bits per Hz). The modulation types specified by the standard are: •

QPSK (2 bits/s/Hz)

•

8PSK (3 bits/s/Hz)

•

16APSK (4 bits/s/Hz)

Coding refers to the error-correction coding schemes available. Low-Density Parity Coding (LDPC) and Bose-Chaudhuri-Hocquenghem (BCH) codes are used in DVB-S2. Effective rates are 1/4 through 9/10. The 9/10 coding rates are only supported for long BBFRAMEs. The DVB-S2 standard does not support every combination of modulation and coding. DVB-S2 specifies the MODCODs shown in Table 2-1 on page 8. In general, the lower the MODCOD, the more robust the error correction, and the lower the efficiency in bits per Hz. The higher the MODCOD, the less robust the error correction, and the greater the efficiency in bits per Hz.

Technical Reference Guide iDX Release 3.3

7

DVB-S2 Key Concepts

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

3/5

ACM or CCM

12

8PSK

13

2/3

14

3/4

15

5/6

16

8/9

17

9/10

CCM only

2/3

ACM or CCM

18

16APSK

19

3/4

20

4/5

21

5/6

22

8/9

23

9/10

CCM only

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

8

•

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

Technical Reference Guide iDX Release 3.3

DVB-S2 in iDirect

•

VCM (Variable Coding and Modulation) specifies that MODCODs are assigned according to service type. As in ACM mode, the resulting downstream contains BBFRAMEs transmitted at different MODCODs. Although iDirect does not support VCM, it does allow configuration of specific MODCODs for multicast streams.

DVB-S2 in iDirect Beginning with iDX Release 3.2, iDirect only supports DVB-S2 downstream carriers. Networks with iNFINITI downstream carriers are only supported in earlier releases. All iDirect hardware supported in this release can operate in a DVB-S2 network. The iBuilder User Guide lists all available line card and remote model types. iDirect DVB-S2 networks support ACM on the downstream carrier with all modulations up to 16APSK. An iDirect DVB-S2 network always uses short DVB-S2 BBFRAMES. iDirect also allows the Network Operator to configure multiple multicast streams and specify the multicast MODCOD of each stream.

DVB-S2 Downstream A DVB-S2 downstream can only be configured as ACM. An ACM downstream is not constrained to operate at a fixed modulation and coding. Instead, the modulation and coding of the downstream varies within a configurable range of MODCODs. In iDirect, CCM is configured by limiting the MODCOD range to a single MODCOD. An iDirect DVB-S2 downstream contains a continuous stream of Physical Layer Frames (PLFRAMEs). The PLHEADER indicates the type of modulation and error correction coding used on the subsequent data. It also indicates the data format and frame length. Refer to Figure 21.

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

Pilot symbols: unmodulated carrier

Data symbols: QPSK, 8PSK, 16APSK, or 32APSK

Figure 2-1. Physical Layer Frames The PLHEADER always uses /2 BPSK modulation. Like most DVB-S2 systems, iDirect injects pilot symbols within the data stream. The overhead of the DVB-S2 downstream varies between 2.65% and 3.85%. The symbol rate remains fixed on the DVB-S2 downstream. Variation in throughput is realized through DVB-S2 support, and the variation of MODCODs in ACM Mode. The maximum possible throughput of the DVB-S2 carrier (calculated at 45 Msym/s and highest MODCOD 16APSK 8/9) is approximately 155 Mbps. Multiple protocol processors may be required to support high traffic to multiple remotes.

Technical Reference Guide iDX Release 3.3

9

DVB-S2 in iDirect

iDirect uses DVB-S2 “Generic Streams” with a proprietary variation of the LEGS (Lightweight Encapsulation for Generic Streams) protocol for encapsulation of downstream data between the DVB-S2 line cards and remotes. LEGS maximizes the efficiency of data packing into BBFRAMES on the downstream. For example, if a timeplan only takes up 80% of a BBFRAME, the LEGS protocol allows the line card to include a portion of another packet that is ready for transmission in the same frame. This results in maximum use of the downstream bandwidth.

ACM Operation Adaptive Coding and Modulation (ACM) allows remotes operating in better signal conditions to receive data on higher MODCODs by varying the MODCOD of data targeted to each remote to match its current receive capabilities. Not all data is sent to each remote at its most efficient MODCOD. Important system information (such as timeplan messages), as well as broadcast traffic, is transmitted at the minimum MODCOD configured for the outbound carrier. This allows all remotes in the network, even those operating at the worst MODCOD, to receive this information reliably. The protocol processor determines the maximum MODCOD for all data sent to the DVB-S2 line card for transmission over the outbound carrier. However, the line card does not necessarily respect these MODCOD assignments. In the interest of downstream efficiency, some data scheduled for a high MODCOD may be transmitted at a lower one as an alternative to inserting padding bytes into a BBFRAME. When assembling a BBFRAME for transmission, the line card first packs all available data for the chosen MODCOD into the frame. If there is space left in the BBFRAME, and no data left for transmission at that MODCOD, the line card attempts to pack the remainder of the frame with data for higher MODCODs. This takes advantage of the fact that a remote can demodulate any MODCOD in the range between the carrier’s minimum MODCOD and the remote’s current maximum MODCOD. The maximum MODCOD of a remote is based on the latest Signal-to-Noise Ratio (SNR) reported by the remote to the protocol processor. The 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 page 11. 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 Guide iDX Release 3.3

DVB-S2 in iDirect

Figure 2-2 and Figure 2-3 show the operation of the SNR feedback loop and the behavior of the line card and remote during fast fade conditions. Figure 2-2 shows the basic SNR reporting loop described above. Protocol Processor Incoming user data

Tx Line Card Downstream throughput (varies based on MODCOD assigned )

New MODCOD

Remote

internal queue

SNR compared to SNR threshold: new MODCOD selected

Rx Line card SNR measured and reported to PP

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

Protocol Processor

New MODCOD

Tx Line Card

Incoming user data

Downstream throughput (varies based on MODCOD assigned)

Reduction in downstream data Tx ine card queue too full? Allocate less user data SNR compared to SNR threshold: New MODCOD selected

Tx line card reports internal queue fullness to PP

Remote

internal queue

Rx Line Card SNR measured and reported to PP

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

Technical Reference Guide iDX Release 3.3

11

DVB-S2 in iDirect

Quality of Service in DVB-S2 ACM Networks iDirect QoS for DVB-S2 downstream carriers is basically identical to QoS for fixed MODCOD downstream carriers. (See QoS Implementation Principles on page 47.) However, with DVB-S2 in ACM Mode, the same amount of user data (in bits per second) occupies more or less downstream bandwidth, depending on the MODCOD at which it is transmitted. This is true because user data transmitted at a higher MODCOD requires less bandwidth than it does at a lower MODCOD. When configuring QoS in iBuilder, a Network Operator can define a Maximum Information Rate (MIR) and/or a Committed Information Rate (CIR) at various levels of the QoS tree. (See the iBuilder User Guide for definitions of CIR and MIR.) For an ACM outbound, the amount of bandwidth granted for a configured CIR or MIR is affected by both the MODCOD that the remote is currently receiving and a number of parameters configurable in iBuilder. The remainder of this section discusses the various parameters and options that affect DVB-S2 bandwidth allocation and how they affect the system performance.

Remote Nominal MODCOD The Network Operator can configure a Nominal MODCOD for DVB-S2 remotes operating in ACM mode. The Nominal MODCOD is the Reference Operating Point (ROP) for the remote. By default, a remote’s Nominal MODCOD is equal to the DVB-S2 carrier’s Maximum MODCOD. The Nominal MODCOD is typically determined by the link budget but may be adjusted after the remote is operational. In a fixed network environment, the Nominal MODCOD is typically chosen to be the Clear Sky MODCOD of the remote. In a 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 Remote’s Nominal MODCOD. The remote is allowed to operate at MODCODs higher than the Nominal MODCOD (as long as it does not exceed the configured Remote Maximum MODCOD described below), but is not granted additional higher CIR or MIR when operating above the Nominal MODCOD.

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

12

Technical Reference Guide iDX Release 3.3

DVB-S2 in iDirect

Fixed Bandwidth Operation During a rain fade, the CIR or MIR granted to a remote are scaled down based on the remote’s Nominal MODCOD. This provides a graceful degradation of CIR and MIR during the fade while consuming the same satellite bandwidth as at the Nominal MODCOD. Figure 2-4 shows the system behavior when operating in Fixed Bandwidth Mode. The remote’s Nominal MODCOD is labeled Nominal @ ClearSky in the figure. In the example, the remote has been configured with 256 kbps of CIR and a Nominal MODCOD of 8PSK 3/5. If the remote operates at a higher MODCOD, it is not granted a higher CIR. When the remote enters a rain fade, the allocated bandwidth remains fixed at the Nominal MODCOD bandwidth. The degradation in throughput is gradual because the remote continues to use the same amount of satellite bandwidth that was allocated for its Nominal MODCOD.

Figure 2-4. Total Bandwidth vs. Information Rate in Fixed Bandwidth Operation

Enhanced Information Rate As noted above, the occupied bandwidth for CIR or MIR varies per MODCOD. If, when allocating downstream bandwidth for a remote, the system always attempted to meet these rates regardless of MODCOD, then a remote in a deep rain fade may be granted a disproportionate share of bandwidth at the expense of other remotes in the network. On the other hand, if CIR and MIR settings were only honored at the remote’s Nominal MODCOD (Fixed Bandwidth Mode), then there would be no option to increase the bandwidth to satisfy the requested information rate when a remote dropped below its Nominal MODCOD. The “Enhanced Information Rate” (EIR) option allows 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 iDX Release 3.3

13

DVB-S2 in iDirect

EIR is only enabled in the range of MODCODs from the remote’s Nominal MODCOD down to the configured EIR Minimum MODCOD. Within this range, the system always attempts to allocate requested bandwidth in accordance with the CIR and MIR settings, regardless of the current MODCOD at which the remote is operating. Since higher MODCODs contain more information bits per second, as the remote’s MODCOD increases, so does the capacity of the outbound channel to carry additional information. As signal conditions worsen, and the MODCOD assigned to the remote drops, the system attempts to maintain CIR and MIR only down to the configured EIR Minimum MODCOD. If the remote drops below this EIR Minimum MODCOD, it is allocated bandwidth based on the remote’s Nominal MODCOD with the rate scaled to the MODCOD actually assigned to the remote. The net result is that the remote receives the CIR or MIR as long as the current MODCOD of the remote does not fall below the EIR Minimum MODCOD. Below the EIR minimum MODCOD, the information rate achieved by the remote falls below the configured settings. The system behavior in EIR mode is shown in Figure 2-5. The remote’s Nominal MODCOD is labeled “Nominal” in the figure. The system maintains the CIR and MIR down to the EIR Minimum MODCOD. Notice in the figure that when the remote is operating below EIR Minimum MODCOD, it is granted the same amount of satellite bandwidth as at the remote’s Nominal MODCOD.

Figure 2-5. EIR: Total Bandwidth vs. Information Rate as MODCOD Varies

14

Technical Reference Guide iDX Release 3.3

DVB-S2 in iDirect

Scaling Factors for Fixed Bandwidth Allocation Table 2-2 shows the scaling factors that can be used to calculate the information rate at different MODCODs when the allocated bandwidth is held constant at the remote’s Nominal MODCOD. This happens both in Fixed Bandwidth Mode or in EIR Mode when the remote’s MODCOD falls below the EIR Minimum MODCOD. Table 2-2. ACM MODCOD Scaling Factors MODCOD

Scaling Factor

Comments

16APSK 8/9

1.2382

Best MODCOD

16APSK 5/6

1.3415

16APSK 4/5

1.4206

16APSK 3/4

1.5096

16APSK 2/3

1.6661

8PSK 8/9

1.6456

8PSK 5/6

1.7830

8PSK 3/4

2.0063

8PSK 2/3

2.2143

8PSK 3/5

2.4705

QPSK 8/9

2.4605

QPSK 5/6

2.6659

QPSK 4/5

2.8230

QPSK 3/4

2.9998

QPSK 2/3

3.3109

QPSK 3/5

3.6939

QPSK 1/2

5.0596

QPSK 2/5

5.6572

QPSK 1/3

6.8752

QPSK 1/4

12.0749

Worst MODCOD

The following formula can be used to determine the information rate at which data is sent when that data is scaled to the remote’s Nominal MODCOD: IRa = IRn x Sb / Sa where: • • • •

IRa is the actual information rate at which the data is sent IRn is the nominal information rate (for example, the configured CIR) Sb is the scaling factor for the remote’s Nominal MODCOD Sa is the scaling factor for the MODCOD at which the data is sent

Technical Reference Guide iDX Release 3.3

15

DVB-S2 in iDirect

For example, assume that a remote is configured with a CIR of 1024 kbps and a Nominal MODCOD of 16ASPK 8/9. If EIR is not in effect, and data is being sent to the remote at MODCOD QPSK 8/9, then the resulting information rate is: IRa = IRn x Sb / Sa IRa = 1024 kbps x 1.2382 / 2.4605 = 515 kbps For two scenarios showing how CIR and MIR are allocated for a DVB-S2 network in ACM mode, see page 68 and page 70. NOTE: When bandwidth is allocated for a remote, the CIR and MIR are scaled to the remote’s Nominal MODCOD. At higher levels of the Group QoS tree (Bandwidth Group, Service Group, etc.) CIR and MIR are scaled to the network’s best MODCOD.)

Bandwidth Allocation Fairness There are three configurable options for bandwidth allocation fairness: •

Allocation Fairness Relative To CIR

•

Allocation Fairness Relative to Nominal MODCOD

•

Allocation Fairness Relative to Operating MODCOD

Enabling or disabling any of these options for a Group QoS node or for a physical remote affects how CIR and MIR bandwidth is apportioned during bandwidth contention. Allocation Fairness Relative to MODCOD only affects bandwidth allocation on DVB-S2 ACM outbound carriers. Allocation Fairness Relative to CIR affects bandwidth allocation in general. For a detailed explanation of these options, see the Quality of Service chapter in the iBuilder User Guide. For sample scenarios illustrating the use of these options, see Bandwidth Allocation Fairness Relative to CIR on page 71 and Bandwidth Allocation Fairness Relative to MODCOD on page 72.

DVB-S2 Configuration Various iBuilder settings affect the operation of DVB-S2 networks. For details on configuring DVB-S2, see the iBuilder User Guide. The following areas are affected: •

Downstream Carrier Definition: When adding an ACM DVB-S2 downstream carrier, the Network Operator must specify a range of MODCODs over which the carrier will operate. Error correction for the carrier is fixed to LDPC and BCH. In addition, iBuilder does not allow selection of an information rate or transmission rate for a DVB-S2 carrier as an alternative to the symbol rate, since these rates vary dynamically with changing MODCODs. However, iBuilder provides a MODCOD Distribution Calculator that estimates the overall Information Rate for the carrier based on the distribution of the Nominal MODCODs of the remotes in the network. Access this calculator by clicking the MODCOD Distribution button on the DVB-S2 Downstream Carrier dialog box. A similar calculator allows estimation of CIR and MIR bandwidth requirements at various levels of the Group QoS tree.

16

Technical Reference Guide iDX Release 3.3

DVB-S2 in iDirect

•

Multicast MODCOD: By default, all multicast data on an ACM downstream carrier is transmitted at the lowest MODCOD of the carrier. The Network Operator can configure different MODCODs for user multicast traffic by selecting Multicast MODCODs for Multicast Applications in iBuilder. See the Quality of Service chapter of the iBuilder User Guide for details.

•

Remote Nominal MODCOD and Remote Maximum MODCOD. These remote parameters are discussed in detail at the beginning of this section. These parameters are configured on the Remote QoS tab in iBuilder.

•

DVB-S2 Line Card Definition: When adding a DVB-S2 line card, the Network Operator must configure a second IP port (called the GIG0 port) in addition to the management IP port. All data to be transmitted on the DVB-S2 downstream carrier is sent to this port.

•

DVB-S2 Network-Level Parameters: DVB-S2 network-level parameters control how a DVBS2 network reacts to fade conditions when ACM is enabled for the downstream carrier.

DVB-S2 Performance Monitoring iMonitor allows a Network Operator to monitor the following characteristics of DVB-S2 outbound carriers: •

ACM Gain represents the increase in performance achieved on a DVB-S2 outbound carrier when the MODCOD used to transmit data is higher than the minimum MODCOD configured for the carrier. ACM Gain can be monitored at the Network, Inroute Group, Remote and Tx Line card levels of the iMonitor tree.

•

The Network Operator can examine how the downstream data is distributed across the range of MODCODs configured for an ACM carrier. MODCOD distribution can be monitored at the Network, Remote and Tx Line Card levels of the iMonitor tree.

•

In an ACM network, each DVB-S2 remote periodically reports its current Signal-to-Noise Ratio (SNR) to the protocol processor. Based on the remote’s last-reported SNR, the protocol processor determines the maximum MODCOD at which the remote can receive data. Remote SNR can be monitored at the Network, Inroute Group, and Remote levels of the iMonitor tree.

•

A DVB-S2 line card keeps detailed statistics for traffic that is sent from the protocol processor to the line card and then transmitted by the line card on the DVB-S2 outbound carrier. DVB-S2 hub line card debug statistics can be monitored at the Tx Line Card level of the iMonitor tree.

•

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 remote’s 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 iDX Release 3.3

17

DVB-S2 in iDirect

18

Technical Reference Guide iDX Release 3.3

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

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

DVB-S2 Modulation Modes and FEC Rates Beginning with iDX Release 3.2, all downstream carriers in iDirect networks conform to the DVB-S2 standard. iNFINITI downstream carriers (and iNFINITI hardware) are no longer supported. Therefore, in this release, only Evolution line cards in DVB-S2 mode can be used to transmit downstream carriers. Similarly, only Evolution remotes in DVB-S2 mode can receive downstream carriers. iDirect supports QPSK, 8PSK and 16APSK modulation modes for DVB-S2 downstream carriers. All supported DVB-S2 MODCODs (including FEC rates) are listed in Table 2-1 on page 8. iDirect’s DVB-S2 implementation is described in DVB-S2 in iDirect Networks on page 7.

2D 16-State Inbound Coding for DVB-S2 Networks iDirect supports 2D 16-State Inbound Coding on upstream TDMA and SCPC carriers in DVB-S2 networks. 2D 16-State Coding is extremely efficient inbound coding that provides maximum flexibility to network designers. 2D 16-State Coding supports three payload sizes: 100 bytes (88 byte IP payload), 170 bytes (158 byte IP payload), and 438 bytes (426 byte IP payload). The 100 byte payload size has a 16 byte larger payload than the QPSK .66 1K TPC block supported in earlier releases. This ensures the same low latency at call connection for VoIP applications. The 438 byte payload size is

Technical Reference Guide iDX Release 3.3

19

TDMA Waveform Enhancements

similar to the 4k TPC block and provides low TDMA overhead. The 170 byte payload size provides an intermediate option when considering the trade off between bandwidth granularity and minimizing TDMA overhead. 2D 16-State Coding has a number of benefits when compared to TPC and LDPC coding: •

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

•

Efficiency gains on average of 1 dB

•

Cost savings from the use of smaller antenna and BUC sizes

•

Easy implementation since no new network design is required

2D 16-State Coding supports easy mapping of TPC to 2D 16-State configurations. For example, the QPSK 2D16S-100B-3/4 offers similar performance and better spectral efficiency than the TPC QPSK 1k block with .66 FEC. NOTE: Because 2D 16-State coding is superior to TPC, TPC inbound coding is no longer supported in iDirect networks. The Link Budget Analysis Guide defines all upstream Modulation and Coding rates available per payload size when using 2D 16-State Inbound Coding over TDMA and SCPC upstream carriers. The LBA Guide also specifies EbN0 values and C/N thresholds for all upstream MODCOD/block size combinations. See the LBA Guide sections “Upstream TDMA Carrier Performance Specifications” and “Upstream SCPC Carrier Performance Specifications” for details.

TDMA Waveform Enhancements The iDirect TDMA burst formats are optimized on an ongoing basis in order to reduce overhead, to increase the tolerance to imperfections and channel effects, and to improve demodulation performance. Improvements in the state-of-the-art signal processing algorithms and increases in processing power are exploited to provide performance improvements over time. The TDMA burst formats used prior to iDX Release 3.2 can be summarized as follows: •

Non-spread BPSK and QPSK bursts consist of a known preamble followed by data-bearing symbols.

•

8PSK bursts consist of a preamble, followed by three blocks of data-bearing symbols. "Mid-ambles" of known symbols are present between the first and second data symbol block, and between the second and third data symbol block.

•

Spread Spectrum bursts are similar to 8PSK non-spread bursts in terms of the distribution of known symbols. Direct-sequence spreading is applied to the complete burst.

The payload of each burst consists of one code word of a 16-state, parallel-concatenated code referred to as 2D 16-State Code as discussed on page 19. 2D 16-State is a very high performance code. With perfect synchronization, it is generally within 0.6 dB to 0.7 dB of the theoretical bounds specified by the block size, coding rate, and modulation type. The 2D 16State code performance has been optimized for all block sizes supported by iDirect: 100 bytes, 170 bytes, and 438 bytes. Beginning in iDX Release 3.2 the waveform formats for BPSK, QPSK and 8PSK employ the Distributed Pilot TDMA (DP-TDMA) scheme to improve demodulator synchronization accuracy.

20

Technical Reference Guide iDX Release 3.3

TDMA Waveform Enhancements

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

Pilot Blk 1

Payload Blk 1

Pilot Blk 2

Payload Blk 2

Pilot Blk 3

Payload Blk Np

Pilot Blk Np

Payload Blk n+1

Lgd

Lp

L1

Lp

L1

Lp

L1

Lp

L2

Figure 3-1. TDMA Burst Format with Distributed Pilots Highlights of performance improvements that were introduced in iDX Release 3.2 with this new waveform structure include: •

Support for several 2D 16-State coding rates for each Modulation and Block size. This provides more granularity in C/N dynamic range for both homogenous inroute groups of static carriers and inroute groups using Adaptive TDMA.

•

C/N Performance improvement up to 1.5 dB or equivalent spectral efficiency in certain combinations of modulation, coding rates and block sizes. Refer to the Link Budget Analysis Guide for performance specifications.

•

Frequency tolerance of up to 1.5% of the symbol rate across all modulations

•

Improved TDMA burst detection performance

Technical Reference Guide iDX Release 3.3

21

guard

TDMA Waveform Enhancements

22

Technical Reference Guide iDX Release 3.3

4 iDirect Spread Spectrum Networks This chapter provides information about Spread Spectrum technology in iDirect networks. It contains the following major sections: •

Overview of Spread Spectrum on page 23

•

Spread Spectrum Hardware Components on page 24

•

Supported Forward Error Correction (FEC) Rates on page 24

•

TDMA Upstream Specifications on page 25

•

SCPC Upstream Specifications on page 25

Overview of Spread Spectrum Spread Spectrum is a transmission technique in which a pseudo-noise (PN) code is employed as a modulation waveform to “spread” the signal energy over a bandwidth much greater than the signal information bandwidth. The signal is “despread” at the receiver by using a synchronized replica of the pseudo-noise code. By spreading the signal information over greater bandwidth, less power density is required. A sample Spread Spectrum network diagram is shown in Figure 4-1.

Figure 4-1. Spread Spectrum Network Diagram Spreading takes place when the input data (dt) is multiplied with the PN code (pnt) which results in the transmit baseband signal (txb). The baseband signal is then modulated and transmitted to the receiving station. Despreading takes place at the receiving station when the baseband signal is demodulated (rxb) and correlated with the replica PN (pnr) which results in the data output (dr).

Technical Reference Guide iDX Release 3.3

23

Spread Spectrum Hardware Components

Spread Spectrum is employed in iDirect networks to minimize adjacent satellite interference (ASI). ASI can occur in applications such as Comms-On-The-Move (COTM) because the small antennas (typically sub-meter) used on mobile vehicles have a small aperture size, large beam width, and high pointing error which can combine to cause ASI. Enabling Spread Spectrum reduces the spectral density of the transmission so that it is low enough to avoid interfering with adjacent satellites. iDirect designed the Spread Spectrum feature for COTM and ASI mitigation on very small aperture terminals. Although this feature may be useful for other applications such as overpowering interference or hiding carriers from hostile jammers, customers should consult with iDirect sales engineering to ensure that their specific application is appropriate for this technology. iDirect Spread Spectrum is an extension of BPSK modulation. The feature is supported on TDMA and SCPC upstream carriers. Spread spectrum is not available on DVB-S2 downstream carriers. The signal is spread over wider bandwidth according to a Spreading Factor (SF) selected for the carrier in iBuilder. For an SCPC upstream carrier, the Network Operator can select No Spreading, 2, 4 or 8. For a TDMA upstream carrier, the Network Operator can select No Spreading, 2, 4, 8 or 16. SF 16 is only supported for Evolution e8350, iConnex e800/e850mp remotes. NOTE: Only Spreading Factor 2 is supported for Evolution e150 remotes. Each symbol in the spreading code is called a “chip.” The spread rate is the rate at which chips are transmitted. For example, selecting No Spreading means that the spread rate is one chip per symbol (which is equivalent to regular BPSK). Selecting a Spreading Factor of 4 means that the spread rate is four chips per symbol. NOTE: The following model types require an iDirect licence to use the upstream Spread Spectrum feature: Evolution XLC-11 line cards; Evolution X5, and X7 remotes.

Spread Spectrum Hardware Components The following iDirect line card model types can receive Spread Spectrum carriers: •

Evolution eM1D1 (No license required; TDMA or SCPC return)

•

Evolution XLC-11 (License required; TDMA only)

The following iDirect remote model types can transmit Spread Spectrum carriers: •

Evolution e8350, iConnex e800/e850mp (No license required; TDMA or SCPC return)

•

Evolution X5 (License required; TDMA only; Spreading Factors 2, 4 and 8)

•

Evolution X7 (License required; TDMA only; Spreading Factors 2, 4 and 8)

•

Evolution e150 (No license required; TDMA only; Spreading Factor 2 only)

Supported Forward Error Correction (FEC) Rates The upstream FEC rates that can be used for Spread Spectrum carriers in this release are specified in the Link Budget Analysis Guide.

24

Technical Reference Guide iDX Release 3.3

TDMA Upstream Specifications

TDMA Upstream Specifications The Spread Spectrum specifications for TDMA upstream transmissions are defined in Table 4-1. Table 4-1. Spread Spectrum: TDMA Upstream Specifications PARAMETERS

VALUES

ADDITIONAL INFORMATION

Modulation

BPSK

Other Modulations not supported

Spreading Factor

No Spreading, 2, 4, 8 or 16

SF = 2 only for e150 remotes SF = 16 restricted to e8350, e800 and e850mp

Symbol Rate

64 ksym/s - 7.5 Msym/s

Chip Rate

7.5 Mchip maximum

BER Performance

Refer to the iDirect Link Budget Analysis Guide

Maximum Frequency Offset

1.5% * Fsym

Unique Word Overhead

128 symbols

Occupied Bandwidth

1.2 * Chip Rate

Hardware Platforms

Evolution e8350, e800, e850mp, X5, X7, e150

SCPC Upstream Specifications The Spread Spectrum specifications for SCPC upstream transmissions are defined in Table 4-2. Table 4-2. Spread Spectrum: SCPC Upstream Specifications PARAMETERS

VALUES

Modulation

BPSK

Spreading Factor

No Spreading, 2, 4, 8

Symbol Rate

128 ksym/s - 15 Msym/s

Chip Rate

15 Mchip/s maximum

BER Performance

Refer to the iDirect Link Budget Analysis Guide

Occupied BW

1.2 * Chip Rate

Hardware Platforms

Evolution e8350, iConnex e800/e850mp

Technical Reference Guide iDX Release 3.3

ADDITIONAL INFORMATION Other Modulations not supported

25

SCPC Upstream Specifications

26

Technical Reference Guide iDX Release 3.3

5 Multichannel Line Cards

Multichannel Line Cards are receive-only Evolution line cards capable of receiving up to eight upstream carriers simultaneously. A Multichannel Line Card can receive either TDMA upstream carriers or SCPC return channels with appropriate licensing. Evolution XLC-M line cards are capable of simultaneously receiving up to 16 narrowband TDMA upstream carriers of up to 128 ksym per carrier. Beginning with iDX Release 3.2, TRANSEC is supported on eM0DM line cards in multichannel mode.

Multichannel Line Card Model Types There are two iDirect Multichannel Line Card model types: •

Evolution XLC-M

•

Evolution eM0DM

Only XLC-M line cards support up to 16 narrowband TDMA receive carriers. Only eM0DM line cards support TRANSEC. NOTE: Allow for 60 Watts of power for each Multichannel Line Card in a 20 slot chassis. Total available power for each 20 slot chassis model type is specified in the Series 15100 Universal Satellite Hub (5IF/20-Slot) Installation and Safety Manual.

Multichannel Line Card Receive Modes When configuring a Multichannel Line Card in iBuilder, select one of the following receive modes for the line card: •

Single Channel TDMA

•

Multiple Channel TDMA

•

Multiple Channel SCPC NOTE: Single Channel SCPC Mode is only selectable for Evolution eM1D1 line cards. It cannot be selected on multichannel line cards.

Technical Reference Guide iDX Release 3.3

27

Multichannel Line Card Restrictions and Limits

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

Multichannel Line Card Restrictions and Limits The following restrictions apply to Multichannel Line Cards:

28

•

All upstream carriers received by an Evolution XLC-M or eM0DM line card must be the same carrier type. A Multichannel Line Card cannot receive both SCPC and TDMA carriers at the same time.

•

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

•

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

•

TDMA upstream carriers received by a Multichannel Line Card can have different Modulations, FEC Rates, and Symbol Rates. However the Payload Size must be the same for all carriers.

•

The center frequency and symbol rate of an adaptive carrier received by a Multichannel Line Card must remain constant across all Inroute Group Compositions; only the MODCOD of the carrier can change.

•

All TDMA upstream carriers received by a Multichannel Line Card must be on the same transponder and within a 36 MHz window.

•

SCPC upstream carriers received by a Multichannel Line Card can have different Modulations, FEC Rates, and Symbol Rates.

•

All upstream carriers received by Multichannel Line Card must be completely within a 36 MHz operational band, including the “roll off” resulting from the 1.2 carrier spacing. The operational band must fall between 950 MHz and 1700 MHz for an XLC-M line card and between 950 MHz and 2000 MHz for an eM0DM line card. (See Table 5-1.)

•

There are per-carrier symbol rate limits on Multichannel Line Cards for both TDMA and SCPC. (See Table 5-1.)

•

There are composite symbol rate limits on Multichannel Line Cards for TDMA. (See Table 5-1.) The sum of the symbol rates of all return channels received by the line card cannot exceed these limits.

•

There are composite information rate limits on Multichannel Line Cards for both TDMA and SCPC. (See Table 5-1.) The sum of the information rates of all return channels received by the line card cannot exceed these limits.

•

Licenses are required to configure Multichannel Line Cards in TDMA and SCPC multichannel modes for more than one channel. (See the iDirect Features and Chassis Licensing Guide for details.) A license is not required for TDMA single channel receive mode, or to configure a single channel in TDMA or SCPC multichannel mode.

•

Spread Spectrum is not supported on Multichannel Line Cards.

Technical Reference Guide iDX Release 3.3

Multichannel Line Card Restrictions and Limits

Table 5-1 shows various parameters associated with the Multichannel Line Cards. Table 5-1. Multichannel Receive Line Card Parameters

NOTE: For Upstream TDMA and SCPC Modulation Modes and FEC Rates, see Modulation Modes and FEC Rates on page 19. The iBuilder User Guide contains procedures for configuring Multichannel Line Cards.

Technical Reference Guide iDX Release 3.3

29

Multichannel Line Card Restrictions and Limits

30

Technical Reference Guide iDX Release 3.3

6 SCPC Return Channels

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

Hardware Support and License Requirements This section lists the iDirect remote and line card model types capable of transmitting and receiving an SCPC return channel and the licenses required per unit. The following remote model types can transmit a dedicated SCPC return channel to the hub: •

Evolution e8350, iConnex e800/e850mp (No license required)

•

Evolution X3 (No license required)

•

Evolution X5 (No license required)

The following line card model types can receive SCPC return channels: •

Evolution eM1D1 (Single channel, Rx-only; No license required)

•

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

•

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

For more information on iDirect licensing, see the iDirect Features and Chassis Licensing Guide. NOTE: An Evolution eM1D1 line card cannot transmit a downstream carrier and receive an SCPC return channel simultaneously. To configure an eM1D1 to receive an SCPC return channel, the Line Card Type must be set to receive-only. See the iBuilder User Guide for details.

Technical Reference Guide iDX Release 3.3

31

Single Channel vs. Multichannel SCPC Return

Single Channel vs. Multichannel SCPC Return Table 6-1 shows the differences and similarities between single channel and multichannel SCPC return modes. As shown in the table, single channel SCPC return mode is only available on Evolution eM1D1 line cards. Single channel SCPC supports higher symbol rates per channel than multichannel SCPC. In addition, single channel SCPC supports Spread Spectrum while multichannel SCPC does not. Table 6-1. Single Channel vs. Multichannel SCPC Single Channel SCPC

Multichannel SCPC

Line Card Support

eM1D1

eM0DM, XLC-M

Line Card Type

Rx-only (No Tx/Rx)

Rx-only

Symbol Rate Limit (per channel)

128 ksym to 15 Msym

128 ksym - 11.75 Msym

Composite Information Rate

N/A

40 Mbps (maximum)

Spread Spectrum

Spreading Factors 2, 4, 8 15 Mchip/s (maximum)

Not supported

NOTE: SCPC upstream carriers received by a multichannel line card can have different symbol rates, modulation modes and FEC rates. For more information on multichannel SCPC return, see Multichannel Line Cards on page 27. NOTE: For supported 2D 16-State Inbound Coding Modulation Modes, FEC Rates and Block sizes see the Link Budget Analysis Guide.

SCPC Return Feature on Remotes For remotes that support SCPC return, the firmware images for both SCPC and TDMA are contained in the same download package. Therefore, there is no need to reload the remote packages to switch remotes between TDMA and SCPC. However, when switching from one carrier type to another, the remote must be reset after the configuration changes are applied. Typically, the remote will be out of the network for approximately 1.5 to 2 minutes when switching between TDMA and SCPC. Upstream QoS on an SCPC remote is configured by assigning a Remote Profile directly to the remote. Because an SCPC remote has the full use of the upstream carrier, there is no upstream bandwidth contention among SCPC remotes. Remote Profiles are used to apportion the available bandwidth among the applications on the remotes. For details, see the section titled “Assigning an Upstream Profile to an SCPC Remote” in the iBuilder User Guide. NOTE: To conserve bandwidth, QoS Service Level statistics are available in iMonitor by custom key only. See the section titled “Viewing Service Level Statistics” in the iMonitor User Guide for details. The Move operation in the iBuilder tree allows the Network Operator to switch a remote between TDMA and SCPC. During the move, select the SCPC line card and channel or the

32

Technical Reference Guide iDX Release 3.3

VNO for SCPC Return

TDMA Inroute Group to which the remote is moving as well as the appropriate QoS profile for the new configuration. For details, see “Moving Remotes Between Networks, Inroute Groups, and Line Cards” in the iBuilder User Guide. The initial transmit power and maximum transmit power configured for a remote depend on the characteristics of the upstream carrier. Therefore, the values configured for these parameters will be different for TDMA and SCPC, and they will vary for SCPC carriers that are not similar. TDMA maximum and initial power and SCPC maximum and initial power (per carrier) are defined separately in iBuilder. This allows easy switching of remotes between TDMA and SCPC and between different SCPC carriers by preconfiguring these power parameters for any SCPC carriers that the remote will transmit. NOTE: When a remote is moved to an SCPC carrier that does not have the initial and maximum power values preconfigured for that carrier, the remote becomes incomplete in iBuilder. If this happens, configure the power settings on the remote for that carrier for the remote to become operational. See “Adding Remotes” in the iBuilder User Guide for details on configuring TDMA and SCPC initial and maximum power for a remote in iBuilder. See the Installation and Commissioning Guide for iDirect Satellite Routers for details on determining a remote’s initial and maximum powers.

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

Technical Reference Guide iDX Release 3.3

33

VNO for SCPC Return

34

Technical Reference Guide iDX Release 3.3

7 Adaptive TDMA

Beginning with iDX Release 3.2, iDirect supports Adaptive TDMA. Adaptive TDMA (ATDMA) allows remotes to dynamically adapt their transmissions to the hub to use the optimal symbol rate and Modulation and Coding (MODCOD) for current conditions. This can reduce the amount of rain margin that must be designed into the upstream link, significantly improving clear sky throughput of the remotes when compared to non-adaptive TDMA networks. Eliminating the extent to which system resources must be reserved for worst-case conditions allows additional resources to be used for data transmission. This is the same principle that underlies the use of Adaptive Coding and Modulation (ACM) for DVB-S2 outbound carriers. (See DVB-S2 in iDirect Networks on page 7.)

Theory of Operation The core element of iDirect's adaptive TDMA system is an inroute group of heterogeneous TDMA carriers supporting different transmission rates and providing different levels of protection against adverse channel effects such as rain fade. Individual remotes are assigned time slots on upstream carriers based on their current demand and capability, as determined by the channel state. The configuration of the inroute group automatically adapts over time to maximize the system efficiency. An inroute group can be regarded as a fixed portion of space segment bandwidth and power partitioned into TDMA carriers with different properties. A collection of carrier definitions that can be assigned to an inroute group is called an Inroute Group Composition (IGC). The IGC currently assigned to an inroute group determines the MODCODs of each carrier in the inroute group at the present time. Up to three IGCs can be configured for a single inroute group but only one IGC is assigned to the inroute group at any time. An inroute group can include carriers with different symbol rates and MODCODs. The IGC currently assigned to the inroute group defines the MODCODs of the various carriers in the group. An adaptive carrier can change MODCODs from one IGC to another. When a new IGC is assigned to the Inroute Group, the MODCODs of the individual adaptive carriers change according to the newly-applied IGC definition. Note however that the symbol rates and center frequencies of the individual carriers remain the same in all IGCs. The MODCODs of the upstream carriers do not vary frame by frame. The protocol processor assigns TDMA slots on the upstream carriers based on the upstream link conditions of the individual remotes. In the short term, remotes adapt to changing conditions by frequency hopping among carriers with different properties. Over time, the protocol processor may also adjust the configuration of the inroute group by selecting different IGCs as network conditions change. Whenever a different IGC is assigned to the inroute group, the MODCODs of the

Technical Reference Guide iDX Release 3.3

35

Theory of Operation

upstream carriers change to match the configuration of the newly-selected IGC. Thus the system automatically adapts in two ways: frame-by-frame through remote frequency hopping, and longer term by selecting the optimal IGC for the prevailing conditions. Figure 7-1 shows how Adaptive TDMA operates in an iDirect network for a single inroute group.

Remote Terminals

Constraints

Real-time Real-time resource resource management: management: Assign Assign slots slots in in current current composition composition to to remotes, remotes, respecting respecting constraints constraints on on the the carriers carriers they theyy can can use use

Contention level

Short-term Short-term adaptivity: adaptivity: Determine Determine which which remotes remotes can can use use which which carriers carriers in in the the current current Inroute Inroute Group Group Composition Comp position

Inroute Group Composition 1

Compositon choice

Medium-term Medium-term adaptivity: adaptivity: Select Select best best among among defined defined Inroute Inroute Group Group Compositions Compositions

Statistics

Long-term adaptivity: adaptivity: Long-term Design most most suitable suitable set set of of Inroute Inroute Design Group Compositions Compositions Group

Bandwidth Requests

Power, signal quality

Inroute Group Composition 2

Inroute Group Composition 3

Figure 7-1. Control Elements of iDirect’s ATDMA System The following sections discuss the Adaptive TDMA control elements shown in Figure 7-1.

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

36

Technical Reference Guide iDX Release 3.3

Theory of Operation

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

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

Update Interval: The frequency (in seconds) with which the IGC selection algorithm is executed. The default is 60 seconds.

Technical Reference Guide iDX Release 3.3

37

Theory of Operation

•

Fixed IGC: If the Network Operator selects Enable Fixed IGC, then a specific IGC must be selected as the Fixed IGC. In that case, the IGC selection algorithm is not executed.

•

Allowed Dropout Fraction: During the trial scheduling of an IGC executed as part of the IGC selection process, the algorithm calculates the number of remotes that theoretically would drop out of the network if that IGC is selected for the inroute group. If the algorithm estimates that the percentage of remotes unable to sustain transmissions on the most protected carrier of the IGC would exceed the configured Allowed Dropout Fraction, then that IGC is not selected. If the Allowed Dropout Fraction is exceeded for all IGCs, the default IGC is selected for the inroute group. Note that remotes are never dropped explicitly as a result of this assessment. Remotes are only dropped if they fail to maintain the link during operation.

•

Default IGC: The IGC that is selected if the Allowed Dropout Fraction is exceeded for all IGCs defined for the inroute group. NOTE: A severe downlink fade is observed at the hub as simultaneous fading of all remotes. iDirect recommends including a very robust IGC among those defined for the inroute group to allow the system to operate during a severe downlink fade.

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

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

38

Technical Reference Guide iDX Release 3.3

Adaptive TDMA Configuration and Constraints

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

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

Technical Reference Guide iDX Release 3.3

39

Adaptive TDMA Configuration and Constraints

Adaptive carriers. An upstream carrier assigned to any other type of single channel line card must be static. That is, the MODCOD of the carrier received by the line card cannot change from one IGC to another. The following constraints apply to the configuration of inroute groups and TDMA upstream carriers: •

Only upstream carriers assigned to eM0DM, XLC-M, or receive-only eM1D1 line cards can be configured as Adaptive. All other upstream carriers must be static.

•

The upstream carrier Payload Block Size configured in iBuilder must be the same for all carriers defined for any inroute group and in all IGCs.

•

A maximum of three IGCs can be configured for an inroute group.

•

All inroute groups have at least one IGC even if no Adaptive carriers are included.

•

To define multiple IGCs, an inroute group must have at least one Adaptive carrier.

•

For each carrier, the center frequency and symbol rate must be the same for all IGCs.

•

A different MODCOD can be selected for each Adaptive carrier in each IGC.

•

Spread Spectrum carriers must be Static. (The MODCOD must be the same for all IGCs.) NOTE: TRANSEC carriers can be adaptive.

Table 7-1 shows an example of an inroute group containing four upstream carriers and three Inroute Group Compositions. Table 7-1. Sample Adaptive Inroute Group Configuration Carrier ID

Static / Adaptive

Center Frequency (MHz)

Symbol Rate (ksym/s)

IGC1

IGC2

IGC3

A1

Adaptive

1300.000

1024

8PSK 2/3

8PSK 2/3

QPSK 3/4

A2

Adaptive

1301.229

1024

8PSK 2/3

8PSK 2/3

QPSK 2/3

A3

Adaptive

1302.150

512

8PSK 6/7

8PSK 2/3

8PSK 2/3

S1

Static

1302.611

256

QPSK 1/2

QPSK 1/2

QPSK 1/2

The first three carriers (A1, A2 and A3) in Table 7-1 are Adaptive; the fourth carrier (S1) is Static. Notice that the center frequency and symbol rate of each carrier remain constant across all compositions. The MODCODs of the Adaptive carriers vary from IGC to IGC. The MODCOD of the Static carrier is the same for all IGCs. The example in Table 7-1 was designed for Ku band in the Amazon rain forest.

40

Technical Reference Guide iDX Release 3.3

Adaptive TDMA Configuration and Constraints

Remote Configuration A number of parameters affect Adaptive TDMA operations for individual remotes. These parameters are described in this section.

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

Remote Carrier Constraint Parameters Carrier constraint parameters for individual remotes are configured on the iBuilder Remote QoS tab. These parameters include: •

Minimum Symbol Rate: The minimum symbol rate (in ksym/s) of any upstream carrier on which this remote is allowed to transmit.

Technical Reference Guide iDX Release 3.3

41

Adaptive TDMA Configuration and Constraints

•

Maximum C/N: The maximum C/N at which a remote is allowed to be received by the hub line card. This parameter is determined at network design. A remote will not be assigned slots on an upstream carrier if transmitting on that carrier would cause it to violate this constraint.

•

Maximum Link Impairment (dB): The maximum amount of fade by this remote that is allowed to influence the IGC selection. If a remote’s fade exceeds its configured Maximum Link Impairment, then the IGC selection algorithm treats the remote as if it were in clear sky conditions. NOTE: Maximum Link Impairment only affects IGC selection. It does not affect the amount of bandwidth allocated to the remote.

42

Technical Reference Guide iDX Release 3.3

8 Multicast Fast Path

Beginning with iDX Release 3.0, iDirect supports the Multicast Fast Path feature. Multicast Fast Path improves multicast throughput, allowing service providers to offer more reliable and higher performing services for organizations that want to expand their use of HD broadcast, IPTV, distance learning, digital signage and other video applications. Beginning with iDX Release 3.2, iDirect has added support for encryption of Multicast Fast Path traffic. The Multicast Fast Path feature is available on all remote model types. The remote model types that can receive encrypted Multicast Fast Path traffic are listed on page 44.

Overview When Multicast Fast Path is enabled for a multicast stream, downstream multicast packets received by a remote are forwarded directly to the Ethernet by the remote firmware. This bypasses software processing on the remote resulting in improved throughput. Multicast traffic that does not use the Fast Path feature is handled by the full software stack and processed as regular data traffic. This limits the maximum aggregate throughput. Using the Multicast Fast Path feature to bypass software processing on the remote results in much higher throughput of multicast traffic. Multicast Fast Path has significantly less impact on total throughput than non-fast path multicast. Therefore, the unicast performance of the remote is much less affected by multicast traffic when Multicast Fast Path is enabled for the multicast stream. There is no requirement to use the Multicast Fast Path feature to transmit user multicast traffic. Multicast implementations from releases that do not support Multicast Fast Path can still be used for downstream multicast traffic. As in prior releases, NMS multicast traffic continues to be transmitted as regular multicast traffic.

Multicast Fast Path Streams A Network Operator can configure Multicast Fast Path streams in iBuilder by adding downstream Multicast Applications on the Group QoS tab for a network and selecting the Multicast Fast Path check box. iDirect supports a maximum of 16 Multicast Fast Path Applications per network. Different QoS Application Profiles can be added for each of the 16 Multicast Fast Path streams, allowing the operator to prioritize and better manage multicast traffic. All downstream multicast packets that match the rules configured for a Multicast Fast Path Application are forwarded to the Ethernet by the remote firmware. This bypasses IGMP

Technical Reference Guide iDX Release 3.3

43

Multicast Fast Path Encryption

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

Multicast Fast Path Encryption Multicast Fast Path traffic can be encrypted on a per-network basis. When enabled, Multicast Fast Path Encryption provides 256 bit AES encryption for all Fast Path multicast packets transmitted on the downstream carrier. Multicast Fast Path Encryption can be enabled for multicast streams received by the following remote model types: •

Evolution X3

•

Evolution X5

•

Evolution X7

•

Evolution e8350/e850mp/e800

Evolution X1 and Evolution e150 remotes support the Multicast Fast Path feature. However, these model types cannot receive encrypted Multicast Fast Path traffic. Note the following points regarding Multicast Fast Path Encryption: •

Link Encryption licenses are required on all Protocol Processor blades that process encrypted Multicast Fast Path traffic.

•

Link Encryption licenses are required for all Evolution X3, X5 and X7 remotes that receive encrypted Multicast Fast Path traffic.

•

Remotes configured as Receive-Only drop all encrypted Multicast Fast Path traffic.

•

NMS multicast and other non-Fast Path multicast packets are not encrypted.

•

If Multicast Fast Path Encryption is enabled for a network, then all non-encrypted multicast traffic is transmitted as non-Fast Path traffic.

•

There is a single Multicast Fast Path Encryption domain per network. All encrypted Multicast Fast Path traffic in a network uses the same encryption / decryption keys.

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

44

Technical Reference Guide iDX Release 3.3

Multicast Fast Path Encryption

Protocol Processor uses the remote’s X.509 public key to individually encrypt the Multicast Fast Path encryption key, ensuring secure transport of the encryption key to the remote. By default, the Multicast Fast Path encryption key is updated every 28 days. Because a remote receives the key after acquisition into the network, it is possible for the remote to miss a key update (also called a “key roll”) and still join the network and receive the latest key. To change the frequency of the Multicast Fast Path encryption key roll, create a network-level custom key in iBuilder as follows: 1. Right-click the network in the iBuilder Tree and select ModifyItem. 2. Click the Custom tab. 3. Enter the following Custom Key: [FASTPATH] dyn_key_update_time_sec = where is the new key update frequency in seconds. 4. Click OK to save the changes. 5. Right-click the network in the iBuilder Tree and select Apply ConfigurationNetwork to download the changes. NOTE: To disable key rolls for the network, set dyn_key_update_time_sec to 0. Multicast Fast Path encryption keys are generated by the samnc process that runs on the Protocol Processor blade responsible for multicast traffic. If the samnc process that generates the keys restarts, or if multicast responsibility moves to a different blade, the blade generates and distributes new keys, and the time to the next key roll is reset.

Technical Reference Guide iDX Release 3.3

45

Multicast Fast Path Encryption

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

Figure 8-1. Enabling Multicast Fast Path Encryption Refer to the section titled “Configuring Remotes for Multicast Fast Path” in the iBuilder User Guide for details on configuring Multicast Fast Path.

Multicast Fast Path Encryption Monitoring Failures to decrypt encrypted Multicast Fast Path packets are reported in iMonitor. The remote generates the Multicast Fast Path Decryption Failed alarm (MCFP_DECRYPT_FAIL) when it drops encrypted Multicast Fast Path packets due to a failed integrity check caused by a bad decryption key. The remote automatically clears this alarm after it successfully decrypts two consecutive encrypted Multicast Fast Path packets. Failure to decrypt Multicast Fast Path packets also results in the following SNMP trap: •

46

rmtMCFPDecryptFail: “Remote unable to decrypt multicast fast path traffic”

Technical Reference Guide iDX Release 3.3

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

Quality of Service (QoS) Quality of Service is defined as the way IP traffic is classified, filtered and prioritized as it flows through the iDirect system.

QoS Measures When discussing QoS, at least four interrelated measures are considered: Throughput, Latency, Jitter, and Packet Loss. This section describes these parameters in general terms, without specific regard to an iDirect network. Throughput. Throughput measures the amount of user data that is received by the end user application. For example, a G729 voice call without additional compression (such as cRTP), or voice suppression, requires a constant 24 Kbps of application-level RTP data to achieve acceptable voice quality for the duration of the call. Therefore this application requires 24 Kbps of throughput. When adequate throughput cannot be achieved on a continuous basis to support a particular application, QoS can be adversely affected. Latency. Latency measures the amount of time between events. Unqualified latency is the amount of time between the transmission of a packet from its source and the receipt of that packet at the destination. If explicitly qualified, it may also mean the amount of time between a request for a network resource and the time when that resource is received. In general, latency accounts for the total delay between events and it includes transit time, queuing, and processing delays. Keeping latency to a minimum is very important for Voice Over IP (VoIP) applications for human factor reasons. Jitter. Jitter measures the variation of latency on a packet-by-packet basis. Referring to the G729 example again, if voice packets (containing two 10 ms voice samples) are transmitted every 20 ms from the source VoIP equipment, ideally those voice packets arrive at the destination every 20 ms; this is a jitter value of zero. When dealing with a packet-switched network, zero jitter is particularly difficult to guarantee. To compensate for this, all VoIP

Technical Reference Guide iDX Release 3.3

47

QoS Measures

equipment contains a jitter buffer that collects voice packets and forwards them at the appropriate interval (20 ms in this example). Packet Loss. Packet Loss measures the number of packets that are transmitted by a source, but not received by the destination. The most common cause of packet loss is network congestion. Congestion occurs whenever the volume of traffic exceeds the available bandwidth causing packets to fill queues internal to network devices at a rate faster than those packets can be transmitted from the device. When this condition exists, network devices drop packets to keep the network in a stable condition. Applications that are built on a TCP transport interpret the absence of these packets (and the absence of their related ACKs) as congestion and they invoke standard TCP slow-start and congestion avoidance techniques. With real-time applications, such as VoIP or streaming video, it is often impossible to gracefully recover these lost packets because there is not enough time to retransmit lost packets. Packet loss may affect the application in adverse ways. For example, parts of words in a voice call may be missing or there maybe an echo; video images may break up or become block-like (pixilation effects).

iDirect QoS Profiles The iDirect system allows the Network Operator to define various QoS profiles for upstream and downstream traffic. When they are assigned to remotes, these profiles specify how packets are filtered, scheduled and prioritized as they flow through the network. All profile types are applied to upstream and downstream traffic independently, so that upstream traffic may have one set of QoS definitions, while downstream traffic may have a different set of QoS definitions. QoS Profile types include: •

Application Profile: A group of service levels and rules, collected together and given a user-defined name. Application Profiles are the building blocks for Service Profiles and Remote Profiles used in Group QoS.

•

Filter Profile: A single filter definition, consisting of a set of rules rather than a set of service levels. Filter Profiles are assigned directly to remotes.

•

Service Profile: A set of Applications selected from Application Profiles. Service Profiles are assigned to remotes in Group QoS Application Service Groups.

•

Remote Profile: A set of Applications selected from Application Profiles. Remote Profiles are assigned to remotes in Group QoS Remote Service Groups. Upstream Remote Profiles are also assigned directly to remotes that transmit SCPC return channels.

The relationship between remotes and the various types of QoS Profiles is illustrated in Figure 9-1 on p. 49. See Group QoS on page 57 for a general discussion of Group QoS. For more details on how these profiles are used in the iDirect system and for procedures for configuring QoS profiles, see the chapter titled “Configuring Quality of Service for iDirect Networks” in the iBuilder User Guide.

48

Technical Reference Guide iDX Release 3.3

QoS Measures

Figure 9-1. Remote and QoS Profile Relationships

Technical Reference Guide iDX Release 3.3

49

Classification and Scheduling of IP Packets

Classification and Scheduling of IP Packets This section describes how the iDirect system prioritizes and schedules IP packets for transmission.

Service Levels Each packet that enters the iDirect system is classified into one of the configured Service Levels. A Service Level may represent a single application (such as VoIP traffic from a single IP address) or a broad class of applications (such as all TCP based applications). Each Service Level is defined by one or more packet-matching rules. The set of rules for a Service Level allows logical combinations of comparisons to be made between the following IP packet fields: •

Source IP address

•

Destination IP address

•

Source port

•

Destination port

•

Protocol (such as DiffServ DSCP)

•

TOS priority

•

TOS precedence

•

VLAN ID

Packet Scheduling Packet Scheduling determines the order in which packets are transmitted according to priority and classification. When a remote always has sufficient bandwidth for all of its applications, packets are transmitted in the order that they are received without significant delay. Priority makes little difference since the remote never has to select which packet to transmit next. However, when a remote does not have sufficient bandwidth to transmit all queued packets the remote scheduling algorithm must determine which packet to transmit next from the set of queued packets across a number of service levels. For each service level defined in iBuilder, the Network Operator can select any one of the following queue types to determine how packets using that service level are to be selected for transmission: Priority Queue, Class-Based Weighted Fair Queue (CBWFQ), and Best-Effort Queue. Priority Queues are emptied before CBWFQ queues are serviced; CBWFQ queues are in turn emptied before Best Effort queues are serviced. Figure 9-2 on p. 51 presents an overview of the iDirect packet scheduling algorithm.

50

Technical Reference Guide iDX Release 3.3

Classification and Scheduling of IP Packets

Figure 9-2. iDirect Packet Scheduling Algorithm The packet scheduling algorithm (Figure 9-2) first services packets from Priority Queues in order of priority, P1 being the highest priority for non-multicast traffic. It selects CBWFQ packets only after all Priority Queues are empty. Similarly, packets are taken from Best Effort Queues only after all CBWFQ packets are serviced. A Network Operator can define multiple service levels using any combination of the three queue types. For example, the operator can define a combination of Priority and Best Effort Queues only.

Technical Reference Guide iDX Release 3.3

51

Application Throughput

Priority Queues There are five levels of Priority Queues: •

Multicast: (Highest priority. Only for downstream multicast traffic.)

•

Level 1: P1

•

Level 2: P2

•

Level 3: P3

•

Level 4: P4 (Lowest priority)

All queues of higher priority must be empty before any lower-priority queues are serviced. If two or more queues are set to the same priority level, then all queues of equal priority are emptied using a round-robin selection algorithm prior to selecting any packets from lowerpriority queues.

Class-Based Weighted Fair Queues Packets are selected from Class-Based Weighted Fair Queues for transmission based on the service level (or “class”) of the packet. Each service level is assigned a “cost”. Packet cost is defined as the cost of its service level multiplied by its length. Packets with the lowest cost are transmitted first, regardless of service level. The cost of a service level changes during operation. Each time a queue is passed over in favor of other service levels, the cost of the skipped queue is credited, which lowers the cost of the packets in that queue. Over time, all service levels have the opportunity to transmit at least occasionally even in the presence of higher priority traffic. Assuming there is a continuously-congested link with an equal amount of traffic at each service level, the total bandwidth available is divided more evenly by deciding transmission priority based on each service level cost.

Best Effort Queues Packets in Best Effort queues do not have priority or cost. All packets in these queues are treated equally by applying a round-robin selection algorithm to the queues. Best Effort queues are only serviced if there are no packets waiting in Priority Queues and no packets waiting in CBWFQ Queues.

Application Throughput Application throughput depends on proper classification and prioritization of packets and on proper management of available bandwidth. For example, if a VoIP application requires 16 Kbps and a remote is only given 10 Kbps the application fails regardless of priority, since there is not enough available bandwidth. In iDirect, bandwidth assignment is controlled by the Protocol Processor. As a result of the various network topologies (for example, a shared TDM downstream with a deterministic TDMA upstream), the Protocol Processor has different mechanisms for downstream control versus upstream control. Downstream control of bandwidth is provided by continuously evaluating network traffic flow and assigning bandwidth to remotes as needed. The Protocol Processor assigns bandwidth and controls the transmission of packets for each remote according to the QoS parameters defined for the remote’s downstream.

52

Technical Reference Guide iDX Release 3.3

Application Throughput

Upstream bandwidth is requested continuously with each TDMA burst from each remote. A centralized bandwidth manager integrates the information contained in each request and produces a TDMA burst timeplan which assigns individual bursts to specific remotes. The burst timeplan is produced once per TDMA frame (typically 125 ms or 8 times per second). NOTE: There is a 250 ms delay from the time that the remote makes a request for bandwidth and when the Protocol Processor transmits the burst timeplan to it. iDirect has developed a number of features to address the challenges of providing adequate bandwidth for a given application. These features are discussed in the sections that follow. For information on configuring these features and for a discussion of additional QoS properties, see the chapter titled, “Configuring Quality of Service for iDirect Networks” of the iBuilder User Guide.

Minimum Information Rate Minimum Information Rate is upstream bandwidth allocated to a remote that is guaranteed even when the remote does not need the capacity. By default, a remote is granted a single slot per TDMA frame. This value can be changed by defining a new Minimum Information Rate for the remote on the iBuilder Remote QoS tab. Minimum Information Rate is the highest priority bandwidth. It can only be configured in the upstream direction. The downstream does not need or support the concept of a Minimum Information Rate. Increasing this value above one slot per frame is inefficient because slots are wasted if the remote is inactive. No other remote can be granted these slots unless the remote with the Minimum Information Rate has not acquired the network. It is possible to configure a remote’s upstream Minimum Information Rate to be less than one burst per TDMA frame. This allows many remotes to be “packed” into a single upstream but also increases the remote’s ramp latency. (Ramp latency is the amount of time it takes a remote to acquire the bandwidth necessary to begin transmitting incoming packets.) The lower the Minimum Information Rate, the fewer TDMA timeplans contain a burst dedicated to the remote, and the greater the ramp latency. Some applications may be sensitive to ramp latency resulting in a poor user experience if the delay is noticeable. iDirect recommends that this feature be used with care. Beginning with iDX Release 3.1, iBuilder allows a Network Operator to configure Minimum Information Rates for remotes below the limit of one slot every two seconds that was supported in previous releases. However, if the configured Minimum Information Rate is not supported by the network or the iDirect hardware, remotes may drop out of the network. See page 92 for more information and for recommendations on setting the Minimum Information Rate for remotes. Also beginning with iDX Release 3.1, iBuilder allows a Network Operator to enable the Idle and Dormant States feature to dynamically reduce the remote’s Minimum Information Rate based on the length of time that the remote has no user traffic to transmit on the TDMA upstream carrier. This feature is described in Remote Idle and Dormant States on page 89. For instructions for configuring Minimum Information Rate and Idle and Dormant States, see the section titled “Upstream and Downstream Rate Shaping” in the chapter titled “Configuring Remotes” of the iBuilder User Guide.

Technical Reference Guide iDX Release 3.3

53

Application Throughput

Committed Information Rate (CIR) The Network Operator can configure Committed Information Rate for remotes in both the downstream and upstream directions. Unlike Minimum Information Rate, CIR is not statically committed and is granted only when demand is actually present. This allows CIR-based service level agreements and, based on statistical analysis, oversubscribe networks with respect to CIR. If a remote has a CIR but demand is less than the CIR, only the actual demanded bandwidth is granted. CIR can be configured for remotes and for most container nodes in the Group QoS Tree. By default, additional burst bandwidth is assigned evenly among all remotes requesting bandwidth, regardless of CIR allocations that have already been made. As discussed in the iBuilder User Guide, this default behavior can be changed by selecting Allocation Fairness Relative to CIR. In some early iDirect releases, a remote in a highly congested network would often not get burst bandwidth above its CIR. For example, consider a network with a 3 Mbps upstream and three remotes, R1, R2, and R3. R1 and R2 are assigned a CIR of 1 Mbps each and R3 has no CIR. In older releases, if all remotes requested 2 Mbps each, 1 Mbps was given to R3, making the total used BW 3 Mbps. In that case, R1 and R2 received no additional BW. Using the same example network, the additional 1 Mbps BW is evenly distributed by giving each remote an additional 333 Kbps. The default configuration is to allow even bandwidth distribution. Using Group QoS, the Network Operator can alter the “fairness” algorithm used to apportion both the CIR bandwidth and the best-effort bandwidth. “Allocation Fairness Relative to CIR” and “Allocation Fairness Relative to MODCOD” can be selected at various levels of the group QoS tree. Further information and QoS configuration procedures can be found in the chapter titled, “Configuring Quality of Service for iDirect Networks” of the iBuilder User Guide.

Maximum Information Rate (MIR) Maximum Information Rate (MIR) specifies the maximum amount of bandwidth that will be allocated to a remote or Group QoS node, regardless of amount of bandwidth requested. Allocated bandwidth never exceeds the configured MIR bit rate. The QoS bandwidth allocation algorithm does not strictly enforce MIR for upstream traffic. Therefore, it is possible that a remote may receive more bandwidth than the configured maximum if free bandwidth is available. However, this does not affect bandwidth allocations for competing remotes or QoS nodes. MIR is strictly enforced for outbound traffic.

Free Slot Allocation Free slot allocation is a round-robin distribution of unused TDMA slots by the centralized bandwidth manager on a frame-by-frame basis. The bandwidth manager assigns TDMA slots to particular remotes for each TDMA allocation interval based on current demand and configuration constraints (such as configured MIR and CIR). Once demand is met, it is possible that there are unused TDMA slots. In that case, Free Slot Allocation grants these extra slots to remotes in a fair manner. Beginning with iDS Release 8.2, Free Slot Allocation is always enabled. It is no longer configurable in iBuilder. Free Slot Allocation can be disabled with a custom key.

54

Technical Reference Guide iDX Release 3.3

Application Jitter

Compressed Real-Time Protocol (cRTP) The Network Operator can enable Compressed Real-Time Protocol (cRTP) to significantly reduce the bandwidth requirements of VoIP flows. cRTP is implemented using standard header compression techniques. It allows for better use of real-time bandwidth especially for RTPbased applications, which utilize large numbers of small packets, since the 40-byte IP/UDP/RTP header often accounts for a significant fraction of the total packet length. iDirect has implemented a standard header compression scheme including heuristic-based RTP detection with negative cache support for mis-identified UDP streams. For example, G729 voice RTP results in less than 12 Kbps (uncompressed is 24 Kbps). To enable cRTP, see the section titled “Enabling IP Packet Compression Types” in the chapter titled “Configuring Remotes” of the iBuilder User Guide.

Sticky CIR Sticky CIR is activated only when CIR is over-subscribed on the downstream or on the upstream. When enabled, Sticky CIR favors remotes that have already received their CIR over remotes that are currently asking for it. When disabled (the default setting), the Protocol Processor reduces assigned bandwidth to all remotes to accommodate a new remote in the network. Sticky CIR can be configured in the Bandwidth Group and Service Group level interfaces in iBuilder.

Application Jitter Jitter is the variation in packet-by-packet latency for a specific application traffic flow. For an application like Voice over IP (VoIP), the transmitting equipment spaces each packet at a known fixed interval (every 20 ms, for example). However, in a packet switched network, there is no guarantee that the packets will arrive at their destination with the same interval rate. To compensate for this, the receiving equipment stores incoming packets in a jitter buffer and attempts to play out the arriving packets at the interval at which they were transmitted. To accomplish this, additional latency is introduced by buffering packets for a certain amount of time before forwarding them at the fixed interval. While jitter plays a role in both downstream and upstream directions, an iDirect network tends to introduce more jitter in the upstream direction than in the downstream direction. This is due to the discrete nature of the TDMA timeplan which only allows a remote to transmit data in assigned slots. Jitter is introduced when the inter-slot times assigned to a particular remote do not match the desired play out rate. Another source of jitter is additional traffic transmitted between (or in front of) successive packets in the real-time stream. When a large packet needs to be transmitted in front of a real-time packet, jitter is introduced because the remote must wait longer than desired before transmitting the next real-time packet.

TDMA Slot Feathering When TDMA Slot Feathering is enabled, the Protocol Processor bandwidth manager attempts to “feather” or evenly spread the TDMA slots allocated to an individual remote across each upstream frame. For Voice over IP, this is a desirable attribute because the remote’s bursts are distributed more uniformly in time, reducing TDMA jitter and improving the quality of the voice call. This feature is enabled by selecting “Reduce Jitter” for an Application’s Service

Technical Reference Guide iDX Release 3.3

55

Packet Segmentation

Level in iBuilder. For details, see the chapter titled “Configuring Quality of Service for iDirect Networks” in the iBuilder User Guide.

Packet Segmentation Beginning with iDS Release 8.2, Segmentation and Reassembly (SAR) and Packet Assembly and Disassembly (PAD) have been replaced by a more efficient iDirect application. The Network Operator can configure the downstream segment size in iBuilder. Beginning with iDX Release 3.0, the operator can also configure the SCPC upstream segment size. However, all TDMA upstream packet segmentation is handled internally to optimize upstream packet segmentation. Some applications may require changing the downstream or SCPC upstream segment size on small carriers to reduce jitter in the downstream or SCPC upstream packets. Typically, this is not required. For details on configuring the downstream segment size, see the chapter on “Configuring Remotes” in the iBuilder User Guide.

Application Latency Application latency is typically a concern for transaction-based applications such as credit card verification systems that require a rapid completion time per transaction. For applications like these, it is important that the priority traffic be expedited through the system at the expense of the less important background traffic. This is especially important in bandwidth-limited conditions where a remote may have a limited number of TDMA slots on which to transmit its packets. In that case, it is important to minimize application latency as much as possible after the distributor’s QoS decision. Accomplish this by configuring a higherpriority for transaction-based applications, allowing those packets to be transmitted immediately.

Maximum Channel Efficiency vs. Minimum Latency Each TDMA burst carries a discrete number of payload bytes. The remote must divide higherlevel packets into TDMA-burst-sized parts to package these bursts for transmission. The Network Operator can control how bursts are packaged for transmission by selecting between two options on the iBuilder Service level dialog box: Maximum Channel Efficiency (default) and Minimum Latency. Maximum Channel Efficiency delays the release of a partially-filled TDMA burst to allow for the possibility that the next packet will fill the burst completely. In this configuration, the system waits for up to four TDMA transmission attempts before releasing a partial burst. Minimum Latency never delays partially-filled TDMA bursts. Instead, it transmits them immediately. In general, Maximum Channel Efficiency is the desired choice, except in certain situations when it is vitally important to achieve minimum latency for a prioritized service level. For example, in a typically-congested network with transaction-based (“bursty”) traffic that requires a minimum round trip time, Minimum Latency may be the better choice. These settings are configured in iBuilder in the QoS Service Level dialog box. For details, see the chapter titled “Configuring Quality of Service for iDirect Networks” in the iBuilder User Guide.

56

Technical Reference Guide iDX Release 3.3

Group QoS

Group QoS Group QoS (GQoS), introduced in iDS Release 8.0, enhances the power and flexibility of iDirect’s QoS feature for TDMA networks. It allows advanced Network Operators a high degree of flexibility in creating subnetworks and groups of remotes with various levels of service tailored to the characteristics of the user applications being supported. Group QoS is built on the Group QoS tree: a hierarchical construct within which containership and inheritance rules allow the iterative application of basic allocation methods across groups and subgroups. QoS properties configured at each level of the Group QoS tree determine how bandwidth is distributed when demand exceeds availability. Group QoS enables the construction of very sophisticated and complex allocation models. It allows Network Operators to create network subgroups with various levels of service on the same outbound carrier or Inroute Group. It allows bandwidth to be subdivided among customers or Service Providers, while also allowing oversubscription of one group’s configured capacity when bandwidth belonging to another group is available. For details on using the Group QoS feature, see the chapter titled “Configuring Quality of Service for iDirect Networks” in the iBuilder User Guide.

Group QoS Structure The iDirect Group QoS model has the following structure as shown in Figure 9-3:

Figure 9-3. Group QoS Structure

Technical Reference Guide iDX Release 3.3

57

Group QoS

Bandwidth Pool A Bandwidth Pool is the highest node in the Group QoS hierarchy. As such, all sub-nodes of a Bandwidth Pool represent subdivisions of the bandwidth within that Bandwidth Pool. In the iDirect network, a Bandwidth Pool consists of an outbound carrier or an Inroute Group.

Bandwidth Group A Bandwidth Pool can be divided into multiple Bandwidth Groups. Bandwidth Groups allow a Network Operator to subdivide the bandwidth of an outroute or Inroute Group. Different Bandwidth Groups can then be assigned to different Service Providers or Virtual Network Operators (VNO). Bandwidth Groups can be configured with QoS properties such as: •

CIR and MIR: Typically, the sum of the CIR bandwidth of all Bandwidth Groups equals the total bandwidth. When MIR is larger than CIR, the Bandwidth Group is allowed to exceed its CIR when bandwidth is available.

•

Priority: A group with highest priority receives its bandwidth before lower-priority groups.

•

Cost: Cost allows bandwidth allocations to different groups to be unequally apportioned within the same priority. For equal requests, lower cost nodes are granted more bandwidth than higher cost nodes.

Bandwidth Groups are typically configured using CIR and MIR for a strict division of the total bandwidth among the groups. By default, any Bandwidth Pool is configured with a single Bandwidth Group.

Service Group A Service Provider or a Virtual Network Operator can further divide a Bandwidth Group into sub-groups called Service Groups. A Service Group can be used strictly to group remotes into sub-groups or to differentiate groups by class of service. For example, a platinum, gold, silver and best effort service could be defined as Service Groups under the same Bandwidth Group. Like Bandwidth Groups, Service Groups can be configured with CIR, MIR, Priority and Cost. Service Groups are typically configured with either a CIR and MIR for a physical separation of the groups, or with a combination of Priority, Cost and CIR/MIR to create tiered service. Beginning with iDX Release 2.1, there are two types of Service Groups, Application Service Groups and Remote Service Groups. An Application Service Group contains multiple Applications. Remotes assigned to an Application Service Group share the bandwidth assigned to the various Applications in the group. When using Remote Service Groups, a remote becomes a container node for its Applications. Each remote is configured with its own QoS properties such as MIR and CIR and independently allocates that bandwidth to its Applications. Remote Service Groups allow the Network Operator to configure bandwidth for individual remotes and then assign multiple Applications to the remotes. The bandwidth allocated to the Applications under a remote is taken from bandwidth granted to the individual remote; it is not shared with other remotes as it is with Application Service Groups. Note that this structure allows remotes to retain their QoS configuration when moving between networks. The use of and the differences between each type of Service Group are discussed in detail in the iBuilder User Guide.

58

Technical Reference Guide iDX Release 3.3

Group QoS

Application An Application defines a specific service available to the end user. Applications are defined by Application Profiles and associated with any Service Group. The following are examples: • VoIP • VLAN • Multicast • NMS Traffic • Default NOTE: Beginning with iDX Release 3.0, Multicast Fast Path Applications can be configured for remotes in iBuilder. Multicast Fast Path bypasses software processing on the remote resulting in improved throughput. For details, see Multicast Fast Path on page 43. Each Application can have one or more Service Levels with matching rules such as: • Protocol: TCP, UDP, and ICMP • Source and/or Destination IP or IP Subnet • Source and/or Destination Port Number • DSCP Value or DSCP Ranges • VLAN Each Application can be configured with various QoS properties such as: • CIR/MIR • Priority • Cost

Service Profiles Service Profiles are applicable only to Application Service Groups. A Service Profile is created by selecting Applications from the associated Application Service Group and configuring the Group QoS properties (such as CIR and MIR) of the Service Profile. While the Application Service Group specifies the CIR and/or MIR by Application for the entire Application Service Group, the Service Profile specifies the per-remote CIR and/or MIR by Application. For example, the VoIP Application could be configured with a CIR of 1 Mbps for the Service Group in the Application Group and a CIR of 14 Kbps per-remote in the Service Profile. Typically, remotes in an Application Service Group use the Default Profile for that Service Group. In order to accommodate special cases, however, additional profiles (other than the Default Profile) can be created by an operator with Group QoS Planning permissions. For example, profiles can be used by a specific remote to prioritize an Application that is not used by other remotes; to prioritize a specific VLAN on a remote; or to prioritize traffic to a specific IP address (such as a file server) connected to a specific remote in the Service Group. Or a Network Operator may want to configure some remotes for a single VoIP call and others for two VoIP calls. This can be accomplished by assigning different Service Profiles to each group of remotes.

Technical Reference Guide iDX Release 3.3

59

Group QoS

Remote Profiles Remote Profiles are applicable only to Remote Service Groups. Like Service Profiles, Remote Profiles define the Applications that are used by the remotes. Unlike Service Profiles, the Applications defined by Remote Profiles are subnodes of the Remotes in the Group QoS tree. Each Application in a Remote Profile can be configured with its own CIR, MIR, etc. which determine how bandwidth is shared on individual remotes that have the Remote Profile assigned. The Applications are themselves built from Application Profiles, which contain the QoS Service Levels and Rules governing the bandwidth usage of the remote.

Group QoS Scenarios Physical Segregation Scenario Example: A satellite provider would like to split a network with a 10 Mbps outbound carrier for two Service Providers, allocating 6 Mbps for one and 4 Mbps for the other. The first group should be allowed to burst up to 8 Mbps when the bandwidth is not being used by the second group. Configuration: The satellite provider could configure two Bandwidth Groups as follows: •

The first group with: CIR/MIR of 6 Mbps/8 Mbps

The second group with: CIR/MIR of 4 Mbps/4 Mbps

60

Technical Reference Guide iDX Release 3.3

Group QoS

The sum of all CIR bandwidth should not exceed the total bandwidth. A scenario depicting physical segregation is shown in Figure 9-4.

Figure 9-4. Physical Segregation Scenario NOTE: Another solution would be to create a single Bandwidth Group with two Service Groups. This solution would limit the flexibility, however, if the satellite provider decides in the future to further split each group into sub-groups.

CIR Per Application Scenario Example: A Service Provider has a 1 Mbps outbound carrier and would like to make sure that half of it is dedicated to VoIP with up to two VoIP calls per remote. He also has a critical application with Citrix traffic that requires an average of 8 Kbps per remote requiring 128 Kbps. Configuration: The Application Service Group’s Application List could be configured as follows: •

VoIP – CIR 512 Kbps

•

Citrix – CIR 128 Kbps

•

NMS – Priority 1, MIR 16K (Set NMS MIR to 1% to 2% of total BW)

•

Default – Cost 1.0 (Default cost is 1.0)

The derived “Default Application Profile” could be configured as follows:

Technical Reference Guide iDX Release 3.3

61

Group QoS

•

VoIP – CIR 28 Kbps

•

Citrix – CIR 8 Kbps

•

NMS – Priority 1

•

Default – Cost 1.0

A scenario depicting CIR per application is shown in Figure 9-5.

Figure 9-5. CIR Per Application Scenario VoIP could also be configured as priority 1 traffic. In that case, demand for VoIP must be fully satisfied before serving lower priority applications. Therefore, it is important to configure an MIR to avoid having VoIP consume all available bandwidth.

Tiered Service Scenario Example: A Network Operator with an 18 Mbps outbound carrier would like to provide different classes of service for customers. The Platinum service will have the highest priority and is designed for 50 remotes bursting up to an MIR of 256 Kbps. The Gold Service, sold to 200 customers, will have an MIR of 128 Kbps. The Silver Service will be a “best effort” service, and will allow bursting up to 128 Kbps when bandwidth is available. Configuration: There are several ways to configure tiered services. The operator should keep in mind that when priority is used for a Service Group, the Service Group is satisfied up to the MIR before

62

Technical Reference Guide iDX Release 3.3

Group QoS

lower priority Service Groups are served. Here is one example of how the tiered service could be configured: •

Platinum – Priority 1 – MIR 12 Mbps

•

Gold – Priority 2 – MIR 18 Mbps (Identical to no MIR, since the Bandwidth Pool is only 18 Mbps.)

•

Silver – Priority 3 – No MIR Defined (The same as an MIR of 18 Mbps)

A scenario depicting tiered service is shown in Figure 9-6.

Figure 9-6. Tiered Service Scenario Note that cost could be used instead of priority if the intention were to have a fair allocation rather than to satisfy the Platinum service before any bandwidth is allocated to Gold; and then satisfy the Gold service before any bandwidth is allocated to Silver. For example: •

Platinum – Cost 0.1 - CIR 6 Mbps, MIR 12 Mbps

•

Gold – Cost 0.2 - CIR 6 Mbps, MIR 18 Mbps

•

Silver – Cost 0.3 - No CIR, No MIR Defined

Third Level of Segregation by VLAN Scenario The iDirect Group QoS model is designed for two levels of physical segregation of bandwidth. If the user has a need to split the bandwidth into a third level, this could be accomplished by using VLANs. Example: A satellite provider would like to divide an 18 Mbps carrier among six distributors, each with 3 Mbps of bandwidth. One of the distributors would like to offer service to three

Technical Reference Guide iDX Release 3.3

63

Group QoS

Network Operators, giving them 1 Mbps each. Another would like to provide a tiered service (Platinum, Gold and Silver), dedicating 256 Kbps for the Platinum VoIP service. This effectively provides a third level of physical segregation. It could be accomplished by using VLANs as shown in the example below. Configuration: The Service Group’s Applications for the tiered service could be configured as follows: •

Platinum – VLAN-91 & VoIP - Priority 1 – CIR 256 Kbps, MIR 256 Kbps

•

Platinum – VLAN-91 & All Others - Priority 1 – CIR 256 Kbps, MIR 512 Kbps

•

Gold – VLAN-92 - Priority 2 – CIR 256 Kbps, MIR 1 Mbps

•

Silver – VLAN-93 - Priority 2 – CIR 0, MIR 1 Mbps

A scenario depicting a third level VLAN is shown in Figure 9-7.

Figure 9-7. Third Level VLAN Scenario

64

Technical Reference Guide iDX Release 3.3

Group QoS

The Shared Remote Scenario Example: A Network Operator provides service to oil rigs for two companies. Many of the oil rigs have both companies present. Company A bought 8 Mbps of outbound bandwidth, while Company B bought 2 Mbps of outbound bandwidth. The Network Operator would like to use a single outbound carrier of 10 Mbps to provide service for both companies, while ensuring that each customer receives the bandwidth that they paid for. This scenario is complicated by the fact that, on oil rigs with both companies present, the Network Operator would like to use a single remote to provide service to both by separating their terminals into VLAN-51 for Company A and VLAN-52 for Company B. Both companies would also like to prioritize their VoIP. Configuration: If we had separate remotes for each company, this would be a simple “Physical Segregation” scenario. However, keeping both companies in the same Application Service Group and allocating bandwidth by VLAN and application would not provide the strict separation of 8 Mbps for Company A and 2 Mbps for Company B. Instead, the solution is to create two Application Service Groups: • Company A: CIR/MIR 8 Mbps/8 Mbps • Company B: CIR/MIR 2 Mbps /2 Mbps Service Profiles for both companies would have VoIP and Default with the appropriate priority, cost, CIR and MIR. In order to allow the same remote to serve both companies, the remote is assigned to both Application Service Groups as shown in Figure 9-8. Note that this is an unusual configuration and is not recommended for the typical application

Figure 9-8. Shared Remote Scenario

Technical Reference Guide iDX Release 3.3

65

Group QoS

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

66

Technical Reference Guide iDX Release 3.3

Group QoS

Remote 2 is on board a private vessel that requires bandwidth for VoIP as well as for more general internet traffic such as web browsing. The VoIP application has a CIR of 64 kbps to ensure sufficient bandwidth for high-quality voice calls. Limiting the CIR for other applications to 448 kbps ensures that VoIP traffic will be granted the 64 kbps even if the remote’s demand for other bandwidth is greater than 448 kbps. The 512 kbps of MIR for other applications is shown for clarity. It is not really necessary to configure the 512 kbps of MIR for these applications since the remote itself is already limited to 512 kbps.

Figure 9-9. Remote Service Group Scenario

Technical Reference Guide iDX Release 3.3

67

Group QoS

DVB-S2 ACM Scenario 1: Scaled Aggregate CIRs Below Partition’s CIR This scenario applies only to DVB-S2 ACM outbound carriers with EIR configured. Refer to Quality of Service in DVB-S2 ACM Networks on page 12 for a detailed description of ACM operation with EIR enabled. The scenario shows three remotes in an Application Service Group in Remote-Based Group QoS Mode with the following QoS configuration for the Network: •

Remote Based QoS Mode

•

Committed Information Rate (CIR) set to 1 Mbps per remote

•

Maximum Information Rate (MIR) set to 2 Mbps per remote

•

CIR set to 6.5 Mbps for the Application Service Group

•

MIR set to 7.2 Mbps for the Application Service Group

•

Nominal MODCOD for each remote set to 16APSK 8/9

•

Networks best MODCOD set to 16APSK 8/9

Assume for this example that the 6.5 Mbps CIR and 7.2 Mbps MIR are available for the Application Service Group. Demand from each remote is at 1.5 Mbps and each remote is configured in EIR Mode down to a Minimum EIR MODCOD of QPSK 1/4. The only difference in the three remote configurations is their SNR and the corresponding MODCODs. Remote 1 is operating in 8PSK 8/9; Remote 2 is operating in QPSK 8/9; and Remote 3 is operating in QPSK 3/5. In order to calculate the allocated bandwidth for each remote, the Scaling Factor corresponding to the operating MODCOD of each remote as well as the remote’s Nominal MODCOD Scaling Factor are needed and are shown in Figure 9-10 on page 69. NOTE: When bandwidth is allocated for a remote, the CIR and MIR are scaled to the remote’s Nominal MODCOD. At higher levels of the Group QoS tree (Bandwidth Group, Service Group, etc.) CIR and MIR are scaled to the network’s best MODCOD.) Referring to Figure 9-10:

68

•

The Scaled CIR for Remote 1 = 1 Mbps * 1.6456 / 1.2382 = 1.33 Mbps

•

The Scaled CIR for Remote 2 = 1 Mbps * 2.4605 / 1.2382 = 1.99 Mbps

•

The Scaled CIR for Remote 3 = 1 Mbps * 3.6939 / 1.2382 = 2.98 Mbps

•

The Scaled Aggregate CIR for the three remotes is 6.3 Mbps. Since the Scaled Aggregate CIR is less than the Service Group CIR (6.5 Mbps), all three remotes get their full CIR of 1 Mbps.

•

The remaining 900 Kbps (Service Group MIR of 7.2 Mbps minus 6.3 Mbps required for CIRs) are divided equally between the three remotes which gives each remote 300 Kbps based on the Nominal MODCODs.

•

Remote 1 receives 300 Kbps * 1.2382 / 1.6456 = 226 Kbps of Best Effort for a Total of 1.226 Mbps

•

Remote 2 receives 300 Kbps * 1.2382 / 2.4605 = 150 Kbps of Best Effort for a Total of 1.151 Mbps

•

Remote 3 receives 300 Kbps * 1.2382 / 3.6939 = 101 Kbps of Best Effort for a Total of 1.101 Mbps

Technical Reference Guide iDX Release 3.3

Group QoS

Figure 9-10. Scaled Aggregate CIRs Below Partition’s CIR

Technical Reference Guide iDX Release 3.3

69

Group QoS

DVB-S2 ACM Scenario 2: Scaled Aggregate CIRs Exceeds Partition’s CIR This scenario uses the same configuration as the scenario on page 68 with a change in CIR and MIR for the Application Service Group. In this case, the Application Service Group is oversubscribed as follows: •

The CIR of the Application Service Group is set to 3 Mbps.

•

The MIR of the Application Service Group is set to 3 Mbps.

Assume for this example that the 3 Mbps CIR and 3 Mbps MIR are available for the Application Service Group. In the scenario (Figure 9-11), the Scaled Aggregate CIR for the three remotes (6.3 Mbps) exceeds the Service Group CIR of 3 Mbps. Bandwidth is therefore distributed scaled to the Nominal MODCODs of the remotes. •

Remote 1 receives 1 Mbps * 1.2382 / 1.6456 = 752 Kbps

•

Remote 2 receives 1 Mbps * 1.2382 / 2.4605 = 503 Kbps

•

Remote 3 receives 1 Mbps * 1.2382 / 3.6939 = 335 Kbps

Figure 9-11. Scaled Aggregate CIRs Exceed Partition’s CIR

70

Technical Reference Guide iDX Release 3.3

Group QoS

Bandwidth Allocation Fairness Relative to CIR iBuilder allows a Network Operator to enable or disable Bandwidth Allocation Fairness Relative to CIR at various nodes in the Group QoS tree. If this option is configured, then, during contention for bandwidth, bandwidth allocation is proportional to the configured CIR. If this option is not selected, bandwidth is allocated equally to competing nodes until available bandwidth is exhausted. If there is enough available bandwidth to satisfy all CIR demand, this option extends to the best effort round of bandwidth allocation. Whether or not to enable Bandwidth Allocation Fairness Relative to CIR depends on the requirements of the Service Provider or network. For example, some corporate networks may want to disable this option in order to satisfy remote sites with small CIRs during bandwidth contention. On the other hand, some Service Providers that price their services based on CIR may want to enable this option in order to allocate bandwidth in proportion to the configured CIRs.

Figure 9-12. Bandwidth Allocation Fairness Relative to CIR Figure 9-12 shows two remotes, Remote 1 and Remote 2. Remote 1 is configured with a CIR or 256 Kbps while Remote 2 is configured with a CIR of 512 Kbps. Both remotes are requesting their full CIR, but only 450 Kbps of bandwidth is available. The tree on the left-hand side of Figure 9-12 shows the result of disabling Bandwidth Allocation Fairness Relative to CIR for the Service Group. The bandwidth is split equally between Remote 1 and Remote 2 until the bandwidth is exhausted. Both remotes receive 225 Kbps of bandwidth. (If Remote 1’s CIR could be fully satisfied, any remaining bandwidth would be granted to Remote 2. For example, if Remote 1 had only 200 Kbps of configured CIR, Remote 1 would be granted 200 Kbps of bandwidth and Remote 2 would be granted 250 Kbps of bandwidth.) The tree on the right-hand side of Figure 9-12 shows the result of enabling Bandwidth Allocation Fairness Relative to CIR for the Service Group. In that case, Remote 1 receives 150 Kbps of bandwidth, half that of Remote 2, since Remote 1 has half the configured CIR of Remote 2.

Technical Reference Guide iDX Release 3.3

71

Group QoS

Bandwidth Allocation Fairness Relative to MODCOD Beginning with iDX Release 3.2, iDirect supports two types of Allocation Fairness Relative to MODCOD: •

Allocation Fairness Relative to Nominal MODCOD

•

Allocation Fairness Relative to Operating MODCOD

Bandwidth Allocation Fairness Relative to Nominal MODCOD only applies to networks that use DVB-S2 with Adaptive Coding and Modulation (ACM). It allows the system to provide equal information rates to remotes configured with the same CIR regardless of their configured Nominal MODCODs. NOTE: Allocation Fairness Relative to Nominal MODCOD was called Allocation Fairness Relative to MODCOD in pre-iDX 3.2 releases. If Bandwidth Allocation Fairness Relative to Nominal MODCOD is enabled, bandwidth allocation is based on information rate rather than on raw satellite bandwidth. Therefore, remotes with lower nominal MODCODs receive more satellite bandwidth than remotes with higher nominal MODCODs to achieve the same information rate. If Bandwidth Allocation Fairness Relative to Nominal MODCOD is disabled, satellite bandwidth is allocated without regard to MODCOD. If there is enough available bandwidth to satisfy all CIRs, this option extends to the best effort round of bandwidth allocation. Whether or not to enable Bandwidth Allocation Fairness Relative to Nominal MODCOD depends on the requirements of the Service Provider or network. For example, some corporate networks may elect to disable this option to favor remotes operating at more efficient MODCODs. On the other hand, Service Providers that want to encourage end-users to invest in larger antennas through their service pricing model may elect to enable this option. In that case, the pricing model reflects the additional bandwidth required at lower MODCODs and Bandwidth Allocation Fairness Relative to Nominal MODCOD is more appropriate.

Figure 9-13. Bandwidth Allocation Fairness Relative to Nominal MODCOD Figure 9-13 shows two remotes, Remote 1 and Remote 2, each configured with a CIR of 1 Mbps. Remote 1 is operating at a Nominal MODCOD of 8PSK 3/4. Remote 2 is operating at a Nominal MODCOD of QPSK 3/4. Both remotes are requesting their full CIR, but only enough bandwidth to satisfy 1.65 Mbps of CIR at 8PSK 3/4 is available. Note that QPSK 3/4 requires about 1.5 times the raw satellite bandwidth of 8PSK 3/4 to deliver the same CIR.

72

Technical Reference Guide iDX Release 3.3

Group QoS

The tree on the left-hand side of Figure 9-13 shows the result of disabling Bandwidth Allocation Fairness Relative to MODCOD for the Service Group. The satellite bandwidth is split equally between Remote 1 and Remote 2 until the bandwidth is exhausted. This results in Remote 1 receiving 825 Kbps of CIR and Remote 2 receiving 550 Kbps of CIR. The tree on the right-hand side of Figure 9-13 shows the result of enabling Bandwidth Allocation Fairness Relative to MODCOD for the Service Group. Each remote receives enough bandwidth to carry 660 Kbps CIR. To accomplish this, Remote 2 must be granted 1.5 times the satellite bandwidth of Remote 1. Allocation Fairness Relative to Operating MODCOD operates similarly to Allocation Fairness Relative to Nominal MODCOD except that adjustments are made dynamically based on the MODCOD at which the remote are currently operating rather than the remote’s nominal MODCOD. This favors remotes currently operating at lower MODCODs, since their satellite bandwidth allocations must increase to achieve the same information rate as remotes operating at higher MODCODs. For additional information, see the section titled “Allocation Fairness Relative to MODCOD” in the iBuilder User Guide.

Technical Reference Guide iDX Release 3.3

73

Group QoS

74

Technical Reference Guide iDX Release 3.3

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

The Installation and Commissioning Guide for iDirect Satellite Routers contains the procedure for determining the correct TDMA Initial Power and Reference Carrier parameters for a remote.

•

Remote Acquisition on page 127 describes the process by which a remote joins an iDirect network.

•

Uplink Control Process on page 79 describes uplink power control in iDirect networks.

Technical Reference Guide iDX Release 3.3

75

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

All Remotes Need To Transmit Bursts in the Same C/N Range In a burst mode demodulator, the gain must be set at some nominal point prior to the arrival of a data burst so that the burst is correctly detected and demodulated. Since a single Hub Line Card receives bursts from many different remote modems, it constantly calculates the optimal gain point by taking into account the average levels of all bursts arriving at that Hub Line Card. If all the bursts arrive at similar C/N levels, the average C/N is close to the optimal value for all bursts. However, if many bursts arrive at varying C/N levels, the higher-level and lowerlevel bursts can skew the average such that the average is no longer optimal. The nominal C/N range is 2 dB. The actual range at which bursts can be optimally detected is approximately 8 dB, centered at the nominal gain point (Figure 10-1).

Figure 10-1. Optimal C/N Detection Range As shown in Figure 10-1, under ideal circumstances, the average C/N of all remotes on the upstream carrier is equal to the center of the UCP adjustment range. Notice that the optimal detection range extends below the threshold C/N of the upstream carrier.

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

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

76

Technical Reference Guide iDX Release 3.3

What Happens When Initial Tx Power Is Set Incorrectly?

to acquire using traditional acquisition (rather than Superburst) with a C/N value of less than 7 dB will not acquire the network.

Figure 10-2. Skewed C/N Detection Range: Initial Transmit Power Too High

When Initial Transmit Power is Too Low Remotes acquiring the network with initial transmit power set too low skew the average C/N to be below the center of the UCP Adjustment Range. This could cause remotes coming into the network at the higher end (for example, 14 dB) to experience some distortion in the demodulation process. Additionally, a remote acquiring at below the C/N threshold may experience a large number of CRC errors after joining the network until its power is sufficiently increased. Since UCP updates may occur as infrequently as every 20 seconds, it may take a minute or more for carriers with initial power set too low to increase their power to be within the nominal range. During this time, remotes that are operating under clear sky conditions could drop out of the network because the bursts no longer fall within the optimal detection range. Remotes that are trying to acquire with a C/N value of greater than 13 dB may not acquire the network. Bursts can still be detected below the threshold C/N but the probability of detection and demodulation is reduced.

Figure 10-3. Skewed Detection Range: Initial Transmit Power Too Low

Technical Reference Guide iDX Release 3.3

77

What Happens When Initial Tx Power Is Set Incorrectly?

78

Technical Reference Guide iDX Release 3.3

11 Uplink Control Process

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

TDMA Uplink Control TDMA Uplink Control is active while the remote is acquiring the network and after the remote becomes operational in the network. This section discusses both phases of TDMA Uplink Control.

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

Guard Interval

Guard Interval

Figure 11-1. TDMA Frame Format

Technical Reference Guide iDX Release 3.3

79

TDMA Uplink Control

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

80

Technical Reference Guide iDX Release 3.3

TDMA Uplink Control

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

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

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

Technical Reference Guide iDX Release 3.3

81

TDMA Uplink Control

The Guard Interval is no longer entered into iBuilder in symbols. It is now entered in units of system time called NCR ticks. For clarity, the number of NCR ticks entered is translated to microseconds and displayed on the screen (Figure 11-2).

Figure 11-2. iBuilder: Maximum Speed and Guard Interval for Inroute Group

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

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

82

Technical Reference Guide iDX Release 3.3

TDMA Uplink Control

A remote may be assigned slots on an upstream carrier that does not match its current nominal carrier. For example, during upstream bandwidth contention, a remote may be granted slots on a less efficient carrier if there are no available slots on the nominal carrier. In that case, the remote automatically adjusts its transmit power such that the power matches what is required on the assigned carrier. In earlier releases, the target C/N (or TDMA Nominal C/N) was an operator-entered value determined by adding the C/N threshold for the inroute from the Link Budget Analysis Guide to the additional operating margin determined by the Link Budget Analysis for the network. Beginning in iDX Release 3.2, the target C/N is calculated using the C/N thresholds for the inroutes from the Link Budget Analysis Guide and the following margins configured in iBuilder: •

The Fade Slope Margin (M1) allows for incremental fade that can occur during the reaction time of the power control algorithm as well as the uncertainty in the C/N0 estimations.

•

The Hysteresis Margin (M2) is added to the Fade Slope Margin to prevent unnecessarily frequent switching between carriers. NOTE: The Acquisition Margin (M3) is used only to select the initial nominal carrier when a remote acquires the network. This margin is discussed on page 80.

The system adds the sum of the Fade Slope Margin and the Hysteresis Margin to the C/N thresholds from the LBA Guide to determine the target C/Ns for each carrier in the inroute group. iDirect provides a dimensioning tool to assist network designers in determining suitable values for these parameters. If a remote’s C/N falls below the target C/N, the power control algorithm increases the remote’s transmit power if possible to bring the signal back up to the target level. If the remote’s power cannot be increased on the nominal carrier and a more protected carrier is available, then the remote’s nominal carrier is changed to the more robust carrier. This keeps the remote in the network at the expense of diminished throughput. If the remote is consistently below the threshold defined by the target C/N minus the Hysteresis Margin on the most protected carrier in the inroute group, the remote is “logged out” of the network. A remote that has been logged out must re-acquire the network before it can continue to transmit user traffic. If a remote’s C/N is above the target C/N plus the hysteresis margin, the power control algorithm looks for a more efficient carrier on which the remote can maintain the target C/N. If such a carrier is found and if UCP estimates that remote is capable of transmitting on that carrier, the remote’s nominal carrier is changed to the new carrier. If the remote cannot switch to a better carrier, the power control algorithm decreases the power as necessary to return the remote’s signal to the target C/N. The power control algorithm reacts faster when the hub determines that a remote has entered an upstream fade. When monitoring the remote’s signal, the algorithm samples the C/N periodically. The algorithm determines a “fade slope” for the remote based on analysis of the C/N samples. The algorithm adjusts the measurement interval depending on the fade slope, such that it is shorter when the fade varies rapidly. This tends to keep small and constant the amount of margin required in order to account for the reaction time. If a remote fade is detected, then the update interval is decreased based on the severity of the fade. Decreasing the update interval may require the system to allocate additional

Technical Reference Guide iDX Release 3.3

83

TDMA Uplink Control

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

Correction aims for C3 of next carrier up

Out of UPC: Drops below C2; Switch down

UPC keeps C/N0 close to C3

UPC keeps C/N0 close to C3

Correction aims for C3 of next carrier down

C3

Hysteresis margin

C3 M2

M2

C2 Fade Slope margin

C2 M1

M1

H

C1

H

C1

Carrier 1

Carrier 1 C3

'

M2

Sufficient headroom to switch up

C2 M1 C1 Carrier 2

Increasing fade

UPC keeps C/N0 close to C3

Decreasing fade

Figure 11-3. Uplink Power Control During Remote Fade In Figure 11-3: •

84

C/N0 = C/N + 10log10 (Rs) : The C/N adjusted for the carrier symbol rate (Rs).

Technical Reference Guide iDX Release 3.3

SCPC Return Uplink Control

•

C1 : The C/N threshold from Link Budget Analysis Guide.

•

C2 = C1 + M1 : The C/N threshold plus the Fade Slope Margin.

•

C3 = C2 + M2 : The C/N threshold plus the Fade Slope Margin plus the Hysteresis Margin.

•

: The C/N0 difference between Carrier 1 and Carrier 2.

•

H : Power Headroom; i.e. the amount that the remote can increase its transmit power before reaching its configured TDMA maximum power.

Uplink power control continuously monitors the remote’s C/N0 as measured at the hub and adjusts the remote’s transmit power as required to maintain the target C/N0 on the nominal carrier. Referring to Figure 11-3, the system reacts to a remote fade as follows: 1. Prior to the fade, the remote is operating on Carrier 1. Uplink power control keeps the C/N0 of the remote at approximately the target C/N0 represented by C3 of Carrier 1. 2. As the remote enters the fade, uplink power control increases the remote’s transmit power as necessary to maintain the target C/N0 on Carrier 1. 3. When the remote’s power headroom is exhausted, the remote’s C/N0 continues to drop on Carrier 1 but the transmit power can no longer be increased to return the remote to C3. 4. When the remote’s C/N0 falls below C2 on Carrier 1, the remote is moved to a more protected carrier (Carrier 2) where the target C/N0 of the remote can be maintained. 5. As the fade decreases, uplink power control decreases the remote’s transmit power to maintain the target C/N0 on Carrier 2. 6. Once the fade has decreased to the point that the remote has sufficient power headroom to meet the target C/N0 (C3) of Carrier 1, the remote is moved back to Carrier 1. 7. When the fade passes, uplink power control continues to operate to keep the remote’s C/N0 at C3 on Carrier 1 as it did prior to the fade.

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

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

Technical Reference Guide iDX Release 3.3

85

Viewing UCP Statistics in iMonitor

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

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

Figure 11-4. iMonitor UCP Statistics The following information for the selected remote is displayed on the iMonitor UCP Info tab:

86

•

The remote’s Upstream C/N0 as measured at the hub

•

The remote’s UCP Power Adjustment

•

The remote’s UCP Symbol Timing Offset (TDMA only)

•

The remote’s UCP Frequency Offset

Technical Reference Guide iDX Release 3.3

Viewing UCP Statistics in iMonitor

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

The number of valid acquisition bursts received from the remote

•

The number of CRC errors received in acquisition slots assigned to the remote

•

The number of missing acquisition bursts in acquisition slots assigned to the remote

Figure 11-5 shows the upstream acquisition statistics for a remote in the process of acquiring the network. Notice that there are a high number of missing acquisition bursts and acquisition CRC errors as the UCP algorithm adjusts the remote’s frequency offset. When the hub detects a burst from the remote, the hub sends the remote the correct frequency offset correction and the missing bursts and CRC errors drop to zero.

Figure 11-5. Remote Upstream Acquisition Statistics

Technical Reference Guide iDX Release 3.3

87

Viewing UCP Statistics in iMonitor

For details on viewing UCP and Upstream Performance statistics in iMonitor, see the iMonitor User Guide.

88

Technical Reference Guide iDX Release 3.3

12 Remote Idle and Dormant States Beginning with iDX Release 3.1, the Idle and Dormant States feature allows a remote to dynamically reduce its Minimum Information Rate based on the length of time that the remote has no user traffic to transmit on the TDMA upstream carrier.

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

Technical Reference Guide iDX Release 3.3

89

Feature Description

Feature Description A remote with the Idle and Dormant States feature enabled can be in one of three states: Active, Idle or Dormant. Figure 12-1 shows how the remote’s states change when this feature is enabled.

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

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

90

Technical Reference Guide iDX Release 3.3

Feature Description

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

Technical Reference Guide iDX Release 3.3

91

Feature Description

Profile” in the chapter “Configuring Quality of Service for iDirect Networks” in the iBuilder User Guide for details.)

Figure 12-3. Upstream Service Level with Trigger State Change Selected NOTE: When using the Idle and Dormant States feature in conjunction with Remote Sleep Mode, the Sleep timeout should be longer than the Idle and Dormant State timeouts. Otherwise, the remote will sleep before the Dormant State timeout expires and the Idle and State feature will be ineffective. See Remote Sleep Mode on page 123. Using the configuration in Figure 12-2 as an example, if the remote has been recently Active but has no more user traffic to transmit, it will remain in the Active State for 120 seconds (the Idle State timeout). During that time, the remote will be granted its configured Minimum Information Rate of 27.264 kbps. If after 120 seconds the remote still has no user traffic to transmit, it will enter the Idle State and the Minimum Information Rate granted to the remote will change to 3.14 kbps (or 1 slot every 8 frames). If after 180 seconds in the Idle State the remote still has no user traffic to transmit, it will enter the Dormant State and its Minimum Information Rate will change to 0.85 kbps. The remote will remain in the Dormant State until it receives upstream user traffic to transmit. If at any time a remote in Idle State or Dormant State receives upstream user traffic for transmission, it will to return to the Active State and the Minimum Information Rate will return to 27.264 kbps. To remain in the network, a remote should transmit at least 1 burst every 4 seconds. With a typical frame length of 125 ms, this translates into a minimum allocation of 1 slot every 32 frames. As in previous releases, the Minimum Information Rate for the Active State cannot be set lower than one slot every 16 frames (the equivalent of one slot every 2 seconds.) Typically, this minimum allocation is sufficient for any remote to stay in the network. For the Idle State and the Dormant State, however, the Minimum Information Rate can be set as low as one slot every 64 frames (one slot every 8 seconds). Note that based on the discussion in the previous paragraph is unlikely that a remote with such a low Minimum Information Rate will remain in the network except when all of the following conditions are met: •

The remote is transmitting a BPSK or QPSK upstream carrier to an Evolution line card under clear sky conditions.

•

The remote is a fixed-site (non-mobile) remote in a Ku Band, C Band or X Band network.

Therefore, configuring a rate below the recommended setting may cause the remote to drop out of the network and be forced to reacquire if there is insufficient margin to handle rain

92

Technical Reference Guide iDX Release 3.3

Feature Description

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

Technical Reference Guide iDX Release 3.3

93

Feature Description

94

Technical Reference Guide iDX Release 3.3

13 Verifying Error Thresholds Using IP Packets This chapter provides instructions on testing iDirect equipment functioning in IP networks to ensure that Layer 1 errors are seen at the specified rate at the C/N thresholds. The C/N thresholds are published in the Link Budget Analysis Guide.

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

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

Technical Reference Guide iDX Release 3.3

95

TDMA Upstream Threshold Testing

When testing the upstream channel in a network by inserting IP test packets at the remote and terminating them at the hub, the advertised CLR threshold must be adjusted to account for the size of the IP packets being used in the test. For example, if it takes 10 TDMA cells to transmit each IP packet, the IP PER will be 10 times worse than the CLR at the threshold point; in other words, a PER of 1e-4 will be measured at the advertised threshold. Use the following equations to find the expected upstream IP Packet Error Rate: IP_PacketErrorRate = CellLossRate * (1 + IP_PacketSize) / (TDMA_CellSize) Where, TDMA_CellSize = TDMA_BlockSize – 12

Upstream Example 1 Find the IP Packet Error Rate for: 512 byte IP test packets 8PSK modulation 2D 16-State/170 Byte-4/5 FEC In this example: TDMA_CellSize = 170 – 12 = 158 bytes Therefore, IP_PacketErrorRate = 1e-5 * (1 + 512) / 158 = 3.25e-5 Since this TDMA mode reaches its error threshold at a C/N of 11.7 dB, 3.25 IP Packets are expected to be lost for every 100,000 transmitted at this C/N.

Upstream Example 2 Find the IP Packet Error Rate for: 512 byte IP test packets QPSK modulation 2D 16-State/438 Byte-2/3 FEC In this example: TDMA_CellSize = 438 – 12 = 426 bytes Therefore, IP_PacketErrorRate = 1e-5 * (1 + 512) / 426 = 1.20e-5 Since this TDMA mode reaches its error threshold at a C/N of 5.0 dB, 1.20 IP Packets are expected to be lost for every 100,000 transmitted at this C/N.

96

Technical Reference Guide iDX Release 3.3

DVB-S2 Downstream Threshold Testing

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

Downstream Example Find the IP Packet Error Rate for: 1024 byte IP test packets 8PSK Rate 3/4 MODCOD In this example: FrameLossRate = (11600 + 112) * 1e-8 = 1.17e-4 DVB-S2_FrameSize = (11600 / 8) – 7 = 1443 bytes Therefore, IP_PacketErrorRate = 1.17e-4 * (1 + 1024) / (1443 – 2) = 8.32e-5 Since this DVB-S2 MODCOD reaches its error threshold at a C/N of 8.5 dB, 8.32 IP Packets are expected to be lost for every 100,000 transmitted at this C/N.

Technical Reference Guide iDX Release 3.3

97

DVB-S2 Downstream Threshold Testing

98

Technical Reference Guide iDX Release 3.3

14 Global NMS Architecture

This chapter describes how the Global NMS works in a global architecture and a sample Global NMS architecture.

How the Global NMS Works The Global NMS allows the Network Operator to add a single physical remote, as identified by its Derived ID (DID), to multiple networks at the same time. A remote that is a member of multiple networks is called a “roaming remote.” For details on defining and managing roaming remotes, refer to the iBuilder User Guide. Figure 14-1 illustrates the current and Global NMS database relationships.

Figure 14-1. Global NMS Database Relationships

Technical Reference Guide iDX Release 3.3

99

Sample Global NMS Network

Sample Global NMS Network This section illustrates a sample global NMS architecture, and it explains how the NMS works in this type of network (Figure 14-2).

Figure 14-2. Sample Global NMS Network Diagram In this example, there are 4 different networks connected to three different Regional Network Control Centers (RNCCs). A group of remote terminals has been configured to roam among the four networks. NOTE: This diagram shows only one example from the set of possible network configurations. In practice, there may be any number RNCCs and any number of protocol processors at each RNCC. On the left side of the diagram, a single NMS installed at the Global Network Control Center (GNCC) manages all the RNCC components and the group of roaming remotes. Network Operators, both remote and local, can share the NMS server simultaneously with any number of VNOs. (Only one VNO is shown in the Figure 14-2.) All users can run iBuilder, iMonitor, or both on their PCs. The connection between the GNCC and each RNCC must be a dedicated high-speed link. Connections between NOC stations and the NMS server are typically standard Ethernet. Remote NMS connections are made either over the public Internet protected by a VPN, port forwarding, or a dedicated leased line.

100

Technical Reference Guide iDX Release 3.3

15 Security Best Practices

This chapter recommends basic security practices to enhance the security of iDirect networks. iDirect also recommends implementation of all additional security measures required by your company security standards.

Hub and NMS Server Security An iDirect installation includes a number of Linux servers used to configure and run the networks. These servers include: •

NMS servers for network configuration and monitoring

•

Protocol Processor Blade servers to manage network traffic at the hub

•

GKD servers to manage and distribute encryption keys

iDirect recommends securing all hub and NMS servers from unauthorized physical access. In addition, iDirect strongly recommends implementing the security measures in the following sections to protect the servers.

Network Isolation and External Access In addition to limiting physical access to the servers, iDirect recommends isolation of all networks from external access to the extent possible. Access to iDirect servers should be protected behind a commercial-grade firewall. If external access is required, iDirect recommends the use of secure private networks. •

For Network Operators requiring remote access, including VNO operators, all connections should be established through carefully managed Virtual Private Networks (VPNs).

•

All iBuilder and iMonitor clients connecting to the NMS over a Wide Area Network (WAN) should do so over a private network or VPN.

Server Password Security iDirect Servers are shipped with default passwords. At installation, the passwords should be changed from the default on all servers for the following users: •

root

•

idirect (iDX Release 2.1 and later)

Technical Reference Guide iDX Release 3.3

101

NMS Client Security

Thereafter, these passwords should be changed periodically. When selecting new passwords, iDirect recommends following common guidelines for constructing strong passwords.

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

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

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

NMS Client Security iDirect recommends the following measures to ensure secure access to iDirect networks from the iBuilder and iMonitor clients.

User Passwords and Permissions The NMS clients are preconfigured with the following users: •

admin

•

guest

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

102

Technical Reference Guide iDX Release 3.3

Console Password Security

Client Access Access to iBuilder and iMonitor sessions should be strictly controlled. Network Operators should always log out of any NMS clients when leaving workstations to prevent unauthorized access.

Remote Access All remote access by NMS client applications to iDirect networks should be established over secure private networks.

Console Password Security The following iDirect network elements are pre-configured with a user account and an admin account that allow access to the iDirect applications using a console terminal window. •

Remotes

•

Line Cards

•

Protocol Processor Blades

At installation, these passwords should be changed from the default on each of these network elements. Thereafter, these passwords should be changed periodically. All of these passwords can be changed in iBuilder by right-clicking the network element; selecting the Modify option from the menu; and applying the changes as required. (See the iBuilder User Guide for details.) NOTE: The user and admin console passwords for protocol processor blades are configured at the Protocol Processor level of the iBuilder tree and shared by all blades configured under that Protocol Processor.

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

Technical Reference Guide iDX Release 3.3

103

DNS Queries on Satellite (SAT0) Interface of Remote

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

104

Technical Reference Guide iDX Release 3.3

16 Global Protocol Processor Architecture This chapter describes how the Protocol Processor works in a global architecture. Specifically it contains “Remote Distribution,” which describes how the Protocol Processor balances remote traffic loading and “De-coupling of NMS and Data Path Components,” which describes how the Protocol Processor Blades continue to function in the event of a Protocol Processor Controller failure.

Remote Distribution The actual distribution of remotes and processes across a blade set is determined by the Protocol Processor controller dynamically in the following situations: •

At system Startup, the Protocol Processor Controller determines the distribution of processes based on the number of remotes in the network(s).

•

When a new remote is added in iBuilder, the Protocol Processor Controller analyzes the current system load and adds the new remote to the blade with the least load.

•

When a blade fails, the Protocol Processor Controller re-distributes the load across the remaining blades, ensuring that each remaining blade takes a portion of the load.

The Protocol Processor controller does not perform dynamic load-balancing on remotes. Once a remote is assigned to a particular blade, it remains there unless it is moved due to one of the situations described above.

De-coupling of NMS and Data Path Components If the Protocol Processor Controller fails, the Protocol Processor Blades continue to function normally since the NMS and Protocol Processor Controller are independent. However, during a period of Controller failure, automatic failover does not occur and cannot be reconfigured. It is possible to build process redundancy into the design by running duplicate processes over

Technical Reference Guide iDX Release 3.3

105

De-coupling of NMS and Data Path Components

multiple Protocol Processor Blades. A high-level architecture of the Protocol Processor, with one possible configuration of processes across two blades is shown in Figure 16-1.

Figure 16-1. Protocol Processor Architecture

106

Technical Reference Guide iDX Release 3.3

17 Distributed NMS Server

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

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

Figure 17-1. Sample Distributed NMS Configuration

Technical Reference Guide iDX Release 3.3

107

iBuilder and iMonitor

The configuration in Figure 17-1 has the following process distribution: •

NMS Server 1 runs the configuration server (nmssvr), latency server (latsvr), the chassis manager server (cmsvr) and the PP controller (cntrlsvr) process.

•

NMS Server 2 runs only the Statistics processes (nrdsvr).

•

NMS Server 3 runs only the Event processes (evtsvr).

In the example, the busiest NMS processes, nrdsvr and evtsvr, are placed on their own servers for maximum processing efficiency. All other NMS server processes are grouped on NMS Server 1.

iBuilder and iMonitor From the iBuilder or iMonitor user perspective, a distributed NMS server functions identically to a single NMS server. In both server configurations, users provide a user name, password, and the IP address or Host Name of the NMS configuration server at the time of login. The configuration server stores the location of all other NMS servers and provides this information to the iBuilder or iMonitor client. Using this information, the client automatically establishes connections to the server processes on the correct machines. See the appendix “Configuring a Distributed NMS Server” in the iBuilder User Guide for details.

108

Technical Reference Guide iDX Release 3.3

18 Transmission Security (TRANSEC) This chapter describes how TRANSEC is implemented in an iDirect Network. It includes the following sections: •

What is TRANSEC?

•

iDirect TRANSEC

•

TRANSEC Key types

•

DVB-S2 Downstream TRANSEC

•

Upstream TRANSEC

•

ACQ Burst Obfuscation

•

TRANSEC Dynamic Key Management

•

TRANSEC Remote Admission Protocol

•

ACC Key Management

•

Automatic Beam Selection (ABS) and TRANSEC

What is TRANSEC? Transmission security prevents an adversary from exploiting information available in a communications channel without necessarily having defeated the encryption inherent in the channel. For example, even if an adversary cannot defeat the encryption placed on individual packets, the adversary may be able to determine answers to questions such as: •

What types of applications are currently active on the network?

•

Who is talking to whom?

•

Is the network or a particular remote site active now?

•

Based on traffic analysis, what is the correlation between network activity and real world activity?

•

Is a particular remote site moving?

•

Is there significant acquisition activity?

iDirect supplies FIPS 140-2 certified TRANSEC-capable IP modems. iDirect’s TRANSEC feature, as outlined in this chapter, makes answers to questions like those listed above theoretically impossible for an adversary to determine.

Technical Reference Guide iDX Release 3.3

109

iDirect TRANSEC

iDirect TRANSEC iDirect achieves full TRANSEC compliance by presenting to an adversary eavesdropping on the RF link a constant wall of fixed-sized, strongly-encrypted (AES, 256 bit key, CBC Mode) traffic segments, the frequency of which do not vary with network activity. All network messages, including those that control the admission of a remote terminal into the TRANSEC network, are encrypted and their original size is hidden. The content and size of all user traffic (Layer 3 and above), as well as all network link layer traffic (Layer 2), is completely indeterminate from an adversary’s perspective. In addition, no higher-layer information can be ascertained by monitoring the physical layer (Layer 1) signal. iDirect TRANSEC includes a remote-to-hub and a hub-to-remote authentication protocol based on standard X.509 certificates designed to prevent man-in-the-middle attacks. This authentication mechanism prevents an adversary’s remote from joining an iDirect TRANSEC network. In a similar manner, it prevents an adversary from coercing a TRANSEC remote into joining the adversary’s network. While these types of attacks would be extremely difficult even in a non-TRANSEC iDirect network, the mechanisms in place within a TRANSEC network render them theoretically impossible. All encryption in a TRANSEC network is done using the AES algorithm with a 256 bit key and operates in CBC Mode.

TRANSEC Key types iDirect TRANSEC is based on the following keys: •

Host Private Keys/Public Keys. Each host in a TRANSEC network has a set of selfgenerated private keys and public keys. These keys are used for certificate exchange and verification. Once generated, these keys are never changed. All Dynamic Network Key exchanges are protected by these keys.

•

Dynamic Network Key (or Dynamic Key or DCC Key). The network-wide Dynamic Network Key is used to encrypt all user traffic and traffic headers in both the upstream and downstream directions. This key is updated frequently to preserve the key strength. Because a remote receives the Dynamic Network Key after acquisition into the network, it is possible for the remote to miss a key update (also called a “key roll”) and still join the network. The Dynamic Network Key is not preserved across power cycles of a modem. The channel encrypted with the Dynamic Key is referred to the Dynamic Ciphertext Channel, or DCC. There is a separate DCC for the downstream and upstream channels. Both the downstream and upstream DCC use the same Dynamic Network Key.

•

Network Acquisition Key (or ACC Key). The Network Acquisition Key is used to encrypt all traffic and traffic headers that are required for a remote to acquire the network. This key is rolled infrequently. If a remote misses two consecutive key updates, it is not able to reacquire the network until the key is provided to the remote. The Network Acquisition Key is stored on the remote and is preserved across power cycles. The channel encrypted with this key is referred to the Acquisition Ciphertext Channel, or ACC. There is an ACC for the downstream and an ACC for the upstream. The same key is used for the upstream and downstream. The iDirect TRANSEC system is designed so that compromise of the ACC Key only reveals which remotes are acquiring the network. Compromise of this key does not allow an

110

Technical Reference Guide iDX Release 3.3

DVB-S2 Downstream TRANSEC

attacker to join the network or to perform traffic analysis on remotes that have already acquired the TRANSEC network.

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

Technical Reference Guide iDX Release 3.3

111

DVB-S2 Downstream TRANSEC

implementation purposes; however, that does not change which fields are encrypted by a given key.)

Figure 18-1. DVB-S2 TRANSEC Frame Structure The first 21 bytes of the DVB-S2 frame are sent in the clear. These initial 21 bytes consist of: •

A four-byte fixed header, which never changes

•

A 16-byte Initialization Vector (IV) used by the encryption / decryption algorithm

•

A single byte containing the key ring position for the ACC Key. This allows for key rolls of the ACC Key as described in ACC Key Management on page 120.

The next 16 bytes are always encrypted with the ACC Key. They contain the following information: •

The length of the ACC-encrypted data

•

The length of the DCC-encrypted data

•

The key ring position of the DCC Key, required to allow key rolls.

Because these 16 bytes are encrypted, the proportion of the ACC to DCC data is hidden from an attacker. Compromise of the ACC Key can only jeopardize the acquisition information (i.e. who is acquiring). Once acquired, all traffic patterns are protected by the DCC Key. Because the DCC Key is protected by the RSA public/private keys, possession of the ACC Key does not allow an attacker to determine the DCC Key. The total length of encrypted data is always the same. If there is unused space in a BBFRAME, it is filled with random data and then encrypted. In some cases, the entire BBFRAME may consist of encrypted random data. The steps in the decryption process are: 1. The packet is recovered at the physical layer, including CRC checking. 2. The four-byte fixed header is checked. If it is not correct, the packet is discarded. 3. The 16 byte IV is loaded into the AES core. 4. The key ring position is used to select the correct ACC Key. 5. The first 16 bytes are decrypted and ACC and DCC lengths are extracted. 6. The AES core decrypts the ACC data (using CBC); the key is switched to the DCC Key; and the DCC data is decrypted. (The DCC Key ring position is used to select the appropriate key). The last 16 bytes of the ACC data serve as the IV of the DCC encrypted data.

112

Technical Reference Guide iDX Release 3.3

Upstream TRANSEC

7. The decrypted packet is processed in the normal fashion to extract the IP packets. At startup, the initial IV is the result of the Known Answer Test. For each subsequent BBFRAME, the last 16 bytes of encrypted data are used as the IV for the following BBFRAME.

Upstream TRANSEC All data for transmission on the upstream TDMA carrier starts as IP data packets. These packets are segmented by software into fragments that fit into the fixed size payloads of the TDMA bursts. This segmented data is segregated into two queues: one for ACC data and one for DCC data. A given TDMA burst only contains ACC or DCC data. All packets regardless of class are encrypted. The key used to encrypt the data varies depending on the packet’s queue. Packets extracted from the DCC queue are encrypted using the DCC Key. Packets extracted from the ACC queue are encrypted using the ACC Key. NOTE: TRANSEC is not supported on SCPC return channels.

Disguising Remote Acquisition The number of ACC-encrypted slots in a burst varies depending on whether or not the remote is acquiring the network. If unprotected, this variation would give an attacker the ability to determine whether or not the remote is acquiring the network. To prevent that, the following scheme (illustrated in Figure 18-2) is used to hide which key is used for any given burst.

Figure 18-2. Disguising Which Key is Used for a Burst

Technical Reference Guide iDX Release 3.3

113

Upstream TRANSEC

Each Code Field show in Figure 18-2 is an eight-bit (one byte) field with the following structure:

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

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

114

Technical Reference Guide iDX Release 3.3

Upstream TRANSEC

provide a robust IV for the TDMA burst, the last 256 bits of the previous TDMA burst are processed by the encryption engine with the DCC Key applied. This results in a new 128 bit value which cannot be linked to the previous burst. Figure 18-4 illustrates the generation of the upstream Initialization Vector.

Figure 18-4. Generating the Upstream Initialization Vector As illustrated in Figure 18-4, the following inputs are provided to the AES Core: •

The first 128 bits are provided to the IV Input.

•

The second 128 bits are provided to the Data Input.

•

The Key used for burst N+1 is provided to the Key Input.

The 128 bit Output is used as the IV for the next burst. While no logic is included to ensure that IVs do not repeat, the probability of repeating the same IV within a two-hour period is extremely small—roughly estimated to be 1 in 297 for a maximum data rate iDirect TDMA channel. NOTE: A random number from a FIPS-certified random number generator is used to generate the first TDMA IV.

Upstream TRANSEC Segment The upstream Segment is of fixed, configurable length and consists of the standard iDirect TDMA frame. A detailed description of the standard TDMA frame is beyond the scope of this discussion. In general, the iDirect TDMA frame consists of: •

The Demand Header (indicating the amount of bandwidth requested by the remote)

•

The Link Layer (LL) Header

•

The Payload

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

Technical Reference Guide iDX Release 3.3

115

ACQ Burst Obfuscation

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

Figure 18-5. Upstream ACQ Burst Obfuscation A remote responding to “dummy” invitations sends filler data encrypted with the Network Acquisition Key. The remote deliberately offsets the time, frequency, and transmit power of the burst to mimic a real acquisition attempt.

116

Technical Reference Guide iDX Release 3.3

TRANSEC Dynamic Key Management

The proportion of dummy ACQ bursts, deliberately-empty slots, and actual ACQ slots is controlled by the hub side equipment. A random function provides significant short and long term variation in activity, while also providing a minimum number of used and unused slots. After a network restart, all the remotes are out of the network. ACQ burst obfuscation does not operate until at least one remote per inroute has acquired the network. During this startup period, all of the ACQ slots contain real ACQ invitations. NOTE: Beginning with iDX Release 3.2.3, the “dead time” required to accommodate dummy ACQ bursts in TRANSEC networks was increased from 600 s to 1500 s. This results in ~0.72% additional decrease in upstream bandwidth due to ACQ burst obfuscation.

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

Figure 18-6. Key Distribution Protocol

Technical Reference Guide iDX Release 3.3

117

TRANSEC Dynamic Key Management

Figure 18-6 assumes that upon the receipt of a certificate from a peer, the host is able to validate and establish a chain of trust based on the contents of the certificate. iDirect uses standard X.509 certificates and methodologies to verify the peer’s certificate. After the completion of the sequence described in Figure 18-6, a peer may provide an unsolicited key update message as required. The data structure used to complete the key update (also called a “Key Roll”) is described in Figure 18-7.

Figure 18-7. Key Roll Data Structure This data structure shown in Figure 18-7 consists of: •

A set of pointers (Current, Next, Fallow)

•

A two-bit identification field used in the Encryption Headers

•

The Symmetric Keys

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

118

Technical Reference Guide iDX Release 3.3

TRANSEC Dynamic Key Management

Figure 18-8 describes the iDirect Host Keying Protocol.

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

Technical Reference Guide iDX Release 3.3

119

TRANSEC Remote Admission Protocol

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

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

120

Technical Reference Guide iDX Release 3.3

Automatic Beam Selection (ABS) and TRANSEC

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

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

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

Technical Reference Guide iDX Release 3.3

121

Automatic Beam Selection (ABS) and TRANSEC

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

122

Technical Reference Guide iDX Release 3.3

19 Remote Sleep Mode

The Remote Sleep Mode feature conserves remote power consumption during periods of network inactivity. This chapter explains how Remote Sleep Mode is implemented. It includes the following sections: •

Feature Description on page 123

•

Awakening Methods on page 124

•

Enabling Remote Sleep Mode on page 124

•

Power Consumption on page 125 NOTE: Sleep Mode is intended for use by non-roaming remotes with occasional transmissions. It is not compatible with the Roaming Remote or Alternate Downstream Carrier features.

Feature Description The Remote Sleep Mode feature automatically powers down the BUC when the remote has no data to transmit to conserve power. When Sleep Mode is enabled on the iBuilder GUI for a remote, the remote enters Remote Sleep Mode after a configurable period elapses with no data to transmit. By default, the remote exits Remote Sleep Mode whenever packets arrive on the local LAN for transmission on the inbound carrier. NOTE: The remote console commands powermgmt mode set sleep and powermgmt mode set wakeup enable and disable remote sleep mode. The stimulus for a remote to exit sleep mode is also configurable in iBuilder. The Network Operator can select which types of traffic automatically “trigger wakeup” on the remote by selecting or clearing a check box for the any of the QoS service levels used by the remote. If no service levels are configured to trigger wakeup the remote, the operator can manually force the remote to exit sleep mode by disabling sleep mode on the remote configuration screen. Before a remote enters sleep mode, the protocol processor continues to allocate traffic slots (including minimum CIR) to the remote. Before it enters sleep mode, the remote notifies the NMS and the real time state of the remote is updated in iMonitor. Once the remote enters sleep mode, as far as the protocol processor is concerned, the remote is out of the network. Therefore, no traffic slots are allocated to the remote while it is in sleep mode. When the

Technical Reference Guide iDX Release 3.3

123

Awakening Methods

remote receives traffic that triggers wakeup, the remote returns to the network and traffic slots are allocated as normal by the protocol processor.

Awakening Methods There are two methods by which a remote is “awakened” from Sleep Mode. They are “Operator-Commanded Awakening”, and “Activity-Related Awakening”.

Operator-Commanded Awakening With Operator Command Awakening, a Network Operator can manually force a remote into Remote Sleep Mode and subsequently “awake” it from the NMS. This can be done remotely from the Hub since the remote continues to receive the downstream while in sleep mode.

Activity Related Awakening With Activity-Related Sleep Awakening, the remote enters Remote Sleep Mode after a configurable period elapses with no data to transmit. The remote “wakes up” as soon as it receives traffic with these service level markings. When a remote is reset, the activity timer also resets. When the remote sees no traffic that triggers the wake up condition for the configured sleep time-out, it goes into Remote Sleep Mode. In this mode, all the IP traffic that does not trigger a wake up condition is dropped. When a packet with the service level marking that triggers a wakeup is detected, the remote resets the sleep timer and wakes up. In Remote Sleep Mode, the remote processes the burst timeplans but it does not apply them to the firmware. No indication is sent to the remote’s router that the interface is down, and therefore the packets from the local LAN are still passed to the remote’s distributor queues. Packets that would wake up the interface will not be dropped by the router and are available to the layers that process this information. The protocol layer that manages the sleep function drops the packets that do not trigger the wakeup mode. Power consumed by the remote under normal and low power (Sleep Mode) is shown in Table Table 19-1 on page 125.

Enabling Remote Sleep Mode Remote Sleep Mode can be enabled or disabled in iBuilder on the Remote Information tab. The service levels that trigger the remote to wake up are also configurable. A sleep time-out period is configurable for each remote. The sleep time-out is the period of inactivity after which the remote enters low power mode. With Sleep Mode enabled on the Remote QoS tab, the remote will conserve power by disabling the 10 MHz reference for the BUC after the specified number of seconds have elapsed with no remote upstream data transmissions. A remote should automatically wake from sleep mode when packets arrive for transmission on the upstream carrier, provided that Trigger Wakeup is selected for the service level associated with the packets. In some earlier releases that supported Sleep Mode, the SAT0 custom key was required to force remotes to wake from sleep mode when packets arrived for transmission that matched a

124

Technical Reference Guide iDX Release 3.3

Power Consumption

service level with Trigger Wakeup selected. This is now the default behavior for remotes in Sleep Mode, so the SAT0 custom key is no longer necessary. NOTE: When Sleep Mode is enabled, a remote with RIP enabled will always advertise the satellite route as available on the local LAN, even if the satellite link is down. Therefore, the Sleep Mode feature is not compatible with configurations that rely on the ability of the local router to detect loss of the satellite link. To enable Remote Sleep Mode, see the chapter on configuring remotes in the iBuilder User Guide. To configure service level based wake up, see the QoS Chapter in the iBuilder User Guide.

Power Consumption Examples of the power consumed by typical remote terminals during both normal operation and sleep mode is shown in Table 19-1. Table 19-1. Power Consumption: Normal Operations vs. Remote Sleep Mode

Technical Reference Guide iDX Release 3.3

125

Power Consumption

126

Technical Reference Guide iDX Release 3.3

20 Remote Acquisition

This chapter describes how remotes join iDirect TDMA networks. The network acquisition process requires the remote to transmit one or more acquisition bursts at various frequencies on a dynamically assigned inroute until the hub line card successfully demodulates a burst. At that point, the Uplink Control Process takes over to keep the remote in the network. The protocol processor at the hub controls the acquisition process.

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

Technical Reference Guide iDX Release 3.3

127

Acquisition Process

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

128

•

Acquisition over Spread Spectrum upstream carriers

•

Acquisition in TRANSEC networks

•

Acquisition on upstream carriers received by single channel line cards except receive-only eM1D1 line cards configured for Single Channel TDMA (Adaptive) Receive Mode.

Technical Reference Guide iDX Release 3.3

Acquisition Algorithm

•

Acquisition on upstream carriers received by multichannel line cards in Single Channel TDMA Receive Mode

•

Acquisition on upstream carriers received by Evolution XLC-M line cards with more than eight assigned narrow-band carriers NOTE: By default, Superburst Acquisition is used whenever possible. However, if Superburst is disabled for the carrier in iBuilder, the remotes revert to Traditional Acquisition.

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

Technical Reference Guide iDX Release 3.3

129

Superburst Acquisition

entire acquisition frequency range each time. In IF networks, such as those used in test environments, the 10 MHz reference clock is not used.

Superburst Acquisition Beginning with iDX Release 3.2, remotes can use Superburst Acquisition to acquire the network on non-spread upstream carriers received by multichannel line cards or by receiveonly eM1D1 line cards. To use Superburst Acquisition, the Receive Mode of a multichannel line card must be set to Multiple Channel TDMA Mode in iBuilder. The Receive Mode of a receiveonly eM1D1 line card must be set to Single Channel TDMA (Adaptive). Superburst is not available for carriers received by any other Line Card Types in any other Receive Modes. A maximum of eight TDMA upstream carriers with Superburst enabled can be assigned to one multichannel line card. In addition, all carriers received by a multichannel line card must be configured for the same type of acquisition bursts. Superbursts and traditional acquisition bursts cannot be received simultaneously by the same line card. An Evolution XLC-M line card can receive up to 16 narrowband carriers. Since a multichannel line card cannot receive more than eight carriers with Superburst enabled, an XLC-M line card receiving more than eight carriers must use iDirect’s Traditional Acquisition for all carriers.

Advantages of Superburst Superburst Acquisition represents a significant improvement when compared to iDirect’s Traditional Acquisition. Superburst allows a remote to quickly acquire the network under clear sky or fade conditions in much less time than Traditional Acquisition. This improvement is due to the robust nature of the Superburst waveform and the frequency tolerance of the Superburst demodulator. When using iDirect’s Traditional Acquisition, the frequency detection of the TDMA demodulator at the hub is limited to a frequency offset of 1.5% of the symbol rate. Due to frequency inaccuracies throughout the satellite system (mainly caused by the instability of hub downconverter), the remote must sweep in discrete frequency steps until the demodulator detects a burst. Because of the limited detection range, remotes typically transmit a number of bursts during the sweep that are not detected. This results in a significant number of allocated acquisition slots that do not result in remote acquisition. Additionally, the traditional acquisition bursts are identical to traffic bursts. Therefore there is no additional frequency tolerance or C/N performance that the demodulator can take advantage of to detect a remote’s burst more quickly. Superburst Acquisition addresses both the narrow tolerance for frequency offset and the disadvantages of transmitting the acquisition burst at the same MODCOD as the upstream traffic bursts. Superbursts are transmitted using a unique, robust waveform that is independent of the MODCOD of the upstream carrier. Superburst increases upstream symbol rate frequency tolerance from 1.5% to 7.5% of the upstream symbol rate. In addition, the hub can reliably detect a Superburst with receive C/N between –2.5 dB and +20 dB. Because of these improvements, the hub usually detects a remote’s first Superburst. In that case the remote acquires the network on the first attempt and no frequency sweeping is required. However, in rare cases (for example at low symbol rates with large hub downconverter instability), a remote may need to transmit a small number of additional Superbursts to acquire the network. Typically, a sweep requires no more than a few steps.

130

Technical Reference Guide iDX Release 3.3

Superburst Acquisition

NOTE: More acquisition attempts may be required in the case of high-speed mobile remotes due to the high Doppler shift.

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

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

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

Ability to Acquire When No Traffic Carrier Is Available When a Superburst is received from a remote, the protocol processor determines the appropriate nominal carrier for the remote in the inroute group. In making this selection, the protocol processor considers measurements made on the Superburst; information sent in the Superburst; and the remote’s configuration.

Technical Reference Guide iDX Release 3.3

131

Superburst Acquisition

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

132

Technical Reference Guide iDX Release 3.3

21 Automatic Beam Selection This section contains information pertaining to Automatic Beam Selection (ABS) for roaming remotes.

Automatic Beam Selection Overview An iDirect network is defined as a single outroute and one or more inroutes, all operating with one satellite and one hub. A Network Management System (NMS) can manage and control multiple networks. This chapter also uses the term “beam” to refer to an iDirect outroute and its associated inroutes. iDirect remotes can “roam” from network to network around the globe. These roaming remotes are not constrained to a single location or limited to any geographic region. Instead, by using the capabilities provided by the iDirect “Global NMS” feature, remote terminals have global IP access. The decision of which network (or beam) a particular remote joins is made by the remote. When joining a new beam, the terminal must re-point its antenna and the remote modem must tune to a new outroute. Selection of the new beam can be performed automatically using ABS or manually by using remote modem console commands. This chapter describes how Automatic Beam Selection is implemented in an iDirect system. For detailed information on configuring and monitoring roaming remotes, see the iBuilder User Guide and iMonitor User Guide. For additional information on the ABS feature, see the appendix “Configuring Networks for Automatic Beam Selection” in the iBuilder User Guide. If using the iDirect TRANSEC feature for ABS networks, Global Key Distribution is required to ensure that the Network Acquisition Keys are the same for all networks. A remote cannot roam from one TRANSEC network to another unless these keys are the same. For details, see the Appendix “Global Key Distribution” in the iBuilder User Guide. If the mobile remotes in an ABS network exceed 150 mph, they must be licensed for the HighSpeed COTM feature. In addition, high-speed remotes require special configuration. For details, see the appendix “COTM Settings and Custom Keys” in the iBuilder User Guide. Mobile remotes that exceed 150 mph must licensed for the High-Speed COTM feature. In addition, high-speed remotes require special configuration. For details, see the appendix “COTM Settings and Custom Keys” in the iBuilder User Guide. NOTE: Automatic Beam Selection is not supported on Evolution X1, X3 or e150 remotes.

Technical Reference Guide iDX Release 3.3

133

Theory of Operation

Theory of Operation ABS is built on iDirect’s existing mobile remote functionality. When a remote is in a particular beam, it operates as a traditional mobile remote in that beam.

Overview In an ABS system, a roaming remote terminal consists of an iDirect remote modem and a controllable, steerable, stabilized antenna. The ABS software in the remote modem can command the antenna to find and lock to any satellite. Using iBuilder, a Network Operator defines an instance of the remote in each beam that the remote is permitted to use. The operator configures and monitors all instances of the remote as a single entity. The “consoldated” remote options file (which conveys configuration parameters to the remote from the NMS) contains the definition of each of the remote’s beams. Consolidated options files are described in the iBuilder User Guide. As a remote moves from one beam to another, the remote must switch from its current beam to the new beam. Automatic Beam Selection enables the remote to select a new beam, decide when to switch to the new beam, and to perform the switch, without human intervention. ABS logic in the remote reads the current location from the antenna and decides which beam will provide optimal performance for that location. The remote selects the new beam based either on a beam map or, if no map is available, using a round-robin selection algorithm. This selection is made by the remote, rather than by the NMS, because the remote must be able to select a beam even if it is not in any iDirect network.

iDirect Beam Map File and Map Server Before joining a network, the remote must determine the best beam to use in its current location. Once acquired, the remote may move to a higher-quality beam if one is available. In both cases, the remote relies on a beam map file to determine the best beam. The beam map file is a large data file containing beam quality transmit power information for each point on the Earth's surface as computed by the Satellite Provider. Sections of the beam map file (called beam maplets) are downloaded from the NMS to the remote and stored in non-volatile memory on the remote. In an ABS system, a map server is responsible for managing the iDirect beam maps for the remotes in its networks. The map server reads the beam maps and responds to map requests from remotes. A single map server may be deployed (for example, on the NMS server machine) or multiple instances of the map server may be deployed on processors that are colocated with the remotes. Maritime applications typically use a map server at the hub, while avionics applications typically require a local map server for each remote. The details depend on the application. Prior to iDX Release 3.0, when the iDirect NMS services started on an NMS server machine, the map server was automatically started with the other NMS processes. Beginning with iDX Release 3.0, the map server is no longer an NMS process. Now, the map server runs as a separate, stand-alone application. A remote has a limited amount of non-volatile storage, so it cannot save an entire map of all beams. Instead, the remote asks the map server to send a map of a smaller area (called a beam “maplet”) that encompasses its current location. When the remote nears the edge of its current maplet, the remote sends a request to the map server for a new maplet centered on

134

Technical Reference Guide iDX Release 3.3

Theory of Operation

its new location. The geographical size of the beam maplets varies in order to keep the file size approximately constant. A typical beam maplet covers approximately 1000 km square with 0.1 degree resolution. From the maplet, the remote determines the Beam Quality and Tx Gain for each beam at its current location. The Beam Quality depends on the geographic location of the remote. To decide which beam to join, the remote looks up the Beam Quality for each beam at its current location. When first acquiring a network, the remote uses the Beam Quality of the various beams as inputs to a decision algorithm that selects the best beam. Once the remote has joined a beam, it periodically compares the Beam Quality of other networks to the current Beam Quality. When the Beam Quality on an alternate beam is higher than the current Beam Quality (plus an additional hysteresis for stability), the remote automatically switches to the alternate beam. By default, a remote always attempts to join any beam included in the beam map file if that beam is determined to be the best choice available. This includes beams with a Beam Quality value of zero for the remote’s current location. However, selecting “Inhibit Tx (when Beam Quality = 0)” in the iBuilder Network dialog box configures the network so that remotes never attempt to join a beam if the quality of the beam at the current location is zero. See the iBuilder User Guide for instructions on configuring a network in iBuilder. For details on configuring and running a map server, see the appendix “Configuring Networks for Automatic Beam Selection” in the iBuilder User Guide.

Beam Selection The remote uses the Beam Quality of its current location to determine which beam to use. The following rules apply: •

If the remote has not joined a network, it attempts to enter the beam with the highest Beam Quality number. If it fails to do so after a configured timeout period, it cycles through the lower Beam Quality beams in order.

•

If a remote is already in a network, it switches beams if there is a beam with a Beam Quality that is higher than the current Beam Quality plus an offset known as the quality hysteresis. The quality hysteresis is defined in the map file header.

•

A Beam Quality of 0 is a special value indicating that the beam is not usable at the current location due to lack of coverage and/or geopolitical constraints. (See Regulatory Considerations on page 136.)

The Tx Gain values read by the remote from the beam map are used in two ways: •

When the remote is attempting to acquire the network, it adjusts the initial transmit power based on the Tx Gain of the current location. This allows the system to compensate for G/T variations of the satellite. (See Initial Transmit Power on page 139 for details.)

•

A Tx Gain of 0 indicates that the beam is receive-only at this location. The remote will remain in the beam if it is locked on the downstream carrier. However, the remote will not attempt to establish a return link. This feature can be used to designate receive-only geographic areas. (See Regulatory Considerations on page 136.)

Technical Reference Guide iDX Release 3.3

135

Theory of Operation

Conveyance Beam Map File Whenever a new beam is required by remotes using ABS, the Satellite Provider must generate new map data in a pre-defined format referred to as a “conveyance beam map file.” The conveyance file contains information on Beam Quality, Tx Gain, and (optionally) regulatory restrictions for areas within the satellite footprint of the beam. A conveyance beam map file must be in one of two formats: •

The GXT format is an open standard developed by iDirect. The GXT format is specified in the iDirect GXT Map Converter User Guide.

•

The Intelsat format is proprietary. Conveyance beam map files in this format can only be provided by Intelsat Corporation. NOTE: In order to use the iDirect ABS feature, the Satellite Provider must enter into an agreement with iDirect to provide the beam map data in a supported conveyance file format.

iDirect provides a utility that converts the conveyance beam map file from the Satellite Provider into a beam map file that can be used by the iDirect system. Instructions for converting a conveyance beam map file into an iDirect beam map are contained in the iBuilder User Guide appendix “Configuring Networks for Automatic Beam Selection.” Beginning in iDX Release 3.2, the system uses the Tx Gain contours when calculating C/N adjustments used to determine the maximum C/N at which a remote can be received at its current location. Because of this, the minimum Tx Gain contour for all beams in the generated beam map should be set to zero. When using the GXT format for conveyance beam maps, this can be accomplished by setting the gain_offset in the GXT header file such that the minimum Tx Gain of each beam as defined in the beam’s gain file plus the gain_offset for that beam equals zero. The formats of the GXT header file and gain files are defined in the iDirect GXT Map Converter User Guide.

Regulatory Considerations iDirect supports the use of separate GXT data files for reading Beam Quality and Tx Gain information into the iDirect GXT Map Converter utility used for creating beam maps. The GXT Map Converter also supports the input of geo-political or regulatory constraints. The regulatory file input uses the same GXT data format as Beam Quality and Tx Gain data files. The regulatory input creates “regulatory contours” in the resulting beam map file. A regulatory contour restricts the service for all beams in the specified area. This avoids the necessity of individually editing each conveyance beam map file. The GXT data file format and its use are described in the iDirect GXT Map Converter User Guide. The two types of regulatory contours are Do Not Operate and Do Not Transmit. A Tx Gain of 0 for a regulatory contour means Do Not Operate. A Tx Gain of 1 for a regulatory contour means Do Not Transmit. A Do Not Transmit contour defines a receive-only area for multicast traffic. This disables remote transmissions in the specified area. Examples of when Do Not Transmit contours can be useful include:

136

•

Some Ku band transmissions are prohibited near radio telescope installations.

•

Some regulatory restrictions limit transmissions over a specific country, even when the satellite beam covers more than that country.

Technical Reference Guide iDX Release 3.3

Theory of Operation

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

Beam Characteristics: Visibility and Usability The remote can determine two characteristics of each beam even without the map: •

A beam is defined as visible if the look angle to the satellite is greater than the minimum look angle. (A remote uses the minimum look angle defined for the satellite in iBuilder unless it is overridden for the remote on the Remote Geo Location tab. See the appendix “Configuring Networks for Automatic Beam Selection” in the iBuilder User Guide for details.)

•

A beam is usable unless an attempt to use it fails. A beam is considered unusable for a period of one hour after the failure, or until all visible beams are unusable.

Technical Reference Guide iDX Release 3.3

137

Theory of Operation

NOTE: A custom key is required to change the length of time that a remote considers beams to be unusable. (See the appendix “Configuring Networks for Automatic Beam Selection” in the iBuilder User Guide for details.) If the selected beam is unusable, the remote attempts to use another beam, provided one or more usable beams are available. A beam can become unusable for many reasons, but each reason ultimately results in the inability of the remote to communicate with the outside world using the beam. Therefore the only usability check is based on the “layer 3 state” of the satellite link, such as whether or not the remote can exchange IP data with the upstream router. Examples of events that can cause a beam to become unusable include: •

The NMS operator disables the remote instance in iBuilder.

•

A Hub Line Card fails with no available backup.

•

The Protocol Processor fails with no backup.

•

A component in the upstream or downstream RF chain fails.

•

The satellite fails.

•

The beam is reconfigured.

•

The remote cannot lock to the downstream carrier.

•

The receive line card stops receiving the remote.

Unless the remote is in receive-only mode, anything that causes the remote to stop transmitting and the receive line card to stop receiving the remote, eventually causes Layer 3 to fail. The remote stops transmitting if it loses downstream lock. A mobile remote will also stop transmitting under the following conditions: •

The remote has not acquired the beam and no GPS information is available.

•

The remote antenna declares loss-of-lock.

•

The antenna declares a blockage.

•

Beam map data places the remote in receive-only mode.

•

The remote has been configured as Rx Only in iBuilder.

Selecting a Beam without a Map Under certain circumstances the remote may not have a beam maplet that covers its current location. When this occurs, the remote uses a round-robin selection algorithm, trying each visible, usable beam defined in its options file in turn for five minutes until the remote joins a network. This can occur under various conditions:

138

•

When a remote is being commissioned.

•

If the remote travels with the modem turned off and must locate a beam when returned to service.

•

If the remote cannot remain in the network for an extended period due to blockage or network outage.

•

If the map server is unreachable.

Technical Reference Guide iDX Release 3.3

Theory of Operation

In all cases, after the remote establishes communications with the map server, it immediately asks for a new maplet. When a maplet becomes available, the remote uses the maplet to compute the optimal beam, and switches to that beam if it is not the current beam. NOTE: By default, remotes continue to operate without a map as described above. However, a remote custom key can be configured that tells the remote to mute its transmitter when the remote does not have a maplet that covers its current location. See the appendix “Configuring Networks for Automatic Beam Selection” in the iBuilder User Guide for details.

Controlling the Antenna To make the system work, the remote must be able to control the antenna. The remote software communicates with the antenna control unit supplied with the antenna over the local LAN. The following antenna protocols are currently supported: •

Open AMIP

•

Orbit-Marine AL-7104

•

Schlumberger SpaceTrack 4000

•

SeaTel DAC

OpenAMIP is an ASCII-based protocol developed by iDirect used to exchange information between the remote modem and an antenna controller. It allows the remote modem and controller to exchange the information necessary for the remote to initiate and maintain satellite communications via the antenna. The OpenAMIP protocol is defined in the document titled Open Antenna — Modem Interface Protocol (AMIP) Specification. A steerable, stabilized antenna must know its geographical location in order to point the antenna. The antenna includes a GPS receiver for this purpose. The remote must also know its geographical location to select the correct beam and to compute its distance from the satellite. The remote periodically requests the current location from the antenna controller.

IP Mobility Communications to the customer intranet (or to the Internet) are automatically reestablished after a beam switch. The process of joining the network after a new beam is selected uses the same internet routing protocols that are already established in the iDirect system. When a remote joins a beam, the Protocol Processor for that beam begins advertising the remote's IP addresses to the upstream router using the RIP protocol. When a remote leaves a beam, the Protocol Processor for that beam withdraws the advertisement for the remote's IP addresses. When the upstream routers see these advertisements and withdrawals, they communicate with each other using the appropriate IP protocols to update their routing tables. This permits other devices on the Internet to send data to the remote over the new path with no manual intervention.

Initial Transmit Power The optimal initial transmit power that a remote should use for acquisition bursts transmitted on the TDMA upstream carriers varies with geographic location. As the remote moves across the satellite footprint, or when it switches to a new beam, the EIRP budgeted for the link changes.

Technical Reference Guide iDX Release 3.3

139

Theory of Operation

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

Calculation of Initial Transmit Power The remote considers the following values when calculating the initial transmit power: •

The Tx Gain budgeted for the link at the current location as read from the beam map

•

The Initial Transmit Power Offset determined at commissioning and configured on the iBuilder Remote VSAT tab. (See Setting the Initial Transmit Power Offset on page 140.)

•

If applicable, the variation in antenna gain for the satellite elevation at the remote’s current location. This value is interpolated from the set of discrete Elevation / Gain pairs configured in the iBuilder Reflector dialog box.

During acquisition, the remote performs the following steps to determine the transmit power: 1. The remote retrieves the Tx Gain for the current location from the beam map. 2. The remote subtracts the Tx Gain for the current location from the configured Initial Transmit Power Offset to determine the initial transmit power. 3. If Elevation / Gain pairs are configured for the Reflector then: a. The remote calculates the satellite elevation based on geographic location. b. The remote calculates the gain variation of the antenna for the elevation using the data points provided in the options file. c. The remote adjusts the initial power computed in Step 2 to account for the gain variation. Once the remote has acquired the carrier, the UPC algorithm takes over to regulate the transmit power during operation. NOTE: If the beam map is not available, the remote uses the TDMA Initial Power configured on the Remote Information Tab to acquire the beam rather than the Initial Transmit Power Offset.

Setting the Initial Transmit Power Offset The Initial Transmit Power Offset is determined at remote commissioning after the remote has acquired the downstream carrier using the standard commissioning procedure. The commissioning options file should be pre-configured with an Initial Tx Power Offset of –30 dB.

140

Technical Reference Guide iDX Release 3.3

Theory of Operation

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

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

Figure 21-2. Remote VSAT Tab: Entering the Initial Transmit Power Offset 6. The Network Operator saves and applies the iBuilder configuration changes.

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

Technical Reference Guide iDX Release 3.3

141

Theory of Operation

differ between beams, it is not possible to infer the value for one beam automatically from that used for the commissioning. The network designer or network operator must determine an appropriate value for the additional beams and configure them separately in iBuilder. Because the gain values retrieved from the map represent the receive sensitivity (G/T) of the satellite, if the link budget is uplink-dominated, the necessary adjustment in the Initial Transmit Power Offset value between beams is equal to the difference in absolute value of the G/T between the beams. The following example illustrates this. Absolute Contours

Generated Map

-3 dB/K

0 dB

+1 dB/K

+4 dB

Beam A: X

X

+2 dB/K 0 dB +4 dB/K +2 dB Beam B:

Y

Y

Figure 21-3. Absolute vs. Generated G/T Contours for Two Beams Figure 21-3 shows two beams: Beam A and Beam B. The two diagrams on the left show the absolute G/T contours for the beams, as obtained from the satellite operator. The generated map defines the edge of coverage for each beam as the 0 dB contour. The G/T contours of the generated map are shown on the right for each beam. Assume the remote is commissioned in Beam A at point X and that the steady-state power observed is –10 dBm. (All power levels used in this example are normalized to the reference carrier). The beamselector txpower offset command used to determine the offset will return a value of –6 dBm, corresponding to the power that would be needed if the acquisition took place at the edge of coverage. During actual acquisition attempts in Beam A, the remote automatically adjusts for the location so that the power used is appropriate. If the same power setting were used to attempt to acquire in Beam B, the bursts would likely arrive at a too high level, potentially causing interference or over-driving the satellite and/or the demodulator. For example, if the remote attempted to acquire at location Y with the same power setting as in Beam A, then the transmit power would be –8 dB, which is 2 dB lower than the edge-of-beam value.

142

Technical Reference Guide iDX Release 3.3

Theory of Operation

If the difference in G/T is the only difference between the link budgets for these two beams (for example, if both beams are dominated by the uplink), then the bursts in beam B will arrive at a level corresponding to the difference in the edge-of-beam G/T. In that case, the network designer can conclude that the Initial Transmit Power Offset value for beam B should be 5 dB lower than that used for beam A, or –11 dBm. At point Y the acquisition power used would be –13 dBm. If there are other factors influencing the inbound link budget, a more detailed assessment of the differences between the beams may be appropriate for determining the Initial Transmit Power Offset value, or the remote should be commissioned separately in each beam.

Receive-Only Mode for ABS Remotes If a remote is placed in receive-only mode, the remote stops transmitting on the upstream TDMA carrier but continues to receive the downstream carrier and remains in the network. A remote in receive-only mode does not transmit, but it does receive and forward multicast traffic. Typically, remotes using the ABS feature are placed in receive-only mode based on data read from the beam map. Specifically, if the Tx Gain of the remote’s current location on the map is zero, then the remote will not transmit. This allows the reception of broadcasts in geographic regions where transmission is prohibited by regulation. (See Regulatory Considerations on page 136 for more information.) NOTE: This feature can be disabled on a remote by entering a custom key. See the appendix “Configuring Networks for Automatic Beam Selection” in the iBuilder User Guide for details. A remote may also be configured as Rx Only on the iBuilder Remote Information tab. This is a general feature and is not restricted to remotes using the ABS feature. If a remote is configured as Rx Only in iBuilder, the remote will never transmit.

Multiple Map Servers per Network Prior to iDX Release 3.0, an ABS network was limited to a single map server process running at the NMS that supplied the beam map data to all remotes. This restriction has been removed. To enable receive-only operations, and for general system robustness, the system supports multiple map servers per network. This allows the deployment of a local map server for each remote. When the ABS feature is enabled at the NMS, a single IP address is configured for the map server process running at the NMS. That IP address is then downloaded to the remotes in their options files and used by the remote to communicate with the map server. To run a local version of the map server, override the map server IP address in the remote’s option file by entering a remote-side custom key defining the local map server’s IP address within the private address space of the remote. This custom key must be applied to each remote with a local map server. (See the appendix “Configuring Networks for Automatic Beam Selection” in the iBuilder User Guide for the definition of this custom key.)

Technical Reference Guide iDX Release 3.3

143

Operational Scenarios

Operational Scenarios This section presents a series of top-level operational scenarios that can be followed when configuring and managing iDirect networks that contain roaming remotes using Automatic Beam Selection. Steps for configuring network elements such as iDirect networks (beams) and roaming remotes are documented in iBuilder User Guide. Steps specific to configuring ABS functionality, such as adding an ABS-capable antenna or converting a conveyance beam map file, are described in the appendix “Configuring Networks for Automatic Beam Selection” in the iBuilder User Guide.

Creating the Network This scenario outlines the steps that must be performed by the customer, the Satellite Provider, and the Network Operator to create a network that uses ABS. 1. The Customer and Satellite Provider agree on the set of beams (satellites, transponders, frequencies and footprints) to be used by remotes using ABS. 2. The Satellite Provider enters into an agreement with iDirect specifying the format of the conveyance beam map file. 3. The Satellite Provider supplies the link budget for the hub and remotes. 4. iDirect delivers the map conversion program to the customer specific to the conveyance beam map file specification. 5. The Satellite Provider delivers to the customer one conveyance beam map file for each beam that the customer will use. 6. The customer orders and installs all required equipment and an NMS. 7. The NMS operator configures the beams (iDirect networks). 8. The NMS operator runs the conversion program to create the server beam map file from the conveyance beam map file or files. 9. The NMS operator runs the map server as part of the NMS or independently.

Adding a Remote This scenario outlines the steps required to add a roaming remote using ABS to all available beams. 1. The NMS operator configures the remote in one beam. 2. The NMS operator adds the remote to the remaining beams. 3. The NMS operator saves the remote's options file and delivers it to the installer. 4. The installer installs the remote. 5. The installer copies the options file to the remote using iSite. 6. The installer manually selects a beam for commissioning. 7. The remote commands the antenna to point to the satellite. 8. The remote receives the current location from antenna.

144

Technical Reference Guide iDX Release 3.3

Operational Scenarios

9. The installer commissions the remote in the initial beam. 10. The remote enters the network and requests a maplet from the NMS map server. 11. The remote checks the maplet. If the commissioning beam is not the best beam, the remote switches to the best beam as indicated in the maplet. This beam is then assigned a high preference rating by the remote to prevent the remote from switching between overlapping beams of similar quality. 12. Assuming center beam in clear sky conditions: a. The installer determines the Initial Transmit Power Offset as discussed in Setting the Initial Transmit Power Offset on page 140. b. The Network Operator sets the Initial Transmit Power Offset in iBuilder on the Remote VSAT tab. c. The Network Operator sets the TDMA Maximum Power to 6 dB above the nominal transmit power in iBuilder on the Remote Information tab. NOTE: Check the levels the first time the remote enters each new beam and adjust the transmit power settings if necessary.

Normal Operations This scenario describes the events that occur during normal operations when a remote is receiving map information from the NMS. 1. As the remote moves, it periodically receives the current location from antenna. 2. While in the beam, the antenna automatically tracks the satellite. 3. As the remote approaches the edge of the current maplet, it requests a new maplet from the map server. 4. When the remote reaches a location where the maplet shows a better beam, the remote switches by doing the following: a. Computes best beam. b. Saves best beam to non-volatile storage. c. Commands the antenna to move to the correct satellite and beam. d. Reboots. e. Reads the new best beam from non-volatile storage. f.

Again commands the antenna to move to the correct satellite and beam. NOTE: This command is repeated after reboot because the remote is not aware of the reason for restart. The antenna controller ignores the repeated command since it has already been commanded to track this beam in Step c.

g. Joins the new beam.

Mapless Operations This scenario describes the events that occur during operations when a remote is not receiving beam mapping information from the NMS.

Technical Reference Guide iDX Release 3.3

145

Operational Scenarios

1. While operational in a beam, the remote periodically asks the map server for a maplet. The remote does not attempt to switch to a new beam unless one of the following conditions are true: a. The remote drops out of the network. b. The remote receives a maplet indicating that a better beam exists. c. The satellite drops below the minimum look elevation defined for that beam. 2. If not acquired, the remote selects a visible, usable beam based only on satellite longitude and attempts to switch to that beam. 3. After five minutes (by default), if the remote is still not acquired, it marks the new beam as unusable and selects the best beam from the remaining visible, usable beams in the options file. This step is repeated until the remote is acquired in a beam, or all visible beams are marked as unusable. 4. If all visible beams are unusable, the remote marks them all as usable, and continues to attempt to use each beam in a round-robin fashion as described in step 3.

Blockages and Beam Outages This scenario describes the events that occur when a remote cannot join or loses the selected beam. 1. If the remote fails to join the selected beam after five minutes, it marks the beam as unusable and selects a new beam based on the maplet. 2. If the remote loses network connectivity for five minutes, it marks the current beam as unusable and selects a new beam based on the maplet. 3. Any beam marked as unusable remains unusable for an hour (by default) or until all beams are marked as unusable. 4. If only the current beam is visible, the remote will not attempt to switch from that beam, even after losing connectivity for five minutes.

Error Recovery This section describes the actions taken by the remote under certain error conditions. 1. If the remote cannot communicate with the antenna and is not acquired into the network, it will reboot after five minutes. If the antenna is initializing, the remote waits for the initialization to complete. It will not attempt to switch beams during this time.

146

Technical Reference Guide iDX Release 3.3

22 Hub Geographic Redundancy This chapter describes how to establish a primary and back up hub that are geographically diverse. It includes the following sections: •

Section , Feature Description describes how geographic redundancy is accomplished.

•

Section , Configuring Wait Time Interval for an Out-of-Network Remote describes how to set the wait period before switchover.

Feature Description The Hub Geographic Redundancy feature builds on the Global NMS feature and the existing Backup and Restore utilities. The Network Operator configures the Hub Geographic Redundancy feature by defining all the network information for both the Primary and Backup Teleports in the Primary NMS. All remotes are configured as roaming remotes and they are defined identically in both the Primary and Backup Teleport network configurations. During normal (non-failure) operations, carrier transmission is inhibited on the Backup Teleport. During failover conditions (when roaming network remotes fail to see the downstream carrier through the Primary Teleport NMS) the operator can manually enable the downstream transmission on the Backup Teleport, allowing the remotes to automatically acquire the downstream transmission through the Backup Teleport NMS. Re-acquisition occurs after a wait period that defaults to five minutes. iDirect recommends the following for most efficient switchover: •

A separate IP connection (at least 128 Kbps) between the Primary and Backup Teleport NMS for database backup and restore operations. A higher rate line can be employed to reduce this database archive time.

•

The downstream carrier characteristics for the Primary and Backup Teleports MUST be different. For example, either the FEC, frequency, frame length, or data rate values must be different.

•

On a periodic basis, backup and restore the NMS configuration database between the Primary and Backup Teleports. See the NMS Redundancy and Failover Technical Note for complete NMS redundancy procedures.

Technical Reference Guide iDX Release 3.3

147

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

Configuring Wait Time Interval for an Out-of-Network Remote If a roaming remote is configured at both a Primary and Backup Hub, and the remote loses the Downstream carrier from the Primary Hub, the remote attempts to lock to the downstream carrier from the Backup Hub, after a configured interval in seconds. By default this “wait time” before attempting the switch is 300 seconds (5 minutes). This wait time for beam switchover can be changed by setting the net_state_timeout custom key value (in seconds) to the desired wait period. For example, to make the wait period 10 minutes, use the following custom key: [REMOTE_DEFINITION] net_state_timeout=600 NOTE: Roaming is not supported on Evolution X1 remotes. Therefore, X1 remotes cannot automatically switch to a new downstream carrier. For further configuration information, see the chapter “Defining Network Components” in the iBuilder User Guide.

148

Technical Reference Guide iDX Release 3.3

23 Carrier Occupied Bandwidth This chapter discusses occupied bandwidth of iDirect carriers. Occupied bandwidth includes the actual carrier size plus the guard band required to prevent interference with adjacent carriers. Minimizing the guard band between adjacent carriers optimizes the use of the available satellite bandwidth. In earlier releases, iDirect required a minimum guard band of 20% of the carrier symbol rate for both upstream and downstream carriers. Beginning with iDX Release 3.2, the minimum guard band required for DVB-S2 downstream carriers has been reduced from 20% of the carrier symbol rate to 5% of the carrier symbol rate by reducing the roll-off factor of these carriers. This is discussed in detail in DVB-S2 Roll-Off Factors on page 151. This chapter includes the following sections: •

Overview describes the relationships among occupied bandwidth, guard band and information rate and factors to consider when setting the guard band.

•

DVB-S2 Roll-Off Factors describes the improvements to the iDirect downstream carrier wave form that allow reduced guard bands beginning with iDX Release 3.2.

•

Improving Throughput by Reducing Guard Band provides an example of how to increase the efficiency of the occupied bandwidth by reducing the guard band of DVB-S2 carriers.

•

DVB-S2 Guard Band Constraints specifies limitations of minimum symbol rates and MODCODs for DVB-S2 carriers with small guard bands.

•

Adjacent Channel Interference discusses the relationship between DVB-S2 Roll Off factor and interference on adjacent carriers.

Overview A lower guard band requirement between carriers makes it possible to fit a higher bit rate carrier into the same satellite bandwidth. Therefore, with a lower guard band requirement, a Network Operator can increase the bit rate of existing carriers without purchasing additional bandwidth. Optimized digital filtering is used in the iDirect transmit firmware to minimize the amount of satellite bandwidth required for an iDirect carrier. For upstream carriers, iDirect supports a guard band as low as 20% of the carrier symbol rate. Beginning in iDX Release 3.2, iDirect supports a guard band for DVB-S2 downstream carriers as low as 5% of the carrier symbol rate. The amount of required guard band between carriers can also be expressed as the carrier spacing requirement. For example, if the required guard band is 20%, the channel spacing

Technical Reference Guide iDX Release 3.3

149

Considerations When Determining Guard Band

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

Considerations When Determining Guard Band The spectral shape of the carrier is not the only factor contributing to the guard band requirement. Frequency stability parameters of a system may result in the need for guard bands slightly greater than those specified in this chapter. iDirect complies with the adjacent channel interference specification in IESS 308 which accounts for adjacent channels on either side with +7 dB higher power. It is possible that due to instability of frequency references in a satellite network system, a carrier may not fall exactly on its assigned center frequency. For TDMA upstream carriers, iDirect networks combat frequency offset using an automatic frequency control algorithm. Any additional instability must be accommodated by additional guard band. The frequency references to the hub transmitter and to the satellite itself are generally very stable so a main source of upstream frequency instability is the downconverter at the hub. This is because the automatic frequency control algorithm uses the hub receiver’s estimate of frequency offset to adjust each remote’s transmitter frequency. Hub stations which use a feedback control system to lock their downconverter to an accurate reference may have negligible offsets. Hub stations using a locked LNB have a finite frequency stability range. Transient errors are a major risk for upstream TDMA carriers if there is insufficient guard band. During remote acquisition, if there is frequency uncertainty due to remote mobility or instability of the hub downconverter, it may take several UCP intervals for the hub to correct the remote’s frequency offset. During that time, bursts transmitted by the remote may cause significant CRC errors on the upstream carrier and adjacent carriers. During operation, when a mobile remote experiences Doppler shift or the ambient temperature at a remote site changes suddenly, insufficient guard band may result in transient CRC errors while the UCP algorithm is correcting for the frequency shift. Some customers may want to include additional guard band to prevent such transient errors. Others may choose to tolerate these errors if the transient conditions are relatively rare in order to optimize bandwidth usage. Upstream CRC errors can be monitored using iMonitor. For details, see the section on viewing Upstream Performance Statistics in the iMonitor User Guide. Another reason to add guard band is to account for frequency stability of other carriers directly adjacent on the satellite which are not part of an iDirect network. Be sure to review this possibility with the satellite link designer when determining the carrier parameters.

150

Technical Reference Guide iDX Release 3.3

DVB-S2 Roll-Off Factors

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

Figure 23-1. Spectral Mask Illustrating 20% and 5% Roll Off Factors

Technical Reference Guide iDX Release 3.3

151

DVB-S2 Roll-Off Factors

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

1.20 (Guard band = 20% of carrier symbol rate)

•

1.15 (Guard band = 15% of carrier symbol rate)

•

1.10 (Guard band = 10% of carrier symbol rate)

•

1.05 (Guard band = 05% of carrier symbol rate)

Group Delay and Downstream Performance DVB-S2 waveform performance is affected on remote platforms when operated under channel conditions characterized by high transponder group delay. Such atypical channel conditions are encountered in singe carrier per transponder applications with certain transponder model types and to the extent symbol rate occupies the transponder bandwidth depending on configured roll-off factor. When the symbol rate Fsym exceeds 75% of transponder bandwidth (18/27/40.5 Msps for 24/36/54 MHz XPDRs), customers are encouraged to check the cascaded IMUX and OMUX filter group delay of the transponder usually available from satellite operator. These plots or specifications capture the peak-to-peak ripple (in nanoseconds) of the group delay at different frequency offsets from the transponder center. For group delay ripple that exceeds 0.5 symbol period across symbol rate bandwidth, performance is severely degraded for the X3/X5 remote platforms to the point that the channel becomes unusable. For example, a 34.285 Msps with 5% ROF DVB-S2 carrier on a 36 MHz transponder requires the cascaded group delay ripple to be less than 14.6 ns peak-topeak across the symbol rate bandwidth of 34.285 MHz.

0.5 --------------------------------- = 14.6 34.285  1e6 On X1/X7/e8x platforms, the demodulator handles the group delay levels better with robust equalizers usually up to 1.5 symbol periods across symbol rate bandwidth with negligible SNR degradation. Group delay exceeding 1.5 symbols periods (i.e. approximately 43.8 ns peak-topeak based on the 34.285 Msps with 5% ROF carrier example) will result in noticeable SNR degradation and negatively affect link performance on these platforms. SNR degrades significantly in excess of 3 dB as the group delay approaches 4 symbol periods and eventually resulting in complete loss of channel performance. Group delay exceeding limits identified above (0.5/Fsym over Fsym bandwidth for X3/X5 platforms or 1.5/Fsym over Fsym bandwidth for X1/X7/e8x platforms) usually requires Hub side Tx Group delay equalizer (available COTS) to compensate for transponder effects or symbol rate/roll-off factor reduction to keep away from group delay edges for satisfying identified limits.

152

Technical Reference Guide iDX Release 3.3

Improving Throughput by Reducing Guard Band

Improving Throughput by Reducing Guard Band A lower bandwidth requirement between carriers makes it possible to fit a higher bit rate carrier into the same occupied bandwidth or to fit additional carriers into the same overall bandwidth. The example in this section shows how a lower guard band requirement can allow a Network Operator to increase the information rate of a DVB-S2 carrier without changing the occupied bandwidth and allotted power. NOTE: Increasing the information rate of existing carriers may affect the link budget of the satellite network. This is especially true for upstream carriers since uplink power control will automatically increase the transmit power of the remotes. Consult with the link budget provider prior to adjusting any carrier configurations. Table 23-1 illustrates the increase in information rate that can be achieved on a DVB-S2 downstream carrier by decreasing the guard band while holding the occupied bandwidth constant. The calculations were performed using the 8PSK-8/9 MODCOD. Table 23-1. Increasing Information Rate by Reducing Guard Band Guard Band

Occupied Bandwidth (kHz)

Symbol Rate (ksym/s)

Information Rate (kbps)

20%

20000

16666.667

41729

15%

20000

17391.304

43543

10%

20000

18181.818

45522

05%

20000

19047.619

47690

In the example, reducing the guard band from 20% of the symbol rate to 5% of the symbol rate results in a 14.29% increase in information rate.

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

Guard Band

Minimum Symbol Rate (ksym/s)

Minimum MODCOD

1.20

20%

1000

QPSK-1/4

1.15

15%

1000

QPSK-1/4

1.10

10%

1000

QPSK-1/2

1.05

05%

10000

QPSK-1/2

Technical Reference Guide iDX Release 3.3

153

Adjacent Channel Interference

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

Figure 23-2. Adjacent Carrier Interference Example For DVB-S2 roll off factors of 10, 15 and 20%, the BER degradation of the wanted carrier does not exceed 0.25 dB from LBA guide across all supported MODCODs for ACI levels of +7 dBc (each) on either side independent of the symbol rate, roll off and waveform modulation type of the adjacent carriers. However, for 5% roll off factor, the robustness to ACI levels is degraded slightly. Based on carrier arrangements robustness to ACI levels for 5% roll off factor vary from +4 dBc to +7 dBc on either side. The worst case typically occurs at the highest operating MODCOD (i.e. 16APSK-8/9) under the following conditions: •

The wanted carrier is less than 15 Msps and the adjacent carriers have an identical symbol rates shaped with 5% roll off factor

•

With strong, narrow-band adjacent carriers that occupy 5% to 10% of symbol rate of the wanted carrier on either side

In most cases, the DVB-S2 downstream carrier operates at the highest power spectral density in the transponder, maximizing the contracted equal power equal bandwidth (EPEBW) limit. This makes ACI levels exceeding +4 dBc unlikely. In addition, adjacent carriers shaped at 5% (bullet 1) or narrow-band carriers stronger than the DVB-S2 downstream carrier (bullet 2) that are likely to violate the EPEBW mask are unusual. Network designers can realize the benefit of 5% roll off by planning around the identified constraints.

154

Technical Reference Guide iDX Release 3.3

Adjacent Channel Interference

Technical Reference Guide iDX Release 3.3

155

Adjacent Channel Interference

156

Technical Reference Guide iDX Release 3.3

24 Alternate Downstream Carrier This chapter provides information about iDirect’s Alternate Downstream Carrier feature. It contains the following sections: •

Background on page 157

•

Feature Description on page 157

Background The Alternate Downstream Carrier feature is intended to make it easier to move an iDirect network to a new transmit carrier and to eliminate the danger of stranding remotes that have not received the new carrier definition when the carriers are switched. If, for example, the network must move to a larger downstream carrier, the Alternate Downstream Carrier feature can facilitate the transition. Before this feature was available, if the downstream carrier changed, a site visit was required to recover any remotes that were not in the network at the time that the carrier was changed. The Alternate Downstream Carrier feature is disabled if the NMS server is licensed for the Global NMS feature. However, the Global NMS feature can accomplish the same goal by creating an alternate network containing the new downstream carrier and configuring roaming remotes instances in both the existing network and the new network. Like the Alternate Downstream Carrier feature, this allows the Network Operator to verify that all remotes have the new downstream carrier definition prior to the actual upgrade.

Feature Description Beginning in iDX Release 2.0, iBuilder provides the capability of selecting an alternate downstream carrier on the Line Card dialog box of the transmit line card. (See the chapter titled “Defining Networks, Line Cards, and Inroute Groups” in the iBuilder User Guide for details). The configuration includes all necessary parameters for the remote to acquire the alternate downstream. Configure the alternate carrier for a network well in advance of the carrier change to ensure that all remotes have the alternate carrier definition when the downstream change is implemented. If a remote is not in the network at the time of the carrier change it will attempt to acquire the old primary carrier unsuccessfully when it first tries to rejoin the network. Since the old primary carrier is no longer being transmitted, the remote will then attempt to acquire its configured alternate downstream carrier which is the new primary carrier. At that point the remote will acquire the network on the new carrier.

Technical Reference Guide iDX Release 3.3

157

Feature Description

When a remote joins a network with a configured Alternate Downstream Carrier, it first attempts to acquire the last downstream carrier to which it was locked before it attempts to acquire the other carrier. Therefore, if the remote was last locked to the primary carrier, it attempts to lock to the primary carrier again when it tries to rejoin the network. Similarly, if the remote was last locked to the alternate carrier, it attempts to lock to the alternate carrier again when it tries to rejoin the network. By default, a remote tries for five minutes (300 seconds) to find the last carrier before switching to the other carrier. However, this timeout can be changed by defining the net_state_timeout remote-side custom key on the Remote Custom tab in iBuilder as follows: [BEAMS_LOCAL] net_state_timeout = where is the number of seconds that the remote tries to acquire the primary carrier before switching to the alternate carrier. NOTE: If a new remote has never locked to any carrier, it always attempts to lock to the primary downstream carrier first. Therefore, when commissioning a new remote, it will first look for the primary carrier even if an alternate carrier is configured. Primary and alternate downstream carriers cannot co-exist as active carriers in an iDirect system. In addition, the Alternate Downstream Carrier feature is not intended to be used as a recovery channel. A carrier selected as the Alternate Downstream Carrier for one Tx line card cannot also be assigned to another line card, either as the primary or alternate carrier. The procedure for moving a network to an Alternate Downstream Carrier is documented in the iBuilder User Guide. See “Changing to an Alternate Downstream Carrier” in the chapter titled “Defining Networks, Line Cards, and Inroute Groups.”

158

Technical Reference Guide iDX Release 3.3

25 Transmit Key Line

This chapter describes the iDirect Transmit Key Line Feature. It includes the following sections: •

Introduction

•

Feature Description

Introduction The iDirect Transmit Key Line feature is supported on iConnex e850mp and Evolution e150 remotes. The feature uses a pair of differential hardware lines to indicate when the remote is transmitting on a burst-by-burst basis. iDirect anticipates that this signal will be used by terminal providers to conserve power on the remote terminal by powering on the Solid State Power Amplifier (SSPA) on the Block Upconverter (BUC) only when the remote is required to transmit on the upstream carrier. NOTE: This feature is only available for remote terminals equipped with an iConnex e850mp or Evolution e150 satellite router board that has been properly integrated with a BUC that supports the transmit key line signal.

Feature Description Maintaining satellite communications is often a critical requirement of deployments in which the only power source available to the remote terminal consists of batteries or small generators with limited fuel. This makes power conservation crucial to the success of the mission. Since the biggest power requirement of a satellite terminal comes from the BUC, the Transmit Key Line feature is designed to allow the terminal to conserve power by turning off the BUC’s Power Amplifier (PA) when the remote is not transmitting. This significantly increases the amount of time the terminal is on line. The Transmit Key Line feature uses a differential RS 422-compatible signal provided to the BUC through a connector on the remote modem. Details of this interface are defined in the integration guide for each model type. For the iConnex e850mp, see the e800 Series Satellite Router Integration Guide. For the Evolution e150, see the e150 Satellite Router Integration Guide. By default, the Transmit Key Line feature is disabled for e850mp and e150 remotes. A Network Operator can enable the feature on individual remotes by selecting a check box on the Remote VSAT Tab in iBuilder. When Transmit Key Line is enabled, the operator must also

Technical Reference Guide iDX Release 3.3

159

Feature Description

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

160

Technical Reference Guide iDX Release 3.3

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

Benefits of NMS Database Replication When the NMS Database Replication feature is enabled, changes to the NMS databases on the Primary NMS are automatically replicated to the backup server(s) using MySQL’s master/slave replication tools. The Primary NMS acts as a MySQL master while each backup server acts as a MySQL slave. This feature provides the following benefits: •

Near real-time backup of the Primary NMS Server databases. Since changes to the database are replicated on a per-transaction basis, the databases on the backup server are typically updated whenever the master databases change. If changes occur to the database on the Primary NMS while the backup databases are locked, replication quickly catches up to bring the backup databases up-to-date once the databases are unlocked.

•

Eliminates impact of idsBackup on the Primary NMS Server. When NMS Database Replication is enabled, the idsBackup script used to archive the databases is run on the backup databases rather than on the databases on the Primary NMS Server. This permits idsBackup to lock the Backup NMS databases, with no impact on the Primary NMS Server. This eliminates lost updates to the primary NRD database and improves NMS performance while idsBackup is running.

•

Provides an alternate read-only set of NMS databases to other applications. Providing near real-time databases on a backup server allows external applications such as SatManage and custom applications to access the backup databases, thus off-loading this burden from the Primary NMS Server. NOTE: Great care must be taken not to permit such applications to update the databases residing on the backup server. Doing so will cause replication from the Primary NMS to the Backup NMS to stop. This may only be noticed when the MySQL master attempts to update the same table and row that was inappropriately updated in the MySQL slave database.

•

Allows replication of key server configuration files. By using the -b option when setting up replication, key NMS server files are automatically replicated to the backup server. This eliminates the need to manually backup these files to provide server redundancy.

Technical Reference Guide iDX Release 3.3

161

Feature Description

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

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

Figure 26-1. NMS Database Replication Architecture The example in Figure 26-1 shows a single NMS server with one backup server and an external server that reads the replicated database. However, the NMS Database Replication feature can be set up in a number of different configurations. Note the following:

162

•

NMS databases can be replicated from a single MySQL master to a single MySQL slave (as shown in Figure 26-1) or from a single MySQL master to multiple MySQL slaves.

•

It is not possible to replicate the NMS databases from multiple MySQL masters to a single MySQL slave. Each MySQL slave can only receive replicated databases from a single master.

Technical Reference Guide iDX Release 3.3

Feature Description

•

It is not possible to select which individual NMS databases that reside on an NMS server to replicate. When NMS Database Replication is enabled, all databases are replicated.

•

idsBackup can be configured to run on any, all or none of the MySQL slave servers.

•

idsBackup can be configured to archive the NMS databases to its own server (as shown in Figure 26-1) or to a different backup server.

•

On a distributed NMS, NMS Database Replication can run on any, all, or none of the NMS servers on which databases are stored.

•

On a distributed NMS, it is not possible to replicate the NMS databases from multiple NMS servers on which the databases are stored to a single backup server. Each NMS server with replication enabled must replicate its database(s) to a different backup machine.

•

Key configuration files can be replicated to the Backup NMS Server by enabling replication with the -b option (see page 168). This allows the Backup NMS Server to be easily brought on line as the Primary NMS Server if the primary server fails. However, when using this option, the backup server cannot act independently in another role (such as a GKD server) since the configuration on the backup server will be overwritten by the configuration from the Primary NMS Server.

Replicating iDirect NMS Databases An iDirect NMS maintains two MySQL databases: •

The nms database contains the system configuration defined in iBuilder and written to the database by the NMS cfgsrvr process.

•

The nrd_archive database contains: • Statistics written to the database by the NMS nrdsvr process • Events and conditions written to the database by the NMS evtsvr and latsvr processes

Figure 26-2 shows a sample implementation of the NMS Database Replication feature with one Primary NMS Server and one Backup NMS Server.

Figure 26-2. NMS Database Replication from a Single Primary NMS Server

Technical Reference Guide iDX Release 3.3

163

Feature Description

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

NMS Database Replication on a Distributed NMS As discussed on page 163, four NMS process write to the NMS databases. With respect to these processes, a typical Distributed NMS (DNMS) is set up on three NMS server machines as follows: •

The NMS Configuration Server process (cfgsvr) runs on NMS Server 1.

•

The NMS Statistics Server process (nrdsvr) runs on NMS Server 2.

•

The NMS Event Server process (evtsvr) and NMS Latency Server process (latsvr) run on NMS Server 3.

All NMS databases are created on each of these three server machines. However, each of these processes updates only its local database. Therefore:

164

•

The nms database on NMS Server 1 contains the configuration data.

•

The nrd_archive database on NMS Server 2 contains the statistics.

•

The nrd_archive database on NMS Server 3 contains the conditions (events and warnings).

Technical Reference Guide iDX Release 3.3

Feature Description

Figure 26-3 shows a distributed NMS with NMS Database Replication enabled on all three NMS server machines.

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

Technical Reference Guide iDX Release 3.3

165

Setting Up NMS Database Replication

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

Setting Up NMS Database Replication This section describes how to set up NMS Database Replication on the NMS servers. Before enabling replication, ensure that: •

The Primary NMS Server and the Backup NMS Server(s) have the same iDirect release installed

•

There is IP connectivity between the Primary NMS Server and the Backup NMS Server(s)

The cr8DbMaster script is run from the root account of the Primary NMS Server to configure replication on the NMS server machines. The script can be used configure the Primary NMS Server as a MySQL master and one or more Backup NMS Servers as MySQL slaves. To create the MySQL slaves, cr8DbMaster calls the cr8DbSlave script on the backup machine. Run cr8DbMaster to perform the following tasks: •

Create a MySQL master and one MySQL slave

•

Create a MySQL master and more than one MySQL slave

•

Add a MySQL slave to an exiting MySQL master

•

Delete a MySQL slave

•

Force recreation of existing MySQL slave

The full syntax and explanation of the cr8DbMaster script can be viewed on any NMS server by entering the command: perldoc cr8DbMaster The synopsis is repeated here: cr8DbMaster [-h] [-v] [-d] [-f] [-b] [-t temp_dir] -u replUser -p replPassword slave_host...

166

-h

Help, display this usage statement and exit.

-v

Display cr8DbMaster script version and exit.

-d

Delete an existing database slave host.

-f

Force recreation of specified existing slave servers.

-b

Backup mode, also replicate key NMS files.

-t temp_dir

Create the temporary working in \temp_dir\. Default is /var/idirect/backup\

-u replUser

Replication user name for slave replication user.

-p replPassword

Replication user password for slave replication user.

Technical Reference Guide iDX Release 3.3

Setting Up NMS Database Replication

slave_host

The IP address of one or more iDirect NMS servers to be configured as a MySQL slave server.

The cr8DbMaster script calls the cr8DbSlave script on each of the specified slave servers to properly configure and start replication to the slave. Generally, the cr8DbSlave script is only run manually on a MySQL slave server when the master has failed to turn the slave server into the new Primary NMS. See Stop Replication on a Backup NMS Server on page 169. MySQL slave servers must run the same iDX release with the same version of the MySQL as the MySQL master server. The cr8DbMaster script enforces this requirement when the slave is initially configured. Upgrading to a new release on the MySQL master server but not upgrading the MySQL slave servers can lead to unpredictable results. Therefore, when upgrading to a new iDX release on the Primary NMS Server, be sure to also upgrade all backup servers.

Examples This section provides examples showing how to configure NMS Database Replication on NMS Servers. With the exception of the cr8dBSlave command used to stop replication on a MySQL slave’s local machine to prepare for a failover, all commands should be run from the root account of the Primary NMS containing the databases to be replicated. If not previously done, enable remote access from the Primary NMS Server to a backup server by executing the pushSSHKeys command. This command only needs to be executed one time. To enable remote access to a backup server: 1. Log on to the root account of the Primary NMS Server 2. Enter the command: pushSSHKeys where is the IP address of the backup server.

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

Technical Reference Guide iDX Release 3.3

167

Setting Up NMS Database Replication

Figure 26-4 shows sample output from this command.

Figure 26-4. Enabling NMS Database Replication to a Backup Server NOTE: When replication is enabled, idsBackup is automatically disabled on the Primary NMS Server and enabled on the Backup NMS Server. NOTE: Enabling replication restarts iDirect NMS services on the Primary NMS Server.

Add Two Additional Backup NMS Servers as MySQL Slaves The following example adds two additional MySQL slaves (on backup servers 192.168.77.21 and 192.168.77.30) to the MySQL slave created in the previous example. The databases from this Primary NMS will be replicated to all three backup servers. A different MySQL user / password (user2 / user2pwrd) is created on the two additional backup servers. cr8DbMaster -u user2 -p user2pwrd 192.168.77.21 192.168.77.30

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

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

168

Technical Reference Guide iDX Release 3.3

Monitoring NMS Database Replication

NOTE: If 192.168.77.16 is the only MySQL slave associated with this MySQL master, this command also disables replication on this Primary NMS Server and this NMS Server is no longer configured as a MySQL master.

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

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

Monitoring NMS Database Replication The cr8DBMaster script may, depending on options, create up to three “root” cron jobs: •

mysql-binlog-purge runs periodically to clean up master replication logs that have been successfully processed by all slaves. By default this cronjob is set to run at 12:00 AM, 6:00 AM, 12:00 PM and 6:00 PM when replication is configured using the cr8DbMaster script. When the last slave is deleted, the cr8DbMaster script removes this cronjob.

•

mysql-repl-monitor monitors the status of each of the slaves to ensure that replication is occurring properly. A warning is sent to the NMS and displayed in iMonitor if replication is not functioning properly. By default this cronjob is set to run on the hour and every five minutes when replication is configured using the cr8DbMaster script. When the last slave is deleted, the cr8DbMaster script removes this cronjob. NOTE: This script can also be used to send e-mail to the root user if replication is not functioning properly. The sendmail aliases file (/etc/aliases) may be used to forward this e-mail to any user. See “man 5 aliases” and “man 1 newaliases” for details on forwarding root’s e-mail to another user.

Technical Reference Guide iDX Release 3.3

169

Monitoring NMS Database Replication

•

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

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

Viewing Replication Conditions in iMonitor Events and warnings generated by the replication scripts are sent to the NMS and may be displayed as conditions in iMonitor. View these conditions in iMonitor as follows: 1. Select Conditions from the iMonitor View menu to open the Conditions pane. 2. Click the Conditions Log tab. Figure 26-5 shows examples of a number of replication conditions as viewed in iMonitor. iMonitor will display similar conditions whenever something significant occurs with respect to replication. For example:

170

•

When replication is initially set up on the Primary NMS

•

When new MySQL slaves are added or removed

•

When the MySQL binary log files are purged

•

When a replication error is detected

Technical Reference Guide iDX Release 3.3

Monitoring NMS Database Replication

•

When a previously-detected replication error is cleared

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

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

Figure 26-6. Replication Error Resulting in Active Condition in iMonitor

Technical Reference Guide iDX Release 3.3

171

Monitoring NMS Database Replication

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

172

Technical Reference Guide iDX Release 3.3

27 Feature and Chassis Licensing Licenses are required for chassis slots and certain iDirect features before they can be enabled in iBuilder. Please see the iDirect Features and Chassis Licensing Guide for detailed information on how to obtain, install and activate iDirect licenses.

iDirect Licensing Requirements This section lists all licenses available for iDirect networks. A Network Operator cannot configure slots in a hub chassis or enable the software features listed here without a valid license. iDirect licenses fall into the following categories: •

Chassis Slot Licences are required to enable the chassis slots on both 4-slot and 20-slot hub chassis. These licenses must be imported using the iBuilder License Toolbar.

•

Hardware-Specific Feature Licenses are software feature licenses available for specific remote modems or hub line cards. These licenses must be imported using the iBuilder License Toolbar. Hardware-Specific Feature Licenses include: • Evolution X1 AES Link Encryption • Evolution X3 AES Link Encryption • Evolution X5 AES Link Encryption • Evolution X7 AES Link Encryption • Evolution X5 Upstream Spread Spectrum • Evolution X7 Upstream Spread Spectrum • Evolution e8350/e800/e850mp High-Speed COTM • Evolution XLC-11 Upstream Spread Spectrum • Evolution eM1D1 TRANSEC • Evolution eM0DM TRANSEC • Evolution eM0DM/XLC-M TDMA multichannel support • Evolution XLC-M TDMA Narrowband multichannel support • Evolution eM0DM/XLC-M SCPC return multichannel support

Technical Reference Guide iDX Release 3.3

173

iDirect Licensing Requirements

•

NMS Server Feature Licenses are software feature licenses that apply to all iDirect networks managed by an NMS server. To enable these licenses, a valid license file must be copied to a specific directory on the NMS server. NMS Server Feature Licenses include: • Global NMS • VNO User Groups • CNO User Groups

•

Protocol Processor Blade Feature Licenses are software feature licenses that apply to all iDirect modems controlled by a Protocol Processor Blade server. To enable these licenses, a valid license file must be copied to a specific directory on the PP blade server. PP Blade Server Feature Licenses include: • Encryption License (for Link Encryption and TRANSEC)

High-speed COTM licenses are required for mobile remotes that exceed the speed of 150 mph. A mobile remote determines its speed by monitoring its geographic location over time. If an unlicensed remote calculates three consecutive times that it has exceeded 150 mph, the remote issues the event “COTM License Violated” and all user traffic to the remote is stopped. When the remote’s speed falls below the 150 mph limit, the violation is reset and the remote resumes carrying user traffic. NOTE: For more information on the High-Speed COTM feature, see the appendix “COTM Settings and Custom Keys” in the iBuilder User Guide. For information on importing Chassis Slot Licenses and Hardware-Specific Feature Licenses into iBuilder and for validating Hub Slot Group Licenses in iBuilder, see the iBuilder User Guide.

174

Technical Reference Guide iDX Release 3.3

28 Hub Line Card Failover

This chapter describes basic hub line card failover concepts, transmit/receive verses receiveonly line card failover, failover sequence of events, and failover operation from a user’s point of view. For information about configuring line cards for failover, refer the “Networks, Line Cards, and Inroute Groups” chapter of the iBuilder User Guide.

Basic Failover Concepts Each second, every line card sends a diagnostic message to the NMS. This message contains the status of various onboard components. If the NMS fails to receive any diagnostic messages from a line card for 60 seconds, and all failover prerequisites are met, it considers that the line card may be in failed state. It takes another 15 seconds to ensure that line card has truly failed. It then starts the failover process. If the standby line card is acting as a warm standby for the failed line card, it assumes the failed card’s role immediately. If the standby is a cold standby for the failed line card, it needs to flash a new options file and reset. The estimated time to complete a line card failover to a warm standby is less than 10 seconds; the estimated time to complete a failover to a cold standby is less than 1 minute. NOTE: If a Tx line card fails, or there is only one Rx line card and it fails, all remotes must re-acquire the network after failover is complete.

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

Technical Reference Guide iDX Release 3.3

175

Failover Sequence of Events

pre-configured with the parameters of the Tx card for that network, and has those parameters loaded into memory. The only difference between the active Tx(Rx) card and the warm standby is that the standby mutes its transmitter (and receiver). When the NMS detects a Tx(Rx) line card failure, it sends a command to the warn standby to un-mute its transmitter (and receiver), and the standby immediately assumes the role of the Tx(Rx) card. Cold standby line cards take longer to failover than warm standby line cards because they need to receive a new options file, flash it, and reset.

Failover Sequence of Events The flow chart that shows the sequence of events performed on the NMS server to execute a complete failover is shown in Figure 28-1. Portions of the failover sequence of events are revealed in real-time. You may perform a historical condition query in iMonitor at any time to see the alarms and warnings that are generated and archived during the failover operation.

176

Technical Reference Guide iDX Release 3.3

Failover Sequence of Events

Figure 28-1. Line Card Failover Sequence of Events

Technical Reference Guide iDX Release 3.3

177

Failover Sequence of Events

178

Technical Reference Guide iDX Release 3.3

29 NMS, PP and GKD Server Port Assignments This chapter defines the IP port numbers that are used by the various processes that run on the NMS servers, Protocol Processor servers, and GKD servers. This information is provided to assist iDirect Network Operators, iDirect network architects, and any other personnel responsible for configuring and maintaining iDirect networks or for integrating iDirect networks with other systems. This chapter contains the following sections: •

NMS Server Ports on page 179 defines the port numbers for all ports used by the NMS server processes that run on NMS server machines.

•

GKD Server Ports on page 181 defines the port numbers used by the GKD servers to manage TRANSEC keys. A GKD server can run on an NMS, protocol processor blade, or standalone machine.

•

PP Controller Ports on page 181 defines the port numbers used by the PP controller process that runs on the NMS server machine.

•

Protocol Processor Ports on page 181 defines the port numbers used by the processes that run on the protocol processor blade machine.

•

Port Assignments for NMS/Upstream Router Traffic Flow on page 182 defines the port numbers and respective protocols for traffic flow between the NMS servers and the upstream router.

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

Technical Reference Guide iDX Release 3.3

NMS Server

Port Type

Port Number

config Server

ConfigServer

1493

MnCServer

1492

ProxyServer

14599

ConfigConsole

14123

UDPPush

14599

179

NMS Server Ports

Table 29-1. NMS Server Ports (continued) NMS Server

Port Type

Port Number

nrd Server

NRD Server

2858

NRDListner

2859

NRDServiceMon

9001

NRDConsole

13257

EVTServer

2861

EVTListner

2860

EVTConsole

13259

REVServer

2865

REVListener

2866

REVConsole

13265

DMONServer

2867

DMONListener

2868

DMONConsole

13266

snmp Server

SNMPConsole

13263

control Server

ControlServer

1393

ControlConsole

13123

DMONConsole

13266

LATServer

2863

LATConsole

13261

map Server

MapServer

5003

oss Server

OSSServer

1593

OSSListener

1594

OSSConsole

15123

SKYServer

2869

SkyConsole

2870

CMServer

15261

CMConsole

15262

evt Server

rev Server

dmon Server

latency Server

sky Server

chassis manager Server

180

Technical Reference Guide iDX Release 3.3

PP Controller Ports

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

Port Number

Listen

3001[pp database ID] 5495

Console

15000[pp database ID]

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

Port Number

GkdServer

45001

GkdCertificate

45010

GkdConsole

46002

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

Technical Reference Guide iDX Release 3.3

Port Type

Port Number

MnC

1494

CA Handler

2494

Key Controller

8700, 8701 via udp

MultiCastPackageDownload

9000

Console

13255

181

Port Assignments for NMS/Upstream Router Traffic Flow

Table 29-5 defines the port ranges reserved for the remaining protocol processor processes, such as sada, sarmt, sarouter, and sana. The number of ports used depends on the number of networks assigned to each protocol processor and the number of processes running on each blade. Table 29-5. Protocol Processor Port Ranges Port Type

Port Number Ranges

Inter-Process Communication

3000 and up

Tunnel between PP and HLC

8000 (8001 in 7.0)

Console

13456 and up, and is assigned a different port by the SAMNC process

Port Assignments for NMS/Upstream Router Traffic Flow Table 29-6 defines the designated port numbers and the respective protocol for traffic flow to and from NMS servers through the upstream router. Table 29-6. Port Designations for NMS/Upstream Router Traffic

182

Source Host

Protocol/Port

Destination Host

Description

nmssvr eth0

TCP 2494

hlc eth0

configuration and control to hub line cards and remote modems

nmssvr eth0

UDP 9090

pp eth1

“unicast proxy” multicast download to remotes

nmssvr eth0

UDP 9000

multicast

multicast download to PP blades, hub line cards, and remote modems

pp_controller eth0

TCP 2494

pp eth1

configuration and control to PP blades

pp eth1

UDP 8000 + pp_id

pp_controller eth0

blade heartbeat

pp eth1

UDP 8500 + pp_id

pp_controller eth0

blade status

pp eth1

UDP 2859

nrdsvr eth0

network statistics

pp eth1, hlc eth0

UDP 2860

evtsvr eth0

network events

Technical Reference Guide iDX Release 3.3

30 VRRP and Remote LAN Port Monitoring This chapter describes the iDirect Virtual Router Redundancy Protocol (VRRP) and Remote LAN Port Monitoring features. This chapter contains the following sections: •

Virtual Router Redundancy Protocol (VRRP) on page 183 describes the VRRP feature and how to configure it in iDirect networks.

•

Remote LAN Port Monitoring on page 191 describes the Remote LAN Port Monitoring feature and how to configure it in iDirect networks.

•

Monitoring VRRP Status and Remote LAN Status on page 193 describes how to monitor VRRP and remote LAN port status in iDirect networks.

Virtual Router Redundancy Protocol (VRRP) iDirect supports Virtual Router Redundancy Protocol (VRRP) version 2 for IPv4 as specified by RFC 3768. Authentication as specified in the RFC is not supported. The iDirect implementation also supports VRRP Accept Mode as defined in RFC 5798.

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

Technical Reference Guide iDX Release 3.3

183

Virtual Router Redundancy Protocol (VRRP)

the virtual IP address is automatically given a priority of 255. Therefore, the router that “owns” the Virtual IP address of the Virtual Router is the default VRRP Master for that VRRP group. The routers in a VRRP group communicate using a predefined multicast address. The Master router sends periodic VRRP Advertisement messages every Advertisement Interval. The Advertisement Interval defaults to one second but can be configured. If the Backup routers do not receive any Advertisements from the Master for three Advertisement Intervals, then the Backup routers elect a new Master. Unless an election is in progress, Backup routers do not typically send VRRP messages. However, if a Backup router is configured with a higher priority than the current Master and preemption is enabled on the Backup router, then the Backup router uses the VRRP protocol to preempt the Master. The priorities of the routers in a VRRP group may change dynamically. Therefore, the current priority of a router is not always identical to the configured priority. For example, if the virtual IP address assigned to the Virtual Router is identical to the IP address of the router’s LAN interface, then the actual priority of that router is set to 255 rather than to the configured value. In addition, if Route Tracking is enabled for a destination address and that address becomes unreachable, the priority of the Master router is reduced by a pre-defined value. (Route Tracking is a VRRP extension discussed in VRRP Route Tracking on page 188.) Any user-defined VLAN interface configured on an Evolution X5 or Evolution X7 remote can be included in a VRRP group. Please note the following conditions: •

Any VLAN can be included in only one VRRP group.

•

The default VLAN (VLAN 1) cannot be included in a VRRP group.

•

iDirect supports a maximum of seven VRRP groups per remote on separate VLANs.

•

Since iDirect does not support multiple remotes on a single subnet, two iDirect remotes cannot be included in the same VRRP group. NOTE: If the LAN cable is disconnected from an Evolution X7 remote and LAN Port Monitoring is not enabled, the remote enters the Master state. If this occurs without LAN Port Monitoring enabled, the X7 could incorrectly remain in the Master state.

184

Technical Reference Guide iDX Release 3.3

Virtual Router Redundancy Protocol (VRRP)

Figure 30-1 shows an example of a Virtual Router consisting of an iDirect remote and a router.

Per VLAN VRID: 1 Virtual IP: 10.15.1.1 Virtual MAC: 00-00-5E-00-01-{VRID}

iDirect Hub

IP Network

10.15.1.5 Remote Backup Priority 100

Host 1 Default gateway: 10.15.1.1 10.15.1.1 Host 2

Router Master Priority 255

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

Technical Reference Guide iDX Release 3.3

185

Virtual Router Redundancy Protocol (VRRP)

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

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

186

Technical Reference Guide iDX Release 3.3

Virtual Router Redundancy Protocol (VRRP)

These optional parameters are defined as follows: • vrrp_priority is the configured priority of the remote in the VRRP group. If this custom key is not included, vrrp_priority defaults to 100 unless this VLAN owns the virtual IP address, in which case the priority is automatically set to 255. NOTE: The remote’s actual priority may differ from the configured priority if Route Tracking is enabled. See VRRP Route Tracking on page 188 for details. •

•

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

•

vrrp_accept_enabled determines whether or not this remote, when acting as Master router, accepts packets addressed to the virtual IP address as its own if it is not the IP address owner. By default, vrrp_accept_enabled is set to 0 (disabled). Set this value to 1 to enable Accept Mode for this remote on this VLAN.

4. After entering all the VRRP custom keys, click OK to save the remote configuration. 5. Right-click the remote in the iBuilder tree. 6. Select Apply ConfigurationReliableHub-Side (TCP) to apply the configuration. Figure 30-2 shows an example of a remote configured for VRRP.

Figure 30-2. Example VRRP Configuration in iBuilder

Technical Reference Guide iDX Release 3.3

187

Virtual Router Redundancy Protocol (VRRP)

In Figure 30-2, three VLANs are configured in different VRRP groups. Note that: •

For VLAN 2 and VLAN 4, the configured VRRP priorities are set to 113 and 200, respectively. Since no VRRP priority is configured for VLAN 3, the remote’s configured priority on that VLAN is 100. (However, in all cases if the remote’s ETH0 Interface IP address for a VLAN is the same as the Virtual Router IP address, then the configured VRRP priority is ignored and the priority is automatically set to 255).

•

For VLAN 2 and VLAN 4, the Advertising Interval is set to 2 seconds (2000 ms) and 3 seconds (3000 ms), respectively. Since no Advertising Interval is set for VLAN 3, the remote’s Advertising Interval on that VLAN is one second by default.

•

For VLAN 4, the default Preempt Mode setting of 1 (True) has been changed to 0 (False). Therefore, even with a higher priority, the remote when acting as Backup router does not preempt an existing Master router. (However, the remote will preempt if the remote’s ETH0 Interface IP address for VLAN 4 is set to the Virtual Router IP address of 160.100.4.1.)

•

For VLAN 4, the default Accept Mode setting 0 (False) has been changed to 1(True). Therefore, in the Master state, the remote accepts packets addressed to 160.100.4.1 even if that is not the ETH0 Interface IP address for VLAN 4 configured on the remote.

When configuring another router for the same VRRP group, such as the terrestrial router in Figure 30-1 on p. 185, ensure that the following settings are identical to those configured for the remote VLAN: •

VLAN ID

•

Virtual Router Identifier

•

Virtual Router IP address

•

Advertisement Interval

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

188

Technical Reference Guide iDX Release 3.3

Virtual Router Redundancy Protocol (VRRP)

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

Technical Reference Guide iDX Release 3.3

189

Virtual Router Redundancy Protocol (VRRP)

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

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

190

Technical Reference Guide iDX Release 3.3

Remote LAN Port Monitoring

The remote hub-side custom key in Figure 30-4 changes the timeout that the remote waits for the next Router Priority message before restoring the configured priorities. In the figure, the timeout is set to three minutes.

Figure 30-4. Changing a Remote’s Router Priority Message Timeout

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

Technical Reference Guide iDX Release 3.3

191

Remote LAN Port Monitoring

Table 30-1. PP Routing Table Operations: LAN Port Monitoring and VRRP LAN Status

VRRP Status

Operation in RIP Forwarding Table

Up

Feature not enabled

Add routes

Down

Feature not enabled

Remove routes

Up

Master

Add routes

Down

Master

Remove routes

Up

Backup

Remove routes

Down

Backup

Remove routes

Feature not enabled

Master

Add routes

Feature not enabled

Backup

Remove routes

To add LAN Port Monitoring on a remote VLAN, configure the following hub-side custom key group on the Remote Custom tab in iBuilder: [RMT_LAN_PORT_MONITOR_] vid = port_mask = where: is an integer from 0 to 7 unique to this custom key group for this VLAN. is the VLAN for which LAN port monitoring is enabled. is a bit mask indicating the remote LAN ports to which this VLAN is assigned. Since Evolution X5 remotes have a single LAN port, port_mask should always be set to 1 for an X5 remote. Evolution X7 remotes have eight LAN ports. For an X7, configure the port_mask such that all bits representing ports to be monitored for this vid are set to one. Port 1 is the least significant bit and port 8 is the most significant bit in the eight-bit port mask. The example in Figure 30-5 enables LAN port monitoring for VLAN 2 on ports 7 and 8 for an Evolution X7 remote by configuring a hub-side custom key group on the Remote Custom tab. Notice that port_mask is set to 128 + 64 = 192 (C016, 110000002) to enable ports 8 and 7, respectively

Figure 30-5. Example of LAN Port Monitoring Configuration for Multiple Ports in iBuilder

192

Technical Reference Guide iDX Release 3.3

Monitoring VRRP Status and Remote LAN Status

The example in Figure 30-6 enables LAN port monitoring for VLAN 3 and VLAN 17 on port 1 by configuring two hub-side custom key groups on the Remote Custom tab.

Figure 30-6. Example LAN Port Monitoring Configuration for Single Port in iBuilder You can enable LAN Port Monitoring for up to eight VLANs per remote using groups RMT_LAN_PORT_MONITOR_0 through RMT_LAN_PORT_MONITOR_7.

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

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

Technical Reference Guide iDX Release 3.3

193

Monitoring VRRP Status and Remote LAN Status

Remote Console Commands If you create a console connection to the Admin account of a remote, you can view the VRRP status and Remote LAN status by entering console commands. The vrrp status console command displays the VRRP State and current Priority for all remote VLANs enabled for VRRP. Sample output of the vrrp status command is shown here: vrrp status VLAN 2 7

RtrID Address 2 112.100.2.3 7 168.10.10.4

State Master Backup

Running Priority 255 200

If the State is Initializing, the remote is unable to join the VRRP group. The vrrp params console command displays the current VRRP parameters for the Virtual Router ID specified in the command. Sample output of the vrrp params command for Virtual Router ID 2 is shown here: vrrp 2 params vrrp_enabled = 7 vrrp_state = Backup vrrp_mac_addr = 00005E-000102 vrrp_ip_addr = 168.10.10.4 vrrp_configured_priority = 190 vrrp_priority_configuration_override = 190 vrrp_route_tracking_priority_decrement = 0 vrrp_running_priority = 190 vlan_id = 2 vrrp_adver_interval_ms = 1000 vrrp_master_down_interval_ms = 3257 vrrp_premption_enabled = 1 vrrp_accept_enabled = 0 The lan_port_monitor status console command displays the LAN Port Monitoring status for all remote VLANs enabled for LAN Port Monitoring. Sample output of the lan_port_monitor status command is shown here: lan_port_monitor status VLAN_ID ------2 7

194

STATUS ------DOWN DOWN

Technical Reference Guide iDX Release 3.3

Monitoring VRRP Status and Remote LAN Status

Technical Reference Guide iDX Release 3.3

195