Idirect MeshUserGuide Jan 18 2007

iDirect User Guide for
iNFINITI Mesh
January 18, 2007
CORPORATE HEADQUARTERS 13865 SUNRISE VALLEY DRIVE HERNDON, VA 20171 +1 703.648.8000 www.idirect.net
Copyright © 2007, iDirect, Inc. All rights reserved. This document may not be reproduced, in
part or in whole, without the permission of iDirect, Inc.
The specifications and information regarding the products in this document are subject to
change without notice. All statements, information, and recommendations in this manual are
believed to be accurate, but are presented without warranty of any kind, express, or implied.
Users must take full responsibility for their application of any products.
iDirect Technologies, iDirect iNFINITI series, iDirect 3000 series, iDirect 5000 series, iDirect
7000 series, iDirect 10000 series, and iDirect 15000 series are registered trademarks or
trademarks of iDirect, Inc. in the United States and/or other countries.
Trademarks, brand names and products mentioned in this manual are the property of their
respective owners. All such references are used strictly in an editorial fashion with no intent to
convey any affiliation with the name or the product’s rightful owner.
iDirect User Guide for iNFINITI Mesh

iDirect Proprietary and Confidential
2
Contents
1 Introduction ...................................................................................................................5
2 Theory of Operation......................................................................................................5
3 Network Architecture....................................................................................................7
Outbound TDM Channel .................................................................................................7
Inbound D-TDMA Channels............................................................................................8
4 Mesh Topology Options ...............................................................................................9
Physical Topology...........................................................................................................9
Network Topology .........................................................................................................11
5 Frequency Hopping ....................................................................................................13
Mesh Frequency Hopping.............................................................................................13
Mesh/Star Frequency Hopping .....................................................................................15
6 Mesh Data Path ...........................................................................................................15
Single and Double-hop Traffic Selection.......................................................................15
Routing .........................................................................................................................16
Real-Time Call Setup....................................................................................................16
7 Hardware Requirements.............................................................................................17
Hub Chassis Hardware .................................................................................................17
Private Hub Hardware ..................................................................................................17
Hub ODU Hardware......................................................................................................17
Remote IDU Hardware .................................................................................................17
Remote ODU Hardware................................................................................................17
8 Network Considerations.............................................................................................18
Link Budget Analysis (LBA) ..........................................................................................18
Mesh Link Budget Outline.............................................................................................18
Uplink Control Protocol (UCP) ......................................................................................19
Bandwidth Considerations ............................................................................................23
9 Mesh Commissioning.................................................................................................24
Star-to-Mesh Network Migration ...................................................................................25
10 Configuring and Monitoring Mesh Networks ...........................................................25
Building Mesh Networks ...............................................................................................26
Special Mesh Constants ...............................................................................................26
Turning Mesh On and Off in iBuilder.............................................................................26
Changes to Acquisition/Uplink Control in iBuilder.........................................................27
Common Remote Parameters for Mesh Inroute Groups ..............................................28
Monitoring Mesh Networks ...........................................................................................28
Additional Hub Statistics Information ............................................................................28
Additional Remote Status Information ..........................................................................29
Mesh Traffic Statistics...................................................................................................29
Remote-to-Remote Mesh Probe ...................................................................................31
Long-Term Bandwidth Usage Report for Mesh ............................................................32
11 Mesh Feature Set and Capability Matrix ...................................................................32
12 Summary .....................................................................................................................33

3
Figures
Figure 1: Basic Mesh Topology ...................................................................................................6

Figure 2: Segregated Mesh and Star network ...........................................................................10
Figure 3: Mesh Private Hub .......................................................................................................10
Figure 4: High Volume Star / Low Volume Mesh Topology .......................................................12
Figure 5: Low Volume Star / High Volume Mesh Network .........................................................13
Figure 6: Frequency Hopping with Mesh - View 1: Inroute Group with 2 Inroutes.....................14
Figure 7: Frequency Hopping with Mesh – View 2: Communicating between Inroutes within the
Inroute Group..............................................................................................................................14
Figure 8: Frequency Hopping with Star and Mesh.....................................................................15
Figure 9: Mesh VSAT Sizing.......................................................................................................19
Figure 10: Uplink Power Control .................................................................................................22
Figure 11: Specifying UPC Parameters in Release 7.0 ..............................................................27
Figure 12: Common Remote Parameters for Mesh ....................................................................28
Figure 13: Mesh, SAT, IP statistics collection.............................................................................31

4
1 Introduction
The iDirect Broadband VSAT network is a complete turn-key solution for broadband IP
connectivity over satellite. The iDirect network combines the industry’s fastest data rates with
the leading satellite access technology to provide the most reliable and bandwidth efficient
solutions to meet voice, video, and data transmission requirements. An iDirect networking
solution can be implemented irrespective of the topology requirements, point-to-point (SCPC),
star or mesh, of an application.
This document describes the operation of a full-mesh network. It details the advantages of
adding a mesh network overlay on top of the current iDirect star network, which allows direct
connectivity between remote terminals with a single trip over the satellite. As with our other
products, iDirect will implement the mesh functionality in a phased manner. The first phase is
delivered in IDS Release 7.0.
This document relates to Mesh features and functionality delivered in

Note
iDS Release 7.0 and future iDS releases.
Although iDirect’s Mesh offering may be considered as a full-mesh solution, it is implemented as

