Technical Reference Guide iDS 8.3

Phase II of mesh, which was delivered in iDS Release 8.2 and is supported in this release, added the following enhancements to the original Mesh feature: • The ability to configure multi

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

About This Guide

Purpose xi

Intended Audience xi

Contents Of This Guide xi

Document Conventions xii

Related Documents xiii

Getting Help xiii

1 iDirect System Overview System Overview 1

IP Architecture 2

2 Mesh Technical Description Mesh Theory of Operation 7

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

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

3 Modulation Modes and FEC Rates iDirect Modulation Modes And FEC Rates 39

4 iDirect Spread Spectrum Networks What is Spread Spectrum? 41

Spread Spectrum Hardware Components 42

Supported Forward Error Correction (FEC) Rates 43

Upstream Specifications 44

5 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

6 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

7 Global NMS Architecture How the Global NMS Works 67

Sample Global NMS Network 68

8 Hub Network Security Recommendations Limited Remote Access 69

9 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

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

List of Figures

Figure 1 Sample iDirect Network 1

Figure 2 iDirect IP Architecture – Multiple VLANs per Remote 3

Figure 3 iDirect IP Architecture – VLAN Spanning Remotes 4

Figure 4 iDirect IP Architecture – Classic IP Configuration 5

Figure 5 iDirect IP Architecture - TDMA and iSCPC Topologies 6

Figure 6 Double-Hop Star Network Topology 8

Figure 7 Single-Hop Mesh Overlay Network Topology 9

Figure 8 Basic Mesh Topology 10

Figure 9 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 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

List of Tables

Table 1 Mesh-Related Constants 29

Table 2 Mesh IP Statistics Example 33

Table 3 iDirect Products Supporting Mesh 36

Table 4 Mesh Feature Set and Compatibility Matrix 37

Table 5 Modulation Modes and FEC Rates 40

Table 6 Spread Spectrum: Downstream Specifications 43

Table 7 Spread Spectrum: Supported FEC Rates 43

Table 8 Spread Spectrum: Upstream Specifications 44

Table 9 Power Consumption in Remote Sleep Mode 89

About This Guide

Purpose

The Technical Reference Guide provides detailed technical information on iDirect technology

and major features as implemented in iDS Release 8.3

Intended Audience

The intended audience for this guide includes network operators using the iDirect iDS system, network architects, and anyone upgrading to iDS Release 8.3

Note: It is expected that the user of this material has attended the iDirect IOM

training course and is familiar with the iDirect network solution and associated equipment.

Contents Of This Guide

This document contains the following major sections:

• “iDirect System Overview”

• “Mesh Technical Description”

• “Modulation Modes and FEC Rates”

• “iDirect Spread Spectrum Networks”

• “QoS Implementation Principles”

• “Configuring Transmit Initial Power”

• “Global NMS Architecture”

• “Hub Network Security Recommendations”

• “Global Protocol Processor Architecture”

• “Carrier Bandwidth Optimization”

• “Hub Line Card Failover”

Document Conventions

This section illustrates and describes the conventions used throughout the manual Take a look now, before you begin using this manual, so that you’ll know how to interpret the information presented

at a command line or on a console

Output similar to the following sample appears:

[SECURITY]

password =

$idi2$/bFMhf$5H8mYAaP1sTZ0m1Ny/dYyLaS40/admin_password =

$idi2$146rgm$.KtDb4OH5CEBxzH6Ds2xM.ehHCHos_password =

$1$UTKh0V$cc/UfNThFmBI7sT.zYptQ0Bold

Trebuchet

font

Used when the user is required to type information or values into a field within a windows-type interface software

Used when specifying names of commands, menus, folders, tabs, dialogs, list boxes, and options

1 If you are adding a remote to an inroute group,

right-click the Inroute Group and select Add Remote.

The Remote dialog box has a number of selectable tabs across the top The Information Tab is

user-visible when the dialog box opens

For instructions on adding an iSCPC line card to the network tree and selecting a Hub RFT for the line card,

Bold italic

Trebuchet

font

Used to emphasize information for the user, such as in notes

Note: Several remote model types can be

configured as iSCPC remotes.

Used when the user needs

to strictly follow the

instructions or have additional knowledge about

