Professional Documents
Culture Documents
Copyright © 2018. VT iDirect, Inc., 13861 Sunrise Valley Drive, Suite 300, Herndon, VA 20171, USA.
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.
VT iDirect® is a global leader in IP-based satellite communications providing technology and solutions
that enable our partners worldwide to optimize their networks, differentiate their services and
profitably expand their businesses. Our product portfolio, branded under the name iDirect®, sets
standards in performance and efficiency to deliver voice, video and data connectivity anywhere in the
world. VT iDirect® is the world’s largest TDMA enterprise VSAT manufacturer and is the leader in key
industries including mobility, military/government and cellular backhaul.
iDirect Government™, created in 2007, is a wholly owned subsidiary of iDirect and was formed to better
serve the U.S. government and defense communities.
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.
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
Figure 6-51. QoS Application: Multicast Fast Path Stream Number . . . . . . . . . . . . . . . . . . . 208
Figure 6-52. Remote L2oS Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Figure 6-53. Adding Layer 2 SVN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Figure 6-54. CE Tag Transparent SVNs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Figure 6-55. Remote MAC Address Aging Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Figure 6-56. L2oS Advanced Header Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Figure 6-57. Roaming Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Figure 6-58. Roaming Properties Update Dialog Box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Figure 6-59. Modifying Shared Parameters of All Roaming Remote Instances . . . . . . . . . . . . 219
Figure 6-60. iBuilder View Menu: Collapse Details Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 220
Figure 6-61. iBuilder Details View with Collapsed Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 220
Figure 6-62. Modifying Shared Parameters of Multiple Roaming Remotes Instances . . . . . . . . 221
Figure 6-63. Add Multiple Roaming Remotes Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Figure 6-64. Add Roaming Remotes to Networks Dialog Box . . . . . . . . . . . . . . . . . . . . . . . 223
Figure 6-65. Using the Console beamselector Command . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Figure 6-66. Selecting Compression Types on the Remote Information Tab . . . . . . . . . . . . . 225
Figure 6-67. Enabling L2TP Payload Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Figure 7-1. Group QoS Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Figure 7-2. Application Service Group vs. Remote Service Group . . . . . . . . . . . . . . . . . . . 235
Figure 7-3. Application Service Group Subtree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Figure 7-4. Remote Service Group Subtree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Figure 7-5. SCPC Remote Upstream QoS Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Figure 7-6. Remote Based Mode vs. Application Based Mode . . . . . . . . . . . . . . . . . . . . . . 241
Figure 7-7. Selecting the QoS Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Figure 7-8. Selecting the Group QoS View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Figure 7-9. Group QoS: Group View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Figure 7-10. Group QoS: Service Profile View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Figure 7-11. Group QoS: Service Profile-Remote View . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Figure 7-12. Remote Profile View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
Figure 7-13. Group QoS: Remote View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Figure 7-14. Configured vs. Effective MIR and CIR before Estimation . . . . . . . . . . . . . . . . . 252
Figure 7-15. MODCOD Distribution Calculator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Figure 7-16. Calculating Estimated Information Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Figure 7-17. Calculating Information Rate Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Figure 7-18. Configured vs. Effective MIR and CIR after Estimation. . . . . . . . . . . . . . . . . . . 255
Figure 7-19. Effective MIR and CIR in the Group View . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Figure 7-20. Competing Service Groups without Allocation Fairness Relative to CIR . . . . . . . 256
Figure 7-21. Results of Selecting Allocation Fairness Relative to CIR on Parent . . . . . . . . . . . 257
Figure 7-22. Configured vs. Effective Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Figure 7-23. Results of Selecting Allocation Fairness Relative to Nominal MODCOD . . . . . . . . 258
Figure 7-24. Selecting Allocation Fairness Relative to Nominal MODCOD . . . . . . . . . . . . . . . 260
Figure 13-20. VNO with Network Visibility and GQoS Node Ownership . . . . . . . . . . . . . . . . . 407
Figure 13-21. VNO Network Menu with Owned GQoS Nodes but No Network Access . . . . . . . . . 408
Figure 13-22. VNO with Network Write Access and GQoS Node Ownership . . . . . . . . . . . . . . . 408
Figure 13-23. VNO Network Menu with Owned GQoS Nodes and Write Access to Network . . . . . 409
Figure 13-24. VNO Ownership of Partial Bandwidth Pool . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Figure 13-25. VNO View of Partially-Owned Bandwidth Pool . . . . . . . . . . . . . . . . . . . . . . . . 410
Figure 13-26. Request Property Access for GQoS Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Figure 13-27. Group Dialog Box: Viewing GQoS Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Figure 13-28. Selecting VNO Permissions for GQoS Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Figure 13-29. A Visible Bandwidth Group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Figure 13-30. An Owned Service Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Figure 13-31. VNO View of the Group QoS Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Figure 13-32. Setting VNO Visibility for a QoS Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Figure 13-33. Enabling the Create Permission on a QoS Folder for a VNO User Group. . . . . . . . 416
Figure 13-34. Enabling the Write Permission for a QoS Profile. . . . . . . . . . . . . . . . . . . . . . . 417
Figure 13-35. User Dialog Box: Adding a User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Figure 13-36. Change Password Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
Figure 13-37. User Dialog Box: Cloning a User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 420
Figure 13-38. Active Users Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
Figure 14. Opening the Active Users Pane from the View Menu . . . . . . . . . . . . . . . . . . . . 422
Figure 15. User Account Options from the Active Users Pane . . . . . . . . . . . . . . . . . . . . . 423
Figure 13-1. Change Password Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Figure 13-2. Detected Default Password Dialog Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Figure 13-3. Message Displayed if Another User Has Modified the Configuration . . . . . . . . . . 427
Figure 14-1. Configuring the Adaptive Parameters for a Remote . . . . . . . . . . . . . . . . . . . . 431
Figure 14-2. Configuring an Upstream TDMA Carrier as Adaptive . . . . . . . . . . . . . . . . . . . . 432
Figure 14-3. Selecting the Payload Block Size for Adaptive and Static Carriers . . . . . . . . . . . 432
Figure 14-4. Enabling Superburst for TDMA Upstream Carrier . . . . . . . . . . . . . . . . . . . . . . 432
Figure 14-5. Removing Existing Carriers from an Inroute Group . . . . . . . . . . . . . . . . . . . . . 434
Figure 14-6. Replacing an Upstream Carrier on a Single Channel Line Card . . . . . . . . . . . . . 434
Figure 14-7. Selecting Configure Carriers on a Multichannel Line Card . . . . . . . . . . . . . . . . 434
Figure 14-8. Replacing Upstream Carriers on a Multichannel Line Card . . . . . . . . . . . . . . . . 435
Figure 14-9. . Assigning the New Upstream Carrier to the Inroute Group . . . . . . . . . . . . . . . . 435
Figure 14-10. Changing the MODCOD of an Adaptive Carrier for an IGC . . . . . . . . . . . . . . . . . 436
Figure 14-11. Setting the Adaptive Parameters of an Inroute Group . . . . . . . . . . . . . . . . . . . 437
Figure 14-12. Adding an IGC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Figure 14-13. Configuring Adaptive MODCODs for Remaining IGCs . . . . . . . . . . . . . . . . . . . . 437
Figure 14-14. Configuring Adaptive UCP Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Figure 14-15. Checking the Remote TDMA Initial Power . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Figure 14-16. Checking and Modifying the Remote TDMA Maximum Power . . . . . . . . . . . . . . . 440
Figure 14-17. Clicking the Carrier Grooming (Debug Mode) Check Box . . . . . . . . . . . . . . . . . 442
Purpose
The iBuilder User Guide provides detailed instructions for configuring iDirect networks using
the iBuilder client application of the iDirect Network Management System (NMS). For details
on monitoring iDirect networks, see the iMonitor User Guide.
Intended Audience
The iBuilder User Guide is intended for network operators, network architects, and other
personnel who operate or monitor iDirect networks. It is not intended for end users or field
installers.
Document Conventions
This section illustrates and describes the conventions used throughout this document.
Convention Description Example
Command Used when the user is required to Type the command:
type a command at a command cd /etc/snmp/
line prompt or in a console.
Terminal Used when showing resulting crc report all
Output output from a command that was 8350.3235 : DATA CRC [ 1]
entered at a command line or on a 8350.3502 : DATA CRC [5818]
console. 8350.4382 : DATA CRC [ 20]
Screen Used when referring to text that 1. To add a remote to an inroute group, right-click
Reference appears on the screen on a the Inroute Group and select Add Remote.
Graphical User Interface (GUI). The Remote dialog box has a number of user-
Used when specifying names of selectable tabs across the top. The Information
commands, menus, folders, tabs, tab is visible when the dialog box opens.
dialogs, list boxes, and options.
Hyperlink Used to show all hyperlinked text For instructions on adding a line card to the
within a document or external network tree, see Adding a Line Card on
links such as web page URLs. page 108.
Getting Help
The iDirect Technical Assistance Center (iDirect TAC) and the iDirect Government Technical
Assistance Center (iDirectGov TAC) are available to provide assistance 24 hours a day, 365
days a year. Software user guides, installation procedures, FAQs, and other documents that
support iDirect and iDirectGov products are available on the respective TAC Web site:
• Access the iDirect TAC Web site at http://tac.idirect.net
• Access the iDirectGov TAC Web site at http://tac.idirectgov.com
The iDirect TAC may be contacted by telephone or email:
• Telephone: (703) 648-8151
• E-mail: tac@idirect.net
The iDirectGov TAC may be contacted by telephone or email:
• Telephone: (703) 648.8111
• Email: tac@idirectgov.com
iDirect and iDirectGov strives to produce documents that are technically accurate, easy to
use, and helpful to our customers. Please assist us in improving this document by providing
feedback. Send comments to:
• iDirect: techpubs@idirect.net
• iDirect Government: techpubs@idirectgov.com
For sales or product purchasing information contact iDirect Corporate Sales at the following
telephone number or email address:
• Telephone: (703) 648-8000
• Email: sales@idirect.net
Related Documents
The following iDirect documents are available at http://tac.idirect.net and may also contain
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 iMonitor User Guide
• iDX Technical Reference 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
• Terminal WUI User Guide
iBuilder is a component of the iDirect iVantage Network Management System (NMS). The
iVantage NMS is a complete suite of tools for configuring, monitoring, and controlling iDirect
satellite networks.
The iVantage NMS consists of the following components:
• iBuilder enables rapid, intuitive configuration of any iDirect network. It allows you to
easily add components to your network, change your current configuration, and download
configuration and software to network elements. The iBuilder Revision Server provides
automated management of software and firmware upgrades for your remote modems.
The iBuilder Group QoS (GQoS) user interface allows advanced network operators a high
degree of flexibility in creating subnetworks and groups of remotes with various levels of
service tailored to their network requirements. The iBuilder User Guide provides detailed
instructions for using iBuilder to configure and manage your network.
• iMonitor provides network operators with detailed information on real-time and
historical performance of the network. Among its many capabilities, iMonitor allows you
to analyze bandwidth usage; view remote status; view network statistics; monitor
performance of networks, sub-networks and individual network elements; and manage
alarms, warnings and network events. Alarms, warnings and statistics can be forwarded as
SNMP traps. All events and performance statistics are automatically archived. Data
displayed on the iMonitor GUI can be exported directly into Excel for further analysis. A
Network Probe allows detailed investigation of network issues. The iMonitor User Guide
provides instructions for using iMonitor.
• iSite allows you to monitor and configure iDirect devices in the field. It includes several
features that aid in the remote commissioning process, including assistance for antenna
pointing, antenna look angle calculation, and cross polarization. An iSite API is available
for custom development. Remotes that support the iSite client do not support Web iSite.
• Web iSite is the Web-based version of iSite available for the latest generation of iDirect
remote modems, including the Evolution X1, X7 and e150. Web iSite can be used with any
supported Web browser; therefore, no client software is required. Remotes that support
Web iSite do not support the iSite GUI client discussed above.
• A Virtual Network Operator (VNO) license enables network operators to view and
manage only their own networks and remotes, independent of other operators delivering
services out of the same hub. The VNO package makes it possible to scale investments to
actual business growth, significantly reducing initial capital equipment expenses.
Configuring VNOs is described in the iBuilder User Guide.
This chapter presents a high-level overview of iDirect Networks. It provides a sample iDirect
network and describes the network architectures supported by iDirect.
System Overview
An iDirect network is a satellite 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.
iDirect supports both traditional OSI Layer 3 TCP/IP networks and Layer 2 over Satellite (L2oS)
networks that transport Ethernet frames over the satellite link. iDX Release 3.3.1 introduced
the L2oS feature and iDX Release 3.3.3.1 introduced the Layer 2/Layer 3 Hybrid mode feature
to allow Layer 2 and Layer 3 functionality in the same network. For more information, refer
to the “Layer 2 over Satellite” chapter of the Technical Reference Guide.
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.
Before 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 shows an example of 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.
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 numerous features, including:
• Packet-based and network-based QoS, including Layer 2 and Layer 3 packet classification
• TCP acceleration (IPv4)
• AES link encryption
• Multicast support
• End-to-end VLAN tagging
Layer 3 TCP/IP networks also support a long list of IP features, including DNS, DHCP, RIPv2,
IGMP, GRE tunneling, and cRTP. Layer 2 Ethernet-based networks provide Layer 3 protocol
transparency and simplified operation for applications such as Virtual Private Networks. 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
The examples in this section apply to traditional iDirect TCP/IP networks which transport IPV4
traffic over the satellite link. Layer 2 networks, which transport Ethernet frames over
satellite, are discussed in the Technical Reference Guide. Since Layer 3 protocols are
transparent to a Layer 2 network, a Layer 2 network can support Layer 3 protocols (such as
IPv6 and BGP) that are not supported in an iDirect TCP/IP network.
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 page 6, Figure 1-3 on page 7, and Figure 1-4 on page 8 illustrate the IP level
configurations available to a network operator for Layer 3 networks.
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.
2.1 Introduction
iDirect’s Network Management System (the iVantage NMS) is a powerful suite of applications
and servers that provide complete control and visibility to all components of iDirect networks.
The NMS client/server system architecture consists of three series of components:
• Three NMS applications with Graphical User Interfaces (GUIs) for configuring and
monitoring iDirect networks
• A database that stores the data entered by and displayed to users
• A middleware tier that manages access to the database on behalf of user operations
This chapter provides information required to understand how iBuilder works and how to use
it as effectively as possible. This chapter discusses how to prepare for installation; how to use
the tools available in iBuilder; how to create, customize, and print reports; and how to
determine the configuration status of network elements. For a description of all iVantage NMS
components see The iVantage Network Management System on page 1.
iBuilder
The iBuilder application provides all configuration and control functions to network
operators. Configuration options consist of creating network elements (e.g. networks, line
cards, remotes) and specifying their operational parameters, such as QoS profiles or IP
addresses. Control options consist of applying the specified configurations to the actual
network elements, retrieving active configurations, resetting elements, and upgrading
element software and firmware.
iMonitor
The iMonitor application provides complete visibility to the real-time status and operational
data of network elements. “Status” refers to the real-time state of network elements, such as
OK, warning, or alarm. Operational data are captured in a variety of network statistical data
tables and displays, revealing, for example, IP traffic statistics, satellite link quality, and
hardware component operating values.
In addition to real-time visibility, iMonitor can retrieve historical statistics from the archive
database to analyze anomaly conditions and perform trend analyses. Refer to the iMonitor
User Guide for a complete list of real-time and historical data available through iMonitor.
iSite
The iSite application is used primarily for commissioning new sites and monitoring TDMA
remotes from the local LAN side. It contains functions to help installers calculate antenna
azimuth/elevation, perform antenna pointing, and put up a continuous wave (CW) carrier for
antenna peaking, cross-polarization and 1dB compression tests. It also provides configuration
and real-time state/statistical information for one or more remote units. Instead of
interacting with the NMS middleware, it connects directly to each remote to perform all of its
operations. iSite does not provide access to historical information. See the Installation and
Commissioning Guide for iDirect Satellite Routers for more on commissioning remotes using
iSite.
NOTE: End-users do not need iSite in order to receive or transmit data over
iDirect networks.
Configuration Server
The configuration server is the core component of the NMS server family. It manages access to
the configuration database, which contains all the network element definitions and their
operational parameters. Additionally, the configuration server provides most network control
functions (configuration apply, firmware download, resetting, etc.). The other servers also
use this server to determine what the network components are.
Event Server
The event server’s primary job is to generate warnings and alarms and send them to iMonitor
for display. Warnings and alarms are collectively known as “conditions”. The event server also
collects and archives all system events and provides them to iMonitor for display.
Latency Server
The latency server measures round-trip time, or latency, for every active remote in the
networks. These measurements are stored in the archive and provided to iMonitor for display.
PP Controller Servers
The PP Controller processes control the samnc process on each PP blade.
SBC Server
The SBC server (sbcsvr) process interrogates the Cisco IOS software on X7-ER remotes to make
Ethernet interface link statistics available at iMonitor.
Consolidation Script
The consolidation process periodically consolidates records in the statistics archive to
preserve disk space on the server machine. Default consolidation parameters are already
entered into the configuration database; they can be tuned to particular storage
requirements if necessary.
NOTE: The iDirect clients may not operate correctly below screen resolution 1280
X 1024.
Figure 2-1. Windows 7 Start Menu Entries for NMS GUI Clients
The iDirect clients may not operate correctly in the 32-bit version of Windows 7. If an iDirect
client experiences problems, configure it to run in Windows XP Service Pack 3 compatibility
mode as follows:
1. Right click the .exe file and select Properties.
2. Click the Compatibility tab.
3. Select Run this program in compatibility mode for: Windows XP (Service Pack 3).
4. Click OK.
NOTE: Because the use of default passwords opens iDirect network to attacks and
exposes a risk to customers, the NMS checks for the use of default password
credentials after their initial use.
NOTE: Access to the iDirect system is only allowed from a local host. Users who
require telnet access to iDirect devices (e.g., NMS servers, PP servers, or line
cards) must go through a local host.
1. To launch iBuilder, double-click the desktop shortcut or select it from the Windows Start
menu.
2. Enter the user name and password in the Login Information dialog box.
If a default password is entered, a dialog pop-up box opens to warn the user to change
the default password. See Figure 2-3.
At this point, the user has the option to click the Change Now button or the OK button.
a. Click Change Now to open the Change Password dialog box to change the password.
See Figure 2-4.
NOTE: The Detected Default Password dialog box opens each time the default
password is used unless the default password security check is turned off. See
Ea
Turning Off/On Security Enhancement on page 17.
NOTE: A user can also change the default password at a later time. Refer to
Changing Passwords on page 423.
3. Click the Server drop-down menu and select the IP address of the primary NMS Server
machine. If the IP address is not in the list, enter it in the Server box.
4. Click OK to log on to the NMS server.
NOTE: To log on, the iBuilder and NMS server versions must match. (For example,
version 3.0.0 of iBuilder can connect only to version 3.0.0 of the NMS server.)
The iBuilder application automatically connects to the NMS server processes that are required
to perform NMS functions. If this connection is lost, iBuilder automatically reconnects to the
servers when they become available.
2. Enter the User Name, Password and Server IP Address of the second server.
NOTE: Entering a default password opens the Detected Default Password dialog
box to start the password security activity described in Launching iBuilder on
page 14.
3. Click OK.
Figure 2-6 shows para_cfg.opt with all security checking turned off. Table 2-1 lists the values
available for allow_default_passwords and their corresponding effects on password
security checking.
When Automatically accept configuration changes is disabled (i.e., when the check box in
Figure 2-7 is cleared), then when another user changes the configuration or when you make a
change that affects other network elements, the Accept Changes button on the toolbar
changes color from gray to red. See Figure 2-8.
You cannot modify the configuration until you accept the changes. Accepting the changes
automatically refreshes the iBuilder view to reflect the latest configuration.
An attempt to modify the network configuration without accepting changes results in the
following warning message:
To view the changes before accepting them, select View Configuration Changes (see
Configuration Changes Pane on page 38).
To accept the changes and update the iBuilder display, click Accept Changes.
CAUTION: Do not modify or clone the Bench Test Spacecraft, Bench Test Inroute,
or Bench Test Outroute for a real network configuration. These should only be
used for testing purposes. Instead, create a new spacecraft and new carriers.
For instructions on how to add entries to folders, see Adding Entries to Folders on page 30.
Right-Clicking
Right-click an element or folder in the iBuilder tree to display a menu of operations that can
be performed on that element.
2. Click and hold the double-ridge lines at the top of the pane and drag the pane to a new
position. Depending on its new position, the pane may change shape. The shape of the
new position will be outlined in iBuilder.
3. Release the mouse pointer to re-dock or detach the pane.
4. To detach a pane completely, double-click the double-ridge lines.
5. To move a detached pane, either click and drag, or right-click in the border at the top of
the pane and select Move.
6. To resize the pane, place the mouse pointer at the edges of the pane.
Figure 2-17. . Expand Tree Selection Figure 2-18. Expanded Tree with Child
Elements
3. Click the Sort items in drop-down list and select either Ascending or Descending.
4. Click the Sort items by drop-down list and select one of the options. The choices in the
Apply sort to field change depending on the selection in the Sort items by field.
5. When sorting by Name, select or clear the Names are case sensitive check box.
6. In the Apply Sort to field, select the element to sort on. Figure 2-23 shows the available
sort selections.
Figure 2-23. Sort Preferences Dialog Box: Selecting the Sort Field
NOTE: iBuilder remembers the selected sort preference after logging out and
logging on again.
A minus sign (-) next to an element or folder indicates that the element or folder has been
completely expanded and has no other child entries below this level, or branch, in the tree,
other than the children that are currently visible.
In Figure 2-24, the NMS Network has been expanded as far as possible. The Network cannot
include children in another network; therefore, its only children are the line cards and the
Inroute Group. The Inroute Group is a parent element that can be expanded by clicking its
plus sign (+) to reveal its children elements (remotes) at the next level of the tree.
In Figure 2-25, the QoS folder has been expanded as far as possible. The QoS folder cannot
include children in another folder on the same branch of the tree; therefore, its only children
are the Filter, Application, Remote and Group Profiles folders. These folders are parents to
the Downstream and Upstream folders that can be expanded by clicking their plus signs (+) to
reveal their subfolders or elements below them in the tree.
An exclamation point (!) next to an element indicates the element has a default password.
See Figure 2-26.
Canceling an Entry
Click Cancel in any of the dialog boxes to discard the current changes without saving.
However, canceling the configuration when the element is first added may result in an
unwanted new element in the iBuilder tree with a default name. To delete the element, right-
click the element in the tree and select Delete.
Title Bar
The Title bar identifies the name of the application (in this case, iBuilder) and the IP address
of the server to which iBuilder is connected.
Menu Bar
The Menu bar at the top of the display provides access to log in, log out, quit, and other high-
level functions.
Toolbar
The Toolbar, shown in Figure 2-30, contains context-sensitive buttons used for a variety of
operations on a currently-selected element without using its context menu. Their functions
are described in Table 2-1.
Opens the Modify Configuration dialog box of a selected parent element in the tree,
allowing creation of a new child element for that parent. If the selected element has no
child elements, this icon is displayed in gray and does not function.
Adds an element to the tree under the element currently selected. If no element can be
added under the selected element, the button is displayed in gray and does not function.
Displays the properties of the selected element in the tree in read-only mode
Opens the modify dialog box to view and edit the selected element in the tree.
Deletes the selected element in the tree. This function is not available if the selected
element has one or more child elements.
Accepts any changes made to the system by another user. This feature is off by default.
For more information see Accepting Changes on page 19.
Searching iBuilder
The Find toolbar provides the option to search the NMS for matching elements and display the
results in either the Network Tree View or the Results Window. This becomes increasingly
important as the network grows larger.
To search using the Find toolbar:
1. Select ViewFind Toolbar from the main menu.
2. Enter a string in the first box or click the drop-down arrow to select from earlier search
strings.
3. Select an element type in the second drop-down list.
4. Select a search type in the third drop-down list.
5. Select the screen area to search in the last drop-down list.
6. Click the Binoculars icon to begin the search.
The search in Figure 2-31 finds remotes in the iBuilder Tree with X1 in the name.
Alternatively, search by clicking the Find (Binocular) button on the main toolbar. This opens a
dialog box that provides the same search options as the Find toolbar.
To search using the Find button:
1. Click the Find button on the main toolbar to open the Find dialog box (Figure 2-32).
View Menu
The View menu on the main menu toolbar displays or hides the toolbars and panes shown in
Figure 2-33. The same menu is available by right-clicking in the main iBuilder pane. If an
element is selected in the tree, the Properties option is also available.
Status Bar
The Status bar is located at the bottom of the iBuilder window and displays the user name of
the person who is currently logged in and what their server connection status is. On the
toolbar shown in Figure 2-34, the connection status is Ready.
Legend Pane
The Legend pane displays the Configuration Status icons and their meanings. They are
organized by type of element as shown in Figure 2-36:
NOTE: By default, the auto-accept changes feature is enabled in iBuilder and you
will not be notified if another user changes the configuration. See Accepting
Changes on page 19 for instructions on how to disable the auto-accept changes
feature.
To view the changes in iBuilder before accepting them, select Configuration Changes from
the View menu to display the Configuration Changes pane. Click the arrow to the left of each
item to see more detail. Figure 2-38 shows the changes that appear when another user
creates a new remote.
To accept the changes, click the Accept Configuration Changes icon. This clears all entries
from the Configuration Changes Pane.
Configuration States
Configuration States are identified by both icons and color-coded words on either side of their
corresponding element in the network as shown in Figure 2-39. (Configuration Status is not
the same as Configuration State. Configuration Status is discussed in detail in Configuration
Status of Elements on page 46.) The legend details the meanings of the various icons and
color-coded words. (See Legend Pane on page 36.
Properties View
The Properties view shows the properties of a selected element in the tree, in read-only
mode. To view properties via the View menu, click an element in the tree and select View
Properties, or simply double-click the element.
Details
The NMS is shipped with predefined sets of details that may be viewed for any element in the
tree. Different elements have different predefined details. Use the Details view to sort, view
and print a number of details of all or some of the elements under the parent node selected in
the tree.
To view the details of an element’s children that reside at the next level down in the tree:
1. Select ViewDetails.
2. Select an element in the tree to see the details of the child nodes one level down.
For example, click a Network in the tree (Figure 2-41) to view the details about the elements
under that network (such as line cards and Inroute Groups) that reside one level below the
network in the tree (Figure 2-42). Notice that the remote in the tree is not displayed in the
Details view since it is not on the same level as the line cards and inroute group. Also, the
details of the Network itself are not displayed.
Figure 2-41. Network Selected in Tree Figure 2-42. Result in Details View
To print a report of all the elements in the Details view, select FilePrint from the main
menu. To print a subset of the elements in the Details view, use CTRL-click or the Shift key to
select the elements to print. Once the elements are selected in the Details view, select
FilePrint. (To customize the details, see Customizing Details Views for Configuration
Reporting on page 41.)
Figure 2-43. Network Selected in Tree Figure 2-44. Result in Details View
3. Click the Select filter for Details list drop-down list in the Choose Details dialog box.
4. Select one of the filters. Each filter offers a different set of details. For example, the
Carrier filter offers a list of all the predefined details that can be viewed for a carrier.
When a filter is selected, the detail choices appear in the Choose Details dialog box.
Figure 2-46 shows the details for Carrier.
5. From the list of available choices, click the details to view for the selected element.
a. Click the Show All button to select all of the details with one click.
b. Click the Move Up and Move Down buttons to reorder the details from left to right on
the Details pane.
c. Click the Hide All button to clear all selected check boxes.
6. When finished customizing the view, click OK to save the list of details for this filter. The
saved list of details for the filter are retained by iBuilder.
7. In Figure 2-47, a carrier was selected in the tree. The user selected View Choose
Details and Show All for the carrier filter to display all carrier filter parameters.
4. Type a name into the field and click OK. The buttons at the bottom of the Choose Details
pane change as shown below.
to:
5. To modify the field selection for the filter, make changes to the detail selections for the
filter and click the Modify button shown in Figure 2-49.
6. When the message appears asking to save the filter, enter a name for the filter and click
OK. A new filter is created.
7. To delete a filter, click the X button at the bottom of the Choose Details dialog box.
In Figure 2-51, changes will be made to the remotes in an Inroute Group. Therefore, the
Inroute Group has been selected as the parent element. The child elements (all remotes
in the Inroute Group) are displayed in the Details pane.
NOTE: To edit multiple elements that are not under the same parent, select
ViewCollapse Detail Hierarchy from the main menu and select the Teleport in
the iBuilder Tree. All elements under the Teleport will appear in the Details view.
Click on the Type column in the Details pane to sort elements by type. Then
perform the remaining steps in this procedure.
3. Use Control (CTRL) + click or Shift + click to select the elements to change. In the
example in Figure 2-52, changes will be made to three remotes.
4. Right-click the Names of the selected elements in the Details pane and select Modify to
open the Configuration dialog box for those elements.
5. Make the group edit changes and click OK. The changes are saved in the database for
each selected element.
However, it creates a situation where the NMS database is temporarily out-of-sync with the
actual network. This occurs after the operator has made database modifications, but before
they have been applied to the network.
To help operators easily manage this situation and others like it, iDirect implements the
concept of configuration state. Configuration states show the current configuration status of
key components of the network: Hub Chassis, individual networks, line cards, and remote
modems.
Using a specific modification as an example, we can see how configuration state changes over
time:
1. Remote “r_123” is configured, commissioned, and all previous changes have been
applied. Its configuration state is “Nominal”.
2. User changes the upstream QOS settings for remote r_123.
3. The configuration state for r_123 becomes “Changes Pending”.
4. User reviews the changes, determines they are correct, and then applies them to the
remote.
5. The configuration state for r_123 returns to “Nominal”.
Configuration Network
Definition
State Element
Nominal Network The element is completely configured, is alive in the network,
Chassis and there are no unapplied changes.
Line Card
Remote
Inroute Group
Protocol
Processor
Configuration Network
Definition
State Element
Changes Network The element is completely configured and is alive in the
Pending Chassis network. There are changes in the database that have not
been applied.
Line Card
Remote
Protocol
Processor
Incomplete Network The element is only partially configured; one or more key
Chassis components of the configuration are unspecified (e.g. carriers,
IP address, serial number)
Line Card
Remote
Inroute Group
Protocol
Processor
Never Applied Network The element is completely configured but the configuration
Chassis has never been applied to the element.
Line Card
Remote
Protocol
Processor
Deactivated Remote The element was at one time active in the network, but it has
Line Card been deactivated.
Network
An explanation of all configuration states for all elements, their meaning, and their
respective icons is available in iBuilder by selecting View Legend from the main menu.
As long as the icon is in color, the element cannot be deleted. If the icon next to an element
in the iBuilder Tree is displayed in gray, modifications will not affect other elements in the
network.
The NMS database assigns a number to each element when it is created. The first teleport is
assigned the number 1. The second teleport is assigned the number 2, and so on. A similar
numbering scheme is used for every type of element. The first spacecraft is named New
Spacecraft #1, the first remote is named New Remote #1, and so on. This element number is
always associated with its original element in the database even if the name is changed. This
allows the NMS to keep track of each element, its relationships to other elements, and its
configuration parameters, for as long as the element exists.
When an element is deleted, the numbers of the elements created after it do not change. For
example, if there are five teleports, and teleport number 3 is deleted, teleport number 4
does not become teleport number 3. Teleport number 4 remains teleport number 4 forever. If
a sixth teleport is created, it becomes teleport number 6, not teleport number 3.
2. In the Activity Log dialog box, enter a Start Time and an End Time. The Duration will be
calculated by iBuilder. (Alternatively, use the slider to adjust Duration. The slider
represents the offset between the Start Time and the End Time. Adjusting the Duration
with the slider automatically updates the End Time.)
NOTE: It is also possible to set the times by clicking the ellipsis buttons to the
right of Start Time and End Time to launch the clock display. Click the hour or
minute hand to select it. Then click the clock numbers to move the hand.
3. In the Activity Name area of the dialog box, select all activities to view. (Use the Select
All and Clear All buttons to select or clear all activities.)
4. Click the Show Log button to display the activities in the List of Activities pane. (Also
click this button to refresh the display with recent activities if the End Time is set to a
future time.)
5. When viewing Activities, if the Activity Type is applied configuration, then the Details
column will contain a hyperlink to the options file that was applied. Click the hyperlink to
view the options file in Notepad.
6. To copy and paste multiple rows from the Activity Log List of Activities into another
Windows application such as Excel:
a. Select the data to copy. (Click to select a single row. Shift-click to select a range of
rows. Ctrl-click to select multiple, individual rows.)
b. Right-click in the window and select Copy or Copy without headers from the menu to
copy the data.
limit is changed such that some active warnings now fall in the normal range, those warnings
are automatically cleared.
NOTE: When upgrading from a pre-7.0 release, the installation drops current
warning definitions from the database and recreates them. Custom limits must be
redefined after the upgrade.
iBuilder allows modification of both global warning properties and warning properties of
individual network elements. The customized warning settings for an individual element
override the settings of the global warning. Changes to global warning settings apply only to
those elements that do not have their settings customized on an individual basis.
The behavior of the system with regard to global properties and individual overrides is as
follows:
• A warning whose properties have not been modified for an individual element uses the
global properties for that warning. In the event that the global properties of the warning
are modified, the new global properties will be used by the element.
• A warning whose properties have been modified for an individual element uses the
customized properties for that warning for that element. Changes to the global properties
of the warning have no effect on the warning properties configured for that element; the
element will continue to use the modified properties.
• When a warning that has been modified for an individual element is reset for that
element, any properties that were previously modified for the warning take on the
current, global values.
The Modify Global Warning dialog box opens with all warnings appropriate to the
selected network element type.
2. Select the Warning Type for the warning to be modified and click the Edit button.
3. Enter the new settings in the Modify Warning dialog box and click OK to save the
changes.
NOTE: Changes to global warning settings do not affect warnings that have been
customized on the Warning Properties tab. Reset the customized warning to
return to the global settings. (See Clearing Customized Warning Properties on
page 58.)
2. When the dialog box for the network element opens, click the Warning Properties tab.
4. Click the Reset button at the bottom of the screen. The following dialog box opens:
5. Click OK in the dialog box. Then click OK on the Warning Properties tab. The warning
will be reconfigured with the global settings.
telnet 0 15262
d. At the Username prompt, log on to the chassis manager admin account. (The default
password is iDirect. Change this password.)
c. Enter the command:
download on
These steps are illustrated in Figure 2-65.
2. Click the Import license files button on the iBuilder License Toolbar (Figure 2-64) to open
the Select License Type dialog box.
7. When importing a chassis license file, disable download on the chassis manager as
follows:
a. From the terminal window opened in Step 1, enter the following commands:
download off
update
b. Exit the telnet session.
8. If auto-accept changes is off, click the Accept Changes icon on the iBuilder main toolbar.
(See Accepting Changes on page 19 for details on turning off and on the feature for
automatically accepting changes.)
Figure 2-69 shows an example of a License Properties tab for an Evolution X5 remote.
Notice that the remote has been licensed for Inbound Spread Spectrum and Link Encryption.
(A Value of 1 indicates that the license has been enabled.) If no licenses have been imported,
the License Properties tab is blank.
NOTE: For details on requesting licenses from iDirect, see the iDirect Features
and Chassis Licensing Guide.
iBuilder provides an automated method to generate a Comma Separated Values (CSV) file of
Serial Numbers, DIDs and Model Types for the elements to be licensed. This can be useful
when requesting licenses for a large number of existing hardware elements.
To export data for feature licenses from iBuilder:
1. Select a parent element in the iBuilder Tree that contains all of the hardware units to
license.
2. Click the Export Data for Licensing button on the iBuilder Licensing Toolbar.
3. Click the Export Data for Licensing button in the License Toolbar to open the Data for
Licensing dialog box (Figure 2-71). In Figure 2-70, Network 8 was selected in the iBuilder
Tree before clicking the Export Data for Licensing button.
4. In the Data for Licensing dialog box, select all units that require a license.
5. Click the Save to File button to display the Save As dialog box.
6. Navigate to the folder where you want to save the CSV file and click the Save button.
Figure 2-73 shows an example of a license request CSV file opened in Microsoft Excel
containing information required for an iDirect license request.
NOTE: SSH can not be used to log on directly to the root account of an NMS server
or Protocol Processor blade. Instead, use SSH to log on to another account such as
the iDirect account. Then enter su - from the command line to log on as root.
9. Update the Chassis Manager with the new configuration by entering the command:
update
10. Return to the NMS server machine by entering the command:
exit
11. Log off of the NMS server machine.
License download to the Chassis Manager is now permanently enabled, even if the Chassis
Manager server process restarts.
The new antenna appears in the iBuilder Tree with a system-generated name, and the
Antenna dialog box opens to the Information tab.
2. If desired, select a Manufacturer from the drop-down list. Items in this list were either
pre-defined or they were added to the folder earlier. See Adding Entries to Folders on
page 30.
3. In Manufacturer Part Number, enter a part number or name for the antenna.
4. Enter an iDirect Part Number for the antenna (optional).
5. Click OK. The new antenna appears in the iBuilder Tree under the antenna folder.
6. For additional antennas, repeat this procedure, assigning each new antenna a different
name.
NOTE: Be sure to enter the correct frequency translation values for all
upconverters and downconverters. The NMS uses these values to generate
network configurations.
1. Under the Hub RFT Components folder in the iBuilder Tree, right-click the Upconverter
or Downconverter folder, and select Add Upconverter or Add Downconverter.
The new upconverter or downconverter appears in the iBuilder Tree with a system-
generated name, and the appropriate dialog box opens to the Information tab. Figure 3-2
shows an upconverter being added. The procedure is the same for adding a
downconverter.
2. In Manufacturer Part Number, enter a part number or name for the upconverter
(optional).
3. Enter a frequency in MHz in the Frequency Translation field. This information is provided
on the specifications sheet for the upconverter.
4. Select a Manufacturer for the Upconverter (optional).
5. Enter an iDirect Part Number for the Upconverter (optional).
6. Select ODU Tx DC Power and ODU Tx 10 MHz to tell the iDirect modem to supply DC
power and the 10 MHz clock. These settings are applicable when operating a small
teleport whose BUC and LNB are not built into the antenna.
NOTE: Older iDirect chassis and line cards do not provide these capabilities;
remote modems have these capabilities built into them. Four-slot chassis with
newer line cards support these functions but require additional configuration on
the four-slot chassis screen. See Configuring a Four-Slot Chassis on page 318 for
details.
7. Leave Spectral Inversion at Normal unless using C-band. If the local oscillator is higher in
frequency than the one being transmitted or received, then the spectrum must be
inverted.
8. Click OK. The new upconverter appears in the iBuilder Tree under the Upconverter
folder.
9. To add additional upconverters, repeat this procedure, assigning each upconverter a
different name.
10. Repeat these steps for all of the downconverters at the teleport.
The new HPA appears in the iBuilder Tree with a system-generated name, and the HPA
dialog box opens to the Information tab.
A new spacecraft appears in the iBuilder Tree with a system-generated name, and the
Spacecraft dialog box opens to the Information tab.
2. Select the name of the Operator (usually the service provider) or select a configured
Operator from the drop-down menu.
3. In Spacecraft Name, enter a name for the spacecraft.
The new transponder appears in the iBuilder Tree with a system-generated name, and the
Transponder dialog box (Figure 3-6) opens to the Information tab.
2. In Operator Reference Name, enter a name for the transponder to identify it in the
iBuilder Tree.
3. Translation Frequency can be obtained from the satellite provider. The frequency, in
MHz, is transponder specific. It is that frequency used to down convert the radio
frequency (RF) uplink to the RF downlink for retransmission from the satellite. The
Translation Frequency must be correct for iDirect networks to function correctly.
4. Enter the information for the remaining fields, which can also be obtained from the
service provider. This information is for reference purposes only.
5. Click OK. The new transponder is added to the iBuilder Tree under the Spacecraft.
The new bandwidth entry appears in the iBuilder Tree with a system-generated name, and
the Bandwidth dialog box opens to the Information tab.
2. On the Information tab, in the Operator Reference Name box, enter a name to identify
the bandwidth in the iBuilder Tree.
3. Enter the Center Frequency, Bandwidth, and Power values, which can be obtained from
the service provider. This information is for reference purposes only.
4. Click OK. The bandwidth entry is added to the iBuilder Tree under the Transponder.
The new carrier appears in the iBuilder Tree with a system-generated name, and the
Downstream Carrier dialog box opens to the Information tab.
a. Select both a Minimum M ODCOD and a Maximum MODCOD. This defines the range of
MODCODs used on the downstream carrier.
NOTE: iDX Release 3.5 does not support CCM. To simulate CCM, select the same
Minimum MODCOD and Maximum MODCOD. If simulating CCM, adjust the DVB-S2
network parameters as described in Adjusting DVB-S2 Parameters for CCM
Networks on page 157.
b. Click the MODCOD Distribution button to estimate the Information Rate for the DVB-
S2 carrier based on the MODCODs that the remotes in this network are able to
receive. See Estimating the Information Rate for a DVB-S2 Carrier on page 87 for
details.
9. For Error Correction, LDCP BCH is automatically selected for all DVB-S2 carriers. For
information on the available FEC rates and modulation modes, see the iDirect Link Budget
Analysis Guide for this release.
10. In the Assigned to Line Card field, select a transmit line card for this carrier. If no line
card is available for selection, configure a new card or re-configure an existing card for
use by this carrier.
11. Enter the Symbol Rate for the DVB-S2 carrier. (You cannot enter a Transmission Rate or
Information Rate for DVB-S2 carriers.) The symbol rate for DVB-S2 carriers must be
between 1000 and 45000 ksym.
12. In Timeplan Parameters:
a. FEC Blocks per Frame is not applicable to DVB-S2 carriers.
b. Frame Length is automatically set to 125 ms.
13. Spreading Parameters cannot be selected. Spread Spectrum is not supported on DVB-S2
downstream carriers.
14. Click OK. The outbound carrier appears in the iBuilder Tree.
The new carrier appears in the iBuilder Tree with a system-generated name, and the
Upstream Carrier- TDMA dialog box opens to the Information tab.
8. If Adaptive is selected in Modulation, the Payload Size field appears in place of the Error
Correction field (Figure 3-10). Select a Payload Size for the Adaptive carrier.
NOTE: The Payload Size must be identical for all carriers in the same inroute
group. For non-Adaptive carriers, the payload size is included in the Error
Correction field.
9. The Assigned to Line Card field is populated automatically when this carrier is assigned
to a hub line card in the Line Card dialog box.
10. Enter either a Transmission Rate, Information Rate, or Symbol Rate. Entering any of the
rate values will cause the remaining two rates to be automatically calculated.
NOTE: Only Symbol Rate is applicable to Adaptive carriers. The Transmission Rate
and Information Rate vary dynamically with the current MODCOD of the Adaptive
carrier. (See the chapter titled “Adaptive TDMA” in the iDirect Technical
Reference Guide for more information.)
NOTE: Evolution X1 and e150 remotes are not allowed to transmit on TDMA
upstream carriers larger than 4 Msps.
NOTE: See the chapter titled “Remote Acquisition” in the iDirect Technical
Reference Guide for details on Acquisition Slots and Superburst.
12. If using the iDirect Spread Spectrum feature with BPSK modulation, select a Spreading
Factor in the Spreading Parameters area of the dialog box. The following upstream
Spreading Factors can be selected:
• No Spreading
• COTM SF=2: Spreading factor of 2
• COTM SF=4: Spreading factor of 4
• COTM SF=8: Spreading factor of 8
• COTM SF=16: Spreading factor of 16
NOTE: The iDirect Spread Spectrum feature is only supported for BPSK
modulation. For more information, see the chapter titled “Spread Spectrum” in
the iDirect Technical Reference Guide.
NOTE: Spread Spectrum is not supported for upstream carriers received by XLC-M
or eM0DM line cards.
NOTE: Only Evolution e8350, e800, and e850mp remotes can transmit on
upstream carriers with Spreading Factor 16.
NOTE: The Acquisition Aperture is still present; however, it is not used for TDMA
acquisition slots on the selected carrier.
To disable the use of acquisition slots on specific carriers (e.g., high symrate or low symrate
carriers), create a network-level custom key in iBuilder as follows:
1. Right-click the network in the iBuilder Tree and select ModifyItem.
2. Click the Custom tab.
3. Enter the following Custom Key:
[INROUTE_x] //x = Inroute id
acq_disable=1
4. Click OK to save the changes.
5. Right-click the network in the iBuilder Tree and select Apply ConfigurationNetwork to
download the changes.
CAUTION: Before removing a carrier from an inroute group, first remove its
corresponding custom key and then remove the carrier.
Removing the carrier without first removing its corresponding custom key can
cause a network outage.
The new carrier appears in the iBuilder Tree with a system-generated name, and the
Upstream Carrier - SCPC dialog box opens to the Information tab.
NOTE: Additional Guard Band is required for SCPC return channels being
transmitted by some mobile remotes. See Guard Band for SCPC Return Channels
on page 534.
NOTE: For information on the available FEC rates and modulation modes, see the
iDirect Link Budget Analysis Guide for this release.
8. Enter either the Transmission Rate, Information Rate, or Symbol Rate. Entering any of
these values will cause the remaining rates and the Occupied Bandwidth to be
automatically calculated.
NOTE: Not all configurable Symbol Rates and Modulations are supported for some
mobile applications. See Minimum Symbol Rates for Mobile Remotes on page 531.
9. In Frame Parameters, the Frame Length and the number of FEC Blocks per Frame are
automatically calculated based on the selected Error Correction.
10. To use the iDirect Spread Spectrum feature, select a Spreading Factor in the Spreading
Parameters area of the dialog box. The following SCPC upstream Spreading Factors can
be selected:
• No Spreading
• COTM SF=2: Spreading factor of 2
• COTM SF=4: Spreading factor of 4
• COTM SF=8: Spreading factor of 8
NOTE: The iDirect Spread Spectrum feature is only supported for BPSK
modulation. A Spreading Factor can only be selected if BPSK is selected in the
Modulation field. For more information, see the chapter titled “Spread Spectrum”
in the iDirect Technical Reference Guide.
NOTE: Spread Spectrum is not supported for upstream carriers received by XLC-M
or eM0DM line cards.
11. In the Uplink Control Parameters area of the dialog box (Figure 3-13 on page 84), specify
the Operating Margin and the three Power Adjust parameters. The Uplink Control
Parameters are defined as follows:
NOTE: Click and drag the Power Adjust sliders to vary the C/N ranges and
automatically update the Power Adjust settings.
NOTE: If the SCPC return channel will be transmitted by a mobile remote, it may
be necessary to adjust the upstream acquisition range by configuring a custom
key on the receive line card once the carrier is assigned to a line card. See SCPC
Upstream Acquisition Range on page 532 for details.
NOTE: After creating an SCPC return carrier and associating the carrier with a
line card, the Modulation and FEC Blocks per Frame areas are grayed out; this
occurs even when there is no remote associated with the line card.
To work-around this issue, perform the following:
1. Create another carrier with the required configuration on the same frequency.
2. Move the remote to an inroute group.
3. De-select the carrier on the HLC menu.
4. Select the newly created carrier.
5. Return the remote to the carrier.
Figure 3-14 shows an instance of the MODCOD Distribution Calculator. The range of the
MODCOD column is limited to the DVB-S2 Range defined for the carrier assigned to this
network. The Total row shows the totals for the columns.
2. Double-click the cells to enter estimates of either the percentages of traffic or the
Information Rates that will be transmitted on the different MODCODs for remotes
receiving this carrier.
Changing the percentages in the Distribution column causes the Information Rate for
each MODCOD to be automatically recalculated and the total displayed in the Total row.
Changing bit rates in the Information Rate column causes percentages in the Distribution
column to be automatically recalculated and the new total percentage is displayed in the
Total row.
Figure 3-15 shows the results of changing the percentages in the Distribution column.
In the example in Figure 3-15, the network operator estimates that 20% of the remotes
typically receive 16APSK-4/5, 20% receive 16APSK-5/6, and the remaining 60% receive
16APSK-8/9 (the best MODCOD defined for the carrier). Based on this input, the calculator
determines the estimated Information Rate for the carrier to be 6532 kbps.
3. Click OK to save the changes.
A variation of the MODCOD Distribution Calculator can be used to calculate the effective MIR
and CIR for Group QoS nodes. See Estimating Effective MIR and CIR for DVB-S2 Networks on
page 252 for details.
The Teleport is the highest component in the iBuilder Tree hierarchy and represents the
facility where the antenna and, typically, the rest of the Hub equipment is housed. After
adding a Teleport, add a Protocol Processor (PP), Blades, Hub RFT, and Chassis to the iBuilder
Tree. This chapter discusses how to configure all of these elements except the chassis. Chassis
configuration is discussed in Configuring a Hub Chassis on page 313.”
This chapter contains the following sections:
• Adding a Teleport on page 89
• Adding a Backup Teleport on page 90
• Adding a Hub RFT on page 93
• Protocol Processors on page 94
• Adding a Protocol Processor Blade on page 101
• Setting Warning Properties for Protocol Processor Blades on page 100
• Adding an SVN on page 102
• Configuring L2oS Hub Parameters on page 105
2. On the Information tab, enter a name and a phone number for the Teleport facility.
3. Click the Geo Location tab.
The Geo Location identifies precisely where the uplink facility (i.e., the Hub RFT) is
geographically located on the Earth. The teleport transmits the uplink signal to the
satellite and receives the downlink signal from the satellite.
NOTE: The Geo Location information must be accurately configured for a remote
to function correctly in an iDirect network.
4. Enter the exact Latitude and Longitude of the teleport. This information can be obtained
from the service provider or can be determined with a GPS device. Be sure to select the
correct hemisphere for each. Latitude represents North and South; longitude represents
East and West.
5. Click OK to save the settings. The Teleport appears in the iBuilder Tree.
The procedure for configuring a backup teleport assumes that the primary teleport is already
operational and that the backup teleport has been installed. Generally, the iBuilder
configuration of the backup components should be identical to the configuration of the
primary teleport. During operation, any configuration changes made at the primary teleport
should also be made at the backup teleport. This can be accomplished using the NMS database
backup and restore utility described in the iDirect Technical Note NMS Redundancy and
Failover for this release.
NOTE: When using the same outbound carrier for both the primary and backup
teleports, the teleport operator must disable the backup transmitter while the
primary teleport is operational. In the event of failure of the primary site, the
teleport operator must enable the backup transmitter for the backup teleport to
become operational.
Using iBuilder at the primary teleport, follow these steps to configure the backup teleport
hub equipment and to add existing remotes to the backup teleport’s networks. The procedure
assumes that the primary teleport and the networks it controls are already configured in
iBuilder and operational.
1. Add the backup teleport by following the steps in the section Adding a Teleport on
page 89. Then configure all the components of the backup teleport, including:
• The Hub RFT (See Adding a Hub RFT on page 93)
• The Protocol Processor (See Protocol Processors on page 94)
• Protocol Processor Blades (See Adding a Protocol Processor Blade on page 101)
• Networks (See Adding a Network on page 118)
• Line Cards (See Adding a Transmit or Transmit and Receive Line Card on page 121)
• Inroute Groups (See Inroute Groups on page 146)
2. Right-click the backup teleport in the iBuilder Tree and select ModifyItem.
3. In the Backup NMS area of the Teleport dialog box, select Enabled (Figure 4-3).
4. Enter the IP address (or addresses) of the NMS server(s) at the backup teleport.
5. Click OK to save the changes.)
NOTE: A distributed NMS requires up to three IP addresses for the NMS servers.
Unless there is a distributed NMS at the backup site, all three IP addresses should
be identical.
b. In the Roaming dialog box, select the remote’s Network under the backup teleport.
c. Click OK to save the changes.
7. At this point, all remotes will have changes pending. Apply the changes for each network
as follows:
a. Right-click the network in the iBuilder Tree and select Apply Configuration
Multiple.
b. In the Automated Configuration Downloader dialog box, select all remotes and line
cards.
The new Hub RFT appears in the iBuilder Tree with a system-generated name, and the
Hub RFT dialog box opens to the Information tab.
2. Enter a name for the Hub RFT, and then select the subcomponents for the Hub RFT from
each of the drop-down list boxes.
3. Select the Satellite to which this Hub RFT is assigned.
4. Click OK. The Hub RFT is added to the iBuilder Tree.
technical description of iDirect’s TRANSEC feature, see the iDirect Technical Reference
Guide.
NOTE: A license is required for all Protocol Processor blades and line cards that
use the TRANSEC feature. All blades must be licensed for TRANSEC in order to add
a TRANSEC protocol processor in iBuilder. For complete details on requesting and
installing iDirect licenses, see the iDirect Features and Chassis Licensing Guide.
To configure a TRANSEC network in iBuilder, first create one or more TRANSEC protocol
processors. All network elements that are subsequently created under a TRANSEC protocol
processor are part of the TRANSEC-compliant network.
TRANSEC networks require TRANSEC-capable remote and line card model types. For a list of
compatible model types, see TRANSEC Hardware Requirements on page 446.
All hosts in an iDirect TRANSEC network must have X.509 certificates issued by the iDirect
Certificate Authority (CA) Foundry. Hosts include NMS Servers, Protocol Processor blades,
TRANSEC line cards, TRANSEC remotes, and GKD Servers. Issue X.509 certificates before
creating the TRANSEC network. For details on the certification process, see Using the iDirect
CA Foundry on page 467.
The new Protocol Processor appears in the iBuilder Tree with a system-generated name,
and the Protocol Processor dialog box opens to the Information tab.
3. The User Password and Admin Password text boxes are empty. Specify alternate, secure
passwords.
NOTE: If a default password is entered, the Detected Default Password dialog box
opens to warn the user to change the default password. The dialog box opens
each time the default password is used unless the default password security check
is turned off. For more information, see Turning Off/On Security Enhancement
on page 17.
4. In Download Monitor Credentials, enter any value greater than one and less than four
billion. (This number is used for multicast firmware image download and can be
duplicated across multiple Protocol Processors. It is critical for communications between
the NMS and network elements.)
5. In Upstream Gateway, enter the IP address of the upstream router. This is the address of
the router interface connected to the upstream LAN segment.
6. Click Enabled RIPv2 to configure the Protocol Processor to advertise remote routes to the
upstream router using the RIPv2 protocol. This setting affects the default VLAN only.
7. Select the Upstream and Tunnel Interfaces. The tunnel is the LAN segment between the
Protocol Processor and the line cards.
8. Select TRANSEC Enabled to add a protocol processor for a new TRANSEC network.
(Selecting Add TRANSEC Protocol Processor from the iBuilder Tree automatically enables
this field.)
NOTE: Before selecting this option for an existing network, ensure that all
preliminary steps have been taken. Follow the procedure in Converting a Network
to TRANSEC on page 445 to convert an existing network to TRANSEC.
NOTE: TRANSEC Enabled only appears in the dialog box if a TRANSEC license is
installed on the Protocol Processor. Before deploying this feature, contact the
iDirect Technical Assistance Center (TAC).
9. Select L2oS Enabled to configure Layer 2 networks or Layer 2/Layer 3 Hybrid mode
networks containing Evolution X1 and/or Evolution X7 remotes under this Protocol
Processor.
10. A persistent multicast group is a multicast group that includes all remotes communicating
with this protocol processor. The protocol processor always forwards upstream multicast
traffic for a persistent multicast group.
To add a persistent multicast group, click Add in the Multicast Groups section of the
Information tab to open the Persistent Multicast Group dialog box.
11. Enter the Vlan Id and the IP Address of the multicast group.
NOTE: For more information, see the Technical Note titled “IP Multicast in
iDirect Networks.”
12. Under SI Table, enter a Multicast IP Address for system messages that are broadcast by
the Protocol Processor to the remotes. Select a multicast IP address that meets the
following conditions:
• The selected IP address must not conflict with any multicast IP addresses being used
by the networks.
• The tunnel switch must not filter out the selected multicast IP address.
• If there are multiple Protocol Processors that are not isolated on the LAN, then a
different Multicast IP Address must be configured for each Protocol Processor.
NOTE: When the local NMS manages the second downstream, configuring the
local Protocol Processor is not required. Configuring the Protocol Processor is
required when the second downstream is managed by another NMS or Protocol
Processor.
Additionally, see the following sections for additional information about configuring
an X7 remote to receive encrypted Multicast Fast Path traffic on a second
demodulator:
• Adding a Network on page 118
• Remote VSAT-2 Tab on page 207
• Setting Up Global Key Distribution for Encrypted Multicast Fast Path on an X7
Second Demodulator on page 500
NOTE: Link Encryption licenses are required on all Protocol Processor blades that
process encrypted Multicast Fast Path traffic.
• A Multicast Application Profile and associated rules for the multicast streams properly
configured in the Downstream Application folder. See Adding an Application Profile on
page 304.
• A Multicast Service Profile added to the Network Group QoS tab. See Configuring
Remotes for Multicast Fast Path on page 277.
NOTE: Record the number of the Multicast Fast Path Stream displayed on the
Multicast QoS Application dialog box. The stream number is required to enable
the multicast stream on the Evolution X7 remotes.
• A Persistent Multicast Group configured for each VLAN (including the default VLAN)
configured by the Multicast Fast Path Application Profile to carry the Multicast Fast Path
packets. See Adding a Network on page 118.
NOTE: Without a Persistent Multicast Group, the Protocol Processor will not
forward the Multicast traffic to the transmit line card for transmission on the
downstream carrier.
NOTE: When you override global blade warnings on the Protocol Processor
Warning Properties tab, the new settings are applied to all blades of that protocol
processor. You cannot override the settings for the individual blades of a protocol
processor.
For details on configuring warning properties for line cards, remotes and protocol processors,
please see Configuring Warning Properties on page 54.
c. Click the Add button to open the Protocol Processor Blade Dialog Box (Figure 4-11 on
page 102).
2. Alternatively, right-click the Protocol Processor in the iBuilder Tree and select Add Blade.
In either case, the Protocol Process Blade dialog box opens (Figure 4-11).
CAUTION: iBuilder incorrectly allows you to add more PPs than the number of
usable hosts per subnet in the VLAN; any invalid IP address will be broadcast. Be
sure to verify that only valid PPs are assigned to the VLAN.
To add a SVN:
1. Right-click the Protocol Processor in the iBuilder Tree and select Modify Item.
7. In the Address Start field, specify the Upstream Interface IP Address to be used by the
first blade. iBuilder automatically enters the remaining IP addresses. (To override the
automatic addressing by following the procedure in the next section.)
8. Click OK. A new Upstream SVN Interface is now defined.
If a new blade is subsequently added, all SVN end addresses will be automatically updated to
give the new blade the appropriate upstream interfaces, and the SVNs will be added to the
new blade.
NOTE: If a line like this is already present for eth0, but contains a different value
(e.g. 1500), then edit the line to the above value. The MTU value can also be
checked by typing ifconfig at the prompt to display the MTU size.
CAUTION: Do not change the default MTU (1500) on the tunnel interface (eth1).
The L2oS parameters for the hub are configured on the SVNs tab of the Protocol Processor
(Figure 4-15) when the L2oS Enabled check box is enabled on the Protocol Processor
Information tab as described in Protocol Processors on page 94.
Refer back to Figure 4-12 to see the SVNs tab before the L2oS Enabled check box is enabled.
It shows Layer 3 SVNs configured for a Layer 3 network only.
Figure 4-15. Protocol Processor SVN Tab with L2oS Enabled Checked
Figure 4-15 shows the SVNs tab after the L2oS Enabled check box is enabled. Note that it
shows both Layer 2 and Layer 3 SVNs. These SVNs were configured for a Layer 2/Layer 3
Hybrid network.
Note also that the SVNs tab has changed to allow SDT selection and L2SW Default selection.
(An SDT is a tag on each Ethernet frame that associates that packet with an SVN.) A user can
now add Layer 2 SVNs as well as Layer 3 SVNs.
Finally, note the grayed-out Reserved outer SVN ID for L3 check box and text box. This is
used with L2oS to provide an SVN ID that is reserved for Layer 3 traffic. For more information,
see Configuring SVNs on page 108.
NOTE: SVNs, whether Layer 2 or Layer 3, must be predefined in the SVNs tab
pane as shown in Figure 4-15 before they can be assigned to a remote.
Figure 4-16 shows the SVNs tab after the L2oS Enabled check box is enabled and Layer 2 SVNs
including CE Tag Transparent SVNs (indicated by _X) have been assigned.
Figure 4-16. Protocol Processor SVN Tab Showing CE Tag Transparent SVNs
To configure the L2oS hub parameters for networks under this Protocol Processor requires
performing the following:
• Configuring SDT
• Configuring L2SW Default
• Configuring SVNs
NOTE: In a L2OS network with a hub configured in SDT mode QinQ, it is necessary
to change the PP eth0 interface MTU from 1504 to 1508 to support frames with
QinQ tags. For more information, see Changing MTU at Protocol Processor in L2oS
Network in the Technical Reference Guide.
For information on learned MAC expiration at the remote, see Remote MAC Address Aging
Timeout on page 213.
NOTE: In the QinQ SDT mode, when the Reserved outer SVN ID check box is
unchecked, only Layer 2 SVN types can be selected.
7. If desired, configure Optional Overrides to modify the Default Mode parameters for the
SVN as follows:
a. If desired, override the default service mode by selecting a different Mode for this
SVN: VPLS, VPWSEPC or VPWS.
b. If desired in VPWSEPC mode, enter a MAC Address in the MAC Address Rewrite field.
This is the MAC Address to which the Protocol Processor forwards all Ethernet frames
received over-the-air for this SVN.
NOTE: When the Reserved outer SVN ID check box is checked, both Layer 2 and
Layer 3 SVN types can be configured.
NOTE: After SVNs are defined, the SDT Mode cannot be changed. However, the
L2SW Defaults can be changed. Any overrides under the L2SW Overrides column in
the SVN pane will change automatically.
NOTE: A user can also edit or remove an SVN from the predefined list before it
has been assigned to a remote with the Edit and Remove buttons in the SVNs tab.
NOTE: In the QinQ SDT mode, when the Reserved outer SVN ID check box is
unchecked, only Layer 2 SVN types can be selected.
NOTE: Do not assign the SP ID an existing Layer 2 SVN or Layer 3 outer SVN ID.
NOTE: A line card must be assigned to a hub chassis before it can become
operational. Until a line card is assigned to a hub chassis, the line card will be in
the incomplete state in the iBuilder Tree. See Configuring a Hub Chassis on
page 313 for details on assigning a line card to a chassis.
NOTE: Only Evolution XLC-M, eM0DM, and eM1D1 line cards can receive SCPC
inbound carriers.
NOTE: If you enable Inhibit Tx (When beam quality = 0) and the beam maps have
been designed to avoid unnecessary beam switching, it is possible that a remote
may mute its transmitter when you do not expect it. For questions, please contact
the TAC before enabling this feature.
5. To enable encryption for Multicast Fast Path streams, select Multicast Encryption.
NOTE: Link Encryption licenses are required for protocol processors and some
remote model types to use this feature. See the chapter on “Multicast Fast Path”
in the Technical Reference Guide for details.
6. To enable Multicast Overlay for Multicast Fast Path streams, select Multicast Overlay.
b. In the Persistent Multicast Group dialog box, enter the VLAN Id and the multicast
Address for the persistent multicast group.
NOTE: For more information, see the Technical Note titled “IP Multicast in
iDirect Networks.”
Note:
The various Line Card Types as they appear in iBuilder are defined as follows:
• Transmit Line Card: Transmit-only line card. The line card can transmit an outbound
carrier, but cannot receive an inbound carrier.
• Receive Line Card: Receive-only line card. The line card can receive an inbound carrier,
but cannot transmit an outbound carrier.
• Transmit and Receive Line Card: The line card can transmit an outbound carrier and
receive an inbound carrier.
• Standby Line Card: The line card acts as a standby (spare) line card for one or more
active line cards in a chassis.
• Solo Transmit and Receive Line Card: A Transmit and Receive Line Card that is the only
active hub line card in a network. You cannot add additional Receive Line Cards to the
network if you select this option. A Solo line card can co-exist with other Solo line cards
or with one other Tx or Tx/Rx line card in a single Chassis Timing Group.
The new line card is added to the iBuilder Tree with a system-generated name, and the
Line Card dialog box opens to the Information tab.
NOTE: Serial numbers are not sufficient to uniquely identify remotes and line
cards. Serial numbers are unique within a particular model type, but can repeat
from one model type to another. Therefore a unique Derived ID (DID) is
automatically generated to avoid problems that would be caused by duplicate
serial numbers.
CAUTION: You must correctly specify both the serial number and the model type
for the line card to function properly. For example, an eM1D1 card configured as
an XLC-11 card will not operate in the network.
5. Select the Line Card Type from the drop-down menu. See Line Card Types on page 120
for options.
6. Select the Hub RFT that is associated with this network. This allows you to select the
appropriate carriers in Step 11.
7. If this is a Transmit and Receive Line Card, the Receive Mode field will appear on the
screen. Select the appropriate Receive Mode.
NOTE: A line card in Single Channel TDMA Receive Mode is not capable of
processing more than 600 traffic slots per TDMA frame. Therefore, a TDMA carrier
with more than 600 traffic slots per frame should never be assigned to any line
card configured for Single Channel TDMA Receive Mode. See page 125 for more
details.
8. Under LAN / MGMT IP Address, enter the IP Address, Subnet Mask, and Gateway used by
the NMS to communicate with the line card.
9. Under GIG0 IP Address:
a. Enter the IP address for downstream data from the protocol processor to the network.
b. Use the drop-down menu to set the Speed of your GIG0 port to 100 Mbps or 1000
Mbps.
NOTE: Your switch and chassis must support the selected port speed. (Older
iDirect chassis do not support 1000 Mbps.) Also, you must explicitly configure the
port speed on your switch to be the same as the port speed selected for the line
card. Do not set the switch to auto-negotiate.
10. The User Password and Admin Password text boxes are empty. Specify alternate, secure
passwords.
NOTE: If a default password is entered, the Detected Default Password dialog box
opens to warn the user to change the default password. The dialog box opens
each time the default password is used unless the default password security check
is turned off. For more information, see Turning Off/On Security Enhancement
on page 17.
11. Select the Transmit Carrier associated with this line card. If this is a transmit/receive
line card, also select the Receive Carrier.
NOTE: You cannot modify a line card’s Model Type, Receive Mode, Serial Number,
or Line Card Type once a Receive Carrier is assigned to the line card. You must
unassign the carrier to change these fields. To unassign a receive carrier from a
line card, first remove the carrier from its inroute group or line card (in SCPC
return mode) and then select None in the Carrier Name field.
12. If configuring an Alternate Downstream Carrier for this network, select that carrier in the
Alternate Transmit Properties area of the dialog box.
Configuring an alternate downstream carrier facilitates moving a network to a new
downstream carrier while minimizing the chance of stranding remotes in the process. See
Changing to an Alternate Downstream Carrier on page 132 for the procedure to move a
network from the current transmit carrier to the alternate downstream carrier.
13. Click OK to save the line card configuration. The line card is added to the iBuilder Tree
under the Network.
NOTE: For details on deleting a line card, see Deleting a Line Card on page 130.
• All TDMA upstream carriers received by a multichannel line card must be on the same
transponder.
• All TDMA upstream carriers received by a multichannel line card must be configured for
the same type of acquisition bursts. Superbursts and traditional acquisition bursts cannot
be received simultaneously by the same line card. See Adding TDMA Upstream Carriers on
page 79 for details on selecting the carrier acquisition type.
• A multichannel line card cannot receive more than eight carriers with Superburst
acquisition enabled. Since Superburst and traditional acquisition bursts cannot be
received simultaneously by the same line card, an Evolution XLC-M line card receiving
more than eight narrowband carriers must use traditional acquisition.
• For a single channel line card to receive an Adaptive TDMA upstream carrier, the receive
mode must be set to Single Channel TDMA (Adaptive).
• A line card in Single Channel TDMA Receive Mode is not capable of processing more than
600 traffic slots per TDMA frame. Therefore, a TDMA carrier with more than 600 traffic
slots per frame should never be assigned to any line card configured for Single Channel
TDMA Receive Mode. This restriction only applies to Single Channel TDMA Receive Mode. It
does not apply to Single Channel TDMA (Adaptive) Receive Mode. Traffic slots per frame
are displayed in iBuilder on the Inroute Group Composition Dialog Box as shown in
Figure 5-33 on page 152.
• Only Evolution XLC-M, eM0DM, and eM1D1 line cards can receive SCPC upstream carriers.
• An Evolution eM1D1 line card receiving an SCPC upstream carrier must be configured as a
receive-only line card. It cannot be used as a Tx/Rx line card.
• Licenses are required to use Evolution XLC-M and eM0DM line cards in TDMA and SCPC
Multiple Channel modes for more than one channel. (See the iDirect Features and Chassis
Licensing Guide for details.)
• If an XLC-M line card has a narrowband multichannel license, individual upstream TDMA
carriers assigned to the line card cannot exceed 468 ksym/s.
NOTE: You cannot modify a line card’s Model Type, Receive Mode, Serial Number,
or Line Card Type if a Receive Carrier is assigned to the Line Card.
The new line card is added to the iBuilder Tree with a system-generated name, and the
Line Card dialog box opens to the Information tab.
NOTE: If a default password is entered, the Detected Default Password dialog box
opens to warn the user to change the default password. The dialog box opens
each time the default password is used unless the default password security check
is turned off. For more information, see Turning Off/On Security Enhancement
on page 17.
9. In Receive Properties, if you selected Single Channel TDMA mode or Single Channel
SCPC mode, select the Carrier associated with this line card.
NOTE: To enable Single Channel SCPC mode for an XLC-M line card, choose
Multiple Channel SCPC mode for Receive Properties, and select the Carrier
associated with the line card.
NOTE: You cannot modify a line card’s Model Type, Receive Mode, Serial Number,
or Line Card Type once a Receive Carrier is assigned to the Line Card. You must
unassign the carrier to change these fields. To unassign a receive carrier from a
line card, first remove the carrier from its inroute group or SCPC line card and
then select None in the Carrier Name field.
NOTE: iBuilder does not allow an operator to assign a TDMA carrier with more
than 600 traffic slots per frame to a line card configured for Single Channel TDMA
Receive Mode and displays a warning if this is attempted (Figure 5-6). This
restriction only applies to Single Channel TDMA Receive Mode; it does not apply to
Single Channel TDMA (Adaptive) Receive Mode. The restriction usually limits the
symbol rate and MODCOD of the carrier that can be assigned to the line card.
The symbol rate, in a small percentage of cases, may still violate the maximum
rates identified in the link budget for various receive operating modes. For
information on this, see the symbol rate/MODCOD against minimum/maximum
operating limits identified in the "Upstream TDMA Modes and Throughput
Limitations" section of the iDX Release 3.5 Link Budget Analysis Guide.
10. To add your carriers in Multiple Channel TDMA mode or Multiple Channel SCPC mode,
follow the procedure in the next section, “Adding Multiple Receive Carriers to a Line
Card.”
11. Once you have added your carrier or carriers, click OK to save the line card configuration.
The receive line card is added to the iBuilder Tree under the Network.
Figure 5-6. Single Channel TDMA Receive Mode Traffic Slot Warning
Figure 5-8 shows the Select Carrier dialog box for a multichannel line card in Multiple
Channel SCPC mode. Notice that the line card is licensed for eight carriers and seven have
been selected.
2. Enter a Line Card Center Frequency. This is the downlink RF center frequency of a 36
MHz operational band. (The operational band must fall between 950 MHz and 2000 MHz
for an XLC-M or eM0DM line card.) All upstream carriers received by this line card must be
completely within the 36 MHz operational band, which is graphically represented at the
bottom of the dialog box. You will not be able to select carriers outside the band.
3. From the list of carriers, select the check box of each carrier that you want to assign to
the line card. As you select your carriers, the Composite Information Rate, Occupied
Bandwidth and Carriers Selected fields all update automatically. (Grey font in the table
indicates an unselectable carriers. A carrier may not be selectable for a number of
reasons. For example, you cannot select a carrier that is outside the 36 MHz band or a
carrier that is already assigned.)
NOTE: Since all TDMA carriers assigned to a multichannel line card are in the
same inroute group, you can only select TDMA carriers with the same payload
block size. See Adding an Inroute Group on page 147 for more information.
4. Each selected carrier is displayed on the graph as a vertical green or yellow bar. The
yellow bar represents the carrier currently selected (ID 11 in Figure 5-8.) If you attempt
to select a carrier that is outside the 36 MHz band, it will be displayed as a red bar.
5. Select Show carriers associated with other line cards to see TDMA and SCPC upstream
carriers in this line card’s frequency band that are assigned to other line cards. Carriers
assigned to other line cards appear as vertical orange bars in the graph (Figure 5-9).
NOTE: Selecting Show carriers associated with other line cards also shows
carriers assigned to other line cards on different networks.
NOTE: Hover the cursor over any carrier in the graph to see details of that
carrier’s configuration.
6. To modify a carrier, double-click the carrier in the table, or select the row for the carrier
and click the Edit Carrier button.
7. If the line card is in Multiple Channel SCPC Mode, the User Group column appears on the
right side of the Select Carrier dialog box (Figure 5-8). In the User Group column, you
can associate a selected SCPC carrier with a return channel owned by the System user
group or by a VNO user group. Follow these steps:
Figure 5-10. Associating an SCPC Return Channel with a VNO User Group
The carrier is now assigned to one of the SCPC channels owned by the selected VNO
user group. The carrier automatically becomes visible to the VNO user group.
NOTE: Only VNO user groups that own channels on this SCPC line card appear in
the drop-down menu. For details on assigning SCPC return channels to VNO user
groups, see Configuring VNO Access Rights for SCPC Return Channels on page 404.
NOTE: When deleting an Rx-only line card, skip directly to Step 5 on page 131.
1. Right-click the inroute group of the line card to be deleted and select ModifyItem to
display the Inroute Group dialog box.
2. When deleting a Tx or Tx/Rx Line Card, remove all Rx line cards from the inroute group.
When deleting an Rx-only line card, remove only this line card from the inroute group.
To remove a line card from an inroute group:
a. Select the line card in the Line Cards area of the dialog box.
b. Click Remove (Figure 5-11).
c. Click OK to save the changes to the line card. The line card will automatically be
placed in the “deactivation pending” state.
5. If this is an Rx-only line card, right-click the line card and select Activate Line Card to
remove the check mark (Figure 5-13). This puts the Rx line card in the “deactivation
pending” state.
6. Right-click the line card and select Apply ConfigurationReliable (TCP) to deactivate
the line card.
NOTE: It may not be possible to apply the changes if the line card has failed. In
that case, ensure that the failed line card is powered off or disconnected. Also,
power off the line card’s chassis slot in iBuilder. (See Configuring and Controlling
the Hub Chassis on page 316.)
CAUTION: A failed transmit line card may continue to transmit if not deactivated
or powered off.
7. If you were not able to deactivate the line card, you will not be able to delete it from
iBuilder unless you first set it to standby. To set the line card to standby:
a. Right-click the line card and select ModifyConfiguration to display the Line Card
dialog box.
b. In the Line Card Type field of the dialog box, select Standby.
CAUTION: Remotes that have not been downloaded with the alternate
downstream carrier definition will be stranded. Site visits may be required to
recover those remotes.
When a remote rejoins a network configured with an alternate downstream carrier, it first
tries to acquire the last carrier it was receiving. When you follow the procedure in this
section, the old primary carrier is brought down and the new primary carrier begins
transmitting, forcing all remotes to lose lock and then try to rejoin the network. The remotes
first try to acquire the old active carrier before timing out and acquiring the new active
carrier. By default this timeout is set to five minutes (300 seconds). To shorten this timeout,
define the following remote-side custom key on the Remote Custom tab for each remote
before executing the procedure.
[BEAMS_LOCAL]
net_state_timeout = <timeout>
where <timeout> is the number of seconds that the remote tries to acquire the primary
carrier before switching to the alternate carrier.
The example in this section shows how to swap the current active carrier (DVB-S2 Down
1250) with the alternate carrier (DVB-S2 Down 1230). Figure 5-15 shows this initial
configuration. (To move to the alternate carrier without selecting a new alternate carrier,
select None in Step 2 of the procedure.)
Follow these steps to move your network to the alternate downstream carrier:
1. Right-click your transmit line card in the iBuilder Tree and select ModifyConfiguration.
2. In the Carrier Name field of the Alternate Transmit Properties section of the Line Card
dialog box, select the carrier that is currently defined as the active downstream carrier.
3. In Carrier Name field of the Transmit Properties section of the Line Card dialog box,
select the carrier that was configured as the alternate downstream carrier as the new
primary downstream carrier.
4. Click OK to save your changes. The iBuilder Tree will show changes pending on your
transmit line card, receive line cards, and remotes (hub-side and remote-side).
5. Apply the changes to your transmit and receive line cards. Also apply the hub-side
changes to your remotes.
NOTE: To avoid applying the remote-side changes twice, wait until the remotes
have re-acquired the network on the new carrier before applying the remote-side
changes.
At this point, the remotes will lose the original primary carrier. Since they were last
locked to that carrier, they will attempt to re-acquire on the same carrier. After the
remotes timeout, they will search for their alternate carrier which is the new active
carrier. At that point, the remotes will rejoin the network.
6. Once the remotes have rejoined the network on the new active carrier, apply the remote-
side changes.
NOTE: Any remotes that were not in the network at the time of the carrier
change will acquire the new carrier when they re-acquire the network since that
carrier is still defined as their alternate carrier.
• An Rx-only line card configured to receive one or more inbound TDMA carrier or one or
more inbound SCPC carriers transmitted by the remote modems in a network. (An Rx-only
line card does not transmit an outbound carrier. Rx-only line cards are referred to as Rx
line cards in this section.)
A standby line card is a line card that does not become operational until it is enabled by the
NMS to take over for an active line card. Line card switching can be automatic or manual,
depending on the configuration of the standby line card.
In the iDirect system, there are two types of relationships between standby and active line
cards:
• A warm standby is a line card that has been pre-configured with the same software and
configuration as an active line card. Because the configuration is pre-loaded, a line card
acting as a warm standby for an active line card provides the fastest recovery time
available. However, a line card can serve as a warm standby for only one active line card.
• A cold standby is not pre-loaded with the same configuration as the active line card. Since
the configuration must be downloaded from the NMS server to the line card before the
standby can become operational, a line card acting as a cold standby for an active line
card takes significantly longer to take over for a failed active line card. However, a line
card can serve as a cold standby for multiple active line cards.
Automatic failover occurs when the NMS fails to receive the expected heartbeat message
from the active line card. The following prerequisite conditions must be met in order for the
failover operation to proceed:
1. A standby line card must be configured in iBuilder for the network to back up the failed
line card.
2. The standby line card must be in the OK state (and accessible from the NMS) as
determined by the NMS event server.
3. A standby line card backing up a Tx or Tx/Rx line card must be in the same chassis as the
failed line card.
4. A standby line card backing up an Rx-only line card must be in the same chassis as the
failed line card.
5. The chassis must be accessible to the NMS through the TCP interface.
6. A standby line card must be a warm standby for at least one active line card. (There is no
requirement to establish any cold relationships.)
NOTE: When configuring a line card to backup a transmit line card, connect the
Tx IFL cable only after the standby line card configuration has been downloaded.
Once you have configured the line card, ensure that the cable is connected.
Default redundancy relationships are not established automatically when you configure
standby line cards for your networks. Therefore, once you have configured a standby line
card, you must explicitly configure the warm and cold redundancy relationships for that line
card on the chassis. (See Managing Line Card Redundancy Relationships on page 138 for
details.)
When you configure a standby line card in a network, you can limit the types of redundancy
relationships that an operator can configure for the line card using the Allow Failover For
field of the Standby Line Card dialog box. The following selections are available:
• None: The standby line card does not back up any active line cards. The line card cannot
be swapped (automatically or manually) for a failed line card until another selection is
made. The line card’s configuration will be labeled “incomplete” in the iBuilder Tree.
• All: The standby line card can be configured to act as a warm standby for one line card
and as a cold standby for any remaining line cards. (Typically the standby line card is
configured as a warm standby for the Tx line card and as a cold standby for Rx line cards.
This favors the most critical line card. In a multi-inroute, frequency-hopping network, the
failure of a receive-only line card results in diminished upstream bandwidth only; remotes
will automatically load-balance across the remaining receive line card(s) without
dropping out of the network. However, if the transmit line card fails, the entire network
will be out of service.)
• Tx Only: The standby line card can be configured to act only as a standby for the Tx (or
Tx/Rx) line card.
• Rx Only: The standby line card can be configured to act as a warm standby for one Rx (or
Tx/Rx) line card and as a cold standby for all remaining Rx line cards.
In general, a standby line card can only back up line cards of the same model type. Table 5-1
shows the line card model types that can act as standby for each active line card model type.
2. Enter a Name, Model Type, Serial Number, and LAN IP Address for the new line card.
3. Configure the GIG0 IP Address as required.
4. Make sure that Standby is selected for Line Card Type.
5. The User Password and Admin Password text boxes are empty. Specify alternate, secure
passwords.
NOTE: If a default password is entered, the Detected Default Password dialog box
opens to warn the user to change the default password. The dialog box opens
each time the default password is used unless the default password security check
is turned off. For more information, see Turning Off/On Security Enhancement
on page 17.
6. Select the desired option in the Allow Failover For drop-down list. Four selections are
available in the menu:
• Select None to disable failover. You cannot configure redundancy relationships for
this standby line card if None is selected. Changing a standby line card’s selection to
None deletes any existing redundancy relationships.
• Select All to allow the standby line card to be configured to backup all transmit and
receive line cards.
• Select Tx Only to allow the standby line card to be configured to backup only your
transmit (or Tx/Rx) line card.
• Select Rx Only to allow the standby line card to be configured to backup only your
receive line cards. (This includes Tx/Rx line cards.)
7. Click OK to save the standby line card configuration.
8. Once you have defined your standby line card, follow the procedures in the next section
Section 5.8.3, Managing Line Card Redundancy Relationships to set up the line card’s
redundancy relationships.
The default view (By Standby) of the Manage line card redundancy dialog box is shown in
Figure 5-20.
Figure 5-20. Manage Line Card Redundancy Dialog Box: By Standby View
This dialog box has two views. The default view (By Standby, shown in Figure 5-20) lists each
standby line card on the left. On the right of each standby, the dialog box lists each active
line card backed up by the standby line card, and the standby line card’s relationship (warm
or cold) to the active line card.
The second view (By Active, shown in Figure 5-21) lists the active line cards on the left and
each of their standby line cards on the right.
Figure 5-21. Manage Line Card Redundancy Dialog Box: By Active View
To switch between views, right-click anywhere in the dialog box and select a View from the
menu.
The dialog box is divided into virtual backplanes, organized by the assignments of the line
cards to the chassis. The dialog box also shows the physical slot numbers and the redundancy
relationships of all line cards in the chassis.
NOTE: A standby line card must be assigned as a warm standby for an active line
card before it can become a cold standby for any additional line cards.
2. If there are any valid line cards available, a dialog box opens with a list of all valid
selections. Right-clicking a standby line card shows a list of available active line cards.
Right-clicking an active line card shows a list of available standby line cards. Figure 5-22
shows both views.
3. Select a line card from the list and click OK. iBuilder saves the configuration immediately.
4. Apply the changes to the standby line card by right-clicking the line card in the iBuilder
Tree menu and select Apply Configuration.
2. If there are any valid line cards available, a dialog box opens with a a list of all valid
selections. Right-clicking a standby line card shows a list of available active line cards.
Right-clicking an active line card shows a list of available standby line cards. Figure 5-23
shows both views.
3. Select a line card from the list and click OK. iBuilder saves the configuration immediately.
NOTE: You do not need to apply the changes to the cold standby line card. A cold
standby is automatically downloaded when a failover occurs.
2. In the Dissociate cold standby dialog box, select all standby line cards that you no longer
want to serve as cold standbys for the active line card. Then click OK. The standby line
card will not be selected to take over for the active line card in the event that the active
line card fails.
NOTE: In order to perform a manual swap, the standby line card must have a
redundancy relationship with the active line card.
1. Right-click the active line card and select Swap Line Card from the menu.
2. In the dialog box, select the standby line card that you want to be the new active line
card.
Figure 5-25. Choosing a New Active Line Card During Line Card Swap
failed and then attempts to perform a series of actions to switch the active and standby line
cards. Note that this series of actions will only succeed if the active line card has experienced
a temporary loss of communication with the NMS long enough to trigger the failover, but short
enough to allow the NMS to re-establish communication with the failed line card during the
course of these actions. Otherwise, the standby line card will take over for the failed active
line card, and the failed line card will be disabled.
NOTE: For line cards with an active GIG0 port, the NMS expects a heartbeat
message from both line card LAN ports.
The NMS performs the following actions to attempt to switch a failed active line card and a
standby line card:
1. The NMS monitors the standby line card to ensure that the standby remains operational.
2. The NMS establishes a TCP connection to the failed line card and reconfigures it to be a
standby line card.
3. The NMS establishes a TCP connection to the original standby line card and reconfigures it
to be the new active line card.
4. The NMS re-establishes all redundancy relationships for the new standby line card,
mirroring the redundancy configuration of the old standby as it existed before the
failover.
If all of the steps above are successful, you will see the same sequence of events in iMonitor
that you see when you manually swap line cards. See Figure 5-26 on page 144.
In many cases, the NMS will be unable to configure the failed line card to be the new standby
line card. If the NMS cannot connect to the failed line card, it will power off the chassis slot
of that line card. It will then re-configure the original standby to be the new active line card
to recover the network. At that point, the system will be operational, but the failed line card
will be in an interim state requiring recovery. You should call the TAC to assist you in
diagnosing the reason for the failure and to guide you through the recovery process.
If the line card experienced a hard failure or internal component failure, you will be
instructed to remove the failed card from the chassis and return it to iDirect for repair. Some
failures, such as those listed below, may be repaired on-site.
• Switch port failure
• LAN cable failure
• FPGA image load failure or runtime flash corruption
CAUTION: Do not power on the chassis slot of a failed line card unless the I/F Tx
and Rx cables are disconnected and you have recovered from the line card failure
condition.
For details on configuring warning properties for line cards, remotes and protocol processor
blades, please see Configuring Warning Properties on page 54.
NOTE: A dedicated SCPC upstream carrier is assigned directly to the remote that
transmits that carrier. Therefore, an SCPC remote is not part of an inroute group.
(See Adding Remotes on page 160 for details on assigning an SCPC upstream
carrier to a remote.)
Figure 5-27 shows the relationship between upstream carriers, line cards, and inroute groups
in a TDMA-only network.
Network
Tx/Rx -- or -- Rx Remotes
Remotes
Hub Line Card Remotes
Remotes
Inroute Carrier
(in Spacecraft folder in tree)
The Protocol Processor selects in real time the inroute on which each remote transmits.
Remotes “hop” from one inroute to another either on frame boundaries or within the same
frame. This frequency hopping by remotes among the upstream carriers in an inroute group is
used for both Adaptive TDMA and for load balancing.
Adaptive TDMA allows the carriers in an inroute group to have different symbol rates and
MODCODs. The goal of frequency hopping in Adaptive TDMA is to select the most efficient
upstream carrier on which the remote can transmit and still remain in the network. This
optimizes the use of upstream bandwidth and prevents fading remotes from losing the
network.
Frequency hopping is also used to balance the load across the carriers in the inroute group.
The Protocol Processor analyzes upstream demand from all remotes and assigns timeplan slots
to achieve a balance of remote traffic across all the inroutes. For load balancing with
Adaptive TDMA, the Protocol Processor first attempts to allocate slots to a remote on a carrier
with the most suitable MODCOD and symbol rate for that remote under current conditions. If
no slots are available, slots may be assigned on a less-optimal carrier, provided the remote’s
bursts can be received at the hub on that carrier.
The specific rules regarding the assignment of TDMA upstream carriers to inroute groups are:
• All carriers in an inroute group must have the same payload block size.
• A carrier can only be assigned to a single inroute group.
• A line card’s carrier assignment cannot be changed if the carrier is assigned to an inroute
group. However, some of the carrier’s parameters can be modified.
A TDMA upstream carrier can be configured as either Static or Adaptive. Multiple Inroute
Group Compositions (IGCs) can be created per inroute group to optimize the carrier
definitions for different network conditions. (For details, see the chapter titled “Adaptive
TDMA” in the iDirect Technical Reference Guide.)
The specific rules regarding the use of Adaptive and Static carriers and the configuration of
IGCs are:
• Both Static and Adaptive carriers can be included in the same inroute group.
• An Adaptive carrier must be received by a multichannel line card or by an Evolution
eM1D1 line card in receive-only mode.
• Spread Spectrum carriers cannot be Adaptive.
• All inroute groups have at least one IGC.
• To configure multiple IGCs for an inroute group, at least one carrier must be Adaptive.
• A maximum of three IGCs can be configured for an inroute group.
• A different MODCOD can be selected for each Adaptive carrier in each IGC.
• The center frequency and symbol rate of an Adaptive carrier is the same for all IGCs.
• The MODCOD of a Static carrier is the same in all IGCs.
The new inroute group is added to the iBuilder Tree with a system-generated name, and
the Inroute Group dialog box opens to the Information tab.
NOTE: A high-speed COTM license is required for mobile remotes that exceed 150
mph.
4. The Timeplan Parameters define the Acquisition Aperture and Guard Interval of TDMA
bursts:
a. The Acquisition Aperture is the length in microseconds of the window in which
remotes send acquisition bursts on the upstream carriers. The default value is
automatically calculated. Click Default to return to the default value.
b. The Guard Interval is the guard time in NCR ticks needed to account for symbol
timing uncertainty when the remotes transmit TDMA bursts. NCR ticks are used
internally by the system for network timing. The Guard Interval is translated into
microseconds on the screen. (See Figure 5-28.)
5. Shared Carrier Parameters are the same for all carriers in the inroute group. These
parameters are defined as follows:
a. Payload Size is a read-only field that shows the payload block size configured for the
carriers. Only carriers with the same payload size can be added to the inroute group.
b. Frame Length is a read-only field that shows the frame length of the upstream
carriers in the inroute group.
6. Adaptive Parameters determine how IGCs are selected for this inroute group. Adaptive
Parameters only need to be configured for inroute groups with multiple IGCs. For
additional information, see the chapter titled “Adaptive TDMA” in the Technical
Reference Guide.
a. Before selecting an IGC, the algorithm predicts the percentage of remotes currently
in the network that would drop out if that IGC were selected. If the predicted
percentage of remotes that would drop out exceeds the Allowed Dropout Factor,
that IGC will not be selected unless that IGC is the default IGC.
b. The Default IGC is the IGC that is selected if the Allowed Dropout Factor is exceeded
for all IGCs defined for the inroute group.
c. The Update Interval is the frequency (in seconds) with which the IGC selection
algorithm executes to select the optimal IGC for the current network conditions. The
algorithm may run more frequently if required by network performance. The default
is 60 seconds.
d. Under Selection Algorithm, check Enable Fixed IGC and select a specific IGC to lock
this inroute group to that IGC. When a fixed IGC is selected, other IGCs are not used.
Checking Enable Fixed IGC also enables the Carrier Grooming (Debug Mode) check
box.
e. Checking the Carrier Grooming (Debug Mode) check box opens the following pop-up:
It also enables the Show Lock to Inroute check box and a Details pull-down list of
carriers at the Transmit Properties section of the Remote Information tab to use with
Carrier Grooming mode. See Carrier Grooming on page 441 for more information.
7. In the Line Cards section of the Information Tab, click Add to open the Assign Hub To
Inroute Group dialog box.
8. In the Assign Hub To Inroute Group dialog box, select the upstream carrier to be added
to this inroute group.
NOTE: All TDMA upstream carriers assigned to a multichannel line card must be in
the same inroute group.
NOTE: The Group QoS tab of the Inroute Group is discussed in Chapter 7,
Configuring Quality of Service for iDirect Networks.
NOTE: An inroute group in which all carriers are static has only one IGC since the
MODCODs of static carriers cannot change from one IGC to another. A single
default IGC is created automatically for each inroute group.
3. Click Edit IGC and select the new IGC to open the Inroute Group Composition dialog box.
Figure 5-33 shows the Inroute Group Composition dialog box. When editing an IGC, the IGC
number is shown in the screen title.
• Spreading Factor is the Spread Spectrum Spreading Factor selected for BPSK carriers. All
Spread Spectrum carriers are Static.
• C/N0 is the C/N threshold of the carrier as specified in the Link Budget Analysis Guide
adjusted for the Symbol Rate of the carrier and includes the M1 and M2 margins
configured for the inroute group. (See the next section for details.)
• Traffic Slots is the number of traffic slots per TDMA frame for this carrier.
3. Any changes to the default Adaptive Parameters should be determined during network
design. These parameters are defined as follows:
• The Fade Slope Margin (M1) allows for the incremental fade that can occur during
the reaction time of the power control algorithm as well as the uncertainty in the
C/N0 estimations.
• The Hysteresis Margin (M2) is added to the Fade Slope Margin when determining
whether or not a remote should switch to an upstream carrier with a different
MODCOD and/or symbol rate. This margin prevents unnecessarily frequent switching
between carriers.
• The Measurement Spacing is the number of seconds between UCP measurements of
remote bursts by the hub during steady-state operation. During a fade, the UCP
algorithm automatically increases the remote’s update interval.
NOTE: During a fade, the number of upstream frames allocated to an idle remote
may exceed its configured Minimum Information Rate. This allows the remote to
transmit more frequent bursts for measurement by the Uplink Control Process.
• The Acquisition Margin (M3) is used to determine the initial nominal upstream carrier
for the remote based on the C/N of the acquisition burst. For more information, see
the section titled “Acquisition” in the “Uplink Control Process” chapter of the
Technical Reference Guide.
• The Hysteresis Logoff check box is used to enable or disable the hysteresis_logoff
parameter in the network options file for a given inroute group.
• Checking the check box enables the hysteresis_logoff parameter and sets the
value of the Logoff Interval to -1.
• Unchecking the check box disables the hysteresis_logoff parameter and sets the
value of the Logoff Interval to 120.
• The Logoff Interval shows the hysteresis_logoff interval in the network options file.
NOTE: These parameters apply to all remotes in an ACM network. You cannot
modify these settings for individual remotes.
steady state operation, the Steady State Margin is added to the threshold. Additional margin,
Fast Fade Margin, is added during fast fade conditions at the remote.
In addition to the margin added to the SNR threshold during operation, the system must also
take into account the variance, or margin of error, associated with the remote’s SNR
measurement. To account for this margin of error, an additional 0.2 dB is added to the SNR
threshold. This margin of error cannot be changed.
As an example, consider an Evolution e8350 Satellite Router receiving a DVB-S2 outbound
carrier with a current MODCOD of 16PSK 3/4. This MODCOD has an SNR threshold of 10.8 dB,
determined at hardware qualification. Table 5-2 shows the operational SNR threshold below
which the hub changes the outbound frames transmitted to the remote to a lower MODCOD.
The table assumes the default settings for the Steady State Margin and Fast Fade Margin are
in effect.
Adding margin to increase the SNR threshold causes the system to behave more conservatively
by dropping to a lower MODCOD at a higher SNR threshold. For more information, see the Link
Budget Analysis Guide and the Technical Reference Guide for this release.
2. In the DVB-S2 Configuration dialog box, edit any settings you want to change.
The Steady State Margin and Fast Fade Margin must be greater than or equal to zero.
The Fast Fade Threshold and Fade Slope Threshold must be greater than zero.
NOTE: You can click Set to Default to return your network to the default settings.
NOTE: MODCOD indexes are documented in the Link Budget Analysis Guide for
this release.
Remote satellite routers provide IP or Ethernet connectivity between each remote LAN and
the hub. This chapter contains detailed procedures for configuring remotes to operate in
iDirect networks. The chapter contains the following sections:
• iDirect Remote Satellite Router Models on page 159
• Adding Remotes on page 160
• Remote Information Tab on page 161
• Remote IP Config Tab on page 169
• Remote Switch Tab on page 182
• Remote QoS Tab on page 188
• Remote Geo Location Tab on page 199
• Remote VSAT Tab on page 201
• Remote VSAT-2 Tab on page 207
• Remote L2oS Tab on page 209
• Setting Warning Properties for Remotes on page 214
• Adding a Remote by Cloning an Existing Remote on page 214
• Roaming Remotes on page 216
• Enabling IP Packet Compression Types on page 224
NOTE: An inroute group is not required for a remote that transmits an SCPC
upstream carrier to the hub. In the iBuilder Tree, an SCPC remote is added
directly to the line card that receives the remote’s upstream carrier.
Any iDirect remote that transmits to the hub on a TDMA upstream carrier must be assigned to
an inroute group. All remotes in the inroute group share the upstream carriers assigned to the
inroute group. The protocol processor assigns TDMA frame slots to individual remotes in real
time based on the each remote’s current bandwidth demand.
An SCPC remote transmits a dedicated SCPC return channel to a receive line card at the hub.
An SCPC remote is not a member of an inroute group. Instead, an SCPC remote is assigned to
its receive line card. For a line card to receive an SCPC upstream carrier, the line card must
be configured in single channel or multiple channel SCPC mode. See Adding Receive-Only (Rx-
Only) Line Cards on page 124 for details.
To add an SCPC remote, right-click the receive line card and select Add SCPC Remote
from the menu.
NOTE: The Switch tab appears only when configuring a remote with an eight-port
switch. See Remote Switch Tab on page 182.
NOTE: Serial numbers are not sufficient to uniquely identify remotes and line
cards. Serial numbers are unique within a particular model type, but can repeat
from one model type to another. Therefore a unique Derived ID (DID) is
automatically generated to avoid potential problems caused by duplicate serial
numbers.
5. For TDMA remotes, the name of the remote’s Inroute Group is automatically displayed in
the Inroute Group field. This field is not applicable to SCPC remotes.
6. Enter a new User Password and Admin Password. The User Password provides access to
basic remote console commands. The Admin password provides administrator-level
access to all remote console commands. Specify alternate, secure passwords.
NOTE: If a default password is entered, the Detected Default Password dialog box
opens to warn the user to change the default password. The dialog box opens
each time the default password is used unless the default password security check
is turned off. For more information, see Turning Off/On Security Enhancement
on page 17.
7. Select Active to make the Protocol Processor aware of this remote site once the remote
has been commissioned. A remote must be Active to join the network.
NOTE: To deactivate an active remote, clear the Active check box. A deactivated
remote is removed from the Protocol Processor’s current network configuration
while preserving the configuration in iBuilder.
8. Select MUSiC Box, Disable Tx PWM, Disable Authentication, and/or Link Encryption.
a. Select MUSiC Box if this remote site uses a Multi User Summing Chassis. The iDirect
MUSiC Box allows a common antenna/electronics platform to be shared across
multiple remotes at the same physical location. Selecting MUSiC Box overwrites VSAT
ODU settings that turn on the DC/10 MHz timing; instead, the MUSiC Box provides the
DC/10 MHz timing.
b. Select Disable Tx PWM to disable the Transmit Pulse Width Modulation on the remote
and enable console pointing mode. (With this box selected, installers are not required
to remove the transmit cable during antenna pointing.)
c. Select Disable Authentication to certify a previously-uncertified remote in a
TRANSEC network. For details, see Bringing an Unauthorized Remote into a TRANSEC
Network on page 471.
d. Select Link Encryption to encrypt the connection between the remote and the
protocol processor blade. Link Encryption can only be selected if it is supported for
this remote model type.
NOTE: Link Encryption is a licensed feature. A license file must be loaded on each
protocol processor blade that supports Link Encryption. For information on
obtaining these licenses, please contact the iDirect Technical Assistance Center
(TAC).
9. To enable Sleep Mode on the remote, select Sleep in and enter a value in seconds. If
Sleep Mode is enabled, the remote conserves power by disabling the 10 MHz reference
for the BUC after the specified number of seconds have elapsed with no remote
upstream data transmissions. A remote automatically wakes from Sleep Mode when
packets arrive for transmission on the upstream carrier, provided that Trigger Wakeup is
selected for the service level associated with the packets. (See Adding an Application
Profile on page 304 for details.)
NOTE: For Sleep Mode to work, the 10 MHz reference must be enabled for the
BUC assigned to the remote on the Remote VSAT Tab. The 10 MHz reference is
enabled by selecting ODU Tx 10 MHz in the BUC configuration dialog box.
NOTE: When enabling Sleep Mode, also edit the QoS Service Levels that apply to
the remote to ensure that “Trigger Wakeup” is only enabled for those Service
Levels that match customer traffic. If “Trigger Wakeup” is enabled for
management traffic, the constant flow of management traffic will prevent the
remote from entering Sleep Mode. See page 307 for details.
10. Check the Telnet access from local host only check box to allow telnet access from local
host only; uncheck the check box if it is necessary to have telnet access from an external
host.
• For existing remotes without this feature, the check box is unchecked by default.
• For cloned remotes (i.e., remotes cloned by right-clicking a remote and selecting
Clone or selecting Add to Networks under Roaming, or right-clicking an Inroute
Group and selecting Add Multiple Roaming Remotes), the check box setting follows
the source remote.
• For other new remotes, the check box is checked.
When modifying a remote, a popup warning dialog appears if Telnet access from local
host only is enabled but the check box is unchecked.
Figure 6-2. Detected Telnet access from local host only Dialog Box
Click on OK to apply changes without enabling telnet access from local host only; click
on Change Now to return to the Telnet access from local host only check box to check
the check box.
The popup warning dialog will continue to appear if the check box is unchecked.
Additionally, a security icon (“!”) appears beside a remote to indicate the remote is
insecure if telnet access is not limited to local host.
For information on turning the dialog box and security icon off, see Managing Telnet
Access from Local Host Only on page 18.
NOTE: Telnet access from local host only is disabled for TRANSEC mode and for X1
remotes.
11. In the Compression area of the dialog box, select any IP compression types to be used by
this remote. For details on the different types of compression available, see Enabling IP
Packet Compression Types on page 224.
Figure 6-3. Remote Information Tab: Transmit and Receive Parameters for TDMA Remote
NOTE: See the Installation and Commissioning Guide for Remote Satellite
Routers for details on determining the Reference Carrier Initial Power.
b. Click the Show Lock to Inroute check box to lock the remote to a single carrier
selected at the Details pull-down list.
This check box is only enabled when the Carrier Grooming mode is selected at the
Inroute Group Information tab. See Carrier Grooming on page 441 for more
information.
c. In TDMA Max Power, enter the maximum TDMA transmit power level in dBm as
determined during remote commissioning. The default is 0 dBm. This field is not
applicable if the remote is transmitting an SCPC upstream carrier.
e. If desired, record the 1dB Compression Point determined at remote commissioning.
This field is informational only.
Figure 6-4 shows the Transmit Properties of an SCPC remote.
Figure 6-4. Remote Information Tab: Transmit and Receive Parameters for SCPC Remote
NOTE: The initial power and maximum power must be configured for the SCPC
remote to become operational.
d. Enter the Initial Power and Max Power for the SCPC upstream carrier selected on the
Remote Information tab by double-clicking the cells and entering the values in dBm.
e. If this remote may transmit on other SCPC upstream carriers in the future, you can
also configure the initial power and maximum power for those carriers at this time.
If any customers or distributors have already been added to the NMS database, the names
appear in the list.
2. To the right of the dialog box, click Add to add another customer or distributor.
3. The Customer (or Distributor) dialog box opens.
9. For customers, you can enter a Commission Date, Contract Number, and additional
information in the Site Notes box.
10. Click OK to close the dialog box and save the changes or click the IP Config tab to
continue configuring the remote.
The iDirect VLAN capability allows customers to use their existing IP addressing schemes.
Since all routing options (RIPv2 and static routing) are configurable per VLAN interface, the
end-to-end VLAN feature allows each end customer to have their own routing architecture
independent of other customers sharing the same physical network components.
There are two check boxes for configuration of the Routing Information Protocol (RIPv2) on
the remote: one for the LAN interface (eth0) and one for the for satellite interface (sat0).
(The sat0 interface is called the management interface when referring to the default VLAN.)
You can enable or disable RIPv2 independently on the two interfaces. Depending on the RIPv2
options selected, the remote behaves as follows:
• When RIPv2 is not enabled on either interface, RIP is completely disabled on the remote.
It does not send or receive any RIP updates.
• When RIPv2 is enabled on the LAN interface, the remote sends and receives RIP updates
over the LAN, updating its own IP routing table when new routing information is received.
• When RIPv2 is enabled on the satellite (or management) interface, the remote sends and
receives RIP updates over the satellite, updating its IP own routing table when new
routing information is received.
The remote does not relay RIP messages to other routers. Instead, it generates RIP messages
based on its own IP routing table.
NOTE: Previously, iBuilder allowed the configuration of more than eight VLANs for
X1, 9-Series, and 980 remotes although the configuration would not function
because the remotes do not support it. This is no longer allowed and an error
appears when an attempt is made to exceed the eight VLAN limit.
iBuilder also previously allowed the configuration of more than eight VLANs for
X3, X5, X7, and e8xxx remotes. To avoid upgrade issues, this is still allowed.
However, because these remotes function in an unsupported and untested way
that can lead to customer problems, a warning now appears indicating that the
configuration is not supported.
NOTE: Once the GRE tunnel is enabled, the Tag Packets field disappears and the
packets are tagged.
The IP information for a remote is configurable per VLAN. Select a VLAN on the left side of
the dialog box. Then configure its IP addressing information on the Interface sub-tab.
1. The LAN Interface IP address represents the remote’s IP address on the selected VLAN.
a. Enter the IP Address and Subnet Mask.
b. Select Tag Packets to tag packets with the VLAN ID according to the IEEE 802.1Q
VLAN Tagging specification.
NOTE: VLAN tagging must be enabled in order to connect to the Ethernet side of
the default LAN from a hub PC. Ensure that Tag Packets is selected to enable this
capability for the selected VLAN.
NOTE: Changing the LAN port selection for an iConnex e800 from Port B to Port A
requires a remote reset for the change to take effect. Right-click the remote in
the iBuilder Tree and select Reset Remote to perform this operation.
2. The remote’s Management Interface (Sat) IP address represents the remote’s virtual
interface on the default VLAN. The NMS always communicates with the remotes using this
address. This address should not conflict with the LAN Interface addresses.
a. Selecting Same as LAN sets the Management Interface IP address to the LAN Interface
IP address. (The Gateway is always set to 0 and cannot be changed.)
NOTE: When you select a VLAN other than the default VLAN, the interface names
change. LAN Interface changes to ETH0 Interface. Management Interface changes
to SAT0 Interface.
Once an SVN is added to the remote, it is added to the VLAN list, and the LAN and
Management Interfaces change to ETH0 and SAT0 Interface for the VLAN.
4. Click the Remove button (Figure 6-12) to delete an SVN. A warning message is displayed,
asking to confirm the deletion. VLAN 1 is the default VLAN and cannot be removed.
The VLAN ID is also considered in QoS Profiles. See section Adding an Application Profile on
page 304.
DNS Operation
The DNS component functions as follows:
1. Clients on the remote network issue DNS queries to the DNS component.
2. The DNS searches its cache for a matching response.
3. If a matching response is found, the DNS replies with the cached response.
4. If a matching response is not found, the DNS performs the following:
a. Appends the query along with a timestamp to the forward queue.
b. Sends the query to its primary DNS server.
5. If a response is received within the time specified by the Forward Timeout parameter
the DNS performs the following:
a. Adds the response to its cache.
b. Forwards the response to the client.
c. Deletes the query from the forward queue.
6. If a response is not received within the time specified by the Forward Timeout
parameter, the DNS performs the following:
a. Forwards the query to the secondary name server.
b. Resets the timestamp associated with the forwarded query.
7. If a response is received within the time specified by the Forward Timeout parameter,
the DNS performs the items listed in Step 5 above.
8. If a response is not received within the time specified by the Forward Timeout
parameter, the DNS deletes the query from the forward queue.
DHCP, including DHCP relay, is configurable on a per VLAN basis. In iBuilder, DHCP is disabled
by default.
To use an existing or separate DHCP server at your hub location:
1. Select Relay.
2. Enter the IP Address of your DHCP Server.
To enable the remote to act as the DHCP server:
1. Select Server to enable DHCP configuration entries.
2. Enter the Lease Duration or the amount of time before the address must be renewed.
3. Enter the Primary and Secondary DNS server addresses, and the Default Gateway.
4. Click the Add button to enter Client Address Ranges, which are the ranges of assignable
addresses. Multiple unique ranges may be assigned as desired.
5. To edit a Client Address Range:
a. Click the range in the table to highlight the range you want to change.
b. Select Edit.
c. Modify the range and click OK to save your changes.
6. To delete a Client Address Range:
a. Select a range in the table and click the Remove button, a warning message is
displayed, asking you to confirm the deletion.
b. Click OK to delete the range.
To configure RIPv2:
1. Select a VLAN in the left pane of the dialog box.
2. Select Enable RIPv2 for the ETH0 (LAN) interface and/or SAT0 (Management) interface
to enable RIPv2 over the satellite link for the selected VLAN.
Static Routes
Click the Static Routes sub-tab to add, edit, or remove static routes. The default route across
the sat 0 interface is added automatically when you create a new remote. Do not delete this
route unless your remote routing scheme requires it.
NOTE:
• Static route redistribution to RIP is enabled by default for 9-series remotes.
• X7 remotes do not advertise static routes to RIP.
CAUTION: When a remote is clamped to a specific blade, it will not re-acquire the
network if that blade fails and the blade's load will not be automatically
distributed across the remaining blades. The network will remain down until the
custom key(s) clamping the remote(s) are removed. At that point, the failed
blade's load will be distributed across the remaining blades.
NOTE: To determine a blade’s ID, select ViewDetails from iBuilder’s main menu
and click the blade. The blade’s ID is displayed in the ID column of the details
view.
7. Right-click the remote in the iBuilder tree and select Apply ConfigurationReliable
Hub-Side.
8. Right-click the remote again and select Activate Remote to return it to the network. The
check mark should re-appear.
9. Right-click the remote in the iBuilder tree and select Apply ConfigurationReliable
Hub-Side.
Port forwarding allows you to specify that IP packets with certain port numbers are forwarded
to private IP addresses behind the remote. For example, to run a web server on a PC with a
private IP address, specify http as the port start and port end; TCP as the protocol; and the
PC’s IP address in the IP address field.
1. Select a VLAN in the left pane of the dialog box.
2. Select the Enable NAT (Network Address Translation) check box. Then click Add to open
the Add Port Forwarding dialog box.
3. Select a Port Range Start and Port Range End for port forwarding.
4. Select a Protocol and specify an IP address.
5. Click OK to save your changes.
2. Specify the Hub Gateway and Remote Gateway endpoints for the tunnel.
3. Click OK to save your changes.
NOTE: This procedure only sets up the GRE tunnel within the iDirect system. You
must still establish the actual GRE endpoints on both sides of the link for a GRE
tunnel to work. GRE endpoints must be configured upstream from the Protocol
Processor and downstream from the remote.
Multicast Groups
Click the Multicast Group sub-tab to add, edit, or remove a persistent Multicast Group. To
configure the remote to be a member of a persistent Multicast Group, follow these steps:
1. Click the Add button.
NOTE: For more information, see the Technical Note titled “IP Multicast in
iDirect Networks.”
On an X7 remote, an L2oS CE Tag Transparent SVN can be assigned to one port only.
• If some CE Tag non-transparent SVNs are assigned to port 6 and CE Tag Transparent SVN
10 is assigned to port 6, then all CE Tag non-transparent SVNs are removed from port 6.
• If CE Tag Transparent SVN 11 is assigned to port 1 and CE Tag non-transparent SVN 100 is
assigned to port 1, then CE Tag Transparent SVN 11 is unassigned and port 1 is moved to
CE Tag non-Transparency mode.
• If CE Tag Transparent SVN 10 is assigned to port 2 and new CE Tag Transparent SVN is
assigned to port 2, then CE Tag Transparent SVN 10 is unassigned
• If CE Tag Transparent SVN 10 is assigned to port 1 and CE Tag Transparent SVN 11 is
assigned to port 2, and then CE Tag Transparent SVN 10 is assigned to port 2, then port 1
would be assigned for all CE Tag non-transparent SVNs and SVN11 is unassigned.
For more information on l2oS CE Tag Transparent SVNs, refer to the Technical Reference
Guide.
NOTE: CE Tag Transparent SVNs are indicated by an X attached to the SVN ID (for
example, 10_X) and are colored red.
NOTE: For X7-ER remotes, Port 1 and Port 2 are labeled as follows:
• Port 1 (Reserved-Cross Connect to 5921 Only)
• Port 2 (Reserved-Cross Connect to 5921 Only)
Port 1 and Port 2 are not used for VLAN assignment. The ports connect to the
single board computer (SBC) running the Cisco IOS 5921 routing software.
NOTE: For X7-EC remotes, Port 1 and Port 2 are labeled as follows:
(Reserved- Cross Connect to EC Applications Only)
Port 1 and Port 2 are not used for VLAN assignment. The ports connect to the
single board computer (SBC) running different application software.
The Switch tab contains two panes: the Port View (on the left), and the VLAN View (on
the right). In Layer 3 networks, only VLANs that have already been added to this remote
appear in the display.
By default, all ports are defined as trunks. Trunk ports display the word Yes in the All
VLANs row of the VLAN View. This default configuration is illustrated in Figure 6-26.
2. Use either the Port View or the VLAN View to assign a VLAN to a port. Both methods are
described here:
To use the Port View to assign a VLAN to a port:
a. In the Port View, right-click the port and select Assign VLAN from the menu to
display the dialog box.
NOTE: As an alternative, select the port and click the Assign VLAN button at the
bottom of the screen.
b. In the dialog box, select the VLAN ID of the VLAN to be assigned to the port. (In Layer
3 networks, the VLAN Name will be displayed automatically.)
c. In L2oS and Layer 2/Layer 3 Hybrid mode networks only, if the SVN/VLAN ID has not
yet been configured, enter the SVN/VLAN ID. The range of valid VLAN IDs is from 2 to
4094.
NOTE: The ID pull-down list provides IDs for the Layer 2 SVNs that have been
assigned to the remote from the L2oS tab and the Layer 3 SVNs that have been
assigned at the IP Config tab.
NOTE: If a local Id is defined at the remote’s L2oS tab, the list will use local id
instead of global id.
d. Click OK.
To use VLAN View to assign a VLAN to a port:
a. In the VLAN View, right-click in the table cell representing the port of the VLAN you
want to configure.
b. Choose Select from the menu.
Both methods of assigning a VLAN to a port are illustrated in Figure 6-28.
In the VLAN View, the word Yes is displayed for the VLAN in the column for the selected
port.
NOTE: Double-click in any empty cell in the VLAN view to select that cell. The
word Yes will be displayed in that cell.
Figure 6-31. Selecting the Same Switch Setting for All Ports
5. By default, the port speed and port mode are automatically negotiated. Follow these
steps to disable auto-negotiation and select a port speed and port mode:
a. In the Port View, right-click the port and select Properties from the menu to open
the Properties dialog box.
CAUTION: The port settings must match the attached equipment. Mismatches in
either port speed or port mode will result in packet loss.
6. To copy a row (or all rows) from the VLAN View in order to paste the information into a
separate application such as a spreadsheet, follow these steps:
a. In the VLAN column, click the VLAN name (or click All VLANs) in the first column of
the row you want to select. This will highlight the name in the VLAN column. (Or press
Ctrl + A to select all rows in the table.)
b. Right-click on any of the selected entries in the first column; then select Copy or
Copy without headers from the menu.
Filter Profiles are described in Application Profiles and Filter Profiles on page 301.
NOTE: You can click the Details button next to the Filter Profile drop-down menu
to view the configuration of the selected Filter Profile.
Follow these steps to select a Service Group and Service Profile or Remote Profile, or a
downstream Multicast Service Profile, to a remote:
1. Click the Edit button next to the current Upstream or Downstream Service Group
assignment (Figure 6-34) to display the QoS Profile Select dialog box (Figure 6-36).
Figure 6-36. Remote QoS Tab: QoS Profile Select Dialog Box
5. Click OK. The new assignments are displayed on the Remote QoS tab.
In rare cases, when using Application Service Groups, you may want to assign multiple
Downstream or Upstream Service Profiles to a single remote. If you select more than one
Service Profile, the last Service Profile that you select in the QoS Profile Select Dialog Box is
designated as the Primary Service Profile. The NMS and Default Applications from the Primary
Service Profile are used by the system. The NMS and Default Applications from other selected
Service Profiles are not used. For more information see Assigning Service Profiles to Remotes
on page 271.
NOTE: Unlike Service Profiles, only one Downstream and one Upstream Remote
Profile can be assigned to a Remote.
Figure 6-37 shows two Service Profiles assigned to a single remote in an Application Service
Group. Service Profile 1 is the Primary Service Profile. The Primary Service Profile is always
displayed in bold typeface on the GUI.
2. In the QoS Profile Select dialog box, select an upstream Remote Profile.
3. Click OK.
Figure 6-39. Remote QoS Tab: Upstream and Downstream Rate Shaping
Your ability to configure the Downstream and Upstream Rate Shaping parameters, as well as
Allocation Fairness Relative to CIR, depends on the type of Service Group selected in the
Service Group field (Figure 6-34) and the QoS Mode selected on the QoS tab of your Network
and Inroute Group. Since QoS Mode only applies to Application Service Groups, the selection
among the following three options determines which parameters you can configure here:
• Remote Service Groups
• Application Service Groups in Remote Based QoS Mode
• Application Service Groups in Application Based (or Application Scaled) QoS Mode.
For a detailed explanation of Service Group types and QoS Modes, see Configuring Quality of
Service for iDirect Networks on page 229.
Table 6-1 on page 193 shows which QoS parameters you can select on the Remote QoS tab
depending on which of the three options listed above is configured for the remote’s Network
(Downstream) or Inroute Group (Upstream). As noted in the table, you cannot configure EIR
on the Remote QoS tab unless it has been enabled for remotes in this remote’s Service Group
on the QoS tab of your DVB-S2 network.
NOTE: Upstream Rate Shaping parameters such as CIR and MIR are not applicable
to SCPC remotes at the remote level of the QoS tree, since all of the upstream
bandwidth is dedicated to the physical remote. However, you can select or clear
Allocation Fairness Relative to CIR to influence how bandwidth is distributed
among the Applications running on the remote.
Table 6-1. Availability of Remote QoS Parameters by Service Group Type and Mode
* DVB-S2 Networks only. EIR must be enabled for the Service Group on the Network QoS tab
to select this option.
NOTE: For definitions of Priority, Cost, MIR, CIR, MIN, EIR, and Allocation Fairness
Relative to CIR, see QoS Properties on page 230.
NOTE: If this remote is in a DVB-S2 ACM network, you can enable EIR on the
Downstream and select a Minimum MODCOD. See the EIR and MODCOD
Configuration on page 197 for details.
Note: This feature is applicable only to remotes that transmit TDMA upstream
carriers. Enabling Idle and Dormant States has no effect on SCPC remotes.
If the Idle and Dormant States feature is enabled, the remote can be in one of three states:
Active, Idle or Dormant. Figure 6-40 shows the fields on the Remote QoS tab used to configure
this feature. The configuration of the remote’s Minimum Information Rate fields determine
the system behavior in the Active State. The configuration of the Idle and Dormant States
fields determine the system behavior in the other two states.
For a detailed description of this feature, see the chapter titled “Remote Idle and Dormant
States” in the Technical Reference Guide.
NOTE: Minimum Information Rate must be greater than or equal to the Idle
Minimum Information Rate. Similarly, the Idle Minimum Information Rate must be
greater than or equal to the Dormant Minimum Information Rate.
NOTE: For remotes to remain in the network, Evolution remotes should transmit
at least 1 burst every 4 seconds. With a frame length of 125 ms, this translates
into a minimum of 1 slot every 32 frames. Unless explicitly permitted by the
network design, do not go below this limit for any state.
NOTE: A low Minimum Information Rate in any state may trigger Latency Warnings
for the remote in iMonitor. To prevent these warnings, increase the Latency
timeout for the remote on the Remote Warning Properties tab. See Setting
Warning Properties for Remotes on page 214 for details.
Follow these steps to enable Minimum Information Rate and/or Idle and Dormant States for
a remote:
1. To configure a Minimum Information Rate:
a. Select Enable.
b. Enter a Minimum Information Rate in kbps. As shown in Figure 6-40, the equivalent
slots/frame is automatically displayed when you click in another field on the screen.
2. To configure Idle and Dormant States, select Enable Idle and Dormant States.
3. For both the Idle State and the Dormant State:
a. Enter the minimum frequency at which slots are allocated to the remote in that state
(in units of 1 slot per n frames). As shown in Figure 6-40, the equivalent Minimum
Information Rate is automatically displayed in kbps.
b. In Timeout, enter the number of seconds that the remote should remain in the
previous state with no upstream user traffic before entering this state.
NOTE: By default, only upstream user traffic triggers a state change from Idle
State or Dormant State to Active State. Upstream NMS traffic does not trigger a
state change by default. However, you can change these default settings by
selecting or clearing the Trigger State Change field in your upstream Service
Levels. See Adding an Application Profile on page 304 for details.
NOTE: The maximum C/N includes the Fade Slope Margin (M1) and the Hysteresis
margin (M2). For mobile terminals that use the map server feature, the
configured value refers to the edge of coverage and the actual value may be
adjusted automatically depending on the actual location.
Follow these steps to configure the Adaptive Parameters for this remote:
1. Click the Adaptive Parameters sub-tab on the Remote QoS tab to view the Adaptive
Parameters section.
NOTE: Maximum Link Impairment only affects IGC selection. It does not affect
the amount of bandwidth allocated to the remote.
3. Enter a Minimum Symbol Rate for the remote. The remote will not be allowed to
transmit on upstream carriers with symbol rates lower than the configured value.
4. Enter the Maximum C/N for the remote. The remote will not be allowed to transmit on
upstream carriers that require its TDMA bursts to exceed this C/N.
NOTE: The maximum C/N includes the Fade Slope Margin (M1) and the Hysteresis
margin (M2). For mobile terminals that use the map server feature, the
configured value refers to the edge of coverage and the actual value may be
adjusted automatically depending on the actual location.
The EIR and MODCOD sections of the dialog box apply only to remotes receiving a DVB-S2
outbound carrier with ACM enabled. Note the following:
• EIR is enabled for CIR allocations within the range defined by the Nominal MODCOD and
the EIR Minimum MODCOD defined for the remote.
• Allocation of physical bandwidth is held constant at the remote’s Nominal MODCOD when
the current MODCOD of the remote is below the EIR Minimum MODCOD.
• CIR and MIR allocations to the remote are capped at the remote’s Nominal MODCOD. A
remote may operate above its Nominal MODCOD, but CIR and MIR allocations are not
increased.
NOTE: You can only configure upstream and downstream CIR and downstream EIR
on the Remote QoS tab when using Remote Service Groups or when the QoS mode
for the Network is set to Remote Based. See QoS Modes on page 240 for more
information about QoS Modes.
NOTE: You cannot configure EIR on the Remote QoS tab unless EIR has been
enabled for remotes in this Service Group. This applies to both Remote Service
Groups and Application Service Groups in Remote Based Mode. The minimum
possible EIR MODCOD for the remote is also determined by the Service Group
configuration. See Adding a Service Group on page 262 for more information.
NOTE: Do not select 16APSK or 32APSK as the Maximum MODCOD unless your
remote is using an internal PLL LNB.
NOTE: Beginning with iDS Release 8.2, the TDMA upstream segment size is
automatically calculated by the system. You can no longer configure the TDMA
upstream segment size in iBuilder.
To change the Segment Size for the Downstream Distributor or Upstream Distributor:
1. Select Enable.
2. Enter a Segment Size.
See the chapter titled “QoS Implementation Principles” in the iDirect Technical Reference
Guide for more information about packet segmentation.
Figure 6-44. Remote Geo Location Tab: Settings for Stationary Remotes
When commissioning a mobile remote, use the Geo Location tab to specify the remote’s
mobile settings.
Figure 6-45. Remote Geo Location Tab: Settings for Mobile Remotes
The GPS Input selected determines the baud rate of the serial console interface to the
remote. For Serial or NMEA, change the Baud Rate and other serial interface parameters
as required.
3. Select Handshake Signaling to provide an input and output signal to the stabilizing
antenna through the serial console port.
4. Select Mobile Security to prevent the remote’s latitude and longitude location from being
transmitted to the NMS over the satellite link. With Mobile Security selected, it is not
possible to determine the remote’s location from the hub.
5. If required, change the Minimum Look Angle configured for this remote’s antenna by
selecting Override and entering a new angle. Select Inherit from Satellite to use the
value configured for the satellite. (See Adding a Spacecraft on page 73.)
6. If required, change the Maximum Skew configured for this remote’s antenna by selecting
Override and entering a new angle. This value represents the maximum angle of skew
that the antenna can tolerate before it stops transmitting. Select Inherit from Satellite
to use the value configured for the satellite. (See Adding a Spacecraft on page 73.)
7. If required, change the Skew Margin configured for this remote’s antenna by selecting
Override and entering a value in degrees. Skew Margin is used to optimize the use of
upstream carriers for mobile remotes using non-circular polarization in Adaptive systems.
Select Inherit from Satellite to use the value configured for the satellite. (See Adding a
Spacecraft on page 73.)
8. Select a COTM type: Maritime, Vehicular, or Avionics. This selection should be consistent
with the Maximum Speed configured for the remote’s inroute group.
NOTE: A high-speed COTM license is required for mobile remotes that exceed 150
mph. Avionics does not appear in the drop-down menu unless this feature license
has been imported into iBuilder for this remote. See Managing NMS Licenses on
page 60.
Mobile State
When the remote is configured as Mobile, it looks for GPS string on the serial console port to
provide its latitude and longitude information in the form of an NMEA string. It uses this
information to compute the FSD and acquire into the network.
Once a remote has been acquired into the network, the remote automatically sends its
latitude and longitude to the hub every 30 seconds. However, when Mobile Security is
selected, the remote will not send its current geographic location to the hub. Since the
remote requires this information to communicate with the hub, mobile remote users must
determine it and communicate it to the remote, enabling the remote to compute the FSD.
In the absence of a GPS receiver interface to the modem, you can supply the latitude and
longitude information manually through the serial console interface. You can also provide the
geographic location information for the hub through the iSite GUI. (The hub geographic
location is always sent as a broadcast message from the hub.)
The baud rate of a serial connection to a mobile remote depends on the GPS Input selected in
the Mobile area of the Geo Location tab. The baud rates and typical usage of these selections
are discussed here:
• Manual (9600 baud): Select Manual when the port is not connected to a GPS receiver and
you want to manually set the latitude and longitude from the remote console. Selecting
Manual will cause the modem to save the latitude and longitude to flash memory. If you
select either of the other options, this information will not be saved to flash and will be
lost in the event that the remote resets.
• Serial or NMEA (4800 baud): Select Serial or NMEA when the port is connected to a GPS
receiver. The 4800 baud rate is a requirement of the NMEA protocol used by GPS to
communicate with the remote.
• Antenna (9600 baud): Select Antenna when using the iDirect Automatic Beam Selection
feature. If you select this option, the port must be connected to one of the mobile
antennas supported by iDirect. For more on this feature, see Configuring Networks for
Automatic Beam Selection on page 507.
NOTE: E8350 remotes have a separate serial port for GPS and are not affected by
configuration changes made at the Geo Location tab.
NOTE: X5 and X7 remotes accept Baud Rate configuration changes only; Data Bit,
Parity, or Stop Bit changes are not supported.
NOTE: The serial console interface is set to 9600 baud for non-mobile remotes.
Handshake signaling requires a stabilizing antenna and requires customers to build their own
electrical interface (converter) to communicate with the antenna. When Handshake
Signaling is enabled at the NMS, the mobile remote provides an input and output signal to the
stabilizing antenna through the serial console port. The output signal, or lock signal, indicates
the frame lock status of the receiver on the remote. The input signal TxMute is used to mute
the transmitter until the antenna pointing is completed.
The remote sends an RS-232 active signal on the console port DTR output (pin 2) while the
modem is trying to acquire the downstream carrier. Once the remote achieves TDM frame
lock, the DTR signal becomes inactive. This signal is intended to indicate to the auto-point
antenna equipment when to switch from coarse-tune to fine-tune mode.
The DSR input on the console port (pin 7) can be used as a “mute” function and will allow the
auto-point antenna equipment to delay acquisition transmit until the antenna has finished
pointing. Without this function, the modem may transmit as soon as it detects TDM frame
lock, before the antenna is properly pointed and polarized. Sending an RS-232 active level to
the DSR input enables the mute function.
NOTE: The Tx Key Line area of the Remote Antenna section of the VSAT Tab
(Figure 6-46) only appears when configuring Evolution e850mp, e150, or 9-Series
remotes.
NOTE: iDirect brand BUCs and LNBs are preconfigured in the Components folder
of the iBuilder Tree.
NOTE: iBuilder filters the list of selectable BUCs based on the value configured
for the ODU Tx Oscillator field of the BUC components. Evolution X7 remotes
allow both 10 MHz and 50 MHz. All other remote model types require 10 MHz.
2. Select the LNB for this remote from the LNB drop-down menu.
NOTE: When selecting an iDirect PLL LNB, ensure that the LNB has the correct
selection for the 22 kHz tone in the LNB dialog box. Enable the 22 kHz tone to
select the high frequency band. Disable the 22 kHz tone to select the low
frequency band.
3. Select Boost LNB Supply Voltage to add 1 dB to the DC voltage configured for the LNB
selected in Step 2. (This field is only applicable for LNBs with ODU Rx DC Power
enabled.)
4. Selecting an IFL, Reflector Mount, and/or Reflector is optional.
5. The Approximate Cable Length should be set during the commissioning process. You can
record it here for reference.
6. The Transmit Key Line feature is only available for Evolution e850mp, e150, or 9-Series
remote terminals that support the transmit key line interface. Enabling Tx Key Line tells
the remote to provide a differential RS-485 signal to the BUC. This signal can be used to
conserve terminal power. To enable this feature:
a. Under Tx Key-line, select Enable.
b. Enter a BUC PA Warm-up Time from 0 to 1700 microseconds.
NOTE: See the Technical Reference Guide for a description of the Transmit Key
Line feature.
7. The tabs on the lower half of the dialog box display the details of the components that
you have selected. Click OK to save your settings. The new remote is added to the
iBuilder Tree under the Inroute Group or line card.
NOTE: If using the iDirect Automatic Beam Selection feature, select a Reflector
that is configured with a controllable antenna. For controllable antennas, a
number of additional fields are shown on the right-hand side of the Remote
Antenna area of the VSAT tab. (See Figure 6-47 on page 204 for one example.) For
details on configuring these fields, see Configuring Networks for Automatic Beam
Selection on page 507.
To select the LNB frequency band and cross polarization for these Transceivers from the LNB
folder of the iBuilder Tree:
1. Right-click the Transceiver in the LNB folder and select ModifyItem.
2. In the LNB dialog box, select the correct ODU Rx DC Power and 22 kHz Tone settings for
the transceiver as follows:
a. For a DRU15F16X or DRU17F16X, select 18V for ODU Rx DC Power for cross-
polarization. Select 13V for ODU Rx DC Power for co-polarization.
NOTE: The DC Voltage can be increased by 1 Volt by selecting Boost LNB Supply
Voltage. See Step 3 on page 203.
b. The presence or absence of a 22 kHz tone determines the LNB frequency band
selected by the transceiver. Select Enable 22 kHz Tone for the high frequency band
(11.70 to 12.20 GHz). Clear the Enable 22 kHz Tone check box for the low frequency
band (10.70 to 11.70 GHz).
[SATELLITE]
stacker_primary_polarity = H
Default Value
Custom Key Group/Name Description Value Range
Process
#[FREQ_TRANS] When tuning the remote's Rx, if MHz, the LNB down_translation
#stacker_down_translation the beam being tuned has a translation
polarization different from frequency for
stacker_primary_polarity, the the 'non-primary'
remote will use polarity band.
stacker_down_translation
instead of down_translation.
Otherwise the previous beam-
based logic will apply.
[SATELLITE] If present, indicates the • V- vertical null
stacker_primary_polarity terminal has a Stacked • H - horizontal
antenna/LNB. When sending • L - left
the OpenAMIP 'P' command, the
• R - right
remote will always use the
stacker_primary_pol value, if it
exists. Otherwise the previous
beam-based logic will apply.
Additionally, see the following sections for additional information about configuring
an X7 remote to receive encrypted Multicast Fast Path traffic on a second
demodulator:
• Configuring a Protocol Processor to Enable X7 Encrypted Multicast Fast Path
on a Second Demodulator on page 98
• Adding a Network on page 118
• Setting Up Global Key Distribution for Encrypted Multicast Fast Path on an X7
Second Demodulator on page 500
To configure an Evolution X7 remote to receive Multicast Fast Path traffic on a second
demodulator, perform the following:
1. Click the VSAT-2 tab of the remote to open it. See Figure 6-50.
5. In Rx Frequency, enter the downlink center frequency of the second downstream carrier.
6. Enter the Symbol Rate of the second downstream carrier.
7. In the Authorized Multicast Fast Path Streams section, select the stream numbers of the
Multicast Fast Path streams that this remote should forward to the local LAN.
NOTE: The stream numbers can be viewed in the Application dialog boxes of the
Multicast Fast Path Applications configured in the Group QoS tab of the second
network. Figure 6-51 illustrates this.
NOTE: The IFL and BUC tabs at the bottom of the VSAT-2 screen display the
details of the selected components.
The L2oS tab is only displayed if the L2oS Enabled check box is checked on the Information
tab of the Protocol Processor controlling this remote’s network. Figure 6-52 shows the Remote
L2oS tab.
NOTE: At the bottom of the L2oS tab, Enable BFD Proxy is disabled by default.
Bidirectional Forwarding Detection (BFD) is a network protocol used to detect
faults between two forwarding engines connected by a link. Refer to the Technical
Reference Guide for additional information.
NOTE: All three modes are available for X1 remotes; only VLAN mode is available
for X7 remotes.
b. If Mode is VLAN or QinQ, enter Ethertype 1. This field defaults to 0x8100 for VLAN
Mode and 0x9100 for QinQ Mode.
c. If Mode is QinQ, enter Ethertype 2. This field defaults to 0x8100.
NOTE: Both CE Tag Transparent SVNS and CE Tag Non-Transparent SVNs can be
assigned to the same remote. Refer to the Technical Reference Guide for
information.
NOTE: Layer 2 or Layer 3 SVNs must be predefined in the Protocol Processor SVNs
tab pane before they can be assigned to a remote. Refer to Configuring L2oS Hub
Parameters on page 105.
NOTE: For information on adding Layer 3 SVNs to the remote, see Adding Layer 3
SVNs to a Remote on page 172.
NOTE: For X7 remotes, all eight ports are available for CE transparent SVNs.
However, if all eight ports are used for CE Tag Transparent SVNs, there will be no
access to the VLAN 1 on the remote LAN side; Web iSite will not work either. For
more information on assigning X7 ports, see Remote Switch Tab on page 182.
A CE Tag Transparent SVN is indicated by an X attached to the SVN ID (for example, 10_X)
as shown below.
3. If desired, enter a Local Id. This is an optional SVN ID that remaps the SVN ID(s) on the
remote LAN to a different SVN ID.
iBuilder does not permit Local IDs to be configured for CE Tag Transparent SVNs.
For more information on local IDs, see the Layer 2 over Satellite chapter in the Technical
Reference Guide.
The following local IDs are available for the SDT modes:
• For VLAN mode, Local ID (SP) is available
• For QinQ mode, Local ID (SP) and Local ID (CE) are available
• For Access mode, no Local ID is available
NOTE: For X1 remotes, Local ID (SP) and Local ID (CE) are available. For X7
remotes, Local ID (SP) is available except for CE Tag Transparent SVNs (for these
SVNs, the traffic from the assigned ports would not have SP tags).
4. Select Enabled to enable this SVN. An SVN must be enabled to be used. A maximum of
eight SVNs can be enabled per remote.
5. Click OK to add the SVN to the list of SVNs in the SVNs pane.
NOTE: After an SVN is added to the SVNs pane, it can be changed by selecting the
SVN and clicking the Edit button. The SVN dialog box will open for making
changes.
NOTE: After an SVN is added to the SVNs pane, it can be removed by selecting
the SVN and clicking the Remove button.
For information on learned MAC expiration at the Protocol Processor, see Protocol Processor
MAC Address Aging Timeout on page 107.
NOTE: The L2oS Advanced header compression options are described in detail in
the chapter “Layer 2 over Satellite” of the Technical Reference Guide.
NOTE: Global NMS is a licensed feature. If you plan to define and track roaming
remotes in your network, please contact the iDirect Technical Assistance Center
(TAC).
The Global NMS feature allows remotes to move among networks on various transponders and
satellites, controlled from various hubs. To accomplish this, you must define the remote in all
of the networks in which it will be visible. For more information of the Global NMS feature,
see the chapter titled “Global NMS Architecture” in the iDirect Technical Reference Guide.
The set of parameters that defines a roaming remote falls into three categories:
• Parameters that must be the same in all networks: DID, passwords, and remote name.
iBuilder will not allow you to define these parameters inconsistently across networks for
the same remote.
• Parameters that must be different in each network. These consist mostly of internal
database IDs and references that are automatically established by iBuilder when the
remote is defined in multiple networks.
• Parameters that may be the same or different from network to network. These “don’t
care” parameters include everything not in the lists above. Examples are IP configuration,
QoS settings, initial transmit power values.
Once you define a roaming remote and add it to multiple networks, the “don’t care”
parameters will be identical in all networks. At that time, you can modify these parameters in
the different networks as desired. (See Managing “Don’t Care” Parameters on page 218).
2. Select the appropriate check boxes to add the remote to one or more additional
networks.
NOTE: For purposes of redundancy, the Roaming Remote dialog box also allows
you to configure an SCPC remote in multiple networks by selecting line cards in
SCPC return mode.
3. Click OK to save your changes and close the dialog box. iBuilder automatically adds the
remote to the selected networks, copying the “don’t care” configuration items to the
new networks. You are free to modify the remote’s configuration in the other networks as
desired.
NOTE: When adding roaming remotes to networks, only networks in which the
remote is not currently configured are displayed in the dialog box.
The Revision Server is completely compatible with roaming remotes. You may upgrade a
network even if a roaming remote is in another network. As long as IP connectivity is available
from the NMS to the remote, the remote will receive the download package (image and
options file), write it to flash memory, and reset. For details, see Upgrading Remotes Using
Revision Server on page 367.
2. Update the values in the Roaming Properties Update dialog box as desired.
3. Click OK to save your changes and close the dialog box. iBuilder updates the remote in all
of its networks.
desired network and selecting Modify. This allows you to modify the remote’s parameters in
one network while leaving them unchanged in the others.
However, it is likely that many of a roaming remote’s “don’t care” parameters will be the
same from network to network. In those instances, iDirect recommends that you use iBuilder’s
Group Edit feature to modify the remote. Since this method allows you to modify shared
parameters on all instances of the remote at the same time, it is both easier and less error-
prone than making the changes one by one. For a general discussion of this feature, see
Working with Multiple Elements Simultaneously on page 44.
The procedure beginning on page 220 explains how to modify multiple instances of the same
remote using the iBuilder Details pane. Although you can use this method to modify any or all
instances of a remote, a more convenient method exists to modify all instances of the
remote.
To modify all instances of the same remote:
1. Right-click the Remote in the iBuilder Tree and select Modify All Instances in the
Roaming section of the menu.
2. In the Modify Configuration Object dialog box (Figure 6-59), change the remote
parameters that you want to modify.
NOTE: iBuilder will only allow you to modify “don’t care” parameters when
modifying multiple instances of the same remote.
This option removes the hierarchical structure of the network elements and components
so they can all be shown in a single window.
4. In the Details View, select the Type column header to sort by element type. This will
group together all remotes, regardless of their networks.
5. If desired, select the Name column header to further sort by element name. This will
group together all instances of a roaming remote, since the remote has the same name in
all networks.
6. Select all desired instances of the Roaming Remote in the Details pane.
7. Place the mouse pointer over the remote names in the highlighted group.
8. Right-click and select Modify from the menu.
9. Modify the remote’s shared parameters as required. Only parameters that are common to
all network instances can be changed.
The Add Multiple Roaming Remotes dialog box opens with a list of available remotes.
NOTE: Remotes that already exist in more than one other network may be listed
multiple times.
NOTE: When you select a remote instance from the list, other instances may be
invalidated. Invalid selections appear in red and an explanation is displayed in the
Comment column.
The Add Roaming Remotes to Networks dialog box opens with a list of available network
/ inroute group combinations.
2. Select the network / inroute groups to which you want to add the remote.
NOTE: You can only select one inroute group in any network for the remote.
Invalid selections appear in red and an explanation is displayed in the Comment
column.
NOTE: Access to the iDirect system is only allowed from a local host. Instead of
using the telnet <ip address> command, users now must ssh to the server with
the ssh <ip address> command and then telnet to the console from the local host
using the telnet localhost <port number> command or the telnet 0 <port
number> command.
.
[RMT:2036] admin@telnet:10.0.150.7;1084
> beamselector
control Beam selector control command
list list known beams
mapsize print or change the map size request params
params stats | params | debug
switch switch to new beam
[RMT:2036] admin@telnet:10.0.150.7;1084
> beamselector list
3 is currently selected
3 = Beam_603_340000_GA
2 = Beam_906_64000_GB
1 = Beam_605_174000_GA
Follow these steps to enable the first four compression types per remote on the remote
Information tab:
1. Right-click the Remote and select ModifyItem.
2. In the Compression area of the Information Tab, select each compression type that you
want to enable for the remote.
disabled for all sessions. If CPU utilization is below 50 percent, a maximum of five TCP
sessions are compressed. If the number of sessions exceeds five, the additional sessions are
not compressed.
6.14.3 CRTP
Compression of RTP packet headers (CRTP) is performed on per-packet basis using zlib. Unlike
TCP Payload compression, it is not stream-based. CRTP is available for all iDirect remote
model types.
iDirect’s implementation of the CRTP algorithm follows the specification in RFC 2508,
Compressing IP/UDP/RTP Headers for Low-Speed Serial Links. This RFC defines both CRTP
(header compression for RTP packets) and UDP header compression (for other UDP packets).
When you enable CRTP in iBuilder, only RTP packet headers are compressed. To apply header
compression to other UDP packets, enable UDP header compression. (See UDP Header
Compression on page 226.)
The iDirect CRTP implementation is a simplex-based compression scheme with the periodic
retransmission of full headers to restore the compression state in the event of error. Correct
functionality of the CRTP implementation has been field-proven in multiple releases.
NOTE: The QoS bandwidth allocation algorithm does not strictly enforce MIR for
inroute traffic. Therefore, it is possible that a node may receive more bandwidth
than the configured maximum if free bandwidth is available. However, this does
not affect bandwidth allocations for competing nodes. Note that MIR is strictly
enforced for outbound traffic.
• Committed Information Rate (CIR): CIR specifies an amount of bandwidth that is allocated
to a node before additional (non-CIR) bandwidth is allocated to that node for traffic with
the same priority. At any priority level, all competing nodes are first granted their CIR
bandwidth to the extent possible. If CIR demand is met, additional demand exists, and
additional bandwidth is available, then the remaining (non-CIR) demand is met to the
extent possible.
NOTE: Unlike the other QoS properties described here, Full-Trigger CIR can only
be configured with a remote custom key. See Configuring Full-Trigger CIR for a
Remote on page 291 for details.
Note:
• Allocation Fairness Relative to CIR: If you select this option then, during contention for
bandwidth, bandwidth allocation is proportional to the configured CIR. This favors QoS
nodes with higher CIR settings, since those nodes are granted a larger portion of the
available bandwidth. If this option is not selected, bandwidth is allocated equally to
competing nodes until available bandwidth is exhausted. If selected, this option applies
to both CIR and best-effort bandwidth allocation. (See Allocation Fairness Relative to CIR
on page 256 for more details.)
NOTE: The above definition assumes that equal cost has been configured for
bandwidth on all competing nodes. Unequal cost will affect the proportions of
bandwidth allocated to each node regardless of whether or not Allocation Fairness
is selected.
• Enhanced Information Rate (EIR): EIR only applies to networks that use DVB-S2 with
Adaptive Coding and Modulation (ACM). ACM adjusts the modulation and coding (MODCOD)
of the outbound channel on a frame-by-frame basis depending on the current receive
capabilities of the individual remotes in the network.
EIR is enabled only within the range of MODCODs from the Nominal MODCOD configured
for a remote down to the EIR Minimum MODCOD configured for a remote application. (See
page 277.) Within this range, the system attempts to sustain the bandwidth allocations
required for the remote to meet its configured QoS information rates (CIR and MIR) even
as the encoding of the remote’s downstream data drops to lower MODCODs. This is
accomplished by increasing the bandwidth allocated to the remote application in order to
compensate for the additional bits required for error correction at the lower MODCODs.
When the remote’s current MODCOD is below the EIR minimum MODCOD, the system
ignores the current MODCOD status of the remote when allocating bandwidth. Instead,
physical bandwidth is allocated to the remote application as if it were receiving the
outbound carrier at the Remote’s Nominal MODCOD. Therefore, below the minimum
MODCOD, the system does not attempt to meet the CIR or MIR settings and the remote’s
information rate will decrease based on the satellite bandwidth required at the remote’s
nominal MODCOD. For more information on EIR, see the DVB-S2 chapter of the iDirect
Technical Reference Guide.
• Allocation Fairness Relative to Nominal MODCOD: This property only applies to networks
that use DVB-S2 with Adaptive Coding and Modulation (ACM). If you select this option,
bandwidth allocation is scaled to information rate at the Nominal MODCODs of the
remotes. This favors remotes configured with lower nominal MODCODs, since their
satellite bandwidth allocations must increase to achieve the same information rate as
remotes with higher MODCODs. If neither this option nor Allocation Fairness Relative to
Operating MODCOD is selected, satellite bandwidth is allocated without regard to
MODCOD. This favors remotes with higher MODCODs, since the higher the MODCOD, the
greater the information rate for the same amount of bandwidth.
• Allocation Fairness Relative to Operating MODCOD: This property only applies to networks
that use DVB-S2 with Adaptive Coding and Modulation (ACM). If you select this option,
bandwidth allocation is scaled to information rate at the operating MODCODs of the
remotes. This favors remotes currently operating at lower MODCODs, since their satellite
bandwidth allocations must increase to achieve the same information rate as remotes
operating at higher MODCODs. If neither this option nor Allocation Fairness Relative to
Nominal MODCOD is selected, satellite bandwidth is allocated without regard to MODCOD.
This favors remotes with higher MODCODs, since the higher the MODCOD, the greater the
information rate for the same amount of bandwidth.
NOTE: Unlike TDMA upstream MIR and CIR, downstream MIR and CIR are not based
on IP Data Rate. Downstream MIR and CIR are based on Information Rate.
• Best-effort
For more details on iDirect’s QoS implementation, see the chapter titled “QoS
Implementation Principles” in the iDirect Technical Reference Guide.
Bandwidth
Pool
Bandwidth Bandwidth
Group 1 Group 2
Application 1
Application 2
Application 3
Remote A Remote B
Application 4 Application 10
Remote 1 Remote 2 Remote 3 Application 6 Application 11
Application 7 Application 14
A node is a basic element in the Group QoS tree and can either be a terminating element or a
container for other nodes. Beginning at the highest (root) node in the Group QoS tree,
available bandwidth is allocated by that node to all subnodes based on operator-defined QoS
properties and the current demand as indicated by the subnodes.
Only terminating (leaf) nodes generate demand. As demand moves up the tree in the form of
bandwidth requests, each higher-level (parent) node aggregates demand from its subnodes
before passing it up in the form of its own request. All demand reaches the root in a single
request representing the total demand of all leaf nodes.
Bandwidth allocation begins at the root node and flows down the tree. Each node subdivides
its own allocation among its subnodes based only on the Group QoS properties of the
subnodes. Therefore each node competes for bandwidth only within its own node group (i.e.
the set of subnodes that share a parent node). Each Remote prioritizes the use of its allocated
bandwidth according to QoS properties configured for the different types of applications that
generated the demand in the first place. (See QoS Properties on page 230.)
The properties configured for a parent node supersede those of its subnodes when those
properties conflict. For example, the total maximum bandwidth granted to all nodes in a node
group will never exceed the maximum bandwidth configured for the parent node, regardless
of the configuration of its subnodes.
NOTE: For flexibility, the NMS does not attempt to enforce limits on subnodes
based on the properties of the parent node. For example, the total CIR configured
for a node group may exceed the CIR configured for the parent node. If CIR is
oversubscribed in this way, it is possible that all nodes will not receive their full
CIR allocations during times of heavy traffic.
Bandwidth Pool
A Bandwidth Pool represents the root of a Group QoS tree. Therefore, all other groups in the
tree are contained in the Bandwidth Pool. In iDirect, a Bandwidth Pool can be either an
Outroute or an Inroute Group.
Bandwidth Group
A Bandwidth Pool can be divided into multiple Bandwidth Groups. By defining Bandwidth
Groups, a network operator can subdivide an Outroute or Inroute Group into multiple QoS
groups, each with its own QoS properties.
A Network Operator might use multiple Bandwidth Groups to divide a Bandwidth Pool among
different Service Providers or Virtual Network Operators (VNOs). Bandwidth Groups can be
configured with CIR and MIR to enforce the desired division of the total bandwidth among the
Bandwidth Groups.
NOTE: The bandwidth allocation algorithm cannot guarantee that MIR configured
at the Bandwidth Group and Service Group levels will be met.
Service Group
Just as a Bandwidth Pool can be divided into multiple Bandwidth Groups, a Bandwidth Group
can be subdivided into multiple Service Groups, each with its own QoS properties.
There are two types of Service Groups, Application Service Groups and Remote Service
Groups. There are no restrictions on the types of Service Groups contained in a Bandwidth
Group. A Bandwidth Group may contain only Application Service Groups, only Remote Service
Groups, or both types of Service Groups.
An Application Service Group contains multiple Applications. Remotes assigned to an
Application Service Group share the bandwidth assigned to the various Applications in the
group.
When using Remote Service Groups, a remote becomes a container node for its Applications.
Each remote is configured with its own QoS properties such as MIR and CIR and independently
allocates that bandwidth to its Applications. Remote Service Groups allow you to configure
bandwidth for individual remotes and then assign multiple Applications to the remotes. The
bandwidth allocated to the Applications under a remote is taken from bandwidth granted to
the individual remote; it is not shared with other remotes as it is with Application Service
Groups. Note that this structure allows remotes to retain their QoS configuration when
moving between networks. See Moving Remotes Between Networks, Inroute Groups, and Line
Cards on page 333 for more information.
Figure 7-2 illustrates the difference between Application Service Groups and Remote Service
Groups.
Application Remote
Service Service
Group Group
Application 1
Application 2
Application 3
Remote 1 Remote 2 Remote 3
Application Service Group: Bandwidth allocated to an Application Remote Service Group: Bandwidth allocated to a remote is
is shared by all remotes requesting bandwidth for that Application. shared by all Applications on that remote requesting bandwidth.
Application Service Groups, along with the Applications they contain, are used to define
Service Profiles that are then assigned to remotes. This differs from Remote Service Groups,
in which Remotes are assigned to Service Groups and Applications are assigned directly to
remotes using Remote Profiles.
A Service Group might be used solely to partition the bandwidth of a Bandwidth Group among
sub-groups; or it might be used to differentiate groups by class of service. For example, an
operator or a VNO might further divide a Bandwidth Group into Service Groups and assign
each Service Group to a different customer, using CIR and MIR to enforce the desired division
of the total bandwidth among the Service Groups. Or a Service Provider might create Service
Groups to offer multiple levels of service, using a combination of Priority, Cost and CIR/MIR to
create tiered service.
NOTE: When upgrading from an iDirect release that did not support Group QoS
(pre-iDS 8.0) you can choose to upgrade to Application Service Groups or Remote
Service Groups. Select Remote Service Groups to best preserve your pre-8.0 QoS
functionality.
Application
Applications consist of the Service Levels and Rules defined to handle the various types of
traffic in your networks. Applications are defined by Application Profiles and are either
assigned to Application Service Groups or to Remotes in Remote Service Groups.
Like Bandwidth Groups and Service Groups, each Application is configured with QoS
properties. In addition, an Application is associated with one or more Upstream or
Downstream Application Profiles, containing Service Levels and Rules for that Application.
Upstream Application Profiles are associated with Inroute Groups to manage Inroute traffic.
Downstream Application Profiles are associated with Outroutes to manage Outroute traffic.
An Application Service Group contains two or more Applications. (An NMS Application and a
Default Application are required for every Application Service Group.) A Remote Service
Group does not contain Applications. Instead, a Remote Service Group contains remotes and
the remotes are assigned Applications.
Service Profile
Service Profiles are only used to define Applications for Application Service Groups. They are
not used to define Applications used directly by remotes in Remote Service Groups.
Like an Application Service Group, a Service Profile contains two or more Applications, each
of which consists of the Service Levels and Rules specified by their respective Application
Profiles. You can view a Service Profile as the implementation of an Application Service
Group. In other words, an Application Service Group provides a template from which you can
create your Service Profiles.
Service Profiles are assigned directly to Remotes that use Application Service Groups. When
you assign a Service Profile to a remote, the Applications contained in the Service Profile are
applied to the remote as Virtual Remotes.
When you create a new Application Service Group, you automatically create a default Service
Profile for the new group containing the NMS and Default Applications. (These two
Applications are part of every Application Service Group and Service Profile.) When you add
Applications to Application Service Groups, those Applications are added to the list of
Applications that you can select for the Service Profiles based on that Service Group. (See
Creating Service Profiles on page 267 for further details.)
Remote Profile
Remote Profiles are used to define Applications for remotes in Remote Service Groups or
remotes that transmit a dedicated SCPC upstream carrier. Remote Profiles are not used to
define Applications used by Application Service Groups.
A Remote Profile contains one or more Applications. Each Application in a Remote Profile is
built from one or more Application Profiles. Application Profiles contain the Service Levels
and Rules defined to handle the various types of traffic in your networks.
A Remote Profile is either an Upstream Remote Profile (built from Upstream Application
Profiles) or a Downstream Remote Profile (built from Downstream Application Profiles). When
you assign a Remote to a Remote Service Group for your Network or Inroute Group, you can
select the Remote Profile to be used by the remote.
An SCPC upstream carrier is dedicated to a single remote. Therefore, a remote that transmits
an SCPC upstream carrier is not part of any upstream Service Group. You assign the Upstream
Remote Profile directly to the remote on the Remote QoS tab. (See Group QoS and SCPC
Remotes on page 239 for further details.)
Application Profile
Application Profiles are fundamental building blocks of Group QoS. They define the
Applications that are used by Service Profiles and Remote Profiles. In addition to being
configured with QoS properties that determine packet scheduling, Application Profiles contain
one or more rules that determine which packets match the type of traffic defined by the
Application Profile. Rules specify boolean operations that are performed on individual fields
in packet headers to determine whether or not packets match Applications using the
Application Profile.
An Application Profile is typically used to categorize packets for a specific traffic type, such
as NMS traffic, Voice over IP (VoIP) traffic, etc. The Default Application Profile is used to
handle any traffic not explicitly defined by the other Application Profiles in a Service Profile.
Virtual Remote
When you assign a Service Profile or a Remote Profile to a remote, you are configuring the
remote with the complete set of the Applications specified in the profile. Each individual
Application running on a remote is called a “Virtual Remote.” The physical remote makes
independent requests for bandwidth for each of its Virtual Remotes in accordance with the
properties assigned to that Application.
NOTE: The concept of Virtual Remote does not apply to Multicast Applications.
Application
Service Configured in the
Group GQoS Group View
Application 1
Added in the GQoS Application 2 Application Configured in the
Group View from Profiles Application Profiles Folder
Application Profiles
Application n
Figure 7-3 shows the Application Service Group subtree of the Group QoS hierarchy.
Applications are configured from Application Profiles and then added to the Group QoS
Application Service Group. These Applications are then used to create a Service Profile which
is assigned to remotes. The Applications in the Service Profile are implemented on the
remotes as Virtual Remotes.
Remote
Configured in the
Service
GQoS Group View
Group
Remote 1 Remote 2
Application 1 Application a
Application 2 Application b
Application n Application m
Figure 7-4 shows the Remote Service Group subtree of the Group QoS hierarchy. Remotes are
added directly to Remote Service Groups and configured with their own set of QoS properties
such as CIR, MIR, Priority, etc. Applications are configured from Application Profiles which are
used to build Remote Profiles. Remote Profiles are assigned to individual remotes. The
Applications in the Remote Profile are implemented on the remote as Virtual Remotes.
SCPC
Remote
(Upstream)
Application a
Application b
Application n
Bandwidth is allocated to the remote’s upstream Applications based on the properties and
rules defined for the selected Remote Profile. (See Remote Profiles on page 282 for
information on configuring remote profiles). Remote Profiles are assigned directly to SCPC
remotes on the Remote QoS tab. See Remote QoS Tab on page 188 for the steps to assign an
upstream Remote Profile to an SCPC remote.
NOTE: QoS Modes only apply to Application Service Groups. Selecting a QoS mode
has no effect on Remote Service Groups. When using only Remote Service Groups,
it is not necessary to select a QoS mode for your Inroute Group or Network.
When operating in Remote Based QoS mode, you will define your QoS settings much like you
did in pre-8.0 releases. In other QoS modes, or when using Remote Service Groups, you define
multiple Applications per remote. These Applications run on the physical remote as “Virtual
Remotes.” Each Virtual Remote is responsible for bandwidth allocation for its own
application.
However, in Remote Based mode, remotes do not run multiple QoS Applications. Since the
concept of multiple Virtual Remotes is not applicable in this mode, you cannot define
individual request and allocation properties for Applications. Although Group QoS can be
configured for inroute groups and networks in Remote Based mode, all Group QoS Applications
are merged into a single Application in the remote-side and hub-side remote options files.
Therefore, Application properties such as MIR, CIR and Priority defined for new QoS
Applications are not used in Remote Based mode.
This is illustrated by Figure 7-6.
When Remote Based QoS Mode is selected (top image), no properties (such as Priority and
Cost) are shown for the two Applications (NMS and Default). When Application Based is
selected, the GQoS Application Properties appear and can be configured by the operator. This
is true because Remote Based Mode collapses all Applications into a single Application that is
executed on the physical remote. To change properties such as Priority or Cost for Remote
Based traffic, configure these parameters per Service Level.
As in pre-8.0 releases, you define the QoS behavior of a remote in Remote Based mode by
creating Service Levels in QoS profiles. Service Levels contain Rules and matching criteria that
are compared in order to packets until a match is found. Once a packet matches a Rule, no
further comparisons are made.
Remote Based QoS differs from pre-8.0 QoS in that, rather than each remote being assigned a
single Traffic Profile, each remote is assigned a Service Profile derived from multiple
Application Profiles, each with its own list of Service Levels. (Application Profiles are similar
to pre-8.0 Traffic Profiles.) This means that the order in which Service Levels are applied to a
packet is determined by the order of the Applications in the Service Profile. If the packet does
not match any Service Levels in the first Application, it is compared to those in the second
Application, and so on, until a match is found. Therefore, it is very important that you add
new Applications to your Service Profiles so that the correct overall order of the Service
Levels is maintained across all Applications.
When you upgrade from a pre-8.0 release, Traffic Profiles currently assigned to remotes are
converted to Application Profiles. If you choose to upgrade to Application Service Groups,
those new Application Profiles are automatically included in new Service Profiles, and the
Service Profiles are assigned to those remotes that were using the equivalent Traffic Profiles.
(Traffic profiles not assigned to remotes are removed from the QoS folders.) After the
upgrade, you can assign these Service Profiles to remotes on the Remote QoS tab, the same
way you assigned Traffic Profiles to remotes prior to GQoS.
However, if you require a new Application Profile to be used by some of the remotes in your
network, you will need to create a new Service Profile that uses the new Application Profile,
and then assign the Service Profile to the Remotes. You must use the Group QoS feature to
create Service Profiles from Application Profiles. See the Creating Service Profiles on
page 267 for details.
remote: NMS and Default. Each additional Virtual Remote increases the processing load on the
protocol processor and the remote during bandwidth allocation.
Application Scaled mode merges the NMS and Default Virtual Remotes into a single Virtual
Remote to improve performance. This merging is performed in the hub-side and remote-side
options files; not on the GUI. Therefore, even though these two Virtual Remotes are combined
on the protocol processor and on the remote, this is not visible on the iBuilder GUI. Both the
NMS and Default Applications (and Virtual Remotes) still appear on the GQoS screens.
NOTE: Although iBuilder still allows you to configure the NMS and Default
Applications in Application Scaled mode, the Default Application properties
override the NMS Application properties for any conflicting settings. Therefore,
changing the properties of the NMS Application to be different from those in the
Default Application has no effect in this mode, and can be misleading.
NOTE: The QoS Mode selection only applies to Application Service Groups; it does
not apply to Remote Service Groups.
• There is only one Multicast Bandwidth Group per Network. Therefore you cannot clone
the Multicast Bandwidth Group, insert additional multicast Bandwidth Groups, or delete
the Multicast Bandwidth Group.
• The Multicast Bandwidth Group must contain one and only one Application Service Group.
It cannot contain any Remote Service Groups. You cannot clone or delete the default
Application Service Group in the Multicast Bandwidth Group. You cannot insert additional
Service Groups under the Multicast Bandwidth Group.
• Like other Application Service Groups, the Application Service Group in the Multicast
Bandwidth Group contains two Applications by default: NMS and Default. The NMS
application is used for outbound multicast NMS traffic.
• By default, the Multicast Bandwidth Group, its Application Service Group, and the NMS
Application are assigned Multicast priority, the highest priority setting. This setting is only
available for the Multicast Bandwidth Group, its Service Group, and multicast
Applications.
• You cannot disable MIR for the Multicast Bandwidth Group. The minimum value that you
can set for Multicast MIR is 128 kbps.
• When configuring a DVB-S2 ACM network, you can select a different Multicast MODCOD for
each Application. By default, NMS multicast traffic is sent on the Minimum MODCOD of the
DVB-S2 carrier. To prevent user multicast traffic from accidentally consuming too much
downstream bandwidth, the Multicast MODCOD of the Default Application is set to the
Maximum MODCOD of the DVB-S2 carrier. See Adding Applications to Application Service
Groups on page 264 for details.
You can create new multicast Application Profiles and add new Applications for user multicast
traffic the same way that you add applications to other Bandwidth Groups. See Configuring
Group QoS on page 244 for details.
NOTE: You can enable Multicast Fast Path when configuring your user multicast
Applications. When Multicast Fast Path is enabled, downstream multicast packets
received by a remote are forwarded directly to the Ethernet by the remote
firmware. This bypasses software processing on the remote resulting in improved
throughput. For details on configuring Multicast Fast Path Applications and
assigning them to your remotes see Configuring Remotes for Multicast Fast Path
on page 277.
• On the Remote QoS tab, you can define QoS properties for remotes using Remote Service
Groups or Application Service Groups in Remote Based QoS mode.
When you create a new Network or Inroute Group in the iBuilder Tree, the default
downstream or upstream group profile is used to automatically configure the default QoS
settings for the new bandwidth pool.
The default Group QoS configuration for a Network contains:
• Two default Bandwidth Groups, one named Multicast and one named Bandwidth
The default Group QoS configuration for an Inroute Group contains:
• A single Bandwidth Group named Bandwidth
The default Multicast Bandwidth Group contains a single default Application Service Group
named Application Service Group.
All non-Multicast default Bandwidth Groups contain two default Service Groups:
• An Application Service Group named Application Service Group
• A Remote Service Group named Remote Service Group
NOTE: When only using a single type of Service Group, you can delete the other
default Service Group. However, each Bandwidth Group is required to have at
least one Service Group of either type. Therefore, you cannot delete the last
Service Group in a Bandwidth Group.
2. When the dialog box opens, click the Group QoS tab.
and assign them to remotes that use Application Service Groups. It also allows you to assign
Remote Profiles to remotes that use Remote Service Groups.
The Group QoS User Interface has five views, described in the following sections:
• Group View
• Service Profile View
• Service Profile-Remote View
• Remote Profile View
• Remote View
To select any of the Group QoS views, right-click anywhere in the main area of the Group QoS
tab and select the view you want to display.
Group View
The Group View shows the Group QoS Hierarchy (Bandwidth Groups, Service Groups,
Applications and Remotes) and the properties associated with each group in the tree. The
Group View illustrated in Figure 7-9 shows an Inroute Group with a single Bandwidth Group
divided into one Application Service Group (Appl SG 1) and one Remote Service Group (Rmt
SG 1).
• For Rmt SG 1, all remote priorities and cost are equal. Therefore, bandwidth will be
distributed evenly to these remotes. Each remote has a CIR of 32 kbps and will never
receive more than its MIR of 128 kbps.
NOTE: In Figure 7-9, only three of five remotes in Rmt SG 1 are displayed in this
view because Maximum Remotes Displayed is set to 3. You can adjust the
maximum number of remotes displayed for each Remote Service Group by
changing the setting for Maximum Remotes Displayed and clicking the Set button.
For detailed information on all QoS properties see QoS Properties on page 230. For
information on how QoS properties are applied in the Group QoS hierarchy see Group QoS
Hierarchy on page 233.
NOTE: The Select Group drop down menu at the top of the Service Profile View,
the Remote Profile View, and the Service Profile - Remote View, allows you to
filter on the entire Bandwidth Pool, a specific Bandwidth Group, or a specific
Service Group for display in the main window.
You can assign remotes to a Remote Profile by selecting one or more the remotes and clicking
the check box of the profile in the Remote Profile-Upstream (or Downstream) pane at the
right of the screen. Clicking the Remote Profile column in the main area of the screen sorts
remotes by Remote Profile name within each Remote Service Group.
Remote View
The Remote View (Figure 7-13) shows all remotes in a Bandwidth Pool, and all Applications
and Service Levels assigned to each remote. The Remote View includes remotes in Application
Service Groups and remotes in Remote Service Groups. The Remote View groups the QoS
configuration by remote, allowing you to better understand how QoS processing will be
applied on any remote.
Figure 7-14. Configured vs. Effective MIR and CIR before Estimation
Notice in Figure 7-14 that initially the Configured MIR and CIR are equal to the Effective CIR
and MIR. By default, the calculator for the node assumes that all remotes receive the best
MODCOD of the assigned carrier.
1. Click the MODCOD Distribution button (Figure 7-14) to display the calculator
(Figure 7-15).
Figure 7-15 shows an instance of the MODCOD Distribution Calculator. The range of the
MODCOD column is limited to the DVB-S2 Range defined for the carrier assigned to this
network. The Total row shows the totals for the columns. The Network Best row shows
the configured MIR and CIR for the node.
2. Double-click the cells to enter either the percentages of traffic or the data rates that you
estimate will be transmitted on the different MODCODs for remotes under this node.
If you change the percentages in the MIR Distribution and CIR Distribution columns, the
Estimated MIR and Estimated CIR are automatically recalculated and the totals are
displayed in the Total row. If you change information rates in the Estimated MIR and
Estimated CIR columns, percentages in the MIR Distribution and CIR Distribution
columns are automatically recalculated and the new configuration totals are displayed in
the Network Best row.
Figure 7-16 shows the results of changing the percentages in the MIR Distribution and CIR
Distribution columns.
In the example in Figure 7-16, the satellite operator estimates that 20% of the remotes
typically receive 8PSK3/4, 20% receive 8PSK-5/6, and the remaining 60% receive 8PSK-8/9
(the best MODCOD defined for the carrier). The calculator maintains the configured
information rates at 512 kbps and 128 kbps while adjusting the effective information
rates to account for the traffic on the lower MODCODs.
Figure 7-17 shows the results of entering the Estimated MIR and Estimated CIR in kbps,
splitting the information rates evenly between the two best MODCODs
.
Notice in Figure 7-17 that the distribution percentages and the Network Best information
rates have been automatically adjusted to account for the variation in bandwidth
required by the different MODCODs to transmit the same information rate.
3. Click OK to save your changes.
Figure 7-18 shows the results of the following the steps in the example.
Figure 7-18. Configured vs. Effective MIR and CIR after Estimation
In the top image in Figure 7-18, the totals for the Effective MIR and Effective CIR that were
recalculated by changing the percentages in the MIR Distribution and CIR Distribution
columns (Figure 7-16) have been updated in the dialog box. In the bottom image in
Figure 7-18, the totals for the Configured MIR and Configured CIR that were recalculated by
changing the Estimated MIR and Estimated CIR columns (Figure 7-17) have been updated in
the dialog box.
The estimated MIR and CIR, not configured MIR and CIR, are displayed in the Group QoS Group
View. This is illustrated in the MIR and CIR columns for Bandwidth Group 2 in Figure 7-19.
This is the result of saving the configuration in the top image of Figure 7-18.
Although effective MIR and CIR are only estimations based on the inputs to the MODCOD
Distribution Calculator, you can use iMonitor to monitor your DVB-S2 performance and refine
these estimations over time to more accurately reflect your actual network performance. See
the iMonitor User Guide for details on monitoring your DVB-S2 networks.
Figure 7-20. Competing Service Groups without Allocation Fairness Relative to CIR
NOTE: The Allocation Fairness Relative to Bandwidth CIR check box in the Group
View (Figure 7-20) applies to competing Bandwidth Groups in this Bandwidth Pool.
Notice in Figure 7-20 that Service Group 1 has been granted 256 kbps of CIR while Service
Group 2 has been granted 128 kbps of CIR. Allocation Fairness Relative to CIR has not yet
been enabled for BWG 1. Therefore bandwidth allocation is not affected by the proportion of
CIR configured for each node and the Bandwidth % column and the Cost column are identical
for the two Service Groups.
Figure 7-21 shows the effect of selecting Allocation Fairness Relative to CIR for BWG 1.
Since bandwidth allocation is now proportional to the configured CIRs for the two nodes, the
Bandwidth % for Service Group 1 (256 kbps of CIR) is now twice that of Service Group 2 (128
kbps of CIR). Also notice that the Cost column shows that the Service Group 1 bandwidth
allocation cost is half the cost of Service Group 2.
The difference between the Configured Cost and Effective Cost is displayed on the dialog
box of the competing subnodes. Figure 7-22 shows the Configured and Effective Costs for
Service Group 1 used in this example.
For definitions of Cost and Allocation Fairness Relative to CIR, see QoS Properties on
page 230.
Figure 7-23 shows the results of selecting Allocation Fairness Relative to Nominal MODCOD
for a Remote Service Group containing two remotes with different nominal MODCODs.
Remote e8350 44444 is configured with a lower MODCOD (QPSK 3/4) than remote e8350
71217 (8PSK 8/9). This difference in nominal MODCOD is reflected in the lower effective cost
of bandwidth assigned to e8350 4444. All other things being equal, this cost adjustment
causes e8350 4444 to receive more raw satellite bandwidth (in symbols) than e8350 71217
in order to achieve the same information rate when both remotes are operating at their
nominal MODCODs.
A remote does not always receive the outbound carrier at its nominal MODCOD. When
Allocation Fairness Relative to Nominal MODCOD is enabled, the effective cost of bandwidth
is fixed based on the configured nominal MODCOD. Therefore, at a given symbol rate, the
remote’s information rate changes when the operating MODCOD of the remote changes. For
example, if a remote is operating below its nominal MODCOD, the remote’s information rate
is reduced relative to other remotes since the remote requires more bits for error correction
than at its nominal MODCOD.
Note that when Allocation Fairness Relative to Nominal MODCOD is enabled, the MODCOD
that a mobile remote receives may vary due to differences in beam quality at various
locations in the beam footprint. This can cause the information rate received by the remote
to vary even in clear sky conditions as the remote moves across the beam. This variation in
information rate can be avoided by selecting Allocation Fairness Relative to Operating
MODCOD.
Like Allocation Fairness Relative to CIR, Allocation Fairness Relative to Nominal MODCOD
and Allocation Fairness Relative to Operating MODCOD apply to both CIR bandwidth
allocation and to best-effort bandwidth allocation.
For definitions of the different types of Allocation Fairness, see QoS Properties on page 230.
For details on configuring Group QoS Service Groups, see Adding a Service Group on page 262.
For details on configuring Group QoS Applications, see Adding Applications to Application
Service Groups on page 264.
2. In the Bandwidth Group dialog box, enter a Name for the new Bandwidth Group.
NOTE: Group QoS nodes are divided into Allocation Properties and Request
Properties. (For example, see Figure 7-25.) Allocation Properties of Group QoS
nodes influence the behavior of the node on which they are configured when that
node is allocating bandwidth to its subnodes. Request Properties of Group QoS
nodes determine how the configured node requests its bandwidth.
3. Enter the properties you want to configure for the Bandwidth Group and click OK. (For
details on all Group QoS properties, see QoS Properties on page 230.)
4. When configuring Group QoS for a DVB-S2 network with CIR or MIR defined, click the
MODCOD Distribution button to estimate the effective rates for the network. See
Estimating Effective MIR and CIR for DVB-S2 Networks on page 252 for details. Configured
and effective cost are discussed in Allocation Fairness Relative to CIR on page 256.
Figure 7-26 shows a new Bandwidth Group inserted into the Group QoS tree for a Bandwidth
Pool.
A new Bandwidth Group automatically includes one Remote Service Group and one
Application Service Group containing two Applications. Properties are assigned to these
subgroups based on the configuration of the default upstream or downstream Group Profile.
(See Working with Group Profiles on page 293 for a discussion of Group Profiles.)
2. In the Service Group dialog box, enter a Name for the new Service Group.
3. Enter the properties you want to configure for the Service Group and click OK. (For
details on all Group QoS properties, see QoS Properties on page 230.)
4. When configuring Group QoS for a DVB-S2 network with CIR or MIR defined, click the
MODCOD Distribution button to estimate the Effective rates for your network. See
Estimating Effective MIR and CIR for DVB-S2 Networks on page 252 for details.
Configured and Effective cost are discussed in Allocation Fairness Relative to CIR on
page 256. Allocation Fairness Relative to Nominal MODCOD and Allocation Fairness
Relative to Operating MODCOD are discussed on page 258.
5. For Service Groups, Enable EIR for Remotes in Group applies only to DVB-S2 networks.
For Application Service Groups, it only applies to Remote Based QoS mode. It can also be
selected for Remote Service Groups in a DVB-S2 network. Select this option to allow EIR to
be configured for physical remotes on the Remote QoS tab. (See Remote QoS Tab on
page 188.)
NOTE: Selecting Enable EIR for Remotes in Group allows a network administrator
with Group QoS permissions to allow or disallow the configuration of EIR for
physical remotes per Service Group in a DVB-S2 network. It also allows the
administrator to limit the value that can be set for the EIR Minimum MODCOD on
the physical remotes.
6. If you selected Enable EIR for Remotes in Group, also select the Minimum MODCOD
Allowed for the remotes in this Service Group. The selected MODCOD is the minimum
MODCOD that can be configured for the physical remote on the Remote QoS tab.
Figure 7-28 shows a new Application Service Group inserted into a Bandwidth Group in the
Group QoS tree.
Figure 7-28. New Application Service Group Inserted Into a Bandwidth Group
A new Application Service Group automatically contains two Applications, NMS and Default.
The properties of these Applications are assigned based on the configuration of the default
upstream or downstream Group Profile. (See Working with Group Profiles on page 293 for a
discussion of Group Profiles.)
2. In the QoS Application dialog box, enter a Name for the new Application.
3. You can only select Multicast Fast Path when configuring a downstream Multicast
Application.
4. Enter the properties you want to configure for the Application in the Request Properties
and Allocation Properties areas of the dialog box. These properties determine how
bandwidth is allocated for all remotes you configure to use this Application. (For details
on all Group QoS properties, see QoS Properties on page 230.)
5. When configuring Group QoS for a DVB-S2 network with CIR or MIR defined, click the
MODCOD Distribution button to estimate the Effective rates for the network. See
Estimating Effective MIR and CIR for DVB-S2 Networks on page 252 for details.
Configured and Effective cost are discussed in Allocation Fairness Relative to CIR on
page 256. Allocation Fairness Relative to Nominal MODCOD and Allocation Fairness
Relative to Operating MODCOD are discussed on page 258.
6. Enable EIR for Remotes in Application applies only to DVB-S2 networks in Application
Based (or Application Scaled) QoS mode. Select this option to configure EIR for Virtual
Remotes using this Application.
7. If you selected Enable EIR for Remotes in Application, also select the Minimum MODCOD
Allowed. The selected MODCOD is the minimum MODCOD that can be configured for
remotes using this Application.
8. When configuring a Multicast Application for a DVB-S2 network, the Allocation Properties
display the Multicast MODCOD (Figure 7-30) rather than an EIR Minimum MODCOD. Select
a Multicast MODCOD for your Multicast Application.
9. In the Application Profiles area of the dialog box, select each Application Profile you
want to include in this Application. Each Application is specified by one or more
Application Profiles configured in the Application Profiles folder. (See section Adding an
Application Profile on page 304 for details.)
NOTE: You can use the arrow buttons to change the order of the
Application Profiles within an Application. First, select an Application Profile;
then click the buttons to move the Application up or down in the list.
NOTE: The order of Application Profiles within your Applications is important for
two reasons. First, once a rule in an Application Profile matches a packet, no
further classification of the packet is performed. Second, placing high-volume
Application Profiles higher in the list will reduce the amount of processing time
used to check seldom-matched rules.
10. Click OK when you have finished defining the Application.
Figure 7-31 shows a new Application for TCP inserted into an Application Service Group in the
Group QoS tree.
3. In the QoS Service Profile dialog box, select each Application you want to add to the
Service Profile. If the Application contains more than one Application Profile, you can
individually select which Application Profiles you want to include.
4. Click OK to save the Service Profile and return to the Group QoS tab.
NOTE: You can use the Add and Delete buttons (shown in Figure 7-32) to insert
Applications into the Service Group or remove Applications from the Service
Group without returning to the Group View.
Group. You might then define an MIR of 100 kbps for the Application in a Service Profile to
limit each remote using that Service Profile to 100 kbps for that Application.
Follow these steps to configure the QoS properties assigned to Virtual Remotes:
1. Right-click anywhere on the Group QoS tab and select Service Profile View from the
menu.
2. Under the Service Profile you want to change, right-click an Application and select
Modify from the menu.
3. In the Request Properties area of the dialog box, modify the properties you want to
change.
4. In the Allocation Properties, the EIR section of the dialog box applies only to DVB-S2
outbound carriers with ACM enabled. EIR is only enabled within the range defined by the
carrier’s Maximum MODCOD and the Minimum MODCOD entered here. (See page 231 for
the definition of EIR. See page 78 for details on configuring the MODCOD range of your
DVB-S2 carriers.)
5. Select Apply to All only if you want to apply these settings to all Virtual Remotes using
this Application. This will remove any overrides that were previously configured for
individual Virtual Remotes. If you do not select Apply to All, previously-defined overrides
are retained. (See Overriding Application Properties on Individual Remotes on page 275.)
6. Click OK to save your changes.
You cannot configure a remote with more than one NMS or Default Application. If you choose
to assign multiple Service Profiles to a single remote, the NMS and Default Applications of the
new Service Profile will be applied to the remote in place of the NMS and Default Applications
that were previously applied. When you remove a Service Profile from a remote which had
multiple profiles assigned, then if the NMS and Default Applications were applied from that
profile, the remote will be re-assigned the NMS and Default Applications of the first Service
Profile in the Group QoS Profile View that is still assigned to the remote. Applications other
than NMS and Default should be unique across all Service Profiles assigned to a remote. If not,
only one of the identical Applications will be selected, overriding the duplicate Application.
Normally, an operator assigns Service Profiles to individual remotes on the Remote QoS tab.
(See Remote QoS Tab on page 188 for details.) Service Profiles assigned to a Remote are
displayed in the Upstream QoS and Downstream QoS sections of that tab. Figure 7-34 shows
two Service Profiles (SP 1 and SP 2) assigned to a single remote for an Inroute Group. (The
Service Profile shown in bold—called the Primary Service Profile—contains the NMS and
Default Applications applied to this remote.)
The remainder of this section describes how to assign Service Profiles to remotes from the
Group QoS Service Profile-Remote View. This method can be used by a Group QoS
administrator as an alternative to assigning Service Profiles to individual remotes on the
Remote QoS tab.
2. Right-click anywhere in the Service Profile-Remote View and select Expand Tree to view
the current Service Profile assignments.
3. Right-click the Service Profile you want to assign and select Assign/Unassign Remote.
4. In the Remote Select dialog box (Figure 7-35), select the remote or remotes you want to
assign. Use Ctrl-click or Shift-click to select multiple remotes.)
NOTE: You can also change the Service Profile assignments of remotes by
selecting remotes in the Service Profile-Remote View and dragging the remotes
between Service Profiles. Figure 7-36 shows remote e8350 32132 being dragged
from Appl Service Group 1/SP 1 to Appl Service Group 2/SP 2.
2. Under the Service Profile you want to change, right-click a Virtual Remote and select
Modify from the menu.
3. In the Request Properties area of the Properties dialog box, modify the properties you
want to change.
4. In the Allocation Properties area of the dialog box, you can override the EIR Minimum
MODCOD setting on the outbound for a remote receiving a DVB-S2 outbound. See
Configuring Application Properties for Remotes on page 269 for details.
5. Click OK to save your changes to the Virtual Remote.
2. In the Group View of the Group QoS tab for your network, right-click an existing
Application in the Application Service Group of your Multicast Bandwidth Group and
select Insert.
Figure 7-39. QoS Application Dialog Box: Selecting Multicast Fast Path
5. Configure the remaining QoS properties for your Application as described in Adding
Applications to Application Service Groups on page 264.
6. In the Application Profiles area of the QoS Application dialog box (Figure 7-40), select
the downstream multicast Application Profile that you configured in Step 1.
Figure 7-40. Selecting a Fast Path Application Profile for a Multicast Application
7. Click OK to add the Multicast Fast Path Application to the Multicast Bandwidth Group and
return to the Group View.
8. In the Group View, double-click the Profiles folder for the Multicast Service Group to open
the Service Profile View for the Multicast Application Service Group.
NOTE: If this is the first Multicast Service Profile configured for your network, the
Service Profile View for the Multicast Service Group will be empty.
9. If the Service Profile View is empty (Figure 7-42, left image), right-click anywhere in the
main window and select Insert from the menu. If there are existing Multicast Service
Profiles (Figure 7-42, right image), right-click an existing Service Profile and click Insert.
Figure 7-42. Inserting a Multicast Service Profile into the Multicast Service Group
Figure 7-43. Selecting a Fast Path Application for a Multicast Service Profile
15. In the Remote Select dialog box, select the Available Remotes (on the left) to which you
want to assign the Multicast Fast Path Service Profile.
16. Click the single arrow in the center of dialog box to move those remotes into the Assigned
Remotes area (on the right) of the dialog box.
17. Click OK to save the remote assignments and return to the Service Profile Remote View.
18. Click OK to save the Group QoS changes for your network. You should see changes pending
on your network and hub-side changes pending on your remotes.
NOTE: Operators can also assign remotes to Multicast Service Groups on the
Remote QoS Tab. See Remote QoS Tab on page 188 for details.
20. Add a persistent multicast groups to your network for each VLAN (including the default
VLAN) configured by the Multicast Fast Path Application to carry the Multicast Fast Path
packets. Adding a Network on page 118 contains the steps for adding persistent multicast
groups to a network. For a complete description of multicast support in iDirect, see the
Technical Note titled IP Multicast in iDirect Networks.
NOTE: A remote will always forward Multicast Fast Path packets to the local LAN,
even if a persistent multicast group is not configured for the eth0 interface of the
remote. However, you should configure a persistent multicast group for your
Network to ensure that the protocol processor forwards the multicast packets to
the transmit line card for transmission on the downstream carrier.
Remote Profiles
A Remote Profile contains one or more Applications. Each Application in a Remote Profile is
built from one or more Application Profiles. Application Profiles contain the Service Levels
and Rules defined to handle the various types of traffic in your networks. (See Adding an
Application Profile on page 304 for details on creating and editing Application Profiles.)
Remote Profiles are created in the QoS folder of the iBuilder Tree under the Remote Profiles
folder. Two subfolders named Downstream and Upstream contain the Remote Profiles that
you can assign for your Networks and Inroute Groups, respectively. Figure 7-45 shows an
example of the Remote Profiles folder in the iBuilder Tree.
By default, there are two preconfigured Remote Profiles: Default Downstream Profile and
Default Upstream Profile. These default profiles are built from the NMS and Default
Application Profiles described on page 302. You can assign default Remote Profiles to your
remotes, but you cannot change them or delete them.
You can add, clone, modify and delete Remote Profiles in the same way that you perform
these operations for other profiles in the QoS folder. For instructions on how to perform these
operations, see page 302.
Remote Profiles are configured in the Upstream and Downstream Remote Profile dialog boxes.
An example of the Upstream Remote Profile dialog box is shown in Figure 7-46.
As shown in Figure 7-46, the Remote Profile dialog box is divided into three sections.
In the top section of the dialog box, you can add new Applications and Application Profiles to
the Remote Profile. You also can drag the Applications or Application Profiles to change their
order. The order of the Applications and Application Profiles determines the order in which
the Service Levels are applied on Remotes assigned to this Remote Profile. Figure 7-46 shows
a Remote Service Group with two Applications, each containing two Application Profiles. The
QoS properties configured for the Applications are shown in the columns on the right.
The Service Levels pane of the dialog box shows the Service Levels configured for the
selected Application Profile. In Figure 7-46, the NMS Application Profile is selected in the top
section of the dialog box. Therefore, the Service Levels configured for the NMS are displayed
in the Service Levels section.
The Used By pane of the dialog box shows all remotes assigned to this Remote Profile. For
upstream profiles such as the one in figure Figure 7-46, the Inroute Group for each remote is
displayed in the second column. For downstream profiles, the Network containing each
remote is displayed in the second column.
You can perform the following operations on your Remote Profile:
• Add, Delete and Modify Applications
• Insert Application Profiles into Applications
• Delete Application Profiles from Applications
• Rearrange the order of Applications and of Application Profiles within Applications
• Move Application Profiles between Applications
The following rules apply when creating Remote Profiles
• Each Application in the Remote Profile must contain at least one Application Profile.
• The NMS Application Profile must be included in one Application within the Remote
Profile.
• The same Application Profile cannot be included more than once in a Remote Profile.
• The last Application Profile in the last Application of a Remote Profile must be the Default
Application Profile.
A new Remote Profile automatically contains a single Application built from the NMS and
Default Application Profiles.
2. Enter a Profile Name for your Remote Profile.
3. To add a new Application or Modify an existing Application:
a. Right-click an Application and select Add Application or Modify from the menu.
NOTE: You can drag Applications to rearrange their order within a Remote Profile.
b. In the Choose Application Profile dialog box, select the Application Profile you want
to add to the Application.
NOTE: You can drag Application Profiles to rearrange their order within an
Application.
Figure 7-52. Assigning a Remote Service Group on the Remote QoS Tab
This remainder of this section describes how to assign Remotes to Remote Service Groups
from the Group QoS Remote Profile View. This method can be used by a Group QoS
administrator as an alternative to assigning Service Profiles to individual remotes on the
Remote QoS tab.
To assign Remotes to a Remote Service Group:
1. Right-click anywhere in the Group QoS tab of a Network or Inroute Group and select
Remote Profile View from the menu.
2. Right-click anywhere in the Remote Profile View and select Expand Tree to view the
current Remote Service Group assignments.
3. Right-click the Service Profile you want to assign and select Assign/Unassign Remote.
4. In the Remote Select dialog box (Figure 7-53), select the remote or remotes you want to
assign. Use Ctrl-click or Shift-click to select multiple remotes.
NOTE: The Remote Profile column shows the Remote Profile assignments for all
remotes in the Remote Profile view. You can click the column header to sort by
Remote Profile within each Remote Service Group. In Figure 7-54, the last remote
displayed has not yet been assigned a Remote Profile.
NOTE: You can also change the Remote Service Group assignments of remotes by
selecting remotes in the Remote Profile View and dragging the remotes between
Remote Service Groups. Figure 7-55 shows remote e8350 42132 being dragged
from Remote Service Group 1 to Remote Service Group 2.
5. In the Modify Configuration Object dialog box, click the Custom Tab. Then add a custom
key to the Hub-Side Configuration pane in the following format:
[UPSTREAM_VR_#]
full_cir_trigger = 1
where # is the Virtual Remote number determined in Step 3. Figure 7-57 shows the
custom key required to enable Full-Trigger CIR for Virtual Remote 2 on the remote being
configured.
iBuilder Tree, iBuilder automatically assigns the Default Upstream Profile to the new Inroute
Group. The contents of the default Group Profiles are described in Configuring Group QoS on
page 244. You can modify the default Group Profiles, but you cannot delete them.
2. Right-click anywhere in the Group View and select Save to Profile to display the QoS
Group Profile dialog box.
3. In the QoS Group Profile dialog box, enter a name for your new Group Profile.
4. You can view the properties of the various group members before saving the Group
Profile. To see the properties of a Bandwidth Group, Service Group or Application, select
its icon in the Group Hierarchy pane. The properties of that group member appear in the
Group Members pane.
5. To save the Group Profile, click OK in the QoS Group Profile dialog box. Then click OK in
main screen of the Group QoS tab.
Inroute Group QoS profiles are saved in the QoSGroup ProfilesUpstream folder of the
iBuilder Tree. Network Group QoS profiles are saved in the QoSGroup
ProfilesDownstream folder of the iBuilder Tree.
2. In the Modify Configuration Object dialog box, enter a Profile Name for the new Group
Profile.
3. If desired, you can make changes to the Group Profile before you save it. See Configuring
Group QoS on page 244 for details on modifying the Group QoS configuration.
NOTE: Only the Group View and Service Profile View are available when working
with Group Profiles. The Service Profile-Remote View, Remote Profile View, and
Remote View, which appear on the Group QoS tab, are not applicable to Group
Profiles.
2. In the Modify Configuration Object dialog box, make the desired changes to the Group
QoS configuration. See Configuring Group QoS on page 244 for details on modifying the
Group QoS configuration.
NOTE: Only the Group View and Service Profile View are available when working
with Group Profiles. The Service Profile-Remote View, Remote Profile View, and
Remote View, which appear on the Group QoS tab, are not applicable to Group
Profiles.
4. Right-click anywhere in the Group View and select Create From Profile to display the
QoS Group Profile dialog box.
5. In the QoS Group Profile dialog box, select the Group Profile you want to use for this
Bandwidth Pool. (Only Upstream Group Profiles can be selected for Inroute Groups. Only
Downstream Group Profiles can be selected for Networks.)
6. You can view the properties of the various group members before applying the Group
Profile to the Bandwidth Pool. To see the properties of a Bandwidth Group, Service Group
or Application, select its icon in the Group Hierarchy pane. The properties of that group
member will appear in the Group Members pane.
7. When finished, click OK in the dialog box. Then click Yes in the confirmation dialog box to
replace the Group QoS configuration.
8. When using Application Service Groups, follow the steps in Assigning Service Profiles to
Remotes on page 271 to assign remotes to Service Profiles based on the Application
Service Groups of the new configuration.
9. When using Remote Service Groups, follow the steps in Assigning Remotes to Remote
Service Groups on page 288 to assign remotes to Remote Service Groups.
10. When finished, click OK at the bottom of the Group QoS tab to save your changes.
NOTE: Remote Profiles are built from Application Profiles. Remote Profiles are
discussed in detail in Remote Profiles on page 282.
Application Profiles define the Group QoS Applications that you add to your Service Profiles or
Remote Profiles. You then assign the Service Profile or Remote Profile to your remotes using
the Group QoS tab for your Bandwidth Pools or the QoS tab for your remotes. (See Configuring
Group QoS on page 244 for details.)
Filter Profiles encapsulate a single filter definition. A Filter Profile contains a group of rules,
but no Service Levels. Filter Profiles are assigned on the Remote QoS tab.
Application Profiles, Remote Profiles and Filter Profiles are stored in separate folders in the
iBuilder Tree. They are not associated with a teleport; instead they are independent of any
network hierarchy, similar to spacecraft and antenna components. Figure 7-65 shows the
folders that store these profiles.
iBuilder contains a number of pre-configured Profiles to help you define various categories of
traffic. You can modify these pre-configured profiles to meet your needs; copy them to use as
templates for new profiles; or create your own profiles. A typical list of Downstream Filter
Profiles in the iBuilder Tree is shown in Figure 7-66.
Preconfigured Application Profiles (Default Downstream, Default Upstream and NMS) are
automatically added to your Networks or Inroute Groups when created.
A Modify Configuration dialog box opens to allow you to configure the profile you are adding.
Details are discussed in Adding an Application Profile on page 304 and Adding a Filter Profile
on page 308. Adding Remote Profiles is discussed in Adding a Remote Profile on page 284.
Once a Profile is configured and saved, it is added to the iBuilder Tree within its respective
folder. Figure 7-67 shows Group QoS Downstream Application Profiles in the iBuilder Tree.
NOTE: When a profile is being used, the icon in the iBuilder Tree is colored red
and the name is displayed in bold typeface.
If you select Clone As, the Clone As dialog box opens. The Clone As dialog box allows you
select a Direction for the copy of your profile. By selecting a Direction, you can copy a
Downstream profile to the Upstream folder, or an Upstream Profile to the Downstream folder.
NOTE: Clone As is not available for Group QoS Profiles or Remote Profiles. You
cannot copy Group Profiles or Remote Profiles between the Upstream and
Downstream folders.
You can also modify or copy an existing profile by right-clicking the profile and selecting Modify Item, Clone or Clone As from the menu. Clone creates a copy in the current folder.
Clone As allows you to copy profiles between the Downstream and Upstream folders.
2. After you have selected the operation you want from the menu, a dialog box opens.
(Figure 7-69 shows an Upstream Application Profile with multiple Service Levels. New
Application Profiles will be empty.)
Each Application Profile contains one or more Service Levels. Each Service Level can have
multiple Rules. When you select a Service Level in the Service Levels pane of the dialog
box, all Rules associated with that Service Level are displayed in the Rules pane.
The Used By pane shows which network elements and QoS groups are using this
Application Profile. For upstream Application profiles, remotes, Inroute Groups, Remote
Profiles and Service Profiles are displayed. For downstream profiles, remotes, Networks,
Remote Profiles and Service Profiles are displayed.
3. You can Add, Edit or Delete Service Levels by selecting the Service Level and clicking the
appropriate button. Figure 7-70 shows the Add Service Level dialog box. The Edit
Service Level dialog box is identical.
NOTE: TCP acceleration only works for IPv4 TCP packets. TCP acceleration is not
available for IPv6 traffic transported over an L2oS network.
7. By default, TDMA slots used by an application are grouped together in the frame for
transmission. If you select Reduce Jitter, the system will attempt to distribute the slots
as evenly as possible across the frame. Reduce Jitter should be selected for VoIP
applications. However, since it can decrease throughput, it should not be selected for
applications that are not jitter-sensitive.
8. Select or clear Drop Oldest First.
9. Select Trigger Wakeup to cause remotes to automatically exit Sleep Mode to transmit
incoming LAN packets on the upstream carrier if the packets match the Service Level
definition. Trigger Wakeup applies only to upstream profiles, and affects only remotes
that have Sleep Mode enabled. (See Adding Remotes on page 160.)
10. Select Trigger State Change to cause remotes to automatically change from the Idle
State or Dormant State to the Active State when incoming packets for transmission on the
upstream carrier match the Service Level definition. (See Configuring Minimum
Information Rate and Idle and Dormant States on page 194.)
11. Select the method of Optimization for traffic matching this Service Level. Selecting
Maximum Efficiency instructs the software to allocate bandwidth as efficiently as
possible. Selecting Minimum Latency instructs the software not to hold onto partially
filled TDMA bursts but to release them immediately. For more details, see the chapter
titled “QoS Implementation Principles” in the iDirect Technical Reference Guide.
12. Select the method of Scheduling to be used for this Service Level: Priority Queue, Cost-
Based, or Best Effort. If you select Priority Queue, then select the priority level from the
menu. If you select Cost-Based, then enter a cost value. For details on each scheduling
method, see the discussion of packet scheduling in the chapter titled “QoS
Implementation Principles” in the iDirect Technical Reference Guide.
13. Enter the Queue Depth.
14. Choose the Type of Service Marking you want.
15. Click OK to save this Service Level.
16. Use the Add, Edit and Delete Buttons in the Rules Pane to configure Rules for your
Service Profile. The steps for configuring Rules are covered in Adding a Rule to an
Application Profile or Filter Profile on page 309.
2. In the Filter Profile dialog box, click the Add button in the Rules pane to display the Add
Filter dialog box.
3. Follow the steps in Adding a Rule to an Application Profile or Filter Profile on page 309 to
configure a rule for this Filter Profile.
NOTE: There is a limit of 63 QoS service rules. If more than 63 service rules are
configured in iBuilder, the additional service rules are not honored. Traffic
matching these rules is classified as default traffic instead of priority traffic.
4. When you have finished adding Rules, click OK in the Filter Profile dialog box to save the
Filter Profile.
In the profile dialog box, the Rules pane displays all Rules configured for the Service Level
selected in the Service Level pane, along with the name of the selected Service Level. In the
Filter Profile dialog box, the Rules pane displays all Rules configured for the Filter Profile.
(See Adding an Application Profile on page 304 and Adding a Filter Profile on page 308 for
more details.)
When you select or clear the Show Protocol Names check box at the bottom of the dialog
box, the Rules pane toggles the displayed Rules between protocol names and numbers.
Figure 7-75 shows the result of selecting the check box (top) and of clearing the check box
(bottom) in the profile dialog box. Application and Filter Profile dialog boxes both provide the
same capability.
Figure 7-75. Selecting and Clearing the Show Protocols Name Check Box
Follow these steps to add a new rule for an Application or Filter Profile.
NOTE: Classifiers marked L2oS only in the descriptions below are used to classify
Ethernet frames in Layer 2 networks. These classifiers are not applicable to Layer
3 IPv4 networks. Other classifiers can be used in both Layer 2 and Layer 3
networks.
1. Click the Add button in the Rules pane to display the Add Rule dialog box.
NOTE: When specifying rules, all comparisons specified (as indicated by the check
boxes on the left-hand side of the dialog box) must match for the rule to match a
packet.
2. Select the check boxes at the left to enable packet header fields for comparison by the
rule or filter. Then define the values and operators for each comparison as follows:
• Source IP and Destination IP address and Subnet Masks: The IP header field may be
equal to (=) or not equal to (<>) the value entered. The subnet mask is first applied to
the IP address in the packet, and then compared to the address specified in the filter.
• Source IPv6 and Destination IPv6 address and Subnet Masks (L2oS only): To enter an
IPv6 IP address:
• Select Source IPv6 or Destination IPv6 in the IP address drop-down list.
• Enter a valid IPv6 address / network prefix size (Figure 7-77).
• Source and Destination Port Ranges: Enter port range and mask. Select Same as
Source to configure the Destination Port Range to be identical to the Source Port
Range.
• SVN ID (L2oS only): This field refers to the SVN ID of the Ethernet frame. One or two-
part SVN IDs are allowed. Two-part SV IDs are used for QinQ tagging.
• SVN PCP (L2oS only): This field refers to the PCP (Priority Code Point) field of the SDT
in an Ethernet frame.
• DSCP, TOS, Precedence: If you select DSCP you cannot select TOS or Precedence. If
you select TOS or Precedence you cannot select DSCP.
• Protocol: The protocol of the packet can equal to (=) or not equal to (<>) the selected
protocol.
• Ethernet Type (L2oS only): This field refers to the outer-most Ethertype of the
Ethernet frame.
• Effective Ethernet Type (L2oS only): This field refers to the inner-most Ethertype
contained in the Ethernet frame.
• VLAN PCP (L2oS only): This field refers to the PCP field of the VLAN tag after the SDT
headers are removed.
• VID Ranges: VID Ranges can be equal to (=) or not equal to (<>) the value entered.
3. Click OK to save the filter or rule.
NOTE: If you do not know if the chassis has an EDAS or MIDAS controller board,
attempt to follow Step 1 through Step 6 in Setting the IP Address for a Chassis
with a MIDAS Controller Board on page 314. If you have an EDAS controller board,
you will not be able to log on to the board using the MIDAS procedure.
CAUTION: Do not click the “Write Ethernet Address” Button. The Ethernet
Address field should never be modified.
13. Reset the EDAS board either by powering the hub chassis off and on, or by resetting only
the EDAS board.
NOTE: To reset the EDAS board without powering down a 20 slot chassis, remove
the EDAS board cover and disconnect and reconnect the power connector to the
board itself. To reset the EDAS board without powering down a four slot chassis,
press the “EDAS Reset” button on the chassis control module.
4. Configure a serial terminal program (such as Tera Term under Windows or Minicom under
Linux) to match the serial settings on the MIDAS control module. The default settings are:
• Baud rate: 57600
• Data bits: 8
• Parity: None
• Stop bits: 1
• Flow Control: None
5. Press Enter in the terminal program to display the MIDAS login: prompt.
6. At the MIDAS login: prompt, type the MIDAS administrative login name and press Enter.
(The default administrative login name is admin.)
7. At the Password > prompt, type the administrative password and press Enter. (The
default administrative password is admin.)
8. To display the current IP settings, enter the command:
show ip config
9. At the admin > command line prompt, enter the command:
set ip <n.n.n.n>
where <n.n.n.n> is the IP address. For example, to set the IP address to 172.17.2.50,
enter the command set ip 172.17.2.50.
10. Enter the command:
set mask <n.n.n.n>
where <n.n.n.n> is the subnet mask. For example, to set the subnet mask to
255.255.255.0, enter the command set mask 255.255.255.0.
11. Enter the command:
set gateway <n.n.n.n>
where <n.n.n.n> is the gateway IP address. The default gateway should be your
upstream router. For example, to set the gateway IP address to 172.17.2.1, enter the
command set gateway 172.17.2.1.
12. Enter the command:
reboot
The new IP settings will take effect on completion of the reboot.
13. To verify the IP settings, log on again and enter the following command:
show ip config
NOTE: A hub line card must be assigned to a licensed chassis slot before it can be
activated.
A line card can be assigned to any free slot.
Until a line card is assigned to slot, the line card will be in the “incomplete” state
in the iBuilder Tree.
For information on licensing the chassis, see the iDirect Features and Chassis Licensing Guide
available on the TAC web page.
The Chassis dialog box opens, containing one row for each slot and jumper. Rows are
arranged from top to bottom to mirror the chassis slots from left to right.
2. If the chassis license has not been imported into iBuilder, follow the procedure in
Importing License Files on page 60.
3. Enter a Name for the new chassis.
4. Enter the six-digit Serial Number of the chassis and click the Validate SN button. The
Serial Number entered must match a chassis serial number in the chassis license file.
Once iBuilder has validated the chassis serial number, the read-only IP Address of the
chassis is displayed and all licensed slots and jumpers change from Off - Not Licensed to
Off - Licensed.
Figure 8-2. Chassis Dialog Box: 20-Slot Chassis with Licensed Slots
NOTE: The IP Address displayed in the Chassis Dialog Box must match the IP
Address configured for the chassis. See Configuring the Chassis IP Address on
page 313.
NOTE: Select Free to indicate that no modems are installed in that slot. These
associations must reflect the actual physical layout of the chassis; iBuilder cannot
map logical associations to physical line card locations.
8. When you select Assign Hub, a drop-down list appears in the row, listing all of the line
cards that can be assigned to that slot. Select the line card installed in that slot.
9. Click OK to save the changes. iBuilder will display “Changes Pending” for the Chassis in
the iBuilder Tree.
10. To activate the changes, right-click the Chassis and select Apply Configuration.
All chassis slots are powered on by default when the chassis is powered on. For this reason,
the configuration database is the sole keeper of slot power and jumper settings. When the
configuration server starts up, or after a reconnection to the chassis, it automatically applies
the chassis settings stored in the database, thus restoring the desired chassis state.
The Chassis dialog box opens, containing one row for each slot and jumper. Rows are
arranged from top to bottom to mirror the chassis slots.
Figure 8-6. Chassis Dialog Box: Four-Slot Chassis with Licensed Slots
NOTE: The IP Address displayed in the Chassis Dialog Box must match the IP
Address configured for the chassis. See Configuring the Chassis IP Address on
page 313.
4. If the chassis contains a Reference Clock Module (RCM), select RCM Installed.
5. The Chassis Information area of the dialog box (see Figure 8-5) displays status
information about the IF Module (IFM) and Outdoor Power Modules (OPM) received from
the chassis.
6. The OPMs have the following configurable options:
a. Select BUC Voltage On to enable BUC voltage. These settings should be the same for
OPM A and OPM B.
b. Select LNB Voltage On to enable LNB voltage. These settings should be the same for
OPM A and OPM B.
NOTE: A four-slot chassis with four RF ports can only supply DC voltage to a BUC
or LNB on RF port 1. It cannot supply voltage on RF port 2, 3 or 4.
c. Select 22 kHz Tone On to enable the 22 kHz tone option. The 22 kHz tone capability
is for use with DiSEqC-compatible Universal LNBs. If this option is selected for one
OPM, it cannot be selected for the other.
d. If you have selected LNB Voltage ON, select one of the OPM-AB LNB Voltage options:
• Select Low to enable low LNB voltage (+14VDC at 500 mA)
• Select High to enable high LNB voltage (+19VDC at 500 mA). Typically, High is
selected. This is the default, standard setting.
7. The procedure to power on the slots, assign the line cards and set jumpers 1 through 3 is
identical to the procedure for a 20-slot chassis. Jumper 4 is controlled by the software.
See Configuring and Controlling the Hub Chassis on page 316 for details on assigning line
cards to slots and setting the jumpers.
8. You can configure line cards in a four slot chassis to supply the 10 MHz clock to the
upconverter, the downconverter, or both. Note the following:
• You must select ODU Tx 10 MHz on the upconverter screen or ODU Rx 10 MHz on the
downconverter screen for these selections to appear in the menu. See Adding an
Upconverter or Downconverter on page 70 for details.
• Only one line card per upconverter or downconverter can be selected for this
function. The upconverter and downconverter associated with each line card in this
chassis are shown in the Hub Assignment column.
• This feature is available on the following line card model types: eM1D1 (Tx and Rx);
XLC-11 (Tx and Rx); XLC-10 (Tx only); and XLC-M (Rx only).
To turn on or off the 10 MHz reference from a line card, right-click in the Tx-10 MHz
column (for the upconverter) or Rx-10 MHz column (for the downconverter) in the slot
containing the line card. Then select 10 MHz On/Off from the menu. The 10 MHz setting
will toggle between off and on.
9. Click OK to save the changes. Elements requiring update will show changes pending in the
iBuilder Tree.
10. Apply the changes to the chassis and line cards as required.
NOTE: When changing the 10 MHz clock source from one line card to another,
apply the line card changes to the original clock source to turn off the 10 MHz
before applying the line card changes to the new clock source.
NOTE: Only 20 slot chassis can be shared among multiple Network Management
Systems. Four slot chassis cannot be shared.
When multiple Network Management Systems share one or more chassis, a single NMS Chassis
Manager Server (CM Server) controls all access to the chassis. All NMS configuration servers
that share the chassis share the single CM Server.
The CM server only allows access to chassis slots that have been licensed by iDirect. An HNO
can share licensed slots with additional NMS configuration servers by including the MAC
addresses of the configuration server machines in a CM server configuration file named
para_cfg.opt.
Figure 8-8 on page 322 shows an example of an HNO NMS sharing a 20 slot chassis with VNO1
NMS and VNO2 NMS.
Figure 8-8. Sharing a Hub Chassis Among Multiple Network Management Systems
To share the chassis, the HNO first determines where to run the common Chassis Manager
Server and configures the HNO NMS accordingly. (For details on how to distribute the NMS
server processes across multiple server machines, see Configuring a Distributed NMS Server
on page 453.) The HNO must also obtain a chassis license from iDirect and use iBuilder to
import the license file. (See Importing License Files on page 60.)
Once the chassis is licensed, the HNO modifies the configuration file para_cfg.opt on the
Chassis Manager Server to allow the VNO NMS configuration servers to access specific chassis
slots. This is accomplished by adding the MAC address of the VNO’s NMS configuration server
machine for each slot that the VNO is allowed to access.
An excerpt from para_cfg.opt is shown in the upper left of Figure 8-8. In the figure, VNO 1 can
access slots 1 through 4 of the chassis with IP address 172.20.136.6, while VNO 2 can access
slot 5 through 8 of the chassis with IP address 172.20.136.6.
NOTE: SSH can not be used to log on directly to the root account of an NMS server
or Protocol Processor blade. Instead, use SSH to log on to another account such as
the iDirect account. Then enter su - from the command line to log on as root.
2. Stop the NMS services on the server by entering the following command:
service idirect_nms stop
3. Run the script attach_extern_cm2nms.pl by entering the following command:
/home/nms/utils/db_maint/attach_extern_cm2nms.pl -db=nms
-xip=<ip address>
where <ip address> is the IP address of the external CM server machine.
4. Answer yes at the prompt:
Do you want to change Chassis Manager location?(yes/no)
5. Answer no at the prompt:
NOTE: SSH can not be used to log on directly to the root account of an NMS
server or Protocol Processor blade. Instead, use SSH to log on to another
account such as the iDirect account. Then enter su - from the command line
to log on as root.
The 20 slot chassis in Figure 8-10 has Serial Number 700100 and IP address 192.168.76.16.
The rows for each slot contain the MAC addresses of the NMS configuration server
machines that can access the chassis. Zeros in a slot MAC address mean that the slot can
only be accessed by the licensed NMS.
5. For each slot you want to share with NMS 2, replace the zero MAC address with the MAC
address of the machine running NMS 2’s configuration server.
In Figure 8-11, slots 1 and 2 of the chassis with serial number 700100 have been
reconfigured for sharing with a configuration server machine whose MAC address is
00:14:5E:17:A8:AC.
NOTE: You can enter more than one MAC address per slot. Separate each address
with a semicolon. For example: slot_1 = 00:11:25:A9:38:1E;00:21:52:C3:22:22
means that two additional configuration servers can access slot 1 of this chassis.
6. Once you have added the MAC address for each slot you want to share, save the file and
exit the editor.
7. Enter the command:
ssh <ip address>
where <ip address> is the IP address of the server running the NMS chassis manager
process.
8. Enter one of the following commands:
telnet localhost <port number>
or
telnet 0 <port number>
9. At the Username prompt, log on to the chassis manager admin account. (The default
password is iDirect. Change this password.)
10. Update the Chassis Manager with the new configuration by entering the command:
update
11. Return to the NMS server machine by entering the command:
exit
12. Log off of the NMS server machine.
Make sure the Serial Number and any other common chassis parameters (such as RCM
Installed) are identical to the configuration on NMS 1.
3. Save the chassis in iBuilder.
4. Right-click the chassis in the iBuilder Tree and apply the chassis configuration.
You can now configure line cards on NMS 2 and assign those line cards to the slots you
configured for access from NMS 2’s configuration server MAC address.
NOTE: You can control which operations a VNO user on NMS 2 can perform on the
chassis by setting VNO access rights on the chassis and slots in NMS 2’s database.
For more information see Sharing a Chassis Among Multiple VNO User Groups on
page 398.
2. Log on to the root account of the NMS server machine that is running the Chassis Manager
Server.
NOTE: SSH can not be used to log on directly to the root account of an NMS server
or Protocol Processor blade. Instead, use SSH to log on to another account such as
the iDirect account. Then enter su - from the command line to log on as root.
Figure 8-12 contains an excerpt from para_cfg.opt. In the figure, the chassis with Serial
Number 700100 has an IP address of 192.168.76.16.
6. Change the IP address of the chassis to the new IP address.
7. Save the file and exit the editor.
8. Enter the command:
ssh <ip address>
where <ip address> is the IP address of the server running the NMS chassis manager
process.
9. Enter one of the following commands:
telnet localhost <port number>
or
telnet 0 <port number>
10. At the Username prompt, log on to the chassis manager admin account. (The default
password is iDirect. Change this password.)
11. Update the Chassis Manager Server with the new IP address by entering the command:
update
The term Activation Pending is displayed in red text to the right of the remote being
activated. The term Changes Pending is displayed in red text to the right of its
corresponding network. For other states, see Step 4 on page 332.
2. Select the network in which the remote resides, right-click the network, and then select
Apply Configuration.
If the remote has been acquired into the network, the term Nominal is displayed in blue
text to the right of both the remote and the network. If it has not been commissioned and
acquired into the network for the first time, the term Never Applied is displayed to the
right of the remote.
5. To deactivate an active remote, select an activated remote, right-click it, and select
Activate Remote. The check mark will be removed and the remote will become inactive.
2. On the left side of the Move Remote dialog box, select the new Inroute Group for this
remote. The new Inroute Group can be in the same Network or in a different Network.
3. When moving the remote to a new network, in the Network QoS Tree section of the
dialog box, select either a Remote Service Group in the Service Group column or a
Service Profile from an Application Service Group in the Service Profile column.
4. In the Inroute Group QoS Tree section of the dialog box, select either a Remote Service
Group in the Service Group column or a Service Profile from an Application Service Group
in the Service Profile column.
5. If you selected a Remote Service Group for the new Network and/or Inroute Group, you
can also select new Remote Profiles in the Downstream and Upstream Remote Profile
sections of the dialog box.
NOTE: When moving a remote from one Remote Service Group to another, the
Remote Profile that was assigned to the remote in the original Service Group will
still be assigned in the new Service Group unless you select a new Remote Profile.
NOTE: An NMS Operator must have Group QoS permissions to select a new Remote
Profile while moving a remote. If you do not have Group QoS permissions, you will
not see the Remote Profile sections of the dialog box.
6. Click OK to move the remote. The remote is added to the iBuilder Tree under the new
Inroute Group.
You can also move remotes between Inroute Groups and Line Cards in SCPC Receive Mode, or
between two Line Cards in SCPC Receive Mode. This example shows how to move a remote
from an Inroute Group to a receive-only line card in SCPC Receive Mode.
1. Right-click the remote to be moved, and select Move from the menu.
Figure 9-3. Moving a Remote from an Inroute Group to an SCPC Line Card
2. On the left side of the Move Remote dialog box, select the Line Card that will receive the
remote’s SCPC upstream carrier.
3. When moving the remote to a new network, in the Network QoS Tree section of the
dialog box, select either a Remote Service Group in the Service Group column or a
Service Profile from an Application Service Group in the Service Profile column.
4. The SCPC Channel List section of the dialog box displays all available SCPC upstream
carriers assigned to the selected line card. Select the Channel ID of the SCPC upstream
carrier that you want to assign to this remote.
5. In the Upstream Remote Profiles section of the dialog box, select a Remote Profile.
NOTE: An NMS Operator must have Group QoS permissions to select a new Remote
Profile while moving a remote. If you do not have Group QoS permissions, you will
not see the Remote Profile sections of the dialog box.
6. You can change the remote’s Initial Power and Max Power by entering values in the fields
at the bottom of the dialog box. If these values have been pre-configured for the remote,
then the pre-configured values are displayed on the screen.
NOTE: The remote cannot become operational until the Initial Power and Max
Power are configured for the upstream carrier.
7. Click OK to move the remote. The remote is added to the iBuilder Tree under the receive
Line Card.
NOTE: If a VNO user retrieves an options file, only elements owned by or visible
to that VNO are included.
The following sections describe how to modify, retrieve, compare, and apply configurations
on remotes as well as on other network elements.
NOTE: The Dynamic Function Options Exchange (DFOE) protocol allows some
remote-side configuration changes to be dynamically applied. All remote hub-side
options groups beginning with 'RMT_' are sent from the Protocol Processor to the
remote using the DFOE protocol. For these options, you are no longer required to
apply remote-side changes to the remote and you will no longer see remote-side
changes pending in iBuilder.
or view the configuration of an element by selecting either Delete, View Properties, View
Properties Item, or View Properties VNO.
NOTE: You must deactivate a remote before you can delete it. When a remote is
activated, a check mark is shown next to the Activate Remote selection in the
iBuilder Tree for the remote. To deactivate a remote, right click the remote in the
iBuilder Tree and select Activate Remote to remove the check mark.
Figure 10-2 shows the iBuilder Tree menu selections for viewing and deleting a remote. Notice
that you cannot select Delete until a remote is deactivated.
NOTE: In the case of remotes, the menu allows selection of either the hub-side or
the remote-side configuration for retrieval.
2. Navigate to the PC folder in which to save the options file and click Save.
3. The options file opens in Notepad allowing you to review the configuration parameters.
1. Right-click the Network element and select Retrieve Multiple. Then select either Active
Configurations or Saved Configurations.
This example shows Saved Configurations being selected. The procedure for retrieving
multiple Active Configurations is identical.
2. In the Multiple Configurations Retrieve dialog box, select the remotes and/or the hubs
for which you want to retrieve the configurations.
4. In the Save As dialog box, navigate to the location on your PC where you want to save the
configuration files.
5. Click Save.
iBuilder retrieves the selected configurations and copies them to the designated location.
Both the remote-side and hub-side options files will be retrieved and saved for all selected
remotes.
2. To view all configuration parameters in the dialog box, clear the Show differences only
check box. Note that differences are shown in red.
3. To view only the parameters that are different, select the Show differences only check
box.
Sequence of Download
When applying configurations to multiple elements, iBuilder treats each group of elements as
a batch, processing the batches in upstream order. Therefore, remotes are downloaded first,
followed by hub lines cards, and finally the network itself.
All elements of a batch must complete its download successfully before iBuilder will proceed
to the next batch. For example, if any remote in a given batch fails during the download
process, iBuilder will stop at the end of the remote batch and wait for your next command. It
will not download to any line cards or to the network. However, all elements within a single
batch are processed simultaneously, so a single remote failure will not stop the other remotes
from being downloaded. Also, if the reset button is selected on the dialog box, iBuilder
immediately sends a reset command to any remote that downloads successfully. If this
behavior is not desired, make sure you check the Don’t reset button (you can always select
“Reset only” at a later time).
2. Select the options particular to your download. (These options are explained in the next
section.)
3. Click Start. The Status column shows that the configuration is downloading.
2. When the message appears asking you to confirm the download, click Yes.
3. When the message appears indicating that the configuration has been downloaded
successfully, click OK.
After the configuration is applied to the Network, the status of the network changes from
Changes Pending to Nominal.
When the download is complete and successful, a message appears, allowing you the
option of resetting the unit now or waiting and resetting it later.
4. Click OK.
3. When the message appears asking you to confirm the download, click Yes.
When the download is complete and successful, a dialog box appears, giving you the
option of resetting the remote now or waiting and resetting it later.
One Remote, One Network One Remote (global instance ), Multiple Networks
Remote
Options File
PP Options Network 1
File Network 2 Network 2
Network 3
PP Options
File Network 3
As with non-roaming remotes, the NMS sends a single options file to each roaming remote.
However, the NMS puts all the necessary parameters for each of the member networks into a
single remote options file.
The structure of the options file sent to the protocol processor has not changed. However, the
NMS generates a separate PP options file for each network a roaming remote belongs to.
An image package is a file that contains FPGA (Field Programmable Gated Array) firmware
images for a particular release and hardware platform. You can download images to remotes
or line cards using the Multicast Download feature, the TCP Download feature, or the Revision
Server. All three methods allow you to download both option files and image files to remotes
and line cards.
To upgrade from one version to another, schedule a maintenance window with your
customers. The time required for an upgrade varies based on the number of remotes you have
deployed. The upgrade process is described in the Network Upgrade Procedure for your
release. That document is specific to each release.
This chapter includes:
• Image Package Versions on page 353
• Upgrading with the Multicast Download Feature on page 354
• Resetting Remotes on page 361
• Upgrading with the TCP Download Feature on page 361
• Upgrading Remotes Using Revision Server on page 367
CAUTION: A mixed installation (i.e., one where not all components have the same
version) is not guaranteed to function properly.
A number of packages are installed on the NMS server during the upgrade. See the Network
Upgrade Procedure for your release for details.
NOTE: Your upstream router must have multicast enabled before you can
multicast images to your line cards.
NOTE: Users can safely upgrade more than 150 remotes to a network at one time
without experiencing issues.
Package Section
Figure 11-2 shows the package section.
Modems Section
Figure 11-3 shows the Modems section.
Remotes Section
The Remotes section contains the following elements:
• Remotes pull-down lists
• Select/Deselect - Use this pull-down list with the All pull-down list (directly below)
for additive and subtractive remote selection.
• All - Use this pull-down list with the Select/Deselect pull-down list (directly above)
for additive and subtractive remote selection.
• Nominal
• Changes Pending
• Deactivated
• RT WARNING
• RT ALARM
• Go button - Click Go to select remotes.
• Remote section pane shows the following:
• Name - Identifies a specific remote
• Status - Shows download status
• Flash started
• Flash complete
• Rebooting OS
• REMOTE HELLO
• R/T State - Indicates R/T state as:
• ALARM
• Deactivated
• WARNING
• OK
Hubs Section
The Hubs section contains the following elements:
• Hubs pull-down lists
• Select/Deselect - Use this pull-down list with the All pull-down list (directly below)
for additive and subtractive line card selection.
• All - Use this pull-down list with the Select/Deselect pull-down list (directly above)
for additive and subtractive line card selection.
• Nominal
• Changes Pending
• Deactivated
• RT WARNING
• RT ALARM
• Go button - Click Go to select line cards.
• Hubs section pane shows the following:
• Name - Identifies a specific line card
• Status - Shows download status
• Flash started
• Flash complete
• Rebooting OS
• REMOTE HELLO
• R/T State
• ALARM
• Deactivated
• WARNING
• OK
NOTE: At the Progress bar, download movement displays as 0 to 100% per group
of 150 remotes. Below the Progress bar, you will see an indication of which group
is being downloaded (e.g., 3 of 8). Each group has a separate Board Support
Package (BSP) and remote package.
The Progress bar at the bottom of the dialog box indicates the status of the download.
Depending on the status of the download, you will see either Download Complete or
Download Incomplete. If you receive the latter message, this does not necessarily mean the
download failed; it simply means the sending application did not receive an ACK
(acknowledgement) from that destination device. This behavior is explained in the next
sections.
NOTE: For Multicast Download, remote option files are bundled together with the
remote package.
NOTE: At the Progress bar, download movement displays as 0 to 100% per group
of 150 remotes. Below the Progress bar, you will see an indication of which group
is being downloaded (e.g., 3 of 8). Each group has a separate Board Support
Package (BSP) and remote package.
Group Reset
Use the Reset check box in the Download Parameters Section on page 359.
Individual Reset
Reset a remote as follows:
1. Right-click the remote, select Reset RemoteReliable (TCP).
2. When a message appears asking if you are sure, click Yes to confirm the reset.
A message appears confirming that the reset command has been issued. The success of
the reset is confirmed with a dialog box.
3. Click OK to acknowledge the confirmation.
NOTE: Users can safely upgrade more than 150 remotes to a network at one time
without experiencing issues.
• Options
Selection Section
Figure 11-6 shows the Selection section.
Targets Section
Note: iBuilder does not allow you to download an image package to an
incompatible element. When you select a specific hardware element, only the
elements that correspond to that hardware type appear in the Remotes or Line
Cards panes in the Target section. For example, if you select the package for
e8350 remotes, only e8350 remotes appear in the Remotes pane.
If you do not want to download the image package to a given remote or line card,
clear the check box next to it.
Figure 11-7 shows the Targets section.
Remotes Section
The Remotes section contains the following elements:
• Remotes pull-down lists
• Select/Deselect - Use this pull-down list with the All pull-down list (directly below)
for additive and subtractive remote selection.
• All - Use this pull-down list with the Select/Deselect pull-down list (directly above)
for additive and subtractive remote selection.
• Nominal
• Changes Pending
• Deactivated
• RT WARNING
• RT ALARM
• Go button - Click Go to select remotes.
• Information window shows the following:
• Name - Identifies a specific remote
• Status - Shows download status
• Flash started
• Flash complete
• Resetting...
• Reset
• Rebooting OS
• REMOTE HELLO
• R/T State
• ALARM
• Deactivated
• WARNING
• OK
Options Section
The Options section provides the options shown in Figure 11-8.
NOTE: For the TCP Download features, remote option files are bundled together
with the remote package.
• Follow the manual upgrade procedure for all of your iDirect equipment, including
remotes. Then launch the Revision Server to upgrade any sites that were unreachable at
the time of the initial upgrade.
• Upgrade your hub equipment, including line cards and protocol processors, manually.
Then launch the Revision Server to upgrade all remote sites.
When changing remote configuration parameters, you can use the Revision Server to
automatically apply those changes by sending the updated options files to the remotes as they
become available in the network.
NOTE: The Revision Server will upgrade or downgrade your remotes to the iDirect
version that is currently running on your NMS Server. Therefore you should
upgrade the NMS servers, followed by your Protocol Processors, before starting a
Revision Server upgrade.
NOTE: You can use the Revision Server to upgrade to the new release provided
you are upgrading from iDS Release 5.05 or later.
The Revision Server dialog box opens (Figure 11-10), including a list of all the remotes in
the network. Remotes with a status of DownRev have a different package version from
that of the NMS server. UpRev remotes are current.
2. In the Remotes section of the dialog box, select all remotes you want to upgrade by
clicking the check boxes. You can also click any of the following buttons to select remotes
for download:
• The Select All button selects all remotes in the network.
• The Select Down Rev button selects only remotes with a status of DownRev.
• The Select Active button selects only remotes that are currently acquired into the
network.
• The Changes Pending button selects all remotes with remote-side configuration
changes that have not yet been applied.
• The Clear All button clears the check boxes for all remotes in the network.
3. You can change the Download Rate specified in the Download Parameters section if
desired. By default, the download rate is calculated to be 10 percent of the downstream
information rate.
4. Select Options Files Only if you only want to send options files to the remotes. No image
files will be sent.
NOTE: The status of UpRev or DownRev is determined solely by the version string
of the image package. Therefore, remotes with an up-to-date package for which
the remote-side options files have not been applied will have a status of UpRev.
1. Right-click in the Remotes area of the Revision Server dialog box and select Stop All from
the menu to stop events from all remotes.
2. Highlight the remotes for which you want to view events. (Use Shift + click to highlight a
range of remotes. Use Ctrl + click to select multiple, individual remotes.)
3. Right-click any of the highlighted remotes in the Remotes area of the Revision Server
dialog box and select Start Highlighted from the menu.
NOTE: Only events from the highlighted remotes are added to the event pane at
the bottom of the Revision Server dialog box.
4. To begin viewing events from all remotes again, right-click in the Remotes area of the
Revision Server dialog box and select Start All from the menu.
As an alternative to Stop All followed by Start Highlighted, you can select all remotes you do
not want to monitor. Again, assuming you have selected all remotes for download and are
currently receiving events for all remotes:
1. Highlight the remotes for which you do not want to view events.
2. Right-click any of the highlighted remotes in the Remotes area of the Revision Server
dialog box and select Stop Highlighted from the menu.
Events from the selected remotes are no longer added to the event pane at the bottom of the
Revision Server dialog box.
Figure 11-15. Selecting Revision Server Status from the View Menu
The Revision Server Status pane will appear in place of the iBuilder Tree, showing the
status of all upgrades that are in progress. Note that two tabs appear at the bottom of the
pane allowing you toggle between the iBuilder Tree (iBuilder Tree View tab) and the
Revision Server Status pane (Revision Server tab) as shown in Figure 11-16.
2. To see the status of completed upgrades as well as current upgrades, select Show
historical information.
3. Click Details for any upgrade to see more information about that upgrade. This includes
the upgrade Status of each remote in the upgrade list.
This section provides instructions for commissioning iDirect line cards. It discusses the
following topics:
• Powering on the equipment
• Determining the IP address
• Downloading the initial image package and options file
• Performing the 1 dB compression test when necessary
• Setting the transmit power for the downstream carrier
12.1 Prerequisites
Before executing this procedure, the following tasks must have been performed at the hub:
• The physical teleport installation is complete.
• The hub antenna is pointed and the cross polarization test performed.
• The NMS client and server software are installed and running.
• The following components and network elements are configured in iBuilder:
• All hub equipment, satellite transponder bandwidth, and the upstream carrier to be
transmitted by this line card. (See Defining Hub RFT Components and the Satellite on
page 69.)
• All hub components in the iBuilder Tree. (See Defining Network Components on
page 89.)
• The iBuilder network in which this line card will operate. (See Defining Networks,
Line Cards, and Inroute Groups on page 117)
NOTE: If adding a new line card, the Tx Out, Rx In and Lan A ports should not be
connected at this time. Do not connect these cables until instructed to do so by
this procedure.
3. Right-click the line card in the iBuilder Tree and select Retrieve Saved Configuration.
4. In the Save As dialog box, navigate to the folder on your PC in which you want to save
the options file. Then click the Save button to save the file to your PC.
5. After you save the options file, it is displayed in Notepad as a text file. You can review the
configuration before closing the Notepad window.
2. In iBuilder, right-click the chassis in the iBuilder Tree and select Modify Item to open
the Chassis dialog box.
3. In the State column, select the check box for the slot that contains the new line card. The
State of the slot changes from Off-Licensed to On-Licensed.
4. Right-click in the Hub Assignment column of the slot and select the line card.
5. Click OK to save the Chassis configuration.
6. Wait two minutes.
7. Right-click the Chassis in the iBuilder Tree and select Apply Configuration to power on
the slot.
NOTE: The default IP Address of a line card is 192.168.0.1, with a subnet mask of
255.255.255.0. If you already know the IP address, you can skip this section.
1. Connect a console cable from the COM1 port on your client PC to the console port on the
line card.
2. Using a terminal emulator program such as Tera Terminal or HyperTerminal, connect to
the line card with the following settings:
• 9600 bps
• 8 bits
• No parity
• 1 stop bit
This is illustrated in Figure 12-2 using Tera Terminal.
3. Log in as:
Username: root
Password: <password>
Either iDirect or P@55w0rd! is the default password for the root account.
4. At the Linux prompt, type
telnet localhost
The Telnet login screen will appear.
5. Log in to the Telnet session as:
Username: admin
Password: <password>
Either iDirect or P@55w0rd! is the default password for the admin account.
6. At the Telnet prompt, type the following command to determine the IP Address and
subnet mask of the line card:
laninfo
The output of the laninfo command is shown in Figure 12-3.
7. Note the IP address and subnet mask. You will need this information when downloading
the image packages and options file.
NOTE: The default IP Address of a line card is 192.168.0.1, with a subnet mask of
255.255.255.0.
2. Connect a cross-over Ethernet cable between the LAN port of the line card and your PC or
laptop.
3. Launch iSite. The main iSite screen will appear.
4. Right-click the globe in the iSite Tree and select New. An Unknown element is added to
the iSite Tree.
5. Right-click the new element and select Login to display the Login dialog box.
6. Enter the IP Address of the line card and a password. (iDirect is the default password.)
7. Select Admin in the Login as section and click OK. The line card will appear in the iSite
Tree, replacing the unknown element.
8. In the iSite Tree, right-click the line card and select Download Package to display the
Download Package dialog box.
NOTE: You must download both packages to your line card, beginning with the
Board Support Package (BSP), followed by the hub package(s).
14. Right-click the line card in the iSite Tree and select Reset from the menu.
At this point the new line card configuration (including the new IP address) has been applied
and you will lose connectivity to the line card. Do not disconnect the console cable.
CAUTION: Connecting the transmit port of your line card will result in the
transmission of a carrier on the satellite. This step should only be performed
while on line with the satellite provider.
1. Connect the Tx coax patch cable to the line card’s Tx Out port.
2. Connect the Tx coax patch cable to the corresponding Tx patch panel port above the line
card slot.
12.9 Set the Transmit Power for the Outroute with the
Satellite Operator
Set the transmit power for the outroute as follows:
NOTE: Whenever tx pn or tx cw commands are used, you must reset the line card
to restore normal operation. Be sure to follow the instructions in the next section
to reset your line card after applying the configuration.
1. If you do not have a console connection to the line card, establish one now by following
the steps in Section 12.4 on page 379.
2. Configure the line card to transmit at the frequency indicated by the satellite operator by
entering the command:
tx freq <fx>
where fx represents the L band frequency in MHz.
3. Configure the line card to transmit a signal with pseudo-random data by entering the
command:
tx pn on
4. Working with the satellite operator, adjust the transmit power to achieve the contracted
power at the satellite. To change the tx power to a new value, type:
tx power <pwr>
where pwr represents the power setting in dBm.
5. Disable the PN carrier by entering the command:
tx pn off
6. Open iBuilder and select the line card in the iBuilder Tree. Then select Modify
Assigned Downstream Carrier from the context menu.
7. In the Downstream Carrier dialog box, enter the value for Power determined in step 4.
Prior to iDS Release 7.0, all user accounts were independent of one another. Beginning with
iDS Release 7.0, all users belong to one of a variable number of User Groups. Visibility of
network elements and access rights to those elements are now defined at the user group level
rather than for each user account. This chapter explains how to create and manage user
groups and user accounts, and how to define the permissions and access rights associated with
each. It discusses the following topics:
• Conversion of User Accounts During Upgrade Procedure on page 389
• NMS User Groups on page 390
• Modifying Group QoS Settings for VNO User Groups on page 407
• Adding and Managing User Accounts on page 417
• Changing Passwords on page 423
• User Privileges on page 424
• Simultaneous Changes to the NMS Database on page 427
CAUTION: As soon as possible after you upgrade from a pre-7.0 release, you must
re-define the visibility settings for each VNO user group. VNO users will be unable
to use the system until you have done this.
NOTE: VNO and CNO User Groups are licensed features. Before defining VNO or
CNO User Groups, please contact your iDirect Account Manager.
NOTE: The term HNO Administrator is used in the following sections to refer to a
System Group User with permissions to create and modify VNO User Groups.
• Visibility has three different levels of access rights. When you give visibility of an
element to a User Group, for example an inroute group, you have the following additional
access rights you can grant or revoke:
• Create access allows users to create new elements underneath this node. For
example, you can allow a user to create new remotes in an inroute group.
• Write access allows users to modify the contents of the element itself. For example,
a user with Write access to an inroute group could modify the inroute group to turn
off frequency hopping.
• Control access gives users the right to perform control operations on child elements
of the specified node. For example, users with Control access for an inroute group can
perform all control operations on remotes in that inroute group.
• Ownership is different from Visibility. When you set a node as Owned by a VNO group,
you are dedicating that node and all of its children to this VNO group exclusively (except
for system users, of course). No other VNO groups are able to see or interact with this
group in any way. Visibility to network elements, however, can be shared across multiple
VNOs.
• VNOs cannot see each other; System users see all. When a VNO creates a network
element, only the members of that group and the System User Group are able to see the
element. When the system group creates or owns a network element, no VNOs can see
this element unless they are granted visibility to it.
• User Groups are highly configurable. The implementation of VNO User Groups is quite
flexible; you can configure groups in a number of ways. However, unless you are careful
when configuring your user groups, this flexibility can result in unwanted results. It is
possible to give VNO User Groups various combinations of write and visibility access that
may create confusion in practice.
For example, giving a VNO Write access to an inroute group, without granting Control
access at the Network level, could result in a condition from which the VNO user is unable
to recover. In this example, a VNO user could modify the inroute group so that it sets the
Network to the “Changes Pending” state, yet be unable to apply the changes.
• Profiles created by VNO members are visible only to members of that VNO User Group and
the System User Group.
The Information tab contains a Full View of the network tree in the left pane and the User
Group View in the right pane. Notice that the visibility and ownership properties of the tree
elements in the User Group View are color coded according to the key at the bottom of the
window.
2. In the Group dialog box, enter a Group Name for the User Group. If desired, you can also
change the Group Type and add a Description of the group.
3. On the Information tab of the dialog box, right-click on elements in the Full View to set
their visibility and permissions for the User Group.
The menu displays a check mark next to all access rights selected for this element. The
User Group View shows you which elements this group’s users will have access to, and
what their access rights will be. Figure 13-3, Figure 13-4, and Figure 13-5 show examples
of VNO User groups with various settings.
NOTE: When configuring a CNO User Group, you can only select Visible from the
context menu. Other permissions in the list apply to VNO User Groups only.
2. To limit the downstream information rate, select the MaxDownstreamKbps check box and
enter the rate limit in kbps.
3. To limit the upstream information rate, select the MaxUpstreamKbps check box and
enter the rate limit in kbps.
In Figure 13-6, remotes created or controlled by members of the User Group are restricted to
a maximum of 256 kbps on the downstream and a maximum of 32 kbps on the upstream.
2. To make the element visible to a VNO, select the check box next to the VNO name. (You
can also do this by selecting from the context menu as described in the next step.)
In Figure 13-7, the inroute group is visible to three different VNO groups. VNO1 and VNO2
can only view the Inroute Group. VNO3 can perform control operations such as applying
configuration changes.
3. To modify a VNO’s permissions for the selected element, right-click on the VNO name and
select the desired permissions from the menu.
4. To change ownership of the selected element, click the arrow in the Owned by drop-
down menu and select a new group.
Clicking OK causes iBuilder to log out and then log back on to the VNO user session,
committing the configuration changes executed from the HNO’s administrative session.
NOTE: iBuilder will automatically log back on to the VNO user session to enable
the visibility to new items created under component folders by HNO users.
Figure 13-10. VNO Full View: Owned Slots vs. Visible Slots
If a VNO has write access to a chassis, then a VNO operator can modify the chassis. The
operations that each VNO can perform on the chassis slots depend on the VNO’s access rights
to those slots.
• If the VNO owns a chassis slot, a VNO operator can power on and off the slot and assign a
line card to the slot.
• If the VNO owns all slots in two adjacent timing groups, a VNO operator can enable the
jumper between the timing groups. (This is subject to additional backplane checks.)
Ownership of all slots in both timing groups is required to set these jumpers.
• If the VNO has both write access and control access to a chassis slot, a VNO operator can
assign line cards to the slot and power on or off the slot.
• If the VNO has only write access to a chassis slot, a VNO operator can assign line cards to
the slot. However the VNO operator cannot power on or off the slot.
• If the VNO has only control access to a chassis slot, a VNO operator can power on or off
the slot. However the VNO operator cannot assign line cards to slot.
NOTE: A VNO must own a network and its line cards in order to manage line card
redundancy.
If two VNOs have write access to the same chassis, VNO users in both VNO user groups can
modify the chassis in iBuilder. However, on the chassis modify screen, each VNO sees only the
slot assignments of its own line cards or to line cards set to Visible for the VNO. A VNO
operator cannot see the line card assignments for line cards owned by another VNO.
Figure 13-11 shows two versions of the same Chassis Modify screen.
In Figure 13-11, VNO 1 owns the line cards in slots 1 and 2 and VNO 2 owns the line cards in
slots 9 and 10. The top image in Figure 13-11 shows what the HNO sees when right-clicking the
chassis in the iBuilder Tree and selecting ModifyItem. Both VNO 1’s line cards and VNO 2’s
line cards are displayed to the HNO.
The bottom image in Figure 13-11 shows the same screen when a VNO 1 user is logged on to
iBuilder. Notice that VNO 1 cannot see the slot assignments for slots 9 and 10, since those line
cards are owned by VNO 2.
If a VNO owns a chassis slot, then iBuilder does not allow any other VNO to assign line cards to
that slot. Therefore, no conflicts can arise. However, if two VNOs have write access to the
same slot, the slot may be occupied by a line card owned by one VNO that cannot be seen by
the second VNO. In that case, if the second VNO attempts to assign a line card to the occupied
slot, iBuilder does not allow the assignment and displays an error message. Figure 13-12 show
the result when a VNO attempts to assign slot 1 when the slot is already occupied.
NOTE: This example assumes that the VNOs have been granted ownership of their
respective networks and line cards. The VNOs must own these elements to
manage their line card redundancy.
3. In the Full View section of the Modify Configuration screen for the VNO, expand the tree
to expose the chassis you want the VNOs to share.
4. Right-click the chassis and grant Visibility and Write and Control access to the VNO.
NOTE: Control access allows the VNO to apply configuration changes to the
chassis. For example, if the VNO enables or disables the power to a slot, the VNO
can then download the changes to the chassis.
5. Expand the chassis in the Full View to display the chassis slots.
6. Right-click each Slot that you want the VNO to use and grant Visibility and Control to the
VNO.
NOTE: If you are sharing a chassis among multiple Network Management Systems,
please see Sharing a 20 Slot Chassis in a Multi-NMS System on page 322.
Figure 13-17. VNO Full View: SCPC Return Channels Shared by two VNOs
When one or more SCPC return channels are owned by a VNO, the line card is automatically
Visible to the VNO. The VNO can add remotes to the SCPC line card or move remotes between
SCPC line cards and inroute groups.
A VNO can own an SCPC return channel even when the channel has not been assigned an
upstream carrier or a remote. This allows VNO users to assign upstream carriers and remotes
to the VNO’s SCPC return channels without the assistance of the HNO.
NOTE: The HNO must make an SCPC upstream carrier Visible to the VNO before
the VNO can assign that carrier to an SCPC return channel or to a remote. A VNO
cannot own an upstream carrier.
NOTE: When the HNO assigns an SCPC return channel to a VNO user group, and
that channel is already associated with an SCPC upstream carrier, then the carrier
is automatically visible to the VNO user group. Furthermore, if the upstream
carrier is also assigned to a remote, then the VNO automatically owns the remote.
As an HNO, you can assign ownership of SCPC upstream channels to a VNO as follows:
1. Right-click the VNO user group in the iBuilder Tree and select Modify from the menu.
2. In the Full View, expand the line card to view the channels. Channels are numbered from
zero to seven.
3. Right-click the channels you want to assign to the VNO and select Owned (Figure 13-18).
The line card will automatically become Visible to the VNO, with Create permission.
NOTE: If a VNO owns one or more channels on an SCPC line card, then you can
assign SCPC upstream carriers to the VNO when you select the carriers for the line
card. See Step 7 in Adding Multiple Receive Carriers to a Line Card on page 128
for details.
2. In the Line Card dialog box, click the Configure Carriers button to open the Select
Carrier dialog box (Figure 13-19).
Figure 13-19. Line Card Dialog Box: VNO User Selecting Configure Carriers
When opened by a VNO user, the Select Carrier dialog box shows the SCPC upstream
carriers currently assigned to the line card and any additional carriers that the VNO user
can assign. Only carriers that are visible to the VNO are displayed.
3. To assign a new carrier to the line card, select the check box of the carrier. The User
Group is automatically updated with your VNO user group name.
NOTE: A VNO user cannot select more SCPC upstream carriers than the number of
SCPC return channels owned by the VNO.
4. To remove a carrier from the line card, clear the check box of the carrier. The User Group
is automatically cleared.
NOTE: A VNO user cannot change the line card center frequency.
5. Click OK in the Select Carrier dialog box to save the new carrier assignments.
6. Click OK in the Line Card dialog box to save the changes.
Figure 13-20. VNO with Network Visibility and GQoS Node Ownership
As shown in Figure 13-21, when a VNO user right-clicks the network, the user can only select
ModifyGroup QoS but cannot select ModifyItem.
Figure 13-21. VNO Network Menu with Owned GQoS Nodes but No Network Access
When the VNO User selects ModifyGroup QoS, the network dialog box is displayed with all
tabs. However, the user can only modify owned QoS nodes on the Group QoS tab. The VNO
user cannot change anything on the Information tab or the Custom tab.
However, if the VNO has Write access to or Ownership of the network or inroute group, then a
VNO user can change any settings on the network or inroute group as well as on its owned
GQoS nodes. For example, Figure 13-22 shows the VNO from Figure 13-20 re-configured to add
Write and Control access to the network.
Figure 13-22. VNO with Network Write Access and GQoS Node Ownership
Because the VNO has been granted Write access to VNO 1 Network, a VNO user can select
both ModifyGroup QoS and ModifyItem from the network menu. This is illustrated in
Figure 13-23.
Figure 13-23. VNO Network Menu with Owned GQoS Nodes and Write Access to Network
When the VNO user selects ModifyItem for the network, the user can change the
configuration on the Information and Custom tabs as well as the configuration of its owned
GQoS nodes on the Group QoS tab.
When a VNO user modifies the Group QoS settings for VNO 1 Network, the VNO user has
access to all nodes in Bandwidth Group 1 but cannot see or modify Bandwidth Group 2. This
is illustrated in Figure 13-25.
Notice in Figure 13-25 that the VNO user cannot see Bandwidth Group 2, since the VNO has
not been granted any permissions for that Bandwidth Group. However the VNO can see (and
modify) Bandwidth Group 1, since it is owned by the VNO.
NOTE: On the Group QoS tab, a VNO user can only see remotes assigned to a
Remote Service Group if those Remotes are Visible to or Owned by the VNO.
Some properties of Group QoS nodes (called Request Properties) affect how the parent node
allocates bandwidth among its subnodes. When a VNO is granted ownership of a Group QoS
node, the VNO can only modify the Request Properties of the node if the VNO has the right to
modify the parent node. If the VNO could modify the Request Properties of a node without
having permission to modify the parent node, then the VNO could change settings such as the
MIR and CIR granted to the owned node by the parent node, potentially at the expense of
competing nodes. Therefore, the ability to change the Request Properties of a Group QoS
node is dependent on permissions set for the parent.
An example is shown in Figure 13-26.
On the left side of Figure 13-26, the VNO owns Bandwidth Group 1 but does not have
ownership of the network’s Bandwidth Pool. Therefore, the VNO cannot modify the Request
Properties of Bandwidth Group 1. On the right side of Figure 13-26, the VNO owns
Bandwidth Group 1 and its parent node, the network’s Bandwidth Pool. Therefore, the VNO
can modify the Request Properties of Bandwidth Group 1.
2. In the Group dialog box (Figure 13-27), expand the Full View tree to expose the node or
nodes you want to assign to the VNO. Group QoS nodes are displayed in folders under
Networks and Inroute Groups. The top-level folder for the Group QoS Nodes is always
labeled Bandwidth Pool.
3. Grant the desired access by right-clicking the GQoS Node and selecting the desired
options. You can either select Owned or Visible for a GQoS node. However, if you select
Visible, you cannot select any additional access rights.
Figure 13-29 shows a Visible Bandwidth Group (Bandwidth Group 1). VNO users can view
the Bandwidth Group 1 settings but cannot change them. VNO users in this VNO cannot
see Bandwidth Group 2.
In Figure 13-30, the VNO owns Service Group 1under Bandwidth Group 1. Therefore,
Bandwidth Group 1 (and higher nodes) are automatically set to visible for the VNO. VNO
operators in this VNO cannot see Service Group 2.
NOTE: An HNO cannot assign Create, Write or Control access to a VNO for a
Visible Group QoS node. For a VNO user to modify or control a Group QoS node,
the VNO must own the Group QoS node.
Notice in Figure 13-31 that the VNO user can Modify Service Group 1 or Add Applications to
it. However, since the VNO does not own Bandwidth Group 1, the VNO user cannot Insert
additional Service Groups into Bandwidth Group 1 or Delete Service Group 1 from
Bandwidth Group 1. Notice also, that the VNO user cannot see Service Group 2 in Bandwidth
Group 1 (see Figure 13-30), since the VNO was not granted visibility to Service Group 2.
NOTE: Before VNO users can add new Applications to a Service Group, the
Application must first be created and then made Visible to the VNO User Group by
the HNO administrator. This is discussed in the next section.
For details on configuring the various types of QoS Profiles, see Configuring Group QoS on
page 244.
In Figure 13-32, VNO 1 Downstream Profile has been set to Visible for the VNO User Group.
Notice in the User Group View that in addition to the Default and NMS Downstream Profiles,
only VNO 1 Downstream Profile is available for use by this VNO. To remove a Visible Profile
from the User Group View, re-select the Visible permission from the menu to clear the check
mark.
NOTE: You can also right-click the QoS profile in the iBuilder Tree and select
ModifyVNO from the menu to easily make a profile visible to multiple VNOs at
the same time. See Modifying per Node VNO Properties on page 396 for more
information.
Figure 13-33. Enabling the Create Permission on a QoS Folder for a VNO User Group
In Figure 13-33, the image on the left shows the VNO permissions set for the Upstream
Remote Profile folder by the HNO; the image on the right shows the VNO User’s right-click
menu for the same folder. As illustrated on the right of Figure 13-33, VNO users can now add
their own Upstream Remote Profiles. Any QoS profile created by a VNO User is owned by that
VNO User Group.
2. Expand the tree in the Full View pane to view the profile you want to modify in the
Downstream or Upstream folder under the Filter Profiles folder.
3. Right-click the Profile in the Full View and select Write from the menu.
In Figure 13-34, the image on the left shows the VNO permissions set for the Filter Profile by
the HNO; the image on the right shows the VNO User’s right-click menu for the Filter Profile.
As illustrated on the right of Figure 13-34, VNO users can now Modify the profile.
NOTE: Write permission cannot be granted to VNO User Groups for individual
Application Profiles or Remote Profiles. To allow VNO Users to define their own
Application Profiles and/or Remote Profiles, enable the Create permission as
discussed in Allowing VNO Users to Create QoS Profiles on page 416.
1. Right-click the User Group in the iBuilder Tree and select Add User.
2. When you select Add User, the User dialog box opens.
NOTE: If a default password is entered, the Detected Default Password dialog box
opens to warn the user to change the default password. The dialog box opens
each time the default password is used unless the default password security check
is turned off. For more information, see Turning Off/On Security Enhancement
on page 17.
5. If you click either the Super User or Guest check box, the permissions allowed for the
user level you selected appear with check marks next to them on the User dialog box, but
they are not selectable. These permissions may vary in accordance with the type of User
Group.
6. If you clear both of the main User Level boxes (Super User and Guest), the individual
permissions detailed in Table 13-2, Custom Privileges on page 425 become selectable.
Click the boxes next to the customized functions that you want to assign to the user.
7. Click OK to save the settings for the user account. The new user is added to the iBuilder
Tree under the User Group you selected.
2. When the User dialog box opens, change the settings as desired. (For details, see Adding
a User and Defining User Privileges on page 417.)
3. Click OK to save the changes.
2. A new user is added to the iBuilder Tree and the User dialog box is displayed with settings
identical to the cloned user.
NOTE: If a default password is entered, the Detected Default Password dialog box
opens to warn the user to change the default password. The dialog box opens
each time the default password is used unless the default password security check
is turned off. For more information, see Turning Off/On Security Enhancement
on page 17.
The Logged On column indicates the logon session count for that user under both iBuilder and
iMonitor. This pane is updated in real time as values change.
To open the Active Users pane, Select View View Active Users from the main menu.
Figure 14. Opening the Active Users Pane from the View Menu
Depending on your permission level within the NMS, you can perform the following actions:
• Delete a user
• Modify a user’s account
• View a user’s current properties
Figure 15. User Account Options from the Active Users Pane
5. Click OK. If a default password is entered, a dialog pop-up box opens to warn the user to
change the default password.
NOTE: Beginning with iDX Release 3.3.5.1, iDirect introduces NMS security
enhancements to discourage the use of default password credentials after their
initial use. It is important to change the passwords for the default user names as
soon as possible.
NOTE: Changes to user accounts take place immediately, i.e. you do not have to
“apply changes” for users. However, new settings for a specific user will not take
effect until the next login under that account. If the user is logged in while you
make changes, the old settings remain in effect for the remainder of that session.
If the Super User sets up a user as a custom-defined user, the Super User can assign that user
any number of privileges from a list provided in the system. (See Table 13-2.)
Table 13-2 lists the various privileges that can be granted or revoked for a custom-defined
user.
NMS
Privilege Name Description
Application
Database Read The most basic privilege; allows retrieval of stored configuration iBuilder,
information. This is the only privilege Guest users are granted. iMonitor
You cannot grant or revoke this privilege from iBuilder.
Change Database Allows modification of configuration information. iBuilder
Download Allows download of firmware to line cards and remote modems. iBuilder
Firmware
Apply Allows application of configuration changes to networks, hub iBuilder
Configuration lines cards, and remote modems.
Reset Modem Allows remote and line card resets. iBuilder,
iMonitor
Manage Users Allows modification of user names and passwords. iBuilder
Edit Permissions Allows modification of user permission settings. iBuilder
Upload Allows retrieval of a remote modem’s or line card’s active iBuilder
Configuration configuration.
NMS
Privilege Name Description
Application
Basic Probe Allows retrieval of real-time statistics in the Probe tab. iMonitor
Advanced Probe Allows all Probe functions (reset, connect, change tx power, iMonitor
etc.).
Customize Allows access to the “Custom” tab in the Remote Modify Dialog iBuilder
Configuration Box.
Password in Clear Controls whether or not an NMS user can see remote and protocol iBuilder
Text processor passwords in clear text.
Monitor Longterm Allows monitoring of long term statistics in iMonitor. iMonitor
Statistics
GQoS Planning Allows modifications to the Group QoS configuration for iBuilder
Networks, Inroute Groups and Group Profiles.
7. From the hub level in the tree, they cannot perform image downloads, nor can they
create or delete line cards.
A user defined in a VNO as Guest has read-only permissions to the nodes visible to a Super
User in that the VNO.
Figure 13-3. Message Displayed if Another User Has Modified the Configuration
CAUTION: You will only be notified of configuration changes if you have disabled
the feature to automatically accept configuration changes discussed in Accepting
Changes on page 19.
If you choose to save changes after being alerted that another user has modified the
configuration, then the changes made by the first user may be lost if you are both modifying
the same element. For example, if you and another user are modifying the same remote,
when the other user clicks OK to save the configuration, the modifications will not be
reflected in your remote modify window. Therefore, when you save the remote configuration,
the fields changed by the first user will be overwritten with their previous values. To ensure
that you are not overwriting another user’s changes, you can cancel your changes and re-open
the dialog box.
This chapter explains how to convert an Inroute Group containing a uniform set of Static
TDMA upstream carriers to Adaptive TDMA.
This chapter contains the following major sections:
• Overview on page 429
• Prerequisites for Converting to Adaptive TDMA on page 429
• Converting an Inroute Group to Adaptive TDMA on page 430
• Verifying Adaptive Network Operation on page 439
14.1 Overview
Adaptive TDMA allows Inroute Groups to contain upstream carriers with different MODCODs
and symbol rates. Adaptive TDMA also supports multiple Inroute Group Compositions (IGCs)
that vary the MODCODs of individual Adaptive carriers to adjust to changing network
conditions.
After upgrading from an earlier release to a release that supports Adaptive TDMA, all TDMA
upstream carriers in each Inroute Group are set to Static and the carrier definitions from the
previous release are not changed. This chapter explains how to convert an Inroute Group
containing all Static carriers with the same MODCOD and symbol rate to an Inroute Group
containing both Adaptive and Static carriers and multiple IGCs.
This chapter assumes that iDirect’s network planning tools have been used to fully define all
aspects of the Adaptive Inroute Group. Before converting an Inroute Group, read the chapter
titled “Adaptive TDMA” in the Technical Reference Guide and Adding an Inroute Group on
page 147.
• All Shared Carrier Parameters and Adaptive Parameters of the Inroute Group
• For each remote in the Inroute Group:
• Any Carrier Constraints applicable to the remote (Minimum Symbol Rate and/or
Maximum C/N)
• Maximum Link Impairment for the remote, if specified by the design
In addition to the above specifications from the network design:
• All receive line cards required to support Adaptive TDMA should be installed,
configured in iBuilder, and operational.
• The carrier assignments per receive line card should be pre-determined.
• Line card model types, receive modes, and licensing must be correct for all receive
line cards that will receive Adaptive carriers.
• Line card model types and receive modes must be compatible with SuperBurst for line
cards that will receive carriers with SuperBurst acquisition enabled.
14.3.1 Assumptions
This procedure assumes that:
• The new Inroute Group configuration has been completely specified using iDirect’s
network planning tools.
• The total occupied bandwidth of the Inroute Group has not changed.
• All line cards are installed, operational and capable of receiving the specified carriers.
• The reference carrier parameters, maximum power and initial power are set correctly for
remotes in the Inroute Group.
Carrier constraints for remotes should be configured before changing the carriers to avoid
switching a remote to an inappropriate carrier.
The following iBuilder remote settings affect how an individual remote behaves when using
Adaptive TDMA:
• Carrier Constraints limit the minimum symbol rate of the remote’s upstream carrier and
the maximum C/N at which the remote’s bursts are allowed to be received. A remote will
not be assigned TDMA slots on upstream carriers that violate either of these constraints.
• Maximum Link Impairment affects how a fading remote affects the Inroute Group
Composition selection algorithm.
Configure the adaptive parameters for an individual remote in the Adaptive Parameters area
of the Remote QoS tab as follows:
1. If a Maximum Link Impairment is specified by the network design for the remote:
a. Select Enable.
b. Enter the Maximum Link Impairment in dB.
2. Configure any Carrier Constraints specified by the network design:
a. Enter the Minimum Symbol Rate for carriers on which the remote can transmit.
b. Enter the Maximum C/N for the remote.
2. Ensure that the payload block size is the same for all carriers (Adaptive or Static) and that
the selection agrees with the network design. For Adaptive carriers, select the correct
block size in the Payload Size field. For Static carriers, select the correct FEC rate and
block size in the Error Correction field.
Figure 14-3. Selecting the Payload Block Size for Adaptive and Static Carriers
NOTE: Only Multichannel Line Cards and Receive-Only eM1D1 Line Cards can
receive Superbursts. Do not enable Superburst unless the receive line card to
which this carrier will be assigned supports it. For more information, see the
“Remote Acquisition” chapter of the Technical Reference Guide.
CAUTION: Since the occupied bandwidth per carrier of the new inroutes may
differ from that of the existing inroutes, ensure that the entire carrier frequency
space (including guard band) is available before assigning each new carrier to the
Inroute Group. In some cases, this may require removing multiple carriers from
the Inroute Group and line card(s) before adding the new carrier.
NOTE: The steps in this section assume that all receive line cards are installed,
correctly configured, and operational.
Systematically replace the existing carriers in IGC 1 of the Inroute Group with the new
carriers as follows:
1. Select one or more existing carriers that can be replaced by a new carrier. Ensure that
replacing the old carrier(s) with the new carrier does not result in interference with other
existing carriers.
2. On the iBuilder Inroute Group Information tab, select the carrier(s) to be removed and
click Remove. (See Adding an Inroute Group on page 147 for more information.)
3. On the Line Cards Information tab, replace the existing carrier(s) from receive line card(s)
with the new carrier.
Figure 14-9. . Assigning the New Upstream Carrier to the Inroute Group
c. Select the MODCOD for each Adaptive carrier as specified for this IGC.
Power is set too high, the remote may cause interference on upstream carriers during
operation. If either condition is observed, re-execute the procedure for determining the
correct TDMA Maximum Power and update the configuration in iBuilder.
The procedure for determining the TDMA Maximum Power is contained in the iDirect Satellite
Router Installation and Commissioning Guide. That procedure uses iSite or Web iSite and
assumes that the installer is present at the remote site. However, the iMonitor Probe can also
be used to execute the same general procedure since it provides similar capabilities for
transmitting a test carrier and adjusting the remote transmit power. Steps for using the
iMonitor Probe are contained in the iMonitor User Guide.
Figure 14-16 shows the section of the iMonitor Probe used to command the remote to transmit
a test carrier.
Figure 14-16. Checking and Modifying the Remote TDMA Maximum Power
• Assuming there is sufficient demand, use the Timeplan display to verify that slots are
being allocated efficiently on most or all carriers. Keep in mind that fade conditions and
constraints on individual remotes can affect bandwidth allocation.
• In addition to total capacity versus allocated slots, the Timeplan display shows a time line
graph of IGC usage. This shows how the capacity and slot allocations change when a new
IGC is selected.
• Use the Upstream C/N0 and Thresholds display to verify that the individual remotes
operate near the thresholds of the various carriers in the different IGCs. The Upstream
C/N0 and Thresholds display also shows the remote’s current nominal carrier. This should
correspond to the predictions from the network design for the current conditions. For
example, if in clear sky conditions the remote’s nominal carrier does not match the
design, the remote’s TDMA Maximum Power may be set too low or incorrect constraints
may be configured for the remote.
For further details, see the iMonitor User Guide, iBuilder User Guide, and Technical
Reference Guide.
Operation
When Carrier Grooming mode is first enabled, a list of suitable carriers is made and a remote
is randomly assigned to one of the carriers. The randomly chosen carrier is referred to as the
grooming carrier. The remote uses this grooming carrier until:
• The remote falls out of network and acquires back into network; another carrier is
chosen randomly.
• The grooming carrier is deleted or the line card servicing the remote stops working;
another carrier is chosen randomly.
• Carrier grooming is disabled because the user intends to return to frequency hopping
mode.
A user can also select a specific grooming carrier for a remote instead of using a randomly
assigned grooming carrier.
Figure 14-17. Clicking the Carrier Grooming (Debug Mode) Check Box
4. Click the Lock to Inroute check box to lock a remote to a specific carrier selected at the
adjacent pull-down menu.
Click Details to view information about the selected carrier at the Upstream Carrier -
TDMA window. For information about the information shown at this window, see Adding
TDMA Upstream Carriers on page 79.
5. To exit Carrier Grooming mode and return to frequency hopping mode, uncheck the
Carrier Grooming (Debug Mode) check box. This opens the following dialog box.
NOTE: A remote requires the current Network Acquisition Key (ACC Key) in
addition to an X.509 certificate to join a TRANSEC network. The initial ACC Keys
must be manually configured on the remote using a console command as part of
this procedure.
NOTE: Evolution eM1D1 and eM0DM line cards must be licensed to operate in a
TRANSEC network. (See Managing NMS Licenses on page 60.) In addition, Protocol
Processor blades must be licensed for TRANSEC. For complete details on
requesting and installing iDirect licenses, see the iDirect Features and Chassis
Licensing Guide.
4. Following the procedure in Certifying a Host on page 473, connect to each host in your
network and issue an X.509 certificate to the host from your CA. Issue certificates in the
following order:
a. Issue a certificate to each NMS Server.
b. Issue a certificate to each Protocol Processor blade in the sub-tree of the Protocol
Processor.
NOTE: After you issue a certificate to a Protocol Processor blade, you must
restart the iDirect service before it will take effect. After issuing the certificate,
log on to the root account of the blade and enter the command service
idirect_hpb restart.
c. Issue a certificate to each line card in the sub-tree of the Protocol Processor.
d. Issue a certificate to each remote in the sub-tree of the Protocol Processor.
Figure 15-1 illustrates a single TRANSEC sub-tree in the iBuilder Tree with one blade, one line
card and two remotes. All of those network elements, plus the NMS Servers, should be
certified before you convert to TRANSEC.
NOTE: Although it is more convenient and secure to certify your remotes before
TRANSEC is enabled, there may be times when you are required to certify a non-
TRANSEC remote over the air in an existing TRANSEC network. For details on how
to accomplish this, see Bringing an Unauthorized Remote into a TRANSEC
Network on page 471.
CAUTION: Once you have converted your network to TRANSEC and applied the
changes, all remotes will be “out of network” until the current Network
Acquisition Key is configured on the remotes. This requires local access to each
remote.
Once you have ensured that all hardware is TRANSEC-compatible, all licenses are in place,
and you have issued certificates to all X.509 hosts, follow these steps to convert your network
to TRANSEC:
1. Ensure that the Minimum MODCOD and Maximum MODCOD of the DVB-S2 downstream
carrier are set to the same value. (See Adding Downstream Carriers on page 77.)
2. Ensure that Superburst acquisition is not enabled for any TDMA upstream carriers.
Superburst is not supported in TRANSEC networks.
3. Right-click the Protocol Processor in the iBuilder Tree and select ModifyItem.
The Protocol Processor dialog box opens with the Information tab selected.
7. In the Automated Configuration Downloader dialog box, select the following options:
a. In the Remotes area of the dialog box:
• Select all remotes.
• Under Target, select Both.
• Under Protocol, select Reliable (TCP).
• Under Reset, select Reset on Success.
b. In the Line Cards area of the dialog box:
• Select all line cards with Status of Changes Pending.
• Under Protocol, select Reliable (TCP).
• Under Reset, select Reset on Success.
c. In the Network area of the dialog box, select your network.
8. Click the Start button to apply the changes to your network.
9. Repeat Step 6 through Step 8 for any remaining networks under your TRANSEC Protocol
Processor.
10. Right-click the Protocol Processor in the iBuilder Tree and select ApplyConfiguration.
11. In the confirmation dialog box, click Yes to confirm the change.
12. Configure the current ACC Keys on all remotes. (See the next section for details.)
NOTE: This procedure requires physical access to the remote modem. It cannot
be performed from the NMS.
Before the local procedure in this section is executed at the remote site, the network
operator should perform the following steps while the remote is still in the TRANSEC network:
1. In iBuilder, move the remote to the non-TRANSEC network to generate the new remote
options file.
CAUTION: Do not apply the remote-side changes in iBuilder to move the remote
to the non-TRANSEC network until the secure data has been removed from the
remote. The remote must be in the TRANSEC network to remove the secure data.
2. Supply the non-TRANSEC remote options file to the on-site personnel who will remove the
secure data from the remote.
3. Follow the procedure in Revoking a Remote’s Certificate on page 474 to invalidate the
remote’s X.509 certificate.
The remaining steps in this section require physical access to the remote modem. The
procedure assumes that you have all of the following items available locally:
• A copy of the new (non-TRANSEC) options file
• A console connection to the remote modem
• Ethernet connectivity to the remote modem through the LAN port
• A secure copy client such as WinSCP installed on your laptop
Follow these steps to remove the secure data from the TRANSEC remote and to re-configure
the remote for the non-TRANSEC network:
1. Open a console session to the remote modem and log on to the root account of the
remote.
The NMS server processes can be distributed across multiple NMS server machines. The
primary benefits of machine distribution are improved server performance and better use of
disk space.
iDirect recommends a distributed NMS server configuration once the number of remotes being
controlled by a single NMS exceeds approximately 800.
A.1 Prerequisites
The prerequisites for setting up a Distributed NMS are:
• Four NMS servers, each installed with the same version of NMS software. Three of these
servers run various services and the fourth is a backup server. Existing systems with a
single Primary NMS server and a single Backup NMS server require two additional NMS
servers installed with the same version of software as the current Primary NMS.
NOTE: For information on setting up a Backup NMS server, see the iDirect
Technical Note “NMS Redundancy and Failover.”
• IP addresses for all additional NMS servers must be on the same subnet as the Primary and
Backup servers. These servers are on the upstream side. IP connectivity between all
servers is required.
• The MySQL database passwords must be identical on all NMS server machines of a
Distributed NMS. If the MySQL database passwords on the existing NMS server have been
changed from the default passwords, use the dbPasswd command to configure the same
passwords on the remaining servers.
• For NMS servers with private IP addresses that require external access for running iBuilder
and iMonitor, there are two options: configure a VPN system to allow access to the
servers; or NAT the private addresses to the public addresses and run the iDirect-provided
script on every client PC that will run iBuilder and iMonitor clients. See Running the NAT
Script on page 462 for the script.
configured, the distribution of server processes across machines remains unchanged unless
reconfigured. This is true even when upgrading to a new release.
The standard distribution scheme is shown in Figure A-1.
This configuration has the following process distribution for the main processes:
• NMS Server 1 (Primary) runs the configuration server (nmssvr) and MySql, the chassis
manager server (cmsrv), and the Protocol Processor controller process.
• NMS Server 2 (Auxiliary) runs only the Statistics server (nrdsvr).
• NMS Server 3 (Auxiliary) runs the Event server (evtsvr) and the Latency Server (latsvr).
The latsvr is not shown in Figure A-1.
location of all other NMS servers and provides this information to the iBuilder or iMonitor
client. Using this information, the client automatically establishes connections to the server
processes on the correct machines.
NOTE: The NMS server processes must be stopped briefly when setting up a
distributed NMS for an operational network.
NOTE: Step 7 and Step 8 of the following procedure are only required to retain
the historical statistics and events data in the NRD archive. If this is not required,
skip these steps.
NOTE: The following steps must be performed during a maintenance window. NMS
downtime will occur.
14. Stop the NMS services on NMS 1 by entering the following command:
service idirect_nms stop
15. Start the idirect_nms_config service on NMS 1 by entering the following command:
service idirect_nms_config start
16. Run the DNMS conversion script by entering the following command:
/home/nms/utils/db_maint/NMS-configuration-client.pl
The DNMS conversion script prompts to select which processes will run on which servers. In a
standard configuration, nmssvr, nms_monitor, cmsvr, cntrl, revsvr, and snmpsvr run on
NMS 1; sbcsvr and nrdsvr runs on NMS 2; and the evtsvr and the latsvr run on NMS 3.
17. Enter the number of the respective NMS when prompted. Sample output containing the
prompts and resulting server assignments is shown below.
NOTE: If this NMS shares the Chassis Manager Server of an external NMS that is
not part of this DNMS, enter a 0 when prompted for the CM Server to skip that IP
address. The procedure to point a configuration server to an external CM Server is
described in Sharing the Chassis Manager Server on page 323.
===========================================================
List of IPs, where NMS installation was presented:
===========================================================
( 0) skip assignment
( 1) 192.168.76.82
( 2) 192.168.76.80
( 3) 192.168.76.65
NMS Config Client >>> Please enter index for MySql server
(use number in parentheses above)
1
NMS Config Client >>> Server MySql assigned to IP address
192.168.76.82
NMS Config Client >>> Please enter index for CFG server
(use number in parentheses above)
1
NMS Config Client >>> Server CFG assigned to IP address
192.168.76.82
NMS Config Client >>> Please enter index for EVT server
(use number in parentheses above)
3
Note: Once these commands have been entered successfully, all the devices (remote,
HLC, network, PP) will display “Changes Pending” in iBuilder.
5. Launch iBuilder and apply the changes in the following order: all remotes, all Hub Line
Cards, network, and Protocol Processor.
2. In the Service Level area of the dialog box, select the appropriate Service Level for the
IP packet type. (NMS_UDP, NMS_TCP or NMS_ICMP).
3. In the Rules area of the dialog box, select the Rule for that traffic.
4. Click the Edit button to open the Edit Rule dialog box.
5. Change the Destination IP address and Subnet Mask to match the NMS server’s IP address
for this type of traffic. (Route TCP traffic to NMS 1; route UDP traffic to NMS 2; and route
ICMP traffic to NMS 3.)
6. Click OK to save the rule.
7. For the NMS_UDP Service Level, click Add in the Rules area of the dialog box to add a
second rule to route UDP traffic to NMS 3.
8. In the Edit Rule dialog box:
a. Configure Destination IP to be equal to the NMS 3 IP Address and Subnet Mask.
b. Configure Protocol to be equal to UDP.
c. Click OK to save the new rule.
9. Click OK to save the Application Profile.
10. In the iBuilder tree, apply all pending changes.
running on more than one server. Enter the following command on each server and verify that
the correct services are running:
ps -ef | grep svr | grep -vi mysql | grep -vi logger
A list of running services displays.
If a service is running on a server that it should not be, use the following command to kill the
service:
killall service
where service represents the name of the service
For example, if the evtsvr process is running on NMS 1, enter the following command to kill
the process:
killall evtsvr
SET ENV_LAT_NMSAPI_IPADDR=x.x.x.x
Where x.x.x.x represents the IP address of NMS 3
imonitor.exe
3. Rename the Note Pad file to iMonitor.bat.
4. Save the file to the same directory where iMonitor is located.
The various forms of the NMS-configuration-client.pl command are shown here. Typically, no
command arguments are required to configure a distributed NMS.
# ./NMS-configuration-client.pl –h
NMS-configuration-client.pl [-cd=NAME] [-ad=NAME]
[-udp=UDPPORT] [-bcast=BCASTADDRESS]
-cd : Change config database from [nms]
-ad : Change archive database from [nrd_archive]
-udp : Change default UDP port [70123]
-bcast: Change default bcast address[255.255.255.255]
-vvv : verbose mode level equals number or v(s)
-qos : reload service level QoS rules -- do not use it
-h : print help
The NMS-domain-commands.pl command stops, starts or restarts the NMS server processes
on all NMS machines. The command cab be executed on any of the server machines.
The various command forms are displayed by entering the -h option:
./NMS-domain-commands.pl -h
Usage:
NMS-domain-commands.pl [-udp=UDPPORT] [-exec="<command> <server
name> <server name> ..."
-udp : Change default UDP port [70123]
<command> is <start | stop | restart | reload | status >
<server name> is <nmssvr | evtsvr | nrdsvr | latsvr | cntrlsvr |
snmpsvr | nms_monitor>
For example, the following two commands show the status of NMS server processes. The first
example shows the status of all processes. The second example shows the status of the
nms_monitor process.
./NMS-domain-commands.pl -exec="status"
./NMS-domain-commands.pl -exec="status nms_monitor"
The following commands start, stop and restart server processes. The first example starts all
processes. The second example stops all processes. The third example starts the evtsvr
process. The final example restarts the latsvr process.
./NMS-domain-commands.pl -exec="start"
./NMS-domain-commands.pl -exec="stop"
./NMS-domain-commands.pl -exec="start evtsvr"
./NMS-domain-commands.pl -exec="restart latsvr"
All hosts in an iDirect TRANSEC network must have X.509 public key certificates. Hosts include
NMS Servers, Protocol Processor blades, TRANSEC line cards, TRANSEC remotes, and GKD
Servers. Certificates are required to join an authenticated network. They serve to prevent
man-in-the-middle attacks and they add an additional safeguard against unauthorized
admission to the network. You can use the iDirect Certificate Authority (CA) utility (called the
CA Foundry) to issue the certificates for your TRANSEC network. For more information on the
iDirect TRANSEC feature, see the iDirect Technical Reference Guide.
This appendix contains the procedures required to issue and manage the X.509 certificates in
an iDirect TRANSEC network. It contains the following major sections:
• Accessing the CA Foundry on page 467
• Creating a Certificate Authority on page 469
• Logging On to a Certificate Authority on page 470
• Connecting to a Host on page 470
• Bringing an Unauthorized Remote into a TRANSEC Network on page 471
• Certifying a Host on page 473
• Revoking a Remote’s Certificate on page 474
NOTE: All certificates for a TRANSEC network must be generated by the same CA
foundry.
NOTE: SH can not be used to log on directly to the root account of an NMS server
or Protocol Processor blade. Instead, use SSH to log on to another account such as
the idirect account. Then enter su - from the command line to log on as root.
2. At the command line prompt, enter the ca command to display the initial CA Foundry
menu shown in Figure B-2. Once you have created a CA and logged on to it, more menu
choices will become available.
For details on specific CA Foundry operations, see the remaining sections in this appendix.
3. When prompted, enter the information for your new CA. A CA name and password are
required. The remaining entries are optional.
4. Press any key to continue. You will be automatically logged on to the new CA.
connecting first. If not connected to a host, the CA Foundry will prompt for the required host
information and establish the connection before executing the operation.
NOTE: When certifying a new remote in a TRANSEC network, please see Bringing
an Unauthorized Remote into a TRANSEC Network on page 471. The remote must
have authentication disabled and it must be configured with the current Network
Acquisition Key before it can acquire the TRANSEC network.
• After the options file is loaded, the current Network Acquisition Keys must be configured
on remote before the remote can acquire the TRANSEC network. This requires access to
the remote console.
Once the remote options file (with authentication disabled) and the ACC Keys are present on
the remote, the remote will be able to acquire the TRANSEC network. At that point, you can
use the CA Foundry to connect to your remote over the air and issue the X.509 certificate.
Follow these steps to certify the remote in your TRANSEC network. This procedure assumes
that the remote has been configured in the TRANSEC network in iBuilder and that
Authentication has not yet been disabled on the GUI.
1. In iBuilder, right-click the remote in the iBuilder Tree and select ModifyItem to display
the Information tab of the remote configuration dialog box.
2. Select the Disable Authentication check box.
3. When the warning message appears, click Yes to confirm the change.
NOTE: As an alternative, you can wait and transfer the options file and the ACC
Key to the remote site at the same time. In either case, the options file must be
loaded onto the remote (Step 8) before the remote will accept the ACC Key
(Step 9).
8. Have the on-site personnel load the options file on the remote using iSite. The procedure
for downloading an options file using iSite is documented in the Installation and
Commissioning Guide for iDirect Satellite Routers.
9. Follow the procedure Configuring the ACC Key on a Remote on page 477 to retrieve the
current Network Acquisition Key from the hub and to configure it on the remote. Once the
remote has its ACC keys, it should acquire the TRANSEC network.
10. Use the CA Foundry to connect to the remote over the air and issue the X.509 certificate.
(See Certifying a Host on page 473 for details.)
11. Once the remote has its certificate, return to the remote configuration dialog box, clear
the Disable Authentication check box, and click OK.
12. Right-click the remote in the iBuilder Tree and select Apply ConfigurationReliable
Both (TCP) to download the configuration change.
NOTE: After you issue a certificate to a Protocol Processor blade or a GKD server,
you must restart the iDirect service before it will take effect. After issuing the
certificate, log on to the root account of the blade or GKD server and enter the
command service idirect_hpb restart (blade) or service
idirect_gkd restart (GKD).
NOTE: Before certifying an auxiliary NMS server for a distributed NMS, log on to
the root account of the server and enter the command service idirect_nms
start nmssvr to start the nmssvr process. Once the auxiliary server has been
certified, stop the nmssvr process with the command service idirect_nms
stop nmssvr.
You can use the procedure in this section to certify a new host or to update the certificate on
an existing host. Your NMS Server must have IP connectivity to the host to issue a certificate.
Follow these steps to issue a certificate to a host.
1. Start the CA Foundry and log on to a CA according to the procedure on page 470.
2. Use the arrow keys to select Host Operation from the top-level menu and press Enter.
3. Select Flush Host from the menu and press Enter.
NOTE: Select Flush Host rather than Generate Host Key and Cert. The Flush Host
command performs all operations required to certify the host.
NOTE: When certifying a TRANSEC line card, it is possible that the CA will time
out due to high CPU loading on the line card. If this happens, wait a few minutes
and execute the Flush Host command again.
The CA Foundry will issue a new X.509 certificate to the host, signed by your CA. Sample
output is shown in Figure B-11.
1. Using iBuilder, right-click the remote in the iBuilder Tree and select View
PropertiesItem.
2. Note the number in Derived ID field of the remote Information tab.
3. Start the CA Foundry and log on to a CA according to the procedure on page 470.
4. Use the arrow keys to select Maintenance from the top-level menu and press Enter.
5. Select Show Issued Certs from the Maintenance menu and press Enter.
6. In the Subject field of the command output, note the highest CA serial number that
matches the DID determined in Step 1. (In the case that the CA has multiple certificates
for a single remote, the one with the highest serial number is the certificate currently in
use.)
7. Select Revoke Certificate from the Maintenance menu and press Enter.
8. At the prompt, enter the serial number of the certificate to be revoked as determined in
Step 6 and press Enter. Sample output is shown in Figure B-15.
The updated blades will no longer allow the remote to enter the TRANSEC network.
10. To ensure that the remote leaves the network immediately, force two updates of the
Dynamic Network Keys (DCC Keys). The procedure for updating the DCC Keys is
documented in Updating the DCC Keys on page 479.
11. To ensure that the remote’s Network Acquisition Keys (ACC Keys) are no longer valid,
force two updates of the ACC Keys. The procedure for updating the ACC Keys is
documented in Updating the ACC Keys on page 480.
CAUTION: Use great caution when updating the ACC Keys. Any remote that misses
two consecutive ACC Key updates will be stranded. A site visit is required to re-
configure the ACC keys on the remote.
This appendix contains procedures for managing TRANSEC keys. It includes the following
major sections:
• Configuring the ACC Key on a Remote on page 477
• Updating the DCC Keys on page 479
• Changing the DCC Key Update Frequency on page 480
• Updating the ACC Keys on page 480
• Verifying the ACC Keys on an In-Network Remote on page 482
• Identifying the Blade that Distributes TRANSEC Keys on page 485
NOTE: A remote’s DID is displayed on the Remote Information tab in iBuilder. The
passphrase will be required to update the ACC key on the remote modem.
The Protocol Processor displays a string consisting of three lines (or “segments”). This
string represents the ACC Key. The key as represented by the string is encrypted using the
Password-Based Key Derivation Function (PBKDF2) described in PKCS #5 v2.1: Password-
Based Cryptography Standard from RSA laboratories.
Figure C-1 shows sample output for the getGACCkey command.
7. Securely transfer the three string segments to the personnel responsible for entering the
new key on the remote modem.
To update the ACC Key on the remote modem:
1. From the console port, log on to the root account of the remote.
2. Enter the command:
telnet localhost
3. At the Username prompt, log on to the admin account.
4. At the command line prompt, enter the command:
csp enable
5. Enter the command:
keyroll_mgr setACCKey
6. At this point, you will be prompted for each of the three segments (lines) of the
encrypted key and the “passphrase” from Step 6 on page 478. Respond to each prompt
with the requested information. You can type uppercase Q to quit at any time.
7. When asked if you want to continue, enter:
Yes
You should see a message stating that the Network Acquisition Key has been updated. At
this point, if the TRANSEC network is up and the remote is certified, the remote should
acquire the outbound carrier.
8. Once the remote acquires the network, to check the status of the remote, enter the
remotestate command. Sample output is shown below.
remotestate
TX Power: -26.000000 dbm
TX Freq: 1115.000000 Mhz
FSD: 0
Assigned IGroup: 1
Assigned HDLC: 0xd
Assigned UID: 0x40 - 0x4e, 0x4f
TXer State: ON
RXer Lock: LOCKED
Modem State: In Network
Link Layer State: In Data Transfer
Transec: Up
NOTE: Step 8 assumes the remote already has its X.509 certificate for the
TRANSEC network. If not, the hub operator can now disable authentication for the
remote on the iBuilder Remote Information tab to allow the remote to join the
network the first time. Once it has acquired the network, the hub operator can
issue the certificate to the remote over the satellite link and then re-enable
authentication on the remote. See Bringing an Unauthorized Remote into a
TRANSEC Network on page 471 for details.
For details on the TRANSEC key management protocol, see the iDirect Technical Reference
Guide.
CAUTION: Use great caution when updating the ACC Keys. Any remote that misses
two consecutive ACC Key updates will be stranded. A site visit is required to re-
configure the ACC keys on the remote.
NOTE: Even if a valid ACC Key is present on a de-certified remote, the remote
cannot send or receive traffic if you have performed two DCC Key updates.
When using Local Mode (ACC Keys generated by the Protocol Processor blades), you must
execute the ACC Key update from the blade that is generating your ACC Keys. If you have one
or more GKDs configured for your TRANSEC network, you must execute the ACC Key update
from the Master GKD. (For more information, see Global Key Distribution on page 487.)
Follow these steps to update the ACC Keys in a TRANSEC network:
1. If using Local Mode:
a. Follow the steps in Identifying the Blade that Distributes TRANSEC Keys on page 485
to determine the Protocol Processor blade responsible for key distribution.
b. Log on to the idirect account of the blade.
c. At the command line, enter the following command:
telnet localhost 13255
d. At the prompt, log on to the admin account.
2. If you have one or more GKDs configured for your TRANSEC network:
a. Log on to the root account of the Master GKD Server.
b. At the command line, enter the command:
telnet 0 46002
c. At the Username prompt, log on to the admin account. (The default password is
iDirect.)
3. On the GKD or the Protocol Processor blade responsible for generating the ACC Keys,
enter the following command to enable security commands:
csp enable
4. If this is a GKD Server, verify that this is the Master GKD by entering the command:
kd status
5. To update ACC Keys, enter the command:
kd keyroll update confirm
NOTE: The ACC Key update may take several minutes to complete. Therefore,
wait at least an hour before executing the kd keyroll update command a
second time.
6. To ensure that no unauthorized hosts have a valid ACC Key, wait at least one hour and
repeat Step 5.
CAUTION: Any remote that misses two consecutive ACC Key updates will be
stranded. A site visit is required to re-configure the ACC keys on the remote.
Figure C-3. Viewing the ACC Key Data Structure on the Protocol Processor
5. Note the number of the active key. (The active key is Key 0 in Figure C-3.)
NOTE: If you have one or more GKDs configured for your network, it is possible
that the ACC Keys have been updated on the Master GKD but have not yet been
accepted by the Protocol Processor blade. You can enter the kd keyroll show
command on the Master GKD to ensure that the active key on the GKD matches
the active key on the Protocol Processor blade.
6. From the root account of the NMS server, enter the following command to open a secure
connection the remote.
ssh <ip address>
where <ip address> is the IP address of the remote.
7. When prompted, enter the remote’s admin password.
8. Enter the following telnet command and log on with Username admin and the remote’s
admin password:
telnet localhost
Step 6 through Step 8 are illustrated in Figure C-4.
Figure C-5. Viewing the Key Roll Data Structure on a Remote Modem
11. Compare the ACC Key output of the key_mgr command on the Protocol Processor (Step 4)
with the ACC Key output of the remote keyroll_mgr key command. The active key
numbers should be the same. In the example in Figure C-6, the remote has successfully
received the latest ACC Keys. Therefore the number of the active key on the Protocol
Processor (on the left) is identical to the number of the active key on the remote (on the
right).
If the ACC Keys were updated again and the remote had not yet received the new key, Key 1
would become the active key on the Protocol Processor but the remote active key would
remain the same. This is shown in Figure C-7.
NOTE: The blade responsible for sending the TRANSEC keys to a network is always
the same blade that is responsible for multicast traffic for that network.
You must know both the Protocol Processor ID and the Network ID to determine the Protocol
Processor blade responsible for propagating the keys to your network. Follow these steps to
determine the IDs:
1. In iBuilder, select Details from the View Menu.
2. Select Collapse Details Hierarchy from the View Menu
3. Click your Teleport in the iBuilder Tree
4. Click the Type column heading in the Details View to sort elements by Type.
5. Scroll down until you find the IDs of both your network and your protocol processor. In
Figure C-8, the Network ID for TRANSEC Network 1 is 9. The Protocol Processor ID for
TRANSEC Protocol Processor is 2.
Once you have determined the Network ID and the Protocol Processor ID, you must identify
the Protocol Processor blade responsible for multicast traffic for your network. This is the
blade responsible for sending out the TRANSEC Keys.
Follow these steps to determine the blade that sends the TRANSEC Keys to your network:
1. Log on to the idirect account of your NMS server.
2. Enter the following command to connect to the pp_controller process for your protocol
processor.
telnet localhost <pp_controller port_number>
where <pp_controller port_number> is 15000 + the Protocol Processor ID. For the
example in Figure C-8, you would enter the command telnet localhost 15002, since
the Protocol Processor ID is 2. if the Protocol Processor ID were 11, you would telnet to
port number 15011.
3. At the Username prompt, log on to the admin account of the Protocol Processor.
4. From the command line, enter the following command to determine the Tunnel Interface
IP Addresses of all blades responsible for multicast for this Protocol Processor:
blades query multicast
Sample output of this command is shown in Figure C-9. In the figure, the Tunnel Interface
IP Address (eth1) of the multicast blade for Network ID 9 is 192.168.77.230.
NOTE: This command returns the Tunnel Interface IP address of your blade, not
the Upstream Interface IP Address. You can view both IP Addresses on the Protocol
Processor Blade dialog box in iBuilder.
Global Key Distribution is required to generate the Network Acquisition Keys (ACC Keys) used
by remotes to join TRANSEC networks. Global Key Distribution is also required to manage
Multicast Fast Path encryption keys for Evolution X7 remotes that receive encrypted Multicast
Fast Path traffic over a second demodulator. This appendix contains procedures for
configuring networks to use Global Key Distribution to generate either TRANSEC Network
Acquisition keys (ACC Keys) or Multicast Fast Path encryption keys and distribute them to the
Protocol Processors that require them. An instance of the Global Key Distribution software
application running on a Linux server is called a Global Key Distributor (GKD). A Linux server
running the GKD application is called a GKD Server.
This appendix includes the following major sections:
• Reasons for Global Key Distribution on page 487
• Setting Up Global Key Distribution on page 488
• Additional GKD Procedures on page 495
• Setting Up Global Key Distribution for Encrypted Multicast Fast Path on an X7 Second
Demodulator on page 500
NOTE: The same GKD Server cannot generate both TRANSEC ACC Keys and
Multicast Fast Path encryption keys.
Protocol Processor blades generate the ACC Keys is called Local Mode. However, Local Mode
should not be used due to the following limitations:
• In Local Mode, ACC Key management is not redundant across Protocol Processor blades.
Therefore, if the blade generating the ACC Keys for a TRANSEC network fails, the new
blade responsible for ACC Key generation for that network is not guaranteed to be
synchronized with the remotes. If the ACC Keys are not synchronized between the blade
and the remotes, remotes that are not in the network when the keys change cannot re-
acquire until the new keys have been manually configured on the remote. This requires
local access to those remotes.
Configuring GKDs for TRANSEC networks ensures that the ACC Keys are synchronized
across all blades that send the ACC Keys to the remotes. If a blade fails or the Protocol
Processor software restarts, the ACC keys do not change and local reconfiguration of
remotes that are out-of-network when the keys change is not required. In addition, GKD
redundancy prevents the keys from being regenerated if a GKD Server fails.
• Remotes that use iDirect’s Automatic Beam Selection (ABS) feature must be able to move
from network to network as they travel across the globe. If an ABS remote in one network
attempted to acquire a new network with different ACC Keys, acquisition would fail.
Therefore, ACC Keys must be the same on any network that the remote is allowed to join.
Synchronizing the ACC Keys across TRANSEC networks using GKD Servers allows ABS
systems to meet this requirement.
KeyDistributor KeyDistributor
Master GKD
KeySync KeySync
KeyDistributor
KeySync
PP Blade PP Blade
KeySync KeySync
PP Blade PP Blade
KeySync KeySync
In any established network of GKDs, there is only one Master GKD. The Master GKD is
responsible for generating the ACC Keys for all Protocol Processors that have that GKD
configured under it in iBuilder. All other GKDs (called Backup GKDs) are responsible for
synchronizing their keys with the Master GKD.
Each GKD is configured with a unique priority. The highest-priority GKD is the “configured
Master” GKD. If the configured Master GKD fails, the highest-priority Backup GKD becomes the
“promoted Master” GKD. When the configured Master GKD recovers, it resumes the function
of key generation and the promoted Master returns to the Backup role. Similarly, if a backup
GKD loses connectivity to the Master GKD and promotes itself to Master, it returns to Backup
status when connectivity to the configured Master GKD is restored.
A Protocol Processor blade responsible for distributing or using keys generated by a GKD
Server attempts to synchronize its keys with the Master GKD. However, if the blade cannot
communicate with the Master GKD, it may synchronize with a Backup GKD. If the blade cannot
communicate with any GKD, new keys are not generated for the network.
NOTE: In order to minimize the possibility that TRANSEC remotes do not have a
valid ACC Key, a Protocol Processor blade that has received a new ACC Key from a
GKD will not accept the next ACC Key for one hour. This one hour wait is not
enforced if key updates are performed manually using the kd keyroll update
confirm command. (See Updating the ACC Keys on page 480.)
The following sections explain how to install and run one or more GKDs.
NOTE: When multiple GKDs are configured, the relative priorities of the GKDs
determine which active GKD will assume the roll of Master. The highest-priority
operational GKD serves as the Master GKD responsible for generating the keys.
NOTE: Wait until you have created the GKD options files and started the GKDs to
apply the changes to the Protocol Processor. (See Certifying and Starting the GKD
Server on page 494.)
The example uses a Protocol Processor configured in iBuilder with three GKDs. The options file
for the GKD with priority 30 is shown below.
[GKD_NODE_10]
connect_addr = INET;192.168.77.27;45001
priority = 10
[GKD_NODE_20]
connect_addr = INET;192.168.77.30;45001
priority = 20
[GKD_NODE_30]
connect_addr = INET;192.168.77.32;45001
priority = 30
[GKD_LOCAL_CFG]
priority = 30
Note the following points regarding the sample GKD options file:
• The GKD_NODE definitions give the IP address and port number for all GKD Servers in the
GKD network as configured in iBuilder. In this case there are three GKD Servers. These
GKD_NODE definitions must be included in the GKD options file of each GKD.
• All priorities in the GKD options file must match the priorities configured for the GKD in
iBuilder. Priorities must be unique. No two GKD Nodes in an options file can have the same
priority.
• All GKD_NODE numbers must match the priorities configured in iBuilder. For example,
GKD_NODE_20 must have priority = 20.
• The GKD_LOCAL_CFG definition at the end of the options file identifies this GKD. Since
GKD_LOCAL_CFG priority is 30 in the example, this is the options file for the GKD running
on 192.168.77.32. The options file for GKD_NODE_20 would be identical to this options
file except that the final line defining the GKD_LOCAL_CFG would be priority = 20.
• Since it has the highest priority, GKD_NODE_30 is the Configured Master for this group of
GKDs. In other words, if all three GKDs are operational and connected, GKD_NODE_30 will
always assume the role of Master GKD.
• TRANSEC GKD options files are backward-compatible with pre-iDX 3.2 iDirect releases
that supported Global Key Distribution of ACC keys. It is not necessary to change existing
GKD options files when upgrading to iDX Release 3.2 or later.
Figure D-14. Protocol Processor Options File with GKD Node Definitions
4. Delete everything from the options file except the GKD_NODE definitions.
5. Add the following to the end of the options file:
[GKD_LOCAL_CFG]
priority = <This Node’s Priority>
where <This Node’s Priority> is the priority of the GKD that will use this options
file.
6. Select FileSave As and save the file in the folder of your choice with the name of your
choice.
7. Using WinSCP (or any other method) transfer the file to the idirect account of the GKD
Server machine.
8. Log on to the root account of the GKD Server identified by GKD_LOCAL_CFG.
NOTE: Each GKD options file must be named gkd_opts.opt and must be present
in the directory /etc/idirect/gkd on the GKD Server.
To create the options files for the other two GKDs in the example, make two additional copies
of this options file and change the GKD_LOCAL_CFG definitions to match the priorities of the
other two GKDs.
NOTE: When certifying a GKD Server, you must enter port 45010 when prompted
for the port number. Do not use the default port number.
4. The GKD must be restarted after it receives its certificate. Enter the following command
to restart the GKD:
service idirect_gkd restart
5. To run the GKD service automatically at startup, enter the command:
chkconfig idirect_gkd on
6. Check the status of the GKD service by entering the command:
service idirect_gkd status
Two processes (gkd and gkd_monitor) should be running.
7. In iBuilder, right-click the Protocol Processor in the iBuilder Tree and select Apply
Configuration to update the GKD configuration on the blades.
If this is the first time any GKD is being brought on line for this Protocol Processor, then when
you apply the changes to the Protocol Processor, the blade or blades that were responsible for
generating the keys for your networks will no longer have that responsibility. Instead, they
will request the keys from the Master GKD and forward them to the network.
In order not to strand remotes in TRANSEC networks, the blade will not accept more than one
new ACC Key per hour (by default) from the GKD. Therefore, a remote that is not in the
TRANSEC network at the time that the first GKD comes on line should still be able to acquire
the network for at least one hour. However, if that remote does not acquire the network by
the time the blade has synchronized both the current and next ACC Keys with the GKD, it will
be unable to acquire the network until its ACC Keys are manually updated. See Configuring
the ACC Key on a Remote on page 477.
NOTE: The default password is iDirect. You can change the password by following
the procedure in the next section.
The Admin Password is configured in iBuilder on the Information tab of the Protocol
Processor as shown in Figure D-16.
To change the password of the GKD admin account to the Admin Password of an iBuilder
Protocol Processor:
1. In the iBuilder Tree, right-click the Protocol Processor and select RetrieveSaved
Configuration.
2. Click the Save button. The options file will open in Notepad.
3. Scroll down until you find the [SECURITY] group.
4. Copy the information highlighted in Figure D-17 into the GKD options file. A sample GKD
options file is shown below.
[GKD_NODE_20]
connect_addr = INET;192.168.77.30;45001
priority = 20
[GKD_NODE_30]
connect_addr = INET;192.168.77.32;45001
priority = 30
[GKD_LOCAL_CFG]
priority = 20
[SECURITY]
admin_password =
$idi3$//kdd/$0bwUdQy2daA/d95g6/DC4KkVJ40091r0sdVSi0dqFy6lbSBO9zOiYA
qY8GtVYiCf08BricTpbNeF6C45UrNf03
5. Follow the procedure on page 493 to copy the GKD options file into the correct directory
on the GKD Server.
6. Restart the GKD service by entering the following command from the root account of the
GKD Server:
service idirect_gkd restart
7. Follow the procedure in Logging On to the GKD Console on page 495 to verify that the
password change was successful.
1. Log on to the GKD Console. (See Logging On to the GKD Console on page 495.)
2. Enter the following command:
csp enable
3. Enter the kd status command to determine the Key Distributor status of this GKD,
including:
• The Node ID of this GKD. (The Node ID equals the priority of the GKD.)
• The Current State of this Key Distributor. (Master, Backup, Promoted Master, etc.)
• The number of clients (GKDs and blades) receiving keys from this GKD.
Figure D-18 shows an example of the kd status command executed on both a Master
GKD (on the left) and on a Backup GKD (on the right).
4. Enter the ks status command to determine the Key Synchronizer status of this GKD,
including:
• The Node ID of this GKD. (The Node ID equals the priority of the GKD.)
• The Current State of this Key Synchronizer.
• If the Key Synchronizer is connected, the IP Address of the GKD supplying the keys.
Figure D-19 shows an example of the ks status command executed on both a Master
GKD (on the left) and on a Backup GKD (on the right).
5. Enter the kd clients command to determine the IP Addresses of all clients receiving
keys from this GKD. Clients include both Backup GKDs and Protocol Processor blades
responsible for distributing the keys to the networks.
Figure D-20 shows an example of the kd clients command executed on a Master GKD
with two clients.
(REG) after the client IP address indicates that this client has registered with the GKD
Server. (UNREG) indicates that the client has not registered with the GKD Server. Only
registered clients will receive key updates. Under normal circumstances, clients will
always register with the GKD Server shortly after connecting and re-register periodically.
The new key update frequency is not propagated to other GKDs. If a Backup GKD is promoted
to Master GKD, it will use its local setting unless you have also changed it in the options file of
the Backup GKD.
NOTE: The primary network refers to the iBuilder network in which the X7 remote
is configured. The secondary network refers to the network transmitting the
downstream carrier with the Multicast Fast Path traffic. For information on
configuring GKDs for secondary networks, refer to the Technical Reference Guide.
Network Configuration
On the Network tabs, there is no action necessary if the second downstream is controlled by
the local NMS for the primary network.
X7 Remote Configuration
Configure the Remotes as follows:
1. On the Remote Information tab, enable Link Encryption.
2. On the Remote VSAT-2 tab, check Multicast FastPath Encryption.
• The Multicast Fast Path streams have been configured in the secondary network. (See
Configuring Remotes for Multicast Fast Path on page 277.)
NOTE: If the Multicast Fast Path stream is to be received only by the second
receivers of X7 remotes in the primary network, skip the step for assigning the
Service Profile to remotes when configuring the MCFP streams in the secondary
network.
• The Evolution X7 remotes’ second receivers have been enabled and configured to receive
the Multicast Fast Path Streams in the primary network. (See Remote VSAT-2 Tab on
page 207.)
NOTE: An Evolution X7’s primary and secondary networks may be managed by the
same Protocol Processor, by different Protocol Processors, or even by different
Network Management Systems.
Enabling both primary and secondary networks to receive the Multicast Fast Path encryption
keys from the GKD requires configuring the Protocol Processors, Networks, and Remotes for
both networks using iBuilder client.
Network Configuration
Configure the Network as follows:
1. At the Network Information tab, click Multicast Encryption and Multicast Overlay. See
Figure D-25.
2. Click OK.
NOTE: There is no action necessary at the Network Information tab if the second
downstream is controlled by the local NMS for the primary network.
X7 Remote Configuration
Configure the Remotes as follows:
1. Right-click the X7 remote in the secondary network and select ModifyItem from the
menu.
2. Click the Custom tab.
3. In the Hub-side Configuration pane, enter the following Custom Key:
[RMT_FASTPATH_RX2]
encryption = 1
base = 0xffe0
bitmap = 0x000X
Where, X represents the number of channels (in hex value; for instance, 0x0001 to
represent channel 1) where the remote will be receiving the Multicast Fast Path traffic.
4. In the Remote-side Configuration pane, enter the following Custom Key:
[ENC]
enc_enabled = 1
enc_mode = 6
5. Click OK to save the changes to the remote.
Figure D-26. Protocol Processor Options File with GKD Node Definitions
4. Delete everything from the options file except the GKD_NODE definitions.
5. If creating a GKD options file for generating Multicast Fast Path Encryption keys, add the
following to the beginning of the options file:
[GKD_KEY_0]
gkd_key_name = multicast_pp1_tx_key
[GKD_KEY_1]
gkd_key_name = multicast_pp1_rx_key
[GKD_NODE_10]
priority = 10
connect_addr = INET;{Primary PP tunnel interface IP};45001
Where, {Primary PP tunnel interface IP} is the tunnel interface IP address of the PP on
the primary network.
NOTE: All instances of the gkd_key_type keys must be removed from the options
file as well.
NOTE: Each GKD options file must be named gkd_opts.opt and must be present in
the /etc/idirect/gkd directory on the GKD Server.
To create the options files for the other two GKDs in the example, make two additional copies
of this options file and change the GKD_LOCAL_CFG definitions to match the priorities of the
other two GKDs.
NOTE: Evolution X1 and e150 remotes do not support Automatic Beam Selection.
NOTE: When using the iDirect TRANSEC feature for ABS networks, Global Key
Distribution is required to ensure that the Network Acquisition Keys are the same
for all networks. A remote cannot roam from one TRANSEC network to another
unless these keys are the same. See Global Key Distribution on page 487 for
details.
For most parameters in map.conf, the default settings are identical and can be left
unchanged for standard installations. However, note the following differences in Figure E-1:
• For Intelsat format, conveyance_file should be set to curr.in and
conveyance_format should be set to intelsat.
• For GXT format, conveyance_file should be set to Beams and conveyance_format
should be set to gxt_dir.
If ABS was already in use before upgrading to this release, map.conf should already exist on
the NMS server machine. When setting up ABS for the first time, use the template file
(/etc/idirect/map/map.conf.template) on the map server machine to create map.conf. Copy
the template file to map.conf and edit the file to comply with the format if necessary.
NOTE: This procedure is valid only if the map server process is running on an
iDirect server such as the NMS server or GKD server. It is not valid for a local map
server process co-located with the remote modem.
Execute the procedure in this section during the initial set up of the ABS feature. Re-execute
the procedure at any time to add a new beam to the beam map file.
NOTE: The beam name used in the conveyance beam map file must exactly match
the name of the network configured for that beam in iBuilder. For example, if a
beam name in the conveyance file is Beam_10, then the name configured in the
iBuilder Tree for the corresponding network must also be Beam_10.
The satellite provider delivers conveyance beam map files to the customer in a pre-defined
format. This format is defined in a specification document agreed upon between the beam
provider and iDirect. iDirect provides each ABS customer with a software utility that converts
the conveyance beam map files into a format that is usable by the map server. Once the
conversion is complete and the map server must be restarted, the new beam becomes
available for the map server to send to remotes using ABS.
Follow these steps to convert a conveyance beam map file from the satellite provider into the
map server format and make it available for use in your networks.
1. Log on to the map server machine as root.
2. Change to the map server directory:
cd /etc/idirect/map
3. If using the Intelsat format:
a. Copy the conveyance beam map file into the /etc/idirect/map directory using an
appropriate form of file transfer such as CD-ROM or WinSCP.
b. Enter the following command to copy the conveyance beam map file to the file name
curr.in:
Follow these steps to modify one of the pre-configured ABS antenna definitions:
1. In iBuilder, right-click the reflector in the Remote Antenna ComponentsReflector
folder and select ModifyItem to open the Reflector dialog box (Figure E-2).
2. Enter the Size of the Reflector in meters.
3. Enter the Offset Angle in degrees.
4. Select Controllable.
5. Select the Controller Type for the antenna.
6. On the right-hand side of the dialog box (Figure E-2) you can define multiple Elevation /
Gain pairs, each of which represents the variation in antenna gain for a specific satellite
elevation. You can enter as many as 91 values, one for each degree between zero and 90,
inclusive.
During beam acquisition, iDirect uses these data points to interpolate the gain variation
for the elevation at the remote’s current location. This gain variation is used in the
calculation of initial transmit power. (See the iDirect Technical Reference Guide for
details on how the initial transmit power is calculated.)
NOTE: Elevation / Gain pairs are only applicable to flat plate antennas with
multiple plates. For all other antenna types, leave this area blank. To configure
an applicable antenna, contact the antenna manufacturer for the correct data.
NOTE: When entering Elevation / Gain pairs, values must be added for both 0o
and 90o. If these two values are not included, some gain variations will be
undefined.
NOTE: To modify or remove an existing Elevation / Gain pair, select the entry and
clicking the Edit or Delete button. (See Figure E-2.)
7. When using OpenAMIP, you can also define Skew Angle / Gain pairs (Figure E-2). Skew
angle gain affects the maximum emitted power spectral density.
Skew Angle / Gain pairs are configured in the same manner as Elevation / Gain pairs. (See
Step 6 on page 512.) The skew angle range is from zero to 90 degrees. As the configured
skew angle increases, the configured gain must decrease in value.
NOTE: Skew Angle / Gain pairs are only applicable to flat plate antennas using
the OpenAMIP antenna controller protocol.
3. In the Remote Antenna section of the dialog box, enter the antenna components for the
antenna. (See Remote VSAT Tab on page 201 for details on configuring the fields shown in
Figure E-4.)
4. To enable ABS for this remote, select one of the following for the Reflector, as shown in
figure Figure E-5.
• OpenAMIP. (An open antenna controller protocol developed by iDirect.)
• DAC-97. (Used for any supported SeaTel DAC antenna controller: DAC-97 DAC-03,
DAC-2200, or DAC-2202)
• Spacetrack 4000 for Schlumberger Spacetrack 4000
• AL-7104 for the Orbit-Marine AL-7104
When a Reflector is selected that supports ABS, additional configuration fields appear in the
Remote Antenna section of the remote VSAT tab. Many of these fields apply to all ABS
antennas. Other fields apply only to specific antenna types or to antennas controlled by the
OpenAMIP protocol. The two columns on the right of Figure E-6 show the fields that apply to
all ABS antennas. Additional fields appear on the bottom right of the screen when you select
DAC-97, Al-7104 or OpenAMIP. Those additional fields are discussed later in this section.
NOTE: The ABS-specific fields appear on the right-hand side of this screen only
after a controllable Reflector is selected.
2. The Hunt Frequency is the L-Band hunt frequency programmed into the antenna
controller. This frequency may be different for different instances of the roaming remote,
depending on the beam in which that remote instance is defined.
For Hunt Frequency, select Inherit From Downstream Carrier to automatically inherit
the remote’s L-Band receive frequency for each instance of the remote. Select Override
to enter a different value in MHz.
7. If you select a reflector configured to use the OpenAMIP controller type, the OpenAMIP
parameters shown on the left of Figure E-7 appear on the VSAT tab. To configure these
parameters:
a. In Tx Frequency, enter the center frequency of the transmit carrier.
b. In Tx Bandwidth, enter the width of you transmit carrier.
c. In Hunt Bandwidth, enter the width of the Hunt Frequency.
d. In Tx Local Oscillator, enter the frequency of your transmit local oscillator. This
should match the Frequency Translation field configured for the remote’s BUC.
e. In Rx Local Oscillator, enter the frequency of your receive local oscillator. This should
match the Frequency Translation field configured for the remote’s LNB.
8. The SeaTel DAC controller type should be used for any of the four SeaTel antenna
controllers supported by the ABS feature. If you select a reflector configured to use the
SeaTel DAC controller type (such as DAC-97), the SeaTel parameters shown in the center
of Figure E-7 appear on the VSAT tab. To configure these parameters:
a. Select the LNB Voltage. This is the nominal voltage being supplied by external
equipment to the LNB. You can select either 13V or 18V. The default value is 18V.
b. Select 22 kHz Tone to tell the antenna controller to enable the 22 kHz tone to the
LNB.
c. DAC 97 distinguishes a SeaTel DAC-97 from the other supported SeaTel DAC variants
(DAC-03, DAC-2200, or DAC-2202). Select this check box only if using a DAC 97
antenna controller.
d. Enter the NID. This is the Network ID of the DVB-S2 carrier specified by the Hunt
Frequency and Hunt Polarity.
e. Enter a value for DVB_FEC. This is the FEC rate of the DVB carrier specified by the
Hunt Frequency and Hunt Polarity.
9. If you select a reflector configured to use the Orbit SBC controller type (such as AL-7104),
the Orbit SBC parameters shown on the right of Figure E-7 appear on the VSAT tab. To
configure these parameters:
a. Select the LNB Voltage. This is the nominal voltage being supplied by external
equipment to the LNB. You can select either 13V or 18V. The default value is 18V.
b. Select 22 kHz Tone to tell the antenna controller to enable the 22 kHz tone to the
LNB.
NOTE: In addition, for high-speed (greater than 150 mph) applications, a number
of custom keys and iBuilder settings should be set for your networks and remotes.
See COTM Settings and Custom Keys on page 529 for details.
NOTE: Custom keys in the [BEAMS_LOCAL] group only apply to the remote
instances on which they are defined. For a custom key in the [BEAMS_LOCAL]
group to apply to all instances of a remote, the custom key must be added to the
remote in each of the remote’s networks. See Configuring the Network
Acquisition Timers on page 518 and Changing the Download Timeout on page 518.
The general steps for configuring the custom keys defined in this section are:
1. In iBuilder, right-click the remote and select ModifyItem.
2. Click the Custom tab.
3. In the Remote-side Configuration section of the screen, configure the custom key. (See
the subsections below for definitions.)
4. Click OK to save your changes.
5. Right-click the remote in the remote’s current network in the iBuilder Tree and select
Apply ConfigurationReliable Remote-Side (TCP).
The example in this figure changes the remote’s net_state_timeout (discussed below) to six
minutes. The same general steps can be used to define any of the custom keys described in
the remainder of this section.
NOTE: Custom keys in the [BEAMS_LOCAL] group only apply to the remote
instances on which they are defined.
To change the download timeout, enter a remote-side custom key of the form:
[BEAMS_LOCAL]
download_timeout = <timeout>
where <timeout> is the value of the download timeout, in seconds.
NOTE: Custom keys in the [BEAMS_LOCAL] group only apply to the remote
instances on which they are defined.
NOTE: Custom keys in the [BEAMS_LOCAL] group only apply to the remote
instances on which they are defined.
NOTE: Do not configure this value to be less than the hysteresis used in the beam
map.
NOTE: If you have entered a custom key of 0 to disable this feature on a remote,
you can re-enable the feature either by setting the custom key to 1 or by deleting
the custom key.
NOTE: Custom keys in the [BEAMS_LOCAL] group only apply to the remote
instances on which they are defined.
[MAPSERVER_0]
hostname = <Ip Address>
port = <port number>
where <Ip Address> and <port number> are the local IP address and port number of the
local map server process.
CAUTION: You must apply this custom key to all instances of the remote.
For information on configuring and using a local map server, contact the iDirect TAC at (703)
648-8151.
NOTE: Access to the iDirect system is only allowed from a local host. Instead of
using the telnet <ip address> command, users now must ssh to the server with
the ssh <ip address> command and then telnet to the console from the local host
using the telnet localhost <port number> command or the telnet 0 <port
number> command.
E.4.1 latlong
The latlong command displays the current latitude and longitude of the remote. It also
displays the word muted if the current satellite is below the configured minimum look angle.
The precision of the values returned by the latlong command is greater than or equal to the
precision of the values returned to the remote by the antenna controller. (By contrast, the
precision sent to the NMS is in hundredths of a degree to maintain backward compatibility
with the location event format.) The latlong command is convenient when you do not want
to wait for the next location event, since the location event interval is set to five minutes by
default.
Syntax:
latlong
Example:
Figure E-9 shows an example of the latlong command.
E.4.2 tlev
The tlev command sets or reads the system's global trace level.
Although there are seven trace levels, level 4 is the highest level that can be used effectively
under normal operations. At level 4, the various ABS state machines trace all state
transitions. Each time an event occurs, the name of the state machine, the current state, and
the name of the event are displayed on the screen. This provides the analyst with a clear view
of the sequence of events occurring in the software.
Syntax:
tlev Reads the trace level
tlev 0 Sets the trace level to normal, tracing critical events only.
tlev 4 Sets the trace level to the highest trace level that is practical during normal
operations
tlev 7 Sets the trace level too high to be usable during normal operations
Example:
Figure E-10 shows an example of the tlev command. The command in the example sets the
trace level to 4.
NOTE: The antenna debug command works for all types of antennas supported
by ABS. However, the tracing for each antenna type differs dramatically because
the controller interface for each antenna type is unique.
Syntax:
antenna debug 7 7 7 7 Enables all antenna traces
antenna debug 0 0 0 0 Disables all antenna traces
Spaces are required between digits when setting the trace level.
Example:
Figure E-11 shows the trace output after the antenna debug command has been issued to
enable all antenna tracing.
E.4.5 beamselector
Depending on the command line argument, the beamselector command can be used for any
of the following purposes:
• To list the set of beams available to the remote
• To switch the remote from its current beam to a new beam
• To lock the remote to a specific beam during remote commissioning
• To determine the initial Tx power offset during remote commissioning
• To determine the current Tx power as read from the beam map
• To set the trace level of the beam switch module
When using the list argument, the command displays the beam number and the beam name
for each beam in the current set of beams available in the options file. It also indicates which
beam is currently selected and which, if any, of these available beams are unknown to the
map server that provided the current map. A beam that is in the options file but unknown to
the current map server is listed as “not in map.”
NOTE: “Not in map” indicates that the modem does not have a map from a map
server that knows about the beam. In other words, the name of the beam in the
options file does not match the name of any beam in the map being sent to the
modem by the map server.
When using the switch argument, the beamselector command allows the operator to
initiate a beam switch. For example, the command beamselector switch 5 commands
the modem to switch from its current beam to beam 5. Once the command is issued, the
remote will reset and attempt to use the new beam. The beam numbers may be determined
by issuing a beamselector list command.
This form of the command will not permit you to switch to a beam unless that beam is both in
the map and in the current options file. If you are sure you want to switch to a beam that is
unknown or that is not in the map, you must use the -f (or “force”) option.
Syntax:
beamselector list Displays all beams available to this remote as defined in the
remote options file.
beamselector switch <beam number> Switches the remote to the beam indicated
by beam number.
beamselector switch <beam number> -f Forces the remote to switch to the beam
indicated by beam number, even if that beam is not in the map.
NOTE: The beam names displayed by this command are identical to the beam
names in the conveyance beam map file supplied by the satellite provider, as well
as to the corresponding network names configured in iBuilder.
This appendix contains recommended iBuilder settings and custom keys for mobile remotes
using iDirect’s Communications On The Move (COTM) feature. Most of the material in this
appendix is only applicable to mobile remotes that attain speeds in excess of 150 mph.
However, some settings for SCPC return channels (starting on page 532) are also applicable to
other mobile remote types.
High-Speed COTM is a licensed feature that allows mobile remotes to travel at speeds up to
700 mph. This feature is only available for the following remote model types: Evolution
e8350, and iConnex e800/e850mp. For information on requesting and installing iDirect
licenses, see the iDirect Features and Chassis Licensing Guide. For details on importing
licenses into iBuilder, see Managing NMS Licenses on page 60.
NOTE: If a remote without a high-speed COTM license exceeds 150 mph, all user
traffic to the remote is stopped.
Some settings only apply to mobile remotes in TDMA networks (TDMA remotes) while some
settings only apply to mobile remotes that transmit SCPC return channels (SCPC remotes).
The applicable type of remote is noted in each description.
Figure F-1. Setting the Maximum Speed for Remotes in an Inroute Group
Figure F-2. Remote Geo Location Tab: Selecting Avionics for COTM Type
For more information, see Remote Geo Location Tab on page 199.
NOTE: A high-speed COTM license is required for mobile remotes that exceed 150
mph. Avionics does not appear in the drop-down menu unless this feature license
has been imported into iBuilder for this remote. See Managing NMS Licenses on
page 60.
NOTE: The COTM Type should be consistent with the Maximum Speed configured
for the remote’s inroute group.
NOTE: Some upstream modulation modes have minimum symbol rate restrictions
above 128 ksps. See the Link Budget Analysis Guide for this release.
TDMA SCPC
Mobile Remote Maximum Speed Maximum
Type (mph) Acceleration (m/s2) Ku Band Ka Band Ku Band Ka Band
Maritime 30 5 128 256 128 256
Vehicular 150 10 256 512 256 512
Airplane 700 17 400 800 512 1024
NOTE: Table F-2 assumes Hub LNB stability of 1 ppm or better and an elevation
angle of 10o.
3. Using iMonitor, follow the procedure on page 532 to determine the inroute ID of your SCPC
return channel.
4. In the iBuilder Tree, right-click the Network in which this carrier is used and select
ModifyItem.
5. In the Network dialog box, click the Custom tab.
6. Add the following custom key:
[INROUTE_id]
fec_blocks_per_frame = n
where id is the inroute ID of the SCPC return channel determined in Step 3 and n is:
floor (FEC Blocks per Frame / 4)
For example, if the number of FEC Blocks per Frame determined in Step 2 is 10, set
fec_blocks_per_frame to 2.
The remote lock feature allows individual remotes to be locked to a particular network. Once
a remote is locked with a Network Key, it only functions in a network with the same key.
Remote Locking is supported on Evolution X1, X3, X5, X7, and e150 remotes. The procedure
for locking these remotes differs based on remote model type.
This appendix describes remote locking for Evolution X3 remotes and is applicable to X5 and
X7 remotes. Remote locking for Evolution X1 and Evolution e150 remotes is described in the
Web iSite User Guide.
The remote locking feature uses symmetric key generation when locking the remotes. A
unique and secure Locking Key is generated for each remote, using a combination of the
Network Key and a randomly generated Confirmation Word. Remote locking uses a
“hardening” option to permanently save the Locking Key on the remote.
Remote locking is similar to locking a cell phone to a cellular network. It is performed at the
operator’s own risk. Non-Warranty RMA charges (plus all shipping) apply to all remotes
returned to iDirect for the purpose of removing a network lock. Please refer to Non-Warranty
RMA Required to Remove X3 Locks on page 538.
NOTE: iDX Release 3.5.2 introduced support for remote locking on X7 remotes.
• Hard Locks: Once a remote is “soft” locked to a network, entering the rmtlock
command irrevocably burns the remote’s Locking Key into the remote hardware using the
same Confirmation Word that was generated for the Soft Lock. After a Hard Lock has been
burned into the remote, only a Non-Warranty RMA hardware replacement can remove the
Hard Lock. Please refer to warning notes in Setting a Hard Lock on page 537.
NOTE: You must first Soft Lock an X3 remote to a network before you can Hard
Lock that remote.
Where <netkey> is the Network Key of the network to which the remote will be locked.
The following warning message is displayed, which includes the Confirmation Word:
The confirmation word is: DIFEWdsf
Please type:
rmtlock engage <netkey> <confirmation word>
to confirm.
WARNING: Remote lock will be engaged. Make sure the Network Key
is correct. Keep the confirmation word safe. If the remote has to
be disengaged, the confirmation word will be needed. If you lose
the confirmation word, you will not be able to disengage the
lock. In order to unlock the unit will have to be returned to
iDirect under Non-Warranty Repair.
You have 60 seconds to confirm it.
2. Record the Confirmation Word. The Confirmation Word is required to remove the Soft
Lock or to set a Hard Lock on the remote.
3. Within 60 seconds of performing Step 1, confirm the Soft Lock by re-entering the
rmtlock command followed by the Confirmation Word:
rmtlock engage <netkey> <confirmation word>
WARNING: Remote lock will be burned into the hardware. This lock
cannot be changed or removed once burned. In order to unlock the
unit will have to be returned to iDirect under Non-Warranty
Repair.
CAUTION: The following command will permanently lock the remote to the
Network. Only a hardware replacement can reverse this lock.
2. Within 60 seconds of performing Step 1, repeat the rmtlock burn command with the
Confirmation Word appended. This is the Confirmation Word that was generated when you
set the Soft Lock on this remote.
rmtlock burn <confirmation_word>
CAUTION: If the Locking Key is “burned” into the remote hardware using the Hard
Lock option, the remote can only function in a network with the Network Key
associated with the Hard Lock. From this point forward, the lock is permanent
and the Locking Key can only be removed with a Non-Warranty RMA hardware
replacement.
CAUTION: RMA and shipping charges apply to all remotes returned to iDirect for
the purpose of removing a network lock.
Supported Remotes
The following remotes support Remote Signaled and PP Signaled Beam Switching;
• 980
• iConnex eP100
• iConnex e850mp
CAUTION: If the custom keys are not configured correctly, this may not work
properly and the PP will allocate the ACQ slot to the beam switching remote
using the slower round robin method.
[SAPROXY]
enable_fast_beam_switch = 1
mc_address = INET;239.9.9.1;6600
virtual_ip = 10.15.145.13.13
max_ttl_sec_in_bs_priority_queue = 40
bs_rd_normal_acq_slot_alloc_ratio = 5:3:2
tls_client_timeout_sec = 180
mc_intf = eth0
vip_nic = eth0
vip_netmask = 255.255.255.0
foreign_listen_port = 6000
local_listen_port = 6400
[FOREIGN_SAPROXY]
saproxy_listen_address_1 = 10.15.145.14
saproxy_listen_address_2 = 10.15.145.15
NOTE: If the group [FOREIGN_SAPROXY] is missing, this only works within the
teleport.
3. Paste the predefined customs keys into the Protocol Processor Custom tab pane. See
Figure G-6.
4. Click OK.
5. Right-click the PP stack and select Apply Configuration to apply the changes.
NOTE: Selecting Apply Configuration turns Remote Signaled Beam Switching on.
To turn it off, remove the predefined customs keys from the Protocol Processor
Custom tab pane or insert a # in front of each line of the predefined customs keys
to comment each line out.
If configuring the custom keys for another PP stack, perform steps 1 through 3 for each PP
stack while noting the following:
Figure G-7. Hub Side Beam Switch Custom Keys in Different PP Stacks
NOTE: RecentDrop from Local Network Sweep does not require these keys
because it is done within a SADA and does not require communication between PP
stacks/processes.
NOTE: For the RecentDrop from Local Network Sweep feature, the remote must
be configured as Mobile in iBuilder.
CAUTION: If the custom keys are not configured correctly, this feature may
not work properly and the PP will still sweep the remotes In-Network
(Elsewhere).
[SAPROXY]
enable_stop_innet_rmt_acq = 1
mc_address = INET;239.9.9.1;6600
virtual_ip = 10.15.145.13.13
publish_innet_rmts_interval_sec = 20
innet_rmt_status_timeout_sec = 25
tls_client_timeout_sec = 180
mc_intf = eth0
vip_nic = eth0
vip_netmask = 255.255.255.0
foreign_listen_port = 6000
local_listen_port = 6400
[FOREIGN_SAPROXY]
saproxy_listen_address_1 = 10.15.145.14
saproxy_listen_address_2 = 10.15.145.15
NOTE: If the group [FOREIGN_SAPROXY] is missing, this feature only works within
the teleport.
3. Paste the predefined customs keys into the Protocol Processor Custom tab pane. See
Figure G-6.
4. Click OK.
5. Right-click the PP stack and select Apply Configuration to apply the changes.
NOTE: Selecting Apply Configuration turns the Stop Sweeping Remote In-
Network (Elsewhere) feature on. To turn the feature off, remove the predefined
customs keys from the Protocol Processor Custom tab pane or insert a # in front of
each line of the predefined customs keys to comment each line out.
If configuring the custom keys for another PP stack, perform steps 1 through 3 for each PP
stack while noting the following:
• The virtual IP address for each saproxy_listen_address is different in each PP stack
• The mc_address differs for each PP stack
See Figure G-7.
Figure G-10. Hub Side Beam Switch Custom Keys in Different PP Stacks
NOTE: The RecentDrop from Local Network Sweep feature can be configured with
the custom keys shown above if needed. Because the feature can be configured
within a single sada process, it does not need to communicate between PP stacks
and processes. See the configuration that follows.
3. Paste the predefined customs keys into the Protocol Processor Custom tab pane. See
Figure G-12.
4. Click OK.
5. Right-click the PP stack and select Apply Configuration to apply the changes.
NOTE: Selecting Apply Configuration turns the RecentDrop from Local Network
Sweep feature on. To turn the feature off, remove the predefined customs keys
from the Protocol Processor Custom tab pane or insert a # in front of each line of
the predefined customs keys to comment each line out.
CAUTION: If the custom keys are not configured correctly, this feature may
not work properly and the PP will allocate ACQ slots to the remotes using the
slower round robin method.
[SAPROXY]
enable_stop_innet_rmt_acq = 1
enable_recent_drop_rmt_priority_acq_all_beams = 1
mc_address = INET;239.9.9.1;6600
virtual_ip = 10.15.145.13.13
max_ttl_sec_in_rd_priority_queue = 300
publish_innet_rmts_interval_sec = 20
innet_rmt_status_timeout_sec = 25
bs_rd_normal_acq_slot_alloc_ratio = 5:3:2
tls_client_timeout_sec = 180
mc_intf = eth0
vip_nic = eth0
vip_netmask = 255.255.255.0
foreign_listen_port = 6000
local_listen_port = 6400
[FOREIGN_SAPROXY]
saproxy_listen_address_1 = 10.15.145.14
saproxy_listen_address_2 = 10.15.145.15
NOTE: If the group [FOREIGN_SAPROXY] is missing, this feature only works within
the teleport.
3. Paste the predefined customs keys into the Protocol Processor Custom tab pane. See
Figure G-14.
4. Click OK.
5. Right-click the PP stack and select Apply Configuration to apply the changes.
If configuring the custom keys for another PP stack, perform steps 1 through 3 for each PP
stack while noting the following:
• The virtual IP address for each saproxy_listen_address is different in each PP stack
• The mc_address differs for each PP stack
See Figure G-15.
Figure G-15. Hub Side Beam Switch Custom Keys in Different PP Stacks
Debug Information
This section contains stats/params/trace/debug commands useful for debugging beam switch
functionality from end to end and includes the following:
• Verify Link Status between Server and Clients on page 553
• Verify Beam Switch Message Flow on page 554
• Verify InNet Remote List Message Flow on page 555
• Verify ACQ Allocation Performance on page 555
For more information about PP processes, refer to the Technical Reference Guide.
NOTE: The stats and params that follow use bs as an acronym for beam switch
message.
NOTE: This section assumes the operator knows how to find the various PP
processes for a specific network or remote using process console commands.
> saproxy_mcintf
Usage: sap_mc_intf stats|params|debug [on|off|level]
NOTE: Use the rmt list console command to obtain a list of remote IDs and
the rmt id console command to select the remote.
1. Go to the SARMT process to generate a fake beam switch message from the SARMT
remote handler to the selected remote.
[sarmt(1:9)] admin@telnet:::ffff:127.0.0.1;46694 <NET:1
RMT:eP100.10101>
> rh SendBSMsg
Usage: SendBSMsg [net_id_to_switch]
2. Go to the SARMT process to check that Stats/Trace for the beam switch message is
received from remote (OOB message).
[sarmt(1:9)] admin@telnet:::ffff:127.0.0.1;46702 <NET:1
RMT:eP100.10101>
> rh stats | grep bs
3. Go to the SARMT process to check that Stats/Trace for the beam switch message is
forwarded to SAPROXY.
[sarmt(1:9)] admin@telnet:::ffff:127.0.0.1;46702 <NET:1
RMT:eP100.10101>
> saproxy_uconn stats
4. Go to the SAPROXY process to check that the Stats/Trace for the beam switch message
has been routed/distributed by UDP.
(If the network is found in the local PP stack, then the beam switch message is multicast
in the local PP stack by UDP; otherwise, the beam switch is forwarded by TLS to all non-
local PP stacks.)
[saproxy(1:1)] admin@telnet:::ffff:127.0.0.1;46243
> saproxy stats
5. Go to the SAPROXY process to check that the Stats/Trace for the beam switch message
has been routed/distributed to non-local saproxy processes by TLS.
(If network found in Local PP stack, then Multicast in Local PP stack else drop it.)
[saproxy(1:1)] admin@telnet:::ffff:127.0.0.1;46243
> saproxy stats
6. Go to the SADA process to check that SADA receives the Stats/Trace for beam switch
message.
[sada(1:5)] admin@telnet:::ffff:127.0.0.1;32894 <NET:6>
Qb inroute[ 6] ep100.20698
Qr inroute[ 6] e8350.20139
Qn inroute[ 6] e8350.20140
Qb inroute[ 6] ep100.20698
Qr inroute[ 6] e8350.20139
Qn inroute[ 6] e8350.20141
Qb inroute[ 6] ep100.20698
Qr inroute[ 6] e8350.20139
Qb inroute[ 6] ep100.20698
Qb inroute[ 6] ep100.2069
4. At the SADA process, provide the remote ID as shown below to see the last beam switch
acquisition message.
• BS_Rcv shows the epoch time that the remote received the beam switch message.
• in_network shows the epoch time that the remote joined the network.
• bs acq shows how long it has taken the remote to join the network after receiving
the beam switch message in seconds.
Transmission A protocol developed for the Internet to get data from one network device to another;
Control Protocol TCP uses a retransmission strategy to ensure that data will not be lost in transmission.
(TCP)
Transmission Rate Includes all over-the-air data. This includes the user data (information rate), iDirect
overhead, and FEC encoding bits.
Transponder A device in a communications satellite that receives signals from the earth, translates
and amplifies them on another frequency, and then retransmits them.
UHF Ultra High Frequency. Band in the 500-900 MHz range, including TV channels 14 through
83.
Uplink The Earth station used to transmit signals to a satellite and the stream of signals going
up to the satellite.
Upstream Upstream carrier (synonymous to inbound carrier) is the carrier from the remote
modem to the Hub, via the satellite.
Carrier
VHF Very High Frequency, Refers to electromagnetic waves between approximately 54 MHz
and 300 MHz.
VSAT Very Small Aperture Terminal. Means of transmission of video, voice, and data to a
satellite. Used in business applications.
screen 293 N
failure recovery 128
managing redundancy relationships 122 NAT 156
multichannel line card operational frequency network architecture example 2
band 113 network tree, See tree
NMS failover algorithm 129
networks
performing manual switchover or failover 127
prerequisites for automatic failover 119 adding 104
receive carrier types 109 deactivating 106
receive mode restrictions 110 inroute groups
receive modes 109 adding 130
receive-mode licenses required 110 assigning upstream carriers 134
receive-only line card types 109 description 130
rules for assignment to chassis slots 290 line cards
selectable line card types in iBuilder 106 adding receive 109
selecting carriers for multichannel line cards 113 adding transmit 107
setting tx power 351 adding transmit/receive 107
solo Tx/Rx line card described 106 NMS
supported model types 103 applications 8
TRANSEC-compatible model types 408 distributed NMS server 415
types of redundancy relationships 119 iVantage NMS components xxxiii
LNB main components 7
adding to a remote 182 multiple users accessing 13
servers used 9
logging in 12
setting up a distributed environment 417
passwords 12
to other servers 13
longitude O
spacecraft 70
teleport 86 ODU Tx 10 MHz 68
ODU Tx DC power 68
options files 309
M hub-side and remote-side 310
main toolbar 29 orbital inclination 70
management interface 153
mobile remotes P
See remotes: mobile remotes 179
setting the maximum speed for an inroute packet segmentation
group 481 setting a downstream segment size 177
modifying panes
accepting changes 13 active users 32, 385
multicast fast path choose details 37
configuring 249 configuration changes 34
defined 216 details 35
enabling encryption 105 legend 32
selecting for a GQoS application 238 network tree, See tree
See also dialog boxes
passwords 12, 387
properties
viewing element 35