a mesh overlay network on top of the current iDirect star network. The mesh overlay provides
the direct connectivity between remote terminals with a single trip over the satellite, thereby
halving the latency and reducing satellite bandwidth requirements.
Considering that every network is unique, this document provides only general guidelines and
considerations when designing Mesh networks using iDirect equipment. Various physical and
network topologies are presented and how the selection may affect the cost and performance of
the overall network. Network and equipment requirements are specified as well as the
limitations in Phase 1 of iDirect’s Mesh solution. Lastly, an overview of the simplicity of
commissioning an iDirect Mesh network is discussed. Examples for migrating existing star
networks and new Mesh networks are provided.
2 Theory of Operation
In a star network all remote terminals have only direct two-way connectivity with the hub, which
is ideal for applications that terminate into a common point, such as the Internet, public
telephone networks, or corporate data centers. In a mesh network, the remote terminals are
also capable of two-way connectivity directly with other peer remote terminals, as well as to the
hub. When remote-to-remote communications are required, an iDirect mesh network is ideal for
any application that is intolerant of the double-hop delays inherent to star networks.
In an iDirect mesh network, the hub broadcasts to all of the remotes on the typical star TDM
outbound channel. This broadcast sends user traffic and the control and timing information for
5
the entire network of inbound mesh/star channel(s). The remotes then transmit user data on
mesh TDMA inbound channel(s) in which other mesh remotes are configured to receive, as
illustrated in Figure 1: Basic Mesh Topology. The mesh remotes receive and listen to a single
mesh inbound via their second demodulator within the indoor unit (IDU) (iNFINITI 5300 and
7300 series only). The hub will also receive and listen to the mesh inbound channel(s) allowing
remote-hub communications in a similar manner to channels that are implemented for star
connectivity.
iDirect Mesh technology is logically a full-Mesh network topology. All

remotes can communicate directly with each other (and the hub) in a
single-hop jump. The method of network design is achieved with
Note
mesh channel(s) laid over a single star outbound channel. This has
been referred to as a Star/Mesh configuration. When referring to the
iDirect product portfolio, “Star/Mesh” and “Mesh” are synonymous.
Mesh Mesh
Out In
Hub
Mesh Remote
Group
Mesh Outbound
Mesh Inbound
Figure 1: Basic Mesh Topology

6
3 Network Architecture
All mesh networks consist of a single broadcast outbound channel and one, or more, mesh
TDMA inbound channels.
Outbound TDM Channel

The outbound channel for a mesh network is identical to the outbound channel for a star
network, except for the following differences:
1. The hub must be able listen to its mesh outbound channel echo return. This signal provides
the following capabilities:
• a mechanism to determine hub-side rain fade

• a mechanism to measure frequency offset introduced in hub-side equipment
• a mechanism to determine the location of the satellite relative to the hub. The
hub effectively tracks the movement of the satellite. The information is used by
each remote to determine upstream time synchronization.
The outbound echo is demodulated on the same line card (M1D1

only) that is used for modulating the outbound channel. This line card
Note
still possesses the capability of demodulating an inbound channel
(star or mesh).
2. The outbound channel supporting a mesh network carries both the user data and the
Network Monitoring and Control (NMC) information to control the mesh inbound channel(s)
(timing, slot allocation etc.).
The hub is the only node in the mesh network that transmits on the mesh outbound channel.
Data and voice IP packets that need to be sent from the hub to remotes are sent on this shared
broadcast channel. The outbound channel is also used to route network control information
from the centralized Network Management System (NMS) and dynamic bandwidth allocation
changes.
The outbound channel in a mesh network has the following capabilities:
• Bandwidth Management (QoS) – The outbound channel possesses the full suit of QoS
(Quality of Service) functionality the iDirect platform provides including CIR (static and
dynamic), min and max information rates, CBWFQ (Class Based Weighted Fair
Queuing) etc. As functionality as added to the QoS feature set (i.e. Group QoS – IDS
Release 8.0) this will also be realized for all mesh applications.
• Centralized Management – the complete iDirect mesh network can be managed from a
centralized network operations center (NOC) running the advanced iDirect NMS
applications. The hub node in the network provides the ideal connectivity for this
centralized management.

7
• Network Synchronization – the iDirect TDMA inbound channels are able to take
advantage of significant bandwidth efficiency and performance enhancements because
of the tight timing and frequency synchronization that the outbound channel provides.
The centralized hub provides the frequency and timing references for the remote
terminals via the outbound channel, which results in lower equipment costs for the
remote terminals.
Inbound D-TDMA Channels

Each remote terminal must be able listen to its mesh 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 section on routing later in this document if a remote does not hear its’ own bursts). The
same 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
inbound Deterministic Time Division Multiple Access (D-TDMA) channel. This shared access
channel provides data and voice IP connectivity for remote –remote and remotes-hub. Although
the hub will receive and demodulate the mesh inbound it DOES NOT transmit on this
channel(s). The remote terminals are assigned transmit time slots on the channel(s) 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 single or multiple (future iDS
Release) D-TDMA mesh inbound channels for remote-remote and remote-hub
connectivity within an Inroute Group. Each terminal is able to quickly hop between these
frequencies to provide the same efficient bandwidth utilization as a single large TDMA
channel, but without the high power output and large antenna requirements for large
mesh inbound channels.
• Dynamic Allocation – bandwidth is only assigned to remote terminals that need to
transmit data, and is taken away from terminals that are idle. 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 utilized to
transmit the dynamic bandwidth allocation of the mesh inbound carriers.
• Single Hop – data is able to traverse the network directly from a remote terminal to
another remote terminal with a single trip over the satellite. This is critical for
latency-sensitive applications, such as voice and video connections.
Within the mesh topology all iDirect features, such as Application