a procedure or action

a network outage

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

• iDS Release Notes

• iDS Software Installation Guide or Network Upgrade Procedure Guide

• iDS iBuilder User Guide

• iDS iMonitor User Guide

• iDS Software Installation Checklist/Software Upgrade Survey

• iDS Installation and Commissioning Guide for Remote Satellite Routers

• iDS Link Budget Analysis Guide

Getting Help

The iDirect Technical Assistance Center (TAC) is available to help you 24 hours a day, 365 days

a year Software user guides, installation procedures, a FAQ page, and other documentation that supports our products are available on the TAC webpage Please access our TAC webpage at: http://tac.idirect.net

If you are unable to find the answers or information that you need, you can contact the TAC at (703) 648-8151

If you are interested in purchasing iDirect products, please contact iDirect Corporate Sales by telephone or email

Telephone: (703) 648-8000

Email: SALES@iDirect.net

1 iDirect System Overview

This chapter presents a high level overview of an iDirect Network It provides a sample iDirect network and describes IP architecture in SCPC and TDMA networks

System Overview

An iDirect network is a satellite based TCP/IP network with a Star topology in which a Time Division Multiplexed (TDM) broadcast downstream channel from a central hub location is shared by a number of remote nodes An example iDirect network is shown in Figure 1

Figure 1 Sample iDirect Network

The iDirect Hub equipment consists of an iDirect Hub Chassis with Hub Line Cards, a Protocol Processor (PP), a Network Management System (NMS) and the appropriate RF equipment Each

The choice of upstream carriers is determined either at network acquisition time or

dynamically at run-time, based on a network configuration setting iDS software has features and controls that allow the system to be configured to provide QoS and other traffic

engineered solutions to remote users All network configuration, control, and monitoring functions are provided via the integrated NMS The iDS software provides:

• Packet-based and network-based QoS, TCP acceleration

• TCP acceleration

• AES link encryption

• Local DNS cache on the remote

• End-to-end VLAN tagging

• Dynamic routing protocol support via RIPv2 over the satellite link

• Multicast support via IGMPv2

• VoIP support via voice optimized features such as cRTP

An iDirect network interfaces to the external world through IP over Ethernet via 10/100Base-T ports on the remote unit and the Protocol Processor at the hub

IP Architecture

The following figures illustrate the basic iDirect IP Architecture with different levels

configuration available to you:

• Figure 2, “iDirect IP Architecture – Multiple VLANs per Remote”

• Figure 3, “iDirect IP Architecture – VLAN Spanning Remotes”

• Figure 4, “iDirect IP Architecture – Classic IP Configuration”

IP Architecture

Figure 2 iDirect IP Architecture – Multiple VLANs per Remote

IP Architecture

Figure 3 iDirect IP Architecture – VLAN Spanning Remotes

IP Architecture

Figure 4 iDirect IP Architecture – Classic IP Configuration

iDirect allows you to mix traditional IP routing based networks with VLAN based

configurations This capability provides support for customers that have conflicting IP address ranges in a direct fashion, and multiple independent customers at a single remote site by configuring multiple VLANs directly on the remote

In addition to end-to-end VLAN connection, the system supports RIPv2 in an end-to-end manner including over the satellite link; RIPv2 can be configured on per-network interface

In addition to the network architectures discussed so far, the iDirect iSCPC solution allows you

to configure, control and monitor point-to-point Single Carrier per Channel (SCPC) links These links, sometimes referred to as “trunks” or “bent pipes,” may terminate at your teleport, or may be located elsewhere Each end-point in an iSCPC link sends and receives data across a dedicated SCPC carrier As with all SCPC channels, the bandwidth is constant and available to both sides at all times, regardless of the amount of data presented for transmission SCPC links are less efficient in their use of space segment than are iDS TDMA networks However, they are very useful for certain applications Figure 5 shows an iDirect system containing an iSCPC link and a TDMA network, all under the control of the NMS

IP Architecture

Figure 5 iDirect IP Architecture - TDMA and iSCPC Topologies

2 Mesh Technical

Description

This chapter provides general guidelines for designing mesh networks using iDirect

