technical reference guide 8

7/27/2019 Technical Reference Guide 8

1/158

TECHNICALREFERENCEGUIDE

IDS RELEASE8.2

March 07, 2008


2/158

ii Technical Reference Guide iDS Release 8.2

Copyright 2008 iDirect, Inc. All rights reserved. Reproduction in whole or in part without permission is

prohibited.

The specifications and information regarding the products in this document are subject to change withoutnotice. 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 fortheir application of any products.

Trademarks, brand names and products mentioned in this document are the property of their respectiveowners. All such references are used strictly in an editorial fashion with no intent to convey any affiliationwith the name or the product's rightful owner.

iDirect, Inc.International Headquarters13865 Sunrise Valley DriveHerndon, VA 20171www.iDirect.net(888) 362-5475

(703) 648-8080


3/158

Technical Reference Guide iDS Release 8.2 iii

Contents

About This Guide

Purpose ..........................................................................xv

Intended Audience.............................................................xvHow to Use This Guide ........................................................xv

Document Conventions.......................................................xvi

Getting Help ...................................................................xvi

1 iDirect System OverviewSystem Overview................................................................1

IP Architecture ..................................................................2

2 Mesh Technical Description

Mesh Theory of Operation .....................................................7

Network Architecture ........................................................ 11

Transponder Usage . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . 11

Outbound TDM Channel . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 12

Inbound D-TDMA Channels . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 13

Mesh Topology Options....................................................... 14

Physical Topology. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . 14

Network Topology. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . 17

Frequency Hopping ........................................................... 21

Mesh Frequency Hopping. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 21

Mesh/Star Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
http://-/?-http://-/?-


4/158

iv Technical Reference Guide iDS Release 8.2

Mesh Data Path ................................................................ 23

Single-Hop and Double-Hop Traffic Selection . . . . . . . . . . . . . . . . . . . . . . . 23

Routing . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 24

Real-Time Call Setup . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . 25

Hardware Requirements ..................................................... 25

HUB RFT Equipment. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . 25

Hub Chassis Hardware . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 25

Private Hub Hardware . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 26

Hub ODU Hardware. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . 26

Remote IDU Hardware . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 26

Remote ODU Hardware . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 26

Network Considerations...................................................... 27

Link Budget Analysis . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . 27

