Idirect MeshUserGuide Jan 18 2007
Idirect MeshUserGuide Jan 18 2007
iNFINITI Mesh
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.
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
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.
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
iDirect User Guide for iNFINITI Mesh
iDirect Proprietary and Confidential
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.
Mesh Mesh
Out In
Hub
Mesh Remote
Group
Mesh Outbound
Mesh Inbound
All mesh networks consist of a single broadcast outbound channel and one, or more, mesh
TDMA inbound channels.
1. The hub must be able listen to its mesh outbound channel echo return. This signal provides
the following capabilities:
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.
• 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.
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.
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).
Star Inbound
Mesh Outbound
Mesh Inbound
Star
Star Outbound Mesh Mesh
Return Out Return
Hub
Star Remote
Group Mesh Remote
Group
Mesh Mesh
Out In
Private
Hub
Mesh Remote
Group
Mesh Outbound
Mesh Inbound
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.
512 kbps
Star
Outbound 64 kbps
Mesh
out Star
in Mesh
in
Hub
Star Inbound
Mesh Outbound
256 Kbps
Mesh In
Mesh
Out
Hub
Mesh Outbound
5 Frequency Hopping
Mesh Inbound 1
Mesh Inbound 2
Hub
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
Figure 7: Frequency Hopping with Mesh – View 2: Communicating between Inroutes within the
Inroute Group
Star
Outbound
Star Mesh
Mesh
in in
out
Hub
Star Outbound
Star Inbound
Mesh Remote
Group
Mesh Outbound
Mesh Inbound
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.
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.
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.
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.
The iDirect mesh terminal consists of the following components that are all integrated into a
single indoor unit (IDU):
Where possible, iBuilder enforces many of the hardware requirements during network
configuration.
8 Network Considerations
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
• 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.
• 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.
• 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.
iDirect User Guide for iNFINITI Mesh
iDirect Proprietary and Confidential
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.
TDMA Burst
EPEBW from
Remote EIRP (BC)
Noise Floor
SCPC
@ Satellite
C/N @
RX @
Power (dB)
Satellite
Satellite
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)
Noise Floor @
Remote RX
Frequency (Hz)
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.
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.
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.
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.
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.
For detailed information on building mesh networks, including special considerations for link
budgets and commissioning, see the iBuilder User Guide, version 7.0.
The following clear-sky loopback values should be recorded during star/mesh configuration:
• 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.
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.
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.
• 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.
iDirect User Guide for iNFINITI Mesh
iDirect Proprietary and Confidential
28
• SCPC lostlock count – The number of times the mesh line card lost lock on the SCPC
loopback channel since the last statistics message.
• 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.
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:
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.
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.
Specifically, Probe Mesh allows you select a pair of remotes and observe the following data for
each:
• Right-click on a mesh remote and click Probe Mesh to display the Select Mesh Remotes
Pair dialog box.
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:
For further details on report parameters, see the iMonitor User Guide, version 7.0.
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.