equipment Various physical and network topologies are presented, including how each different configuration may affect the cost and performance of the overall network Network and equipment requirements are specified, as well as the limitations of the current phase of iDirect’s Mesh solution Overviews are provided for the commissioning procedure for an iDirect Mesh network; converting existing star networks to mesh; and creating new mesh networks

iDirect’s Mesh offering provides a full-mesh solution implemented as a mesh overlay network superimposed on an iDirect star network The mesh overlay provides direct connectivity between remote terminals with a single trip over the satellite, thereby halving the latency and reducing satellite bandwidth requirements As with other iDirect features, mesh is being implemented in a phased manner The first phase was delivered in IDS Release 7.0 Phase II of mesh, which was delivered in iDS Release 8.2 and is supported in this release, added the following enhancements to the original Mesh feature:

• The ability to configure multiple mesh inroutes per inroute group

• The ability to configure separate data rates for star and mesh inroutes

• Support for TRANSEC over mesh

If you are running a Mesh Phase I release (iDS 7.0, 7.1 or 8.0), you are limited to a single inroute per mesh inroute group In addition, TRANSEC over mesh is not supported in Mesh Phase I For details of iDirect hardware and features supported for each release, see “Mesh Feature Set and Capability Matrix” on page 36

Mesh Theory of Operation

The iDirect Star network solution is ideal for networks which primarily require communication between remote terminals and a common point such as the Internet, a PSTN or a corporate data center However, for real time applications requiring remote-to-remote connectivity, a star network is not suitable

For example, consider a Voice over IP (VoIP) call from remote User A to remote User B in a star network (Figure 6)

Mesh Theory of Operation

Figure 6 Double-Hop Star Network Topology

In the network shown in Figure 6, the one-way transmission delay from user A to user B over a geosynchronous satellite averages 550 ms The extended length of the delay is due to the

“double-hop” transmission path: remote A to the satellite; the satellite to the hub; the hub back to the satellite; and the satellite to remote B This transmission delay, added to the voice processing and routing delays in each terminal, results in an unacceptable quality of service for voice In addition, the remote-to-remote transmission requires twice as much satellite bandwidth as a single-hop call

Mesh Theory of Operation

A more cost-effective use of satellite bandwidth and improved quality of service for real-time traffic can be achieved by providing remote-to-remote connections over a single satellite hop, as provided in mesh networks (Figure 7)

Figure 7 Single-Hop Mesh Overlay Network Topology

In a full-mesh network, all remotes can communicate directly with one another A mesh network is ideal for any application that is intolerant of the double-hop delays inherent in star networks and where remote-to-remote communications are required A mesh satellite network typically consists of a master terminal, which provides network management and network synchronization, and remote user terminals

One advantage of the iDirect Mesh implementation is that mesh remote terminals continue to

be part of the star network This allows the monitor and control functions and the timing reference for the mesh network to be provided by the existing hub equipment over the SCPC downstream carrier

In an iDirect Mesh network, the hub broadcasts to all remotes on the star outbound channel This broadcast transmits user traffic as well as the control and timing information for the entire network of inbound mesh and star channels The mesh remotes transmit user data on mesh TDMA inbound channels, which other mesh remotes are configured to receive

Note: The following remote model types are supported over iDirect Mesh: iNFINITI

5300/5350; iNFINITI 7300/7350; iNFINITI 8350; Evolution e8350; iConnex-100; iConnex-700; and iConnex e800.

Note: iDirect Mesh is logically a full-mesh network topology All remotes can

communicate directly with each other (and the hub) in a single-hop This is accomplished by allowing the remote to receive both the outbound channel from the hub and its home TDMA mesh inbound channel This is sometimes referred to as a star/mesh configuration When referring to the iDirect product portfolio, “star/mesh” and “mesh” are synonymous.

Figure 8 Basic Mesh Topology

• Determine hub-side rain fade

• Measure frequency offset introduced by the hub-side equipment

• Determine and track the location of the satellite relative to the hub

The hub accurately tracks the movement of the satellite The information is used by each remote to determine upstream timing synchronization

Note: The outbound loopback signal is demodulated on the same line card (M1D1

only) that modulates the outbound channel This line card is capable of demodulating a star or mesh inbound channel.

