iDX Release 2.0
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 2.0_Rev F_062410.pdf Document Part Number: T0000240
List of Figures . . . viii
List of Tables . . . .x
About This Guide
Purpose. . . xi
Intended Audience . . . xi
Contents Of This Guide . . . xi
Document Conventions . . . xii
Related Documents . . . xiii
Getting Help . . . xiii
1 iDirect System Overview
System Overview . . . 1
IP Network Architecture . . . 3
2 DVB-S2 in iDirect Networks
DVB-S2 Key Concepts . . . 7
DVB-S2 in iDirect . . . 9
DVB-S2 Downstream . . . 10 ACM Operation . . . 11Quality of Service in DVB-S2 ACM Networks . . . 15
DVB-S2 Configuration . . . 19
2D 16-State Inbound Coding for DVB-S2 Networks . . . 23
4 iDirect Spread Spectrum Networks
What is Spread Spectrum? . . . 25
Spread Spectrum Hardware Components . . . 27
Downstream Specifications . . . 27
Supported Forward Error Correction (FEC) Rates . . . 28
Upstream Specifications . . . 28
5 QoS Implementation Principles
Quality of Service (QoS). . . 29
QoS Measures. . . 29
QoS Application, iSCPC and Filter Profiles . . . 30
Classification Profiles for Applications . . . 31
Service Levels . . . 31
Packet Scheduling . . . 32
Group QoS . . . 35
Group QoS Structure . . . 35
Group QoS Scenarios . . . 38
Application Throughput . . . 49
QoS Properties . . . 49
Packet Segmentation. . . 52
Application Latency . . . 52
Maximum Channel Efficiency vs. Minimum Latency . . . 52
6 Configuring Transmit Initial Power
What is TX Initial Power? . . . 53
How To Determine The Correct TX Initial Power . . . 53
All Remotes Need To Transmit Bursts in The Same C/N Range. . . 54
What Happens When TX Initial Power Is Set Incorrectly? . . . 55
When TX Initial Power is Too High . . . 55
Sample Global NMS Network. . . 58
8 Hub Network Security Recommendations
Limited Remote Access . . . 59
Root Passwords . . . 59
9 Global Protocol Processor Architecture
Remote Distribution . . . 61
De-coupling of NMS and Data Path Components . . . 61
10 Distributed NMS Server
Distributed NMS Server Architecture . . . 63
iBuilder and iMonitor . . . 64
dbBackup/dbRestore and the Distributed NMS . . . 65
11 Transmission Security (TRANSEC)
What is TRANSEC? . . . 67
iDirect TRANSEC . . . 68
TRANSEC Downstream . . . 69
TRANSEC Upstream . . . 71
TRANSEC Key Management. . . 72
TRANSEC Remote Admission Protocol . . . 74
Reconfiguring the Network for TRANSEC . . . 75
12 Fast Acquisition
Feature Description . . . 77
13 Remote Sleep Mode
Feature Description . . . 79
Power Consumption . . . 81
14 Automatic Beam Selection
Automatic Beam Selection Overview . . . 83
Theory of Operation . . . 83
Beam Characteristics: Visibility and Usability . . . 84
Selecting a Beam without a Map . . . 85
Controlling the Antenna . . . 85
IP Mobility . . . 86
Operational Scenarios . . . 86
Creating the Network . . . 86
Adding a Vessel . . . 87
Normal Operations . . . 87
Mapless Operations . . . 88
Blockages and Beam Outages . . . 88
Error Recovery . . . 89
15 Hub Geographic Redundancy
Feature Description . . . 91
Configuring Wait Time Interval for an Out-of-Network Remote . . . 92
16 Carrier Bandwidth Optimization
Overview. . . 93
Increasing User Data Rate . . . 94
Decreasing Channel Spacing to Gain Additional Bandwidth . . . 95
17 Alternate Downstream Carrier
Background . . . 97
Feature Description . . . 97
18 Feature and Chassis Licensing
Licensed Features . . . 99
Warm Standby versus Cold Standby Line Card Failover . . . 101
Failover Sequence of Events . . . 102
Figure 1. Sample iDirect Network . . . 1
Figure 2. iDirect IP Architecture – Multiple VLANs per Remote . . . 3
Figure 3. iDirect IP Architecture – VLAN Spanning Remotes . . . 4
Figure 4. iDirect IP Architecture – Classic IP Configuration . . . 5
Figure 5. Comparison of SCPC, Constant Coding, and Adaptive Coding Modes . . . 9
Figure 6. Physical Layer Frames . . . 10
Figure 7. SNR Threshold vs. MODCOD for Evolution X3 and X5 Remotes . . . 12
Figure 8. SNR Threshold vs. MODCOD for the Evolution e8350 Remote . . . 13
Figure 9. Feedback Loop from Remote to Protocol Processor . . . 14
Figure 10. Feedback Loop with Backoff from Line Card to Protocol Processor . . . 14
Figure 11. Total Bandwidth vs. Information Rate in Fixed Bandwidth Operation . . . 16
Figure 12. EIR: Total Bandwidth vs. Information Rate as MODCOD Varies . . . 17
Figure 13. Spread Spectrum Network Diagram . . . 25
Figure 14. Remote and QoS Profile Relationship . . . 31
Figure 15. iDirect Packet Scheduling Algorithm . . . 33
Figure 16. Group QoS Structure . . . 35
Figure 17. Physical Segregation Scenario . . . 38
Figure 18. CIR Per Application Scenario . . . 39
Figure 19. Tiered Service Scenario . . . 40
Figure 20. Third Level VLAN Scenario . . . 42
Figure 21. Shared Remote Scenario . . . 43
Figure 22. Scaled Aggregate CIRs Below Partition’s CIR . . . 45
Figure 23. Scaled Aggregate CIRs Exceed Partition’s CIR . . . 46
Figure 24. Bandwidth Allocation Fairness Relative to CIR . . . 47
Figure 25. Bandwidth Allocation Fairness Relative to MODCOD . . . 48
Figure 26. C/N Nominal Range . . . 54
Figure 27. TX Initial Power Too High . . . 55
Figure 28. TX Initial Power Too Low . . . 56
Figure 29. Global NMS Database Relationships . . . 57
Figure 30. Sample Global NMS Network Diagram . . . 58
Figure 31. Protocol Processor Architecture . . . 62
Figure 32. Sample Distributed NMS Configuration . . . 64
Figure 33. dbBackup and dbRestore with a Distributed NMS . . . 65
Figure 34. Downstream Data Path . . . 69
Figure 35. SCPC TRANSEC Frame . . . 70
Figure 36. Upstream Data Path . . . 71
Figure 37. TDMA TRANSEC Slot . . . 71
Figure 42. Adding an Upstream Carrier By Reducing Carrier Spacing . . . 96 Figure 43. Line Card Failover Sequence of Events . . . 103
Table 1. DVB-S2 Modulation and Coding Schemes. . . 8
Table 2. ACM MODCOD Scaling Factors. . . 18
Table 3. Modulation Modes and FEC Rates . . . 22
Table 4. Modulation Modes and FEC Rates for 2D 16-State Inbound Coding . . . 23
Table 5. Block Sizes and IP Payload Sizes for 2D 16-State Inbound Coding . . . 24
Table 6. Spread Spectrum: Downstream Specifications . . . 27
Table 7. Spread Spectrum: Upstream Specifications. . . 28
Purpose
The Technical Reference Guide provides detailed technical information on iDirect technology and major features as implemented in iDX Release 2.0.
Intended Audience
The intended audience for this guide includes network operators using the iDirect iDS system, network architects, and anyone upgrading to iDX Release 2.0.
Note: It is expected that the user of this material has attended the iDirect IOM training course and is familiar with the iDirect network solution and associated equipment.
Contents Of This Guide
This document contains the following major sections:
• “iDirect System Overview”
• “DVB-S2 in iDirect Networks” • “Modulation Modes and FEC Rates” • “iDirect Spread Spectrum Networks” • “QoS Implementation Principles” • “Configuring Transmit Initial Power” • “Global NMS Architecture”
• “Hub Network Security Recommendations” • “Global Protocol Processor Architecture” • “Distributed NMS Server”
• “Transmission Security (TRANSEC)” • “Fast Acquisition”
• “Automatic Beam Selection” • “Hub Geographic Redundancy”
Document Conventions
This section illustrates and describes the conventions used throughout the manual. Take a look now, before you begin using this manual, so that you’ll know how to interpret the information presented.
Convention Description Example
Blue Courier font
Used when the user is required to enter a command at a command line prompt or in a console.
Enter the command:
cd /etc/snmp/
Courier font
Used when showing resulting output from a command that was entered at a command line or on a console. crc report all 3100.3235 : DATA CRC [ 1] 3100.3502 : DATA CRC [5818] 3100.4382 : DATA CRC [ 20] Bold Trebuchet font
Used when referring to text that appears on the screen on a windows-type Graphical User Interface (GUI).
Used when specifying names of commands, menus, folders, tabs, dialogs, list boxes, and options.
1. If you are adding 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.
Blue Trebuchet font
Used to show all
hyperlinked text within a document.
For instructions on adding an iSCPC line card to the network tree and selecting a Hub RFT for the line card, see“Adding an iSCPC Line Card” on page 108.
Bold italic Trebuchet font
Used to emphasize information for the user, such as in notes.
Note: Several remote model types can be configured as iSCPC remotes.
Red italic Trebuchet font
Used when the user needs to strictly follow the instructions or have additional knowledge about a procedure or action.
WARNING!
The following procedure may cause a network outage.information relevant to this release. Please consult these documents for information about installing and using iDirect’s satellite network software and equipment.
• iDX Release Notes
• iDX Software Installation Guide or Network Upgrade Procedure Guide • iDX iBuilder User Guide
• iDX iMonitor User Guide
• iDX Installation and Commissioning Guide for Remote Satellite Routers • iDX Features and Chassis Licensing Guide
• iDX Software Installation Checklist/Software Upgrade Survey • iDX Link Budget Analysis Guide
Getting Help
The iDirect Technical Assistance Center (TAC) is available to help you 24 hours a day, 365 days a year. Software user guides, installation procedures, a FAQ page, and other documentation that supports our products are available on the TAC webpage. Please access our TAC webpage at: http://tac.idirect.net.
If you are unable to find the answers or information that you need, you can contact the TAC at (703) 648-8151.
If you are interested in purchasing iDirect products, please contact iDirect Corporate Sales by telephone or email.
Telephone: (703) 648-8000 Email: [email protected]
iDirect strives to produce documentation that is technically accurate, easy to use, and helpful to our customers. Your feedback is welcomed! Send your comments to [email protected].
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 nodes. iDX Release 2.0 supports both iDirect SCPC downstream carriers and DVB-S2 downstream carriers. An example iDirect network is shown in Figure 1. iDX 2.0 does not support iSCPC or Mesh networks.
The iDirect Hub equipment consists of an iDirect Hub Chassis with Hub Line Cards, a Protocol Processor (PP), a Network Management System (NMS) and the appropriate RF equipment. Each remote node consists of an iDirect broadband router and the appropriate external VSAT equipment. The remotes transmit to the hub on one or more shared upstream carriers using Deterministic-Time Division Multiple Access (D-TDMA), based on dynamic timeplan slot assignment generated at the Protocol Processor.
The selection of an upstream carrier by a remote is determined either at network acquisition time or dynamically at run-time, based on a network configuration setting. iDirect software has features and controls that allow the system to be configured to provide QoS and other traffic engineered solutions to remote users. All network configuration, control, and monitoring functions are provided via the integrated NMS.
The iDirect software provides:
• Packet-based and network-based QoS, TCP acceleration • 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
• VoIP support via voice optimized features such as cRTP
An iDirect network interfaces to the external world through IP over Ethernet ports on the remote unit and the Protocol Processor at the hub.
IP Network Architecture
The following figures illustrate the basic iDirect IP network architectures. • Figure 2, “iDirect IP Architecture – Multiple VLANs per Remote”
• Figure 3, “iDirect IP Architecture – VLAN Spanning Remotes”
• Figure 4, “iDirect IP Architecture – Classic IP Configuration”
Figure 4. iDirect IP Architecture – Classic IP Configuration
iDirect allows you to mix traditional IP routing based networks with VLAN based
configurations. This capability provides support for customers that have conflicting IP address ranges in a direct fashion, and multiple independent customers at a single remote site by configuring multiple VLANs directly on the remote.
In addition to end-to-end VLAN connection, the system supports RIPv2 in an end-to-end manner including over the satellite link; RIPv2 can be configured on per-network interface.
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.
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/Hz) • 8PSK (3 bits/Hz) • 16PSK (4 bits/Hz)
Coding refers to the error-correction coding schemes available. Low-Density Parity Coding (LDPC) and Bose-Chaudhuri-Hocquenghem (BCH) codes are used in DVB-S2. Effective rates are 1/4 through 9/10. The 9/10 coding rates are not supported for short BBFRAMEs.
The DVB-S2 standard does not support every combination of modulation and coding. DVB-S2 specifies the MODCODs shown in Table 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 defines three methods of applying modulation and coding to a data stream:
• CCM (Constant Coding and Modulation) specifies that every BBFRAME is transmitted at the
same MODCOD. Effectively, the iDirect SCPC system is a CCM system.
Note: In iDX Release 2.0, you can simulate a CCM outbound carrier using short frames by selecting ACM and setting the Maximum and Minimum MODCODs to the same value. CCM using long frames will be supported in future releases. See the iBuilder User Guide for details on configuring your carriers.
• ACM (Adaptive Coding and Modulation) specifies that every BBFRAME can be transmitted
on a different MODCOD. Remotes receiving an ACM carrier cannot anticipate the MODCOD of the next BBFRAME. A DVB-S2 demodulator must be designed to handle dynamic MODCOD variation.
Table 1. DVB-S2 Modulation and Coding Schemes
# Modulation Code Notes
1 QPSK 1/4 ACM or CCM 2 1/3 3 2/5 4 1/2 5 3/5 6 2/3 7 3/4 8 4/5 9 5/6 10 8/9 11 9/10 CCM only 12 8PSK 3/5 ACM or CCM 13 2/3 14 3/4 15 5/6 16 8/9 17 9/10 CCM only 18 16APSK 2/3 ACM or CCM 19 3/4 20 4/5 21 5/6 22 8/9 23 9/10 CCM only
• VCM (Variable Coding and Modulation) specifies that MODCODs are assigned according to
service type. As in ACM mode, the resulting downstream contains BBFRAMEs transmitted at different MODCODs. (IDirect does not support VCM on the downstream.)
Figure 5 compares iDirect’s SCPC Mode, CCM Mode and ACM Mode.
Figure 5. Comparison of SCPC, Constant Coding, and Adaptive Coding Modes
DVB-S2 in iDirect
iDirect DVB-S2 networks support ACM on the downstream carrier with all modulations up to 16APSK. An iDirect DVB-S2 network uses short DVB-S2 BBFARMES for ACM. iDirect does not support VCM on the downstream carrier.
iDX Release 2.0 supports the following DVB-S2 hardware: • Evolution eM1D1 line card (Tx/Rx; SCPC or DVB-S2) • Evolution XLC-11 line card (Tx/Rx; SCPC or DVB-S2)
• Evolution XLC-10 line card (Tx-only; DVB-S2 networks only)
• Evolution XLC-M line card (Rx-only; one inbound channel; SCPC or DVB-S2 networks) • Evolution e8350 remote satellite router (SCPC or DVB-S2 networks)
• Evolution iConnex e800/e850mp remote satellite routers (SCPC or DVB-S2 networks) • Evolution X3 remote satellite router (DVB-S2 networks only)
• Evolution X5 remote satellite router (SCPC or DVB-S2 networks)
The eM1D1 line card and the XLC-11 line card are Tx/Rx line cards. Both line cards can transmit either an iDirect SCPC or a DVB-S2 downstream carrier while receiving a TDMA upstream carrier. An XLC-10 line card is a Tx-only line card that can only be deployed in
DVB-DVBS2 : ACM Mode:
Each BB Frame: potentially different MODCOD (any of QPSK1/4 , … , 16 PSK 9/ 10 ) QPSK TPC .793 QPSK TPC .793 ... time time time 8 PSK 9/10 8 PSK 9/10 8 PSK 9/10 8 PSK 9/10 ... 16P 5/6 16P 4/5 8 PSK 2/3 16P 4/5 QPSK 2/3 8 PSK 8/9 8 PSK 8/9 16P 8/9 8 PSK 3/4 SCPC Mode:
All Frames: single Modulation (QPSK or BPSK ) All Frames: single coding (TPC 0 .793, etc. )
DVBS2 : CCM Mode:
S2 networks only. An XLC-M line card is multi-channel, Rx-only line card that can be deployed in either DVB-S2 or iDirect SCPC networks.
Note: In iDX Release 2.0, an XLC-M line card only supports a single inbound channel. Note: The eM1D1, XLC-11, and XLC-M line cards all require the correct corresponding
hub firmware package to operate in a DVB-S2 or iDirect SCPC network. These line cards require the evo_d_hub firmware for a DVB-S2 network and the evo_l_hub firmware for an SCPC network. See the iBuilder User Guide chapter titled “Converting Between SCPC and DVB-S2 Networks” for details.
An Evolution e8350, e800, e850 or X5 remote satellite router can receive either an SCPC or a DVB-S2 downstream carrier while transmitting on the TDMA upstream carrier. An Evolution X3 remote satellite router can only operate in DVB-S2 networks.
DVB-S2 Downstream
An iDirect SCPC network is effectively CCM on the downstream. At configuration time, a modulation (such as BPSK) and coding rate (such as TPC 0.79) are selected. These
characteristics of the downstream are fixed for the duration of the operation of the network. A DVB-S2 downstream can be configured as CCM (future) or ACM. If you configure the
downstream as ACM, it is not constrained to operate at a fixed modulation and coding. Instead, the modulation and coding of the downstream varies within a configurable range of MODCODs.
An iDirect DVB-S2 downstream contains a continuous stream of Physical Layer Frames
(PLFRAMEs). The PLHEADER indicates the type of modulation and error correction coding used on the subsequent data. It also indicates the data format and frame length. Refer to Figure 6.
Figure 6. Physical Layer Frames
The PLHEADER always uses /2 BPSK modulation. Like most DVB-S2 systems, iDirect injects pilot symbols within the data stream. The overhead of the DVB-S2 downstream varies between 2.65% and 3.85%.
The symbol rate remains fixed on the DVB-S2 downstream. Variation in throughput is realized through DVB-S2 support, and the variation of MODCODs in ACM Mode. The maximum possible throughput of the DVB-S2 carrier (calculated at 45 MSps and highest MODCOD 16APSK 8/9) is approximately 155 Mbps. As with iDirect SCPC networks, multiple protocol processors may be required to support high traffic to multiple remotes.
iDirect uses DVB-S2 “Generic Streams” for encapsulation of downstream data between the DVB-S2 line cards and remotes. Although the DVB-S2 standard includes the provision for generic streams, it is silent on how to encapsulate data in this mode. iDirect uses the proprietary LEGS (Lightweight Encapsulation for Generic Streams) protocol for this purpose.
PLHEADER: signals MODCOD and frame
length (always /2 BPSK) Pilot symbols: unmodulated carrier Data symbols: QPSK, 8PSK, 16APSK, or 32APSK
LEGS maximizes the efficiency of data packing into BBFRAMES on the downstream. For example, if a timeplan only takes up 80% of a BBFRAME, the LEGS protocol allows the line card to include a portion of another packet that is ready for transmission in the same frame. This results in maximum use of the downstream bandwidth.
ACM Operation
ACM mode allows remotes operating in better signal conditions to receive data on higher MODCODs. This is accomplished by varying the MODCODs of data targeted to specific remotes to match their current receive capabilities.
Not all data is sent to a remote at its best MODCOD. Important system information (such 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 reliably receive this information.
The protocol processor determines the maximum MODCOD for all data sent to the DVB-S2 line card for transmission over the outbound carrier. However, the line card does not necessarily respect these MODCOD assignments. In the interest of downstream efficiency, some data scheduled for a high MODCOD may be transmitted at a lower one as an alternative to inserting padding bytes into a BBFRAME. When assembling a BBFRAME for transmission, the line card first packs all available data for the chosen MODCOD into the frame. If there is space left in the BBFRAME, and no data left for transmission at that MODCOD, the line card attempts to pack the remainder of the frame with data for higher MODCODs. This takes advantage of the fact that a remote can demodulate any MODCOD in the range between the 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 table in Figure 7 shows the SNR thresholds per MODCOD for the Evolution X3 and X5 remotes. The table in Figure 8 shows the SNR thresholds per MODCOD for the Evolution e8350 remote.These values are determined during hardware qualification. The graph shows how spectral efficiency increases as the MODCOD changes.
Figure 8. SNR Threshold vs. MODCOD for the Evolution e8350 Remote
The hub adjusts the MODCODs of the transmissions to the remotes by means of the feedback loop shown in Figure 9 on page 14. 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 reasons of downstream packing efficiency.
Figure 9 and Figure 10 show the operation of the SNR feedback loop and the behavior of the line card and remote during fast fade conditions. Figure 9 shows the basic SNR reporting loop described above. The example shows an XLC-10 line card transmitting to an X3 remote. However, the feedback loop discussion applies to any Evolution line card that is transmitting a DVB-S2 carrier to any Evolution remote.
Figure 9. Feedback Loop from Remote to Protocol Processor
Figure 10 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.
Quality of Service in DVB-S2 ACM Networks
iDirect QoS for DVB-S2 downstream carriers is basically identical to QoS for SCPC downstream carriers. (See “QoS Implementation Principles” on page 29.) 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, you can define a Maximum Information Rate (MIR) and/or a Committed Information Rate (CIR) at various levels of the QoS tree. (See the iBuilder User
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
Beginning with iDX Release 2.0, you can configure a Nominal MODCOD for DVB-S2 remotes operating in ACM mode. The Nominal MODCOD is the Reference Operating Point (ROP) for the remote. By default, a 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 maritime network where the Clear Sky MODCOD depends on the position of the ship, the Nominal MODCOD may be any point in the beam coverage at which the service provider chooses to guarantee the CIR.
The CIR and MIR granted to the remote are limited by the 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
Beginning with iDX Release 2.0, you 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 you 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 your link budget supports higher MODCODs but your remotes are using LNBs that do not have the phase stability required for the higher MODCODs. For example, a DRO LNB cannot support 16APSK due to phase instability at higher MODCODs.
Note that a 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.
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 11 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 11. Total Bandwidth vs. Information Rate in Fixed Bandwidth Operation
Enhanced Information Rate
As noted above, the occupied bandwidth for CIR or MIR varies per MODCOD. If, when
allocating downstream bandwidth for a remote, the system always attempted to meet these rates regardless of MODCOD, then a remote in a deep rain fade may be granted a
disproportionate share of bandwidth at the expense of other remotes in the network. On the other hand, if CIR and MIR settings were only honored at the 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 you to configure the system to maintain CIR or MIR during rain fade for the physical remote (Remote-Based Group QoS) or critical applications (Application-Based Group QoS). EIR only applies to networks that use DVB-S2 with Adaptive Coding and Modulation (ACM). EIR can be enabled for a physical remote or at several levels of the Group QoS tree. For details on configuring EIR, see the iBuilder User Guide.
Nominal @ ClearSky 0 50 100 150 200 250 300 350 400 0 100 200 300 400 500 600 Re la ti v e Ba n d w id th CI R
Fixed Bandwidth
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 12. The remote’s Nominal MODCOD is labeled “Nominal” in the figure. The system maintains the CIR and MIR down to the EIR Minimum MODCOD. Notice in the figure that when the remote is operating below EIR Minimum MODCOD, it is granted the same amount of satellite bandwidth as at the remote’s Nominal MODCOD.
Figure 12. EIR: Total Bandwidth vs. Information Rate as MODCOD Varies
Nominal EIR Min
0 50 100 150 200 250 300 350 400 0 100 200 300 400 500 600 Re la ti v e Ba n d w id th CI R
EIR Mode
Scaling Factors for Fixed Bandwidth Allocation
Table 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. 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
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 44 and page 46.
Note: When bandwidth is allocated for a remote, the CIR and MIR are scaled to the remote’s Nominal MODCOD. At higher levels of the Group QoS tree (Bandwidth Group, Service Group, etc.) CIR and MIR are scaled to the network’s best MODCOD.)
Bandwidth Allocation Fairness
Beginning with iDX Release 2.0, there are two configurable options for bandwidth allocation fairness:
• Allocation Fairness Relative To CIR • Allocation Fairness Relative to MODCOD
Enabling or disabling either or both of these options for your Group QoS nodes or for your physical remotes affects how CIR and MIR bandwidth is apportioned during bandwidth contention. Allocation Fairness Relative to MODCOD only affects bandwidth allocation on DVB-S2 ACM outbound carriers. Allocation Fairness Relative to CIR affects bandwidth allocation in general.
For a detailed explanation of these options, see the Quality of Service chapter in the iBuilder
User Guide. For sample scenarios illustrating the use of these options, see “Bandwidth Allocation Fairness Relative to CIR ” on page 47 and “Bandwidth Allocation Fairness Relative to MODCOD” on page 48.
DVB-S2 Configuration
The iBuilder GUI allows you to configure various parameters that affect the operation of your DVB-S2 networks. For details on configuring DVB-S2, see the iBuilder User Guide. The
following areas are affected:
• Downstream Carrier Definition: When you add an ACM DVB-S2 downstream carrier, you
must specify a range of MODCODs over which the carrier will operate. Error correction for the carrier is fixed to LDPC and BCH. In addition, you cannot select an information rate or transmission rate for a DVB-S2 carrier as an alternative to the symbol rate, since these rates will vary dynamically with changing MODCODs.
However, beginning with iDX Release 2.0, iBuilder provides a MODCOD Distribution Calculator that allows you to estimate the overall IP Data Rate for your carrier based on the distribution of the Nominal MODCODs of the remotes in your network. You can access this calculator by clicking the MODCOD Distribution button on the DVB-S2 Downstream Carrier dialog box. A similar button allows you to estimate CIR and MIR bandwidth requirements at various levels of the Group QoS tree.
• Multicast MODCOD: By default, all multicast data on an ACM downstream carrier is
transmitted at the lowest MODCOD of the carrier. You can configure different MODCODs for your user multicast traffic by selecting Multicast MODCODs for your Multicast
Applications in iBuilder. See the Quality of Service chapter of the iBuilder User Guide for details.
• Remote Nominal MODCOD and Remote Maximum MODCOD. These remote parameters are discussed in detail at the beginning of this section. You can configure these parameters on the Remote QoS tab in iBuilder.
• DVB-S2 Line Card Definition: When you add a DVB-S2 line card, you must configure a
second IP port (called the GIG0 port) in addition to the management IP port. All data to be transmitted on the DVB-S2 downstream carrier is sent to this port.
• DVB-S2 Network-Level Parameters: iBuilder allows you to configure the network-level
parameters that control how a DVB-S2 network behaves when ACM is enabled for your downstream carrier. These parameters affect the behavior of the system during remote fade conditions.
DVB-S2 Performance Monitoring
iMonitor allows you to monitor the following characteristics of your DVB-S2 outbound carriers: • ACM Gain represents the increase in performance achieved on a DVB-S2 outbound carrier when the MODCOD used to transmit data is higher than the minimum MODCOD configured for the carrier. ACM Gain can be monitored at the Network, Inroute Group, Remote and Tx Line card levels of the iMonitor tree.
• You can examine how the downstream data is distributed across the range of MODCODs configured for an ACM carrier. MODCOD distribution can be monitored at the Network, Remote and Tx Line Card levels of the iMonitor tree.
• In an ACM network, each DVB-S2 remote periodically reports its current Signal-to-Noise Ratio (SNR) to the protocol processor. Based on the 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.
• Beginning with iDX Release 2.0, the NMS provides statistics on the operating point of each remote. In iMonitor, you can use these statistics to determine the percentage of time a remote is operating at its Nominal MODCOD and at other MODCODs. Although independent of traffic, this allows you to compare a remote’s actual operating point with its
configured (or contractual) operating point and make adjustments to your network in the case of descrepancies.
FEC Rates
This chapter describes the modulation modes and Forward Error Correction (FEC) rates that are supported in iDX Release 2.0.
iDirect Modulation Modes And FEC Rates
A complete set of modulation modes, channel types, and FEC rates are shown in the following tables. Cells marked with an “X” represent combinations of modulation and FEC rates that are not supported.
iDX Release 2.0 supports star networks with DVB-S2 or iDirect SCPC downstream carriers. In this release, an Evolution eM1D1, XLC-11 or XLC-10 line card can transmit a DVB-S2
downstream carrier. Only Evolution remote satellite routers (e8350, iConnex e800/e850mp, X3 or X5) can receive DVB-S2 downstream carriers.
You can configure some Evolution hardware in iBuilder to use either a DVB-S2 or an SCPC downstream carrier. Evolution eM1D1 and XLC-11 line cards can transmit either carrier type. Evolution e8350, X5, e800, and e850mp remotes can receive either carrier type.
As always, iNFINITI hardware only supports SCPC downstream carriers. iNFINITI hardware does not support DVB-S2.
Note: For specific Eb/No values for each FEC rate and Modulation combination, refer to the iDX 2.0 Link Budget Analysis Guide, which is available for download from the TAC web page located at http://tac.idirect.net.
Table 3 on page 22 shows the upstream and downstream Modulation Modes and FEC Rates for Evolution and iNFINITI hardware. iDirect also supports 2D 16-State Inbound Coding on
upstream TDMA carriers in DVB-S2 networks only. For details see “2D 16-State Inbound Coding for DVB-S2 Networks” on page 23.
In addition to the advantages offered by 2D 16-State Inbound Coding, Evolution line cards have much greater FPGA resources than iNFINITI line cards, allowing improved demodulator performance for existing TCP FEC rates even for SCPC networks containing iNFINITI remotes. For example
• QPSK Rate 0.533 TPC has a 1 dB improvement in C/N and Ebi/No threshold on Evolution line cards when compared to iNFINITI line cards.
Note: For specific Eb/No values for each FEC rate and Modulation combination, refer to the iDirect Link Budget Analysis Guide, which is available for download from the TAC web page located at http://tac.idirect.net.
Table 3. Modulation Modes and FEC Rates
Note: For the list of DVB-S2 downstream MODCODs supported in iDX 2.0, see Table 1
2D 16-State Inbound Coding for DVB-S2 Networks
Beginning with iDX Release 2.0, iDirect supports 2D 16-State Inbound Coding on upstream TDMA carriers in DVB-S2 networks. 2D 16-State Coding is extremely efficient inbound coding that provides maximum flexibility to network designers.
2D 16-State Coding supports three payload sizes: a 100 byte payload (88 byte IP payload), a 170 byte payload (158 byte IP payload), and a 438 byte payload (426 byte IP payload). The new small payload size has a sixteen byte larger payload than the QPSK .66 1K TPC block, ensuring the same low latency at call connection for VOIP applications. The large payload size is similar to the 4k TPC block to allow the same low TDMA overhead performance. The new medium payload size provides an intermediate option when considering the trade off between bandwidth granularity and reducing the TDMA overhead.
2D 16-State Coding has a number of benefits:
• More granular FEC and payload size choices than turbo codes or LDPC • Efficiency gains on average of 1 dB
• Cost savings from the use of smaller antenna and BUC sizes • Easy implementation since no new network design is required
2D 16-State Coding supports easy mapping of existing TPC to 2D 16-State configurations. For example, the QPSK 2D16S-100B-3/4 offers similar performance and better spectral efficiency than the TPC QPSK 1k block with .66 FEC. For detailed options, see the iDX 2.0 Link Budget
Analysis Guide.
Table 4 shows the upstream Modulation and Coding rates available per payload size when using 2D 16-State Inbound Coding. Table 5 shows the IP payload and block sizes for each supported payload size.
Note: For specific Eb/No values for each FEC rate and Modulation combination, refer to the iDX 2.0 Link Budget Analysis Guide.
Networks
This section provides information about Spread Spectrum technology in an iDirect network. It discusses the following topics:
• “What is Spread Spectrum?” on page 25
• “Downstream Specifications” on page 27
• “Upstream Specifications” on page 28
What is Spread Spectrum?
Spread Spectrum (SS) is a transmission technique in which a pseudo-noise (PN) code is employed as a modulation waveform to “spread” the signal energy over a bandwidth much greater than the signal information bandwidth. The signal is “despread” at the receiver by using a synchronized replica of the pseudo-noise code. By spreading the signal information over greater bandwidth, less transmit power is required. A sample SS network diagram is shown in Figure 13.
Figure 13. Spread Spectrum Network Diagram
Spreading takes place when the input data (dt) is multiplied with the PN code (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).
as Comms-On-The-Move (COTM) because the small antenna (typically sub-meter) used on mobile vehicles has small aperture size, large beam width, and high pointing error which can combine to cause ASI. Enabling SS reduces the spectral density of the transmission so that it is low enough to avoid interfering with adjacent satellites.
Conversely, when receiving through a COTM antenna, SS improves carrier performance in cases of ASI (channel/interference).
The iDirect SS is an extension of BPSK modulation in both upstream and downstream. The signal is spread over wider bandwidth according to a Spreading Factor (SF) that you select. You can select a downstream Spreading Factor of 1, 2, 4 or 8. You can select an upstream Spreading Factor of 1, 2, 4, 8 or 16.
Note: A Downstream Spreading Factor of 8 is only available for Evolution hub line cards transmitting to Evolution Remotes. Upstream Spreading Factors of 8 and 16 are only available for Evolution Remotes transmitting to Evolution hub line cards.
Note: The following uses of Spread Spectrum require a license from iDirect: Upstream Spread Spectrum for the Evolution X5 remote; Upstream Spread Spectrum for the XLC-11 line card; and Downstream Spread Spectrum for the XLC-11 line card.
Each symbol in the spreading code is called a “chip”, and the spread rate is the rate at which chips are transmitted. For example, selecting an SF of 1 means that the spread rate is one chip per symbol (which is equivalent to regular BPSK, and therefore, there is no spreading). Selecting an SF of 4 means that the spread rate is four chips per symbol.
An additional Spreading Factor, COTM SF=1, is for upstream TDMA carriers only. Like an SF of 1, if you select COTM SF=1, there is no spreading. However, the size of the carrier unique word is increased, allowing mobile remotes to remain in the network when they might otherwise drop out. An advantage of this spreading factor is that you can receive error-free data at a slightly lower C/N compared to regular BPSK. However, carriers with COTM SF=1 transmit at a slightly lower information rate.
COTM SF=1 is primarily intended for use by fast moving mobile remotes. The additional unique word overhead allows the remote to tolerate more than 10 times as much frequency offset as can be tolerated by regular BPSK. That makes COTM SF=1 the appropriate choice when the Doppler effect caused by vehicle speed and acceleration is significant even though the link budget does not require spreading. Examples include small maritime vessels, motor vehicles, trains, and aircraft. Slow moving, large maritime vessels generally do not require COTM SF=1. Spread Spectrum can also be used to hide a carrier in the noise of an empty transponder. However, SS should not be confused with Code Division Multiple Access (CDMA), which is the process of transmitting multiple SS channels simultaneously on the same bandwidth.
Spread Spectrum may also be useful in situations where local or RF interference is
unavoidable, such as hostile jamming. However, iDirect designed the Spread Spectrum feature primarily for COTM and ASI mitigation. iDirect SS may be a good solution for overcoming some instances of interference or jamming, but it is recommended that you discuss your particular application with iDirect sales engineering.
Spread Spectrum Hardware Components
The Hub Line Cards (HLC) that support Spread Spectrum are the iNFINITI M1D1-TSS line card, the Evolution eM1D1 line card, and the Evolution XLC-11 line card. (An XLC-11 line card must be licensed for upstream and/or downstream Spread Spectrum before this feature can be enabled on the line card.)
The iNFINITI M1D1-TSS line card occupies two slots in the hub chassis. Therefore, you can have a maximum of 10 iNFINITI M1D1-TSS line cards in one 20 slot chassis. Also, you cannot install an M1D1-TSS line card in slot 20. Evolution eM1D1 and XLC-11 line cards only require a single slot.
Note: You must install the M1D1-TSS HLC in a slot that has one empty slot to the right. For example, if you want to install the HLC in slot 4, slot 5 must be empty. Be sure that you also check chassis slot configuration in iBuilder to verify that you are not installing the HLC in a reserved slot.
The remotes that support spread spectrum are the iNFINITI 8350, the Evolution e8350, and the iConnex e800 and e850mp. The Evolution X5 supports upstream Spread Spectrum if Spread Spectrum is licensed on the remote. Other remotes do not currently support spread spectrum.
Downstream Specifications
The specifications for the spread spectrum downstream channel are outlined in Table 6.
Table 6. Spread Spectrum: Downstream Specifications
PARAMETERS VALUES ADDITIONAL INFORMATION
Modulation BPSK Other Modulations not supported in SS
Spreading Factor 1, 2, 4, 8 SF=1 results in no spreading
SF=8 requires Evolution hardware Symbol Rate 64 ksym/s - 15 Msym/s
Chip Rate 15 Mchip/s maximum FEC Rate 0.879, 0.793, 0.495
BER Performance Refer to the iDirect Link Budget Analysis Guide
Occupied BW 1.2 * Chip Rate Plus hub downcoverter oscillator
stability factor Spectral Mask IESS-308/309, MIL-STD 188xxx
Carrier Suppression > -30 dBc
Supported Forward Error Correction (FEC) Rates
The upstream and downstream FEC rates that are supported for Spread Spectrum in this release are described in the tables in “Modulation Modes and FEC Rates” on page 21.
Upstream Specifications
The specifications for the spread spectrum upstream channel are outlined in Table 7. The Spreading Factor COTM 1, used in fast moving mobile applications, is described on page 26.
Table 7. Spread Spectrum: Upstream Specifications
PARAMETERS VALUES ADDITIONAL INFORMATION
Modulation BPSK Other Modulations not supported
in SS Spreading Factor 1, 2, 4, 8 or 16
SFs of 8 and16 require Evolution hardware
SF=1 results in no spreading SF=8 and SF=16 require Evolution hardware
Symbol Rate 64 ksym/s - 7.5 Msym/s
Chip Rate 7.5 Mchip maximum
FEC Rate .66, .431, .533, 1/2, 2/3 Rates 1/2, 2/3 2D-16 coding
available in DVB-S2 networks only 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
Principles
This chapter describes how you can configure Quality of Service definitions to achieve maximum efficiency by prioritizing traffic.
Quality of Service (QoS)
Quality of Service is defined as the way IP traffic is classified and prioritized as it flows through the iDirect system.
QoS Measures
When discussing QoS, at least four interrelated measures are considered. These are Throughput, Latency, Jitter, and Packet Loss. This section describes these parameters in general terms, without specific regard to an iDirect network.
Throughput. Throughput is a measure of capacity and indicates the amount of user data that
is received by the end user application. For example, a G729 voice call without additional compression (such as cRTP), or voice suppression, requires a constant 24 Kbps of application level RTP data to achieve acceptable voice quality for the duration of the call. Therefore this application requires 24 Kbps of throughput. When adequate throughput cannot be achieved
on a continuous basis to support a particular application, Qos can be adversely affected.
Latency. Latency is a measure of the amount of time between events. Unqualified latency is
the amount of time between the transmission of a packet from its source and the receipt of that packet at the destination. If explicitly qualified, it may also mean the amount of time between a request for a network resource and the time when that resource is received. In general, latency accounts for the total delay between events and it includes transit time, queuing, and processing delays. Keeping latency to a minimum is very important for VoIP applications for human factor reasons.
Jitter. Jitter is a measure of the variation of latency on a packet-by-packet basis. Referring to
the G729 example again, if voice packets (containing two 10 ms voice samples) are
transmitted every 20 ms from the source VoIP equipment, ideally those voice packets arrive at the destination every 20 ms; this is a jitter value of zero. When dealing with a packet-switched network, zero jitter is particularly difficult to guarantee. To compensate for this, all VoIP equipment contains a jitter buffer that collects voice packets and sends them at the
Packet Loss. Packet Loss is a measure of the number of packets that are transmitted by a
source, but not received by the destination. The most common cause of packet loss on a network is network congestion. Congestion occurs whenever the volume of traffic exceeds the available bandwidth. In these cases, packets are filling queues internal to network devices at a rate faster than those packets can be transmitted from the device. When this condition exists, network devices drop packets to keep the network in a stable condition. Applications that are built on a TCP transport interpret the absence of these packets (and the absence of their related ACKs) as congestion and they invoke standard TCP slow-Start and congestion avoidance techniques. With real time applications, such as VoIP or streaming video, it is often impossible to gracefully recover these lost packets because there is not enough time to retransmit lost packets. Packet loss may affect the application in adverse ways. For example, parts of words in a voice call may be missing or there maybe an echo; video images may break up or become block-like (pixilation effects).
QoS Application, iSCPC and Filter Profiles
QoS Profiles are defined by Application Profiles, iSCPC Profiles and Filter Profiles. An Application or iSCPC Profile is a group of service levels, collected together and given a user-defined name. A QoS Filter Profile encapsulates a single filter definition, and it consists of a set of rules rather than a set of service levels. Application, iSCPC and Filter Profiles are applied to downstream and upstream traffic independently, so that upstream traffic may have certain QoS definitions, whereas downstream traffic may have a different set of QoS
definitions. (Figure 14 on page 31).
iSCPC Profiles and Application Profiles are used differently in TDMA networks than they are in iSCPC connections.
• For TDMA networks, Application Profiles define the Group QoS Applications that you add to your Service Profiles. You then assign the Service Profile to your TDMA remotes using the Group QoS tab for your Bandwidth Pools.
• iSCPC Profiles are assigned directly to iSCPC line cards on the QoS tab. The Line Card assignments of iSCPC Profiles are mirrored on the iSCPC remote.
Application Profiles are only used for Group QoS. iSCPC Profiles are used only by iSCPC line cards and remotes and are not associated with Group QoS. See “Group QoS” on page 35 for a general discussion of Group QoS. For details on configuring profiles, see the chapter titled “Configuring Quality of Service for iDirect Networks” in the iBuilder User Guide.
Figure 14. Remote and QoS Profile Relationship
Classification Profiles for Applications
This section describes how the iDirect system distinguishes application IP packets from less important background traffic. Each packet that enters the iDirect system is classified into one of the configured Service Levels.
Service Levels
A Service Level may represent a single application (such as VoIP traffic from a single IP address) or a broad class of applications (such as all TCP based applications). Each Service Level is defined by one or more packet-matching rules. The set of rules for a Service Level allows logical combinations of comparisons to be made between the following IP packet fields:
• Source IP address • Destination IP address • Source port
• Destination port
• Protocol (such as DiffServ DSCP) • TOS priority
• TOS precedence • VLAN ID
Packet Scheduling
Packet Scheduling is a method used to transmit traffic according to priority and classification. In a network that has a remote that always has enough bandwidth for all of its applications, packets are transmitted in the order that they are received without significant delay.
Application priority makes little difference since the remote never has to select which packet to transmit next.
In a network where there are periods of time in which a remote does not have sufficient bandwidth to transmit all queued packets the remote scheduling algorithm must determine which packet from a set of queued packets across a number of service levels to transmit next. For each service level you define in iBuilder, you can select any one of three queue types to determine how packets using that service level are to be selected for transmission. These are Priority Queue, Class-Based Weighted Fair Queue (CBWFQ), and Best-Effort Queue.
The procedures for defining profiles and service levels are detailed in the chapter titled “Configuring Quality of Service for iDirect Networks” of the iBuilder User Guide.
Priority Queues are emptied before CBWFQ queues are serviced and CBWFQ queues are in turn emptied before Best Effort queues are serviced. Figure 15 on page 33 presents an overview of the iDirect packet scheduling algorithm.
Figure 15. iDirect Packet Scheduling Algorithm
The packet scheduling algorithm (Figure 15) first services packets from Priority Queues in order of priority, P1 being the highest priority for non-multicast traffic. It selects CBWFQ packets only after all Priority Queues are empty. Similarly, packets are taken from Best Effort Queues only after all CBWFQ packets are serviced.
You can define multiple service levels using any combination of the three queue types. For example, you can use a combination of Priority and Best Effort Queues only.
Priority Queues
There are four levels of user Priority Queues:
• Multicast: (Highest priority. Only for downstream multicast traffic.) • Level 1: P1
• Level 2: P2 • Level 3: P3
• Level 4: P4 (Lowest priority)
All queues of higher priority must be empty before any lower-priority queue are serviced. If two or more queues are set to the same priority level, then all queues of equal priority are emptied using a round-robin selection algorithm prior to selecting any packets from lower priority queues.
Class-Based Weighted Fair Queues
Packets are selected from Cl
ass-Based Weighted Fair Queues
for transmission based on the service level (or “class”) of the packet. Each service level is assigned a “cost”. Packet cost is defined as the cost of its service level multiplied by its length. Packets with the lowest cost are transmitted first, regardless of service level.The cost of a service level changes during operation. Each time a queue is passed over in favor of other service levels, the cost of the skipped queue is credited, which lowers the cost of the packets in that queue. Over time, all service levels get an opportunity to transmit occasionally even in the presence of higher priority traffic. Assuming there is a continuously congested link with an equal amount of traffic on each service level, the total bandwidth available is divided more evenly by deciding transmission priority based on each service level cost.
Best Effort Queues
Packets in Best Effort queues do not have priority or cost. All packets in these queues are treated equally by applying a round-robin selection algorithm to the queues. Best Effort queues are only serviced if there are no packets waiting in Priority Queues and no packets waiting CBWFQ Queues.
Group QoS
Group QoS (GQoS), introduced in iDS Release 8.0, enhances the power and flexibility of iDirect’s QoS feature for TDMA networks. It allows advanced network operators a high degree of flexibility in creating subnetworks and groups of remotes with various levels of service tailored to the characteristics of the user applications being supported.
Group QoS is built on the Group QoS tree: a hierarchical construct within which containership and inheritance rules allow the iterative application of basic allocation methods across groups and subgroups. QoS properties configured at each level of the Group QoS tree determine how bandwidth is distributed when demand exceeds availability.
Group QoS enables the construction of very sophisticated and complex allocation models. It allows network operators to create network subgroups with various levels of service on the same outbound carrier or inroute group. It allows bandwidth to be subdivided among
customers or Service Providers, while also allowing oversubscription of one group’s configured capacity when bandwidth belonging to another group is available.
Note: Group QoS applies only to TDMA networks. It does not apply to iDirect iSCPC connections.
For details on using the Group QoS feature, see the chapter titled “Configuring Quality of Service for iDirect Networks” in the iBuilder User Guide.
Group QoS Structure
The iDirect Group QoS model has the following structure as shown in Figure 16:
Bandwidth Pool
A Bandwidth Pool is the highest node in the Group QoS hierarchy. As such, all sub-nodes of a Bandwidth Pool represent subdivisions of the bandwidth within that Bandwidth Pool. In the iDirect network, a Bandwidth Pool consists of an outbound carrier or an inroute group.
Bandwidth Group
A Bandwidth Pool can be divided into multiple Bandwidth Groups. Bandwidth Groups allow a network operator to subdivide the bandwidth of an outroute or inroute group. Different Bandwidth Groups can then be assigned to different Service Providers or Virtual Network Operators (VNO).
Bandwidth Groups can be configured with any of the following:
• CIR and MIR: Typically, the sum of the CIR bandwidth of all Bandwidth Groups equals the total bandwidth. When MIR is larger than CIR, the Bandwidth Group is allowed to exceed its CIR when bandwidth is available.
• Priority: A group with highest priority receives its bandwidth before lower-priority groups. • Cost: Cost allows bandwidth allocations to different groups to be unequally apportioned
within the same priority. For equal requests, lower cost nodes are granted more bandwidth than higher cost nodes.
Bandwidth Groups are typically configured using CIR and MIR for a strict division of the total bandwidth among the groups. By default, any Bandwidth Pool is configured with a single Bandwidth Group.
Service Group
A Service Provider or a Virtual Network Operator can further divide a Bandwidth Group into sub-groups called Service Groups. A Service Group can be used strictly to group remotes into sub-groups or, more typically, to differentiate groups by class of service. For example, a platinum, gold, silver and best effort service could be defined as Service Groups under the same Bandwidth Group.
Like Bandwidth Groups, Service Groups can be configured with CIR, MIR, Priority and Cost. Service Groups are typically configured with either a CIR and MIR for a physical separation of the groups, or with a combination of Priority, Cost and CIR/MIR to create tiered service. By default, a single Service Group is created for each Bandwidth Group.
Application Group
An Application defines a specific service available to the end user. Application Groups are associated with any Service Group. The following are examples:
• VoIP • Video • Oracle • Citrix • VLAN • NMS Traffic
• Default
Each Application List can have one or more matching rules such as: • Protocol: TCP, UDP, and ICMP
• Source and/or Destination IP or IP Subnet • Source and/or Destination Port Number • DSCP Value or DSCP Ranges
• VLAN
Each Application List can be configured with any of the following: • CIR/MIR
• Priority • Cost
Service Profiles
Service Profiles are derived from the Application Group by selecting Applications and
matching rules and assigning per remote CIR and MIR when applicable. While the Application Group specifies the CIR/MIR by Application for the whole Service Group, the Service Profile specifies the per-remote CIR/MIR by Application. For example, the VoIP Application could be configured with a CIR of 1 Mbps for the Service Group in the Application Group and a CIR of 14 Kbps per-remote in the Service Profile.
Typically, all remotes in a Service Group use the Default Profile for that Service Group. When a remote is created under an inroute group, the QoS Tab allows the operator to assign the remote to a Bandwidth Group and Service Group. The new remote automatically receives the default profile for the Service Group. The Group QoS interface can also be used to assign a remote to a Service Group or change the assignment of the remote from one Service Group to another.
In order to accommodate special cases, however, additional profiles (other than the Default Profile) can be created. For example, profiles can be used by a specific remote to prioritize an Application that is not used by other remotes; to prioritize a specific VLAN on a remote; or to prioritize traffic to a specific IP address (such as a file server) connected to a specific remote in the Service Group. Or a Network Operator may want to configure some remotes for a single VoIP call and others for two VoIP calls. This can be accomplished by assigning