QoS (classification and prioritization), Voice Jitter handling, IP
Routing, and cRTP are still valid and available. Remote-to-remote
Note Encryption and TCP/HTTP acceleration will be available in future iDS
releases. The system will also respect application and system QoS
rules, such as minimum information rate, committed information rate
and maximum information rate.

8
4 Mesh Topology Options
Physical Topology
Network Operators (NO) can design and implement their mesh network topology as either
Integrated Mesh and Star or Segregated Mesh and Star:
1. Integrated Mesh and Star - on existing hub outbound and infrastructure, where the NO
uses a current outbound channel for the star network for mesh remotes, but adds additional
mesh inbound channel(s). In this example, the existing outbound is utilized for current
remotes in a star network and for newly added remotes in the mesh configuration. The
result is a hybrid network that includes star and mesh sub-networks.
2. Segregated Mesh and Star – Allows the Network Operator (NO) to create a new outbound
channel and inbound channel(s) for a totally segregated mesh network. This can be
achieved on two product platforms:
a. Hub Mesh – with separate outbound carriers(s) and separate inbound carrier(s) on
the iDirect 15000 series™ Satellite Hub (see Figure 2: Segregated Mesh and Star
network).
b. Mesh Private Hub – totally standalone segregated mesh option with a single
outbound carrier and a single inbound carrier only on the iDirect 10000 series™
Private Satellite Hub (see Figure 3: Mesh Private Hub).

9
Star Outbound
Star Inbound
Mesh Outbound
Mesh Inbound
Star
Star Outbound Mesh Mesh
Return Out Return
Hub
Star Remote
Group Mesh Remote
Group
Figure 2: Segregated Mesh and Star network
Mesh Mesh
Out In
Private
Hub
Mesh Remote
Group
Mesh Outbound
Mesh Inbound
Figure 3: Mesh Private Hub

10
Network Topology
iDirect mesh technology is a mixture of a star outbound channel with mesh inbound
channel(s) (logically this is full-mesh) and provides options for the NO to design their
network topology to adequately meet the traffic volume requirements of the client. This
allows flexibility in design when the following conditions arise:
1. High-Volume Star / Low-Volume Mesh – this topology reflects the asymmetric

requirement to operate a network with higher data rate requirements on the star
outbound (i.e. 1+ Mbps) and lower data rate requirements on the mesh inbound
channels (256+ Kbps). This topology accommodates high volume data traffic
traversing between the remotes and a central data repository (i.e. Internet, intranet or
HQ), concurrently with lower data rate mesh inbound channel(s) (64 Kbps) for low
volume data traffic traversing directly between remote peers (i.e. 1 to 4 voice lines).
(see Figure 4: High Volume Star / Low Volume Mesh Topology).
Benefits of High-Volume Star / Low-Volume Mesh are that the NO does not suffer
the cost implications of higher specification BUCs and space segment, in comparison
to a higher grade mesh inbound channel (i.e. 256+ Kbps) that would not be fully
utilized.

11
5Mbps
512 kbps
Star
Outbound 64 kbps
Mesh
out Star
in Mesh
in
Hub
Star Inbound
Mesh Outbound
Mesh Inbound Mesh Remote

Group
Figure 4: High Volume Star / Low Volume Mesh Topology
2. Low-Volume Star / High-Volume Mesh – this topology reflects the reverse

asymmetric requirement to High-Volume Star / Low-Volume Mesh. For example, a
network with lower data rate star outbound channel (i.e. 64+ Kbps) in comparison to
a higher data rate mesh inbound channel (s) (256+ Kbps). Thus allowing for higher
levels of volume traffic traversing directly between remote peers. (see Figure 5: Low
Volume Star / High Volume Mesh Network).

12
1 Mbps
256 Kbps
Mesh In
Mesh
Out
Hub
Mesh Outbound
Mesh Inbound Mesh Remote

Group
Figure 5: Low Volume Star / High Volume Mesh Network
5 Frequency Hopping
Mesh Frequency Hopping

In future IDS releases frequency hopping will be available between mesh and star inbound
channels within an inroute group. With an inroute group containing multiple mesh inbound
channels and frequency hopping, a mesh remote will only listen to both the TDM outbound
channel and the configured mesh inbound channel (see Figure 6: Frequency Hopping with
Mesh - View 1). The remote will not listen to multiple mesh inbound channels; the mesh remote
will be configured to receive a single mesh inbound channel, but can transmit on multiple mesh
inbound channels (see Figure 7: Frequency Hopping with Mesh – View 2).

13
Mesh Outbound
Mesh Inbound 1
Mesh Inbound 2
Mesh Mesh In Mesh In

Out 1 2
Hub
Mesh Inbound 1 Mesh Inbound 2
Figure 6: Frequency Hopping with Mesh - View 1: Inroute Group with 2 Inroutes
Mesh Inbound 1
Mesh Inbound 2
Mesh Out
Mesh In Mesh In
1 2
Hub
Mesh Inbound 1 Mesh Inbound 2
Figure 7: Frequency Hopping with Mesh – View 2: Communicating between Inroutes within the
Inroute Group

14
Mesh/Star Frequency Hopping
With future IDS releases frequency hopping will also allow remotes to transmit on both mesh
and star inbound carriers, but the remote can only receive a single mesh inbound channel (see
Figure 8: Frequency Hopping with Star and Mesh).
Star
Outbound
Star Mesh
Mesh
in in
out
Hub
Star Outbound
Star Inbound
Mesh Remote
Group
Mesh Outbound
Mesh Inbound
Figure 8: Frequency Hopping with Star and Mesh
6 Mesh Data Path
Single and Double-hop Traffic Selection

