• No results found

REFTechnical Reference Guide IDX 33Rev B02102015

N/A
N/A
Protected

Academic year: 2021

Share "REFTechnical Reference Guide IDX 33Rev B02102015"

Copied!
215
0
0

Loading.... (view fulltext now)

Full text

(1)

Technical Reference Guide

iDX Release 3.3

(2)

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

(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

(4)
(5)

Contents

List of Figures

. . . xiv

About

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

(6)

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

Short Term Adaptivity and Real-Time Resource Management . . . 36

Medium Term Adaptivity . . . 37

Long Term Adaptivity . . . 38

C/N0 and C/N . . . 38

Adaptive TDMA Configuration and Constraints . . . 39

Remote Configuration. . . 41

Reference Carrier Parameters. . . 41

(7)

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

Minimum Information Rate. . . 53

Committed Information Rate (CIR) . . . 54

Maximum Information Rate (MIR) . . . 54

Free Slot Allocation . . . 54

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

Sticky CIR. . . .55

Application Jitter . . . 55

TDMA Slot Feathering. . . 55

Packet Segmentation. . . 56

Application Latency . . . 56

Maximum Channel Efficiency vs. Minimum Latency . . . 56

Group QoS . . . .57

Group QoS Structure. . . 57

Bandwidth Pool . . . 58 Bandwidth Group . . . 58 Service Group . . . 58 Application . . . 59 Service Profiles . . . 59 Remote Profiles . . . 60

(8)

Group QoS Scenarios. . . 60

Physical Segregation Scenario . . . 60

CIR Per Application Scenario . . . 61

Tiered Service Scenario . . . 62

Third Level of Segregation by VLAN Scenario . . . 63

The Shared Remote Scenario . . . 65

Remote Service Group Scenario . . . 66

DVB-S2 ACM Scenario 1: Scaled Aggregate CIRs Below Partition’s CIR . . . 68

DVB-S2 ACM Scenario 2: Scaled Aggregate CIRs Exceeds Partition’s CIR. . . 70

Bandwidth Allocation Fairness Relative to CIR . . . 71

Bandwidth Allocation Fairness Relative to MODCOD. . . 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 . . . 79

Acquisition. . . .79

Network Operation. . . 81

UCP Correction Processing. . . 81

UCP Symbol Timing . . . 81

UCP Frequency Tracking. . . 82

UCP Power Control and Fade Detection . . . 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

(9)

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

(10)

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

Overview. . . 134

iDirect Beam Map File and Map Server. . . 134

Beam Selection . . . 135

Conveyance Beam Map File. . . 136

(11)

Beam Characteristics: Visibility and Usability . . . 137

Selecting a Beam without a Map. . . 138

Controlling the Antenna. . . 139

IP Mobility . . . 139

Initial Transmit Power. . . 139

Calculation of Initial Transmit Power . . . 140

Setting the Initial Transmit Power Offset. . . 140

6. Determining the Initial Transmit Power Offset for Other Beams. . . 141

Receive-Only Mode for ABS Remotes. . . 143

Multiple Map Servers per Network . . . 143

Operational Scenarios . . . 144

Creating the Network . . . 144

Adding a Remote . . . 144

Normal Operations. . . 145

Mapless Operations. . . 145

Blockages and Beam Outages . . . 146

Error Recovery . . . 146

22 Hub Geographic Redundancy

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

(12)

Feature Description . . . 159

26 NMS Database Replication

. . . 161

Benefits of NMS Database Replication . . . 161

Feature Description . . . 162

NMS Database Replication Architecture . . . 162

Replicating iDirect NMS Databases . . . 163

NMS Database Replication on a Distributed NMS. . . 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

(13)

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

(14)

List of Figures

Figure 1-1. Sample iDirect Network . . . 2

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

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

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

Figure 2-1. Physical Layer Frames . . . 9

Figure 2-2. Feedback Loop from Remote to Protocol Processor . . . 11

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

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

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

Figure 3-1. TDMA Burst Format with Distributed Pilots . . . 21

Figure 4-1. Spread Spectrum Network Diagram . . . 23

Figure 7-1. Control Elements of iDirect’s ATDMA System . . . 36

Figure 8-1. Enabling Multicast Fast Path Encryption . . . 46

Figure 9-1. Remote and QoS Profile Relationships . . . 49

Figure 9-2. iDirect Packet Scheduling Algorithm . . . 51

Figure 9-3. Group QoS Structure . . . 57

Figure 9-4. Physical Segregation Scenario . . . 61

Figure 9-5. CIR Per Application Scenario . . . 62

Figure 9-6. Tiered Service Scenario . . . 63

Figure 9-7. Third Level VLAN Scenario . . . 64

Figure 9-8. Shared Remote Scenario . . . 65

Figure 9-9. Remote Service Group Scenario . . . 67

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

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

Figure 9-12. Bandwidth Allocation Fairness Relative to CIR . . . 71

Figure 9-13. Bandwidth Allocation Fairness Relative to Nominal MODCOD . . . 72

Figure 10-1. Optimal C/N Detection Range . . . 76

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

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

Figure 11-1. TDMA Frame Format . . . 79

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

Figure 11-3. Uplink Power Control During Remote Fade . . . 84

Figure 11-4. iMonitor UCP Statistics . . . 86

Figure 11-5. Remote Upstream Acquisition Statistics . . . 87

Figure 12-1. Active, Idle and Dormant State Change Diagram . . . 90

Figure 12-2. Configuring Active, Idle and Dormant States . . . 90

Figure 12-3. Upstream Service Level with Trigger State Change Selected . . . 92

(15)

Figure 14-2. Sample Global NMS Network Diagram . . . 100

Figure 16-1. Protocol Processor Architecture . . . 106

Figure 17-1. Sample Distributed NMS Configuration . . . 107

Figure 18-1. DVB-S2 TRANSEC Frame Structure . . . 112

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

Figure 18-3. Code Field . . . 114

Figure 18-4. Generating the Upstream Initialization Vector . . . 115

Figure 18-5. Upstream ACQ Burst Obfuscation . . . 116

Figure 18-6. Key Distribution Protocol . . . 117

Figure 18-7. Key Roll Data Structure . . . 118

Figure 18-8. Host Keying Protocol . . . 119

Figure 21-1. iMonitor Probe: Remote Power Section . . . 141

Figure 21-2. Remote VSAT Tab: Entering the Initial Transmit Power Offset . . . 141

Figure 21-3. Absolute vs. Generated G/T Contours for Two Beams . . . 142

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

Figure 23-2. Adjacent Carrier Interference Example . . . 154

Figure 26-1. NMS Database Replication Architecture . . . 162

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

Figure 26-3. NMS Database Replication on a Distributed NMS . . . 165

Figure 26-4. Enabling NMS Database Replication to a Backup Server . . . 168

Figure 26-5. Replication Conditions Viewed in iMonitor . . . 171

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

Figure 28-1. Line Card Failover Sequence of Events . . . 177

Figure 30-1. Example of a Virtual Router . . . 185

Figure 30-2. Example VRRP Configuration in iBuilder . . . 187

Figure 30-3. Changing the Frequency of Router Priority Messages . . . 190

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

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

Figure 30-6. Example LAN Port Monitoring Configuration for Single Port in iBuilder . . . 193

(16)

List of Tables

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

Table 2-2. ACM MODCOD Scaling Factors . . . 15

Table 4-1. Spread Spectrum: TDMA Upstream Specifications . . . 25

Table 4-2. Spread Spectrum: SCPC Upstream Specifications . . . 25

Table 5-1. Multichannel Receive Line Card Parameters. . . 29

Table 6-1. Single Channel vs. Multichannel SCPC . . . 32

Table 7-1. Sample Adaptive Inroute Group Configuration . . . 40

Table 19-1. Power Consumption: Normal Operations vs. Remote Sleep Mode . . . 125

Table 23-1. Increasing Information Rate by Reducing Guard Band. . . 153

Table 23-2. DVB-S2 Guard Band Constraints . . . 153

Table 29-1. NMS Server Ports . . . 179

Table 29-2. pp_controller Ports . . . 181

Table 29-3. GKD Server Ports. . . 181

Table 29-4. samnc Ports . . . 181

Table 29-5. Protocol Processor Port Ranges . . . 182

Table 29-6. Port Designations for NMS/Upstream Router Traffic . . . 182

(17)

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

(18)

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

(19)

Document Conventions

This section illustrates and describes the conventions used throughout this document.

Convention Description Example

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

Enter the command: cd /etc/snmp/

Terminal Output

Used when showing resulting output from a command that was entered at a command line or on a console. crc report all 8350.3235 : DATA CRC [ 1] 8350.3502 : DATA CRC [5818] 8350.4382 : DATA CRC [ 20] Screen Reference

Used when referring to text that appears on the screen on a Graphical User Interface (GUI). Used when specifying names of commands, menus, folders, tabs, dialogs, list boxes, and options.

1. To add a remote to an inroute group, right-click the Inroute Groupand select Add Remote. The Remote dialog box has a number of user-selectable tabs across the top. The Information tab is visible when the dialog box opens.

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

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

NOTE: A Note is a statement or other notification that adds, emphasizes, or clarifies essential information of special importance or interest.

CAUTION: A Caution highlights an essential operating or maintenance procedure, practice, condition, or statement which, if not strictly observed, could result in damage to, or destruction of, equipment or a condition that adversely affects system operation.

WARNING: A Warning highlights an essential operating or maintenance

procedure, practice, condition or statement which, if not strictly observed, could result in injury or death or long term health hazards.

(20)

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

(21)

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.

(22)

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.

(23)

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.

(24)

IP Network Architecture

(25)

IP Network Architecture

(26)
(27)

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.

(28)

DVB-S2 Key Concepts

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

ACM (Adaptive Coding and Modulation) specifies that every BBFRAME can be transmitted on a different MODCOD. Remotes receiving an ACM carrier cannot anticipate the MODCOD of the next BBFRAME. A DVB-S2 demodulator such as those used by iDirect remotes must be designed to handle dynamic MODCOD variation.

CCM (Constant Coding and Modulation) specifies that every BBFRAME is transmitted at the same MODCOD using long frames. Long BBFRAMEs are not used in iDirect. Instead, a constant MODCOD can be achieved by setting the Maximum and Minimum MODCODs of the outbound carrier to the same value. (See the iBuilder User Guide for details on

configuring DVB-S2 carriers.)

Table 2-1. DVB-S2 Modulation and Coding Schemes # Modulation Code Notes

1 QPSK 1/4 ACM or CCM 2 1/3 3 2/5 4 1/2 5 3/5 6 2/3 7 3/4 8 4/5 9 5/6 10 8/9 11 9/10 CCM only 12 8PSK 3/5 ACM or CCM 13 2/3 14 3/4 15 5/6 16 8/9 17 9/10 CCM only 18 16APSK 2/3 ACM or CCM 19 3/4 20 4/5 21 5/6 22 8/9 23 9/10 CCM only

(29)

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 2-1.

Figure 2-1. Physical Layer Frames

The PLHEADER always uses /2 BPSK modulation. Like most DVB-S2 systems, iDirect injects pilot symbols within the data stream. The overhead of the DVB-S2 downstream varies between 2.65% and 3.85%.

The symbol rate remains fixed on the DVB-S2 downstream. Variation in throughput is realized through DVB-S2 support, and the variation of MODCODs in ACM Mode. The maximum possible throughput of the DVB-S2 carrier (calculated at 45 Msym/s and highest MODCOD 16APSK 8/9) is approximately 155 Mbps. Multiple protocol processors may be required to support high traffic to multiple remotes.

PLHEADER: signals MODCOD and frame

length (always S/2 BPSK) Pilot symbols: unmodulated carrier Data symbols: QPSK, 8PSK, 16APSK, or 32APSK

(30)

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.

(31)

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.

Figure 2-2. Feedback Loop from Remote to Protocol Processor

Figure 2-3page 11 shows the backoff mechanism that exists between the line card and protocol processor to prevent data loss. The protocol processor decreases the maximum data sent to the line card for transmission based on a measure of the number of remaining

untransmitted bytes on the line card. These bytes are scaled according to the MODCOD on which they are to be transmitted, since bytes destined to be transmitted at lower MODCODs will take longer to transmit than bytes destined to be transmitted on a higher MODCODs.

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

Protocol Processor Tx Line Card

Remote Rx Line card SNR measured and reported to PP New MODCOD Incoming user data internal queue SNR compared to SNR threshold: new MODCOD selected Downstream throughput (varies based on MODCOD assigned )

Protocol Processor Tx Line Card

Remote Rx Line Card SNR measured and reported to PP New MODCOD Incoming user data

Tx ine card queue too full? Allocate

less user data

internal queue SNR compared to

SNR threshold: New MODCOD selected

Tx line card reports internal queue fullness

to PP Reduction in downstream data Downstream throughput (varies based on MODCOD assigned)

(32)

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.

(33)

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.

(34)

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.

(35)

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.

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

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

(36)

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.

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.

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

(37)

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.

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

DVB-S2 Performance 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.

(38)
(39)

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

(40)

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.

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 16-State code performance has been optimized for all block sizes supported by iDirect: 100 bytes, 170 bytes, and 438 bytes.

Beginning in iDX Release 3.2 the waveform formats for BPSK, QPSK and 8PSK employ the Distributed Pilot TDMA (DP-TDMA) scheme to improve demodulator synchronization accuracy.

NOTE: Because 2D 16-State coding is superior to TPC, TPC inbound coding is no longer supported in iDirect networks.

(41)

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.

Figure 3-1. TDMA Burst Format with Distributed Pilots

Highlights of performance improvements that were introduced in iDX Release 3.2 with this new waveform structure include:

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

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

• Frequency tolerance of up to 1.5% of the symbol rate across all modulations • Improved TDMA burst detection performance

guard Payload Blk 1 Pilot Blk

2 Payload Blk 2 Pilot Blk 3 Payload Blk Np Pilot Blk Np Payload Blk n+1 Lp L1 Lp L1 Lp L1 Lp L2 Lgd Pilot Blk 1 guard

(42)
(43)

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

(44)

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.

Each symbol in the spreading code is called a “chip.” The spread rate is the rate at which chips are transmitted. For example, selecting No Spreading means that the spread rate is one chip per symbol (which is equivalent to regular BPSK). Selecting a Spreading Factor of 4 means that the spread rate is four chips per symbol.

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

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

NOTE: The following model types require an iDirect licence to use the upstream Spread Spectrum feature: Evolution XLC-11 line cards; Evolution X5, and X7 remotes.

(45)

TDMA Upstream Specifications

TDMA Upstream Specifications

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

SCPC Upstream Specifications

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

Table 4-1. Spread Spectrum: TDMA Upstream Specifications

PARAMETERS VALUES ADDITIONAL INFORMATION

Modulation BPSK Other Modulations not supported

Spreading Factor No Spreading, 2, 4, 8 or 16 SF = 2 only for e150 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

Table 4-2. Spread Spectrum: SCPC Upstream Specifications

PARAMETERS VALUES ADDITIONAL INFORMATION

Modulation BPSK Other Modulations not supported

Spreading Factor No Spreading, 2, 4, 8 Symbol Rate 128 ksym/s - 15 Msym/s

Chip Rate 15 Mchip/s maximum

BER Performance Refer to the iDirect Link Budget Analysis Guide

Occupied BW 1.2 * Chip Rate

(46)
(47)

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.

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

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

(48)

Multichannel Line Card Restrictions and Limits

Multichannel Line Card Restrictions and Limits

The following restrictions apply to Multichannel Line Cards:

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

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.

(49)

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

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

(50)

References

Related documents