idirect meshuserguide jan 18 2007

CORPORATE HEADQUARTERS 13865 SUNRISE VALLEY DRIVE HERNDON, VA 20171 +1 703.648.8000 www.idirect.net

iiDDiirreecctt UUsseerr GGuuiiddee ffoorr

iiiNNNFFFIIINNNIIITTTIII MMMeeessshhh

January 18, 2007

iDirect User Guide for iNFINITI Mesh

iDirect Proprietary and Confidential

2

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.



3

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



4

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



5

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.

Note This document relates to Mesh features and functionality delivered in 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



6

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.

Note

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

Mesh In

Mesh Remote Group

Mesh Outbound

Mesh Inbound

Hub

Figure 1: Basic Mesh Topology



7

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.

Note The outbound echo is demodulated on the same line card (M1D1 only) that is used for modulating the outbound channel. This line card 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.



8

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

Note

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



9

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



10

Hub

Star OutboundStar

Return Mesh Out

Mesh Return

Mesh Remote Group

Star Remote Group

Star Outbound

Star Inbound

Mesh Outbound

Mesh Inbound

Figure 2: Segregated Mesh and Star network

Private Hub

Mesh Out

Mesh In

Mesh Remote Group

Mesh Outbound

Mesh Inbound

Figure 3: Mesh Private Hub



11

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.



12

Hub

Star Outbound

Star in Mesh

in

5Mbps

512 kbps

64 kbps Mesh out

Mesh Remote Group

Star Inbound

Mesh Outbound

Mesh Inbound

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



13

Hub

Mesh Out

Mesh In

1 Mbps

256 Kbps

Mesh RemoteGroup

Mesh Outbound

Mesh Inbound

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



14

Mesh Out

Mesh In 1

Mesh Inbound 1

Hub

Mesh In 2

Mesh Inbound 2

Mesh Outbound

Mesh Inbound 1

Mesh Inbound 2

Figure 6: Frequency Hopping with Mesh - View 1: Inroute Group with 2 Inroutes

Figure 7: Frequency Hopping with Mesh – View 2: Communicating between Inroutes within the Inroute Group

Mesh Out Mesh In

1

Mesh Inbound 1

Hub Hub

Mesh In 2

Mesh Inbound 2

Mesh Inbound 1

Mesh Inbound 2



15

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

Hub

Star Outbound

Mesh out

Star in

Mesh in

Mesh Remote Group

Star Outbound

Star Inbound

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.



16

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.

Note

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



17

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.



18

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



19

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.



20

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



21

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.



22

UPC strives to keep each remote operating at the at EIRP(BC) at the satellite

Pow

er (d

B)

Frequency (Hz)

TDMA Burst from

Remote

Noise Floor @ Satellite

RX

SCPCC/N @ Satellite

Noise Floor @ Hub or Remote RX

EPEBW

@Satellite

Pow

er (d

B)

Frequency (Hz)

TDMA Burst from

Remote

SCPC Loopback

C/N @ Hub

Noise Floor @ Hub RX

SCPC LBClear Sky

C/N

@Hub

Pow

er (d

B)

Frequency (Hz)

TDMA Burst from

Remote

SCPC C/N @ Remote

Noise Floor @ Remote RX

SCPCClear Sky

C/N

@Remote

TDMAClear Sky

C/N

EIRP (BC)

TDMA LBClear Sky

C/N

Figure 10: Uplink Power Control



23

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.



24

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.

Note In order for a mesh network to operate optimally and to prevent overdriving of the satellite, commissioning must be performed in clear sky conditions. See the iDirect Remote Installation and Commissioning Guide for details on how this is performed.



25

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.



26

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

SCPC Loopback Clear-Sky C/N

Ideal clear-sky SCPC signal quality in C/N as perceived by the transmit line card.

The Transmit line card for the mesh network

Hub UPC Margin Transmit power range of the external uplink power equipment at the hub

The Transmit line card for the mesh network

TDMA Clear-Sky C/N

Calibrated clear-sky TDMA signal quality as perceived by the line card. You must commission the first mesh remote to get this value.

Uplink Control parameters tab on the mesh inroute group dialog

SCPC Clear-Sky C/N Calibrated clear-sky SCPC signal quality in C/N as perceived by each remote.

Each mesh remote in the mesh network

TDMA Loopback Clear-Sky C/N

Calibrated clear-sky TDMA signal quality in C/N as perceived by each remote

Each mesh remote in the mesh network

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.



27

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



28

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.



29

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

NOTE

These additional fields are sent in the remote status message only for mesh-enabled remotes. Non-mesh remotes do not 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.



30

• 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

NOTE

In the example above, the total throughput on the channel is 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.



31

To In

tern

et

Tunn

el L

an S

egm

ent

Ups

tream

Lan

Seg

men

t

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.



32

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

NOTE

Probe Mesh is primarily intended for debugging. When Probe Mesh is enabled, the remotes send debug information to 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

Line Card Support M1D1 (required for mesh outroute and supports inroute) (Part No: 9131-0028-0101)

7.0

Line Card Support M0D1 (supports mesh inroute) (Part No: 9131-0102-0102)

7.0

Private Hub Support Private Hub (Mesh) (Part No: 9131-0101-0005)

7.0

5000 Series iNFINITI 5300 (Part No: 9131-0102-0008) 5350 (Part No: 9131-0102-0010)

7.0

7000 Series iNFINITI 7350 (Part No: 9131-0101-0002) 7.0

iConnex iConnex 200 (Part No: 9131-0102-0201) 7.0



33

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

Inbound TCP Accelerated Data Path

Remote-Hub-Remote (IDS Release 7.0) Remote-Remote (future IDS release)

7.0 and future

Single Mesh Inroute per Inroute Group Yes 7.0

Multiple Mesh Inroutes per Inroute Group Yes future

Multiple Mesh and Star Inroutes per Inroute Group Yes future

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.

idirect meshuserguide jan 18 2007

Documents