With mesh functionality the data path is dependent on the type of traffic and is therefore
important when designing and sizing the network and its associated outbound and inbound
channels. In IDS Release 7.0, only real-time non-connection-oriented (non-TCP) and un-
accelerated TCP traffic will traverse over a mesh link from remote peer to remote peer. If
remote-to-remote TCP communications is required then TCP Acceleration must be turned off for
the whole Inroute Group. This means all traffic outbound and inbound will be un-accelerated.
If accelerated TCP remote-to-remote connection is desired then this traffic must follow a double-
hop remote-hub-remote (and vice versa) path and TCP Acceleration must be turned on for the
whole Inroute Group and thus for all traffic.

15
In future IDS releases mesh functionality will include the ability (as a configurable option) to
allow TCP traffic to flow directly from one remote peer to another with acceleration and/or
encryption. This functionality will be further tied in with Frequency Hopping.
The design of permitting only non-TCP traffic to traverse directly from

one remote peer to another adds to the QoS functionality within the
iDirect platform. By default, only allowing the traffic that will benefit
Note from a single hop between remote peers, results in less configuration
issues for the Network Operator. Mesh inbound channels can be
scaled appropriately for the traffic (i.e. voice and video) that should
only traverse directly between remotes.
Routing
Prior to the mesh feature all upstream data on a remote was routed over the satellite to the
protocol processor. With the introduction of Mesh, additional routing information is provided to
each remote in the form of a routing table. This table contains routing info for all remotes in the
Mesh inroute group and subnets behind those remotes. The table is periodically updated based
on addition/deletion of new remotes to the mesh inroute group, the addition/deletion of static
routes in the NMS, if RIP is turned on, or on failure conditions of the remote or linecard. The
mesh routing table is periodically multicast to all remotes in the mesh inroute group.
A method of redundancy to increase remote to remote availability is supported. A scenario can

be envisaged where, due to a deep rain fade at a remote site, a remote falls out of the mesh
network (this is determined by a failure to detect his own bursts); however, because the hub has
a large antenna, the remote continues to stay in the star network. When this occurs the mesh
routing table is updated, and all traffic to/from that remote only is routed via the hub. When the
rain fade passes the mesh routing table is updated again, and all un-accelerated traffic takes
the single hop path.
In the event of a failed outbound loopback signal at the hub (TDM_LOCK), the mesh routing
table is updated to reflect that all traffic to/from all remotes is routed via the hub. This occurs
because a remote requires power, frequency and timing information determined from the
outbound loopback to stay in the mesh network. On TDM_LOCK recovery, and once the
remotes start to detect his owns bursts, the table is updated again to reflect the remotes in the
mesh network, subnets behind those remote, static route configuration, etc.
Real-Time Call Setup

Call setup times for real-time applications, such as VoIP voice calls within an iDirect mesh
network, will be identical to that of an iDirect star network with other variables being similar (i.e.
sufficient and available bandwidth, QoS settings etc). This mesh and star similarity also holds
true in situations where a central call-manager is utilized at the hub location to coordinate the
call setup.

16
7 Hardware Requirements
This section describes the hub and remote hardware requirements for mesh networks. Please
refer to section 11 “Mesh Feature Set and Capability Matrix” for a detailed list of iDirect products
and features that support mesh.
Hub Chassis Hardware

For a hub chassis configuration, the outbound carrier must be sourced by an M1D1 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. A
NM2+ ULC does not support Mesh.
Private Hub Hardware

Only iNFINITI Mesh private hubs support Mesh for both the outbound an inbound carriers.
Minihub-15, minihub-30 and NM2+ private hubs do not support Mesh.
Hub ODU Hardware

Where an LNB is used at the hub (hub chassis or private hub) an externally-referenced PLL
downconverter LNB must be used.
Remote IDU Hardware

Only iNFINITI series 53xx, 73xx, and iCONNEX-R 200 support Mesh.
The iDirect mesh terminal consists of the following components 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 – This continuously demodulates the outbound carrier from
the hub and provides the filtered IP packets and network synchronization information.
The outbound receiver connects to the antenna LNB via the L-band receive IFL cable.
The down-converted satellite spectrum from the LNB is also provided to the D-TDMA
receiver.
• TDMA Satellite Transmitter – The TDMA transmitter is responsible for sending data
from the remote terminal to the satellite TDMA channels. All data that is destined for the
Hub or for other remote terminals is sent via this transmitter.
• TDMA Satellite Receiver – The TDMA receiver is responsible for demodulating a
TDMA carrier for providing remote-to-remote mesh connectivity. The receiver will tune to
the channel-+based on control information from the Hub.
Remote ODU Hardware

In addition to the correct sizing of the ODU equipment (remote antenna and remote BUC) to
close the link, a PLL LNB must be used for the downconverter at the remote.

17
Note that compared to star VSAT networks, where the small dish size and low power BUC are
acceptable for many applications, a Mesh network typically requires both larger dishes and
BUC to close the link. See Network Considerations later in the document.
Where possible, iBuilder enforces many of the hardware requirements during network
configuration.
8 Network Considerations
Link Budget Analysis (LBA)