The outbound channel supporting a mesh network carries all outbound user data and the network monitoring and control information used to control the mesh inbound channels, including timing and slot allocation for the inbound channels; dynamic bandwidth allocation changes for the remotes The hub is the only node in a mesh network that transmits on the mesh outbound channel

The outbound channel in a mesh network has the following capabilities:

Bandwidth Management (QoS): The outbound channel possesses the full suite of QoS (Quality

of Service) functionality provided by iDirect This includes Committed Information Rate (CIR), minimum and maximum information rates, Class Based Weighted Fair Queuing (CBWFQ), etc Group QoS is fully supported for mesh networks beginning with iDS Release 8.2

Centralized Management: The iDirect mesh network can be managed from the centralized

Network Operations Center (NOC) running the iDirect NMS applications The hub provides connectivity for this centralized network management

Network Synchronization: The iDirect TDMA inbound channels take advantage of significant

bandwidth efficiency and performance enhancements provided by the accurate timing and frequency synchronization that the outbound channel provides The centralized hub provides the frequency and timing references to the remote terminals over the outbound channel This results in lower equipment costs for the remote terminals

Inbound D-TDMA Channels

Each mesh remote terminal must be able listen to its mesh home inbound channel echo return If a remote can hear itself, it can be assumed that all other remotes will also be able

to hear this remote (See “Routing” on page 20 to determine how the system behaves if a remote does not hear its own bursts.) The same low-noise block converter (LNB) must be used for both the outbound and inbound channels Frequency offsets introduced in the LNB are estimated for the outbound channel and applied to the inbound demodulator

A mesh network consists of one or more inroute groups Each mesh inroute group supports one

or more inbound Deterministic Time Division Multiple Access (D-TDMA) channel This shared

Mesh Topology Options

it does not transmit on these channels The remote terminals are assigned transmit time slots

on the inbound channels based on the dynamic bandwidth allocation algorithms provided by the hub

The D-TDMA channels provide the following capabilities:

Multiple Frequencies: A mesh network can contain one or more D-TDMA mesh inbound

channels for remote-to-remote and remote-to-hub connectivity within an inroute group Each terminal is able to quickly hop between these frequencies to provide the same efficient bandwidth usage as a single large TDMA channel, but without the high-power output and large antenna requirements for large mesh inbound channels Beginning with iDS Release 8.2, iDirect supports separate inbound carriers with different data rates for star and mesh See

“Mesh/Star Frequency Hopping ” on page 18 for details

Dynamic Allocation: Bandwidth is only assigned to remote terminals that need to transmit

data, and is taken away from idle terminals These allocation decisions are made several times a second by the hub which is constantly monitoring the bandwidth demands of the remote terminals The outbound channel is then used to transmit the dynamic bandwidth allocation of the mesh inbound carriers

Single Hop: Data is able to traverse the network directly from a remote terminal to another

remote terminal with a single trip over the satellite This is critical for latency-sensitive applications, such as voice and video connections

iDirect networks support a number of features, including the following:

• Application and Group QoS

• Voice jitter handling

• IP routing

• TCP/HTTP acceleration

• cRTP

All such iDirect features are valid and available for mesh networks

Mesh Topology Options

Physical Topology

You can design and implement a mesh network topology as either integrated mesh and star, or

as segregated mesh and star Both options are discussed in this section.

Integrated Mesh and Star Topology

To implement an integrated mesh and star network on an existing hub outbound and

infrastructure, the Network Operator uses the current outbound channel for the network, but adds additional mesh inbound channel(s) The existing outbound is used for both existing star remotes and for newly added mesh remotes The resulting hybrid network that includes star and mesh sub-networks is shown in Figure 9

Note: The different sizes of the star and mesh carriers in the figure represent the

higher power transmission required for mesh inroutes to operate at the

Mesh Topology Options

Figure 9 Integrated Mesh and Star Network

Multiple mesh and star inroute groups may co-exist in a single network Each mesh inroute group uses its own inbound channels for remote-to-remote traffic within the respective group and for star return traffic There are no limitations to the number or combination of inroute groups in a network, other than the bandwidth required and slot availability in a hub chassis for each inroute However, a mesh inroute group is limited to 250 remotes and eight inroutes

Segregated Mesh and Star Topology

To implement a segregated mesh and star network on an existing hub outbound and

