Technical Reference Guide iDS Release 8.3 June 15, 2010 Copyright © 2010 VT iDirect, Inc All rights reserved Reproduction in whole or in part without permission is prohibited Information contained herein is subject to change without notice The specifications and information regarding the products in this document are subject to change without notice All statements, information, and recommendations in this document are believed to be accurate, but are presented without warranty of any kind, express, or implied Users must take full responsibility for their application of any products Trademarks, brand names and products mentioned in this document are the property of their respective owners All such references are used strictly in an editorial fashion with no intent to convey any affiliation with the name or the product's rightful owner Document Name: REF_Technical Reference Guide iDS 8.3_Rev E_061510.pdf Document Part Number: T0000152 ii Technical Reference Guide iDS Release 8.3 Contents About This Guide Purpose xi Intended Audience xi Contents Of This Guide xi Document Conventions xii Related Documents xiii Getting Help xiii iDirect System Overview System Overview IP Architecture 2 Mesh Technical Description Mesh Theory of Operation Network Architecture 10 Transponder Usage 10 Outbound TDM Channel 11 Inbound D-TDMA Channels 11 Mesh Topology Options 12 Physical Topology 12 Network Topology 15 Frequency Hopping 17 Mesh Frequency Hopping 17 Mesh/Star Frequency Hopping 18 Mesh Data Path 19 Single-Hop and Double-Hop Traffic Selection 19 Technical Reference Guide iDS Release 8.3 iii Routing 20 Real-Time Call Setup 20 Hardware Requirements 20 HUB RFT Equipment 20 Hub Chassis Hardware 21 Private Hub Hardware 21 Hub ODU Hardware 21 Remote IDU Hardware 21 Remote ODU Hardware 21 Network Considerations 22 Link Budget Analysis 22 Uplink Control Protocol (UCP) 24 Bandwidth Considerations 27 Mesh Commissioning 27 Star-to-Mesh Network Migration 28 Pre-Migration Tasks 28 Migration Tasks 28 Configuring and Monitoring Mesh Networks 29 Building Mesh Networks 29 Special Mesh Constants 29 Turning Mesh On and Off in iBuilder 29 Changes to Acquisition/Uplink Control in iBuilder 30 Monitoring Mesh Networks 31 Additional Hub Statistics Information 31 Additional Remote Status Information 32 Mesh Traffic Statistics 32 Remote-to-Remote Mesh Probe 34 Long-Term Bandwidth Usage Report for Mesh 35 Mesh Feature Set and Capability Matrix 36 Modulation Modes and FEC Rates iDirect Modulation Modes And FEC Rates 39 iDirect Spread Spectrum Networks What is Spread Spectrum? 41 Spread Spectrum Hardware Components 42 Downstream Specifications 43 iv Technical Reference Guide iDS Release 8.3 Supported Forward Error Correction (FEC) Rates 43 Upstream Specifications 44 QoS Implementation Principles Quality of Service (QoS) 45 QoS Measures 45 QoS Application, iSCPC and Filter Profiles 46 Classification Profiles for Applications 47 Service Levels 47 Packet Scheduling 48 Group QoS 50 Group QoS Structure 51 Group QoS Scenarios 53 Application Throughput 59 QoS Properties 59 Packet Segmentation 61 Application Latency 62 Maximum Channel Efficiency vs Minimum Latency 62 Configuring Transmit Initial Power What is TX Initial Power? 63 How To Determine The Correct TX Initial Power 63 All Remotes Need To Transmit Bursts in The Same C/N Range 64 What Happens When TX Initial Power Is Set Incorrectly? 65 When TX Initial Power is Too High 65 When TX Initial Power is Too Low 65 Global NMS Architecture How the Global NMS Works 67 Sample Global NMS Network 68 Hub Network Security Recommendations Limited Remote Access 69 Root Passwords 69 Technical Reference Guide iDS Release 8.3 v Global Protocol Processor Architecture Remote Distribution 71 De-coupling of NMS and Datapath Components 71 10 Distributed NMS Server Distributed NMS Server Architecture 73 iBuilder and iMonitor 74 dbBackup/dbRestore and the Distributed NMS 75 Distributed NMS Restrictions 76 11 Transmission Security (TRANSEC) What is TRANSEC? 77 iDirect TRANSEC 78 TRANSEC Downstream 78 TRANSEC Upstream 80 TRANSEC Key Management 82 TRANSEC Remote Admission Protocol 84 Reconfiguring the Network for TRANSEC 84 12 Fast Acquisition Feature Description 85 13 Remote Sleep Mode Feature Description 87 Awakening Methods 87 Operator-Commanded Awakening 88 Activity Related Awakening 88 Enabling Remote Sleep Mode 89 14 Automatic Beam Selection Automatic Beam Selection Overview 91 Theory of Operation 91 Beam Characteristics: Visibility and Usability 92 Selecting a Beam without a Map 93 vi Technical Reference Guide iDS Release 8.3 Controlling the Antenna 93 IP Mobility 94 Operational Scenarios 94 Creating the Network 94 Adding a Vessel 95 Normal Operations 95 Mapless Operations 96 Blockages and Beam Outages 96 Error Recovery 97 15 Hub Geographic Redundancy Feature Description 99 Configuring Wait Time Interval for an Out-of-Network Remote 100 16 Carrier Bandwidth Optimization Overview 101 Increasing User Data Rate 102 Decreasing Channel Spacing to Gain Additional Bandwidth 103 17 Hub Line Card Failover Basic Failover Concepts 105 Tx(Rx) versus Rx-Only Line Card Failover 105 Failover Sequence of Events 106 Technical Reference Guide iDS Release 8.3 vii List of Figures Figure Sample iDirect Network Figure iDirect IP Architecture – Multiple VLANs per Remote Figure iDirect IP Architecture – VLAN Spanning Remotes Figure iDirect IP Architecture – Classic IP Configuration Figure iDirect IP Architecture - TDMA and iSCPC Topologies Figure Double-Hop Star Network Topology Figure Single-Hop Mesh Overlay Network Topology Figure Basic Mesh Topology 10 Figure Integrated Mesh and Star Network 13 Figure 10 Segregated Mesh and Star Networks 14 Figure 11 Mesh Private Hub 14 Figure 12 High-Volume Star / Low-Volume Mesh Topology 16 Figure 13 Mesh Frequency Hopping: Inroute Group with Two Inroutes 17 Figure 14 Mesh Frequency Hopping: Communicating Between Inroutes 18 Figure 15 Frequency Hopping with Star and Mesh 19 Figure 16 Mesh VSAT Sizing 23 Figure 17 Uplink Power Control 26 Figure 18 Specifying UPC Parameters 30 Figure 19 Common Remote Parameters for Mesh 31 Figure 20 Mesh, SAT, IP statistics collection 34 Figure 21 Spread Spectrum Network Diagram 41 Figure 22 Remote and QoS Profile Relationship 47 Figure 23 iDirect Packet Scheduling Algorithm 49 Figure 24 Group QoS Structure 51 Figure 25 Physical Segregation Scenario 54 Figure 26 CIR Per Application Scenario 55 Figure 27 Tiered Service Scenario 56 Figure 28 Third Level VLAN Scenario 57 Figure 29 Shared Remote Scenario 58 Figure 30 C/N Nominal Range 64 Figure 31 TX Initial Power Too High 65 Figure 32 TX Initial Power Too Low 66 Figure 33 Global NMS Database Relationships 67 Figure 34 Sample Global NMS Network Diagram 68 Figure 35 Protocol Processor Architecture 72 Figure 36 Sample Distributed NMS Configuration 74 Figure 37 dbBackup and dbRestore with a Distributed NMS 75 Figure 38 Downstream Data Path 78 viii Technical Reference Guide iDS Release 8.3 Figure 39 SCPC TRANSEC Frame 79 Figure 40 Upstream Data Path 80 Figure 41 TDMA TRANSEC Slot 81 Figure 42 Key Distribution Protocol 82 Figure 43 Key Rolling and Key Ring 83 Figure 44 Host Keying Protocol 83 Figure 45 Overlay of Carrier Spectrums 101 Figure 46 Adding an Upstream Carrier By Reducing Carrier Spacing 104 Figure 47 Failover Sequence of Events 106 Technical Reference Guide iDS Release 8.3 ix List of Tables Table Mesh-Related Constants 29 Table Mesh IP Statistics Example 33 Table iDirect Products Supporting Mesh 36 Table Mesh Feature Set and Compatibility Matrix 37 Table Modulation Modes and FEC Rates 40 Table Spread Spectrum: Downstream Specifications 43 Table Spread Spectrum: Supported FEC Rates 43 Table Spread Spectrum: Upstream Specifications 44 Table Power Consumption in Remote Sleep Mode 89 x Technical Reference Guide iDS Release 8.3 Operational Scenarios A steerable, stabilized antenna must know its geographical location in order to point to the antenna The antenna includes a GPS receiver for this purpose The remote must also know its geographical location to select the correct beam and to compute its distance from the satellite The remote periodically commands the antenna controller to send the current location to the modem IP Mobility Communications to the customer intranet (or to the Internet) are automatically reestablished after a beam switch-over The process of joining the network after a new beam is selected uses the same internet routing protocols that are already established in the iDirect system When a remote joins a beam, the Protocol Processor for that beam begins advertising the remote's IP addresses to the upstream router using the RIP protocol When a remote leaves a beam, the Protocol Processor for that beam withdraws the advertisement for the remote's IP addresses When the upstream routers see these advertisements and withdrawals, they communicate with each other using the appropriate IP protocols to determine their routing tables This permits other devices on the Internet to send data to the remote over the new path with no manual intervention Operational Scenarios This section presents a series of top-level operational scenarios that can be followed when configuring and managing iDirect networks that contain roaming remotes using Automatic Beam Selection Steps for configuring network elements such as iDirect networks (beams) and roaming remotes are documented in iBuilder User Guide Steps specific to configuring ABS functionality, such as adding an ABS-capable antenna or converting a conveyance beam map file, are described in “Appendix C, Configuring Networks for Automatic Beam Selection” of the iBuilder User Guide Creating the Network This scenario outlines the steps that must be performed by the customer, the satellite provider, and the network operator to create a network that uses ABS The customer determines the satellite provider and agree on the set of beams (satellites, transponders, frequencies and footprints) to be used by remotes using ABS The satellite provider enters into an agreement with iDirect specifying the format of the conveyance beam map file The satellite provider supplies the link budget for the hub and remotes iDirect delivers the map conversion program to the customer specific to the conveyance beam map file specification The satellite provider delivers to the customer one conveyance beam map file for each beam that the customer will use The customer orders and installs all required equipment and an NMS The NMS operator configures the beams (iDirect networks) The NMS operator runs the conversion program to create the server beam map file from the conveyance beam map file or files 94 Technical Reference Guide iDS Release 8.3 Operational Scenarios The NMS operator runs the map server as part of the NMS Adding a Vessel This scenario outlines the steps required to add a roaming remote using ABS to all available beams The NMS operator configures the remote modem in one beam The NMS operator adds the remote to the remaining beams The NMS operator saves the modem's options file and delivers it to the installer The installer installs the modem aboard a ship The installer copies the options file to the modem using iSite The installer manually selects a beam for commissioning The modem commands the antenna to point to the satellite The modem receives the current location from antenna The installer commissions the remote in the initial beam 10 The modem enters the network and requests a maplet from the NMS map server 11 The modem checks the maplet If the commissioning beam is not the best beam, the modem switches to the best beam as indicated in the maplet This beam is then assigned a high preference rating by the modem to prevent the modem from switching between overlapping beams of similar quality 12 Assuming center beam in clear sky conditions: 13 The installer sets the initial transmit power to dB above the nominal transmit power 14 The installer sets the maximum power to dB above the nominal transmit power Note: Check the levels the first time the remote enters each new beam and adjust the transmit power settings if necessary Normal Operations This scenario describes the events that occur during normal operations when a modem is receiving map information from the NMS The ship leaves port and travels to next destination The modem receives the current location from antenna every five minutes While in the beam, the antenna automatically tracks the satellite As the ship approaches the edge of the current maplet, the modem requests a new maplet from the map server When the ship reaches a location where the maplet shows a better beam, the remote switches by doing the following: a a Computes best beam b b Saves best beam to non-volatile storage Technical Reference Guide iDS Release 8.3 95 Operational Scenarios c c Reboots d d Reads the new best beam from non-volatile storage e e Commands the antenna to move to the correct satellite and beam f f Joins the new beam Mapless Operations This scenario describes the events that occur during operations when a modem is not receiving beam mapping information from the NMS While operational in a beam, the remote periodically asks the map server for a maplet The remote does not attempt to switch to a new beam unless one of the following conditions are true: a a The remote drops out of the network b b The remote receives a maplet indicating that a better beam exists c c The satellite drops below the minimum look elevation defined for that beam If not acquired, the remote selects a visible, usable beam based only on satellite longitude and attempts to switch to that beam After five minutes, if the remote is still not acquired, it marks the new beam as unusable and selects the best beam from the remaining visible, usable beams in the options file This step is repeated until the remote is acquired in a beam, or all visible beams are marked as unusable If all visible beams are unusable, the remote marks them all as usable, and continues to attempt to use each beam in a round-robin fashion as described in step Blockages and Beam Outages This scenario describes the events that occur when a modem cannot join or loses the selected beam If the remote fails to join the selected beam after five minutes, it marks the beam as unusable and selects a new beam based on the maplet If the remote loses network connectivity for five minutes, it marks the current beam as unusable and selects a new beam based on the maplet Any beam marked as unusable remains unusable for an hour or until all beams are marked as unusable If only the current beam is visible, the remote will not attempt to switch from that beam, even after losing connectivity for five minutes 96 Technical Reference Guide iDS Release 8.3 Operational Scenarios Error Recovery This section describes the actions taken by the modem under certain error conditions If the remote cannot communicate with the antenna and is not acquired into the network, it will reboot after five minutes If the antenna is initializing, the remote waits for the initialization to complete It will not attempt to switch beams during this time Technical Reference Guide iDS Release 8.3 97 Operational Scenarios 98 Technical Reference Guide iDS Release 8.3 15 Hub Geographic Redundancy This chapter describes how you can establish a primary and back up hub that are geographically diverse It includes: • “Feature Description‚" which describes how geographic redundancy is accomplished • “Configuring Wait Time Interval for an Out-of-Network Remote‚" which describes how you can set the wait period before switchover Feature Description The Hub Geographic Redundancy feature builds on the previously developed Global NMS feature and the existing dbBackup/dbRestore utility You configure the Hub Geographic Redundancy feature by defining all the network information for both the Primary and Backup Teleports in the Primary NMS All remotes are configured as roaming remotes and they are defined identically in both the Primary and Backup Teleport network configurations Only iNFINITI remotes can currently participate in Global NMS networks Since the backup teleport feature also uses the Global NMS capability, this feature is also restricted to iNFINITI remotes During normal (non-failure) operations, carrier transmission is inhibited on the Backup Teleport During failover conditions (when roaming network remotes fail to see the downstream carrier through the Primary Teleport NMS) you can manually enable the downstream transmission on the Backup Teleport, allowing the remotes to automatically (after the configured default wait period of five minutes) acquire the downstream transmission through the Backup Teleport NMS iDirect recommends the following for most efficient switchover: • A separate IP connection (at least 128 Kbps) between the Primary and Backup Teleport NMS for database backup and restore operations A higher rate line can be employed to reduce this database archive time • The downstream carrier characteristics for the Primary and Backup Teleports MUST be different For example, either the FEC, frequency, frame length, or data rate values must be different • On a periodic basis, backup and restore your NMS configuration database between your Primary and Backup Teleports See the NMS Redundancy and Failover Technical Note for complete NMS redundancy procedures Technical Reference Guide iDS Release 8.3 99 Configuring Wait Time Interval for an Out-of-Network Remote Configuring Wait Time Interval for an Out-of-Network Remote If a roaming remote is configured at both a Primary and Backup Hub, and the remote loses the Downstream carrier from the Primary Hub, the remote attempts to lock to the Downstream carrier from the Backup Hub, after a configured interval in seconds By default this “wait time” before attempting the switch is 300 seconds (5 minutes) This wait time for beam switchover can be changed by setting the net_state_timeout custom key value (in seconds) to the desired wait period For example, if you want to make the wait period 10 minutes, use the following custom key: [REMOTE_DEFINITION] net_state_timeout=600 For further configuration information, see the chapter “Defining Network Components” in the iBuilder User Guide 100 Technical Reference Guide iDS Release 8.3 16 Carrier Bandwidth Optimization This chapter describes carrier bandwidth optimization and carrier spacing It includes the following sections: • “Overview" describes how reducing carrier spacing increases overall available bandwidth • “Increasing User Data Rate" provides an example of how you can increase user data rates with out increasing occupied bandwidth • “Decreasing Channel Spacing to Gain Additional Bandwidth" provides an example of how you can increase occupied bandwidth Overview The Field Programmable Gated Array (FPGA) firmware uses optimized digital filtering which reduces the amount of satellite bandwidth required for an iDirect carrier Instead of using a 40% guard band between carriers, now the guard band may be reduced to as low as 20% on both the broadcast Downstream channel and the TDMA Upstream Figure 45 shows an overlay of the original spectrum and the optimized spectrum Figure 45 Overlay of Carrier Spectrums This optimization translates directly into a cost savings for existing and future networks deployed with iDirect remote modems Technical Reference Guide iDS Release 8.3 101 Increasing User Data Rate The spectral shape of the carrier is not the only factor contributing to the guard band requirement Frequency stability parameters of a system may result in the need for a guard band of slightly greater than 20% to be used iDirect complies with the adjacent channel interference specification in IESS 308 which accounts for adjacent channels on either side with +7 dB higher power Be sure to consult the designer of your satellite link prior to changing any carrier parameters to verify that they not violate the policy of your satellite operator Increasing User Data Rate Since the amount of required guard band between carriers has been reduced, it is now possible to fit a higher bit rate carrier into the same satellite bandwidth that was required previously Therefore, a network operator can increase the bit rate of existing carriers without purchasing additional bandwidth A consequence of choosing this option is that increasing the bit rate of the carrier to fill the extra bandwidth requires slightly more power Increasing the bit rate by 15% would result in an additional 0.5 dB of power Be sure to consult the provider of your link budget prior to adjusting the bit rate of your carriers Frequency stability in the system may limit the amount of bit rate increase by increasing the guard band requirement The example that follows illustrates a scenario applicable to a system with negligible frequency stability concerns It shows how the occupied bandwidth does not increase when the user data rate increases In this example, FEC rate 0.793 with kbit Turbo Product Code is used Current Carrier Parameters: • User Bit (info) Rate:1000 kbps • Carrier Bit Rate:1261.034 kbps • Carrier Symbol Rate:630.517 ksps • Occupied Bandwidth:882.724 kHz • Guard Band Between Carriers: 40% (Channel Spacing = 1.4) New Carrier Parameters • User Bit (info) Rate: 1166.667 kbps • Carrier Bit Rate: 1471.206 kbps • Carrier Symbol Rate: 735.603 ksps • Occupied Bandwidth: 882.724 kHz • Guard Band Between Carriers: 20% (Channel Spacing = 1.2) A 16.67% improvement in user data rate is achieved at no additional cost It is possible that due to instability of frequency references in a satellite network system, a carrier may not fall exactly on its assigned center frequency iDirect networks combat frequency offset using an automatic frequency control algorithm Any additional instability must be accommodated by additional guard band The frequency references to the hub transmitter and to the satellite itself are generally very stable so the main source of frequency instability is the downconverter at the hub This is 102 Technical Reference Guide iDS Release 8.3 Decreasing Channel Spacing to Gain Additional Bandwidth because the automatic frequency control algorithm uses the hub receiver’s estimate of frequency offset to adjust each remote transmitter frequency Hub stations which use a feedback control system to lock their downconverter to an accurate reference may have negligible offsets Hub stations using a locked LNB will have a finite frequency stability range Another reason to add guard band is to account for frequency stability of other carriers directly adjacent on the satellite which are not part of an iDirect network Be sure to review this situation with your satellite link designer before changing carrier parameters The example that follows accounts for a frequency stability range for systems using equipment with more significant stability concerns Given the “Current Carrier Parameters” the previous example and a total frequency stability of +/-5 kHz, compute the new carrier parameters: Solution: • Subtract the total frequency uncertainty from the available bandwidth to determine the amount of bandwidth left for the carrier (882.724 kHz – 10 kHz = 872.724 kHz) • Divide this result by the minimum channel spacing (872.724 / 1.2 = 727.270 kHz) • Use the result as the carrier symbol rate and compute the remaining parameters New Carrier Parameters • User Bit (info) Rate: 1153.450 kbps • Carrier Bit Rate: 1454.540 kbps • Carrier Symbol Rate: 727.270 ksps • Occupied Bandwidth: 882.724 kHz • Guard Band Between Carriers: 21.375% (Channel Spacing = 1.21375) A 15.345% improvement in user bit rate was achieved at no additional cost Decreasing Channel Spacing to Gain Additional Bandwidth The amount of required guard band between carriers can also be expressed as the channel spacing requirement For example, if the required guard band is 20%, the channel spacing requirement is 1.2*Carrier_Symbol_Rate (Hz) Therefore, a network operator may take advantage of the new carrier bandwidth optimization by reworking their frequency plan such that excess bandwidth is available for use by another carrier For example, consider an iDirect network with a user data (information) rate of Mbps on the downstream and three upstream carriers of Mbps each FEC rate 0.793 with kbit TPC is used for all carriers in this example Figure 46 shows that an additional Upstream carrier may be added by reducing the channel spacing of the existing carriers Technical Reference Guide iDS Release 8.3 103 Decreasing Channel Spacing to Gain Additional Bandwidth Figure 46 Adding an Upstream Carrier By Reducing Carrier Spacing 104 Technical Reference Guide iDS Release 8.3 17 Hub Line Card Failover This chapter describes basic hub line card failover concepts, transmit/receive verses receiveonly line card failover, failover sequence of events, and failover operation from a user’s point of view For information about configuring your line cards for failover, refer the “Networks, Line Cards, and Inroute Groups” chapter of the iBuilder User Guide Basic Failover Concepts Each second, every line card sends a diagnostic message to the NMS This message contains the status of various onboard components If the NMS fails to receive any diagnostic messages from a line card for 60 seconds, and all failover prerequisites are met, it considers that the line card may be in failed state It takes another 15 seconds to ensure that line card has truly failed It then starts the failover process For Tx(Rx) line cards, the standby assumes the failed card’s role immediately For Rx line cards, the standby needs to flash a new options file and reset The estimated time to complete a Tx(Rx) line card failover is less than 10 seconds; the estimated time to complete a Rx-only line card is less than minute Note: If your Tx line card fails, or you only have a single Rx line card and it fails, all remotes must re-acquire into the network after failover is complete Tx(Rx) versus Rx-Only Line Card Failover The most important line card in a network is the Tx(Rx) line card; if this card fails, all remotes drop out of the network When an Rx-only card in a frequency-hopping inroute group fails, all remotes automatically begin sharing the other inroutes While this may result in diminished bandwidth, remotes not drop out of the network iDirect’s failover method guarantees the fastest failover possible for the Tx(Rx) line cards The standby line card in each network is pre-configured with the parameters of the Tx card for that network, and has those parameters loaded into memory The only difference between the active Tx(Rx) card and the standby is that the standby mutes its transmitter (and receiver) When the NMS detects a Tx(Rx) line card failure, it sends a command to the standby to un-mute its transmitter (and receiver), and the standby immediately assumes the role of the Tx(Rx) card Technical Reference Guide iDS Release 8.3 105 Failover Sequence of Events Rx-only line cards take longer to failover than Tx(Rx) cards because they need to receive a new options file, flash it, and reset Failover Sequence of Events The flow chart that shows the sequence of events performed on the NMS server to execute a complete failover is shown in Figure 47 Portions of the failover sequence of events are revealed in real-time You may perform a historical condition query in iMonitor at any time to see the alarms and warnings that are generated and archived during the failover operation Event Server determines line card has failed Configuration Server is notified Automatic failover selected? NO DONE NO DONE iMonitor will show the line card in the Alarm state User may initiate manual failover if desired YES User initiates manual failover Prerequisites Met? User will have already been notified that failover cannot happen YES All subsequent operations are handled by the Configuration Server unless otherwise noted Configuration Server powers down slot of failed card Send ACTIVE options file of failed card to spare and reset YES Rx-only line card? NO Send command to spare to switch role from Standby to Primary; send ACTIVE options file of failed card but DO NOT reset Apply necessary changes to puma (serial number) Former spare gets role of failed card (Tx, TxRx, or Rx) and carrier/inroute group assignments Configuration Server must grab exclusive write lock at this point Any user with the lock will lose the lock and any unsaved changes Failed unit gets new role: Failed Figure 47 Failover Sequence of Events 106 Technical Reference Guide iDS Release 8.3 Failover Sequence of Events Technical Reference Guide iDS Release 8.3 107 ... Sleep Mode 89 x Technical Reference Guide iDS Release 8.3 About This Guide Purpose The Technical Reference Guide provides detailed technical information on iDirect technology... Telephone: (703) 648-8000 Email: SALES@iDirect.net Technical Reference Guide iDS Release 8.3 xiii xiv Technical Reference Guide iDS Release 8.3 iDirect System Overview This chapter presents a... IP Configuration” Technical Reference Guide iDS Release 8.3 IP Architecture Figure iDirect IP Architecture – Multiple VLANs per Remote Technical Reference Guide iDS Release 8.3 IP Architecture