Uplink Control Protocol (UCP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Bandwidth Considerations . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 33

Mesh Commissioning .......................................................... 34

Star-to-Mesh Network Migration ............................................34Pre-Migration Tasks . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . 34

Migration Tasks . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . 35

Configuring and Monitoring Mesh Networks ............................... 36

Building Mesh Networks . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 36

Special Mesh Constants . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 36

Turning Mesh On and Off in iBuilder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Changes to Acquisition/Uplink Control in iBuilder. . . . . . . . . . . . . . . . . 37

Monitoring Mesh Networks................................................... 39

Additional Hub Statistics Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Additional Remote Status Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40


5/158

Technical Reference Guide iDS Release 8.2 v

Mesh Traffic Statistics. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 40Remote-to-Remote Mesh Probe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Long-Term Bandwidth Usage Report for Mesh. . . . . . . . . . . . . . . . . . . . . . . 43

Mesh Feature Set and Capability Matrix................................... 44

3 Modulation Modes and FEC RatesiDirect Modulation Modes And FEC Rates ................................. 47

Upstream and Downstream Combinations ................................ 49

4 iDirect Spread Spectrum Networks

What is Spread Spectrum? ................................................... 51

Spread Spectrum Hardware Components ................................. 53

Downstream Specifications.................................................. 53

Supported Forward Error Correction (FEC) Rates ........................ 54

Calculating CRL Acquisition Time .......................................... 55

Total Acquisition Time . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 55

Upstream Specifications ..................................................... 55

5 QoS Implementation Principles

Quality of Service (QoS) ..................................................... 57

QoS Measures .................................................................. 57

QoS Application, iSCPC and Filter Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Classification Profiles for Applications .................................... 60

Service Levels . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . 60

Packet Scheduling . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . 60

Group QoS...................................................................... 63


6/158

vi Technical Reference Guide iDS Release 8.2

Group QoS Structure . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . 64

Group QoS Scenarios . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . 67

Application Throughput ...................................................... 76

QoS Properties . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . 77

Packet Segmentation ......................................................... 80

Application Latency .......................................................... 81

Maximum Channel Efficiency vs. Minimum Latency ..................... 81

6 Configuring Transmit Initial Power

What is TX Initial Power? .................................................... 83

How To Determine The Correct TX Initial Power ........................ 83

All Remotes Need To Transmit Bursts in The Same C/N Range ........ 84

What Happens When TX Initial Power Is Set Incorrectly? ............... 85

When TX Initial Power is Too High . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

When TX Initial Power is Too Low. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

7 Global NMS Architecture

How the Global NMS Works .................................................. 89

Sample Global NMS Network ................................................ 91

8 Hub Network Security RecommendationsLimited Remote Access ...................................................... 93

Root Passwords ................................................................ 93

9 Global Protocol Processor Architecture


7/158

Technical Reference Guide iDS Release 8.2 vii

Remote Distribution .......................................................... 95De-coupling of NMS and Datapath Components .......................... 96

10 Distributed NMS Server

Distributed NMS Server Architecture ...................................... 97

iBuilder and iMonitor ......................................................... 99

dbBackup/dbRestore and the Distributed NMS ..........................100

Distributed NMS Restrictions ...............................................102

11 Transmission Security (TRANSEC)

What is TRANSEC?............................................................103

iDirect TRANSEC..............................................................104

TRANSEC Downstream.......................................................105

TRANSEC Upstream ..........................................................107

TRANSEC Key Management .................................................109

TRANSEC Remote Admission Protocol ....................................112

Reconfiguring the Network for TRANSEC .................................113

12 Fast Acquisition

Feature Description .........................................................115

13 Remote Sleep Mode

Feature Description .........................................................117

Awakening Methods..........................................................117

Operator-Commanded Awakening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118


8/158

viii Technical Reference Guide iDS Release 8.2

Activity Related Awakening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118

Enabling Remote Sleep Mode ..............................................120

14 Automatic Beam Selection

Automatic Beam Selection Overview .....................................121

Theory of Operation .........................................................121Beam Characteristics: Visibility and Usability. . . . . . . . . . . . . . . . . . . . . .123

Selecting a Beam without a Map. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123

Controlling the Antenna . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 124

IP Mobility. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 124

Operational Scenarios .......................................................125

Creating the Network. . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. 125

Adding a Vessel . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . 126

Normal Operations . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. 127

Mapless Operations . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . 127

Blockages and Beam Outages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128

Error Recovery. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . .. . . . . . . 128

15 Hub Geographic Redundancy

Feature Description..........................................................129

Configuring Wait Time Interval for an Out-of-Network Remote ......130

16 Carrier Bandwidth Optimization

Overview ......................................................................131

Increasing User Data Rate ..................................................132

Decreasing Channel Spacing to Gain Additional Bandwidth ...........135


9/158

Technical Reference Guide iDS Release 8.2 ix

17 Hub Line Card FailoverBasic Failover Concepts.....................................................137

Tx(Rx) versus Rx-Only Line Card Failover ................................137

Failover Sequence of Events ...............................................138

Failover Operation: Users Perspective ..................................140


10/158

x Technical Reference Guide iDS Release 8.2


11/158

Technical Reference Guide iDS Release 8.2 xi

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 ..........................................................11

Figure 9: Integrated Mesh and Star Network .........................................15

Figure 10: Segregated Mesh and Star Networks ......................................16

Figure 11: Mesh Private Hub ............................................................17

Figure 12: High-Volume Star / Low-Volume Mesh Topology........................19

Figure 13: Low-Volume Star / High-Volume Mesh Topology........................20

Figure 14: Mesh Frequency Hopping: Inroute Group with Two Inroutes..........21

Figure 15: Mesh Frequency Hopping: Communicating Between Inroutes.........22Figure 16: Frequency Hopping with Star and Mesh ..................................23

Figure 17: Mesh VSAT Sizing.............................................................28

Figure 18: Uplink Power Control........................................................32

Figure 19: Specifying UPC Parameters.................................................38

Figure 20: Common Remote Parameters for Mesh ...................................39

Figure 21: Mesh, SAT, IP statistics collection.........................................42Figure 41: Spread Spectrum Network Diagram .......................................51

Figure 42: Remote and QoS Profile Relationship.....................................59

Figure 43: iDirect Packet Scheduling Algorithm......................................61

Figure 16: Group QoS Structure.........................................................64

Figure 17: Physical Segregation Scenario .............................................68

Figure 18: CIR Per Application Scenario ...............................................70


12/158

xii Technical Reference Guide iDS Release 8.2

Figure 19: Tiered Service Scenario .....................................................72

Figure 20: Third Level VLAN Scenario..................................................74

Figure 22: C/N Nominal Range ..........................................................85

Figure 23: TX Initial Power Too High ...................................................86

Figure 24: TX Initial Power Too Low ...................................................87

Figure 25: Global NMS Database Relationships ......................................90

Figure 26: Sample Global NMS Network Diagram.....................................91

Figure 27: Protocol Processor Architecture ...........................................96

Figure 28: Sample Distributed NMS Configuration ...................................98

Figure 29: dbBackup and dbRestore with a Distributed NMS ..................... 101

Figure 30: Downstream Data Path .................................................... 105

Figure 31: SCPC TRANSEC Frame ..................................................... 106

Figure 32: Upstream Data Path ....................................................... 107

Figure 33: TDMA TRANSEC Slot........................................................ 108

Figure 34: Key Distribution Protocol ................................................. 110

Figure 35: Key Rolling and Key Ring.................................................. 111

Figure 36: Host Keying Protocol ...................................................... 112

Figure 37: Overlay of Carrier Spectrums ............................................ 132

Figure 38: Adding an Upstream Carrier By Reducing Carrier Spacing........... 135Figure 39: Failover Sequence of Events, NMS Server Perspective ............... 139

Figure 40: Failover Sequence of Events, NMS User Perspective ................. 141


13/158

Technical Reference Guide iDS Release 8.2

Tables

Table 1: Mesh-Related Constants.......................................................36

Table 2: Mesh IP Statistics Example....................................................41

Table 3: iDS Products Supporting Mesh................................................44

Table 4: Mesh Feature Set and Capability Matrix ....................................45

Table 5: FEC Rates and Modulation Modes ............................................48

Table 6: Upstream and Downstream Combinations..................................49

Table 5: Downstream Specification ....................................................53

Table 6: Supported FEC Rates...........................................................54

Table 7: Upstream Specifications ......................................................55


14/158

xiv Technical Reference Guide iDS Release 8.2


15/158

About This Guide

Technical Reference Guide iDS Release 8.2 xv

ABOUTTHISGUIDE

This section includes the purpose, intended audience, contents, document conventions, and

getting help.

PURPOSE

The Technical Reference Guide provides detailed technical information on iDirect technology

and major features as implemented in Release 8.2.

INTENDEDAUDIENCE

The intended audience for this guide is network operators using the iDirect iDS system, network

architects, and anyone upgrading to iDS Release 8.2.

Note: I t is expect ed that t he user of t h is mater ia l has at t ended the iDi r ect IOM tr a in ing

course and is f amil i ar w it h the iDir ect St ar net wor k solut ion and associat ed

equipment.

HOWTOUSETHISGUIDEThis guide is divided into parts. Each part contains a chapter that describes a new feature for

that release. At the end of each part, there is a chapter that describes enhancements to a

previous minor release feature. If you need more information about that feature, there arecross-references that point you to the chapter in the previous release that fully describes that

feature.


16/158

About Th is Guide

xvi Technical Reference Guide iDS Release 8.2

DOCUMENTCONVENTIONSThis section illustrates and describes the conventions used throughout the manual. Take a look

now, before you begin using this manual, so that you can correctly interpret the information

presented.

There are important notes throughout this guide that are presented as follows:

Note: Text w r i t t en wi t h bold i t a l ic indicat es note informat ion. This infor mat i on is ofin t erest t o you, and pert a ins t o the part of t he procedure in which i t is l ist ed. Make

sure you r eview t his inf ormat ion befor e you pr oceed.

GETTINGHELP

The iDirect Technical Assistance Center (TAC) is available to help you 24 hours per day, 365 daysof the year. Software releases, upgrades and patches, documentation that supports our

products, and an FAQ page are available on the TAC web page. Please access our TAC web page

at: http://tac.idirect.net.

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

648-8151.


17/158

iDirect System Overview

Technical Reference Guide iDS Release 8.2 1

1 IDIRECTSYSTEMOVERVIEW

This chapter gives a high level overview of an iDirect Network using iDS Release 8. It provides a

sample iDirect network and describes IP architecture in SCPC and TDMA networks.

SYSTEMOVERVIEW

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


18/158


2 Technical Reference Guide iDS Release 8.2

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. Eachremote node consists of an iDirect broadband router and the appropriate external VSAT

equipment. The remotes transmit to the hub on one or more shared upstream carriers using

Deterministic-Time Division Multiple Access (D-TDMA), based on dynamic timeplan slot

assignment generated at the Protocol Processor.

A Mesh overlay can be added to the basic Star network topology, allowing traffic to pass directly

between remote sites without traversing the hub. This allows real-time traffic to reach its

destination in a single satellite hop, significantly reducing delay. It also saves the bandwidthrequired to retransmit Mesh traffic from the hub to the destination remote. For a description of

the iDirect Mesh overlay architecture, see Mesh Technical Description on page 7.

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, TCPacceleration, 3-DES or 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, and VoIP support via voice optimized features such as cRTP.

An iDirect network interfaces to the external world through IP over Ethernet via 10/100 Base-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


19/158



Figure 2. iDirect IP Architecture Multiple VLANs per Remote

iDi t S t O i


20/158



Figure 3. iDirect IP Architecture VLAN Spanning Remotes



21/158



Figure 4. iDirect IP Architecture Classic IP Configuration

iDS Release 8.0 allows you to mix traditional IP routing based networks with VLAN based

configurations. This capability provides support for customers that have conflicting IP addressranges 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



22/158



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 adedicated 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 5shows an iDirect system containing an iSCPC link

and a TDMA network, all under the control of the NMS.

Figure 5. iDirect IP Architecture - TDMA and iSCPC Topologies

Mesh Technical Description


23/158



2 MESHTECHNICALDESCRIPTION

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 ofiDirects 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.

iDirects 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 is available beginning with Release 8.2.

iDS Release 8.2 introduces the second phase of iDirect Mesh. Mesh Phase II adds the following

enhancements to the 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 (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 44.

MESHTHEORYOFOPERATION

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.



24/158

p


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

network (Figure 6).

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.



25/158

p


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 networkis 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



26/158


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.

Not e: The f ol low ing remot e model t ypes are support ed over iDirect Mesh: iNFINITI 5300/

5350; iNFINIT I 7300/7 350; i NFINITI 8350; Evolut ion E8350; i Connex-100; i Connex-700; and i Connex E800.

Each mesh remote is configured with a home mesh inroute. A mesh remote receives its home

inroute using the second demodulator on the Indoor Unit (IDU). All mesh transmissions to the

remote must be sent on the home inroute of the destination remote. Therefore, any peer

remote sending single-hop data must frequency hop to the peers home inroute before

transmitting.

Not e: iDirect Mesh is logical l y a f ul l -mesh netw ork t opology. Al l r emotes can communicat e

dir ect ly w it h each other (and t he hub) in a single-hop. T his is accompl ished by

al l owing t he r emot e to r eceive bot h the outbound channel f rom t he hub and it s home

TDMA mesh inbound channel. T his is somet imes ref err ed t o as a st ar /mesh

conf igurat ion. When ref err i ng t o the iDi r ect product port fo l i o , star /mesh and

mesh a r e synonymous.



27/158


Figure 8. Basic Mesh Topology

NETWORKARCHITECTURE

All mesh networks consist of a single broadcast outbound channel and at least one mesh TDMA

inbound channel per inroute group.

Transponder Usage

The outbound and inbound channels must use the same transponder.



28/158


Outbound TDM Channel

The outbound channel for a mesh network is similar to the outbound channel for a star network,

except for the differences noted in this section.

The hub must be able to receive its own mesh outbound channel (loopback signal). This signal

provides methods to:

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.

Not e: The out bound loopback signal i s demodulat ed on the same l ine card (M1D1 only) t hat

modulat es t he outb ound channel. Thi s l i ne card i s capable of demodulat ing a st ar or

mesh i nbound 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 ofService) 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 Release 8.2.

Centralized Management: The iDirect mesh network can be managed from the centralizedNetwork 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 significantbandwidth 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.



29/158


Inbound D-TDMA ChannelsEach 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 24to 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

access channel provides data and voice IP connectivity for remoteto-remote and remoteto-hub

communications. Although the hub receives and demodulates the mesh inbound channels, 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 channelsfor 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 Release 8.2, iDirect supports separate inbound

carriers with different data rates for star and mesh. See Mesh/Star Frequency Hopping onpage 22for 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 anotherremote 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



30/158


IP routing

TCP/HTTP acceleration cRTP

All such iDirect features are valid and available for mesh networks.

MESHTOPOLOGYOPTIONS

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.

Not e: The dif f erent sizes of t he st ar and mesh carr ier s in t he f igure repr esent t he higher

power t ransmission requi red f or mesh inroutes to operat e at t he cont ract ed power.



31/158


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 andinfrastructure, 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:

Hub Mesh: Separate outbound carriers and separate inbound carrier(s) on the iDirect 15000series Satellite Hub (see Figure 10).



32/158


Mesh Private Hub: A standalone segregated mesh option using an additional outbound carrier

and a single inbound carrier on the iDirect 10000 series Private Satellite Hub (seeFigure 11).

Figure 10. Segregated Mesh and Star Networks

Hub

Star

Outbound

Star

In

Mesh

Out

Mesh

In

Mesh Remote

Group

Star Remote

Group

Star Outbound

Star Inbound

Mesh Outbound

Mesh Inbound



33/158


Figure 11. Mesh Private Hub

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.

Private

Hub

Mesh

Out

Mesh

In

Mesh Remote

Group

Mesh Outbound

Mesh Inbound



34/158


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 isno requirement for a large outbound channel, other than for the accelerated TCP traffic. In that

cases, iDirect provides the ability to disable TCP acceleration for the entire mesh inroute group.

When this option is selected, TCP acceleration is disabled both from the hub to the remotes and

between the remotes, allowing all remote-to-remote traffic to take a single hop.

Note: When TCP acceler at ion (somet imes call ed spoof ing ) is disabled, each TCP session

is l imi t ed to a maximum of 128 kbps due t o lat ency int r oduced by t he sat e l l i t e path.

Under ideal condit ions, maxi mum t hroughput i s 800 kbps wi t hout accelerat ion.

A network may consist of multiple inroute groups. Although un-accelerated traffic withina mesh

inroute group takes a single hop, all traffic betweeninroute 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 meshcarriers 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 formesh carriers.

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

Note: Since there is only one t ransmi t t er per r emote, t he overa l l dat a rat e a remot e

achieves on a st ar i nrout e is reduced by t he amount of t ime spent t ransmit t ing on

t he mesh inrout es. Since it t akes a longer t ime t o tr ansmit an equal amount of dat a

at a lower dat a rat e, the st ar inr out e capaci t y of t he remote can be signi f icant ly

reduced by mesh t ra nsmissions when dif f erent symbol r at es are used for st ar and

mesh.

Two network topologies are described below: high-volume star/low volume mesh, and low-

volume star/high volume mesh.



35/158


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). (See Figure 12 on page 19).

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, iDS Release 8.2 adds the capability to configure different data rates for