infrastructure, the Network Operator adds a new outbound channel and one or more inbound channels to the existing network, resulting in a totally separate mesh network This topology can be achieved on two iDirect product platforms:

15000 series™ Satellite Hub (see Figure 10)

carrier and a single inbound carrier on the iDirect 10000 series™ Private Satellite Hub (see

Figure 11)

Mesh Topology Options

Figure 10 Segregated Mesh and Star Networks

Figure 11 Mesh Private Hub

Hub

Star Outbound

Star

Mesh Remote Group

Star Remote Group

Mesh Out Mesh In

Mesh Remote Group Mesh Outbound

Mesh Inbound

Mesh Topology Options

Network Topology

When determining the best topology for your iDirect Mesh network, you should consider the following points regarding TCP traffic acceleration, single-hop versus double-hop traffic, traffic between mesh inroute groups, and the relative size of your star and mesh carriers.All unreliable (un-accelerated) traffic between mesh-enabled remotes in an inroute group takes a single hop By default, all reliable traffic between the same remotes is accelerated and takes a double-hop This must be considered when determining the outbound channel bandwidth

In certain networks, the additional outbound traffic required for double-hop traffic may not

be acceptable For example, in a network where almost all the traffic is remote-to-remote, there is no requirement for a large outbound channel, other than for the accelerated TCP traffic In that case, iDirect provides the ability to configure TCP traffic to take a single hop between mesh remotes However, the single hop TCP traffic will not be accelerated

Note: When TCP acceleration (sometimes called “spoofing”) is disabled, each TCP

session is limited to a maximum of 128 kbps due to latency introduced by the satellite path Under ideal conditions, maximum throughput is 800 kbps without acceleration.

A network may consist of multiple inroute groups Although un-accelerated traffic within a mesh inroute group takes a single hop, all traffic between inroute groups takes a double hop

For example, if a network contains two mesh inroute groups (group A and group B), then a mesh remote in group A can communicate with a mesh remote in group B only via the hub.You may configure different symbol rates for star and mesh carriers in an inroute group The symbol rate for star carriers must be between 64 and 5750 ksym/s The symbol rate for mesh carriers must be between 128 ksym/s and 2048 ksym/s

When configuring two symbol rates, the following restrictions apply:

• All carriers (star and mesh) must have the same FEC rate and modulation type

• All star carriers in the inroute group must have the same symbol rate

• All mesh carriers in the inroute group must have the same symbol rate

• The symbol rate for star-only carriers must be greater than or equal to the symbol rate for mesh carriers

• The difference between the two symbol rates must be a multiple of 2n, where n is an

integer

Note: Since there is only one transmitter per remote, the overall data rate a remote

achieves on a star inroute is reduced by the amount of time spent transmitting

on the mesh inroutes Since it takes a longer time to transmit an equal amount

of data at a lower data rate, the star inroute capacity of the remote can be significantly reduced by mesh transmissions when different symbol rates are used for star and mesh.

The following section provides an example of a typical network topology carrying high-volume star traffic and low-volume mesh traffic

Mesh Topology Options

High-Volume Star / Low-Volume Mesh

The high-volume star/low volume mesh topology reflects the requirement to operate a network with higher data rate requirements for the star inbound and lower data rate

requirements for the mesh inbound channels This topology combines high-volume data traffic between the remotes and a central data repository (for example, Internet, intranet or HQ), with lower data rate mesh inbound channels used for low volume traffic sent directly

between remote peers (for example, one to four voice lines) Figure 12 shows an example of a high-volume star/low volume mesh network topology

The benefits of high-volume star / low-volume mesh are that the Network Operator does not suffer the additional costs associated with higher-specification BUCs and space segment that would be required for a higher-bandwidth mesh inbound channel (i.e 256+ kbps) that would not be fully occupied

To support this topology, Mesh Phase II allows you to configure different data rates for star and mesh traffic within a single inroute group

Figure 12 High-Volume Star / Low-Volume Mesh Topology

Frequency Hopping

Frequency Hopping

Mesh Phase II supports frequency hopping between mesh and star inbound channels within an inroute group

Mesh Frequency Hopping