When designing a mesh network attention must be given to ensuring that equipment is correctly
sized such that each site is (at a minimum) capable of “closing” the link. An 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. For the inbound channel, unlike with a star configuration where the operating point is
typically backed off from the EPEBW point, a mesh channel will operate at or near EPEBW.
The link budget analysis provides a per carrier percentage of transponder power or power
equivalent bandwidth (PEB) where the availability of the remote-remote pair is met. For a given
data rate, this PEB is determined by the worst case remote-remote (or possibly remote-hub)
link. Like any other LBA, the determination of BUC size, antenna size, FEC rate and data rate is
an iterative process in order 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 will also be
detected by the remote in the worst case EIRP contour (assuming fade is not greater than the
calculated fade margin). Remote sites in more favorable EIRP contours may operate with
smaller antenna/BUC. An LBA should be performed for each site to determine optimal network
performance and cost.
Mesh Link Budget Outline

This section outlines the general steps for determining a mesh link budget. Figure 9 on page 19
contains a graphical depiction of these steps.
1. Reference Mesh VSAT – using the EIRP and G/T footprints of the satellite of interest and
the region to be covered determine the current or future worst case site. The first link budget
will be this site back to itself. Running through various iterations, determine the combination
of antenna size, HPA size, and FEC that provides the most efficient transponder usage and
practical VSAT sizing for the desired carrier rate. The percentage of transponder power or
power equivalent bandwidth (PEB) required to close this link will be the reference point for
subsequent link budgets.
2. Forward/Downstream Carrier – using the Reference site and its associated antenna size
determined in step 1 ascertain which combination of modulation and FEC provides the most
efficient transponder usage

18
3. Successive Mesh VSATs – the sizing of additional sites is a two step process with the first
link sizing the antenna and the second the HPA.
• Antenna Size – run a link budget using the Reference VSAT as the transmit site and the
new site as the receive site. Using the same carrier parameters as those for the
Reference site, the antenna size is correct when the PEB is less than or equal to the
reference PEB.
• HPA Size – the next link budget is the reverse of the previous with the new site the
transmit site and the Reference site the receive site. Using the same carrier parameters
as those used for the Reference site, this analysis will determine the required HPA size.
Figure 9: Mesh VSAT Sizing
Uplink Control Protocol (UCP)

Changes have been made to the Uplink Control Protocol that is used to maintain optimal
operation (at the physical layer) of a remote in a mesh network. These changes affect
frequency, power and timing.

19
• Frequency - In a star configuration, frequency offsets introduced to the upstream signal
(by frequency down-conversion at remote’s LNB, up-conversion at remote’s BUC,
satellite’s frequency translation, down-conversion at the hub) are all nulled out via Uplink
Control Protocol messages from the hub to each remote every 20 seconds (these can
be viewed in iMonitor for each remote). 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. For mesh, this can averse affects on both the SCPC outbound and TDMA
inbound carriers, resulting in a peer remote demodulator being unable to reliably recover
data from the inbound channel. A PLL LNB offers superior performance, since it is not
subject to the same short term frequency drift.
• Power – A typical iDirect star network consists of a hub with a large antenna, and
multiple remotes with small antennae and small BUCs. In a star network, uplink power
control adjusts each remote’s transmit power on the inbound channel until a nominal
signal strength of ~9dB C/N (for QPSK) is achieved at the hub. Because of the large hub
antenna, the operating point (Tx power) of a remote is typically below the contracted
power (EPEBW) at the satellite, yet, is sufficient to close the link and reliably receive
data. For a mesh network, where remotes typically have smaller antenna than the hub, a
remote would not reliably (possibly not at all) receive data from a peer remote using the
same power. It is therefore important to maximize the use of all available power. Uplink
power control for a mesh network adjusts the remote’s 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. (Note: this may be equal to or less than the contracted power/EPEBW).
Larger antenna and BUCs are required to meet this requirement. The EIRP at beam
center and size of the equipment are calculated based on a link budget analysis.
The uplink power control algorithm uses a combination of the following:
• clear-sky C/N for both the TDMA inbound and SCPC outbound loopback
channels (obtained during hub commissioning)
• the hub UPC margin (how much external hub side equipment can accommodate
hub UPC1)
• the outbound loopback C/N at the hub, and
• each remote’s inbound C/N at the hub, to adjust each remote’s tx power to
achieve the EIRP@BC at the satellite
The inbound UPC algorithm determines hub-side fade, remote-side fade and correlated
fades, by comparing the current outbound and inbound signals strengths against those
obtained during clear sky calibration. For example, if the outbound loopback C/N falls
1
iDirect equipment does not support hub-side UPC. Typical RFT equipment at a teleport installation uses
a beacon receiver to measure downlink fade. An algorithm running in the beacon receiver calculates
equivalent uplink fade and adjusts an attenuator to ensure a constant power (EPEBW) at the satellite for
the outbound carrier. The beacon receiver and attenuator is outside of iDirect’s control. For a hub without
UPC, the margin is set to zero.
20
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 correction power is made to the remote. If
hub-side UPC margin is exceeded, then outbound loopback C/N is affected by both
uplink and downlink fade and a significant difference compared to clear sky would be
observed. Similarly if the inbound C/N drops for a particular remote and the outbound
loopback C/N does not change compared to the clear sky value, UPC increases the
remote’s Tx power until the inbound channel clear sky is attained. Similar C/N
comparisons are made to accommodate correlated fades.

21
UPC strives to keep each remote operating at the
at EIRP(BC) at the satellite
TDMA Burst
EPEBW from
Remote EIRP (BC)
Noise Floor
SCPC
@ Satellite
C/N @
RX @
Power (dB)
Satellite
Satellite
Noise Floor @ Hub