star and mesh traffic within a single inroute group.

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



36/158


Low-Volume Star / High-Volume Mesh

The low-volume star/high volume mesh topology reflects the opposite requirement to high-

volume star/low-volume mesh. This topology can be implemented for a network that requires a

lower data rate star outbound channel (64+ kbps) and higher data rate mesh inbound channels.

This allows higher levels of traffic to be sent directly between remote peers. (See Figure 13 on

page 20.) Alternatively, a single inbound channel could be configured to carry both star and

mesh traffic.

Figure 13. Low-Volume Star / High-Volume Mesh Topology



37/158


FREQUENCYHOPPINGIDS release 8.2 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 meshinbound 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 14 on page 21). 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 15 on

page 22).

Figure 14. Mesh Frequency Hopping: Inroute Group with Two Inroutes



38/158


Figure 15. Mesh Frequency Hopping: Communicating Between Inroutes

Mesh/Star Frequency Hopping

Frequency hopping also allows remotes to transmit on both mesh and star inbound carriers, but

the remote only receives its home mesh inbound channel. (See Figure 16 on page 23.) You can

configure different symbol rates for star and mesh carriers in the same inroute group. However,

some restrictions apply:

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 formesh carriers.

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



39/158


Figure 16. Frequency Hopping with Star and Mesh