A mesh remote receives a single mesh inbound channel, but can transmit on multiple mesh inbound channels Frequency hopping cannot be disabled for an inroute group containing multiple mesh inbound channels A mesh remote listens to both the TDM outbound channel and its configured “home” mesh inbound channel (See Figure 13 on p 17) The remote does not listen to multiple mesh inbound channels This requires that a remote always transmit to another mesh remote on the home inroute of the destination remote (See Figure 14 on p

18)

Figure 13 Mesh Frequency Hopping: Inroute Group with Two Inroutes

• All star-only carriers in the inroute group must have the same symbol rate.

• All mesh carriers in the inroute group must have the same symbol rate

• The difference between the two symbol rates must be a multiple of 2n, where n is an integer

• The symbol rate for star-only carriers must be greater than or equal to the symbol rate for mesh carriers

• No more than eight carriers (star and mesh) are allowed in the inroute group

Mesh Data Path

Figure 15 Frequency Hopping with Star and Mesh

Mesh Data Path

This section describes traffic selection, routing, and real-time setup for traffic in the mesh data path

Single-Hop and Double-Hop Traffic Selection

In a mesh network, the data path is dependent upon the type of traffic This dependency is important when designing and sizing the network and its associated outbound and inbound channels By default, only real-time, non-connection-oriented (non-TCP/un-accelerated) traffic traverses a mesh link from remote to remote This results in non-real-time, remote-to-remote traffic (TCP), which is latency tolerant, to flow through the hub This must be taken into consideration when sizing bandwidth Double-hop traffic is accelerated on both hops

Note: Allowing only non-TCP traffic to be transmitted directly from one remote to

another adds to the QoS functionality within the iDirect platform By default, only allowing the traffic that benefits from a single hop between remote results

in fewer configuration issues for the Network Operator Mesh inbound channels can be scaled appropriately for time-sensitive traffic such as voice and video.

Hardware Requirements

Routing

Prior to the introduction of the mesh feature, all upstream data from a remote was routed over the satellite to the hub protocol processor With the introduction of iDirect Mesh, additional routing information is provided to each remote in the form of a routing table This table contains routing information for all remotes in the mesh inroute group and the subnets behind those remotes The routing table is periodically updated based on the addition or deletion of new remotes in the mesh inroute group; the addition or deletion of static routes in the NMS; enabling or disabling of RIP; or in the event of failure conditions detected on the remote or line card The mesh routing table is periodically multicast to all remotes in the mesh inroute group

To increase remote-to-remote availability, the system provides data path redundancy for mesh traffic It is possible for a remote to drop out of the mesh network due to a deep rain fade at the remote site The remote detects this condition when it fails to receive its own bursts However, because the hub has a large antenna, the remote may still be able to operate in the star network Under these circumstances, the mesh routing table is updated, causing all traffic to and from that remote to be routed through the hub When the rain fade passes, the mesh routing table is updated again, and mesh traffic for that remote again takes the single-hop path

To operate in the mesh network, a mesh remote requires power, frequency and timing information determined by the hub from its SCPC loopback signal Because of this, the entire mesh network falls back to star mode if the hub fails to receive its loopback In that event,

the routing table is updated causing all traffic to or from all remotes to be routed through the

hub Once the hub re-acquires the outbound loopback signal, the mesh routing table is again updated and the remotes rejoin the mesh network

Real-Time Call Setup

Call setup times for real-time applications, such as VoIP voice calls within an iDirect mesh network, are identical to those of an iDirect star network (assuming other variables, such as available bandwidth and QoS settings, are similar) This mesh and star similarity also holds true in situations where a central call manager is installed at the hub to coordinate call setup

Hardware Requirements

This section describes the hub and remote hardware requirements for mesh networks Please refer to the section “Mesh Feature Set and Capability Matrix” on page 36 for a detailed list of iDirect products and features that support mesh

HUB RFT Equipment

The outbound TDM loopback channel and the inbound TDMA channel must take the same RF path at the Hub The Uplink Control Protocol (UCP) assumes that the frequency offsets that are introduced in the hub down-conversion equipment and the signal strength degradations in the downlink path are common to both the outbound TDM loopback channel and the inbound TDMA channel UCP does not work correctly and mesh peer remotes cannot communicate directly with each other if the hub RFT uses different equipment for each channel