or Remote RX
Frequency (Hz)
SCPC LB
TDMA Burst
Clear Sky TDMA
from
C/N Clear Sky
Remote
C/N
@
Power (dB)
SCPC
Loopback Hub
C/N @ Hub
Noise Floor
@ Hub RX
Frequency (Hz)
SCPC
Clear Sky TDMA Burst
C/N from TDMA LB
Power (dB)
Remote Clear Sky

C/N @
Remote
SCPC C/N
@ Remote
Noise Floor @
Remote RX
Frequency (Hz)
Figure 10: Uplink Power Control

22
Note: in a mesh network, for each remote the inbound C/N at the hub is likely to be
greater than that typically observed in a star network. Also, when a remote is in the
mesh network, the nominal C/N signal strength value for a star network is not used as
the reference.
In the event of an outbound loopback failure (TDM_LOCK), the uplink power control
algorithm reverts to star mode. This redundancy allows remotes in a mesh inroute group
to continue to operate in star only mode.
• Timing – An inbound channel consists of a TDMA frame with an integer number of traffic
slots. On 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 (and hence the hub) at exactly the same time (within a couple of
symbols). 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, i.e. 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 the inbound 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 roundtrip time for hub-
satellite-hub from the outbound channel loopback. This information is relayed
information to each remote, where, an algorithm determines when to expect the start of
the inbound channel, and in turn, determine burst boundaries.
Note: In phase 1, a remote listens to all inbound channel bursts, including burst he
originates. Only those bursts sourced from other remotes and destined for that remote,
and bursts originated by the remote are processed by software. All other traffic is
dropped.
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 applied to all remotes in an inroute group. In a star
network, SAR and VLAN can be configured on a hub-remote pair basis. For a mesh network, all
remotes in the inroute group must have a common SAR configuration – SAR is always enabled
and enforced in the NMS (2 bytes required). The same argument applies to VLAN ID (two bytes
are required). Additional header information (currently 2 bytes) indicating the destination applies
to mesh traffic only. Star traffic is unaffected; however, SAR and VLAN are also always enabled
back 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.

23
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 outbound and inbound channels will vary greatly depending on the short term ratio. It must
be understood that although a linecard can support an inbound channel of 4 Mbps aggregated
across many remotes, a remote-remote connection will not support this rate. A remote does
drop inbound traffic not destined for it, thereby limiting unnecessary processing of bursts.
Sample performance curves will be available from iDirect.
9 Mesh Commissioning
The commissioning of a mesh network is straightforward and requires only a few additional
steps compared to the commissioning of a star network. Note: in a mesh network, where
relatively small antenna (compared to the hub antenna) are used at peer remote sites,
additional attention to link budget analysis (LBA) is required. Each remote requires an LBA to
determine antenna and BUC size for the intended availability and data rate.
Due to the requirement that the mesh inbound channel operates at the contracted power point
on the satellite (typically a star network rarely reaches this point), calibration of both the
outbound loopback and the mesh inbound channels at the hub during 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.
In order for a mesh network to operate optimally and to prevent

overdriving of the satellite, commissioning must be performed in
Note
clear sky conditions. See the iDirect Remote Installation and
Commissioning Guide for details on how this is performed.

24
Star-to-Mesh Network Migration
Prior to migrating an existing star network to a mesh network, the following actions should be
performed:
• Perform a link budget analysis comparison for mesh star versus star network.
• Verify the satellite transponder configuration for hub and each remote. All hubs and
remotes must lay in same the geographic footprint – they must be able to “see”
themselves. This precludes the use of the majority of spot beam and hemi-beam
transponders for Mesh networks.
• Verify ODU hardware requirements are met – externally referenced PLL LNB for private
hub, PLL LNB for all remotes, and BUC and antenna sizing for a given data rate.
• Each outbound and inbound channel must be calibrated to determine clear-sky C/N
values.
• Each remote must be re-commissioned - (applies to initial Tx power only). This can be
achieved without manpower at the remote site.
The migration of an existing star network to a mesh network requires that the M1D1 Tx linecard
be reconfigured. In iBuilder, a check box to indicate that the card is enabled for mesh
automatically generates the required configuration for the outbound loopback (carrier, symbol
rate, FEC, etc). The outbound channel clear sky and UPC margin information must be also
entered in iBuilder.
Calibration of an inbound carrier on an M1D1 or M0D1 is a new step in the commissioning of a

mesh network. This is performed at the same time as commissioning the first remote in a mesh
inroute group. See iBuilder User Guide for details on how this is performed. Note that
subsequent mesh inbound channels can be calibrated and added to the network without
affecting existing outbound or inbound channels.
The migration of star remotes in an in existing star network to a mesh network requires re-
commissioning of the initial Tx power setting and recording of outbound and inbound clear sky
C/N conditions. Selection of mesh in iBuilder automatically configures the second demodulator
for the inbound channel (carrier, symbol rate, FEC, etc). Incorrect commissioning of a remote
may prevent the remote from acquiring into the network. As indicated earlier, the remote C/N at
the hub will typically be higher at the hub in a mesh network. UPC adjusts the transmit power of
all remotes so as to operate at a common C/N range at the hub. A remote with a C/N
significantly higher or lower than this range will not acquire into the network. For a mesh
network, a remote will typically have a higher initial Tx power setting than used for star network.
Note: the same rationale applies when changing a remote from a mesh network to a star
network, i.e. the initial Tx power should be adjusted to accommodate the star requirements.
10 Configuring and Monitoring Mesh Networks
This section describes the functionality of the iDirect NMS to build and monitor mesh networks.
Complete details are contained in the iBuilder User Guide, version 7.0., and the iMonitor User
Guide, version 7.0.