MESHDATAPATH

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



40/158


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 intoconsideration when sizing bandwidth. Double-hop traffic is accelerated on both hops.

Note: Al lowing only non-TCP t raf f ic t o be tr ansmi t t ed di rect ly f rom one remote t o another

adds t o the QoS funct ional i t y wi t h in the iDi r ect plat for m. By defaul t , only al lowing

t he t raf f ic t hat benef i t s f r om a single hop betw een remot e resul t s in fewer

confi gurat ion issues f or t he Net wor k Oper at or. Mesh inbound channels can be scaled

appropr i a t e ly f or t ime-sensi t ive t raf f ic such as voice and video.

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 ofnew 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 starnetwork. 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 alltraffic to or from allremotes 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.



41/158


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.

HARDWAREREQUIREMENTS

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 44for 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.

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 li ne card does not suppor t mesh.



42/158


Private Hub Hardware

Only iNFINITI Private Hubs support mesh for both the outbound an inbound carriers. Minihub-15,

Minihub-30 and Netmodem II Plus 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 outboundreceiver 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 datadestined 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 oncontrol 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 mustbe used for the downconverter at the remote.



43/158


Not e: Compared t o st ar VSAT netw orks, where t he smal l dish size and l ow-power BUC ar e

accept able for many appl i cat ions, a mesh net work t ypica l ly r equi r es both lar gerdi shes and BUC t o close t he li nk. See Netw ork Consider at ions on page 27.