Hardware Requirements

Hub Chassis Hardware

For a Hub Chassis configuration:

• The outbound carrier must be sourced by an M1D1 (or M1D1-T) iNFINITI line card

• The receive cable must be physically connected to the receive port on the M1D1 card

• The inbound carrier must be demodulated by either an M1D1 or M0D1 iNFINITI line card hub

Note: A NetModem II Plus line card does not support mesh.

Private Hub Hardware

Only iNFINITI Private Hubs support mesh for both the outbound an inbound carriers

Minihub-15, Minihub-30 Private Hubs do not support mesh

Hub ODU Hardware

If an LNB is used at the hub (Hub Chassis or Private Hub), it must be an externally referenced PLL downconverter LNB

Remote IDU Hardware

Only iNFINITI 5300/5350, 7300/7350, 8350, Evolution e8350, and iCONNEX-100/700/e800 remote models support mesh

The iDirect mesh terminal consists of the following components and features that are all integrated into a single indoor unit (IDU):

Integrated Features: IP Router, TCP Optimization, RTTM feature (Application and System

QoS), cRTP, Encryption, MF-TDMA, D-TDMA, Automatic Uplink Power Control and Turbo Coding

TDM Outbound Receiver: Continuously demodulates the outbound carrier from the hub and

provides the filtered IP packets and network synchronization information The outbound receiver connects to the antenna LNB via the L-band receive IFL cable The down-converted satellite spectrum from the LNB is also provided to the D-TDMA receiver

TDMA Satellite Transmitter: The TDMA transmitter is responsible for transmitting all data

destined for the hub or for other remote terminals over the satellite TDMA channels

TDMA Satellite Receiver: The TDMA receiver is responsible for demodulating a TDMA carrier

to provide remote-to-remote mesh connectivity The receiver tunes to the channel based on control information received from the hub

Remote ODU Hardware

In addition to the correct sizing of the ODU equipment (remote antenna and remote BUC) to

close the link, a PLL LNB must be used for the downconverter at the remote.

Network Considerations

Note: Compared to star VSAT networks, where the small dish size and low-power BUC

are acceptable for many applications, a mesh network typically requires both

Link Budget Analysis

When designing a mesh network, attention must be given to ensuring that equipment is correctly sized A Link Budget Analysis (LBA) for the outbound channel is performed in the same way for both a star and mesh network Typically, the outbound channel operates at the Equal Power Equal BandWidth (EPEBW) point on the satellite

In a star network, the inbound channel is typically configured to operate at a point lower than the EPEBW point A mesh inbound channel operates at or near EPEBW The link budget analysis provides a per-carrier percentage of transponder power or Power Equivalent

Bandwidth (PEB) where the availability of the remote-remote pair is met For a given data rate, this PEB is determined by the worst-case remote-to-remote (or possibly remote-to-hub) link The determination of BUC size, antenna size, FEC rate and data rate is an iterative process designed to find the optimal solution

Once determined, the PEB is used as the target or reference point for sizing subsequent mesh remotes It can be inferred that a signal reaching the satellite from any other remote at the operating or reference point is detected by the remote in the worst-case EIRP contour (assuming fade is not greater than the calculated fade margin) Remote sites in more

favorable EIRP contours may operate with a smaller antenna/BUC combination

Note: iDirect recommends that an LBA be performed for each site to determine

optimal network performance and cost.

Network Considerations

Mesh Link Budget Outline

This section outlines the general tasks for determining a mesh link budget Refer to Figure 16

Figure 16 Mesh VSAT Sizing

To determine a mesh Link Budget Analysis, perform the following tasks:

1 Reference Mesh VSAT: Using the EIRP and G/T footprints of the satellite of interest and

the region to be covered, determine the current or future worst-case site (Step 1) The first link calculation is this worst-case site back to itself (Step 2) Using various

combinations of antenna size, HPA size, and FEC that provides the most efficient

transponder usage and practical VSAT sizing for the desired carrier rate (Steps 3 and 4) The percentage of transponder power or Power Equivalent Bandwidth PEB required is the reference point for subsequent link budgets

2 Forward/Downstream Carrier: Using the reference site and its associated antenna size

determined in Task 1, determine the combination of modulation and FEC that provides the most efficient transponder usage