25
Building Mesh Networks
Just like it does for star-topology networks, iBuilder provides all the tools necessary to create
and configure mesh networks. All mesh restrictions with respect to iNFINITI model types, carrier
types, etc. are checked automatically by the software, ensuring simple, error-free configurations.
For detailed information on building mesh networks, including special considerations for link
budgets and commissioning, see the iBuilder User Guide, version 7.0.
Special Mesh Constants

One significant difference between star/mesh and pure star networks is that, with mesh
networks, the line card and all remotes must listen to their own transmissions to the satellite
(referred to the loopback signals). 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:
Name Meaning Where Recorded

Ideal clear-sky SCPC signal quality
SCPC Loopback The Transmit line card
in C/N as perceived by the transmit
Clear-Sky C/N for the mesh network
line card.
Transmit power range of the
The Transmit line card
Hub UPC Margin external uplink power equipment at
for the mesh network
the hub
Calibrated clear-sky TDMA signal Uplink Control
quality as perceived by the line parameters tab on the
TDMA Clear-Sky C/N
card. You must commission the first mesh inroute group
mesh remote to get this value. dialog
Calibrated clear-sky SCPC signal
Each mesh remote in
SCPC Clear-Sky C/N quality in C/N as perceived by each
the mesh network
remote.
Calibrated clear-sky TDMA signal
TDMA Loopback Each mesh remote in
quality in C/N as perceived by each
Clear-Sky C/N the mesh network
remote
Table 1 - New Mesh-Related Constants
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 per-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 in 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.
26
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 group in a

network. The tab for entering these values has moved from the Network dialog to the
inroute group dialog. You must now specify Acq/UCP parameters for each inroute group in a
network.
• The power adjust range is relative, not absolute. Prior to iDS 7.0, you specified absolute
fine and coarse adjust ranges based on a fixed nominal C/N value. In 7.0 and beyond, 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 11: Specifying UPC Parameters in
Release 7.0.
Figure 11: Specifying UPC Parameters in Release 7.0

27
Common Remote Parameters for Mesh Inroute Groups
The following features must be turned on or off for all mesh remotes in an inroute group:
• TCP Acceleration
• UDP Header Compression (NOTE: includes CRTP as well)
• 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 12: Common Remote Parameters for Mesh
TCP and UDP options are 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 Mesh is disabled, the
individual remote settings are honored.
Monitoring Mesh Networks

iMonitor provides complete 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 on the mesh line card.
• SCPC symbol offset – The offset between the nominal and actual frame position on the
SCPC loopback channel on the mesh line card.
• SCPC frequency offset – The offset between the nominal and actual frequency as perceived
by the SCPC loopback channel on the mesh line card.
• SCPC frame lock status – The current lock status of the transmit line card’s SCPC loopback
channel.
28
• SCPC lostlock count – The number of times the mesh line card lost lock on the SCPC
loopback channel 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 the
remote site.
• TDMA Loopback C/N – the carrier-to-noise ratio of the remote’s TDMA carrier as perceived
at the remote site through loopback.
• TDMA Symbol Offset – the offset between the TDMA transmission symbol timing and the
TDMA received 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 frequency
perceived by the mesh remote’s 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
the mesh channel. Reliable traffic is typically TCP.
• Rx and Tx Unreliable – the count of unreliable bytes sent to (Rx) and from (Tx) this remote
on the 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.
These additional fields are sent in the remote status message

only for mesh-enabled remotes. Non-mesh remotes do not
NOTE
incur the additional overhead for this information, and
archived information for non-mesh remotes isn’t meaningful.
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
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 you
select 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 stats for mesh-enabled remotes, it’s 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
mesh traffic.

29
• 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 stats display, since this display represents traffic
upstream from the protocol processor.
Consider the diagram in Figure 13 on page 27. 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
for the 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 1
and 2, as shown in the table below.
Tx kbps Rx kbps Total kbps

Remote 1 150 150 300
Remote 2 150 150 300
Total 300 300
In the example above, the total throughput on the channel is

NOTE not 600 kbps. Each byte in mesh is actually counted twice:
once by the sender and once by the receiver.
You may use the Mesh IP stats to determine if there is mesh traffic loss on the link. In order to
do this, you must select all mesh remotes for the display. When you do this, the transmitted
kbps and received kbps should be identical. If they’re not, it is likely there is packet loss across
the mesh link.

30
To Internet
Upstream Lan Segment
Tunnel Lan Segment
Figure 13: Mesh, SAT, IP statistics collection
Remote-to-Remote Mesh Probe

The Probe Mesh pane is available from the individual mesh remote nodes in the network tree
view. It allows you to examine statistics on mesh communications between pairs of mesh
remotes.
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
Pair dialog box.

31
• Select the peer remote from the Remote Two list and click OK. The Probe Mesh pane is
displayed showing the information described above.
Probe Mesh is primarily intended for debugging. When Probe

Mesh is enabled, the remotes send debug information to
NOTE iMonitor. This increases the processing on the remotes and
uses upstream bandwidth that could otherwise be used to
send traffic.
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 level of the Tree, you can report on all remotes below the element you have selected.
To generate, view, save, or print the Mesh Long-Term Bandwidth Usage report, follow the
directions below:
• Right-click a network, inroute group, or remote.

