Technical Reference Guide 8
-
Upload
eugeny-smykov -
Category
Documents
-
view
233 -
download
5
Transcript of Technical Reference Guide 8
-
7/27/2019 Technical Reference Guide 8
1/158
TECHNICALREFERENCEGUIDE
IDS RELEASE8.2
March 07, 2008
-
7/27/2019 Technical Reference Guide 8
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
-
7/27/2019 Technical Reference Guide 8
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://-/?- -
7/27/2019 Technical Reference Guide 8
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
-
7/27/2019 Technical Reference Guide 8
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
-
7/27/2019 Technical Reference Guide 8
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/27/2019 Technical Reference Guide 8
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
-
7/27/2019 Technical Reference Guide 8
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
-
7/27/2019 Technical Reference Guide 8
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
-
7/27/2019 Technical Reference Guide 8
10/158
x Technical Reference Guide iDS Release 8.2
-
7/27/2019 Technical Reference Guide 8
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
-
7/27/2019 Technical Reference Guide 8
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
-
7/27/2019 Technical Reference Guide 8
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
-
7/27/2019 Technical Reference Guide 8
14/158
xiv Technical Reference Guide iDS Release 8.2
-
7/27/2019 Technical Reference Guide 8
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.
-
7/27/2019 Technical Reference Guide 8
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.
-
7/27/2019 Technical Reference Guide 8
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
-
7/27/2019 Technical Reference Guide 8
18/158
iDirect System Overview
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
-
7/27/2019 Technical Reference Guide 8
19/158
iDirect System Overview
Technical Reference Guide iDS Release 8.2 3
Figure 2. iDirect IP Architecture Multiple VLANs per Remote
iDi t S t O i
-
7/27/2019 Technical Reference Guide 8
20/158
iDirect System Overview
4 Technical Reference Guide iDS Release 8.2
Figure 3. iDirect IP Architecture VLAN Spanning Remotes
iDirect System Overview
-
7/27/2019 Technical Reference Guide 8
21/158
iDirect System Overview
Technical Reference Guide iDS Release 8.2 5
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
iDirect System Overview
-
7/27/2019 Technical Reference Guide 8
22/158
iDirect System Overview
6 Technical Reference Guide iDS Release 8.2
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
-
7/27/2019 Technical Reference Guide 8
23/158
Mesh Technical Description
Technical Reference Guide iDS Release 8.2 7
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.
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
24/158
p
8 Technical Reference Guide iDS Release 8.2
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.
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
25/158
p
Technical Reference Guide iDS Release 8.2 9
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
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
26/158
10 Technical Reference Guide iDS Release 8.2
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.
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
27/158
Technical Reference Guide iDS Release 8.2 11
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.
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
28/158
12 Technical Reference Guide iDS Release 8.2
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.
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
29/158
Technical Reference Guide iDS Release 8.2 13
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
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
30/158
14 Technical Reference Guide iDS Release 8.2
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.
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
31/158
Technical Reference Guide iDS Release 8.2 15
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).
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
32/158
16 Technical Reference Guide iDS Release 8.2
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
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
33/158
Technical Reference Guide iDS Release 8.2 17
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
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
34/158
18 Technical Reference Guide iDS Release 8.2
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.
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
35/158
Technical Reference Guide iDS Release 8.2 19
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
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
36/158
20 Technical Reference Guide iDS Release 8.2
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
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
37/158
Technical Reference Guide iDS Release 8.2 21
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
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
38/158
22 Technical Reference Guide iDS Release 8.2
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.
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
39/158
Technical Reference Guide iDS Release 8.2 23
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
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
40/158
24 Technical Reference Guide iDS Release 8.2
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.
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
41/158
Technical Reference Guide iDS Release 8.2 25
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.
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
42/158
26 Technical Reference Guide iDS Release 8.2
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.
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
43/158
Technical Reference Guide iDS Release 8.2 27
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 .
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
44/158
28 Technical Reference Guide iDS Release 8.2
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
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
45/158
Technical Reference Guide iDS Release 8.2 29
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.
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
46/158
30 Technical Reference Guide iDS Release 8.2
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.
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
47/158
Technical Reference Guide iDS Release 8.2 31
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.
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
48/158
32 Technical Reference Guide iDS Release 8.2
Figure 18. Uplink Power Control
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
49/158
Technical Reference Guide iDS Release 8.2 33
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
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
50/158
34 Technical Reference Guide iDS Release 8.2
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.
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
51/158
Technical Reference Guide iDS Release 8.2 35
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.
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
52/158
36 Technical Reference Guide iDS Release 8.2
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
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
53/158
Technical Reference Guide iDS Release 8.2 37
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
Mesh Technical Description
l 7 0 if th fi d i l l i t fi ld d th fi /
-
7/27/2019 Technical Reference Guide 8
54/158
38 Technical Reference Guide iDS Release 8.2
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
Mesh Technical Description
-
7/27/2019 Technical Reference Guide 8
55/158
Technical Reference Guide iDS Release 8.2 39
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.
Mesh Technical Description
SCPC frequency offset: The offset between the nominal and actual frequency as perceived
-
7/27/2019 Technical Reference Guide 8
56/158
40 Technical Reference Guide iDS Release 8.2
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
Mesh Technical Description
T ffi G h ti f th t k i t i di id l t l l A ith th IP
-
7/27/2019 Technical Reference Guide 8
57/158
Technical Reference Guide iDS Release 8.2 41
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
Mesh Technical Description
You may use the mesh IP statistics to determine if there is mesh traffic loss on the link. In order
-
7/27/2019 Technical Reference Guide 8
58/158
42 Technical Reference Guide iDS Release 8.2
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
Mesh Technical Description
Specifically Probe Mesh allows you select a pair of remotes and observe the following data for
-
7/27/2019 Technical Reference Guide 8
59/158
Technical Reference Guide iDS Release 8.2 43
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