3 Successive Mesh VSATs: The sizing of additional sites is a two step process, with the first

link budget sizing the antenna and the second sizing the HPA

Network Considerations

the Reference site, the antenna size is correctly determined when the PEB is less than

or equal to the reference PEB

determine the required HPA size

Uplink Control Protocol (UCP)

Changes have been made to the iDirect UPC algorithm used to maintain optimal operation (at the physical layer) of a remote in a mesh network These changes affect frequency, power and timing

Frequency

In a star configuration, frequency offsets introduced to the upstream signal (by frequency down-conversion at a remote’s LNB, up-conversion at a remote’s BUC, satellite frequency translation, and down-conversion at the hub) are all nulled out by Uplink Control Protocol messages from the hub to each remote This occurs every 20 seconds Short-term frequency drift by each remote can be accommodated by the hub because it uses a highly stable reference to demodulate each burst

A remote does not have such a highly stable local reference source The remote uses the outbound channel as a reference source for the inbound channel A change in temperature of

a DRO LNB can cause a significant frequency drift to the reference In a mesh network, this can have adverse effects on both the SCPC outbound and TDMA inbound carriers, resulting in

a remote demodulator that is unable to reliably recover data from the mesh channel A PLL LNB offers superior performance, since it is not subject to the same short term frequency drift

Power

A typical iDirect star network consists of a hub with a large antenna, and multiple remotes with small antennas and small BUCs In a star network, UPC adjusts each remote’s transmit power on the inbound channel until a nominal carrier-to-noise signal strength of

approximately 9 dB is achieved at the hub Because of the large hub antenna, the operating point of a remote is typically below the contracted power (EPEBW) at the satellite For a mesh network, where remotes typically have smaller antennas than the hub, a remote does not reliably receive data from a another remote using the same power It is therefore

important to maximize the use of all available power

UPC for a mesh network adjusts the remote Tx power so that it always operates at the EIRP at beam center on the satellite to close the link, even under rain fade conditions This can be equal to or less than the contracted power/EPEBW Larger antennas and BUCs are required to meet this requirement The EIRP at beam center and the size of the equipment are calculated based on a link budget analysis

The UPC algorithm uses a combination of the following parameters to adjust each remote transmit power to achieve the EIRP@BC at the satellite:

• Clear-sky C/N for each TDMA inbound and for the SCPC outbound loopback channels (obtained during hub commissioning)

Network Considerations

• The hub UPC margin (the extent to which external hub-side equipment can accommodate hub UPC1)

• The outbound loopback C/N at the hub

• Each remote inbound C/N at the hub

The inbound UPC algorithm determines hub-side fade, remote-side fade, and correlated fades

by comparing the current outbound and inbound signal strengths against those obtained during clear sky calibration For example, if the outbound loopback C/N falls below the clear sky condition, it can be assumed that a hub-side fade (compensated by hub side UPC)

occurred Assuming no remote side fade, an equivalent downlink fade of the inbound channel would be expected No power correction is made to the remote If hub-side UPC margin is exceeded, then outbound loopback C/N is affected by both uplink and downlink fade and a significant difference compared to clear sky would be observed

Similarly if the inbound C/N drops for a particular remote and the outbound loopback C/N does not change compared to the clear sky value, UPC increases the remote transmit power until the inbound channel clear sky C/N is attained Similar C/N comparisons are made to accommodate correlated fades

UPC now operates on a per carrier basis Each carrier’s individually commissioned clear-sky C/N is used by the algorithm when monitoring and adjusting the carrier

Note: For each remote in a mesh network, the inbound C/N at the hub is likely to be

greater than that typically observed in a star network Also, when a remote is

in the mesh network, the nominal C/N signal strength value for a star network

is not used as the reference.

In the event of an outbound loopback failure, the UPC algorithm reverts to star mode This redundancy allows remotes in a mesh inroute group to continue to operate in star only mode

Figure 17 illustrates Uplink Power Control

1 iDirect equipment does not support hub-side UPC Typical RFT equipment at a teleport installation uses a beacon receiver to measure downlink fade An algorithm running in the beacon receiver calcu-lates equivalent uplink fade and adjusts an attenuator to ensure a constant power (EPEBW) at the