• Select MESH Long Term Bandwidth Usage. The Long Term Bandwidth Usage Parameters
dialog box appears.
For further details on report parameters, see the iMonitor User Guide, version 7.0.
11 Mesh Feature Set and Capability Matrix
Products Supported iDirect iNFINITI series™ Only iDS Release

M1D1 (required for mesh outroute and
Line Card Support supports inroute) 7.0
(Part No: 9131-0028-0101)
M0D1 (supports mesh inroute)
Line Card Support 7.0
(Part No: 9131-0102-0102)
Private Hub (Mesh)
Private Hub Support 7.0
(Part No: 9131-0101-0005)
5300 (Part No: 9131-0102-0008)
5000 Series iNFINITI 7.0
5350 (Part No: 9131-0102-0010)
7000 Series iNFINITI 7350 (Part No: 9131-0101-0002) 7.0
iConnex 200 (Part No: 9131-0102-

iConnex 7.0
0201)

32
iDS Feature iDS Release
Maximum Mesh Inroute Data Rate Yes, 4.2 Mbps 7.0
NMS Functionality Yes 7.0
RTTM/QoS Yes 7.0
Priority Queuing Yes 7.0
Group QoS Yes 8.0
Turbo Product Codes Yes 7.0
Spot Beam Capability No*
TCP (Non-Acceleration) Yes 7.0
Remote-Hub-Remote (IDS
Release 7.0)
Inbound TCP Accelerated Data Path 7.0 and future
Remote-Remote (future IDS
release)
Single Mesh Inroute per Inroute Group Yes 7.0
Multiple Mesh Inroutes per Inroute
Yes future
Group
Multiple Mesh and Star Inroutes per
Yes future
Inroute Group
Frequency Hopping Yes future
Encryption Yes future
Transec Yes future
Adaptive Coding & Modulation (ACM) Yes future
Table 2: Mesh Feature Set and Capability Matrix
* Cross-strapped capability may be developed in future IDS releases.
12 Summary
iDirect iNFINITI Mesh provides an efficient and cost-effective solution for networks that require
either full mesh topology or a mixture of star and mesh topology. The solution supports varied
network requirements, such as traffic patterns that are majority star topology with minority mesh
topology, or vice versa. With the iDirect solution an organization has the benefits of many
patent-pending features, including the iDirect RTTM feature set, Application QoS, System QoS,
Network QoS, cRTP, TCP and HTTP Acceleration, IP Routing, and built-in AES or 3DES
Encryption.

33

Idirect MeshUserGuide Jan 18 2007

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Idirect MeshUserGuide Jan 18 2007

Diunggah oleh

Hak Cipta:

Format Tersedia

iDirect User Guide for

January 18, 2007

iDirect User Guide for iNFINITI Mesh

iDirect User Guide for iNFINITI Mesh

Figure 1: Basic Mesh Topology ...................................................................................................6

iDirect User Guide for iNFINITI Mesh

This document relates to Mesh features and functionality delivered in

Although iDirect’s Mesh offering may be considered as a full-mesh solution, it is implemented as

iDirect Mesh technology is logically a full-Mesh network topology. All

Figure 1: Basic Mesh Topology

iDirect User Guide for iNFINITI Mesh

Outbound TDM Channel

• a mechanism to determine hub-side rain fade

The outbound echo is demodulated on the same line card (M1D1

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

iDirect User Guide for iNFINITI Mesh

Inbound D-TDMA Channels

Within the mesh topology all iDirect features, such as Application

iDirect User Guide for iNFINITI Mesh

iDirect User Guide for iNFINITI Mesh

Figure 2: Segregated Mesh and Star network

Figure 3: Mesh Private Hub

iDirect User Guide for iNFINITI Mesh

1. High-Volume Star / Low-Volume Mesh – this topology reflects the asymmetric

iDirect User Guide for iNFINITI Mesh

Mesh Inbound Mesh Remote

Figure 4: High Volume Star / Low Volume Mesh Topology

2. Low-Volume Star / High-Volume Mesh – this topology reflects the reverse

iDirect User Guide for iNFINITI Mesh

Mesh Inbound Mesh Remote

Figure 5: Low Volume Star / High Volume Mesh Network

Mesh Frequency Hopping

iDirect User Guide for iNFINITI Mesh

Mesh Mesh In Mesh In

Mesh Inbound 1 Mesh Inbound 2

Mesh Inbound 1 Mesh Inbound 2

iDirect User Guide for iNFINITI Mesh

Figure 8: Frequency Hopping with Star and Mesh

6 Mesh Data Path

Single and Double-hop Traffic Selection

iDirect User Guide for iNFINITI Mesh

The design of permitting only non-TCP traffic to traverse directly from

A method of redundancy to increase remote to remote availability is supported. A scenario can

Real-Time Call Setup

iDirect User Guide for iNFINITI Mesh

Hub Chassis Hardware

Private Hub Hardware

Hub ODU Hardware

Remote IDU Hardware

• Integrated Features – IP Router, TCP Optimization, RTTM feature (Application and

Remote ODU Hardware

iDirect User Guide for iNFINITI Mesh

Link Budget Analysis (LBA)

Mesh Link Budget Outline

iDirect User Guide for iNFINITI Mesh

Figure 9: Mesh VSAT Sizing

Uplink Control Protocol (UCP)

iDirect User Guide for iNFINITI Mesh

The uplink power control algorithm uses a combination of the following:

iDirect User Guide for iNFINITI Mesh

Noise Floor @ Hub

Remote Clear Sky