Whenever possible, iBuilder enforces hardware requirements during network configuration.

NETWORKCONSIDERATIONSThis section discusses the following topics with respect to iDirect Mesh networks: Link Budget

Analysis,Uplink Control Protocol (UCP),and Bandwidth Considerations.

Link Budget Analysis

When designing a mesh network, attention must be given to ensuring that equipment iscorrectly 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 isdetermined 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 EIRPcontours may operate with a smaller antenna/BUC combination.

Not e: iDir ect recommends t hat an LBA be perf ormed f or each sit e to det ermine opt imal

netw ork perf ormance and cost .



44/158


Mesh Link Budget Outline

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

Figure 17. Mesh VSAT Sizing

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

1. Ref er ence 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



45/158


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 forsubsequent link budgets.

2. Forw ard/ Downst ream Carr ier: 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. Successiv e 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.

Ant enna Si ze: Calculate a link budget using the Reference VSAT as the transmit site andthe new site as the receive site. Using the same carrier parameters as those for the

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

equal to the reference PEB.

HPA Size:Use the same carrier parameters as those used for the Reference site todetermine 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 remotes LNB, up-conversion at a remotes 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.



46/158


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 remotes 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 remotetransmit 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)

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

1. iDirect equipment does not support hub-side UPC. Typical RFT equipment at a teleport installation usesa beacon receiver to measure downlink fade. An algorithm running in the beacon receiver calculatesequivalent uplink fade and adjusts an attenuator to ensure a constant power (EPEBW) at the satellite forthe outbound carrier. The beacon receiver and attenuator is outside of iDirects control. For a hub with-out UPC, the margin is set to zero.



47/158


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 carriers individually commissioned clear-sky C/N

is used by the algorithm when monitoring and adjusting the carrier.

Not e: For each remote in a mesh net wor k, t he inbound C/N at t he hub is l i kely t o be great er

t han that t yp ica l ly observed in a st ar net work. Also, w hen a r emote is in t he mesh

netw ork, t he nominal C/N signal st rength val ue f or a star netw ork i s not used as t he

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 18illustrates Uplink Power Control.



48/158


Figure 18. Uplink Power Control



49/158


Timing

An inbound channel consists of a TDMA frame with an integer number of traffic slots. In a star

network, during the acquisition process, the arrival time of the Start of the TDMA frame/

inbound channel at the hub is determined. The acquisition algorithm adjusts in time the start of

transmission of the frame for each remote such that it arrives at the satellite at exactly the

same time. The burst scheduler in the protocol processor ensures that two remotes do not burst

at the same time. With this process the hub line card knows when to expect each burst relative

to the outbound channel transmit reference. As the satellite moves within its station keeping

box, the uplink control protocol adjusts the Start timing of a frame for each remote, so that theinbound channel frame always arrives at the hub at the same time.

A similar mechanism that informs a remote when to expect the start of frame for the inbound

