Technical Reference Guide
iDX Release 3.3
Copyright © 2015 VT iDirect, Inc. All rights reserved. Reproduction in whole or in part without permission is prohibited. Information contained herein is subject to change without notice. The specifications and information regarding the products in this document are subject to change without notice. All statements, information, and recommendations in this document are believed to be accurate, but are presented without warranty of any kind, express, or implied. Users must take full responsibility for their application of any products. Trademarks, brand names and products mentioned in this document are the property of their respective owners. All such references are used strictly in an editorial fashion with no intent to convey any affiliation with the name or the product's rightful owner.
Document Name: REF_Technical Reference Guide iDX 3.3_Rev B_02102015.pdf Document Part Number: T0000598
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
Contents
List of Figures
. . . xivAbout
. . . xviiPurpose. . . xvii
Audience . . . xvii
Contents . . . xvii
Document Conventions . . . xix
Getting Help . . . xx
Document Set . . . xx
1 iDirect System Overview
. . . .1System Overview . . . .1 IP Network Architecture . . . .3
2 DVB-S2 in iDirect Networks
. . . .7 DVB-S2 Key Concepts . . . .7 DVB-S2 in iDirect . . . .9 DVB-S2 Downstream . . . .9 ACM Operation . . . 10Quality 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
3 Modulation Modes and FEC Rates
. . . 19iDirect Modulation Modes And FEC Rates . . . 19
DVB-S2 Modulation Modes and FEC Rates . . . 19
2D 16-State Inbound Coding for DVB-S2 Networks . . . 19
TDMA Waveform Enhancements . . . 20
4 iDirect Spread Spectrum Networks
. . . 23Overview of Spread Spectrum . . . 23
Spread Spectrum Hardware Components . . . 24
Supported Forward Error Correction (FEC) Rates . . . 24
TDMA Upstream Specifications . . . 25
SCPC Upstream Specifications . . . 25
5 Multichannel Line Cards
. . . 27Multichannel Line Card Model Types . . . 27
Multichannel Line Card Receive Modes . . . 27
Multichannel Line Card Restrictions and Limits . . . 28
6 SCPC Return Channels
. . . 31Hardware Support and License Requirements. . . 31
Single Channel vs. Multichannel SCPC Return . . . 32
SCPC Return Feature on Remotes . . . 32
VNO for SCPC Return. . . 33
7 Adaptive TDMA
. . . 35Theory of Operation . . . 35
Short Term Adaptivity and Real-Time Resource Management . . . 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
8 Multicast Fast Path
. . . 43Overview. . . .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
. . . 47Quality 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
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
. . . 75All 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
. . . 79TDMA 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
. . . 89Overview. . . .89
Feature Description . . . 90
13 Verifying Error Thresholds Using IP Packets
. . . 95Introduction. . . .95
TDMA Upstream Threshold Testing . . . 95
Upstream Example 1. . . 96
DVB-S2 Downstream Threshold Testing . . . 97
Downstream Example . . . 97
14 Global NMS Architecture
. . . 99How the Global NMS Works. . . 99
Sample Global NMS Network. . . 100
15 Security Best Practices
. . . 101Hub and NMS Server Security . . . 101
Network Isolation and External Access. . . 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
. . . 105Remote Distribution . . . 105
De-coupling of NMS and Data Path Components. . . 105
17 Distributed NMS Server
. . . 107Distributed NMS Server Architecture . . . 107
iBuilder and iMonitor. . . 108
18 Transmission Security (TRANSEC)
. . . 109What is TRANSEC? . . . 109
iDirect TRANSEC . . . 110
TRANSEC Key types . . . 110
DVB-S2 Downstream TRANSEC . . . 111
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
. . . 123Feature 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. . . 130Considerations 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
. . . 133Automatic 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
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
. . . 147Feature Description . . . 147
Configuring Wait Time Interval for an Out-of-Network Remote . . . 148
23 Carrier Occupied Bandwidth
. . . 149Overview. . . 149
Considerations When Determining Guard Band . . . 150
DVB-S2 Roll-Off Factors . . . 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
. . . 157Background . . . 157
Feature Description . . . 157
25 Transmit Key Line
. . . 159Feature Description . . . 159
26 NMS Database Replication
. . . 161Benefits 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
. . . 173iDirect Licensing Requirements . . . 173
28 Hub Line Card Failover
. . . 175Basic Failover Concepts . . . 175
Warm Standby versus Cold Standby Line Card Failover . . . 175
Failover Sequence of Events . . . 176
29 NMS, PP and GKD Server Port Assignments
. . . 179NMS Server Ports . . . 179
PP Controller Ports . . . 181
GKD Server Ports . . . 181
Protocol Processor Ports . . . 181
Port Assignments for NMS/Upstream Router Traffic Flow . . . 182
30 VRRP and Remote LAN Port Monitoring
. . . 183VRRP 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
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
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
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
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
• 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
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.
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
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.
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.
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.
IP Network Architecture
IP Network Architecture
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.
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
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
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.
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)
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.
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.
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.
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
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
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.
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
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.
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
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).
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.
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
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.
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.
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