channel is required. This is achieved by determining the round trip time for hub-to-satellite-to-

hub from the outbound channel loopback. This information is relayed to each remote. An

algorithm determines when to expect the Start of the inbound channel, and determines burst

boundaries.

Not e: A mesh remot e l ist ens t o al l inbound channel bur st s, i ncluding bursts i t ori ginat es.

Only t hose bursts t r ansmi t t ed fr om ot her r emotes and dest ined for t hat r emote ar e

processed by sof t war e. Al l ot her t raf f ic is dropped, i ncluding burst s t ransmi t t ed by

t he remote i t se l f .

Bandwidth Considerations

When determining bandwidth requirements for a mesh network, it is important to understand

that there are a number of settings that must be common to all remotes in an inroute group. In

a star network, a VLAN can be configured on a hub-remote pair basis. For a mesh network, all

remotes in the inroute group must have a common VLAN configuration. VLAN IDs require two

bytes of header for transmission. An additional two bytes is required to indicate that the

destination applies to mesh traffic only. Star traffic is unaffected; however, if VLAN is

configured, it is also enabled for traffic to the hub.

In a star network, remote status is periodically sent to the hub and reported in iMonitor. With

the same periodicity, additional status information is reported on the health of the mesh link.

This traffic is nominal.

There is a finite amount of processing capability on any remote. A mesh remote receives and

processes star outbound traffic; processes and sends star and mesh inbound traffic; and receives

and processes mesh inbound traffic. The amount of traffic a remote can maintain on the



50/158


outbound and inbound channels varies greatly depending on the short term ratio. It must be

understood that although a line card can support an inbound channel of 4 Mbps aggregated

across many remotes, a remote-remote connection will notsupport this rate. However, a

remote does drop inbound traffic not destined for it, thereby limiting unnecessary processing of

bursts. Sample performance curves are available from iDirect.

MESHCOMMISSIONING

The commissioning of a mesh network requires a few steps that are not required for thecommissioning of a star network. Due to the requirement for the mesh inbound channel to

operate at the contracted power point on the satellite, calibration of both the outbound

loopback and each mesh inbound channel at the hub under clear sky conditions is required

during commissioning. Signal strength measurements (C/N) of the respective channels observed

in iMonitor are recorded in iBuilder. The clear sky C/N values obtained during commissioning are

used for uplink power control of each remote.

Not e: In a mesh net wor k, wher e relat ively smal l ant ennas (compared t o t he hub antenna)

are used at remot e si t es, addi t ional at t ent i on t o Link Budget Analysis (LBA) is

requir ed. Each remot e requir es an LBA to det ermine ant enna and BUC size f or t he

in tended ava i lab i l i t y and data r a t e .

Note: In order f or a mesh netw ork t o operat e opt imal ly and t o prevent over-dr i v ing t he

sat el l i t e, commissioning must be perf ormed under clear sky condit ions. See the

iBui l der User Guide for mor e informat ion.

STAR-TO-MESHNETWORKMIGRATIONThere are tasks to perform prior to migrating from a star to a mesh network, as well as tasks to

perform during the migration. These tasks are summarized in this section. See theiBuilder User

Guidefor a detailed procedure.

Pre-Migration Tasks

Prior to converting an existing star network to a mesh network, iDirect recommends that you

perform the following:

A link budget analysis comparison for star/mesh versus the star-only network.



51/158


Verification of the satellite transponder configuration for the hub and each remote. All hubs

and remotes must be in the same geographic footprint. They must be able to receive theirown transmit signals. This precludes the use of the majority of spot beam and hemi-beam

transponders for mesh networks.

Verification that all ODU hardware requirements are met: externally referenced PLL LNBs forPrivate Hubs; PLL LNB for all remotes; and BUC and antenna sizing for a given data rate.

Calibration of each outbound and inbound channel to determine clear sky C/N values.

Re-commissioning of each remote. This applies to initial transmit power only, and can be

achieved remotely.

Migration Tasks

To migrate from a star to a mesh network, perform the following:

Reconfigure the M1D1 Tx Line Card. In iBuilder, a check box to indicate that the card isenabled for mesh automatically generates the required configuration for the outbound

loopback carrier. The outbound channel clear sky and UPC margin information must be also

entered in iBuilder.

Calibrate the inbound carrier on an M1D1 or M0D1. This is performed at the same time ascommissioning the first remote in a mesh inroute group. See the iBuilder User Guidefor more

information. Subsequent mesh inbound channels can be calibrated and added to the network

without affecting existing outbound or inbound channels.

Re-commission the initial Tx power setting and record the outbound and inbound clear sky

C/N conditions. Selection of mesh in iBuilder automatically configures the seconddemodulator for the inbound channel. Incorrect commissioning of a remote may prevent the

remote from acquiring into the network.



52/158


CONFIGURINGANDMONITORINGMESHNETWORKS

This section describes the functionality of the iDirect NMS to build and monitor mesh networks.

Complete details are contained in the iBuilder User Guideand theiMonitor User Guide.

Building Mesh Networks

As with star networks, iBuilder provides all the tools necessary to create and configure mesh

networks. All mesh restrictions, such as remote and line card model types, carrier types, etc.,

are checked automatically by the software. For detailed information on building mesh networks,

including special considerations for link budgets and commissioning, see the iBuilder User

Guide.

Special Mesh Constants

One significant difference between star/mesh and pure star networks is that, in a mesh

network, the line card and all remotes must listen to their own loopback satellite transmissions.

During the commissioning process for mesh line cards and remotes, the ideal clear-sky values (in

dB) for these loopback signals should be calculated and recorded in iBuilder. The over-the-air

values (i.e. non-loopback) for the same signals must also be calculated and recorded in iBuilder.

The following clear-sky loopback values should be recorded during star/mesh configuration:

TABLE 1. Mesh-Related Constants

Name Meaning Where Recorded

SCPC Loopback Clear-Sky C/N Ideal clear-sky SCPC signal

quality in C/N as perceived by

the transmit line card.

The Transmit line card for the

mesh network

Hub UPC Margin Transmit power range of the

external uplink powerequipment at the hub

The Transmit line card for the

mesh network

TDMA Clear-Sky C/N Calibrated clear-sky TDMA

signal quality as perceived by

the line card. You must

commission the first mesh

remote to get this value.

Uplink Control parameters tab

on the mesh inroute group

dialog



53/158


Turning Mesh On and Off in iBuilder

For operational flexibility, iBuilder allows you to toggle the mesh transmit capability at various

levels of granularity in your network: line card, inroute group, and network. When you turn

mesh off for a specific remote, it affects only that remote; other mesh remotes in the same

inroute group continue to operate as mesh. However, when you turn mesh off at the Tx line card

or inroute group level, all mesh traffic stops for that inroute group, regardless of the settings for

each remote in the group. Frequency requirements still apply.

Changes to Acquisition/Uplink Control in iBuilder

The addition of mesh topology to the iDS system required some changes to the Acquisition/

Uplink Control dialog in iBuilder. Specifically:

Acquisition/Uplink Control parameter are specified for each inroute in a network.The tabfor entering these values has moved from the Network dialog box to the Inroute Group dialog

box. You must now specify Acq/UCP parameters for each inroute in a network.

The power adjust range is relative, not absolute.Prior to iDS Release 7.0, you specifiedabsolute fine and coarse adjust ranges based on a fixed nominal C/N value. Beginning with

SCPC Clear-Sky C/N Calibrated clear-sky SCPC

signal quality in C/N as

perceived by each remote.

Each mesh remote in the mesh

network

TDMA Loopback Clear-Sky C/N Calibrated clear-sky TDMA

signal quality in C/N as

perceived by each remote

Each mesh remote in the mesh

network

Name Meaning Where Recorded


l 7 0 if th fi d i l l i t fi ld d th fi /


54/158


release 7.0, you specify the fixed nominal value in a separate field, and the fine/coarse

range values are specified relative to this nominal value. (See Figure 19.)

Figure 19. Specifying UPC Parameters

Common Remote Parameters for Mesh Inroute Groups

The following features must be turned on or off for all mesh remotes in an inroute group:

UDP Header Compression

cRTP



55/158


UDP Payload Compression

iBuilder allows you to configure these features at the inroute group level of a mesh-enabled

inroute group, as shown here.

Figure 20. Common Remote Parameters for Mesh

The Meshoptions in Figure 20are only available at the inroute group level if the Enabled checkbox is selected. If Mesh is enabled, the values set at the inroute group level apply to all remotes

in the inroute group, possibly overriding the individual remote settings. If Meshis disabled, theindividual remote settings are honored.

MONITORINGMESHNETWORKSiMonitor provides monitoring tools and reports for mesh overlay networks. A number of mesh-

related parameters have been added to existing messages, and some new displays provide

detailed real-time and historical mesh information.

Additional Hub Statistics Information

The hub statistics message now contains the following information for mesh channels:

SCPC SNR cal: The SCPC carrier-to-noise ratio as perceived by the SCPC loopback channel onthe mesh line card.

SCPC symbol offset: The offset between the nominal and actual frame position on the SCPCloopback channel on the mesh line card.


SCPC frequency offset: The offset between the nominal and actual frequency as perceived


56/158


SCPC frequency offset: The offset between the nominal and actual frequency as perceivedby the SCPC loopback channel on the mesh line card.

SCPC frame lock status: The current lock status of the transmit line cards SCPC loopbackchannel.

SCPC lostlock count: The number of times the mesh line card lost lock on the SCPC loopbackchannel since the last statistics message.

Additional Remote Status Information

The remote status message, sent to the NMS from each in-network remote every 20 seconds,

now contains the following additional information for mesh-enabled remotes:

SCPC C/N: the carrier-to-noise ratio of the downstream SCPC channel as perceived at theremote site.

TDMA Loopback C/N: the carrier-to-noise ratio of the remotes TDMA carrier as perceived atthe remote site through loopback.

TDMA Symbol Offset: the offset between the TDMA transmission symbol timing and the TDMAreceived symbol timing. This information is for debug purposes only; the actual UCP symbol

adjustments are still calculated at the hub and transmitted through UCP messages.

TDMA Frequency Offset: The offset between expected frequency and actual frequencyperceived by the mesh remotes TDMA receiver. This information is for debug purposes only;

the actual UCP frequency adjustments are still calculated at the hub and transmitted through

UCP messages.

Rx and Tx Reliable: the count of reliable bytes sent to (Rx) and from (Tx) this remote on themesh channel. Reliable traffic is typically TCP.

Rx and Tx Unreliable: the count of unreliable bytes sent to (Rx) and from (Tx) this remote onthe mesh channel. Unreliable traffic is typically UDP voice or other real-time traffic

Rx and Tx OOB: the count of control and overhead traffic bytes (link layer, etc.) send to (Rx)and from (Tx) this remote on the mesh channel.

Not e: T hese addit ional f ields are sent in t he remote stat us message only f or mesh-enabled

remot es. Non-mesh remot es do not incur t he addit ional overhead for t hisin for mat i on, and archived informat ion f or non-mesh remotes isn t meaningfu l .

Mesh Traffic Statistics

The NMS collects mesh traffic to and from remotes, saves it in the data archive, and provides it

to iMonitor for real-time and/or historical display. To display mesh statistics, select the Mesh


T ffi G h ti f th t k i t i di id l t l l A ith th IP


57/158


Traffic Graph option from the network, inroute group, or individual remote level. As with the IP

and SAT traffic graphs, data for multiple remotes is aggregated into a single value when youselect more than one remote.

The data types collected per-remote are the same for mesh as for the SAT graph: unreliable

bytes sent/received, reliable bytes sent/received, overhead bytes sent/received.

When viewing statistics for mesh-enabled remotes, its important to keep the following facts in

mind:

Remote-to-remote traffic traverses the satellite on the TDMA inroute.

When viewing the SAT traffic graph, the upstream graph includes any remote-to-remote meshtraffic.

When viewing the mesh traffic graph, the displays for sent and received do not include non-mesh traffic. That is, traffic from the remote(s) destined for an upstream host is not included

on the display.

Mesh traffic will never show up on the IP statistics display, since this display represents

traffic upstream from the protocol processor.

Consider Table 2 on page 41. Assume that Remote 1 and Remote 2 are passing 150 kbps of traffic

between each other. At the same time, Remote 1 is also sending 150 kbps of traffic to the

Internet. The Mesh, SAT, and IP traffic graphs will show the following statistics for these two

remotes:

The IP traffic graph will show 150 kbps on the upstream for Remote 1.

The SAT traffic graph will show 450 kbps on the upstream for Remotes 1 and 2, 300 kbps forthe mesh traffic and 150 kbps for the Internet-bound traffic.

The mesh traffic graph will show 300 kbps received and 300 kbps transmitted for Remotes 1and 2, as shown in the table below.

TABLE 2. Mesh IP Statistics Example

Not e: In t he example above, t he tot al t hroughput on the channel is not 600 kbps. Each byt e

in mesh is actual l y count ed t wi ce: once by t he sender and once by t he receiver.

Tx kbps Rx kbps Total kbps

Remote 1 150 150 300Remote 2 150 150 300

Total 300 300


You may use the mesh IP statistics to determine if there is mesh traffic loss on the link. In order


58/158


y

to do this, you must select allmesh remotes for the display. When you do this, the transmitted

kbps and received kbps should be identical. If theyre not, it is likely there is packet loss acrossthe mesh link.

Figure 21. Mesh, SAT, IP statistics collection

Remote-to-Remote Mesh Probe

The Probe Mesh pane is available from the individual mesh remote in the iMonitor network tree

view. It allows you to examine statistics on mesh communications between pairs of mesh

remotes.

Protocol

Processor

Upstream Router

To

Internet

SAT Traffic Stats Collected HereIP Traffic Stats Collected Here

TunnelLanSe

gment

UpstreamL

anS

egment

Remote 1

Remote 2

Remote 3

Mesh Traffic Stats Collected Here


Specifically Probe Mesh allows you select a pair of remotes and observe the following data for


59/158


Specifically, Probe Mesh allows you select a pair of remotes and observe the following data for

each: The number of attempts to transmit to the peer remote

The number of bursts successfully transmitted to the peer remote

The number of bursts received from the peer remote

The number of bursts received from the peer remote that were dropped

To display the Probe Mesh pane:

Right-click on a mesh remote and click Probe Mesh to display the Select Mesh Remotes Pairdialog box.

Select the peer remote from the Remote Two list and click OK. The Probe Mesh pane isdisplayed showing the information described above.

Not e: Probe Mesh is pr imar i l y i nt ended f or debugging. When Pr obe Mesh is enabled, t he

remot es send debug inf ormat ion t o iMonit or. This increases t he processing on t he

remot es and uses upst ream bandwi dt h t hat could ot herwi se be used to send t ra ff ic.

Long-Term Bandwidth Usage Report for Mesh

iMonitor provides a version of the Long-Term Bandwidth Usage Report specifically for mesh

remotes, allowing fast and flexible bandwidth utilization analysis. A percent-of-max-capacity

figure is also calculated, which you can use to quantify unused bandwidth margin on both the

upstream and downstream channels.

At each le

technical reference guide 8

Documents