FunctionalDescription v1.0

Functional Description
Newtec Dialog®
R2.4.1
Revision 1.0
March 22, 2021
© 2021 ST Engineering iDirect (Europe) CY NV and/or its affiliates. All rights reserved.
Reproduction in whole or in part without permission is prohibited. Information contained herein is
subject to change without notice. The specifications and information regarding the products in this
document are subject to change without notice. While every effort has been made to ensure the
accuracy of the statements, information and recommendations in this document, they are provided
without warranty of any kind, express, or implied. Users must take full responsibility for their
application of any products. Trademarks, brand names and products mentioned in this document 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.
ST Engineering iDirect is a global leader in satellite communications (satcom) providing technology

and solutions that enable its customers to expand their business, differentiate their services and
optimize their satcom networks. Through the merger with Newtec, a recognized industry pioneer, the
combined business unites over 35 years of innovation focused on solving satellite’s most critical
economic and technology challenges, and expands a shared commitment to shaping the future of
how the world connects. The product portfolio, branded under the names iDirect and Newtec,
represents the highest standards in performance, efficiency and reliability, making it possible for its
customers to deliver the best satcom connectivity experience anywhere in the world. ST
Engineering iDirect is the world’s largest TDMA enterprise VSAT manufacturer and is the leader in
key industries including broadcast, mobility and military/government.
Company Website: www.idirect.net | Main Phone: +32 3 780 6500

Support Contact Information: Email: customersupport@idirect.net | Website:
www.idirect.net/support-and-training
Table of Contents
Table of Contents
1 About This Guide ............................................................................................ 1

1.1 Revision History ...................................................................................................................................... 1
1.2 Cautions and Symbols ............................................................................................................................ 1
2 What is Newtec Dialog® ................................................................................. 2
3 Forward Link ................................................................................................... 7

3.1 Forward Link Definition ........................................................................................................................... 7
3.2 DVB-S2(X) Key Concepts ....................................................................................................................... 8
3.2.1 Encapsulation ................................................................................................................................... 8
3.2.2 Baseband Frames ............................................................................................................................. 9
3.2.3 Modulation ...................................................................................................................................... 10
3.2.4 Forward Error Correction ................................................................................................................. 13
3.2.5 MODCOD ....................................................................................................................................... 13
3.2.6 Pilots ............................................................................................................................................... 18
3.3 DVB-S2X Annex M ............................................................................................................................... 18
3.3.1 Wideband and Time Slicing ............................................................................................................ 18
3.3.2 Maximum Symbol Rates ................................................................................................................. 19
3.4 Forward Link End-to-End ...................................................................................................................... 22
4 Return Link .................................................................................................... 24

4.1 Return Link Definition ............................................................................................................................ 24
4.2 MF-TDMA 4CPM .................................................................................................................................. 26
4.2.1 Definition ......................................................................................................................................... 26
4.2.2 Coding and Modulation ................................................................................................................... 26
4.2.3 Access Layer ................................................................................................................................... 27
4.2.4 Return Capacity Groups and Carrier Pools ..................................................................................... 30
4.2.5 Burst Demodulator .......................................................................................................................... 31
4.2.6 4CPM Return Link End-to-End ........................................................................................................ 34
4.3 SCPC DVB-S2 and S2 Extensions ....................................................................................................... 35
4.3.1 Definition ......................................................................................................................................... 35
4.3.2 Access Layer ................................................................................................................................... 35
4.3.3 DVB-S2 Return Link End-to-End ..................................................................................................... 36
4.4 Mx-DMA HRC ....................................................................................................................................... 38
4.4.1 HRC SCPC ..................................................................................................................................... 39
4.4.2 HRC Mx-DMA ................................................................................................................................. 40
Functional Description v1.0 3/176

Newtec Dialog R2.4.1
Table of Contents
4.4.3 Encapsulation and Coding .............................................................................................................. 43

4.4.4 MODCOD ....................................................................................................................................... 44
4.4.5 HRC Return Link End-to-End .......................................................................................................... 48
4.5 NxtGen Mx-DMA MRC .......................................................................................................................... 49
4.5.1 MRC Return Link End-to-End ......................................................................................................... 50
4.5.2 Encapsulation and Coding .............................................................................................................. 51
4.5.3 Channel Access .............................................................................................................................. 52
4.5.4 Performance ................................................................................................................................... 53
5 Quality Of Service ......................................................................................... 56

5.1 Marking ................................................................................................................................................. 57
5.2 Mapping ................................................................................................................................................ 58
5.3 Queuing ................................................................................................................................................ 59
5.4 Shaping ................................................................................................................................................. 60
5.4.1 Transport-based Shaping ............................................................................................................... 63
5.4.2 Class-based Shaping ..................................................................................................................... 64
6 Satellite Link Optimization ........................................................................... 68

6.1 Equalink® ............................................................................................................................................. 68
6.2 Clean Channel Technology® ................................................................................................................ 70
6.3 Adaptive Coding Modulation ................................................................................................................. 71
6.3.1 ACM in the Forward ........................................................................................................................ 72
6.3.2 ACM in the Return ........................................................................................................................... 75
6.4 Adaptive Return Link ............................................................................................................................. 77
6.5 Automated Uplink Power Control .......................................................................................................... 78
7 Data Path Optimization ................................................................................. 80

7.1 Header Compression ............................................................................................................................ 82
7.2 TCP Payload Compression ................................................................................................................... 85
7.3 TCP Acceleration .................................................................................................................................. 86
7.4 GTP Acceleration .................................................................................................................................. 89
7.5 Flow Fairness ........................................................................................................................................ 91
7.6 Packet Aggregation ............................................................................................................................... 93
7.7 Cross Layer Optimization ..................................................................................................................... 94
8 Time and Frequency Synchronization ........................................................ 97
9 Terminals ..................................................................................................... 103

9.1 Terminal Description ........................................................................................................................... 103
9.2 Modem Types ..................................................................................................................................... 103

Table of Contents
9.2.1 Specifications ................................................................................................................................ 104

9.2.2 Markets ......................................................................................................................................... 106
9.3 Outdoor Units ...................................................................................................................................... 107
9.4 Terminal Provisioning ......................................................................................................................... 109
9.5 Whitelisted Terminals .......................................................................................................................... 110
9.6 Terminal Installation and Initialization ................................................................................................. 110
9.6.1 Step 1: Terminal Installation ......................................................................................................... 112
9.6.2 Step 2: Satellite Network Lookup .................................................................................................. 117
9.6.3 Step 3: Forward Link Synchronization .......................................................................................... 118
9.6.4 Synchronized State ....................................................................................................................... 118
9.6.5 Step 4: Return Link Synchronization ............................................................................................. 118
9.6.5.1 4CPM Logon Procedure ............................................................................................................ 119
9.6.5.2 DVB-S2 Logon Procedure ......................................................................................................... 119
9.6.5.3 HRC Logon Procedure .............................................................................................................. 121
9.6.5.3.1 SCPC: Static Frequency Plan Mode .................................................................................... 121
9.6.5.3.2 Mx-DMA ............................................................................................................................... 121
9.6.5.3.2.1 Single Carrier Logon ..................................................................................................... 121
9.6.5.3.2.2 Logon Bandwidth .......................................................................................................... 122
9.6.5.3.2.3 Ulogon ........................................................................................................................... 124
9.6.5.3.2.4 Mx-DMA Terminal Logon Priority .................................................................................. 126
9.6.5.4 MRC Logon Procedure .............................................................................................................. 126
9.6.6 Step 5: Network Logon ................................................................................................................. 127
9.7 Return Technology Switching ............................................................................................................. 129
9.8 Terminal Usage ................................................................................................................................... 129
9.8.1 Terminology .................................................................................................................................. 129
9.8.1.1 Fixed or Mobile Terminal ........................................................................................................... 129
9.8.1.2 Single Beam or Multi-beam Operation ....................................................................................... 129
9.8.1.3 Attachment Type ....................................................................................................................... 130
9.8.2 Use Cases ..................................................................................................................................... 130
9.8.2.1 Fixed or COTP Terminal Operating in Single Beam ................................................................... 130
9.8.2.2 COTM Terminal Operating in Single Beam ................................................................................ 131
9.8.2.3 Fixed Terminal Operating in Unknown Beam ............................................................................. 131
9.8.2.4 COTP Terminal Operating in Multiple Beams ............................................................................ 134
9.8.2.5 COTM Terminal Operating in Multiple Beams ........................................................................... 136
9.8.2.5.1 Automatic Initial Beam Selection ......................................................................................... 139
9.8.2.5.2 Target Beam Selection ........................................................................................................ 141
9.8.2.5.3 Beam Switching Mechanism ............................................................................................... 142
9.8.2.5.4 GXT Files ............................................................................................................................. 146
9.8.2.5.5 Mobility API .......................................................................................................................... 147
9.8.2.5.6 Transponder-specific Power Offset during Logon ............................................................... 148

Table of Contents
9.8.2.5.7 MCD Overbooking ............................................................................................................... 148

9.8.2.6 Summary ................................................................................................................................... 149
9.8.3 Summary ....................................................................................................................................... 150
9.9 Remote Terminal Satellite Configuration ............................................................................................. 151
9.9.1 How It works .................................................................................................................................. 153
9.9.2 Use Cases ..................................................................................................................................... 155
9.9.2.1 Extending Beam Capacity ......................................................................................................... 155
9.9.2.2 Adding a New Beam .................................................................................................................. 156
9.9.2.3 Deleting a Beam ......................................................................................................................... 157
9.9.2.4 Roaming Agreement ................................................................................................................. 158
9.9.2.5 Migrating the Forward Carrier .................................................................................................... 159
9.10 BUC and Modem Frequency Synchronization .................................................................................. 160
9.11 Doppler Effect on Terminals ............................................................................................................. 165
9.12 SNMP ................................................................................................................................................ 169
9.12.1 Used MIBs ................................................................................................................................... 170
10 Abbreviations ............................................................................................ 172

About This Guide
1 About This Guide

The Newtec Dialog Functional Description provides detailed information about the concepts,
technologies, and features and of the Newtec Dialog® system.
1.1 Revision History
Version Date Reason of new version
1.0 December, 2020 Initial version of this release.
1.2 Cautions and Symbols

The following symbols appear in this guide:
A caution message indicates a hazardous situation that, if not avoided, may result in
minor or moderate injury. It may also refer to a procedure or practice that, if not correctly
followed, could result in equipment damage or destruction.
A hint message indicates information for the proper operation of your equipment,
including helpful hints, shortcuts or important reminders.
A reference message is used to direct to a location in a document with related document

or a web-link.

What is Newtec Dialog®
2 What is Newtec Dialog®

Dialog® is a single-service and multi-service VSAT platform that allows operators and service
providers to build and adapt their infrastructure and satellite networking according to business or
missions at hand. Based on the cornerstones of flexibility, scalability and efficiency, the Dialog
platform gives the operator the power to offer a variety of services on a single platform.
Key characteristics are:
• Flexible service offering
• Flexible business models
• Multi-service operation
• Anywhere, anytime service
• Streamlined operations
The Dialog platform fully manages all aspects of a service: bandwidth usage, real-time
requirements, network characteristics and traffic classification. The platform offers these services
with carrier grade reliability through full redundancy of the platform components.
The Dialog platform supports multiple traffic types, such as the following:
• Video and audio
• Data
• Voice
• Data casting

The core of the Dialog platform is the Hub, which is located at a physical gateway site. A Dialog
platform can consist of one or more hubs, located at one or more gateways.
A hub consists of one or more Hub Modules. A hub module contains all hardware and software
required for aggregating and processing traffic of one or more satellite networks.
Following types of hub modules exist:
• The 1IF hub module serves one satellite network and is suited for small networks. It provides less
scalability and flexibility than the next hub modules. It is also referred to as HUB6501.
• The 4IF hub module serves up to four satellite networks and is suited for medium to large
networks. It provides flexibility and scalability. It is also referred to as HUB6504.
• The XIF hub module is suited for very large networks and provides full flexibility and scalability. It
can serve up to 18 satellite networks. It is the combination of one or two baseband hub modules
and one processing hub module. The combination of HUB7208 and HUB7318 is referred to as an
XIF hub module.
– The XIF baseband hub module holds the RF devices. It is also referred to as HUB7208.
– The XIF processing hub module holds the processing servers. It is also referred to as
HUB7318. HUB7318 is deployed on the Newtec Private Cloud Infrastructure or NPCI.
Equipment redundancy is supported for all devices in the hub module. A hub module may be
implemented fully redundant, non-redundant or partially redundant.
The Terminal is the equipment located at the end-user’s site. It consists of the outdoor unit
(antenna, LNB and BUC) and the indoor unit, i.e. the modem.
Dialog R2.4.1 supports all modem types.

Do note that new features as described in the release notes of Dialog R2.4.1 and higher
are no longer supported on MDM2200, MDM2500 and MDM3x00.

A hub module is connected to an IP backbone at one side and to an RF interface at the other side,
establishing the Satellite Network.
A satellite network is associated with forward link capacity from one physical or virtual (in case of
DVB-S2X Annex M) forward carrier and with the corresponding return link capacity. The forward link
is based on one of the following technologies:
• DVB-S2
• DVB-S2X
• DVB-S2X Annex M.
The return link supports multiple return link technologies:
• 4CPM MF-TDMA
• DVB-S2 and S2-Extensions SCPC
• HRC SCPC and Mx-DMA
• MRC NxtGen Mx-DMA

Network Resources are configured on top of the physical satellite networks and are isolated from
each other using VLAN identifiers. Dialog provides end-to-end network connectivity for three types
of networks:
• Layer
• Layer 2
• Multicast
Layer 3 network resources consist of one or more virtual networks. A layer 3 virtual network is an
isolated IPv4 or IPv6 network. Devices within the same virtual network can directly communicate
with each other. A virtual network can independently use its own addressing scheme and the same
addressing schemes can be reused in different virtual networks.
Layer 2 network resources consist of one or more point-to-point virtual connections. A layer 2
point-to-point virtual connection can be considered as a virtual Ethernet pipe, which establishes
isolated communication between two devices.
A multicast network connects an uplink network on the hub side with one or more LAN networks on
the modem side. This consists of a single multicast routing instance providing unidirectional routing
of multicast IP traffic from the uplink network to the modem LAN networks. The MC network can
therefore be compared to a multicast router.

The Dialog platform is managed through a single Network Management System or NMS. The
NMS can be embedded in a hub module or it can be a standalone hub module, which is deployed on
a Private Cloud Infrastructure or NPCI. The standalone NMS on NPCI is referred to as HUB7318.
The NMS provides a unified management interface to monitor, manage and control the Dialog
platform. It serves as a single point of access and embeds the following configuration and
management interfaces:
• Satellite resources
• Network resources
• Service and classification profile management
• Terminal provisioning
• Fault (alarms) and performance (metrics) management

Forward Link
3 Forward Link
3.1 Forward Link Definition

The forward link is defined as the link from the hub over the satellite to the terminals. The forward
link can use the DVB-S2 and DVB-S2X standard as well as the DVB-S2X Annex M standard.
Annex M specifies the implementation of a DVB-S2 profile suitable for operation in

wideband mode, without requiring a full-speed decoding of the total carrier capacity, by
suitably mapping the transmitted services in time-slices.
A forward link uniquely identifies a satellite network. The forward link is segmented into forward
pools, which divide the total forward bandwidth into chunks of IP capacity.
A terminal is assigned to a forward link, and hence a satellite network, during terminal provisioning.
DVB-S2/S2X Forward Carrier

In DVB-S2 and DVB-S2X, the physical forward carrier corresponds with one forward link.
DVB-S2X Annex M Forward Carrier (wideband)

In DVB-S2 X Annex M, the wideband forward carrier corresponds with one or more forward links or
virtual carriers.

Forward Link
3.2 DVB-S2(X) Key Concepts
3.2.1 Encapsulation
All traffic sent through a Dialog system needs to be encapsulated into baseband frames. Baseband
frames are the basic units used in the DVB-S2(X) standard. The DVB-S2(X) standard provides
(de)modulation and (de)coding services and a simple addressing scheme in the form of an 8-byte
Input Stream Identifier (ISI). Each baseband frame sent by a modulator has a MODCOD which
specifies the MODulation scheme (QPSK/8PSK/16APSK/32APSK/...) and CODing scheme (7/8,
9/10, ...).
The encapsulation layer provides the following services:
• Process the incoming traffic to allow correct and efficient placement of the data in BBF (baseband
frames). The encapsulator has to insert the traffic in baseband frames of the appropriate
MODCOD, making sure the intended receiver is able to demodulate and decode baseband frames
destined for it at all times, even when the signal-level at the receiver changes over time.
• Ensure that the satellite channel is used efficiently. There should be a minimum waste of space in
the baseband frame layer due to padding. The encapsulator can slices data packets into
fragments if the packet is too large to fit in the baseband frame. Fragments are inserted in
different baseband frames. The encapsulator can also decide to merge packets into the same
baseband frame and it can even decide that packets, which can be sent on a high MODCOD, are
sent on a lower MODCOD when there is still space in the low MODCOD baseband frame.
• To achieve above services, the encapsulation layer pre-pends the traffic with an
encapsulation-header. This header will contain all the necessary info for the receiver to
reconstruct fragments. The encapsulation header additionally contains extra addressing
information, which the receiver can use to decide whether an encapsulated packet is intended for
it. The encapsulator knows which incoming IP addresses are destined for which receivers and
adds the correct encapsulation-level addressing information (generally in the form of a
MAC-address) to the encapsulation-header.
In a Dialog system, you can use the following encapsulation protocols:
• MPE or Multi Protocol Encapsulation is an MPEG-based encapsulation protocol. The payload is
wrapped into an MPE section header. In case of a layer 2 payload, the extra 8-byte LLC/SNAP
header is added as well. Optional stuffing and a 4-byte CRC is added to the trailer. The complete
MPE section is wrapped up to the Transport Stream or TS cells (typically 188-byte). The TS
stream is fitted into baseband frames.
• GSE or Generic Stream Encapsulation is more efficient. GSE can use 0, 3 or 6-byte labels. Data
traffic is GSE-encapsulated and the GSE stream is fitted into baseband frames. The payload is
wrapped into a GSE header, which includes the Protocol Type field used to distinguish between
layer 3 (IPv4 or IPv6) and layer 2 (Ethernet) traffic.
GSE-encapsulated data and MPE-encapsulated data cannot co-exist in the same baseband frame.
The signaling sent by return link controllers is always MPEG-based, even when GSE encapsulation
is used. In case of MPE encapsulation, the signaling and payload MPEG-TS streams can be merged
into the same baseband frame. In case of GSE encapsulation, this is not the case and a separate
ISI (Input Stream Identifier) value in the baseband frame is used to distinguish between signaling
and data traffic.
In case of a low MODCOD, signaling traffic is typically low. When using GSE encapsulation, the
baseband frames with MPEG-TS signaling cannot be filled with the GSE-encapsulated data. They
will be padded instead. As a result, the filling efficiency of the baseband frames is rather low when
using GSE compared to MPE. On the other hand, the data itself is encapsulated more efficiently with
GSE.
The following table shows when it becomes more efficient to use GSE than MPE.

Forward Link
Average packet size Bitrate for which GSE is more Bitrate for which GSE is more
efficient than MPE for layer 3 efficient than MPE for layer 2
traffic traffic
Normal frames
50 bytes 37 Mbps 23 Mbps
Short frames
50 bytes 2.9 Mbps 1.8 Mbps
3.2.2 Baseband Frames

The CSE (Controller Shaper Encapsulator) encapsulates forward traffic (user, control and
management traffic) into DVB-S2(X) baseband frames or BBFs.
Refer to Forward Link End-to-End on page 22 for more details about the CSE and

other equipment involved in the forward link.
The baseband frames are sent to the modulator over UDP/IP. There are two criteria to hand over a
baseband frame from the encapsulator to the modulator:
• When the baseband frame is full.
• When the packing delay has expired.
The modulator takes care of the modulation and forward error correction. For more information, refer
to Modulation on page 10 and Forward Error Correction on page 13. Each baseband frame can be
modulated with a different MODCOD depending on the signal to noise ratio of the forward signal
and the ACM configuration. For more information about MODCODs and ACM, refer to MODCOD on
page 13 and ACM on page 72.
Forward Error Correction or FEC is added to the baseband frame to control errors in the data
transmission. As baseband frames have fixed sizes, the use of FEC reduces the useful date inside
the baseband frame. Typical values for the FEC rate are 1/2, 3/4, 8/9, ... For example, a FEC rate of
3/4 means that for each three data bits sent, one FEC bit is sent.
Two types of frames exist:

Forward Link
• Normal frames, which have a fixed size of 64800 bits.

• Short frames, which have a fixed size of 16200 bits.
3.2.3 Modulation
Modulation is the process of varying one or more properties of a periodic waveform, called the
carrier signal, with a separate signal that typically contains information to be transmitted, called the
modulating signal. When a digital message, such as the baseband frames, has to be represented as
an analog waveform, the technique and term keying (or digital modulation) is used. Keying is
characterized by the fact that the modulating signal will have a limited number of states at all times,
representing the corresponding digital states (zeros and ones).
The most fundamental digital modulation techniques based on keying are:
• PSK or Phase Shift Keying, which uses a finite number of phases. The majority of satellite links
use PSK.
• ASK or Amplitude Shift Keying, which uses a finite number of amplitudes.
• APSK or Amplitude and Phase Shift Keying, which is a mixture of ASK and PSK.
Digital bits are represented by an analog symbol. Depending on the number of bits used per symbol,
following popular modulation types exist:
• BPSK: 1 bit per symbol.
• QPSK (or 4-PSK): 2 bits per symbol.
• 8PSK: 3 bits per symbol.
• 16APSK: 4 bits per symbol, combining phase and amplitude.
• 32APSK: 5 bits per symbol, 3 amplitude levels.
• 64APSK 6 bits per symbol, 4 amplitude levels.
The number of changes applied to the modulating signal per second is the symbol rate (also known
as baud rate or modulation rate). The symbol rate is measured in baud (Bd) or symbols per second.
A modulation is represented by a constellation diagram. The dots on the constellation diagram
correspond with the symbols. The higher the modulation, the more bits per symbol are used and the
more efficiently data is transferred, but the closer the dots are to each other on the constellation.

Forward Link

Forward Link
At the receiving side, the phase and/or amplitude of the modulated signal are measured and
mapped to the corresponding constellation. As the signal has been exposed to noise and losses
during transmission, the measurement will not exactly map to a dot on the constellation. The
receiving side translates the signal into the symbol to which the measurement is the closest.
This also means that the signal quality for a higher modulation should be better than for a lower one.
The better the signal quality, the closer the measurements will be located to the dots on the
constellation.
In Dialog:
• The symbol rate of a non-wideband forward carrier ranges between 1 and 133
Mbaud.
• The symbol rate of a wideband forward carrier ranges between 1 and 480 Mbaud.
If the symbol rate of the forward link is less than 3.6 Mbaud, it is advised to use PLL
LNBs for the terminals.
MDM2000 series only support iLNBs, which is not PLL. Therefore, it is not possible to
use a symbol rate less than 3.6 Mbaud for these modem types.

Forward Link
3.2.4 Forward Error Correction

During transmission, the conditions of the transmission channel can vary causing changes to the
amplitude, frequency or phase of the carrier wave. Possible causes of signal degradation or loss
are:
• Atmospheric absorption and rain
• Noise from other RF sources (for example the sun)
• Power dissipation
• Non linear amplification
Forward Error Correction or FEC is applied to control errors in the data transmission. FEC adds
extra bits to the data before transmitting it. These extra bits reflect the amount of repetition and
protection. The applied FEC rate is defined as content data rate / output data rate. The lower the
rate, the better the protection. A higher FEC rate results in a better efficiency. Some examples of
FEC rates:
• FEC rate 9/10 implies that per 9 bits of data, one protection bit is added.
• FEC rate 1/4 implies that per bit of data, three protection bits are added.
Low-Density Parity Coding (LDPC) and Bose-Chaudhuri-Hocquenghem (BCH) codes are used in
DVB-S2(X).
The 9/10 FEC rate cannot be applied on short BBF.
3.2.5 MODCOD
Data transferred via a satellite is modulated and coded at the transmitting side and demodulated and
decoded at the receiving end. The applied modulation and coding (or FEC rate) is called the
MODCOD. The modulation defines the number of bits that are sent per symbol (2 for QPSK, 3 for
8PSK, 4 for 16APSK, ...). The coding scheme defines the useful bits relative to the total bits present
in a baseband frame. The redundant bits allow the receiver to recover the original useful content
without retransmission in the event of a corrupted baseband frame. A high MODCOD is linked to a
high data rate but requires a good signal-to-noise ratio at the receiver's end. A low MODCOD will
work even with a lower signal-to-noise ratio, but at the cost of having a lower data rate.
Each combination of a specific modulation and coding has a certain spectral efficiency. The spectral
efficiency refers to the amount of information that can be transmitted over satellite in a given
bandwidth: the larger the spectral efficiency, the more information that can be sent over the satellite
link in the same bandwidth. For example, MODCOD 32APSK 9/10 has a spectral efficiency of 4.36
(bits/s)/Hz and MODCOD QPSK 1/4 has a spectral efficiency of 0.48 (bits/s)/Hz.
DVB-S2X extends the range of operation of DVB-S2 with a very low SNR or VL-SNR operation
range, which allows to operate in noise compromised environments or with small antenna terminals,
and a very high SNR or VH-SNR operation, which improves throughput on high capacity trunk and
contribution links. DVB-S2X also introduces linear MODCODs (indicated by a '-L' suffix in the
MODCOD name), which have been optimized for a linear channel in the presence of phase-noise.
In Dialog the use of VL-SNR MODCODs is optional and when enabled, allows terminals with an
Es/No value as low as -10 dB, typically mobile terminals, to lock on the forward. The standard SNR
operation range operates reliably at symbol-energy per noise levels of slightly lower than Es/No =
-2.5 dB.

Forward Link
VL-SNR is only supported on MCM7500.
VL-SNR is supported on AMC5001 and MDM5010.

MDM3310, SMB3310, SMB3315, MDM2510, MDM2210, and MDM5000 are compatible
with VL-SNR frames, meaning that they are able to recognize and ignore VL-SNR
frames.
The other terminals cannot be used on a forward link where VL-SNR MODCODs are
enabled.
Following MODCODs are supported in Dialog.
DVB-S2
ID Modulation Coding Normal Frame Short Frame
1 QPSK 1/4 ✔ ✔
2 1/3 ✔ ✔
3 2/5 ✔ ✔
4 1/2 ✔ ✔
5 3/5 ✔ ✔
6 2/3 ✔ ✔
7 3/4 ✔ ✔
8 4/5 ✔ ✔
9 5/6 ✔ ✔
10 8/9 ✔ ✔
11 9/10 ✔ ✖
12 8PSK 3/5 ✔ ✔
13 2/3 ✔ ✔
14 3/4 ✔ ✔
15 5/6 ✔ ✔
16 8/9 ✔ ✔
17 9/10 ✔ ✖
18 16APSK 2/3 ✔ ✔
19 3/4 ✔ ✔

Forward Link
20 4/5 ✔ ✔
21 5/6 ✔ ✔
22 8/9 ✔ ✔
23 9/10 ✔ ✖
24 32APSK 3/4 ✔ ✔
25 4/5 ✔ ✔
26 5/6 ✔ ✔
27 8/9 ✔ ✔
28 9/10 ✔ ✖
DVB-S2X
Standard and VH-SNR MODCOD
1 QPSK 1/4 ✔ ✔
2 1/3 ✔ ✔
3 2/5 ✔ ✔
4 1/2 ✔ ✔
5 3/5 ✔ ✔
6 2/3 ✔ ✔
7 3/4 ✔ ✔
8 4/5 ✔ ✔
9 5/6 ✔ ✔
10 8/9 ✔ ✔
11 9/10 ✔ ✖
12 8PSK 3/5 ✔ ✔
13 2/3 ✔ ✔
14 3/4 ✔ ✔
15 5/6 ✔ ✔

Forward Link
16 8/9 ✔ ✔
17 9/10 ✔ ✖
18 16APSK 2/3 ✔ ✔
19 3/4 ✔ ✔
20 4/5 ✔ ✔
21 5/6 ✔ ✔
22 8/9 ✔ ✔
23 9/10 ✔ ✖
24 32APSK 3/4 ✔ ✔
25 4/5 ✔ ✔
26 5/6 ✔ ✔
27 8/9 ✔ ✔
28 9/10 ✔ ✖
32 QPSK 11/45 ✖ ✔
33 4/15 ✖ ✔
34 13/45 ✔ ✖
35 14/45 ✖ ✔
36 9/20 ✔ ✖
37 7/15 ✖ ✔
38 8/15 ✖ ✔
39 11/20 ✔ ✖
40 32/45 ✖ ✔
41 8PSK 7/15 ✖ ✔
42 8/15 ✖ ✔
43 5/9_L ✔ ✖
44 26/45 ✖ ✔
45 26/45_L ✔ ✖

Forward Link
46 23/36 ✔ ✖
47 25/36 ✔ ✖
48 32/45 ✖ ✔
49 13/18 ✔ ✖
50 16APSK 7/15 ✖ ✔
51 1/2_L ✔ ✖
52 8/15 ✖ ✔
53 8/15_L ✔ ✖
54 5/9_L ✔ ✖
55 26/45 ✔ ✔
56 3/5 ✔ ✔
57 3/5_L ✔ ✖
58 28/45 ✔ ✖
59 23/36 ✔ ✖
60 2/3_L ✔ ✖
61 25/36 ✔ ✖
62 32/45 ✖ ✔
63 13/18 ✔ ✖
64 7/9 ✔ ✖
65 77/90 ✔ ✖
66 32APSK 2/3 ✖ ✔
67 2/3_L ✔ ✖
69 32/45 ✔ ✔
70 11/15 ✔ ✖
71 7/9 ✔ ✖
72 64APSK 32/45_L ✔ ✖
73 11/15 ✔ ✖

Forward Link
74 7/9 ✔ ✖
76 4/5 ✔ ✖
78 5/6 ✔ ✖
80 128APSK 3/4 ✔ ✖
81 7/9 ✔ ✖
82 256APSK 29/45_L ✔ ✖
83 2/3_L ✔ ✖
84 31/45_L ✔ ✖
85 32/45 ✔ ✖
86 11/15_L ✔ ✖
87 3/4 ✔ ✖
[OPTIONAL] VL-SNR MDOCOD
MODCOD Normal Frame Short Frame
BPSK-S 1/5t ✔ ✖
BPSK-S 11/45 ✔ ✖
BPSK 1/5 ✔ ✔
BPSK 11/45 ✔ ✖
BPSK 4/15 ✖ ✔
BPSK 1/3 ✔ ✔
QPSK 2/9 ✔ ✖
3.2.6 Pilots
A modulator can insert pilots to increase the reliability of the receiver synchronization. At the
physical layer, the baseband FEC frame is sliced into slots of 90 symbols and a pilot is injected after
every 16 slots. Pilots are blocks of 36 unmodulated symbols, which can be received by any receiver.
Pilots are enabled by default in the Forward Carrier of a Newtec Dialog system. The physical layer
frame header flags whether or not pilot insertion is enabled.
3.3 DVB-S2X Annex M
3.3.1 Wideband and Time Slicing

Forward Link
Time slicing is supported on MCM7500 modulators and MDMxx10 modems.
High Transport Satellites use wideband transponders which results in forward carriers that can go up
to 480 Mbaud or reach a throughput of ~ 2 Gbps. The use of wideband carriers require complex and
expensive receivers. To avoid this expense, Annex M of the DVB-S2X standard introduces the
concept of time slicing.
Time slicing is a way to split a wideband carrier into smaller Virtual Carriers or VCs. The smallband
VCs can be received by low-cost modems.
Time slicing cuts the wideband forward carrier into frames, which are marked with a slice identifier at
physical layer. The frames of the wideband carrier with the same slice ID correspond with one VC. A
terminal is linked to a virtual carrier through the satellite network where it is provisioned. The
terminal only processes frames with the corresponding slice ID, all other frames are ignored at
physical layer level. In the figure below, frames with slice id = 1 are processed, the other frames are
dropped. This results in the receiver/demodulator having more time to process the frames.
3.3.2 Maximum Symbol Rates
Without Time Slicing

The tables below provide the maximum symbol rates in Mbaud when time slicing is not used (no
Annex M operation). In this case the physical carrier equals the size of the satellite network.
The maximum symbol rate depends on the population of terminals in the satellite network.
The maximum symbol rates for a uniquely chip-based modem population (MDM2x10 and/or
MDM3xx0) depend on the MODCOD. These modems do not support MODCOD 128APSK and
256APSK.
Maximum Symbol Rate (Mbaud)
QPSK 8PSK 16APSK 32APSK 64APSK
127 82 64 51 43
The maximum symbol rates for a uniquely FPGA-based modem population (MDM5010 and/or
AMC5001) are not MODCOD dependent but are limited by the maximum modem symbol rate and bit
rate.
Maximum Symbol Rate Maximum Bit Rate FPGA Maximum Bit Rate IP (Mbps)
(Mbaud) (Mbps)
220 800 450

Forward Link
In case of a mixed chip-based and FPGA-based modem population, the symbol rates of the
chip-based modems apply making sure that those modems can remain locked on the forward
carrier.
Note that the FPGA-based modems also support MODCOD 128APSK and 256APSK.
With Time Slicing

The table below provides the maximum symbol rates in Mbaud when using time slicing (Annex
M operation).
The maximum symbol rate depends on the population of terminals in the satellite network.
The maximum symbol rates for a uniquely chip-based modem population (MDM2x10 and/or
MDM3xx0) depend on the MODCOD and the number of satellite networks or VCs per physical
carrier. It is assumed that:
• The VC sizes or symbol rates are equal;
• The highest MODCOD is the same per VC;
• The sum of VC sizes equals 0.997 times the physical carrier size.
# VCs Maximum Symbol Rate (Mbaud)
QPSK 8PSK 16APSK 32APSK 64APSK
1 148 148 132 106 88
2 144 144 110 79 NA
3 135 135 102 79 58
4 120 120 108 81 65
5 NA NA 96 86 69
6 NA NA NA 80 72
7 NA NA NA NA 68
Some remarks:
• The sum of VC sizes must be lower than or equal to 0.997 times the size of the physical carrier.
• In case the VCs have different highest MODCODs, the VC sizes corresponding with the highest
MODCOD over all VCs should be used. The size of a VC with a lower highest MODCOD can in
this case be increased by ~10%.
• In case the sum of the VC sizes is lower than 0.8 times the physical carrier size and there is more
than one VC, the symbol rate values in the table above can be increased with 2%.
• The values in the table above are not valid when there is only one VC with a size that is lower
than 0.997 times the physical carrier size.
For these special cases, contact ST Engineering Customer Support for the exact
symbol rate values.
The maximum symbol rates for a uniquely FPGA-based modem population (MDM5010 and/or
AMC5001) are not MODCOD or VC dependent but are limited by the maximum modem symbol rate
and bit rate.

Forward Link
Maximum Symbol Rate Maximum Bit Rate FPGA Maximum Bit Rate IP (Mbps)
(Mbaud) (Mbps)
220 800 450
In case of a mixed chip-based and FPGA-based modem population, the symbol rates of the
chip-based modems apply making sure that those modems can remain locked on the forward
carrier.
Note that the FPGA-based modems also support MODCOD 128APSK and 256APSK.
Chip-based modems can handle a physical carrier size of up to 480 Mbaud. For
FPGA-based modems, the physical carrier size is limited to 220 Mbaud.

Forward Link
3.4 Forward Link End-to-End

Following functional blocks are involved in the forward end-to-end link.
The functional blocks used, depend on the type of traffic.

Layer 3 unicast and layer 2 point-to-point traffic enter the Dialog system via the demarcation service:
• DEM or Demarcation Service provides the interface towards the customer infrastructure for layer 3
traffic.
• L2DEM provides the interface towards the customer infrastructure for layer 2 traffic.
The layer 3 unicast traffic and layer 2 point-to-point traffic is forwarded to the TAS or Traffic
Acceleration Service and then to the CSE or Controller Shaper Encapsulator.
Multicast traffic is directly forwarded to the CSE.
The TAS is responsible for:
• TCP acceleration.
• Encapsulating all user traffic into a tunnel.
• Encrypting user traffic.
• Compressing the header of user traffic.
• Forwarding tunneled traffic to the CSE.
The CSE is responsible for:
• Shaping the forward traffic.
• Sending ACM configuration parameters towards the remote terminal(s).
• Processing the line quality feedback and MODCOD requests from the remote terminal(s).
• Encapsulating the forward traffic:
– With MPE (Multi Protocol Encapsulation) into MPEG TS cells
– With GSE (Generic Stream Encapsulation) into datagrams
• Encapsulating the MPEG cells or datagrams into DVB-S2(X) baseband frames.
• Multiplexing layer 2 control traffic as MPEG cells together with the encapsulated forward data
traffic.
• Forwarding the baseband frames over UDP/IP towards the modulator.
All traffic is forwarded from the CSE to the modulator, which is responsible for:
• Applying forward error correction.
• Turning baseband frames into physical layer (PL) frames, inserting pilots, and applying modulation
to the PL frames.

Forward Link
• Transmitting the modulated PL frames over the satellite link towards the remote terminal.
The remote modem is responsible for:
• Demodulating the incoming signal.
• Performing calculations based upon the received ACM parameters.
• Sending line quality feedback (Es/No measurements) and MODCOD requests back towards the
CSE (via the return link).

Return Link
4 Return Link
4.1 Return Link Definition

The return link is defined as the link from the terminals over the satellite to the hub. The return link in
Dialog supports the following access and coding & modulation technologies:
• 4CPM MF-TDMA
• DVB-S2 and S2-Extensions SCPC
• HRC SCPC and Mx-DMA
• MRC NxtGen Mx-DMA
The access technology allocates the return link resources to the terminals. The coding and
modulation technology transforms the data into an analog satellite signal.
The Dialog platform allows terminals to easily switch from one return technology to another. Having
the choice between the return technologies in a network within a single modem guarantees network
operators a business model with maximum flexibility in supported applications, responsiveness to
new market opportunities and Service Level Agreement or SLA schemes that fit customers’ needs.

Return Link
The supported return technologies depend on the type of modem:
Modem Type SCPC MF-TDMA Mx-DMA NxtGen Mx-DMA
MDM2010 X X
MDM2200 X
MDM2210 X
MDM2500 X
MDM2510 X X X
MDM3100 X X
MDM3300 X X X

Return Link
MDM3310 X X X X
SMB3310 X X X X
SMB3315 X X X X
MDM5000 X X X
MDM5010 X X X X
4.2 MF-TDMA 4CPM
4.2.1 Definition
4CPM (Quaternary Constant Phase Modulation) is a coding and modulation technology that
allows to saturate the outdoor unit without generating distortion, or that allows a transmitter to
operate in full saturation.
MF-TDMA (Multi Frequency - Time Division Multiple Access) is a bandwidth allocation
mechanism which divides the return link capacity in frequency and time slots. In MF-TDMA terminals
are assigned time slots spread over multiple frequencies, which they use to send data. This
assignment is scheduled in a Terminal Burst Time Plan (TBTP). The TBTP is calculated by the
CPMCTL (Constant Phase Modulation Controller) and based upon the capacity requests from the
terminals. The CPMCTL is a virtual machine in the hub.
Capacity requests can be random or on-demand. MF-TDMA uses the concept of statistical
multiplexing, meaning that the resources are dynamically allocated based on analyzed statistics
such as peak data rates and percentage of time a terminal is sending/receiving data. A terminal is
assigned time slots according to priority and need.
4.2.2 Coding and Modulation

In 4CPM the coding and modulation are tied together into six predefined MODCOD values. The
MODCOD value identifies the modulation details, coding details and the ratio of carrier
spacing/symbol rate which is called the NSP (Normalized Spacing) or scheme efficiency.
MODCOD NSP
0 1.906
1 1.631
2 1.215
3 1.192
4 1.133
5 1.077
4CPM supports multiple carrier spacing (128 kHz, 256 kHz, ...). The symbol rate relates to the
carrier spacing as follows: symbol rate = carrier spacing/NSP. For example, a 256 kHz carrier
MODCOD 4 results in a symbol rate of approximately 226 kbaud (256 / 1.133).

Return Link
4.2.3 Access Layer

The 4CPM MF-TDMA return link technology uses following protocol stack:
Encapsulation follows the Generic Stream Encapsulation (GSE) standard, which provides a generic
way to encapsulate variable length data (for example an IP packet) into 4CPM baseband frames of
128 bytes. The payload is wrapped into a GSE header, which includes the Protocol Type field used
to distinguish between layer 3 (IPv4 or IPv6) and layer 2 (Ethernet) traffic. A baseband frame can be
filled up by multiple payloads or a payload can be fragmented over sequential baseband frames. In
case of fragmentation, the last GSE datagram has a CRC-32 (4B) field at the end. No CRC field is
applied in case of unfragmented PDU. Padding is added to the BBF if the BBF is not completely
filled
Because of the variable amount of available bytes in the payload data field, there is no predictable
overhead; 10% is taken as a rule of thumb.
Each terminal has independent GSE streams, one for each return link QoS class.
The SAC (Satellite Access Control) field in a BBF contains the request for slots which are
piggybacked in this field. There are two types of slots: CSC (logon) or TRF (traffic).
As indicated in the protocol stack overview, DAMA (Demand Assigned Multiple Access) is used to
assign traffic slots based on requests from the terminals in the SAC field. CSC slots are requested
using the Slotted ALOHA technology.

Return Link
As mentioned in the Definition on page 26, the Terminal Burst Time Plan (TBTP) defines the
dynamic assignment of time slots. The TBTP is generated every super frame (SF) and a superframe
is calculated every 1/6th of a second.
Guard times are applied to allow the Burst Demodulator or BDM to properly handle the baseband
frames. The guard times anticipate on time shifts. Guard times for traffic slots are typically 4 μs,
guard times for CSC slots are typically 22 ms.

Return Link
Following table shows all possible carrier types and their corresponding amount of slots per
superframe (SF) and traffic rate.

Return Link
4.2.4 Return Capacity Groups and Carrier Pools

The return link resources are defined per satellite network. The MF-TDMA return traffic carriers in
the Dialog system are organized in return capacity groups. They are artificial frequency sections of
the total return link spectrum of the beam. A beam is a geographical area that sends its return signal
via a certain satellite transponder.
A Return Capacity Group (RCG) is segmented into Carrier Pools. Carrier pools are artificial
frequency sections of the total spectrum of the RCG. Each carrier pool consists of traffic or TRF
carriers with the same carrier spacing and associated modulation and coding (known as MODCOD)
and is characterized by a minimum and maximum C/N0 or Carrier to Noise ratio. The type and
number of TRF carriers depends on your link budget. A terminal can jump from one carrier pool to
another using the Adaptive Return Link or ARL technology. For more information about ARL, refer
to Adaptive Return Link on page 77.
Each satellite network has a number of Common Signaling Channel or CSC carriers, which are
used to transmit the logon bursts from the terminals. When logging on to the network, there are no
specific CSC slots assigned to the terminal. The terminal chooses on which CSC slots to bursts. It is
advised to use the same type of CSC carrier per satellite network. When using CPM as return
technology, the synchronization coverage and the satellite position determine the area in which
terminals are able to logon to the network.
4CPM is sensitive to adjacent channel interference (ACI). This means that the slot assigned to
one terminal is interfered by another terminal bursting on a slot at the same time on an adjacent
carrier and vice-versa. The higher the difference in C/N0 of the two terminals, the higher the ACI.
Typically lower 4CPM MODCODs are less sensitive to ACI than higher MODCODs. To limit ACI, a
maximum C/N0 per return carrier pool should be defined. For each bandwidth/MODCOD
combination, default minimum and maximum C/N0 values are defined to find a balance between the

Return Link
dynamic range of the carrier pool and the ACI degradation. It is advised to use these default C/N0
thresholds. When changing the thresholds, keep in mind that:
• The different carrier pools defined in the RCG should form a contiguous region in the C/N0
domain.
• Setting the minimum C/N0 too low can lead to lost volume due to allocated time slots that "weak"
terminals cannot use.
• Setting the maximum C/N0 too high can lead to lost volume due to high ACI imposed on weaker
terminals.
For more information about configuring the return capacity groups and carrier pools,
refer to the Newtec Dialog Configuration User Guide.
4.2.5 Burst Demodulator

Demodulation of the 4CPM return link carriers is done by one or more Burst Demodulators or BDMs.
If multiple BDMs are used for the satellite network, it is advised to spread the return carriers over the
different BDMs.
Following demodulators support 4CPM:
• MCD7000
• MCD7500
• NTC2291
A BDM is characterized by a processing window. The bandwidth of this window is distributed over a
number of receive (RX) channels. An RX channel consists of BDM channels which are configured as
a number of identical carriers with a specific carrier spacing and a specific frequency of the first
carrier. All carriers within the BDM channel are adjacent in frequency.
The more carrier pools or carrier types you have in a return capacity group, the more BDM channels
this will require which can potentially limit the throughput of the RCG. Choosing less carrier pools
can however lead to a less optimal MODCOD distribution. All carriers of an RCG should be
processed on the same BDM. One BDM can handle one or more RCGs. A BDM can support up to
15,000 terminals.
It is not possible to have a mix of NTC2291 and MCD7x00 within the same return
capacity group.
Assigning carrier types to the Return Capacity Groups and Carrier Pools is done
through the Return Link web interface. For more information, refer to the Newtec
Dialog Configuration User Guide.
The configuration limitations of a BDM are shown in the figure and described in the table below.

Return Link
NTC2291 MCD7500 24 MHz MCD7000/MCD7500

MCD7000/MCD7500 16 48 MHz
MHz
Processing window 16 MHz 24 MHz 48 MHz
Input frequency 950 - 2150 MHz 950 - 2150 MHz 950 - 2150 MHz
Max. number of 80 144 144

carriers
Nr of RX channels 4 * 4.096 MHz 3 x 8 MHz 3 * 16 MHz
Nr of BDM 1 or 2, total max 4.096 1 or 2 or 3, total max 1,2 or 3

channels per RX MHz 8 MHz 16 MHz when only
channel TRF sots
8 MHz when TRF +
CSC
Supported TRF carrier: MODCOD TRF carrier: TRF carrier: MODCOD

MODCODs 0-5 MODCOD 0 - 5 0-5
CSC carrier: MODCOD CSC carrier: CSC carrier:
0, 1 MODCOD 0, 1 MODCOD 0, 1

Return Link
Carriers per BDM 10 carriers 128 kHz TRF 16 carriers 128 kHz 16 carriers 128 kHz
channel, single or CSC TRF or CSC TRF or CSC
MODCOD 10 carriers 192 kHz TRF 16 carriers 192 kHz 16 carriers 192 kHz
10 carriers 256 kHz TRF TRF TRF
or CSC 16 carriers 256 kHz 16 carriers 256 kHz
10 carriers 384 kHz TRF or CSC TRF or CSC
8 carriers 512 kHz TRF 16 carriers 384 kHz 16 carriers 384 kHz
or CSC TRF TRF
5 carriers 768 kHz TRF 16 carriers 512 kHz 16 carriers 512 kHz
TRF or CSC TRF or CSC
4 carriers 1024 kHz TRF
or CSC 10 carriers 768 kHz 10 carriers 768 kHz
TRF TRF
2 carriers 1536 kHz TRF
8 carriers 1024 kHz 8 carriers 1024 kHz
2 carriers 2048 kHz TR
or CSC
1 carrier 2560 kHz TRF
TRF TRF
1 carrier 3072 kHz TRF
1 carrier 3584 kHz TRF TRF or CSC TRF or CSC
1 carrier 4096 kHz TRF 3 carriers 2560 kHz 3 carriers 2560 kHz
or CSC TRF TRF
TRF TRF
TRF TRF

Return Link
4.2.6 4CPM Return Link End-to-End

Following functional blocks are involved in the 4CPM return end-to-end link.
The functional blocks used, depend on the type of traffic.

All traffic passes the remote terminal, which is responsible for:
• Classifying and applying marking on incoming data (received on its LAN port).
• Encapsulating data into GSE baseband frames.
• Applying 4CPM modulation.
• Requesting time slots.
The traffic travels over the satellite link to the hub module and enters the BDM. The burst
demodulator is responsible for:
• Demodulating the 4CPM bursts and forwarding the GSE encapsulated data to the DCP.
• Forwarding the return bandwidth requests and ACM feedback towards the CPMCTL.
• Sending HRC modulation statistics and metrics towards the HRCCTL.
The DCP or decapsulator is responsible for:
• Decapsulating the GSE datagrams.
• In case of tunneled and accelerated data, packets will be forwarded to the TAS.
• In case of layer 3 multicast traffic, the traffic is sent to the uplink VLAN dedicated to terminal
multicast of the satellite network.
• Forwarding the layer 3 IP traffic to the DEM, where it will leave the hub module over a dedicated
VLAN per subnet.
• Forwarding the layer 2 traffic to the L2DEM.
Layer 3 unicast and layer 2 point-to-point traffic leave the Newtec Dialog system via the demarcation
service:
• Layer 3 unicast traffic leaves the Newtec Dialog system by means of the DEM. The DEM provides
layer 3 forwarding (routing) of traffic to and from remote terminals for layer 3 networks (VRFs). Its
routing tables are updated with static configuration, OSPF or BGP. In addition, the DEM acts as a
DNS proxy for the terminals.
• Layer 2 point-to-point traffic leaves the Newtec Dialog system by means of the L2DEM. The
L2DEM provides layer 2 forwarding to and from remote terminals for layer 2 point to point
connections.
The CPMCTL is responsible for:

Return Link
• Calculating the TBTP based upon the received bandwidth requests from the terminal.
• Informing the CSE about the calculated burst time plan.
• Forwarding the return bandwidth requests and ACM feedback towards the CSE.
• Inserting the burst time plan info into the forward signaling and sending it back to the modem via
the MOD or modulator.
• Forwarding the result of the processed ACM feedback to the modem.
4.3 SCPC DVB-S2 and S2 Extensions
4.3.1 Definition
For services requiring high speed return links from the terminals, such as broadcast contribution, IP
trunking or backhauling services, DVB-S2 and S2 Extensions can be used.
S2 Extensions is a bundle of improved candidate technologies prior to the launch of

DVB-S2X in February 2014. S2 Extensions has increased granularity in MODCODs, and
offers linear and non-linear MODCODs.
The access technology that is used with DVB-S2 and S2 Extensions is SCPC. A Single Channel Per
Carrier or SCPC carrier can be considered as an always-on, dedicated, high-bandwidth
communication channel that provides high efficiency. The symbol rate of an SCPC carrier can go
from 1 Mbaud up to 20 Mbaud (MDM3x00), or up to 64 Mbaud (MDM3310 and MDM5000), or up
to 133 Mbaud (MDM5010).
In this mode terminals are assigned to an SCPC carrier with fixed center frequency and symbol
rate. The SCPC carrier must fit into the S2 return capacity group. The S2 return capacity group is
a continuous frequency slot defined by a minimum and maximum frequency. An S2 return capacity
group can have up to three SCPC carriers. The carriers should all fall within this slot and they should
not overlap.
Following demodulators support SCPC DVB-S2:
• MCD6000
• MCD7000
ACM or Adaptive Coding Modulation can be enabled or disabled. When ACM is disabled for an S2
return capacity group, all carrier settings (frequency, symbol rate, MODCOD and power) are
configured statically. The bit rate is fixed and determined by symbol rate and MODCOD. The power
is not adjusted if it is too high or too low. If the configured MODCOD needs a higher EsN0 than
available, there will be packet loss. When ACM is enabled, the S2 return controller (S2CTL) will
adjust the power and MODCOD. The frequency and symbol rate are still statically configured. The bit
rate will change as the MODCOD changes.
Following modem types support DVB-S2 or S2 Extensions in the return link:

MDM3310, SMB3310, SMB3315, MDM5000 and MDM5010.
4.3.2 Access Layer

The DVB-S2 or S2 Extensions SCPC return link technology uses following protocol stack:

Return Link
way to encapsulate variable length data (for example an IP packet) into baseband frames. A
baseband frame can have the following sizes:
• 16200 bits in case of short frames (when symbol rate is < 5 Mbaud)
• 64800 bits in case of normal frames (when symbol rate ≥ 5 Mbaud)
The payload is wrapped into a GSE header, which includes the Protocol Type field used to
distinguish between layer 3 (IPv4 or IPv6) and layer 2 (Ethernet) traffic. A baseband frame can be
applied in case of unfragmented PDU.
Setting the frame type (short or normal) is done via the Terminal Provisioning GUI in
the Advanced S2 Settings.
Padding is added to the BBF if the BBF is not completely filled yet.
4.3.3 DVB-S2 Return Link End-to-End

Following functional blocks are involved in the S2 return end-to-end link.
The used blocks depend on the type of traffic.

Return Link

• Encapsulating data into GSE baseband frames.
• Applying DVB-S2 or S2 Extensions modulation.
The traffic travels over the satellite link to the hub module and enters the DEMOD. The demodulator
is responsible for:
• Demodulating the received signal and forwarding the GSE encapsulated data towards the DCP.
• Sending DVB-S2 modulation statistics and metrics towards the S2CTL.
• In case of layer 3 multicast traffic, the IP traffic is sent to the uplink VLAN dedicated to terminal
• Sending ACM feedback messages (indicating the Forward Es/No and requested MODCOD)
towards the CSE.
VLAN per subnet.
• Forwarding the layer 2 traffic to the L2DEM.
Layer 3 unicast and layer 2 point-to-point traffic leave the Newtec Dialog system via the demarcation
service:
• Layer 3 unicast traffic leaves the Newtec Dialog system by means of the DEM. The DEM provides
layer 3 forwarding (routing) of traffic to and from remote terminals for layer 3 networks (VRFs). Its
routing tables are updated with static configuration, OSPF or BGP. In addition, the DEM acts as a
DNS proxy for the terminals.
• Layer 2 point-to-point traffic leaves the Newtec Dialog system by means of the L2DEM. The
connections.
• Sending the return link layer 2 signaling (destined for the remote modem) to the CSE.
The S2CTL is responsible for:
• Instructing the demodulator about the S2 carrier settings it has to use (as configured by the
operator via the NMS GUI).
• Managing the DVB-S2 / S2 Extensions demodulator hardware resources (for redundancy
purposes).
• Sending the DVB-S2 related layer 2 signaling back to the remote modem via the MOD or
modulator.
• Informing the remote modem about the result of the processed ACM feedback.

Return Link
4.4 Mx-DMA HRC

High Resolution Coding™ technology has a similar efficiency as DVB-S2 but is optimized for lower
rate return links. Because of the small baseband frame size it does not add extra latency.
The demodulators that support HRC are listed below.
• MCD6000 with a maximum baudrate per carrier of 5 Mbaud and an input bandwidth of 36 MHz.
• MCD7000 with
– A maximum baudrate per carrier of 5 Mbaud and an input bandwidth of 36 MHz.
OR
• MCD7500_HRC with
OR
• MCD7500_HRC68 with a maximum baudrate per carrier of 68 Mbaud and an input bandwidth of
72 MHz.
HRC works with frequency slots. A frequency slot has a start and stop frequency and acts as a
frequency window in which HRC carriers reside. HRC demodulators are assigned to a frequency
slot. An HRC demodulator can only be assigned to one frequency slot, but multiple demodulators
can be assigned to the same frequency slot. A frequency slot can combine different demodulator
role types. The combinations are however limited to:
• HRC 5 Mbaud / 36 MHz only. In this case, the maximum frequency slot bandwidth is 36 MHz.
• HRC 20 Mbaud / 72 MHz and 68 Mbaud / 72 MHz. In this case, the maximum frequency slot
bandwidth is 72 MHz.
Within the HRC frequency slots, you will define the HRC return capacity groups.
HRC can be used with two types of access technologies:
• SCPC
• Mx-DMA
The main difference between SCPC and MxDMA is the frequency and symbol rate allocation. In
SCPC, the terminal gets a fixed transmit frequency and symbol rate during provisioning. In Mx-DMA,
the HRC return capacity group is further divide into return pools and the terminal is assigned to a
return pool during provisioning. The HRC controller decides which frequency and symbol rate the
terminal can use to transmit data. This resource allocation can change every frame (second).
It is possible to mix HRC SCPC and HRC Mx-DMA return capacity groups in the frequency slot.

Return Link
4.4.1 HRC SCPC

In this mode terminals are provisioned on an HRC return capacity group, and are assigned to an
SCPC carrier with fixed center frequency and symbol rate. Operation of the HRC SCPC mode is
similar to the DVB-S2 SCPC return link technology. Compared to DVB-S2 and S2 Extensions, the
HRC modulation in SCPC mode is perfectly suited for applications requiring low to medium return
throughput rates (for example professional VSAT, low/medium rate broadcast), while assuring
excellent delay and jitter performance.
The HRC SCPC return link can provide carrier symbol rates from:
• 30 kbaud up to 5 Mbaud, in 31 kbaud granularity steps for MCD6000/MCD7000/MCD7500_HRC
5 Mbd / 36 MHz.
• 30 kbaud up to 20 Mbaud, in 31 kbaud granularity steps for MCD7000/MCD7500_HRC 17 Mbd /
70 MHz.
• 30 kbaud up to 68 Mbaud, in 31 kbaud granularity steps until 20 Mbaud and in 123 kbaud steps
from 20 Mbaud onwards for MCD7500_HRC68.
Combined with a very extensive range of MODCODs from QPSK up-to 32APSK, this results in
carrier throughputs:
• Up to 20 Mbps for for MCD6000/MCD7000/MCD7500_HRC 5 Mbd / 36 MHz.
• Up to 70 Mbps for MCD7000/MCD7500_HRC 17 Mbd / 70 MHz.
• Up to 225 Mbps for MCD7500_HRC68.
ACM or Adaptive Coding Modulation can be enabled or disabled. When ACM is disabled for an HRC
SCPC return capacity group, all carrier settings (frequency, symbol rate, modcod and power) are
configured statically. The HRC controller is not involved. As long as the EsN0 is above -10 dB, the
carrier will be online. The bit rate is fixed and determined by symbol rate and MODCOD. The power
is not adjusted if it is too high or too low. If the configured MODCOD needs a higher EsN0 than
available, there will be packet loss. When ACM is enabled, the HRC controller is will adjust the
power and MODCOD. The frequency and symbol rate are still statically configured. The configured
power and MODCOD will only be used during logon. The power will be adjusted to reach the BEPD
level. The MODCOD will be adjusted according to the ACM rules. The bit rate will change as the
MODCOD changes. The minimum and maximum MODCOD for ACM can be set per HRC SCPC
Return Capacity Group. However, it is also possible to set the maximum MODCOD on a terminal
level.

Return Link
Make sure to run the return link calibration procedure before enabling ACM.
During the HRC return link calibration procedure the reference levels that the HRC controller will use
as a baseline for its calculations, are set. If there is no calibration information, the HRC controller
cannot perform any calculations, meaning that only SCPC without ACM is supported.
This HRC return link calibration procedure includes:
• A terminal transmits an installation carrier during clear sky conditions. Terminals are shipped with
"safe" preset initial transmit power settings (safe modem transmit power levels, low MODCOD,
low symbol rate).
• During the transmission of the installation carrier, the end-to-end gain is measured at the hub
(receive) side.
• During transmission of the installation carrier, the distortion is measured at the hub (receive) side.
Based upon the measured results, an initial safety margin is applied. As one or more terminal log in
and request HRC resources, the hub will be able to measure more accurately, which results in a
reduced safety margin. In other words, the more knowledge the hub can gather, the more accurate it
can allocate resources. The transmitted Power Spectral Density of the modem is adjusted in order to
remain below hub BEPD limit. Correct HRC operation can only be achieved if the calibration
procedure is executed.
For more details on how to execute this procedure, refer to the Return Link
Calibration section in the Newtec Dialog Configuration User Guide
4.4.2 HRC Mx-DMA

Mx-DMA return link technology brings together the best of two traditionally isolated worlds: it
combines the flexibility and statistical multiplexing of MF-TDMA access technologies and the
efficiency of SCPC technologies.
The key characteristics of Mx-DMA are:
• Carrier symbol rates from:
– 30 kbaud up to 5 Mbaud, in 31 kbaud granularity steps for
MCD6000/MCD7000/MCD7500_HRC 5 Mbd / 36 MHz.
– 30 kbaud up to 20 Mbaud, in 31 kbaud granularity steps for MCD7000/MCD7500_HRC 17
Mbd / 70 MHz.
– 30 kbaud up to 68 Mbaud, in 31 kbaud granularity steps until 20 Mbaud and in 123 kbaud
steps from 20 Mbaud onwards for MCD7500_HRC68.
and combined with a very extensive range of MODCODs from very low SNR (VL-SNR) QPSK
up to 32 APSK with 5% roll-off, resulting in carrier throughputs:
– Up to 20 Mbps for for MCD6000/MCD7000/MCD7500_HRC 5 Mbd / 36 MHz.
– Up to 70 Mbps for MCD7000/MCD7500_HRC 17 Mbd / 70 MHz.
– Up to 225 Mbps for MCD7500_HRC68.
• Dynamic and on-demand carrier bandwidth allocation, including advanced and flexible multi-level
QoS model by the central hub HRC scheduler results in very good statistical multiplexing,
optimized carrier configuration for each terminal and maximal throughput and efficiency of the
allocated satellite bandwidth.

Return Link
• The dynamic carrier scheduling is combined with excellent jitter, delay and PER (Packet Error
Correction) performance.
• Includes AUPC, ACM (always enabled), ThiMM technologies resulting in very high link availability.
As a result the HRC Mx-DMA technology provides an efficient access scheme for many applications:
backhauling, enterprise/corporate networking, fast news gathering, government services,…
When using HRC Mx-DMA, the bandwidth resources are allocated to logged on terminals. Every PL
(physical layer) frame and for each logged in terminal, the HRC controller in the hub needs to
determine the following parameters:
• Symbol rate
• MODCOD
• Transmit power
• Transmit frequency
The PL frame has a fixed duration of 1 second.
Resource allocation also needs to take into account:
• What is known (initial starting point for allocation)
• What is possible (frequency and MODCOD boundaries)
• What is allowed (avoid violation of satellite Bandwidth Equivalent Power Density (BEPD), which is
a value that is determined by the satellite operator to avoid using more satellite power per carrier
than authorized, considering the carrier's current occupied bandwidth)
• What is fair (respect the service profile assigned to the terminal)
This is reflected in the figure below.

Return Link
Resources are allocated in such a way that terminals operate at the smallest symbol rate that gives
their fair IP rate using a MODCOD that fits the link budget the best.
The HRC resource allocation process makes sure that the following scenarios are respected:
• Carriers assigned to terminals do not exceed the allocated bandwidth of the HRC return capacity
group.
• Carriers within the HRC return capacity group do not overlap.
Guard bands and guard times are applied during resource allocation in order to deal
with timing and frequency uncertainties. Refer to
Time and Frequency Synchronization on page 97 for more details.
• Terminals do not exceed the contractual Power Flux Density of the satellite. For more information,
refer to Automated Uplink Power Control on page 78.
• Degradation of adjacent channels/carriers is avoided by applying a distortion limit (default 12 dB

below noise level) that keeps possible carrier regrowth well below the system noise level. Note:
typically the smallest carriers are placed at the edges of the allocated bandwidth, because small
carriers are unlikely to generate regrowth.

Return Link
ACM is always enabled for HRC Mx-DMA. The minimum and maximum MODCOD for ACM can be
set per HRC Mx-DMA Return Capacity Group. However, it is also possible to set the maximum
MODCOD and minimum and maximum symbol rate per terminal. This is interesting for terminals
operating with VL-SNR or for keeping terminals, which suffer from phase noise (due to BUC
frequency instability for example) under control.
4.4.3 Encapsulation and Coding

Traffic that comes from the host behind the terminal and enters the remote terminal in its LAN
interface is encapsulated into baseband frames and later coded in order to be sent through the RF
interface.
way to encapsulate variable length data (for example an IP packet) into baseband frames. An HRC
baseband frame has a fixed size of 376 bytes.
applied in case of unfragmented PDU. Padding is added to the BBF if the BBF is not completely
filled yet.
The HRC physical layer makes no distinction between transport methods for the control plane and
the user plane. No bit-fields are foreseen in the physical layer for, for example, dynamic bandwidth
adaptation requests issued by a terminal to the hub. Because HRC return link carriers are dedicated
to a terminal and not shared dynamically by several terminals, the overheads (preamble, guard time,
datagram segmentation) and SNR thresholds are significantly lower than in MF-TDMA return link.
The HRC physical layer does not support the "header" concept as found in DVB-S2. All parameters
of the physical layer required to successfully receive the HRC signal by an HRC demodulator are
known in advance by the hub. There is no need to communicate them embedded in the HRC
physical layer.

Return Link
After encapsulation, the baseband frames are coded. After applying FE coding, the baseband
frames become so called "codewords''. These codewords are embedded in physical layer (PL)
frames, which have a fixed duration of 1 second (independent of symbol rate or MODCOD). Inside a
PL frame, all codewords have the same MODCOD. Frames do not need to contain an integer
number of codewords. Individual stuffing symbol sections are spread out evenly over the PL frame in
order to guarantee that the frame duration remains constant.
4.4.4 MODCOD
Data transferred via a satellite is modulated and coded at the transmitting side and demodulated and
decoded at the receiving end. The applied modulation and coding (or FEC rate) is called the
MODCOD. The modulation defines the number of bits that are sent per symbol (2 for QPSK, 3 for
8PSK, 4 for 16APSK, ...). The coding scheme defines the useful bits relative to the total bits present
in a baseband frame. The redundant bits allow the receiver to recover the original useful content
without retransmission in the event of a corrupted baseband frame. A high MODCOD is linked to a
high data rate but requires a good signal-to-noise ratio at the receiver's end. A low MODCOD will
work even with a lower signal-to-noise ratio, but at the cost of having a lower data rate.
Each combination of a specific modulation and coding has a certain spectral efficiency. The spectral
efficiency refers to the amount of information that can be transmitted over satellite in a given
bandwidth: the larger the spectral efficiency, the more information that can be sent over the satellite
link in the same bandwidth.
The HRC controller in the hub selects the MODCOD based on the Es/No value of the terminal's
return link. The Es/No must have a certain minimum value before a MODCOD can be selected.
The standard SNR MODCODs are listed in the table below. The standard SNR operation range
operates reliably at symbol-energy per noise levels of Es/No ~ -1 dB.
MODCOD ID Modulation Coding
6 QPSK 3/10
7 7/20
8 4/10
9 9/20
10 1/2
11 11/20
12 6/10
13 13/20
14 7/10
15 3/4
16 4/5
17 8PSK 17/30
18 6/10
19 19/30

Return Link
MODCOD ID Modulation Coding
20 2/3
21 7/10
22 11/15
23 23/30
24 4/5
25 5/6
26 13/15
27 16 APSK 27/40
28 7/10
29 29/40
30 3/4
31 31/40
32 4/5
33 33/40
34 17/20
35 7/8
36 32 APSK 18/25
37 37/50
38 38/50
39 39/50
40 4/5
41 41/50
42 21/25
43 43/50
44 22/25
45 9/10
Very Low SNR

Return Link
VL-SNR is supported on MCD7000 and MCD7500.
VL-SNR is supported with HRC Mx-DMA and HRC SCPC with ACM.
One of the Communication on The Move or COTM challenges, for example in aircrafts, is the
requirement for extremely small, equivalent aperture antennas. The hardware limit for an antenna on
an aircraft is between 30 cm and 45 cm. Antennas of this dimension severely limit the achievable
link budgets of a COTM network. Additionally, the pointing error and focus of these antennas often
require using power spectral density reduction technologies to mitigate Adjacent Satellite
Interference or ASI. This can lead to very low SNR signal reception conditions on the hub side.
For conditions with a very low SNR, Dialog implements the frame and synchronous spread
spectrum. The transmitted signal will be constructed by multiplying the slower native symbol stream
by a pseudo-random noise sequence or PN sequence. This PN sequence has a symbol rate which
is x times higher than the native symbol rate, where x corresponds with the spreading factor or SF.
The actual symbol rate over the physical link is called the chip rate.
The efficiency of the spread signal is the standard MODCOD efficiency divided by the spreading
factor. The Es/No threshold of the spread signal equals the standard MODCOD Es/No threshold
minus 10log10(spreading factor). On the hub side, the symbols are de-spread with the same PN
sequence to regain the required Es/No value.
In Dialog the use of VL-SNR MODCODs is optional. When enabled, it allows HRC Mx-DMA
terminals with an Es/No value as low as -6 dB and HRC SCPC terminals with an Es/No value as low
as -12 dB to be operational. The -6 dB limit for HRC Mx-DMA is due to logon constraints.
Very low SNR is enabled when a VL-SNR MODCOD is selected as minimum MODCOD for the HRC
Mx-DMA return capacity group or the as fixed MODCOD for the HRC SCPC CCM carrier. The
configured symbol rates in the NMS GUI refer to the chip rate, and correspond with SF * n * 30.8
kBaud, with n an integer number. VL-SNR is not supported for HRC SCPC with ACM.
Dialog supports the following VL-SNR MODCODs, which are the combination of a standard
MODCOD and a spreading factor.
Modulation Coding Spreading Factor *
QPSK 3/10 15
QPSK 3/10 14
QPSK 3/10 13
QPSK 3/10 12
QPSK 3/10 11
QPSK 3/10 10
QPSK 3/10 9
QPSK 3/10 8
QPSK 3/10 7
QPSK 3/10 6

Return Link
Modulation Coding Spreading Factor *
QPSK 3/10 5
QPSK 3/10 5
QPSK 3/10 4
QPSK 7/20 4
QPSK 3/10 3
QPSK 7/20 3
QPSK 4/10 3
QPSK 3/10 2
QPSK 7/20 2
QPSK 4/10 2
QPSK 9/20 2
QPSK 1/2 2
* The spreading factor of the standard SNR MODCODs is 1.
Extended VL-SNR
Extended VL-SNR allows to handle HRC Mx-DMA logons as low as -12 dB. When enabled, the
logon signal is spread using a spreading factor of 32.
Extended VL-SNR is supported on MCD7000 and MCD7500.
Extended VL-SNR is only supported on AMC5001 and MDM5010 using the HRC
Mx-DMA return link technology.
The support of extended VL-SNR is optional.

The table below shows how the HRC controller is configured for a terminal depending on the
mimimum MODCOD set for the HRC Mx-DMA return capacity group and the support/setting of
extended VL-SNR.
Configuration HRC Controller Configuration
Extended VL-SNR Min. MODCOD RCG Min. MODCOD Max. SF
Off / Not capable >= QPSK 3/10 SF3 Min. MODCOD RCG SF of min. MODCOD
< QPSK 3/10 SF3 QPSK 3/10 3
On Any Min. MODCOD RCG SF of min. MODCOD
When enabling extended VL-SNR, universal logon is automatically enabled for that terminal.

Return Link
Make sure that the HRC Mx-DMA return capacity group is configured to support universal
logon.
4.4.5 HRC Return Link End-to-End

Following functional blocks are involved in the HRC return end-to-end link.
The used blocks depend on the type of traffic.

• Encapsulating data into GSE baseband packets.
• Applying HRC modulation.
The traffic travels over the satellite link to the hub module and enters the DEMOD. The demodulator
is responsible for:
• Demodulating the received signal and forwarding the GSE encapsulated data towards the DCP.
• Sending HRC modulation statistics and metrics towards the HRCCTL.
• In case of layer 3 multicast traffic, the IP traffic is sent to the uplink VLAN dedicated to terminal
• Sending ACM feedback messages (indicating the Forward Es/No and requested MODCOD)
towards the CSE.
VLAN per subnet.
• Forwarding the layer 2 traffic to the L2DEM, where it will leave the hub module over a dedicated
VLAN per VC.
Layer 3 unicast and layer 2 point-to-point traffic leave the Dialog system via the demarcation service:
• Layer 3 unicast traffic leaves the Dialog system by means of the DEM. The DEM provides layer 3
forwarding (routing) of traffic to and from remote terminals for layer 3 networks (VRFs). Its routing
tables are updated with static configuration, OSPF or BGP. In addition, the DEM acts as a DNS
proxy for the terminals.
• Layer 2 point-to-point traffic leaves the Dialog system by means of the L2DEM. The L2DEM
provides layer 2 forwarding to and from remote terminals for layer 2 point to point connections.

Return Link
The HRCCTL is responsible for:

• Controlling the dynamic behavior of the HRC return technology.
• Instructing the demodulator every second about the expected changes in symbol rate, carrier
frequency and MODCOD for every terminal in the next upcoming physical layer frame.
• Sending the return link layer 2 signaling (destined for the remote modem) to the CSE.
• Sending the HRC related layer 2 signaling back to the remote modem via the MOD or modulator.
• Informing the remote modem about the result of the processed ACM feedback.
4.5 NxtGen Mx-DMA MRC

Next Generation Multiple Dimension Division Multiple Access - Multi Resolution Coding or
NxtGen Mx-DMA MRC is a Next Generation, flexible satellite return technology.
NxtGen Mx-DMA access technology cross-correlates and assigns frequency, symbol rate, power,
modulation and coding rate, transmission length and code length in real-time, based on the return
traffic demand, QoS management parameters and channel conditions. Therefore, designing a
NxtGen Mx-DMA MRC link does not require precise knowledge of the traffic and terminal mix as the
link self-optimizes in real-time. The high efficiency enables bandwidth savings, higher throughput,
better network availability, and substantial terminal cost savings.
NxtGen Mx-DMA MRC works with a flexible time-frequency plan. Terminals are assigned
transmission slots within the time-frequency plan. Slots of terminals with high capacity can be
grouped, decreasing synchronization overhead and optimizing the transmission. Thanks to that,
NxtGen Mx-DMA MRC offers very efficient return frequency usage with high order constellation and
high spectral efficiency.
Customers are served with a single return link for the majority of their use cases, minimizing
operational complexity and maximizing statistic multiplexing.

Return Link
4.5.1 MRC Return Link End-to-End

Following functional blocks are involved in the MRC return end-to-end link:
At high level, user and control traffic follow these steps:

1. Traffic comes from the host behind the terminal and enters the remote terminal via its LAN
interface. The remote terminal is responsible for:
– Classifying and applying marking on incoming data (received on its LAN port).
– Encapsulating data into baseband frames. For more information, refer to
Encapsulation and Coding on page 51.
– Applying MRC modulation.
– Requesting time slots.
2. The traffic travels over the satellite link to the hub module and enters the DEMOD. The
demodulator is responsible for:
– Demodulating the MRC bursts and forwarding the encapsulated data to the DCP.
– Sending MRC modulation statistics and metrics towards the MRCCTL.
3. The DCP or decapsulator decapsulates the datagrams and it is responsible for:
– Decapsulating the GSE datagrams.
– In case of layer 3 and layer 2 unicast traffic, it forwards the IP packets to the TAS.
– In case of layer 3 multicast traffic, the IP traffic is sent to the uplink VLAN dedicated to
terminal multicast of the satellite network.
– Forwarding MRC return signaling to the MRCCTL. The signaling includes return link
capacity requests and ACM feedback from the terminals.
4. The TAS is responsible for:
– Forwarding the layer 3 IP traffic to the DEM, where it will leave the hub module over a
dedicated VLAN per subnet.
– Forwarding the layer 2 traffic to the L2DEM, where it will leave the hub module over a
dedicated VLAN per VC.
5. Unicast traffic leaves the Dialog system via the demarcation service:
– Layer 3 unicast traffic leaves the Dialog system by means of the DEM. The DEM provides
layer 3 forwarding (routing) of traffic to and from remote terminals for layer 3 networks
(VRFs). Its routing tables are updated with static configuration, OSPF or BGP.
– Layer 2 point-to-point traffic leaves the Dialog system by means of the L2DEM. The
connections.

Return Link
6. Feedback of the link state is sent back to the terminal:

– The MRCCTL estimates the condition of the channel through data sent by the DEMOD,
and offers per active terminal a feasible Transmission Mode or TxMode list to the
Scheduler.
A TxMode is a combination of possible time-frequency ranges, symbol rates, power,
modulation and coding rate, transmission length and code length.
The Scheduler is a sub-system of the MRCCTL which responds to the demand of traffic
from the terminals and generates a Burst Plan per terminal every per 40 ms.
A Burst Plan is a combination of one chosen TxMode for each terminal which optimizes the
usage of the link while guaranteeing a fair distribution of the allocated resources. After the
Scheduler calculates the burst plan, it informs it to the CSE.
The explained process can be observed in the following image:
– The CSE is responsible for inserting the burst plan info into the forward signaling and
sending it back to the modem.
4.5.2 Encapsulation and Coding

Traffic that comes from the host behind the terminal and enters the remote terminal in its LAN
interface is encapsulated into baseband frames and later coded in order to be sent through the RF
interface.
Encapsulation follows the Generic Stream Encapsulation or GSE standard, which provides a generic
way to encapsulate variable length data, for example an IP packet, into baseband frames.
applied in case of unfragmented PDU.

Return Link
After encapsulation, the baseband frames are coded. In Multi Resolution Coding or MRC, multiple
channel coding options are available per setting. The MRC Controller or MRCCTL chooses the
optimal structure of a burst for each demand:
• FEC word size. The selection of the optimal FEC word depends on the payload size of each
transmission. FEC words of 1024 and 3024 bits are supported.
• Pilot distribution. The transmission of pilots is necessary to allow the demodulation at the
receiving site. The number and distribution of pilots depends on the C/N0 and the symbol rate for
each transmission. For example, in the case of terminals with large demands, higher symbol rates
are used, therefore, fewer pilots are needed, which results in lower overhead.
• Synchronization preamble structure. The synchronization preamble structure is also dependent
on the C/N0. The bigger the C/N0, the smaller synchronization overhead is needed.
• BUC guard time overhead. The length of the guard time is always 100 us.
4.5.3 Channel Access

In NxtGen Mx-DMA, the return link capacity is divided in time and frequency. Terminals are assigned
transmission slots, which they use to send data. This assignment is scheduled in a Time-Frequency
Plan, which is calculated by the MRC Controller or MRCCTL, based upon capacity requests from
the terminals, QoS parameters and channel conditions. The MRCCTL is a virtual machine in the
hub.
In the image below, a time-frequency plan example of a NxtGen Mx-DMA MRC signal is visualized.
Each NxtGen Mx-DMA MRC frame of 40 ms is divided into time slots of 5 ms. Each 5 ms slot
contains multiple segments. A segment is a portion in the frequency domain. Hence, two different
segments can have the same time duration but a different frequency bandwidth.

Return Link
A transmission slot from a terminal is denoted a burst. The shortest burst duration is the slot
duration.
This time-frequency usage per terminal is very adaptive and it can adjust to the characteristics of the
traffic:
• In the case of bursty traffic (T2 and T3 in the image), terminals transmit in time-frequency slots.
The duration of the burst is a multiple of a slot duration.
• In case of continuous traffic (T1 in the image), bursts can be expanded in time, avoiding the use
of multiple slots, and as a consequence, decreasing overhead. This is especially useful for
services which require low jitter. For example, mobility application and cellular backhaul.
Terminals which are not transmitting do not get any bandwidth allocated. Therefore, there can be
slots where no traffic is present. This flexible frequency grids prevents stuffing overhead. The carrier
size that can be allocated to a transmitting terminal is between 110 kHz and 20 MHz.
The frequency ranges assigned are the ones within the Return Capacity Group or RCG.
For more information about RCGs, refer to the Configuration User Guide.
NxtGen Mx-DMA MRC avoids padding of bursts. In order to fit any payload length in this granular
time grid without padding, different symbol rates can be chosen.
4.5.4 Performance
Designing a NxtGen Mx-DMA MRC link does not require precise knowledge of the traffic and
terminal mix as the link self-optimizes in real-time. The high efficiency enables bandwidth savings,
higher throughput, better network availability, and substantial terminal cost savings. For each
terminal, a TxMode is chosen. A TxMode is a combination of possible time-frequency ranges,
symbol rates, power, modulation and coding rate, transmission length and code length. The
combination of all TxModes for each terminal is called Burst Plan. The burst plan optimizes the
usage of the link while guaranteeing a fair distribution of the allocated resources.
The following graph represents the efficiency in bits/Hz of an NxtGen Mx-DMA link per throughput
request (bits/slots) for different Signal-to-Noise ratio points of operation. Additionally, the Shannon
bound is show for each point of operation. Optimal efficiency is achieved only for higher throughput.
For low throughput, the overhead is more important and efficiency grows with throughput demand.
This also means that optimal efficiency is achieved for the bigger carriers and those typically

Return Link
consume the larger part of the total allocated spectrum. For different bandwidth usage options, given
the requested throughput, the resulted efficiency of the link is can be found.
The following graph displays the FEC efficiency (in bits per symbol) per EsNo (in dB) for an NxtGen
Mx-DMA link in ideal conditions, at the operational threshold (at FEC error rate of 10^-3), therefore it
shows the minimum efficiency per MODCOD. Each dot represents a TxMode's MODCOD. Orange
dots represent transmission modes with FEC size of 1k, while blue dots represent transmission
modes with FEC size of 3k.

Return Link
For a detailed calculation of the suitable MODCOD in a specific link, use the Satellite
Network Calculator. The Satellite Network Calculator allows to calculate the relation
between bandwidth, symbol rate and info rate of a carrier and shows the thresholds
which must be achieved in the link to be able to maintain a certain MODCOD.

Quality Of Service
5 Quality Of Service
Quality of Service or QoS refers to the ability to differentiate traffic types with the objective to apply
different policies to the different service flows running through a network.
Nowadays, with the increasing trend of convergence towards all-IP networks, ensuring QoS is
particularly critical. A correct definition and application of QoS policies provides the end-user a
greater Quality of Experience or QoE.
Dialog takes the following criteria into consideration to provide quality support:
• Speed
• Accuracy
• Availability
• Reliability
• Security
• Simplicity
• Flexibility
This chapter describes the management of packets according to their service’s speed (latency and
jitter) and reliability (packet drops) requirements.
In Dialog QoS is a process which handles packets in five different steps, as shown in the image
below.
To maximize the quality of experience of the end-users, different services must get different policies
applied. Classification is therefore required to organize traffic into traffic categories.
In the table below examples of services are mapped into their best suited traffic classes.

Quality Of Service
Service Traffic Class Description
VoIP telephony Real Time Telephony has a maximum tolerable

latency and jitter, while it is immune to
certain packet loss, therefore, VoIP
traffic must be classified as Real Time
Transactional Data and Critical Data In transactional data, while certain

bulk data delay and jitter is permitted, no packet
loss is allowed, therefore, it must be
classified as Critical Data
Non-critical data Best Effort Non-critical data can be handled

without priority, therefore, it can be
classified as Best Effort
Ingress traffic is classified into different classes basing on rules. These rules are a set of one or more
defined criteria, depending on the type of traffic.
For layer 3 traffic, the criteria can be:
• DSCP value
• Protocol used
• Source or destination port
• Source or destination IPv4 or IPv6 address range
• Network service label
For layer 2 traffic, the criteria can be:
• DSCP value
• Priority Code Point value
• VLAN tag
• Layer 2 VC group ID
5.1 Marking
After classification, ingress traffic is marked. The Dialog system supports marking based on
Differentiated Services or DiffServ. DiffServ is a method to mark packets in their 6-bit
Differentiated Services Code Point or DSCP field in the IP header. Each tag corresponds to a Class
of Service or CoS. Packets with the same CoS have the same QoS policies applied in the network
nodes.
Marking can be done inside the Dialog system or by an external device, for example, a packet
shaper.
The marking policy is set in a classification profile. The terminal is configured with a forward and
return ingress classification profile during terminal provisioning.
Two types of policies exist:
1. Transparent policies. Already marked incoming traffic passes through the Dialog system
without any modification, as shown in the following image.

Quality Of Service
2. Mark policies. Unmarked incoming traffic is marked by the Dialog system based on the DSCP
settings.
5.2 Mapping
Once packets are classified and marked, they are mapped into different QoS classes. In Dialog the
following QoS classes with their specific priority are defined:
QoS Class Priority Description
Real Time 1 (RT1) First absolute priority Intended for traffic that requires
very low delay and jitter. Traffic
Real Time 2 (RT2) Second absolute priority profiles for real-time traffic are
typically tailored in such a way that

Quality Of Service
Real Time 3 (RT3) Third absolute priority the quality of service of these
selected uses is guaranteed, or at
least prioritized over other classes
of traffic.
Critical Data 1-14 (CD1-14) (1) Fifth absolute priority Intended for traffic that requires low
(2)(3) delay and loss. Such traffic profiles
are also tailored to guarantee and
prioritize data, but its priority is
lower than real-time traffic. There
are up to 14 critical-data traffic
classes depending on the used
shaping model and return
technology. All CD classes have
equal priority but can be
differentiated by their individual
weight.(4)
Best Effort (BE) Lowest priority Intended for traffic that does not
require prioritization or guarantees.
Therefore, such traffic is treated
with the lowest priority. (5)
(1) CD4..14 are only supported in a transport-based shaping model and when using return link
technologies MRC, HRC and S2. For more information about the transport-based shaping model,
refer to Shaping on page 60.
(2) Aggregation Nodes or AG also have the fifth absolute priority.
(3) Priority 4 is for internal management.
(4) For RT QoS classes the weight parameter has no impact. Weights are meaningful when the QoS
classes have the same priority, for example for CD1-14 classes. RT1, RT2 and RT3 have different
priorities.
(5) BE is the default QoS class.
TCP acceleration and header compression can be enabled per QoS class to achieve
higher throughputs. The QoS model is not impacted by the acceleration and
compression mechanisms. For more information, refer to Network Layer Optimization .
If TCP and non-TCP traffic is combined in one QoS class, the TCP traffic will always
have the highest priority.
5.3 Queuing
Once packets are tagged with their QoS class, they are stored into a queue until they can be further
processed. Queues are susceptible to congestion. Congestion occurs, for example, when the traffic
entering the queue is greater than the one leaving the queue.
Dialog’s QoS provides mechanisms to queue traffic with higher priority over traffic with lower priority.
Therefore, packets with the highest priorities are not dropped in case of congestion.
Each QoS class has a queue size and time. The queue time or shaping timeout is configurable.
QoS Class Max. Queue Size Queue Time
Forward Return Forward Return

Quality Of Service
Real Time 1, 2 50 MB 2.56 MB 50 ms 90 ms
Real Time 3 50 MB 2.56 MB 50 ms S2: 200 ms

4CPM: 2 s
HRC: 400 ms
MRC: 400 ms
Critical Data 1..14 2.56 MB 2.56 MB 200 ms S2: 200 ms

4CPM: 2 s
HRC: 400 ms
MRC: 400 ms
Best Effort 2.56 MB 2.56 MB 200 ms S2: 200 ms

4CPM: 2 s
HRC: 400 ms
MRC: 400 ms
The queue time can be set for QoS class and terminal, and in the forward and return link
with the Packet Shaping Timeout parameter during Service Profile configuration.
The queue is filled with packets depending on the data rate of the customer application,
but the packets are queued only for the Packet Shaping Timeout time, and up to the
maximum queue size in MB stated above. Therefore, for applications with data rate that
exceeds the queue size and time, excess packets are dropped.
5.4 Shaping
After queuing the packets, a shaping process takes place. Shaping is a technique that is used to
enforce different bit rate to guarantee performance, improve latency or increase the usable
bandwidth.
In Dialog, shaping is managed in a hierarchical way and can be represented by a shaping tree in
both the forward and return link.
The root of the forward shaping tree corresponds to the entire satellite network for the forward link.
The root of the return shaping tree corresponds to the return capacity group.
The root pool is divided in one or more child nodes or forward/return pools. The type of pool defines
the shaping model. Two types of pools exist:
1. Class-based: In a class-based service offering, the service provider offers applications to
customers.
A class-based pool is divided in QoS pools. On the individual terminal level, the applications are
classified and mapped to QoS classes and these are shaped according to the terminal's service
profile and the individual QoS class priority.
The class-based service profile defines the shaping settings of the QoS classes. The service
provider will typically prioritize the higher priority applications but also protect the lower priority
applications from being starved. A part of the satellite resources needs to be reserved for such
class-based services.
2. Transport-based: In a transport-based service, customer traffic is modeled as a bandwidth pipe
that has a committed rate, sometimes burstable to a higher rate.
Terminals are directly linked to the forward/return pools and contention happens between
terminals and not between applications.
Prioritization of customer hosted applications is managed within the bandwidth pipe by the
customer himself using the terminal's service profile and the individual QoS class priority. The

Quality Of Service
transport-based service profile defines the shaping settings of the terminal circuit and the
individual QoS classes.
The forward/return pools can be dedicated to a VNO or shared between VNOs.
The shaping tree for both shaping models is represented in the following image.
Five different shaping levels can be distinguished:

1. Shaping Level 1: This represents the total capacity. For the forward link this corresponds to the
entire satellite network; for the return link this corresponds to the return capacity group.
2. Shaping Level 2: The total capacity is divided over forward/return pools. This level also
represents the forward multicast pool, if configured, and the
HRC Mx-DMA and MRC NxtGen Mx-DMA free capacity pool on page 62.
3. Shaping Level 3: In class-based pools, this represents the QoS pools. In transport-based
pools, this represents the terminal circuits. In case of a multicast pool, it represents the multicast
circuits.
4. Shaping Level 4: This represents the QoS classes.
You can use three critical-data classes (CD1..3) in the class-based shaping model
and in the transport-based shaping model with return link technology MF-TDMA
4CPM. You can use 14 critical-data classes (CD1..14) in the transport-based shaping
model with return link technologies Mx-DMA HRC and NxtGen Mx-DMA MRC.
5. Shaping Level 5: In a transport-based shaping model, a fifth level is allowed: CD Aggregation

Node. This node allows to aggregate two or more CD classes. The CD classes inside the node
compete for bandwidth and the aggregation node competes with the QoS classes outside the
node for bandwidth.
In a class-based service offering, terminals are linked to QoS pools. In a transport-based service
offering, terminals are linked directly to the transport-based pool. In the class-based setup terminals
are at shaping level 4 and in the transport-based setup terminals are at shaping level 3.
Configuration and Parameters

In Dialog, the shaping model is configured in forward and return QoS plans and terminal service
profiles. The QoS plan specifies the forward/return pools and the class-based QoS pools. The
service profile specifies the QoS classes and terminal circuits. Terminals are linked to a service

Quality Of Service
profile and to forward and return resources during terminal provisioning. The type of service profile
determines which forward and return resources can be assigned: you can only select
transport-based forward and return pools with a transport-based service profile and class-based
forward and return pools with class-based service profiles.
The parameters that are used to control the use of bandwidth at the different shaping levels are:
• PIR: The Peak Information Rate or PIR is the maximum unicast traffic rate.
• CIR: The Committed Information Rate or CIR is the guaranteed or minimum unicast traffic rate.
The Committed Information Rate can be overbooked, meaning that the sum of all CIR values of
the child nodes exceeds the CIR value of the parent node.
• Weight: The weight is an integer value between 1 and 1000 and is used to define the Total
Weight, which equals PIR * Weight. The total weight is used to distribute the available bandwidth
among nodes at the same level and with the same priority.
• Priority (static): Priority is defined by the traffic type.
– RT1 = priority 1
– CD1..14 = priority 5
– BE = priority 6
– MGMT (management) = Priority 4
• Shaping Volume (dynamic): This is the actual capacity need of a terminal. The capacity requests
are triggered by the ingress traffic on the modem's LAN interface.
For more information about the shaping configuration and parameters, refer to the
Newtec Dialog Configuration User Guide.
HRC Mx-DMA and MRC NxtGen Mx-DMA Free Capacity

In case of MRC NxGen Mx-DMA and HRC Mx-DMA, you also have a free capacity pool at shaping
level 2. This free capacity is the capacity of the MRC NxtGen Mx-DMA or HRC Mx-DMA return
capacity group that is left after the capacity requests of all terminals have been fulfilled. The
distribution of free capacity can be enabled or disabled. When enabled, the MRC or HRC controller
hands out the free capacity and a terminal can get more bandwidth than requested. The terminal can
even get more capacity than its configured PIR as the free capacity is not taken into account for PIR.
When disabled only the requested capacity is distributed and any remaining capacity in the return
capacity group is not used and therefore lost. Free capacity distribution is by default enabled.
The free capacity pool has a CIR equal to 0 Mbps and has a configurable PIR between 0 and 250
Mbps (default value is 150 Mbps). The pool has lower priority (priority 99) than the class-based and
transport-based pools (priority 0).
Shaping Process
The allocation of bandwidth happens in two phases:
1. Phase 1 - Distribute all configured CIR values.
2. Phase 2 - Distribute all configured PIR values.
During these phases, weight and priority are taken into account.
Additionally a Phase 0, during which the requested rates are calculated, can be added to the
process.

Quality Of Service
The allocation mechanism applies a top-down method. For example, in a class-based shaping
model, first the CIR at root level gets attributed, then the CIR value at pool level, then the CIR at
QoS pool level and finally the CIR values at terminal level. If there is still capacity left, the controller
distributes capacity based upon PIR values.
In the following chapters, the process for a transport-based and class-based shaping model is
detailed.
5.4.1 Transport-based Shaping
Phase 0 - Requested Rate Calculation

The requested rates are calculated bottom up, from QoS classes per terminal to the pools.
• For transport-based service pools
1.
2.
where n i is the number of terminals with service profile i.
• For aggregation nodes
1.
2. The requested rate of the aggregation node can be clipped by the peak rate, where:
Phase 1 - CIR Allocation

The maximum allocated rate for each node is the minimum of its requested rate and its CIR. CIR
distribution takes priority of the traffic types into account.
1. For RT1
2. For RT2
3. For RT3
4. For all the CD classes and AG nodes

Allocation to the CD classes inside each aggregation node is proportional to their weight, it goes
up to their configured CIR, and it is fed by the allocated rate to the parent aggregation node.

Quality Of Service
The classes and children nodes are filled simultaneously with a flow rate that is proportional to
the weight factor of each class and child bucket. This means that if
and , then, Child2 will be filled
twice as fast as Child1.
If a class or child bucket reaches its requested rate or its CIR level level, it permanently stops
being filled and the remaining parent rate can be distributed over the other classes or children.
5. For BE
Phase 1 ends in case of one of the following scenario:

• All child buckets reach their CIR level or their requested data rate.
• All available parent rate is depleted. This case is defined as CIR overbooking, since not enough
rate can be allocated to reach all CIR levels
Phase 2 - PIR Allocation

The maximum allocated rate for each node is the minimum of its requested rate and its PIR. The
calculation is done as follows:
• For RT classes
• For CD classes and AG nodes

Allocation to the CD classes inside each aggregation node is proportional to their weight, it goes
up to their configured PIR and it is fed by the allocated rate to the parent aggregation node.
The classes and children nodes are filled simultaneously with a flow rate that is proportional to
the weight factor of each class and child bucket. This means that if
and , then, Child2 will be filled
twice as fast as Child1.
If a class or child bucket reaches its requested rate or its PIR level level, it permanently stops
being filled and the remaining parent rate can be distributed over the other classes or children.
• For the BE node
5.4.2 Class-based Shaping
Phase 0 - Requested Rate Calculation

The requested rate of a pool is calculated as it follows:
1.

Quality Of Service
2.
where n i is the number of terminals with service profile i.
Phase 1 - CIR Allocation

The available rate in the QoS classes must first be calculated at the level of the class-based service
pool. This is done in the following order:
1. RT1 rate is allocated.
2. The remaining rate goes to RT2 CIR.
3. The remaining rate goes to RT3 CIR.
4. The remaining rate goes to CD CIR.
5. The remaining rate goes to BE PIR, clipped by the CIR.
Phase 2 - PIR Allocation

Once the allocated rates for the QoS Classes at pool level are calculated, it is possible to calculate
the corresponding allocated rate per terminal to the QoS classes of the child class-based service
profiles.

Quality Of Service
This is visualized in the diagram above, where class-based Pool 1 calculated allocated rates are
known, and the class-based Profile 1 and 2 QoS classes allocated rates need to be calculated. This
is done according to the following rules:
• For RT classes
Data rates are distributed over all the profiles with .

As each class-based profile takes into account the number of terminals, the RT CIR values that
are provided as input for the per profile RT buckets need to be multiplied with the number of
terminals. This increases the weight factor for profiles that consist of more terminals.
• For CD classes
Allocated CD data rate is shared over all the profiles, taking into account the weight factors of
the CD classes across the profiles.
This is done by using the allocation mechanism described before, taking into account the profile
weight factors, the number of terminals in each profile and the weight factors of the CD buckets.
, where n i is the number of

terminals with profile i.
• For BE class

Quality Of Service
Allocated BE data rate is shared over all the profiles, taking into account the weights of the BE
classes of the individual profiles.
This is done by using the CIR/PIR allocation mechanism described above, taking into account
the profile weight factors, the number of terminals in each profile and the weight factors of the
BE buckets,

Satellite Link Optimization
6 Satellite Link Optimization
6.1 Equalink®
Equalink® is a linear and non-linear pre-distortion technology for DVB-S, DVB-S2, and DVB-S2X.
Equalink is a set of advanced digital filters and algorithms implemented in the modulator. The linear
filter compensates for group delay and frequency response imperfections of the satellite input
multiplexer (IMUX), while the non-linear pre-correction compensates for the combined effect of
matched filters and transponder Travelling Wave Tube Amplifier (TWTA) non-linearities (AM/AM and
AM/PM conversions).
This pre-correction improves the performance of the end-to-end satellite communication channel
and allows the use of higher modulation schemes on carriers occupying a full transponder. This
extra link margin can be used to improve the coverage/availability or it can be used to increase the
symbol rate in combination with a lower roll-off factor.
For a communication channel over a satellite link, the overall link performance can be severely
degraded by channel impairments, such as:
• Adjacent Channel Interference and Co-Channel Interference
• Inter-Modulation
• Adjacent Satellite Interference
• Phase noise
• Signal distortion
The Equalink concept effectively optimizes satellite link performance by counteracting these effects.

Linear distortions are typically compensated by the demodulator equalizer on most

modern demodulators. Older demodulators with less good equalizer specs can suffer
from linear distortion. Linear Equalink is only used to optimize a broadcast network with
old demodulators.
For more information about activating Equalink, refer to the Newtec Dialog
Configuration User Guide.

6.2 Clean Channel Technology®

Clean Channel Technology® is a combination of improved roll-offs for DVB-S2(X) (ability to select
5%, 10% or 15% roll-off) and advanced filtering technologies to allow optimal carrier spacing.
The occupied bandwidth of a carrier is defined as symbol rate*(1+roll-off factor). The smaller the
roll-off factor, the higher the symbol rate for the same occupied bandwidth. Standard roll-off values
for DVB-S2 are 20%, 25% or 35%.
During modulation side lobes are created which cause Adjacent Carrier Interference (ACI).
The advanced filtering reduces the side lobes and consequently the ACI as well, allowing to apply
reduced channel spacing. Note that with the same power, the power density will decrease. When
power is increased to achieve the same power density, the used PEB (Power Equivalent Bandwidth)
is increased.

In a Dialog system, Clean Channel Technology® is enabled by default which further improves
satellite efficiency by up to 15% compared to the current DVB-S2(X) standard.
6.3 Adaptive Coding Modulation

Data transferred via a satellite is modulated and coded at the sending side and demodulated and
decoded at the receiving end. Each combination of a specific modulation and coding has a certain
spectral efficiency determining the data throughput, or the rate at which data can be transmitted.
A high MODCOD is linked to a high data rate but requires a good signal-to-noise ratio at the
receivers end. A low MODCOD will work even with a lower signal-to-noise ratio, but at the cost of
having a lower data rate. The spectral efficiency refers to the amount of information that can be
transmitted over satellite in a given bandwidth: the larger the spectral efficiency, the more
information that can be sent over the satellite link in the same bandwidth. For example: MODCOD
32 APSK-5/6 has a spectral efficiency of 4.12 (bits/s)/Hz while MODCOD QPSK-1/4 has a spectral
efficiency of 0.49 (bits/s)/Hz.
The circumstances in which satellite connections are active can change all the time, due to for
example changing weather conditions.
The classic satellite transmission approach always includes a margin in order to overcome
attenuations introduced by atmospheric circumstances. This margin consumes a substantial amount
of satellite bandwidth and power that cannot be used for sending useful information over the satellite
transmission link. Traditionally when dimensioning a satellite link, one has to take into account the
average and extreme conditions at the transmission sites and the acceptable probability of losing the
signal due to fading. The transmission power and the level of error correction overhead are selected
accordingly, so that the signal-to-noise ratio remains above the minimum threshold (indicated as
"Legacy Bandwidth" in the figure below) that guarantees an error-free transmission for a time
defined by the target availability of the link budget. This means that most of the time, when the
weather is clear, the signal to noise-ratio is well above the minimum threshold. During this period, the
additional margin corresponds to a significant portion of the available data throughput that is wasted
with unnecessary error correction overhead.
Adaptive Coding and Modulation or ACM allows modification of the modulation parameters of a
satellite signal on the fly, without interrupting the transmission and without losing data. When
combined with a measurement of the instantaneous link conditions every few seconds and a system
that automatically adjusts the modulation parameters when needed, ACM allows using the highest
possible modulation scheme and the lowest possible level of error correction at all times. In some

instances the amount of data that can be transmitted in a given satellite segment can be doubled (on
average) compared to a fixed modulation system (Constant Coding and Modulation or CCM).
The Dialog system also contains some additional technologies which optimize the satellite link even
more. These technologies are:
• Cross Layer Optimization Through Cross-Layer-Optimization the satellite modulation equipment
is in continuous interaction with acceleration, compression, bandwidth management and IP
shaping technology. As soon as a satellite link condition changes, the link will be auto-optimized
following Quality-of-Service and priority settings without the loss of data or link.
• Thin Margin Manager (ThiMM) ThiMM provides an accurate prediction of the upcoming variation
(depth and direction) of the link condition. Prediction uses mathematical filters on the margin and
is determined over very short time periods. As a result, the excess link margin can be kept to the
absolute minimum and further increase the efficiency of the link (on top of DVB-S2 ACM).
ThiMM and Cross Layer Optimization are enabled by default on a Dialog system.
6.3.1 ACM in the Forward

The Dialog forward link is designed to work in ACM mode and uses the following parameters:
• Reference Threshold (THR)
This is a fixed Es/No value as defined in the DVB-S2 standard which is stored in the remote
terminal.
• Distortion Margin (DM)
Extra margin used in case of non-linear degradation.
• Modulation Loss (ML)
Extra margin to counter the modulation loss.
• Forward ACM In
Minimum margin above the THR, which is required before it is possible to start using the
MODCOD.

• Forward ACM Down

Minimal acceptable margin for which it is still allowed to use the MODCOD.
DM+ML, Forward ACM In, and Forward ACM Down are configurable via the Forward Link web
interface in NMS. This allows the operator to determine how close the system is operating to the
thresholds. By adjusting these margins, the operator can optimize the system either for higher
efficiency (= smaller margins) or for less frame errors (= higher margins).
The default values of the parameters are carefully chosen in the Dialog system. We
strongly advise to keep the default values.
Based on the ACM parameters, the terminal calculates two reference Es/No values:
• Es/No_IN = THR + Forward ACM In + (DM+ML)
• Es/No_DOWN = THR + Forward ACM Down + (DM+ML)
These reference values are used to decide when to move up or down to another MODCOD. The
terminal requests a higher MODCOD when its measured Es/No > Es/No_IN. The terminal requests a
lower MODCOD when the measured Forward Es/No < Es/No_DOWN.
It can occur that there are intermediate MODCODs when moving to another MODCOD. When
moving to a lower MODCOD, the intermediate MODCODs are skipped and the terminal immediately
uses the lowest MODCOD. When moving to a higher MODCOD, the modem skips all MODCODs for
which the measured Es/N0 is at least 2 dB higher than the Es/N0_IN value. From then on it
increases the MODCOD step by step, meaning that all remaining intermediate MODCODs (with an
Es/N0_IN value < measured Es/N0 + 2 dB) are used before reaching the highest MODCOD.
For individual terminal installations, there can be link degradation at higher MODCODs which is not
known to the ACM algorithm. For example, when WiMax signals at the terminal location are present
or when the used frequencies (typically C-band) are close to other mobile applications.
ACM implements two solutions to face unpredictable distortion:
• Reactive behavior based on baseband frame drops
For each available MODCOD the terminal monitors the errored baseband frames. Errored
baseband frames are dropped at the modem's decoder. A MODCOD becomes 'unavailable'
from the moment that errored frames occur and will remain 'unavailable' 120 seconds after the
last errored frame occurred.

When the modem notices a baseband frame drop for the MODCOD it has selected according to
the ACM algorithm described above, it will select a lower and error-free MODCOD. An error-free
MODCOD is a MODCOD where there has not been an errored baseband frame in the last 120
seconds.
The mechanism is explained in the example below.
In the example we assume that, according to the ACM algorithm, the modem is able to use
MODCOD 4. We also assume that at some point in time a local source of distortion appears,
which degrades the forward link quality for the modem.
Due to this link degradation, MODCOD 4 starts showing errored baseband frames. This triggers
the modem to select a lower error-free MODCOD. As MODCOD 3 also has errored baseband
frames, the modem selects MODCOD 2. The modem keeps on using this MODCOD as long as
there are no errored frames and the higher MODCODs are not error-free. In this example the
link degradation gets worse and starts affecting MODCOD 2 as well. MODCOD 2 shows errored
frames and the modem selects a lower error-free MODCOD, which is MODCOD 1. The modem
keeps on using this MODCOD as long as there are no errored frames and the higher
MODCODs are not error-free. After some time the link degradation is less severe and
MODCOD 2 is considered error-free, meaning that the last errored frame occurred 120 seconds
ago. The modem moves up from MODCOD 1 to MODCOD 2 and uses that MODCOD as long
as there are no errored frames and the higher MODCODs are not error-free. When the source
of distortion disappears, MODCOD 3 and 4 are considered error-free after 120 seconds the last
errored frame occurred. When that happens the modem moves from MODCOD 2 to the highest
error-free MODCOD, which is in this case MODCOD 4 and thus skips MODCOD 3.
This baseband frame-aware ACM behavior is only supported on the modem

10-series.
• Static limit on the maximum modulation and coding

The terminal can be provisioned with a maximum MODCOD. The maximum MODCOD is
selected from the MODCOD list, which is ordered according to the ideal Es/N0 threshold, as
specified in the DVB-S2(X) standard. The configuration of the maximum MODCOD implies that
the modem will not use any MODCOD that has an ideal Es/N0 threshold higher than the one of
the maximum MODCOD. The maximum MODCOD for the modem is signaled in the POP-ID of
the FTB and in the POP-ID descriptor of the mobility TIM.
If the defined maximum MODCOD is lower than the lowest MODCOD specified in the
ACM signaling, the modem will select the latter MODCOD.

6.3.2 ACM in the Return
DVB-S2 and S2 Extensions

You can enable or disable ACM for DVB-S2 or S2 Extensions SCPC during terminal provisioning.
By default it is disabled.
Following DVB-S2 ACM parameters are used:
• Min/Max ModCod: The minimum and maximum MODCOD that can be used within the return
capacity group.
• ACM Margin: This is an extra margin to add on top of the nominal MODCOD threshold, which is
used to determine when to switch to another MODCOD. It is advised to set it to 0 dB in case
efficiency is more important than robustness.
HRC
ACM is always enabled for HRC Mx-DMA return capacity groups. ACM can be enabled or disabled
for the HRC SCPC return capacity group. It is disabled by default.
You can define the following ACM parameters:
• Min/Max ModCod: The minimum and maximum MODCOD that can be used within the HRC
return capacity group.
• Static Margin: This is an extra margin to add on top of the nominal MODCOD threshold, which is
• Error Performance Objective: This reflects the mean time between errored seconds in the
return link. In case error-free (robust) link is required, select the highest value together with a
static margin of e.g. 2 dB.
Several MODCODs are available to handle very low SNR link conditions which can
occur, for example, in airborne mobile communication situations. The name of these
MODCODs ends in "-SFx" where x is a number. For example: QPSK9/20-SF2.
Next to setting the minimum and maximum MODCOD per HRC return capacity group, it is also
possible to set the maximum MODCOD on a terminal level.
You can also set the minimum and maximum symbol rate on a terminal level when operating in
HRC Mx-DMA. This is interesting for terminals operating with VL-SNR or for keeping terminals which
suffer from phase noise (due to BUC frequency instability for example) under control.
• Max Symbol Rate: Controls the maximum satellite bandwidth usage of a terminal and reduces the
impact on other terminals within the return capacity group. This is relevant for terminals operating
with very Low SNR feature (down to -10 dB). A terminal with a very robust MODCOD (or a very
low SNR MODCOD) can consume a large amount of bandwidth (in order to keep its configured bit
rate or CIR), resulting in large carriers / symbol rates. This impacts other terminals that are using
the same Return Capacity Group. The parameter is set in the service profile and a service profile
is linked to a terminal during terminal provisioning.
• Min Symbol Rate / Max ModCod: Terminals suffering from phase noise have a high packet error
ratio value. Limiting the maximum MODCOD or increasing the minimum symbol rate of such a
terminal, can decrease the packet error ratio value. These parameters are set during terminal
provisioning.

MRC
ACM is always enabled for MRC NxtGen Mx-DMA return capacity groups.
You can define the following ACM parameters:
• Min/Max ModCod: The minimum and maximum MODCOD that can be used within the MRC
return capacity group.
• Static Margin: This is an extra margin to add on top of the nominal MODCOD threshold, which is
• Error Performance Objective: This reflects the mean time between errored seconds in the
return link. In case error-free (robust) link is required, select the highest value together with a
static margin of e.g. 2 dB.
Next to setting the minimum and maximum MODCOD MRC return capacity group, it is also possible
to set the following parameters on a terminal level:
• Max Symbol Rate: Controls the maximum satellite bandwidth usage of a terminal and reduces the
impact on other terminals within the return capacity group. The parameter is set in the service
profile and a service profile is linked to a terminal during terminal provisioning.
• Min Symbol Rate / Max ModCod: Terminals suffering from phase noise have a high packet error
ratio value. Limiting the maximum MODCOD or increasing the minimum symbol rate of such a
terminal, can decrease the packet error ratio value. These parameters are set during terminal
provisioning.

6.4 Adaptive Return Link

Adaptive Return Link or ARL is used in the MF-TDMA 4CPM return link technology and assigns
terminals to a return link carrier with symbol rate and MODCOD, which are appropriate for the
terminals' link condition
ARL uses a dynamic margin, which is dependent on the number and age of the C/N0 samples in the
return link. Measurements based on fewer or aged samples have a higher uncertainty and will
therefore result in a higher margin. This dynamic margin is configured via the ARL states.
For each ARL state it is possible to define:
1. Kalman gain K (averaging factor)
2. Margin for covering C/N0 measurement uncertainty
3. Min Interval (in superframes) for going up to next lower state
4. Max interval (in superframes) for going down to next higher state
We recommend using the default values.
A Return Carrier Pool also has a minimum and maximum C/N0 defined.
C/N0,min and C/N0,max depend on following values:
• System margin, typical values are:
– C-band: 0.5 dB
– Ku-band: 1 dB
– Ka-band: 1.5 dB
• C/N,allowed: C/N achieved for carrier with maximum allowed PSD (PEB = allocated BW), as
derived from link budget.
• C/N0,threshold: fixed specifications of a demodulator.
And should be calculated as follows:
• C/N0,min = C/N0,threshold + system margin + 0.5 dB
• C/N0,max = min{C/N0,min + 3 dB , C/N,allowed + 10log(carrier spacing)}

A terminal will only be allocated to carrier pool if: C/N0,min ≤ C/N0,calc ≤ C/N0,max, where
C/N0,calc equals the C/N0 value measured at the terminal (C/N0,meas) minus the dynamic margin.
For example: we have two terminals T1 and T2. Terminal 1 sends regular bursts, while Terminal 2
just sent his first burst. Both terminals have a measured C/N0 value that allows them to receive time
slots from Carrier Pool 1, but because the scheduler has a higher uncertainty for T2, it will apply a
bigger margin than T1. Consequently T1 will get time slots in Carrier pool 1, and T2 gets time slots
allocated in Carrier Pool 2 (which has a lower MODCOD than Carrier Pool 1). If T2 would send
regular bursts as well, the margin will become smaller and it will move up to Carrier pool 1.
6.5 Automated Uplink Power Control

AUPC or Automatic Uplink Power Control is an automated feature intended to maintain a constant
receive level over a satellite return uplink that suffers from terminal uplink fading, while respecting
the contractual BEPD limit of the satellite. Especially Ku/Ka band satellite links suffer from varying
amounts of loss due to weather and rain conditions on one or both ends. AUPC can be used with the
MRC, HRC and 4CPM return technologies and is only supported when using the following Outdoor
Unit (ODU) types:
• BUCs using modem output power control : MDM3xxx, MDM5xxx, MDM25xx.
• iLB2220 (MUC): MDM2010, MDM2210 and MDM2510.
Other combinations in ODU will ignore the AUPC related signaling from the hub.
When AUPC is enabled and (rain) fade occurs at the uplink of the terminal, the controller in the hub
will detect the fade and will command the remote terminal to increase its transmit power to
compensate for this fade. When AUPC is disabled, the terminal uplink rain fade is not compensated.
The concepts of AUPC in MRC, HRC and 4CPM are the same but the target values are defined in a
different way:
• When using AUPC in MRC and HRC the target value is the RX Power Density [dBm/Hz].
• When using AUPC in 4CPM the target value is the maximum C/N0 [dB/Hz].

Successfully operating a network in MRC, HRC or 4CPM with AUPC enabled, requires that :
• Each terminal's up-converting infrastructure (for example BUC) is exclusively used by the indoor
unit (non-shared BUC usage).
• For MRC and HRC at least 3 geographically spread (at least 15 km apart, see
RECOMMENDATION ITU-R P.618) terminals are live in the field.
• For 4CPM at least 10 geographically spread (at least 15 km apart, see RECOMMENDATION
ITU-R P.618) terminals are live in the field.
If these conditions are not met, the system will not efficiently compensate uplink fades in the return
because it cannot make a distinction between changing weather conditions in the uplink or downlink.
The modem shall adapt the TX level according to the AUPC control signaling received from the hub
as follows:
1. For login transmissions:
– Modems shall initially attempt to login using the TX level PSD as defined during the
determination of the line-up settings.
– Depending on the ODU type the signaled TX PSD will be applied to the modem output or
to the ODU output.
2. For other transmissions:
– Modems shall apply the TX level specified in the forward link signaling by the AUPC
functionality.
– Depending on the ODU type the signaled TX level will applied to the modem output or to
the ODU output.

Data Path Optimization
7 Data Path Optimization
Introduction
The choice of IP protocol as the transport protocol has been leading to the convergence of
telecommunication and data networks. As the networks evolve to provide more network capacity,
ever-increasing number of IP-based applications and services compete to receive their required
capacity. For the network operators, it is important to offer a high quality of service (QoS) in order to
attract more customers and encourage them to use their network as much as possible.
As for satellite communication networks with high latency, it is getting more difficult to attain those
high bandwidths required. In order to achieve higher user satisfactions and optimal use of valuable
network capacity, the available resources must be used as efficiently as possible. In addition,
another important fact in satellite communication is that dedicating more bandwidth to the
high-priority customers does not always fix slow applications problems. As such, different
techniques have been developed to improve the performance of IP-based communications over
satellite networks.
In general, the goal of different network optimization techniques is to increase network utilization,
reduce the overhead of control data and improve the Quality of Experience (QoE) for the end users.
Deploying these techniques bring several benefits such as faster web-page loading and file
downloads.
Network optimization techniques include:
1. Aggregation
2. Compression
3. Acceleration
4. Cross-Layer-Optimization.
Mechanism

1. Incoming streams (TCP and non-TCP flows) are classified into QoS classes. For more
information, refer to Classification.
2. Header compression and TCP payload compression is applied. For more information, refer to
Header Compression on page 82 and TCP Payload Compression on page 85.
3. Traffic is prioritized. TelliNet pushes the incoming traffic flows' packets into the QoS classes'
buffers. The Flow Schedulers guarantee a fair distribution of the resources among the flows. For
more information, refer to Flow Fairness on page 91.
4. Packet aggregation and encryption is applied. For more information, refer to
Packet Aggregation on page 93.
5. Data is sent into TelliShape via a Priority Scheduler and stored into the QoS queues. For more
information, refer to Queuing on page 59.
The scheduler in this step already existed in previous releases. However, it was only
applied for TCP traffic. From Dialog R2.4.1 on, non-TCP traffic is also affected by this
scheduler.
6. Feedback from TelliShape is sent into TelliNet, containing information about the state of the
satellite link. This has an impact on the possible throughput within TelliNet and TelliShape, as
overflow needs to be avoided in the QoS queues.
The queue time can be set for QoS class and terminal, and in the forward and return
link with the Packet Shaping Timeout parameter during Service Profile configuration.
The queue is filled with packets depending on the data rate of the customer
application, but the packets are queued only for the Packet Shaping Timeout time,
and up to the maximum queue size for the forward link or for the return link
depending on the return technology used. Therefore, for applications with data rate
that exceeds the queue size and time, excess packets are dropped. For more
information, refer to Queuing on page 59.
7. QoS shaping is applied. For more information, refer to Shaping on page 60.

7.1 Header Compression

Header compression reduces the size of one or more protocol headers of a packet. Dialog supports
IP, UDP, TCP, RTP and GTP header compression of unicast IPv4 and IPv6 traffic. It also supports
Ethernet header compression of layer 2 point-to-point virtual connections.
The type of header compression can be set per QoS class in a service profile. This is useful as
different terminals (remote receivers) may have different QoS class settings.
The table below shows which header is compressed when a specific compression is enabled.
Header → Eth * IP TCP UDP RTP GTP

Compression Type
↓
Ethernet * X
IP X X
TCP ** X X X
UDP X X X
RTP X X X X
GTP X X X X
* Ethernet header compression only applies to layer 2 network traffic. Only the Ethernet headers of layer 2 frames are
compressed.
** TCP header compression only applies to non-accelerated TCP connections.
When header compression for a particular protocol is applied, it is also automatically applied to the
main protocols in the layers under.
When the layer 3 network or layer 2 virtual connection is marked as a mobile backhaul network and
GTP header compression is enabled, the other header compression types also apply to the data
inside the GTP tunnel.
Examples
• When only Ethernet header compression is enabled:
– For layer 2 frames, only the Ethernet header are compressed:
– A layer 3 packets, no header is compressed. To apply header compression, enable IP

header compression.
• When only IP header compression is enabled:

– For layer 2 frames, Ethernet and IP headers are compressed:
– For layer 3 packets only the IP header is compressed:
• When UDP header compression is enabled:

– For layer 2 frames that contain a UDP overlay within, the Ethernet, IP and UDP headers are
compressed:
– For layer 2 frames that contain a TCP overlay within, no header compression is applied. To
apply header compression, enable Ethernet, IP or TCP header compression.
– For layer 3 packets that contain a UDP overlay, IP and UDP headers are compressed.
– For layer 3 packets that contain a TCP overlay, no header compression is applied. To apply
header compression, enable IP or TCP header compression:
• When IP and UDP header compression are enabled:

– For layer 2 frames that contain a TCP overlay, the Ethernet and IP headers are
compressed, but the TCP header is not compressed:
– For layer 3 packets that contain a UDP overlay, the IP and UDP headers are compressed:
– For layer 3 packets that contain a TCP overlay, only the IP header is compressed.
• When only RTP header compression is enabled:

– For layer 2 frames that contain an RTP overlay, all headers are compressed:
– For layer 2 frames that do not contain an RTP overlay, no header compression is applied.
To apply header compression, enable Ethernet, IP or UDP header compression.
– For layer 3 packets that contain an RTP overlay, all headers are compressed:

– For layer 3 packets that do not contain an RTP overlay, no header compression is applied.
To apply header compression, enable IP or UDP header compression.
• When GTP and UDP header compression are enabled:
– For layer 3 mobile backhaul network packets, all headers are compressed:
Applying header compression or not is a trade-off between performance (header

compression disabled) and bandwidth efficiency (header compression enabled).
Applying header compression increases CPU load. Hence, it lowers the performance.
To have a positive effect on satellite bandwidth efficiency, it is advised to enable IP,

IP/TCP and IP/UDP header compressions on all the QoS classes used within the service
profile.
For RT1 and RT2, also enable IP/UDP/RTP header compression scheme.
Header compression is most effective for stream-like applications like voice, video, or file
transfers.
Performance Evaluation
For VoIP traffic (RTP/UDP/IPv4 based): The volume (and implicitly throughput) on satellite can be
reduced by 40.2%, The number of packets (and implicitly packet rate) on satellite can be reduced by
97.7%.
Currently, the maximum number of compression streams is set to 256. This means, that up to 256
parallel IP, IP/UDP and IP/UDP/RTP would be header-compressed.
Increasing this number may require more CPU and more RAM on the respective device. On the
other hand, it will increase the bandwidth efficiency.
7.2 TCP Payload Compression

TCP payload compression provides on-the-fly payload compression of TCP traffic, which can be
either lossy or lossless.
• Lossless payload compression: In computer science, lossless compression is a class of data
compression algorithms that allows the original data to be perfectly reconstructed from the
compressed data.

• Lossy payload compression: Lossy compression, or irreversible compression, is the class of

data encoding methods that uses inexact approximations and partial data discarding to represent
the content. These techniques are used to reduce data size while transmitting it over the network.
This is opposed to lossless data compression (reversible data compression) which does not
degrade the data. The amount of data reduction possible using lossy compression is often much
higher than through lossless techniques.
The TCP payload compression in Dialog is based on lossless scheme. In Dialog system, on
average, TCP payload compression savings is 25% to 40%.
It is important to note that many content types are already compressed by design. For example, a
program file which is packaged as a ZIP file is already compressed, any state-of-the-art video
(MPEG4, DivX, MPEG2) is already compressed, most image formats (JPG, GIF, PNG) are already
compressed. Those content types cannot be further compressed.
7.3 TCP Acceleration

The TCP protocol is known to have some disadvantages in high latency and lossy networks, such as
long connection setup (TCP three-way handshake), slow throughput ramp-up (TCP slow start),
sensitivity to packet losses and high jitter (TCP congestion control) and the limitation of throughput
for one connection (TCP flow control). Moreover, TCP is a ‘chatty’ protocol which generates a high
amount of control data next to the actual user payload data. This results in slow
end-user-experience such as time to load a web page or download a file, underutilization of the
bandwidth as well as waste of bandwidth for control data.
TCP acceleration aims to eliminate or at least minimize the drawbacks of TCP over high latency
networks. In Dialog, the Enhanced TCP or eTCP protocol is used to tunnel all traffic over the
satellite link. This protocol is optimized to handle the huge round trip time and reduces the amount
of control traffic over the satellite link.
eTCP first establishes an association between the two communicating peers, negotiating protocol
capabilities, encryption parameters and performing authentication. On top of this association context,
reliable data streams can be established (TCP-like service) and packets can be sent in an unreliable
manner (UDP-like service).
For TCP-based traffic, eTCP protocol significantly reduces the amount of control data overhead. A
comprehensive comparison of TCP features and eTCP enhanced features is listed in the table
below.
Comparison of Transport Protocol Algorithms
Feature TCP Enhanced TCP Rationale

/Protocol

3-way 1.5 RTTs Local TCP handshake Due to local 3-way

hand-shake termination, instant handshake interception,
connection setup the short living TCP
(sending payload data in connections (e.g. HTTP)
the ETCP SYN packet) are significantly speed up
(saving 1 RTT per session)
Connection Slow start Fast start up to the Fast start allows to use the
Startup (doubles rate per maximum available bandwidth
RTT only), may instantly
differ depending
on TCP 'flavor'
Acknowledgme Cumulative ACK, Aggregated ACKs, With aggregated ACKs and

nts selective ACK selective NACKs for a set NACKs the number of
(SACK) on a of up to 128 connections IP/TCP packets and the
per-connection-ba respective data volume is
sis significantly reduced
Packet Header Min. 40 bytes 31 bytes (IPv4+ETCP Smaller header save

Length (IPv4+TCP header) bandwidth on the satellite
header) link
Bandwidth Every session Virtual circuit concept, i.e. A fair connection scheduler
Sharing competes with cooperative bandwidth makes sure that every TCP
others for the usage between sessions session gets the same
bandwidth with a fair session amount of available
scheduler to be TCP-Fair bandwidth
(i.e. every session gets
the same amount of the
available bandwidth)
Resilience to May result in Tolerates high jitter of A robustness against high

Jitter unneeded TCP several 100ms w/o jitter is important for VSAT
segment unneeded systems with TDMA return
re-transmissions re-transmissions links where the RTT can
instantly double or even
triple (e.g. from 600 msec
to 1200 msec)
As described in the above table, TCP optimization has an answer to all TCP issues. This technology
is continuously adapted to any changes in the web industry to make sure that it still brings a value
and does not interfere with the industry’s improvements. Also, since the TCP protocol itself is
agnostic to caching, compression and (transport layer) encryption, enhancement technologies
related to that protocol are future-proof.
TCP acceleration is by default enabled, however, it is possible to disable it. Disabling acceleration
can be considered in case traffic acceleration is performed by an external device. TCP acceleration
can be enabled or disabled for each QoS class individually. For example, TCP acceleration can be
enabled for Real Time traffic and Critical Data and disabled for Best Effort traffic. However, the
settings of TCP acceleration of a specific QoS class must be the same for both the forward and the
return link.
It is not allowed to have TCP acceleration enabled for the forward link of a QoS class
and disabled on its return link.

Note that TCP acceleration requires memory as TCP data needs to be buffered. To
process the buffered data, enough CPU is required. Both memory and CPU are limited.
Therefore, the concept of conditional TCP acceleration exists. When the maximum
memory usage or the maximum number of TCP connections is reached, conditional TCP
acceleration will stop accelerating the excess TCP connections.
An analysis has been done to predict the bandwidth gain a customer can expect using acceleration
by comparing “Acceleration” and “non-Acceleration” situations. The case study consists of typical
traffic including 60% to 80% HTTP, 20% – 30% other TCP and up to 15% non TCP traffic. What has
been observed is a typical gain of 10% to 20% on forward and 20% to 25% on return.
The positive impact on end-user experience of this combination of optimizations is illustrated in the
following figure. In that test, three typical web applications – a Windows software upgrade, social
networking and HTTP-based video streaming - have been benchmarked against TCP.
Another positive side-effect is the significant reduction of data over the return channel (web browser
towards web server). As in most network the return link is shared across several users, this
minimizes the congestion on that link which obviously has a positive effect to responsiveness of the
applications.

7.4 GTP Acceleration

Cellular Network Architecture
The following architecture can be found in third-generation cellular networks:
• End-user devices, such as smartphones and tablets, are located within a specific radio cell. A
radio cell is a geographic space which is served by a base station. The end-user devices, the radio
cell and the base stations are part of the RAN or Radio Access Network.
• The RAN is connected to the Mobile Core Network or MCN. The MCN is that part of the mobile
network responsible for call switching and mobility management functions (by the MME or
Mobility Management Entity), and also provides the connection to external networks such as the
Internet and PSTN or Public Switched Telephone Network. The MCN uses gateways towards the
external interfaces:
– A Serving Gateway is used as interface between the RAN and the MCN.
– A Packet Data Network Gateway or PDN Gateway is used to connect the MCN to the
external network.
In fourth-generation cellular networks the key nodes have different names but, to a
certain extent, their functionality is comparable to nodes used in third-generation
networks.
To provide a reliable end-to-end TCP/IP connection, IP packets originated at the end-user must be
delivered unadulterated to the destination clients located within the Internet and vice versa.
However, not only routing but various other interactions inside the cellular network itself are also
necessary. These include cell handover, QoS management or billing.
For that reason, data between the RAN equipment in each cell and the Serving Gateway is handled
through GTP-U tunnels.
GPRS Tunneling Protocol or GTP is an IP-in-IP tunneling protocol: An IP packet created by a
mobile device is sent into a mobile network core. The mobile network tunnels the original IP packet
inside another IP (on UDP) packet that uses local addressing and a well-defined tunnel endpoint
identifier or TEID to track the specific phone or tablet that originated the message.
GTP is composed by a set of protocols. The one dealing with the user data tunneling between the
RAN and the MCN is GTP-U.

The protocol stack within the GTP-U tunnel is the following: HTTPS/TCP/IPv6[data
packets]/GTP-U/UDP/IP.
While GTP-U is based on UDP, the end-to-end communication between the end-user and the server
is still based on TCP. Per communication, two GTP-U tunnels are established: one forward from the
MCN to the RAN and one return from the RAN to the MCN. Every end-user device can set up
several tunnels. For example, for voice, for data, or for a specific application running on the end-user
device. When an end-user device moves from one cell to another in the mobile network, a new
GTP-U tunnel to the new cell is set up and the newly created tunnel is correlated. An end-user
device going idle and coming back is technically similar.
Dialog and GTP-U Tunneling

Dialog offers a satellite connection between the Radio Access Network and the Mobile Core
Network, as an alternative to point-to-point radio or terrestrial connections.
Enabling GTP acceleration will only have effect when the layer 3 network or layer 2
virtual connection is marked as a mobile backhaul network.
The Dialog platform does not interfere with the signaling plane of the mobile network.
The signaling data of the mobile network is transparently forwarded via the RAN
infrastructure over satellite to the MME.
The mobile backhaul network must be dedicated to backhaul traffic and must not be shared with
other mobile technologies, nor with enterprise traffic or B2C traffic. Only when these networks are
explicitly marked as mobile backhaul networks in the network configuration interface, the system will
identify the traffic as GTP-U traffic.
The mobile backhaul data plane is supported by layer 3 or layer 2 networks.
Dialog implements GTP tunnel learning, associating the corresponding forward and return GTP-U
tunnels.
To identify connections, the following values are identified:

• Source IP address
• Source port number
• Destination IP address
• Destination port number
• IP protocol version
The forward and return GTP-U tunnels must be linked to each other for a correct functioning. It is
assumed that these five values are equal only for one bi-directional GTP-U tunnel. This allows to
easily map TCP connections to new tunnels.
Dialog GTP Acceleration

The protocol stack within the GTP-U tunnel is the following: HTTPS/TCP/IPv6[data
packets]/GTP-U/UDP/IP.
The GTP acceleration feature accelerates the TCP connection inside GTP-U tunnels between a
terminal and the hub when using the Dialog solution in a mobile backhauling set-up. For more
information on the disadvantages of running unaccelerated TCP traffic in a satellite link, refer to
TCP Acceleration on page 86.
The high-level acceleration process is the following:
1. Tellinet client or server identifies a UDP datagram with a destination port of 2152 (default port
used for GTP-U traffic) or with the one configured for GTP-U tunnels.
2. Tellinet client or server inspects the GTP header and payload. The enclosed TCP session is
detected.
3. The TCP end-to-end connections are identified and classified into QoS classes based on the
classification profile rules.
GTP acceleration is enabled per QoS class. GTP traffic must be classified into a traffic
class where GTP acceleration is enabled in order to accelerate the TCP traffic inside
the GTP-U tunnel.
4. The TCP encapsulation is removed at the sending side,

5. The payload data is transmitted through an eTCP connection to the destination side. For more
information about eTCP, refer to TCP Acceleration on page 86.
6. At the destination, the datagram is re-encapsulated.
It is possible that a GTP-U tunnel is encrypted outside the Dialog system. In that case GTP
classification is not possible and acceleration cannot be performed.
7.5 Flow Fairness
Introduction
Dialog can handle a mix of accelerated TCP, non-accelerated TCP and non-TCP traffic. TCP
connections can be unaccelerated, for example, to avoid excessive memory consumption. Examples
of non-TCP transport layer protocols are UDP and QUIC.
A data flow corresponds to a sequence of packets from an application source host to a destination
host. Each flow is uniquely identified by:
• Source and destination IP addresses
• Source and destination ports

• Protocol
From release 2.4.1 on, Dialog provides flow scheduling mechanism which improves end-to-end
congestion control, as unaccelerated flows including QUIC, UDP or unaccelerated TCP, are
scheduled in a fair way together with accelerated TCP flows. Dialog guarantees a friendly
competition between flows by implementing one flow scheduler for every QoS class, establishing
fairness based on bit rate, instead of packet rate.
In previous Dialog releases, all non-TCP data was treated as one big flow. This could
lead to starvation scenarios, where non-accelerated TCP would perform better than
accelerated TCP.
A fair distribution of the data rate among the flows is especially important on satellite links, as the
speed of convergence is slower than in terrestrial links: the long round-trip times slow down the
end-to-end congestion control loops. Besides that, bigger flows can occupy the available buffer
space, and therefore induce to early starvation of the new or smaller flows. Hence, new flows may
back off long before they reach their bit rate share.
Dialog’s flow fairness feature improves the performance of the overall link and the effectiveness of
the end-to-end congestion control. This is especially true for interactive, bursty flows. The flow
scheduler is also beneficial for the jitter behavior. For example, in previous releases, when two
senders shared same QoS class, they also shared a queue. Therefore, a bursty flow from one
sender could cause jitter for the other.
In addition to that, flow fairness feature guarantees that special protocols like QUIC and TCP
versions with special options; for example, multipath-TCP, TCP fast-open or TCP authentication; are
accepted in Dialog and fairly distributed among other accelerated TCP flows, and UDP flows.
User traffic can be aggregated, for example, using tunnels (VPN connections). Dialog
cannot identify the individual flows in an aggregate flow. Therefore, it will schedule the
aggregate as a single flow. The throughput of the aggregate may be lower than
expected. The problems become worse the more flows are hidden in an aggregate.
Backwards Compatibility
In previous TelliNet releases, all non-TCP traffic was treated as one data flow. Therefore, non-TCP
traffic could end up starving out the accelerated TCP traffic. This problem is avoided with the
introduction of Flow Fairness.
The introduction of Flow Fairness may require customers upgrading from Dialog R2.2.3
or lower to review and adapt the configuration to ensure that time-sensitive applications
are allocated with the right priority, as explained in this section below.
• TelliNet-TelliShape feedback is introduced. As a consequence, TelliNet is now aware of

TelliShape scheduling priorities and rate allocation. Therefore, packet drops are now noticeable in
TelliNet.
• It is recommended to keep Free Capacity Assignment always enabled. It should only be disabled
for testing or troubleshooting purposes.
Free capacity is always enabled for MF-TDMA 4CPM but can be disabled for
Mx-DMA HRC and NxtGen Mx-DMA MRC RCGs. For more information, refer to the
Newtec Dialog Configuration User Guide.
• RT1 and RT2 classes are built with smaller QoS queues sizes, and are meant to be used for
applications sensitive to latency and jitter, such as VoIP or SCADA, but not for applications such
as broadcast contribution.
• TCP traffic should not be used as RT1 or RT2.

• Depending on the application, UDP traffic must be prioritized over TCP traffic. In previous Dialog
releases, UDP always had priority over TCP. Customers must configure QoS classification rules
accordingly.
7.6 Packet Aggregation

Packet aggregation optimizes the frame rate and the satellite bandwidth usage. With packet
aggregation, several upper layer packets are inserted into one packet. The aggregation is completed
when either a maximum packet size or the aggregation timeout is reached.
Packet aggregation limits the overhead of the lower layer protocols and increases the amount of
payload bytes. This is typically used in backhauling systems where there are several simultaneous
phone calls.
The example below visualizes the aggregation of three calls. Six separate packets are aggregated
to one packet. Instead of using six headers, only one header is used. In practice, even more than 20
packets (60-bytes each) fit in one IP packet being sent over satellite.
Packet aggregation introduces delay. The value of the packet aggregation timeout is a
trade-off between the delay and the overhead. A smaller value decreases the delay
because there is a shorter waiting time to fill up the buffer but increases the overhead as
the buffer may not be completely full by timeout. For jitter-sensitive real-time applications
it is advised to set the timeout value to 1 ms.
For each packet that is aggregated with another packet, there will be a gain of 20 bytes (IP-header)
+ 2 bytes (CUDP-Port) + 2 bytes (encryption checksum) - (1 or 2) bytes aggregation header
(depends on packet size, below or above 128 bytes).
The relative IP volume saving achievable by aggregation as well as the delay and jitter added
depends on the configuration and in particular on the traffic profile.
For the 100 parallel RTP streams (20 kBit/s per stream) in the requirement, assuming all the
packets can be aggregated, the max_packet_size of 1500 bytes will be filled every 6 ms, so that is
the maximum delay and jitter produced by the aggregation in this case (there may be other causes
of jitter in the TelliNet data pipeline though, which may have impact on the aggregation part as well).
The configured max_aggregation_time = 20 ms will generally not be reached in this case.
The relative IP volume saving depends on the size of the involved packets. In case the packet
payloads are 300 bytes in size, only 5 packets are aggregated into one eTCP packet, which results in
a gain of 4x(20+2+2-2)=86 bytes per 1500 bytes (~5%). If the packets are only 50 Bytes in size, then

30 packets will be aggregated into one eTCP packet, which results in a gain of 29x(20+2+2-1)=667
bytes per 1500 bytes (~30%).
7.7 Cross Layer Optimization

Cross Layer Optimization™ or CLO is an optimization mechanism which is designed to control the
rate of satellite network traffic and avoid congestion-based packet loss. The purpose of CLO is to
provide a chain of control loops to inform the traffic sender the amount of traffic which can be
handled by each terminal. Therefore, the rate of transfers can be controlled and overloading satellite
links can be prevented.
CLO is a hard-coded fundamental feature, implemented within Dialog and applicable for any kind of
IP traffic. However, it is significantly beneficial for TCP traffic and this is mainly due to deficiency of
TCP protocol over high-latency satellite links.
In satellite communication the effective network capacity varies over time due to changing weather
conditions. Since it is possible to constantly monitor the effective IP rate per terminal, the amount of
traffic that can be handled by each terminal can be calculated to avoid the congestion of TCP traffic.
CLO ensures that the satellite links are not overloaded.
Cross Layer Feedback is the essential part of CLO, based on which the available bandwidth is
continuously signaled from the lower layer to the upper layer, in order to prevent a data overflow
which will cause packet drops (backpreassure).
Mechanism
Cross Layer Optimization auto-optimizes the data link by providing a continuous interaction between
satellite equipment, bandwidth management, shaping and acceleration technologies.
CLO provides a chain of feedback data from the satellite link to the CSE and then from the TAS to
the original TCP sender. CLO enforces end-to-end QoS for IP traffic, enables flexible service profile
and adapts the IP traffic throughput on-the-fly according to the service profile and weather
conditions. CLO can be considered as flow control mechanism for eTCP streams. This mainly
results in an improvement in the performance of TCP congestion control mechanism over low-speed
satellite communication system.
Several components are collaborating sequentially to improve the performance of satellite
communication traffic:
TAS is in charge of TCP acceleration and payload compression, packet aggregation, header
compression and encryption. Activation of acceleration is configurable on a per-service profile-basis

and configuration of Packet Aggregation on page 93 and Header Compression on page 82 are per

QoS class.
TAS translates TCP to eTCP. eTCP is able to send data with the exact and precise bit rate over the
satellite link because it has learnt it from CLO. The modulator knows which MODCOD is being used.
The CSE translates the MODCOD to bitrate and sends this information to the TAS. By doing so, TAS
knows how fast IP packets can be forwarded to the shaping software on CSE.
On the other hand, TAS provides feedback to the original TCP sender. TCP flow control information
is used to avoid sending data too fast towards the receiver. Every TCP connection has a
dynamic-size queue in TAS. Using TCP flow control, TAS ensures that this TCP queue is not
overflown with data.
Ingress and egress rates of TAS may deviate slightly due to applying optimization
techniques, for example, compression, acceleration and aggregation.
CSE anticipates the congestion and forecasts the data rate per QoS queue based on the current
and historical traffic situations. CSE applies flow control toward the TAS. QoS classes are shared
between TCP and non-TCP traffic. CSE shapes and limits the allocated network capacity taking
priorities, CIR, PIR and weight values into account.
CSE (Encapsulator) adheres to the IP rate, calculated according to the current MODCOD in
Real-time. CSE encapsulator never drops packets.

The above-mentioned CLO procedure is explained for the flow in forward (from central hub to
terminals). It should be noted that for the return the same principle applies and lower layers are
communicating with upper layers with a chain of control loops. However, the total available satellite
bandwidth on return link from each terminal is not fixed. As such, if the allocated bandwidth
increases or decreases, this aspect will also be taken into account in CLO process on return.

Time and Frequency Synchronization
8 Time and Frequency Synchronization

Shared access return link technologies, such as MF-TDMA, Mx-DMA and NxtGen MX-DMA, divide
the return link in time and frequency. The return link controller assigns time-slots and frequencies to
terminals for return transmission.
In satellite based systems the following uncertainties on time and frequency are introduced.
There is timing uncertainty due to:
• Uncertainty of satellite location (satellite movement within a box)
• Uncertainty of terminal location (no exact location known, moving terminal)
There is frequency uncertainty due to:
• Satellite LO (Local Oscillator) frequency and drift
• BUC drift
• Doppler effect as a result of satellite movement
• Doppler effect as a result of terminal movement
To reduce the processing effort and complexity of the multi-carrier demodulators for resolving the
frequency and time uncertainty, it is important to limit the frequency and time uncertainty of the
return link signal transmitted by the remote modem. Therefore, a common network timing is used in
the hub module and terminal, from which time and frequency are deduced.
In Dialog, the following mechanisms are used for setting up the time and frequency synchronization:
• NCR (Network Clock Reference)
• PTP (Precision Time Protocol)
• External 10 MHz Reference
• 10 MHz Reference output
A distinction can be made between:
• Hub module to terminal time and frequency synchronization
• Hub module internal timing synchronization. In this case, the exact mechanism is different
depending on the hub module type and return link technology.
Hub Module to Terminal

Timing and frequency synchronization between hub and terminal is based on Network Clock
Reference or NCR signaling defined in the DVB-RCS standard. NCR packets are transmitted
regularly over the forward link to the modem, and contain a timestamp value which is a counter of a
27 MHZ reference clock in the hub. This timestamp refers to a well defined event in the forward link
signal (for example the start of a DVB-S2 PL frame).
The following components are involved when generating the NCR signaling:
• FTB (Forward Table Broadcaster), which generates NCR signaling packets with dummy NCR time
information included.
• MPE/GSE encapsulator, which encapsulates the NCR signaling packets in a baseband frame
stream and forwards it to the modulator.
• Modulator, where the very high stability, oven-controlled crystal oscillator (OCXO) is used to
generate the correct NCR time information; The modulator replaces the dummy values with this
correct NCR time information in the NCR signaling packets (= NCR restamping). The OCXO can

be used stand-alone, or slaved to an external 10 MHz reference, or slaved to an external PTP

source.
The terminal receives the NCR signaling packets, extracts the NCR time information, and
synchronizes with the hub module time.
This NCR mechanism is applied to all terminals regardless of their return link technologies.
However, timing and frequency synchronization is more important for terminals operating in
MF-TDMA, Mx-DMA or NxtGen Mx-DMA.
• 4CPM uses MF-TDMA as access technology. Remote terminals are assigned time-slots spread
over multiple frequencies which they use to send their data. The assignment of slots is organized
in burst time plans, which are generated every 1/6th of a second.
• HRC Mx-DMA and MRC NxtGen Mx-DMA apply the same mechanism as MF-TDMA. The
difference with MF-TDMA is the rate at which terminals receive information about transmit time
and frequency. In Mx-DMA, terminals are informed every second. In NxtGen Mx-DMA every 40
ms.
• Terminals operating in DVB-S2 or HRC SCPC use a fixed carrier frequency allocation plan. They
have an "always-on" return channel. Time and frequency synchronization is not really required
because:
– SCPC does not use a multiple access mechanism, hence timing is not critical.
– The minimal symbol rate of SCPC return carrier is 1 Mbaud. Such carriers are robust enough
to cope with different time and frequency offsets, still allowing the demodulators to distinguish
the different return carriers they receive from different terminals. Consequently a guard band
of 3 kHz is negligible relative to the minimal symbol rate of 1 Mbaud.
1IF/4IF Hub Module

The active modulator provides the timing inside the satellite network for which it is active. For 4IF,
each satellite network uses a separate master clock. The standby modulator is slaved to the master
using Precision Time Protocol or PTP.
The modulator distributes the clock reference using:
• NCR restamping in the forward link baseband frame stream
• NCR over ASI (Asynchronous Serial Interface) (M6100 only)
• PTP (Precision Time Protocol)
The modulator offers two modes for time and frequency synchronization:
• External 10 MHz mode: The modulator uses an external 10 MHz reference source, which is
connected to the corresponding input (Ref IN) of the hub module.
• Internal 10 MHz mode: The active modulator provides the 10 MHz reference signal. The output
interface of this signal depends on the modulator redundancy.


XIF Hub Module

The XIF hub module use a redundant pair of PTP sources for time and frequency synchronization.
The reference clock is distributed over PTP.
The PTP master clock can be slaved to an external 10 MHz reference signal. In this case, an
external 10 MHz reference source should be connected to the 10 MHz REF IN interface on the back
panel of the PTP master clock.
Two PTP source deployment modes exist:
• Dedicated: A redundant pair of PTP sources is available per processing hub module. The PTP
sources are connected directly to the Ethernet distribution switches.
• Shared: A redundant pair of PTP sources is available per hub/gateway. The PTP sources are
connected via an external PTP-enabled switch. This switch in turn is connected to multiple
processing hub modules via the Ethernet distribution switches.

During operation, the demodulators in the hub typically deal with timing uncertainties of 4 μs and
frequency uncertainties of 3 kHz. At the startup of a hub, these uncertainties need to be measured
first. The offset values are measured based upon the first terminals that log on to the system.
Typically at startup bigger uncertainty values and sweep ranges are applied, but as soon as the
offset is determined then the previously mentioned typical values apply. The more terminals log on,
the more the system can measure the offsets and the more accurate the system can narrow down
the uncertainties.

Terminals that are moving during operation and/or the synchronization between modem and BUC
introduce additional uncertainties which are absorbed by extra guard bands.
Refer to Doppler Effect on Terminals on page 165 and

BUC and Modem Frequency Synchronization on page 160 for more details.

Terminals
9 Terminals
9.1 Terminal Description

The terminal is a state-of-the-art, high performance equipment package designed to serve a wide
range of applications and services like Internet/intranet access, VoIP, enterprise connectivity,
backhauling, broadcast contribution/distribution and multicast services. A Newtec Dialog terminal
consists of an indoor unit, which is called the modem, and an outdoor unit, which is a combination of
the antenna, the LNB signal receiver, and the MUC or BUC signal transmitter. In case of a MUC, the
LNB and MUC are combined in one device, which is called the iLNB.
The terminal portfolio is perfectly fitted to consumer markets, small and medium enterprises as well
as large enterprises or organizations. Different terminal types can be used on the same platform
sharing the outbound carrier. Management of the modems is done by a single management system
and the service activation flow and corresponding configuration and performance management is
tailored to the business needs.
Through the Ethernet connection, the end-user can access the Graphical User Interface (GUI) of the
modem.
9.2 Modem Types

This chapter will discuss following modem types:

Terminals
Dialog R2.4.1 still supports the older modem types MDM2200, MDM2500, MDM3x00
and MDM5000.
Do note that new features as described in the release notes of Dialog R2.4.1 and higher
are no longer supported on MDM2200, MDM2500 and MDM3x00.
9.2.1 Specifications
The table below gives an overview of the supported forward and return technologies, supported
ODUs and additional features:
MDM2010 MDM2210 MDM2510 MDM3310 MDM5010

SMB3310
SMB3315
Supported Forward Technologies
DVB-S2 64 Mbaud 64 Mbaud 64 Mbaud 64 Mbaud 64 Mbaud

32 APSK 32 APSK 32 APSK 32 APSK 32 APSK
DVB-S2X 64 Mbaud 64 Mbaud 64 Mbaud 64 Mbaud 133 Mbaud

64 APSK 64 APSK 64 APSK 64 APSK 256 APSK

Terminals
DVB-S2X 144 Mbaud 480 Mbaud 480 Mbaud 480 Mbaud 220 Mbaud
Annex M 64 APSK 64 APSK 64 APSK 64 APSK 256 APSK
Supported Return Technologies
MF-TDMA Yes Yes Yes Yes Yes

4CPM
Mx-DMA - - Yes Yes Yes

HRC
NxtGen Yes - Yes Yes Yes

Mx-DMA
MRC
SCPC HRC - - Yes Yes Yes
SCPC - - - Yes Yes

DVB-S2/S2X
ODU support
COTS ODU No Only iLNB Yes + iLNB Yes Yes

support
ODU power iLNB up to iLNB up to Up to 6W BUC Up to 16W Up to 16W

2W 2W
-48Vdc - - - Yes Yes

mains
support
Additional Features
OpenAMIP - - Yes Yes Yes
AIBS - - Yes Yes Yes
#VLAN 4 4 8 16 16
All modems have:

• High service satisfaction
– Embedded TCP acceleration and encryption
– Multi-level Quality of Service
– Low jitter for real time applications
– DNS cache/relay and HTTP pre-fetching
• IP networking features
– Versatile IP routing and addressing
– Support of IPv4 and IPv6
• Easy-to-use implementations
– Over-the-air software upgrade feature
– Over-the-air monitoring and diagnostics tools

Terminals
In case of large latency between the gateway and the content server in the terrestrial link, the
maximum rate per TCP session is limited. The table below gives the maximum throughput per TCP
session for the different round-trip-delay values. Note that this is only about the RTT between GW
and content server, excluding the satellite link delay.
RTT Max rate per TCP session
1 ms 517 Mbps
10 ms 51.7 Mbps
100 ms 5.17 Mbps
300 ms 1.72 Mbps
9.2.2 Markets
The table below shows which markets the different modem types serve:

Terminals
9.3 Outdoor Units

Typically, the modem is connected to equipment that is located outdoors. Consequently all terminal
parts that are used outdoors are considered as Outdoor Unit (ODU). Each modem type has its own
supported Outdoor units combination, and the differentiation is mainly in the used antenna and iLNB
or BUC/LNB.
The MDM2010 IP Satellite Modem can be used with an easy to install ODU. The ODU consists of an
antenna, an integrated transmitter and low noise block down converter (iLNB). The table below
shows the available antenna/iLNB combinations:
MDM2010 Ku-band Ka-band
75cm 1m 1.2m 75cm 1m 1.2m

ANT2010 ANT2025 ANT2035 ANT2010 ANT2025 ANT2035
2W ILB2140 ILB2140 ILB2141 ILB2220 ILB2220 ILB2221

ILB3210 ILB3210
MDM2210* Ku-band Ka-band
75cm 1m 1.2m 75cm 1m 1.2m

0.8W ILB2120 ILB2120 ILB2121
2W Quad ILB2145 ILB2145
*MDM2210 also supports ILB2210 and ILB2110. However, these ODUs are no longer in production.
MDM2510 Ku-band Ka-band
75cm 1m 1.2m 75cm 1m 1.2m

2W Quad ILB2145 ILB2145

Terminals
The MDM2510, MDM3310, SMB3310 and SMB3315 IP Satellite Modems can be connected to a
third party outdoor unit or you can select one from the ODU portfolio. The table below shows the
available antenna and LNB/BUC combinations:
MDM2510 Ku-band Ka-band C-band

MDM3310 0.96m, 1.2m 1m, 1.2m 1.8m, 2.4m
SMB3310
SMB3315
LNB LNB0120 LNB0300
2W BUC0130
3W BUC0100 TRX0120 / TRX0121
4W BUC0200
5W BUC0330
6W BUC0300
The MDM5010 IP Satellite Modem can be connected to a third party outdoor unit. There's no ODU
available for this modem type in the ODU portfolio.

Terminals
9.4 Terminal Provisioning

Terminals only have access to the Dialog platform when they are provisioned. Both the hub network
operator or HNO and the virtual network operator or VNO can perform the provisioning actions.
Provisioning can be done via the NMS GUI or through REST API.
Before you can start provisioning terminals, all required satellite and network resources, and
necessary profiles need to be defined.
For more information, refer to the Terminal Provisioning chapter in the Newtec Dialog
Configuration User Guide.

Terminals
9.5 Whitelisted Terminals

Whitelisted terminals can log on to a satellite network without being provisioned beforehand. This
feature is called Auto Attachment in Dialog.
Auto Attachment can be enabled or disabled per satellite network. When enabled, the FTB message
in the forward link not only includes the pop-ID with the MAC addresses of all provisioned terminals
but also includes the auto attachment signaling. The signaling contains the broadcast MAC address
and the allowed Power Spectral Density or PSD for logon requests.
The MAC address of whitelisted terminals are added to an Auto Attachment Prototype. The prototype
has a modem template that is used to provision the whitelisted terminals when logging on.
When a whitelisted terminal is installed and pointed, it locks on a forward carrier and parses the FTB
message. When it sees that auto attachment is enabled for the satellite network and its MAC
address is not included in the pop-ID (it is not provisioned), the terminal will send a 4CPM logon
request. This request is received by the 4CPM controller of that satellite network. The Hub Module
Management System or HMMS will periodically poll the 4CPM controller of each satellite network on
which auto attachment is enabled to get the "First Sign of Life" messages. From these messages, it
will filter out the provisioned MAC addresses and send the other (unknown) MAC address to the
NMS. If the NMS verifies that the MAC address is part of an Auto Attachment Prototype, it will
provision the terminal based on the modem template of the Auto Attachment Prototype to which it
belongs. It will also delete the terminal from the Auto Attachment Prototype.
It is possible that the template provisions the terminal in another satellite network than it is trying to
log on to. This is no problem as long as the beam is the same. If the terminal should be provisioned
on the satellite network of another beam, the terminal is not provisioned.
If the NMS does not find the MAC address, the terminal is not provisioned.
9.6 Terminal Installation and Initialization

The terminal installation and initialization process can be divided in the following steps:

Terminals
Optionally, a certification step can be executed before Network logon. For more
information, refer to the Terminal Installation Certification System Manual.
The following paragraphs describe these steps in more details.

Terminals
9.6.1 Step 1: Terminal Installation

The first time the modem starts up, the end user is redirected to the Terminal Installation page. The
installation procedure must be performed step by step, and starts with selecting an outdoor unit. The
supported outdoor unit type(s) are predefined in factory. If the outdoor unit which is being used is not
listed, it is possible to add the additional outdoor unit type (e.g. MDM5010). The terminal supports
up to 64 ODU configurations.
Please refer to Outdoor Units on page 107 for an overview of supported outdoor units.
When adding a new outdoor unit in the modem, it should also be configured with the
same settings in the hub by the Network Operator. If an outdoor unit type in the
modem has no matching entry in the hub, the modem is prevented from logging onto
the network.
If the modem has already been installed before, an overview of the selected installation settings is
displayed.
Next step is the selection of the satellite beam. A beam covers a limited geographical area in which
terminals are serviced by the satellite. Satellite spot beams are predefined in factory, or can be
added by the end user.
It is possible to do automatic beam selection. Refer to Automatic Initial Beam Selection

on page 139 for more details.
After outdoor unit and beam selection, one can start pointing the antenna. A pointing carrier is used
during this procedure. Two pointing methods are supported:
1. Manual pointing, using the Point&Play® pointing tool or using the Point&Play® application.
2. Automatic pointing, using an Antenna Control Unit (ACU).
The end user has the possibility to skip the pointing process, for example when the
terminal has been correctly pointed before.
Manual Pointing
Using the Pointing Tool
When two pointing transponders are available, the user can choose which one to use. The preferred
pointing transponder will always be selected by default.
During the pointing process the end user can use the Graphical User Interface (GUI) of the modem
to verify the states of the various elements:
• The modem state indicates "antenna pointing".
• The demodulator on the modem indicates the Es/No of the received signal and if the demodulator
is locked. The interface also indicates the difference with the maximum power received since the
pointing tool was started. The satellite transponder orbital position and west/east flag that is set in
the pointing carrier is compared with the content of the received Network information Table (NIT).
If there is a match, then the modem knows it locks on the correct satellite.
Via the TX cable the modem sends a signal to the earphone of the Point&Play tool. This signal is
used to inform the antenna installer whether or not the antenna is properly pointed.

Terminals
If the modem is locked on the correct satellite, the end user acknowledges via the GUI that the
antenna process is finished. The modem concludes that pointing was successful and the persistent
data is updated: terminal is pointed. The modem will be activated.
If the modem is not locked or locked on the wrong satellite, the modem returns to the idle status.
Using the Application

The Point&Play® application is an installation solution for VSAT terminals, which enables the end
user to accurately position the antenna towards the correct satellite.
The application is available from the Google Play Store (on Android) or the Apple App Store (on
iOS).
The application connects with the VSAT terminals via Wi-Fi. Once a Wi-Fi connection is established,
the installation can start. The installation is started from the application itself and reads out the
Es/No data from the demodulator.
This application guides you (supported with videos) step by step through the installation of the
terminal.
• The modem contains the outdoor unit parameters to make the correct calculations (for
example to calculate the elevation angle).
• When using a different outdoor units, their parameters should be loaded to the
modem. Please contact our customer support to have these parameters entered.

Terminals
Automatic Pointing
The automatic pointing method can be used for all modems except MDM2010 and
MDM2210.
The automatic pointing method can be used for all modems except MDM2010,
MDM2200, and MDM2210.
The automatic pointing method uses an Antenna Control Unit (ACU), which is connected to the
modem via Ethernet. The figure below shows the ACU connection for the MDM2510 modem.
By default automatic pointing is disabled. You can enable it in the modem GUI. When enabling the
feature, the ACU Interface Configuration and Monitoring sections appear.
With automatic pointing, antenna pointing information is exchanged using a logical interface, which
is compatible with OpenAMIP (Open Antenna to Modem Interface Protocol). The parameters for
configuring the ACU interface are set in the ACU Interface Configuration section in the modem GUI.

Terminals
Make sure the ACU IPv4 address and the IP address of the modem Ethernet interface
are in the same subnet.
The modem goes into pointing state when the TCP/IP connection between modem and
ACU is lost or timeout is exceeded. The modem continuously tries to re-establish
connectivity.
The modem will try to reach the ACU on the indicated IP address and TCP port. Once the
connectivity is established, the modem informs the ACU about the default pointing carrier, the
satellite beam settings and the outdoor unit settings using OpenAMIP-compatible messages.
It is possible to define two pointing carriers in the modem. There is no automatic

switchover to the other pointing carrier when the ACU cannot find the satellite based on
the default pointing carrier.
If the other pointing carrier must be used, you must set it as default pointing carrier via
the satellite interface settings on the modem. Refer to the adequate Modem User Manual
for more details.
The ACU starts searching for the satellite based on the pointing carrier information received from the
modem. In the meantime the modem verifies if it can lock on the initial receive carrier (which is set
in the satellite interface menu of the modem GUI).
When the modem is locked on the initial carrier, it will inform the ACU and verify the NIT (Network
Information Table) received on this initial carrier. The NIT contains the orbital position of the satellite
and the modem will compare this position with the value from the beam data. If these values match,
the modem knows that it is locked on the correct satellite. Once the modem has received the correct
NIT and an "allow transmit" signal from the ACU, the modem finishes the pointing state and starts
with the Satellite Network Lookup state on page 117.

Terminals
If the NIT does not contain the correct info, the modem informs the ACU that it is not locked and the
ACU is triggered to continue searching for the correct satellite.
It is possible to define two initial receive carriers in the modem. If the modem (which is in
a pointing state) cannot lock on the default initial receive carrier during a 3 minute time
period, it tries the other initial receive carrier. If there is no lock on the other initial
receive carrier, the modem switches back to the default receive carrier. This switchover
finishes as soon as the modem can lock on an initial receive carrier.

Terminals
9.6.2 Step 2: Satellite Network Lookup

During this phase, the modem is looking for the correct forward carrier to synchronize with. To do
this, the modem receives and parses different tables from the air interface. The terminal receives the
signaling tables via the initial carrier. These signaling tables then 'redirects' the terminal to its final
traffic carrier. The traffic carrier also contains signaling which allows the terminal to setup the return
link. In other words, return link settings are not configured in the terminal. The terminal rather
derives the return link settings from the signaling it has received via the forward traffic carrier.
The modem can change its receive frequency based on the data it receives in the NIT and RMT
tables as described in Step 3: Forward Link Synchronization on page 118.
During the initialization of the terminal, 3 different carriers can be used:

1. Initial Carrier
The settings of these carriers are stored persistent in the terminal and used as start-up
parameters of the modem.
2. RMT Carrier
The location of this carrier is derived from signaling present on the initial carrier (signaled via the
NIT table).
3. Traffic Carrier
This contains the forward data.
In reality the initial carrier, the RMT carrier and the traffic carrier can be combined.
Different carriers can be available on the network. It is possible to configure two initial carriers on the
modem. The modem tries four times to synchronize with the default initial receive carrier (each
attempt takes 50 seconds). If after these four attempts the synchronization does not succeed (due to
incorrect NIT or loss of signal), then it automatically switches to the alternative initial receive carrier.
If the modem succeeds in synchronizing with the alternative carrier, then the modem marks the
alternative carrier as the default carrier (in other words, default and alternative carrier are switched).
If the synchronization fails on the alternative carrier as well, then the modem returns, depending on
the selected pointing mode, to one of the following states:
• Automatic pointing: The modem returns to the pointing state, where the actual lock state is
signaled to the ACU (No Lock). The ACU is instructed to continue searching for the correct
satellite. For the complete sequence please refer to the pointing state on page 112.
• Manual pointing: The modem tries to connect to the initial carrier again, repeating the sequence
until a lock has been established or the operator intervenes.

Terminals
• During the pointing state of the automatic pointing method, the modem already
established a lock on an initial receive carrier. However in the satellite network lookup
state, the modem tries to establish a lock on the default initial receive carrier again. If
during pointing the lock was established on the non-default initial carrier, then it can
take several minutes before the modem starts the satellite network lookup based on
the non-default initial carrier.
• During satellite network lookup state, the modem signals to the ACU that it is still
locked on the satellite.
9.6.3 Step 3: Forward Link Synchronization

During this sub-state, the concept of pop-id signaling is used. Each forward traffic carrier contains a
data carrousel signaling the intended population id for each MAC-address (i.e. each terminal)
provisioned on the associated Satellite Network (SatNet) of that forward traffic carrier. This
population id is stored persistently by the terminal.
Terminals use the stored population id to parse the RMT during acquisition to arrive at a forward
traffic carrier. In case this forward traffic carrier is not signaling the terminal’s MAC address, the
terminal iteratively looks through the RMT for other forward traffic carriers that do. This can be the
case for newly installed terminals or terminals that have just been moved to a different Satellite
Network.
During the synchronization substate, the modem synchronizes its internal clock with the signaled
NCR tables. The phase is split up into two phases.
• During the first phase, only the NCR signaling is processed and the multicast IP data is received.
This allows the modem to detect a broadcasted software download and process the pop-id
signaling.
• During the second phase, the return specific signaling is also processed (FCT, SCT, TCT, WCT
and SCT2). DVB-S2(X) TIMs (Terminal Information Messages) are received and the last
DVB-S2(X) operational TIM is being saved to be able to process and react to it immediately after
being synchronized.
9.6.4 Synchronized State

In the Synchronized state, the modem has achieved time synchronization with the hub and is ready
to activate a return technology and start sending user traffic. It will keep processing the information
that is being signaled to stay synchronized and it will keep processing tables to be aware of updates.
Terminals which are in the synchronized state do not need to fetch configuration files (as described
in Step 4: Return Link Synchronization on page 118), which allows a fast convergence towards an
operational state.
9.6.5 Step 4: Return Link Synchronization

A terminal supports multiple return link technologies: 4CPM, HRC, MRC and DVB-S2(Ext). The
actual used return link technology is determined during terminal provisioning. Refer to Modem Types
on page 103 to know which return link technologies are supported by which type of modem.
Consequently, each return link technology uses its proper synchronization mechanism.
In a previous step, the terminal achieved to lock on the forward link signal. By doing so, it is able to
receive a signaling carrousel which is periodically sent via the DVB-S2(X) forward link. The content
of this carrousel is determined by the terminal provisioning data. Hence a provisioned terminal can
recognize itself in this carrousel by means of its Air MAC address.

Terminals
9.6.5.1 4CPM Logon Procedure
A terminal configured to use 4CPM as return link technology, sends a request towards the hub to
become operational by means of a CSC (Common Signaling Channel) burst. When the terminals are
installed, they are unaware of their exact position in the satellite network and of the position of the
satellites. This means that when they send their initial bursts (logon bursts), they do not have
synchronization in time with the hub. This timing mismatch is overcome by introducing CSC time
budgets of about 11 ms. When receiving a CSC burst from a terminal, the AMP (Air MAC Processor)
within the CPM Controller calculates the timing offset between the time of expected receipt and the
time of actual receipt. The AMP sends a TIM (Terminal Information Message) to the terminal,
informing it of the timing offset. Since satellites are moving, the timing offset is continuously updated
(via TIMs).
The TIM also contains information about where the terminal can fetch its configuration file.
Configuration files are managed by the Terminal Configuration Server (TCS).
The concept of Terminal Information Messages is valid for every return link technology.
The CPM Controller sends TIM towards terminals operating in CPM, the HRC Controller
sends TIM messages to terminals operating in HRC and the S2 Controller sends TIM
towards terminals operating in S2.The TCS serves terminals regardless of their return
link technology.
Once synchronized, a 4CPM terminal sends capacity requests to the hub, and the CPM Controller
composes a TBTP (Terminal Burst Time Plan) which is sent to all logged in CPM terminals. This
TBTP contains the time and frequencies (by means of traffic carriers) at which the terminal is allowed
to transmit. For example after processing the TIM, a terminal requests capacity in order to be able to
fetch its config file.
Note that traffic carriers use guard times of 60 μs (where as CSC carriers have a significant larger
guard time of 11 ms), to overcome the time synchronization.
A terminal operating in CPM only sends capacity requests when needed (this is when traffic is
detected at the Ethernet interface of the modem). Consequently if there is no return IP traffic
anymore, the terminal logs off again and returns to the synchronized/idle state.
Refer to MF-TDMA 4CPM on page 26 for more details about this return link technology.
9.6.5.2 DVB-S2 Logon Procedure
For a terminal provisioned to use DVB-S2 as return link technology, the logon procedure is triggered
by the S2 controller within the hub. The S2 terminal is informed by the hub about its DVB-S2 return

Terminals
link parameters (transmission center frequency, symbol rate, MODCOD, and symbol rate) via an S2
Terminal Information Message (S2 TIM). The DVB-S2 return link settings for a terminal are
configured via the terminal provisioning interface or the REST API.
The S2 terminal starts to transmit based upon the settings it has received. In other words, an S2
terminal does not really use a logon procedure (nor does it send capacity requests towards the hub),
but it is the hub that initializes the terminal to operate in DVB-S2.
Note that if a terminal is provisioned to use DVB-S2 in the return link, the S2 controller in the hub
reserves a demodulator in order to demodulate the return signal from that particular terminal. A
DVB-S2 return link signal can be demodulated by the MCD6000 or MCD7000. Because these
demodulators have three demodulator boards, they can demodulate up to three S2 terminals. You
can verify if the terminal has achieved a lock on the DVB-S2 return link using the demodulators GUI
or via the Rx-lock LED on the front panel of the demodulator.
Rx-lock LED color Description
Green All active demodulators are locked
Yellow At least 1 active demodulator is locked
Red No lock on any active demodulator
Refer to SCPC DVB-S2 and S2 Extensions on page 35 for more details about this

return link technology.

Terminals
9.6.5.3 HRC Logon Procedure
For terminals which are provisioned to use HRC as return link technology, two logon scenarios exist:
• Logon for SCPC
• Logon for Mx-DMA
9.6.5.3.1 SCPC: Static Frequency Plan Mode
In SCPC mode, the terminals log in using the statically allocated carrier (set during terminal
provisioning), after receiving a message from the HRC controller within the hub. The HRC controller
signals the HRC return link parameters to the terminal.
Every second the HRC controller assigns HRC capacity to the terminal. HRC update messages are
sent to the logged on terminal containing information about the MODCOD, (static) symbol rate,
(static) carrier frequency and output power. ACM can be enabled on the HRC SCPC return link,
consequently the information sent via the HRC updates can change every second based upon
return link quality.
9.6.5.3.2 Mx-DMA
There are three Mx-DMA logon modes:

• Single carrier logon
• Logon bandwidth
• Ulogon, which is an extra logon mechanism on top of the logon bandwidth mode.
In the single carrier logon and the logon bandwidth mode, the hub triggers the terminal to login. In
the ulogon mode, the terminal takes the initiative to logon.
Single Carrier Logon

In this logon mode there is a single logon carrier. The log on capacity within the HRC return capacity
group is determined by the Logon Symbol Rate. This rate is configured via the return link web
interface or via REST API. Terminals use the capacity at the "right" (highest frequency) edge of the
HRC return capacity group to log on.

Terminals
Logon Bandwidth
In this logon mode you can have multiple logon carriers, which have the same Logon Symbol Rate,
allowing multiple terminals to log on simultaneously. The logon capacity used within the HRC return
capacity group is determined by the Maximum Logon Bandwidth. The logon symbol rate and logon
bandwidth is configured via the return link web interface or via REST API. Terminals use the
capacity at the "right" (highest frequency) edge of the HRC return capacity group to log on.
The logon bandwidth is defined as a maximum value. In other words, if you would provide logon
capacity for three terminals but only two terminals need to log on at that time, only the logon capacity

Terminals
for two terminals will be used. The other logon capacity becomes available for user traffic. The HRC
controller always makes sure that "worst case" terminal has logon capacity within the logon
bandwidth when needed. Logon capacity will always be available according the need, that is as long
as not al terminals are logged on yet.
• When all provisioned terminals are logged on, the logon capacity at the edge of the HRC Mx-DMA
RCG becomes available for user traffic as well.
• If the terminal succeeds to log on (establishing a lock on an HRC demodulator in the hub), the
HRC controller assigns capacity to the terminal based upon the settings that were configured
during terminal provisioning. The HRC controller sends every second HRC update messages
containing information about the MODCOD, symbol rate, carrier frequency and output power.
ACM is always enabled on the HRC Mx-DMA return link. Hence the information sent via the HRC
updates can change every second based upon return link quality.
• If for some reason the HRC controller notices that all logged on terminals suddenly log off, then the
complete HRC Mx-DMA RCG capacity temporarily becomes logon capacity for a period of
approximately 60 seconds in order to allow the terminals to simultaneously log on again. If there
are still terminals that did not succeed to log on during this temporary period, they need to log on
again on a one by one basis as described earlier.
Logon Times
As described in Time and Frequency Synchronization , BUC and Modem Frequency Synchronization
and Doppler Effect on Terminals there are uncertainties which have an impact on the carrier
placement. The HRC controller uses guard bands to deal with these uncertainties. The HRC
demodulators do frequency sweeps to scan for the carrier within the uncertainty region.There is
quasi linear relation between uncertainty and logon time. A typical uncertainty of 3 kHz corresponds
with a logon time of 3 seconds. Also note that at startup of a hub, the HRC controller measures the
offset first. This is done based upon the first terminal that logs on, using a big guard band.
Consequently it can take some minutes for the first terminal to log on. Once the offset is determined,
the HRC controller lowers the uncertainty to a typical value of 3 kHz for all other terminals that need
to log on. It is also possible to reset the frequency offset of the HRC controller via the NMS GUI. This
triggers the same behavior as when starting up the hub.

Terminals
HRC Limitations
• MCD6000, MCD7000 and MCD7500_HRC support a maximum of 24 terminals. The
MCD7500_HRC68 supports 12 terminals. However, it is possible to provision more HRC terminals
per HRC demodulator than this maximum number of demodulated HRC terminals.
• The maximum bandwidth of a frequency slot is 36 MHz or 72 MHz depending on the demodulator
capability. However, it is advised to limit the bandwidth of the frequency slot to the sum of the
bandwidths used by the HRC return capacity groups. This improves the frequency selectivity of the
HRC receivers meaning that the HRC demodulator scans its frequency window more accurately.
• The number of HRC demodulators assigned to one frequency slot should be lower than or equal
to eight. This means that a maximum number of 192 terminals or 96 terminals in case of
MCD7500_HRC can log on within one frequency slot. It is possible to provision more terminals but
if the maximum number of demodulated terminals is reached, the other provisioned terminals will
not be able to become operational.
• HRC return capacity groups and frequency slots can not overlap in frequency.
• HRC frequency slots should not overlap with resources of other return link technologies.
Refer to Newtec High Resolution Coding™ for more details about this return link technology.
Ulogon
In the previous logon modes, the hub explicitly asks terminals to transmit on one or a set of specific
logon carriers. The logon carrier is not a contention channel and the hub uses a logon carrousel to
let terminals join the network in a quasi-sequential fashion. Therefore, it can take a long time before
a terminal is logged in, especially if you have a massive logon scenario after a network outage.
Furthermore, in a multi-beam scenario, a terminal will be polled in each beam as the hub does not
know in which beam each terminal currently is.
For example: In avionic applications, about 50% of the provisioned terminals are on-line. In case of
400 terminals provisioned in 1 beam, 200 terminals are solicited by the hub’s HRC mechanism to get
on-line. As it takes up to 3 seconds to detect if a terminal is on-line and since the terminals are polled
in a sequential manner, it takes about 600 seconds for the last terminal to be able to logon. The
average logon time will be about 300 seconds.

Terminals
Ulogon or universal logon was introduced to tackle the above issues.

Ulogon can be enabled when the logon mode for the HRC return capacity group is set to logon
bandwidth mode. Ulogon should also be enabled per terminal during terminal provisioning.
In ulogon mode the HRC controller sends a unicast message to the ulogon activated terminal,
requesting Ulogons. When the terminal receives this message and wants to login, it sends a ulogon
burst to the hub, informing the HRC controller that it wants to come on line and in which beam that is.
The HRC controller sends an HRC Start Trigger to the specific modem using the "normal" solicited
logon mechanism. Ulogon triggers solicited logons only for the terminals that want to come online,
and in that specific beam.
In normal circumstances (no queue) a logon in ulogon mode takes about four seconds: one second
for the ulogon, and three seconds for the traditional logon.
Ulogon can handle 40 logons per second in a fixed 510 kHz logon bandwidth and maximum 300 kHz
frequency uncertainty down-to terminals having an Es/N0 = -12 dB (with extended VL-SNR
enabled).
The log on capacity for ulogon within the HRC return capacity group is fixed to 510 kHz. This
reserved bandwidth is not released when the terminal login queue is empty.
The table compares the solicited logon modes with the ulogon mode. Note that the numbers are
examples and might deviate from the actual times due to customer specific size and configuration.
Number of beams 1 1
Number of 400 1,000

terminals
provisioned
% of active 50% 50%

terminals
Number of 200 500

terminals on line
Solicited logon Ulogon Solicited logon Ulogon

modes modes
Login rate 0.33 login/s 40 login/s 0.33 login/s 40 login/s

Terminals
Time to poll a 3 seconds 3 seconds

terminal
Maximum initial 600 seconds 11 seconds 1500 seconds 27.5 seconds

logon time for or 25 minutes
other terminals
Average initial 300 seconds 5.5 seconds 750 seconds 13.8 seconds
logon time for or 12.5
other terminals minutes
Ulogon is typically used for mobile terminals (COTM and COTP). The solicited logon modes is much
less of a problem for fixed terminals: when this type of terminal is logged on, they typically remain
logged on.
The Ulogon method is efficiently scalable to a very large number of terminals with limited bandwidth,
both in nominal operation as well as in a disaster recovery scenario. This ulogon method also has
following capabilities:
• Handling logons of a significant population of varying off/online mobile terminals;
• Efficiency/effectiveness in scenarios with high frequency uncertainty at the hub (e.g. due to
Doppler);
• Efficiency/effectiveness for low receive power spectral density;
• Better tradeoff between logon bandwidth and time to logon in high frequency uncertainty
applications (mobility & unsynchronized BUC) than solicited logon modes.
Mx-DMA Terminal Logon Priority

In HRC Mx-DMA, all non-operational terminals are queued. The terminals in this logon queue are
prioritized in following order (1 the highest, 4 the lowest):
1. Terminals that switch beams; for these terminals ulogon is not used;
2. Terminals for which a uLogon burst has been received; within this group there is no
prioritization;
3. Recently disconnected terminals;
4. Recently provisioned terminals;
5. Non-prioritized (all other).
Login of priority 4 and 5 terminals may be canceled for priority 1 and 2 terminals.
9.6.5.4 MRC Logon Procedure
MRC Universal logon or MRC Ulogon is the default way of logging on modems using the NxtGen
Mx-DMA MRC return link technology. MRC Ulogon is direct and unsolicited:
• Direct, as there are not multiple satellite round trip messages required to log on a terminal. MRC
Ulogon signaling consists of:
– Forward messages. Used to configure the logon channel and instructs terminals on how to
use it. These messages include the time and frequency clock reference, the ulogon
channel properties (frequency, bandwidth waveform parameters and channel access
restrictions), which are broadcasted periodically to the terminals, and the Start Trigger
message.
– Logon request return message. It identifies the terminal, the ulogon channel, the capacity
request and the terminal capabilities.

Terminals
• Unsolicited, as the terminals take autonomously the initiative to log on to the network, overbook
the logon capacity and put in place retry mechanism in case of collision.
A fixed bandwidth of 510 kHz of the NxtGen Mx-DMA MRC return capacity group is reserved as
logon capacity. If the Ulogon feature is disabled in an MRC RCG , a valid Channel ID for another
RCG Ulogon channel must be set.
At least one Ulogon channel must be configured per MCD7500.
MRC Ulogon triggers logons only for terminals that want to come online and only in the beam where
they are. The terminal flags the hub that it wants to come online by sending a unicast Ulogon
request. Ulogon request message contains a capacity request to allow direct assignment of the
correct return traffic volume. As a response, the hub sends a Start Trigger message to the specific
modem. The state of the terminal goes to logged on.
In case there is no traffic from the terminal for a certain period of time, the state changes to
idle/logged off.
The Idle Log off Time can be set during Service Profile Provisioning and by default is
10 seconds.
During idle/logged off state, the modem is synchronized but not operational. If the terminal starts
transmitting again, the traffic is detected, and a Ulogon request message is sent to change the state
to logged on.
The following table shows the Ulogon request message properties.
Es/N0 From -10dB
Modulation Schemes Pi/2 BPSK
Symbol rate 200 kChips/s (SF=5)
CR turbo code 1/3
Packet length 28 bytes
Roll-Off 5%
9.6.6 Step 5: Network Logon

Previous steps are required to setup the layer 1 (physical) and layer 2 (Data Link) connectivity of the
modem. After these steps, it is time to establish layer 3 (IP network) connectivity. To achieve this,
two actions are performed:
1. Authentication
2. Setup of an eTCP association
During layer 2 setup, the (unique) MAC address of the terminal is used as identification. For layer 3
setup, authentication is done based upon X509 certificates. ST Engineering iDirect acts as
Certification Authority (CA) and generates master private/public key pairs as well as individual X.509
certificates/private key pairs for every legitimate terminal manufactured by ST Engineering iDirect.
Consequently an X.509 certificate and a public/private key pair is permanently stored in memory on
each modem during production.
During layer 3 login, a terminal encrypts its certificate using the public key of the hub and presents it
to the TCS (the IP address of the TCS was signaled to the terminal via the TIM). The TCS within the

Terminals
hub decrypts the received certificate using a private key which was generated during hub
installation.
The encryption is based on the AES-128 algorithm, with an effective key length of 56
bits.
If the certificate is valid, the TCS sends an acknowledgement, which contains the user-key to setup
the eTCP association, to the terminal which is encrypted with the terminal public key. The terminal
decrypts this acknowledgement using its private key. If theTCS detects that the certificate is wrong,
it responds with an error code indicating that the request was unauthorized.
After a successful authentication, the terminal can start with setting up the eTCP association
between the terminal and the hub. This is done based upon the user key it received during the
authentication phase.
The eTCP association can be compared with a kind of IPSec tunnel, which is used between the so
called TelliNet client software running on the terminal and the TelliNet Server deployed on the TAS
(Traffic Acceleration Server) within the hub. Hence ingress TCP/IP traffic (on hub or terminal) is
transformed into eTCP (enhanced TCP) and gets restored back to TCP/IP at the other (egress) end
of the eTCP association.
As soon as the eTCP association is accomplished, the terminal is fully operational and ready to send
and receive user traffic over the satellite link.

Terminals
9.7 Return Technology Switching

A terminal supports multiple return link technologies: 4CPM, MRC, HRC and DVB-S2(Ext). The
actual used return link technology is determined during terminal provisioning. Refer to Modem Types
on page 103 to know which return link technologies are supported by which type of modem.
It is possible to switch to another type of return link technology. This is achieved by re-provisioning
the terminal via the terminal provisioning interface or via REST API.
Multiple switch-over scenarios exist. For every scenario, the following flow applies:
• The operator re-provisions the terminal via the NMS, either via the GUI or via REST API.
• The NMS informs the RCM or return control manager about the return link technology switch.
• The RCM triggers the controller of the "old" return link technology to send a log off TIM towards
the terminal.
• The RCM triggers the controller of the "new" return link technology to send a log on TIM towards
the terminal.
• The terminal breaks the layer 2 return link connectivity and sets up a new layer 2 return link
connectivity.
• The terminal fetches its configuration file, establishes the layer 3 (IP network) connectivity and is
operational again using the 'new' return link technology.
The downtime of a terminal during these switch-over scenarios is in best case less than 10 seconds,
but keep in mind that the downtime depends on conditions such as availability of demodulators or
possible queue of terminals logging in.
9.8 Terminal Usage

The following paragraphs describe the different scenarios for terminal usage and applicable
features.
9.8.1 Terminology
9.8.1.1 Fixed or Mobile Terminal
Terminals can be considered as fixed or as mobile:

• Fixed: The terminal remains at the same geographical location during operation.
• Mobile: The terminal has no fixed location. Two mobility use cases can be distinguished:
– Communications on the Pause (COTP): The terminal moves between locations, but is not
operational when moving. Hence its speed equals zero when it is operational.
– Communications on the Move (COTM): The terminal moves between locations, and is
operational when moving. Hence the terminal has a certain speed and optionally a certain
acceleration when it is operational. The terminal (for example, on a plane or a ship) can
either move between different beams or it can remain within a single beam. For these
terminals, the Doppler effect needs to be compensated (see Doppler Effect on Terminals
on page 165).
9.8.1.2 Single Beam or Multi-beam Operation
A second distinction is whether the terminal operates in a single beam or in multiple beams:

Terminals
• Single beam: A fixed or mobile terminal operates within a single beam and is provisioned in one
satellite network. These terminals are linked to one pair of forward and return link resources via a
static attachment.
• Multi-beam: A mobile terminal can operate in multiple beams. These terminals are linked to
forward and return link resources of each potential satellite network via a dynamic attachment
profile.
9.8.1.3 Attachment Type
During terminal provisioning, a terminal is attached to the satellite resources of a satellite network.
There are two types of attachments:
• Static attachment type: This implies that a terminal operates within a single beam.
– A terminal is linked to forward and return link resources of the satellite network, which is
linked to the beam, and it is only provisioned in one satellite network.
– A static attachment defines a beam, a satellite network and a corresponding forward and
return pool.
• Dynamic attachment type: This implies that a terminal can become operational in more than one
beam.
– A terminal is linked with the forward and return link resources of each satellite network in
which the terminal should exist via an attachment profile.
– An attachment profile includes a number of Home Network Attachments. A home network
attachment defines a beam, satellite network and a corresponding forward and return pool.
An attachment profile can also include a number of Visited Network Attachments. A

visited network attachment defines the beam resources of the networks of another
operator. This is interesting in the context of a roaming agreement between two
operators.
If you want to remotely configure the satellite configuration of the terminal, the
terminal must use the dynamic attachment type, even when it is not operating in
multiple beams.
For more information about remote terminal satellite configuration, refer to
Remote Terminal Satellite Configuration on page 151.
9.8.2 Use Cases

This section describes the following use cases:
• Fixed or COTP terminal operating in single beam
• COTM terminal operating in single beam
• Fixed terminal operating in unknown beam
• COTP terminal operating in multiple beams
• COTM terminal operating in multiple beams
9.8.2.1 Fixed or COTP Terminal Operating in Single Beam
In this scenario, the terminal remains at the same geographical location during operation. This can
be a single location (fixed) or multiple locations within the same beam. When moving between
multiple locations, the COTP terminal is offline.

Terminals
The fixed or COTP terminals can be subject to small movements; for example when they are located
on an oil rig. For these terminals, the average speed is very low but there is an acceleration
component: a terminal on an oil rig moves up and down because of the motion of the sea. These
terminals typically use stabilized antennas to keep connectivity with the satellite and the return link
controllers within the hub need to take this movement into account when allocating return link
resources. Therefore, you can specify the maximum speed and acceleration of the movement for
these terminals. This is done via the Mobility tab of the terminal provisioning interface.
Refer to Doppler Effect on Terminals on page 165 for more details.
9.8.2.2 COTM Terminal Operating in Single Beam
A COTM terminal operating in a single beam remains operational during its route within the beam.
The terminal has a certain speed and optionally a certain acceleration when it is operational and
typically uses a stabilized antenna to keep connectivity with the satellite and the return link
controllers within the hub need to take this movement into account when allocating return link
resources.
When you are dealing with a moving terminal, you should specify its maximum speed and
acceleration. This is done via the Mobility tab of the terminal provisioning interface.
Refer to Doppler Effect on Terminals on page 165 for more details.
9.8.2.3 Fixed Terminal Operating in Unknown Beam
For managing a fixed terminal of which you do not know the location of installation, you can use the
Auto Attachment feature for whitelisted terminals. A whitelisted terminal can log on to a satellite
network without being provisioned beforehand.
To set up the Auto Attachment feature, execute the following steps:
• Enable the Auto Attachment feature for each satellite network in which the terminal can potentially
come online.

Terminals
When enabled, the FTB message in the forward link not only includes the pop-ID with the MAC
addresses of all provisioned terminals but also includes the auto attachment signaling. The
signaling contains the broadcast MAC address and the maximum Power Spectral Density or
PSD for logon requests.
• Create an Auto Attachment Prototype where you add the MAC address of the whitelisted terminal
and define the modem template that should be used to provision the whitelisted terminals when
logging on.

Terminals
When a whitelisted terminal is installed and pointed, it locks on a forward carrier and parses the FTB
message. When it sees that auto attachment is enabled for the satellite network and its MAC
address is not included in the pop-ID (it is not provisioned), the terminal will send a 4CPM logon
request. This request is received by the 4CPM controller of that satellite network. The Hub Module
Management System or HMMS will periodically poll the 4CPM controller of each satellite network on

Terminals
which auto attachment is enabled to get the "First Sign of Life" messages. From these messages, it
will filter out the provisioned MAC addresses and send the other (unknown) MAC address to the
NMS. If the NMS verifies that the MAC address is part of an Auto Attachment Prototype, it will
provision the terminal based on the modem template of the Auto Attachment Prototype to which it
belongs. It will also delete the terminal from the Auto Attachment Prototype.
It is possible that the template provisions the terminal in another satellite network than it is trying to
log on to. This is no problem as long as the beam is the same. If the terminal should be provisioned
on the satellite network of another beam, the terminal is not provisioned.
If the NMS does not find the MAC address, the terminal is not provisioned.
9.8.2.4 COTP Terminal Operating in Multiple Beams
Beam roaming is only supported for terminals that use HRC Mx-DMA or MRC
NxtGen Mx-DMA as return link technology and that are linked to a dynamic
attachment profile.
Terminals can travel from one beam to another beam without being operational during the travel. For
example in case of Fast New Gathering or FNG and Satellite News Gathering or SNG. To avoid that
you have to re-provisioning the terminal from one satellite network to another, you can use the
following workflow.
Assume we have a COTP terminal that can be operational in Beam 1/ SatNet 1 and Beam 2 / SatNet
2.
The following configuration should be set:

• In the Service tab of the terminal provisioning interface, the terminal attachment type must be set
to dynamic and the terminal must be linked to an Attachment Profile including a home network
attachment for each satellite network. Each attachment defines a beam, satellite network, forward
pool and return pool.
Provisioning the terminal on multiple satellite networks implies that the return
controller reserves capacity on each involved demodulator. In case of HRC, MCD
overbooking might have to be enabled as the number of terminals that can be
provisioned is limited. See MCD Overbooking on page 148 for more information.
• In the Mobility tab of the terminal provisioning interface, Beam Roaming must be enabled.

Terminals
Enabling beam roaming ensures that the capacity reserved on the HRC or MRC demodulators
on which the terminal is not active, is released.
• Multiple beam configurations must be defined in the terminal modem. Beam configurations are
visible via the Satellite Interface menu of the modem GUI. The terminal operator selects the beam
identifier of the beam it is moving to.
When using AIBS, the terminal can also automatically select the initial beam. For
more information, refer to Automatic Initial Beam Selection on page 139.
AIBS implies that antenna controlling is enabled as well.
If the required beam settings are not available in the modem:

• The hub operator can use the Remote Terminal Satellite Configuration on page
151 feature to add beams.
OR
• The terminal operator can add the required beam settings via the modem GUI.
Refer to the Modem User Manual for more information about modifying the
satellite interface settings.
The terminal locks on the forward link of the "new'" beam and receives a trigger from the hub to
logon using the HRC logon carrier. As soon as the terminal has established return link connectivity,
the NMS notifies the system to stop advertising the terminal network in SatNet 1, and instructs the
system to start advertising the terminal network in SatNet 2. Route advertisement can be done via
OSPF or BGP.

Terminals
To allow this 'dynamic' route advertisement, the Logon state based radio button is automatically
enabled in the Layer 3 tab when provisioning the modem.
As a result, the terminal continues to use the same IP addresses.
9.8.2.5 COTM Terminal Operating in Multiple Beams
Beam roaming is only supported for terminals that use HRC Mx-DMA or MRC NxtGen
Mx-DMA as return link technology and that are linked to a dynamic attachment profile.
COTM terminals are terminals that move during operation. They have a certain speed and optionally
an acceleration and they can pass multiple satellite beam areas during their journey.
COTM terminals that can operate in multiple beams should have Terminal Mobility, Automatic
Initial Beam Selection (AIBS) and Automatic Pointing enabled in the local modem GUI.
At the hub-side, the terminals should be provisioned in all beams that they can encounter during
their operation. The provisioning is done using Attachment Profiles, which consists of multiple
home network attachments. Each attachment corresponds with a beam, a satellite network and the
corresponding forward and return resources. The terminal should also have COTM and Beam
Roaming enabled. This configuration is done during terminal provisioning.

Terminals
The COTM terminal operating in multiple beams can come online in any beam it supports. As it is
not possible to predict in which beam the mobile terminal will become operational, AIBS and
Automatic Pointing is used. AIBS controls the initial network acquisition process for the terminal
and selects a beam using the geographical position of the terminal. Automatic pointing will make
sure that the terminal antenna is optimally pointed towards the beam. AIBS and automatic pointing
are entirely terminal-side driven. For more information about the initial beam selection, refer to
Automatic Initial Beam Selection on page 139.
COTM terminals use the OpenAMIP protocol to instruct the antenna controller to target a
particular satellite. The exchanged information includes, but is not limited to, satellite
longitudinal position, tracking frequencies, LNB band selection, polarity
(horizontal/vertical), cross pol / co-pol selections.
Once operational, the terminal can move from one beam to another. The terminal should be able to
switch between different satellite beam areas without losing the satellite connection. This can be
done using a Mobility Manager. The mobility manager decides to switch beams based on the
position of the terminal and some specific beam information, such as contours, cost, and load.
Dialog provides two types of mobility manager:
• The Central Mobility Manager located at the hub side. In this case the modem sends its GPS
coordinates over the satellite link to the mobility orchestrator. The central mobility manager gets
the GPS coordinates of the terminal from the Mobility Orchestrator and applies the configured
beam switching logic and business rules to make a beam switching decision if needed.
• The Remote Mobility Manager located at the terminal side. In this case, the modem does not
send its GPS coordinates over the satellite link, since they could be considered as sensitive
information. The remote mobility manager, which is integrated In the modem, periodically monitors
the position of the terminal and applies the locally configured beam switching logic to make a
beam switching decision if needed.
When the mobility manager takes the beam switching decision, it sends the target beam to the
Mobility Orchestrator and the mobility orchestrator organizes the actual beam handover. The
mobility orchestrator is an application running on the hub.
The central mobility manager can be an in-house add-on to the Dialog platform or it can be a third
party application running on an external server. The central mobility manager communicates with the
mobility orchestrator using the Mobility API. Make sure to enable the Send status updates to
DMM parameter in the local modem GUI in order for the terminal to send its GPS coordinates to the

Terminals
mobility orchestrator. The mobility orchestrator will send these coordinates to the central mobility
manager.
Remote mobility management is disabled by default. To enable it, make sure to:
• Select Remote Mobility Management check box in the Mobility tab of the Terminal Provisioning
interface.
• Disable the Send status updates to DMM parameter in the local modem GUI. This will make
sure that the terminal does not send GPS coordinates to the mobility orchestrator.
Both types of mobility manager can coexist on the Dialog platform. The Forward Table Broadcaster
(FTB) includes a POP-ID that indicates whether or not remote mobility management is enabled.
For more information about beam selection and switching, refer to Target Beam Selection on page
141 and Beam Switching Mechanism on page 142.
For more information about the configuration, refer to the Modem User Manual and to
the Newtec Dialog Configuration User Guide.

Terminals
9.8.2.5.1 Automatic Initial Beam Selection
An important mobility aspect is the ability for the satellite modem to autonomously acquire the
network. As it is not possible to predict in which beam a multi-beam terminal will log on, Dialog
implements the Automatic Initial Beam Selection or AIBS. AIBS is used to control the initial network
acquisition process.
AIBS is supported on all modems, except MDM2010, MDM2200, and MDM2210.
AIBS allows the modem to automatically select the best satellite beam from the list of configured
beams at startup of the modem.
If the required beam settings are not available in the modem:

• The hub operator can use the Remote Terminal Satellite Configuration on page 151
feature to add beams.
OR
• The terminal operator can add the required beam settings via the modem GUI. Refer
to the Modem User Guide for more information about modifying the satellite
interface settings.
To enable AIBS, select Auto as Spot Beam value in the local modem GUI during the installation of
the terminal.
To select a beam, the terminal has to know its location on earth. Therefore, the Antenna Control
Unit or ACU sends the GPS coordinates at regular intervals to the terminal using the OpenAMIP
protocol.
For more information about the ACU, refer to the 'automatic pointing' section in
Terminal Installation .

Terminals
When the modem knows it location, it parses all the configured beams to find out which beams are
eligible. The modem uses GXT files, which contain beam contour data, to verify if it is located inside
the contours of a beam. For more information about GXT files, refer to GXT Files on page 146.
When multiple beams are eligible the following policies are used in the specified order to select the
initial beam.
• The terminal is allowed to transmit in the beam (no exclusion zone).
• The cost of the beam; the lower the cost, the more eligible the beam is.
• The beam gain at the terminal position; the higher the gain, the more eligible the beam is.
• The beam elevation angle at the terminal position; the higher the elevation angle, the more
eligible the beam is. The elevation angle determines which beam is closest to the modem. A
higher elevation means a closer distance in longitude. A higher elevation has better link quality
than a lower elevation.
When the modem has found the preferred beam, it sends the corresponding antenna pointing data
to the ACU. If the parsing of the beams did not result in an eligible beam, no beam is selected!
The selection mechanism for the initial beam and final traffic carrier is illustrated in the following
example:
Multiple satellite networks can belong to the same beam. Hence, multiple forward carriers can be
used on one beam. Every satellite network is linked with one forward link. In this example, there are
two beams and each beam contains three satellite networks or there are three forward carriers per
beam. Within a beam, one of these three forward carriers can be used as initial carrier (marked in
green). Suppose a terminal is provisioned on SatNet A3 and SatNet B3. Suppose as well that the
AIBS algorithm applied by this terminal results in the selection of beam A as initial beam. The

Terminals
terminal will use the forward carrier of SatNet A2 as initial receive carrier, parse all signaling tables
and finally be redirected to SatNet A3 and end up using the forward carrier of SatNet A3. The
forward carrier of SatNet A3 contains the signaling to setup the return link transmission.
If beam B would have been selected as initial beam, the same mechanism is applied (use forward
carrier B1 as initial carrier and end up on SatNet B3).
Note that this mechanism allows to change the settings of the forward carrier of SatNet A3, without
the need to change the satellite interface settings of the terminal (as the modem continues to use
the forward carrier of SatNet A2 as initial carrier).
The hub operator can use the Remote Terminal Satellite Configuration on page 151

feature to set the initial carrier.
OR
The terminal operator can set the initial carrier via the local modem GUI. Refer to the
Modem User Guide for more information about modifying the satellite interface
settings.
9.8.2.5.2 Target Beam Selection
Once operational, the COTM multi-beam terminal can move from one beam into another. The
mobility manager takes a beam switching decision based on mobility-related data, such as terminal
position, beam contour files, beam costs, and policy rules based on beam KPIs. One set of rules is
used to decide whether the terminal is moving away from the current beam, and one set of rules is
used to define which new beam should be used.
The way the mobility-related information is gathered and the policy rules are defined and applied,
depends on the type of mobility manager: central or remote.
Central Mobility Manager

The terminal periodically sends its GPS coordinates, received from the ACU, to the mobility
orchestrator over the air. The mobility orchestrator forwards the position to the mobility manager via
the mobility API, which is a REST API. The central mobility manager is located at the hub-side.
The mobility manager is configured with beam information and policy rules. Policy rules can be
based on standard KPIs but you can also define additional KPIs, such as number of operational
terminals in the beam and forward EsN0. The standard KPIs are:
• G/T of the terminal in beam
• EIRP of the terminal in beam
• Cost of the beam
• Distance to the edge of the beam
• Antenna elevation
• Antenna skew
• Exclusion zone
For more information about the configuration of policy rules, refer to the Newtec Dialog
Mobility Manager User Guide.
Remote Mobility Manager

Terminals
The remote mobility manager is integrated in the modem and monitors the position of the terminal.
The ACU periodically sends the GPS coordinates of the terminal to the remote mobility manager.
The coordinates are not sent over the air. The beam information is configured in the modem, either
via the modem GUI or the remote satellite configuration. The type and number of policy rules are
fixed. The values to which the rules are checked are configurable in the local modem GUI (as
expert).
Every 10 seconds the modem checks the KPIs of the used beam. The following policy rules are
used to verify if another beam should be selected:
• The terminal moves outside the beam (outside lowest gain contour)
• The terminal moves into an exclusion zone associated to the current beam.
• The beam gain at the terminal position is smaller than the configured minimum gain.
• The elevation angle at the terminal position is smaller than a configured minimum satellite
elevation angle.
• The skew angle at the terminal position is larger than a configured maximum satellite skew angle.
The following policy rules are used in the specified order to select the new beam.
• The terminal is allowed to transmit in the beam (no exclusion zone).
• The cost of the beam; the lower the cost, the more eligible the beam is.
• The beam gain at the terminal position; the higher the gain, the more eligible the beam is.
• The beam elevation angle at the terminal position; the higher the elevation angle, the more
eligible the beam is.
9.8.2.5.3 Beam Switching Mechanism
The mechanism described in this chapter is valid when using NxtGen Mx-DMA MRC
and Mx-DMA HRC return technologies
When the mobility manager has selected the target beam, it sends the new beam to the mobility
orchestrator.
The mobility orchestrator handles the actual beam switch across the different components of the
Dialog platform to ensure a seamless handover. It instructs the terminal to switch beams, makes
sure that the terminal is correctly configured in the NMS and that the routes are advertised.
The mobility orchestrator is also used to orchestrate the logon behavior across all eligible beams. A
mobile terminal is provisioned on multiple satellite networks via its attachment profile. Provisioning
the terminal on multiple satellite networks implies that the return controller reserves capacity on each
involved demodulator in all satellite networks. To avoid “waste” of logon capacity on other
demodulators, the mobility API instructs the controller to lock the modem on unused beams. If the
mobile terminal switches to another beam, the previously active beam goes into ‘lock state’ and the
new active beam gets unlocked allowing the modem to logon to that new beam. A terminal is only

Terminals
locked on other beams if it is logged on in a beam. If the modem is not logged on in any beam, then
logon capacity for the modem is available on all satellite networks (MCDs).
General principles
The mobility orchestrator monitors the return controllers for the terminal operational state (logged
on or logged off). This state triggers the mobility orchestrator to instruct the controller(s) to lock or
unlock the terminals in the beam in which the terminal is provisioned.
The mobility orchestrator keeps track of a terminal state. Following states exist:
• not operational and unlocated, when the terminal is logged off and the mobility orchestrator did
not recently receive the terminal's position.
• not operational and located, when the terminal is logged off but the mobility orchestrator
recently received the terminal's position.
• operational and unlocated, when the terminal is logged on but the mobility orchestrator did not
recently receive the terminal's position.
• operational and located, when the terminal is logged on and the mobility orchestrator recently
received the terminal's position.
• switching, when the terminal is in the process of a beam switch.
Terminal Route Announcement

When a mobile terminal moves from one beam to another, the layer 3 routes on the edge router of
the customer's network should be updated ensuring that the terminal traffic is routed to the correct
satellite network. Route advertisement towards the edge router is done by the DEM VM and uses a
dynamic routing protocol. The dynamic routing protocol can be OSPF or BGP depending on the
network configuration.
In the flows described below, the terminal routes are announced on the target beam before they are
stopped being announced on the original beam. This is called Make Before Break Route
Advertisement.
Make Before Break Route Advertisement is only supported when your Dialog system has a
cloud-based NMS.
When your NMS is not cloud-based, the DMM does not communicate directly with the DEM. In this
case, the DMM configures the NMS with the ID of the target satellite network and the DEM polls the
NMS for changes. Upon a change:
1. The DEM of the original satellite network will delete the terminal routes and stop announcing the
routes towards the customer's edge router.
2. The DEM of the target satellite network will statically configure the new routes and consequently
announce the routes towards the customer's edge router.
Both steps are triggered at the same time and you cannot predict which one will come first. The
dynamic routing convergence takes time and this can result in traffic interruptions of 40 seconds
during a beam switch. With the Make Before Break Route Advertisement traffic interruption is highly
reduced (8 to 12 seconds).
Central Mobility Manager

The complete beam switch and terminal state flow in case of central mobility manager is as follows:
1. At terminal startup, the terminal is logged off and its terminal state is not operational and
unlocated.
2. The mobility orchestrator instructs the controller of all beams in which the terminal is
provisioned to unlock the terminal.

Terminals
3. When the terminal logs on, the mobility orchestrator changes the terminal state to operational
and unlocated. When the mobility orchestrator receives the terminal's GPS coordinates, it
changes the state to operational and located.
4. The mobility orchestrator instructs the controller of all beams, except the active one, to lock the
terminal.
5. The central mobility manager receives the GPS coordinates from the mobility orchestrator.
6. The central mobility manager makes a beam switch decision based on the mobility-related
information and the policy rules, and instructs the mobility orchestrator to switch a terminal to
another target beam. The mobility orchestrator changes the terminal state to switching.
7. The mobility orchestrator informs the DEM that serves the satellite network of the target beam
about the beam switch via an MQTT event.
When using OSPF or BGP at the hub side, this MQTT event triggers the DEM to start
announcing the terminal route towards the customer edge router. This is called conditional
route announcement.
Conditional route announcement is not supported when BGP is used as the routing
protocol at the hub side AND at the terminal side. In this case, the BGP protocol itself
takes care of the route advertisement.
8. The mobility orchestrator instructs the controller of the target beam to unlock the terminal. The
controller of the target beam starts inviting the terminal to log in.
9. The mobility orchestrator triggers the Forward Table Broadcaster (FTB) of the active beam
satellite network to request the terminal to switch to the target beam.
10. The terminal logs out of the active beam and the controller of the active beam notifies the
mobility orchestrator of the new terminal state (logged off).
11. The terminal will try to log in to the target beam. Two scenarios exist:
– The terminal logs in within the switch timeout:
• The controller of the target beam notifies the mobility orchestrator of the new terminal
state (logged on).
• The mobility orchestrator informs the DEM of each available satellite network about the
active beam.
• If the active beam corresponds with the satellite network of the DEM, the DEM
should continue to announce the route.
• If the active beam does not correspond with satellite network of the DEM but the
DEM was announcing the route before, meaning that this is the DEM of the
previously active beam, this DEM should stop announcing.
• The mobility orchestrator instructs the controller of the previously active beam satellite
network to lock the terminal.
• The terminal state is operational and located.
• The flow is resumed from step 5.
– The terminal does not succeed to log in within the switch timeout:
• When the switching timeout expires, the mobility orchestrator sets the terminal state to
not operational and unlocated.
If the terminal is operational and located but for some reason logs out, the controller of the active
beam notifies the mobility orchestrator and the mobility orchestrator changes the terminal state to
not operational and located. At that moment, two scenarios exist:

Terminals
• If the controller of the last active beam notifies the mobility orchestrator that the terminal is logged
on within position timeout, the terminal state changes to operational and located and the flow is
resumed from step 5.
• If the controller of the last active beam did not notify the mobility orchestrator that the terminal is
logged in within position timeout, the terminal state changes to not operational and unlocated
and the flow is resumed from step 2.
Remote Mobility Manager

In case of a remote mobility manager, the mobility orchestrator has no position information of the
terminal. To let the mobility orchestrator know that it is still alive, the terminal will send heartbeat
messages. As long as the mobility orchestrator receives the messages within the position timeout,
the mobility orchestrator considers the terminal as located.
The complete beam switch and terminal state flow in case of remote mobility manager is as follows:
1. At terminal startup, the terminal is logged off and its terminal state is not operational and
unlocated.
2. The mobility orchestrator instructs the controller of all beams on which the terminal is
provisioned to unlock the terminal.
3. When the terminal logs on, the mobility orchestrator changes the terminal state to operational
and unlocated. When the mobility orchestrator starts receiving the terminal's heartbeat
message, it changes the state to operational and located.
4. The mobility orchestrator instructs the controller of all beams, except the active one, to lock the
terminal.
5. The remote mobility manager receives the GPS coordinates of the terminal from the ACU.
6. The remote mobility manager makes a beam switch decision based on the mobility related
information and the policy rules, and instructs the mobility orchestrator to switch a terminal to
another target beam. The mobility orchestrator changes the terminal state to switching.
7. The mobility orchestrator informs the DEM that serves the satellite network of the target beam
about the beam switch via an MQTT event.
When using OSPF or BGP at the hub side, this MQTT event triggers the DEM to start
announcing the terminal route towards the customer edge router. This is called conditional
route announcement.
Conditional route announcement is not supported:

• When BGP is used as the routing protocol at the hub side AND at the terminal side.
In this case, the BGP protocol itself takes care of the route advertisement.
• When static routing is used.
8. The mobility orchestrator instructs the controller of the target beam to unlock the terminal. The
controller of the target beam starts inviting the terminal to log in.
9. The mobility orchestrator triggers the Forward Table Broadcaster (FTB) of the active beam
satellite network to request the terminal to switch to the target beam.
10. The terminal logs out of the active beam and the controller of the active beam notifies the
mobility orchestrator of the new terminal state (logged off).
11. The terminal will try to log in to the target beam. Two scenarios exist:
– The terminal logs in within the switch timeout:
• The controller of the target beam notifies the mobility orchestrator of the new terminal
state (logged on).

Terminals
• The mobility orchestrator informs the DEM of each available satellite network about the
active beam.
• If the active beam corresponds with the satellite network of the DEM, the DEM
should continue to announce the route.
• If the active beam does not correspond with satellite network of the DEM but the
DEM was announcing the route before, meaning that this is the DEM of the
previously active beam, this DEM should stop announcing.
• The mobility orchestrator instructs the controller of the previously active beam satellite
network to lock the terminal.
• The terminal state is operational and located.
– The terminal does not succeed to log in within the switch timeout:
• When the switching timeout expires, the mobility orchestrator sets the terminal state to
not operational and unlocated.
If the terminal is operational and located but for some reason logs out, the controller of the active
beam notifies the mobility orchestrator and the mobility orchestrator changes the terminal state to
not operational and located. At that moment, two scenarios exist:
• If the controller of the last active beam notifies the mobility orchestrator that the terminal is logged
on within position timeout, the terminal state changes to operational and located and the flow is
resumed from step 5.
• If the controller of the last active beam did not notify the mobility orchestrator that the terminal is
logged in within position timeout, the terminal state changes to not operational and unlocated
and the flow is resumed from step 2.
9.8.2.5.4 GXT Files
A GXT file can contain information of multiple beams that are available on the same satellite. Every
beam has its specific beam identifier within that file. There is at least one GXT file per satellite. GXT
files are typically provided by the satellite operators.
GXT is a standardized file format from the International Telecommunication Union (ITU).
The standard GXT format has the intention to provide a topographic description of the beam
coverage. This means that the diagrams in the GXT file provide a description of the beam coverage
in function of equal gain contours and bores (peaks) similar to a topographic map (relief map). This
type of data is used by the central mobility manager to perform gain interpolation at a specific point
of interest (the terminal position).
AIBS and the remote mobility manager do not perform gain interpolation but rely on a simpler
algorithm which determines if a point is within a specific contour associated to a specific gain value.
The contours therefore have a different meaning than the contours in the original GXT format.
Whereas the contour in the original GXT format is a contour containing points having the same gain
value, the contour used by the modem must enclose an area within which the gain is greater or
equal than a specific value.
Although in most cases both definitions result in the same contour, there are several corner cases
where this is not the case. Therefore the GXT files used by the mobility manager and those used by
the modem differ in a number of aspects (the ones used by the modem contain less information).
Another difference is that the central mobility manager is able to use different GXT files for the
uplink and downlink coverage of a beam, while the modem only uses one GXT file for a beam. This
GXT file represents the worst case coverage, which is usually the uplink coverage.

Terminals
The main requirements for the AIBS and remote mobility manager compatible GXT file are:
• All the contours for a given beam shall correspond to the same uplink or downlink gain.
• Only the bores that are within the selected contours shall be listed.
• Contours shall be closed, meaning that the start and end point are the same (by adding a segment
of the satellite horizon if needed).
• Contours shall be simply closed curves, meaning that the contour does not intersect with itself.
• The domain enclosed by a contour with gain value X shall represent a simply connected
geographical area where the beam gain ≥ X.
• A not simply connected but path connected geographical area where the beam gain ≥ X, shall be
broken down in multiple simply connected domains, each of which shall be represented by a
simply closed curve (contour) of gain X.
• If the geographical area where beam gain ≥ X is disconnected, then each of its simply connected
sub-domains shall be shall be represented by a simply closed curve (contour) of gain X.
• Contours shall preferably not contain segments smaller than 0.01 deg (~=1.1 km). It is advisable to
reduce the amount of points per contour to the strict minimum.
Transmit exclusions zones can be defined for each beam to accommodate regulatory restrictions. If
a terminal is located within an exclusion zone, the beam is excluded from the AIBS or beam switch
process.
GIMS is free software offered by ITU which allows you to visualize the beam contours
based on a GXT file.
9.8.2.5.5 Mobility API
The central mobility manager communicates with the mobility orchestrator using the mobility
API.
The central mobility manager is part of the ST Engineering iDirect portfolio but can also be created
by a third party using the mobility API description.
For more information about the mobility API, refer to the Newtec Dialog Mobility API
Description.

Terminals
9.8.2.5.6 Transponder-specific Power Offset during Logon
During logon, the terminal transmit power is derived from the nominal output power measured during
the line-up and the allocated and nominal bandwidth. The nominal values are defined using an
installation carrier on a specific transponder (i.e. reference transponder).
Mobile terminals will typically logon on transponders different from the reference transponder and a
transmit output power solely based on the reference transponder might cause issues of exceeding
the maximum Power Flux Density (PFD) allowed to be received at the logon transponder.
By taking into account the maximum PFD of the logon transponder and the reference transponder,
the hub can calculate a transponder-specific power offset, which can be added to the transmit output
power derived from the line-up settings. This ensures that the terminal output power is not driving
the logon transponder into saturation.
To make sure that the transmit power does not exceed the maximum terminal output power allowed
by regulation, the power is also compared to an off-axis power spectral density (PSD). The off-axis
PSD is calculated from the maximum terminal output power allowed by regulation for the reference
transponder and a level of allowed adjacent satellite interference for the return link.
The mobile terminal transmit power will be the lowest of both power values.
This feature is optional and only available for mobile terminals that use HRC Mx-DMA or MRC
NxtGen Mx-DMA.
9.8.2.5.7 MCD Overbooking
The HRC demodulator supports up to 24 return link carriers. Each HRC return link carrier consumes
specific 'processing resources' which implement the terminal logon process and the carrier reception
and demodulation. If the full MCD capacity is used (all the processing resources are in use),
additional HRC terminals can not log on.
When MCD Overbooking is enabled, the number of 'enabled' terminals can be larger than the
supported number of HRC return carriers.
MCD Overbooking can be enabled for an HRC frequency slot in the Return Frequency Plan
provisioning interface.

Terminals
9.8.2.6 Summary
The table below shows a summary of the different use cases
Return Link Attachment Beam Route

UC Description COTM
Technology Type Roaming Advertisement
Fixed or COTP
1 terminal - single All Static N* N Static
beam
COTM terminal -
2 All Static Y N Static
single beam
Fixed terminal - Static

3 All N* N Static (prototype)
unknown beam (prototype)
HRC Mx-DMA
COTP terminal -
4 MRC NxtGen Dynamic N* Y Dynamic
multiple beams
Mx-DMA
HRC Mx-DMA
COTM terminal -
5 MRC NxtGen Dynamic Y Y Dynamic
multiple beams
Mx-DMA
*You can enable COTM in case your modem is subject to small movements. This to counteract the
Doppler effect.
Where:
• Attachment Type
– Static: the terminal is provisioned in a single beam.
– Dynamic: the terminal is provisioned in multiple beams through an attachment profile.
• COTM
– Y: COTM is enabled, the terminal is operational while moving.
– N: COTM is disabled, the terminal typically operates in a fixed geographical location.
• Beam Roaming
– Y: Beam roaming is enabled, the terminal can move between multiple beams. These
terminals are known within the mobility orchestrator.
– N: Beam roaming is disabled, the terminal operates in a single beam.
• Route advertisement
– Static
– Dynamic (logon state based)

Terminals
9.8.3 Summary
The following table shows the compatibility between modem type and terminal use scenario:
MDM2xx0 MDM3xx0 MDM50x0
Fixed or COTP ✔ ✔ ✔
single beam terminal
COTM single beam ✔ ✔ ✔

terminal with speed restrictions
Fixed terminal ✔ ✔ ✔
(multiple beams)
COTP terminal ✔ ✔
(multiple beams)
COTM terminal ✔ ✔
(multiple beams)
Beam switching
Mobility API

Terminals
9.9 Remote Terminal Satellite Configuration

The remote terminal satellite configuration allows you to remotely update the satellite interface
settings of the modem.
The figure shows the satellite interface settings of the local modem GUI.
The satellite interface configuration defines the beam configuration including:

• Satellite properties such as orbital position.
• The settings of one or two initial carriers.

Terminals
– The terminal uses an initial carrier to lock on the actual forward traffic carrier. This concept
is described in the DVB-RCS standard. According to this standard, the terminal has to pass
three stages to lock on the actual forward carrier: lock on the initial carrier, lock on the
RMT carrier and lock on the actual forward traffic carrier.
The three carrier types can be combined in one carrier.

Every forward carrier in a Newtec Dialog hub can be used as an initial carrier, RMT carrier
and traffic carrier. The NIT contains the RMT carrier of all satellite networks within the
beam. The RMT contains the traffic carrier of all satellite networks within the beam.
– You can configure two initial carriers: one is the preferred carrier and the other one is the
backup carrier in case the terminal cannot lock on the preferred one.
• The settings of one or two pointing carriers.
– A pointing carrier is used during terminal installation and helps pointing the antenna. When
pointed, the modem will check the information in the NIT of the initial carrier with the
configured orbital position. In case of automatic pointing the modem is connected to an
antenna control unit or ACU. The modem will configure the ACU with the pointing carrier.
– You can configure two pointing carriers: one is the preferred carrier and the other one is the
backup carrier in case the terminal cannot point on the preferred one.
• Beam specific settings such as a beam contours and exclusion zones. These settings are used for
Automatic Initial Beam Selection or AIBS.
– With AIBS a mobile modem can automatically select the best satellite beam from the list of
configured beams at startup of the modem. AIBS is always used with automatic pointing.
Note: The GXT files can be viewed under the GXT Files menu item.
The satellite interface configuration is typically common to a set of terminals, which are subject to the
same service.

Terminals
There are several use cases where you would want to change the satellite interface configuration:
• Extending the capacity of a beam with a new satellite network and forward carrier, and moving
terminals to the new satellite network for load balancing reasons.
• Introducing a new beam in the network, which can be used by mobile terminals.
• Deleting a deprecated beam in the network.
• Signing a roaming agreement with a second operator to allow roaming of mobile terminals in the
second network. The beams of the second network should be added to the satellite configuration
of the modem.
• Migrating the forward carrier.
For more information about the use cases, refer to Use Cases on page 155.
The satellite interface can be configured locally using the modem GUI or using the JSON API.
These local changes however are not checked against the settings in the hub. Changing the
settings locally is prone to error and you can potentially prevent the modem from becoming
operational. You will also have to perform this configuration terminal by terminal.
The Remote Terminal Satellite Configuration feature guarantees consistency between the
settings in the hub and the configuration on the modem. The remote satellite configuration is created
from the data in the central Network Management System or NMS, and is downloaded by the
terminal. The feature also allows easy management of the satellite interface configuration of a group
of modems.
The satellite configuration is part of the modem configuration. The modem configuration also
consists of the ODU (outdoor unit) configuration and network configuration. These configuration sets
are not part of this feature but they are mentioned for the sake of completeness.
The terminal stores the remotely received satellite configuration as a candidate configuration. Next
to the candidate satellite configuration, the terminal also has a current configuration and a startup
configuration. The current configuration is the active one. The startup configuration is loaded into the
current one when a terminal reboots.
9.9.1 How It works
The remote satellite configuration feature is enabled on a terminal when the terminal is
linked to a Remote Configuration Profile where the Remote Satellite Config Enabled
parameter is activated.

Terminals
The remote terminal satellite configuration is defined through the static attachment or the dynamic
attachment profile in NMS. From this attachment (profile) the satellite configuration object and GXT
files are derived.
The operator can download the satellite configuration from the NMS, either in the
terminal overview or in the attachment profiles overview. The satellite configuration is a
zipped file including a config.json file and .gxt files.
The satellite configuration object includes one or more beams, each one with the following
information:
• ID;
• Initial carrier 1, which corresponds with the forward carrier of the related satellite network;
• Initial carrier 2, which is empty or which corresponds with the candidate settings for the forward
carrier;
• Pointing carrier 1, which corresponds with a beacon or with the forward carrier if the beacon is not
enabled;
• Pointing carrier 2, which corresponds with the forward carrier if the beacon is enabled, which is
empty if the beacon is not enabled and there are no candidate settings for the forward carrier, or
which corresponds with the candidate settings for the forward carrier;
• Orbital degrees;
• Hemisphere;
• Automatic pointing settings (optional);
• AIBS settings (optional). Note that AIBS cannot be enabled through the remote terminal satellite
configuration.
The NMS assigns a version to the satellite configuration and to each available GXT file. This satellite
configuration version is included in the satellite configuration object and the GXT file version is
added to the filename of the GXT file, which is part of the AIBS settings. When the operator changes
the attachment (profile) a new satellite configuration version is generated. Changes can include for
example, adding a beam, changing the satellite network or changing the beam. Uploading or
updating a GXT file will update the GXT file version and the satellite configuration version.
The Terminal Configuration Server or TCS collects the satellite configuration version from the NMS
and adds the GXT files to a shared file storage that can be accessed by an Apache http server.
The return link controller sends Terminal Information Messages or TIM messages when the satellite
configuration version changes. The TIM message is addressed to the terminal that is linked to the
corresponding attachment (profile) and for which the remote satellite configuration feature is
enabled.
After a login or when the terminal receives a TIM message, the terminal sends a
requestConfiguration message to the TCS, including its current satellite configuration version and
the version of the candidate satellite configuration. If there is no candidate satellite configuration, the
version is "null".
Upon receipt of the TIM message, the terminal will compare its own version with the
version included in the message. Only when the version differs, the terminal will send the
requestConfiguration.
If the candidate configuration version is not "null", the TCS compares that version with the satellite
configuration version stored on TCS. If the candidate configuration version is "null', the TCS
compares the modem's current satellite configuration version with the satellite configuration version
stored on TCS. If the versions do not match, the TCS sends a replyConfiguration message to the
terminal, including the satellite configuration object.

Terminals
Upon receipt of the satellite configuration object, the terminal will download any GXT file referenced
in the object and not yet locally available, from the Apache server. The GXT file are zipped. To avoid
massive download requests from the Apache server, a modem waits a random time between 0 sec
and a configurable backoff value before starting the download. If the download fails, the modem will
try maximally three times, each time doubling the random backoff period. If the download still fails,
the entire satellite configuration download will be considered as failed.
The modem stores the satellite configuration object and GXT file(s) as a candidate configuration and
immediately merges this configuration with the current satellite configuration. At this point, the
modem is in the conditional commit state. The modem will send a satelliteConfigurationUpdate
message to the TCS, including the candidate configuration version and the current configuration
version. If the new configuration does not affect the active beam or the changes to the active beam
are not critical, the terminal moves to the commit state and merges the current configuration with the
startup configuration. It also deletes the candidate configuration. The modem will again send a
satelliteConfigurationUpdate message to the TCS, including the candidate satellite configuration
version (null) and the current satellite configuration version.
If the new configuration affects the active beam with critical changes, the terminal remains in the
conditional commit state. When the terminal is triggered to reinitialize (either by the operator or
because it has lost connectivity) it tries to initialize using the "new" current configuration. If the
terminal becomes operational, it moves to the commit state and merges the current configuration
with the startup configuration. It also deletes the candidate configuration. The modem will send a
satelliteConfigurationUpdate message to the TCS, including the candidate configuration version
(null) and the current satellite configuration version.
If the terminal fails to become operational using the "new" configuration within a configurable timeout
period, the startup configuration is loaded again into the current configuration and the modem can
revert to its normal state. The candidate configuration is not deleted. The default rollback timeout is
two hours.
Following active beam changes are critical:
• The active beam is deleted.
• Initial carrier 1 is changed.
• Pointing carrier 1 is changed.
• Automatic pointing and AIBS settings of active beam are changed.
When changing the settings of the satellite interface locally in the modem GUI, the
satellite configuration version of the modem is set to "null". This implies that the remote
satellite configuration will always overrule the locally changed settings.
9.9.2 Use Cases
9.9.2.1 Extending Beam Capacity
The operator extends the capacity of a beam with a new satellite network and forward carrier, and
moves a terminal to the new satellite network for load balancing reasons.
Start Situation
1. The terminal is provisioned in NMS and linked to an Attachment Profile and to a Remote
Configuration Profile that enables the remote satellite configuration feature for that terminal.
– The attachment profile contains one attachment, which defines a beam (ID 1), a satellite
network (SN 1) within that beam and corresponding forward (FWD 1) and return resources.

Terminals
2. The terminal is operational and the satellite configuration as defined in the attachment profile is
deployed on the modem. The current satellite configuration version of the modem is the same
as the version in TCS, for example v1.
Migration Flow
1. The operator configures the new satellite network (SN 2 with FWD 2) in NMS. The satellite
network is linked to the same beam (ID 1). The operator also creates a new attachment profile
with the new satellite network as attachment.
2. The operator links the new attachment profile to the terminal. The terminal is now provisioned
on SN 2 and no longer provisioned on SN 1.
3. The terminal is still locked on FWD 1 but can no longer access the return link of SN 1. The
terminal will reinitialize using initial carrier = FWD 1 and is redirected to FWD 2 (as it is
provisioned on this one).
4. When the modem becomes operational in SN 2, it sends a requestConfiguration message to the
TCS, including current satellite configuration version v1 and candidate configuration version
"null".
5. The TCS sends a replyConfiguration message, including the new satellite configuration object
and version v2.
6. The terminal stores the data as the candidate configuration and immediately merges the
candidate configuration with the current configuration. The terminal remains operational. The
terminal is in the conditional commit state because initial carrier 1 of the active beam has
changed.
7. When the terminal reinitializes (triggered by the operator or by some other means), it will use
initial carrier = FWD 2 and becomes operational again in SN 2. The terminal is in the commit
state and merges the current configuration with the startup configuration. It also deletes the
candidate configuration.
What if the operator has entered wrong FWD 2 settings?

When the terminal reinitializes, it will use initial carrier = FWD 2 and will not be able to become
operational. After the rollback timeout has expired, the modem merges the startup configuration with
the current configuration and reverts to its normal state. The candidate configuration is not deleted.
9.9.2.2 Adding a New Beam
The operator introduces a new beam to which mobile terminals are migrated.
Start Situation
1. The mobile terminal is provisioned in NMS and linked to an Attachment Profile and to a Remote
– The attachment profile contains several attachments, one for each beam/satellite network
where the modem can be operational.
2. The terminal is configured for AIBS and automatic pointing.
deployed on the modem. The satellite configuration version of the modem is the same as the
version in TCS, for example v1.
Migration Flow

Terminals
1. The operator configures the new beam and satellite network in NMS and adds this
beam/satellite network to the existing attachment profile linked to the terminal. The NMS creates
a new version (v2) for this satellite configuration and this triggers the return link controller to
send a TIM message to the terminal.
2. The terminal sends a requestConfiguration message to the TCS, including current satellite
configuration version v1 and candidate configuration version "null".
and version v2.
4. The terminal stores the data in the candidate configuration and merges the candidate
configuration with the current configuration. The terminal is in the conditional commit state.
There are no changes to the active beam and the terminal immediately moves to the commit
state. The current configuration is merged with the startup configuration and the candidate
configuration is deleted. The current satellite configuration version on the modem is v2. The
terminal remains operational on its currently selected beam.
5. When the terminal moves within the coverage of the new beam, it loses the forward link and
starts AIBS. AIBS selects the new beam and the terminal becomes operational.
What if the operator has entered wrong beam settings?

starts AIBS. Due to the wrong beam settings (for instance, wrong GXT file) AIBS is unable to
select the new beam and the terminal cannot become operational.
2. The operator corrects the settings of the new beam. The NMS creates a new version (v3) for
this satellite configuration. As the terminal is not operational, the return link controller will not
send a TIM message to the terminal.
3. When the modem moves back to the 'old' beam, AIBS is able to select the beam and the
terminal becomes operational.
4. The terminal sends a requestConfiguration message to the TCS, including current satellite
configuration version v2 and candidate configuration version "null".
and version v3.
There are no changes to the active beam and the terminal immediately moves to the commit
state. The current configuration is merged with the startup configuration and the candidate
starts AIBS. AIBS selects the new beam and the terminal becomes operational.
9.9.2.3 Deleting a Beam
The operator deletes a beam, which is no longer used. There are two scenarios: the deleted beam is
not active and the deleted beam is active.
Start Situation
1. The mobile terminal is provisioned in NMS and linked to an Attachment Profile and to a Remote
– The attachment profile contains several attachments, one for each beam/satellite network
where the modem can be operational.

Terminals

Scenario 1: The deleted beam is not active

1. The operator deletes a non-active beam/satellite network from the attachment profile linked to
the terminal. The NMS creates a new version (v2) for this satellite configuration and this triggers
the return link controller to send a TIM message to the terminal.
2. The terminal sends a requestConfiguration message to the TCS, including satellite configuration
version v1 and candidate configuration version "null".
and version v2.
configuration to the current configuration. The terminal is in the conditional commit state. There
are no changes to the active beam and the terminal immediately moves to the commit state.
The current configuration is merged with the startup configuration and the candidate
5. When the terminal moves within the coverage of the deleted beam, it loses the forward link and
starts AIBS. AIBS is unable to select the beam.
Scenario 2: The deleted beam is active and there is no other beam with the
same coverage
1. The operator deletes the active beam/satellite network from the attachment profile linked to the
terminal. The NMS creates a new version (v2) for this satellite configuration and this triggers the
return link controller to send a TIM message to the terminal. The terminal is no longer
provisioned on the active beam and loses connectivity. The terminal starts AIBS and selects a
new beam when it has moved into the coverage of that beam. The terminal becomes
operational again. As long as the modem does not move into the coverage of another beam, it
cannot become operational.
2. Upon receipt of the TIM message, the terminal sends a requestConfiguration message to the
TCS, including satellite configuration version v1 and candidate configuration version "null".
and version v2.
4. The terminal stores the data in the candidate configuration and immediately merges the
candidate configuration with the current configuration. As the deleted beam is no longer the
active one the terminal moves to the commit state, merges the current configuration with the
startup configuration and deletes the candidate configuration. The current satellite configuration
version on the modem is v2.
9.9.2.4 Roaming Agreement
Operator x signs a roaming agreement with operator y. The roaming agreement allows terminals of
operator x to become operational in operator y's satellite network(s).
The beams used by operator x and operator y are uniquely identified; the beams have
different config IDs.

Terminals
Start Situation
1. Operator x provisions the mobile terminal in NMS and links it to an Attachment Profile and to a
Remote Configuration Profile which enables the remote satellite configuration feature for that
terminal.
– The attachment profile contains several attachments, one for each beam/satellite network of
operator x where the modem can be operational.
3. The terminal is operational in operator x's network and the satellite configuration as defined in
the attachment profile is deployed on the modem. The satellite configuration version of the
modem is the same as the version in TCS; for example v1.
Roaming Flow
1. Operator x signs the roaming agreement with operator y.
– Operator y provisions the mobile terminal in NMS and links it to an attachment profile. The
remote satellite configuration feature is disabled. The attachment profile contains several
Home Network Attachments, one for each beam/satellite network of operator y where the
modem can be operational.
– Operator x adds one or more Visited Network Attachments to the attachment profile linked
to the terminal. Each attachment defines a beam of operator y on which the terminal can be
operational. The NMS creates a new version (v2) for this satellite configuration and this
triggers the return link controller to send a TIM message to the terminal.
and version v2.
4. The terminal stores the data in the candidate configuration and immediately merges the
candidate configuration with the current configuration. The terminal is in the conditional commit
state. There are no critical changes to the active beam and the terminal immediately moves to
the commit state. The current configuration is merged with the startup configuration and the
candidate configuration is deleted. The satellite configuration version on the modem is v2. The
5. When the terminal moves within the coverage of a beam of operator y, it loses the forward link
and starts AIBS. AIBS selects the new beam of operator y and the terminal becomes
operational.
9.9.2.5 Migrating the Forward Carrier
The operator migrates the forward carrier.
Start Situation
1. The terminal is provisioned in NMS and linked to an Attachment Profile and to a Remote
– The attachment profile contains one attachment, which defines a beam, a satellite network
within that beam and corresponding FWD and RTN resources.

Terminals
Migration Flow
1. The operator configures candidate settings for the new forward carrier. These candidate
settings become initial carrier 2 within the satellite configuration. Initial carrier 1 is still the active
forward carrier. The NMS creates a new version (v2) for this satellite configuration and this
triggers the return link controller to send a TIM message to the terminal.
and version v2.
There are no critical changes to the active beam and the terminal immediately moves to the
commit state. The current configuration is merged with the startup configuration and the
candidate configuration is deleted. The satellite configuration version on the modem is v2. As
long as the 'old' forward carrier is up, the terminal remains operational.
5. The operator migrates the active forward carrier to the candidate settings. The modem loses the
FWD link.
Changing the forward carrier settings, changes initial carrier 1 in the satellite configuration. The
NMS creates a new version (v3) for this satellite configuration and this triggers the return link
controller to send a TIM message to the terminal.
– If AIBS is enabled, the modem will try initial carrier 2 after the automatic pointing timeout
expires.
– If AIBS is disabled, the modem will try initial carrier 2 after three minutes.
6. The modem locks on initial carrier 2 and receives the TIM message. The terminal sends a
requestConfiguration message to the TCS, including satellite configuration version v2 and
candidate configuration version "null". The TCS sends a replyConfiguration message, including
the new satellite configuration object and version v3. The terminal is in the conditional commit
state because initial carrier 1 of the active beam has changed.
7. When the terminal reinitializes (triggered by the operator or by some other means), it will use
initial carrier 1 = new FWD carrier, and becomes operational again. The terminal is in the
commit state and merges the current configuration with the startup configuration. It also deletes
the candidate configuration.
What if the operator has entered wrong forward carrier candidate settings?
1. The modem does not lock on initial carrier 2. To recover from this scenario, the operator should
migrate the forward carrier to the original settings and wait for the terminal to lock on initial
carrier 1. The operator can then repeat the migration flow using the correct candidate settings.
9.10 BUC and Modem Frequency Synchronization

A modem is connected to a Block Up Convertor or BUC and to a Low Noise Block Down Convertor
or LNB. As described in Time and Frequency Synchronization on page 97, the modem uses a local
frequency reference. The BUC synchronizes by default with the reference clock of the modem (the
reference clock signal is sent via the RF cable between modem and BUC).
BUC and modem frequency synchronization is applicable for all modem types that
support the use of a BUC. These include all modem types, except MDM2200 and
MDM2210, which only support an iLNB with MUC.

Terminals
A BUC can also use its own reference clock or use an external source (different than the modem). In
that case, there is no clock reference synchronization between modem and BUC. This introduces an
uncertainty due to the BUC frequency offset which can be different per terminal. As a result
additional guard bands are used (on top of the uncertainties described in
Time and Frequency Synchronization on page 97) to protect the network from the uncertainties
introduced.
The MRC, HRC and DVB-S2 return link controllers in the hub need to take the protective guard
bands into account when assigning return link resources to the terminals. The main requirement of
the controllers is to avoid overlap of frequency ranges or carrier collisions. For the HRC and the
DVB-S2(Ext) return link technology, the formulas to determine the additional guard bands are
described in the table below. For the MRC return link technology, the BUC and modem are always
synchronized and the additional guard band is 3 kHz.
BUC and Modem Guard Band (*)

Synchronized
YES 3 kHz
NO max [ 2 * (center frequency * BUC max frequency uncertainty / 1000000),
3000 ]
(*) Terminal is fixed. Refer to the Doppler Effect on Terminals on page 165 for the impact of terminal
movements.

Terminals
For S2 carriers, a guard band of 3 kHz is negligible relative to the minimal symbol rate
of 1 Mbaud.
Via the terminal GUI and the terminal provisioning interface, it is possible to define whether or not
the modem and BUC are frequency synchronized.
• A clock reference is by default present on the TX interface of the modem. Set the BUC
reference clock parameter in the modem GUI to off if the BUC uses an internal reference or is
slaved to a reference source other than the modem.
• Enable the BUC synchronized to modem parameter in the modem GUI to keep both devices
in sync. This parameter can also be set in the hub during terminal provisioning.
Disabling the synchronization will result in a higher frequency uncertainty and in longer
terminal logon times.
BUC Synchronized to modem is typically enabled when a BUC reference clock

is selected. Only in special uses cases the configuration can differ from one
another. For example when one BUC is used by multiple modems. In this case:
• Select a BUC reference clock on only one modem. This frequency is used as
the reference signal for the BUC.
• Enable BUC Synchronized to Modem on all modems to keep the devices in
sync.
• Set the BUC and Modem Frequency Synchronized parameter in the Terminal Provisioning GUI
to the same value as the BUC synchronized to modem parameter in the modem GUI. When
they are not equal, the modem cannot not logon to the network.
The Max Frequency Uncertainty parameter is only applicable if synchronization is disabled.
This value can be retrieved from the BUC data sheet. This parameter has an impact on terminal
logon times. Return link controllers take this parameter into account, hence introducing a level
of uncertainty which translates into longer logon times.
The effect of the Max Frequency Uncertainty value is visible in the Return Link Frequency
Plan as shown in the examples below.
– BUC and Modem Frequency Synchronized is enabled.

Terminals
The SCPC carrier bandwidth is calculated based on the symbol rate, roll off factor and
standard guard band of 3 kHz.
– BUC and Modem Frequency Synchronized is disabled and Max Frequency

Uncertainty is set to 4 ppm.
The SCPC carrier bandwidth is calculated based on the symbol rate, roll off factor,
standard guard band of 3 kHz and the maximum frequency uncertainty. This results in a
larger carrier bandwidth than when BUC and modem frequency are synchronized.

Terminals

Terminals
9.11 Doppler Effect on Terminals

Terminals can move during operation (for example, the terminal is on a boat, on an oil rig or in a
train). This movement introduces a Doppler effect as the distance between the sender and receiver
varies. As described in Time and Frequency Synchronization on page 97, guard times and guard
bands are already applied for all terminals to protect the network against the Doppler effect
introduced by the movement of the satellite. Measures against the Doppler effect introduced by the
movement of a terminal need to be taken as well by means of additional guard times.
The MRC, HRC and DVB-S2 return link controllers in the hub need to take the guard times into
account when allocating return link resources to the moving terminals. The main requirement of
controllers is to avoid overlap of frequency ranges or carriers. For the HRC and the DVB-S2(Ext)
return link technology, the formulas to determine the additional guard bands are described in the
table below. For the MRC return link technology, the BUC and modem are always synchronized and
the additional guard band is 3 kHz.
BUC and Modem Guard Band (*)

Synchronized
YES max [ 2 * 2 * (center frequency * terminal speed / c), 3 kHz ]

NO max [ 2 * (center frequency * terminal speed / c) + 2 * (center frequency
* BUC max frequency uncertainty / 1000000), 3000 ]
(*) Terminal is mobile.

Terminals
In the Mobility tab of the Terminal Provisioning interface you can specify if the modem is moving
and what the maximum speed and acceleration of that movement is.
The following table provides rule of thumb values for the maximum speed and acceleration
parameter to use in the Communications On The Move or COTM scenarios.
Application Max speed Max 4CPM HRC DVB-S2/ MRC

(m/s) acceleration S2Ext
(m/s 2)
Maritime rigs 1.5 2 ✔ ✔ ✔ ✔

(>2 Mbaud)
Maritime bulk carrier 7.5 6 ✔ ✔ ✔ ✔

(>2 Mbaud)
Maritime 15 6 ✔ ✔ ✔ ✔
cruise/container only in KU or (>2 Mbaud)
C-band
Aeronautical airliner 350 6 ✖ ✔ ✔ ✖

midflight (>2 Mbaud)
Aeronautical airliner 17 ✖ ✔ ✔ ✖
all conditions (>10 Mbaud)

Terminals
For more information about setting parameters for Communications on the Move, refer
to the Newtec Dialog Configuration User Guide.
The effect of setting the maximum speed in the Terminal Provisioning interface is visible in the
Return Link Frequency Plan.
• BUC and Modem Frequency Synchronized is enabled.
– COTM is disabled.
The SCPC carrier bandwidth is calculated based on the symbol rate, roll off factor and
standard guard band of 3 kHz.
– COTM is enabled and Max Speed is set to 200 m/s.

The SCPC carrier bandwidth is calculated based on the symbol rate, roll off factor, and the
maximum terminal speed. If the speed is large enough, this will result in a larger carrier
bandwidth than when COTM is disabled (this is the case in this example). If the speed is
low, the carrier bandwidth is the same as when COTM is disabled.
The influence of the maximum speed on the guard band is according to the formula in the
first row of the table above. on page 165
• BUC and Modem Frequency Synchronized is disabled and Max Frequency Uncertainty is set
to 4 ppm.
– COTM is disabled.
standard guard band of 3 kHz and the maximum frequency uncertainty. This results in a
larger carrier bandwidth than when BUC and modem frequency are synchronized.

Terminals
COTM is enabled and Max Speed is set to 200 m/s.

standard guard band of 3 kHz, the maximum frequency uncertaintyand the maximum
terminal speed. If the speed is large enough, this will result in a larger carrier bandwidth
than when COTM is disabled (this is the case in this example). If the speed is low, the
carrier bandwidth is the same as when COTM is disabled.
The influence of the maximum speed on the guard band is according to the formula in the
second row of the table above. on page 165

Terminals
9.12 SNMP
SNMP (Simple Network Management Protocol) is a standard protocol that is widely used for
managing devices on IP networks. It is used by network administrators to monitor, configure and
solve problems from a central point.
SNMP is an application-layer protocol. It runs over UDP at the transport level. The protocol is based
on a manager / agent model.
The modems are SNMP manageable. This means that they have an SNMP agent that can be polled
for information from a Network Management Station (NMS). The following figure presents the setup
between the Newtec Dialog hub and a modem.
The SNMP agent used is MIB-II compliant.

The Management Information Base (MIB) provides a standard representation of the SNMP Agent's
available information and where it is stored. The MIB is defined according to the ASN.1 (Abstract
Syntax Notation One).
The following SNMP operations are available:
Operation Description Action by the
get Readout the current value of specific objects in the MIB. NMS
get next Readout the current value of the next object in the MIB. NMS
set Change a value of a specific object in the MIB. NMS
The different operations are displayed in the following figure:
Specific SNMP ports are used to allow SNMP information to be sent to the correct application.

Terminals
Currently only port number 161 is used. The port is used by an external SNMP manager to
communicate with the SNMP agent.
The following SNMP parameters can be edited in the modem GUI.
Make sure to login as expert to show and/or change the SNMP settings.
Parameter Description
Enable on Local Enable this parameter to make SNMP communication possible

Management between the modem and a local management PC.
Remark: SNMP communication is by default possible between the
modem and the Newtec Dialog hub.
Read-Only Community The SNMP Read-Only Community String is like a password.

It is sent along with each SNMP Get-Request and allows (or denies)
access to device. The default public community string is set to
ntcpublic.
We recommend changing the community string. Do not to use "public"
for the Read-Only Community string.
Read-Write Community The read-write community string protects the device against
unauthorized changes. The default RW community is ntcprivate.
We recommend changing the community string. Do not to use
"private" for the Read-Write Community string.
9.12.1 Used MIBs

The MIB (Management Information Base) is a database that describes the structure of the
management data that can be used within a device.
The MIB uses hierarchical names containing OID (object identifiers) to describe the management
data of the device in a structured way. Every OID describes a variable that can be read and/or set
using SNMP.
The Newtec MIB provides a standard representation of the SNMP Agent's available information and
where it is stored.
The MIB is defined according to the ASN.1 (Abstract Syntax Notation One).
The Newtec MIB is derived from the device definition database and allows full monitor and control
over the complete device using any SNMP browser (HPOpenView, NetworkView).
We support a limited subset of OIDs.
The customer must compile the obtained .mib files from within his Network Management Software.
The following MIB files exist:
• NEWTEC-MAIN-MIB.mib:
• NEWTEC-DIALOG-TERMINAL-MIB.mib: This is the MIB Module for the management of the
modem.
• SNMPv2-CONF.mib
• SNMPv2-SMI.mib

Terminals
• SNMPv2-TC.mib
Click SNMP MIBs in the modem GUI to download the SNMP MIB files. A mib.zip file is downloaded
into your default download folder.

Abbreviations
10 Abbreviations
Abbreviation Definition
AMP Air MAC Processor
ASI Asynchronous Serial Interface
ASW Access Switch
BNC Bayonet Neil Concelman
BSC Bootstrapper/System Configurator
BUC Block Up Converter
BW Bandwidth
CBRF Cable RF
CBUTP Cable UTP
CMS Configuration Management Server
CLO Cross-Layer-Optimization
CPM Continuous Phase Modulation
CPMCTL CPM Controller
CSA Canadian Standards Authority
dBm/Hz Decibels (reference to 1 milliwatt) per Hertz
DEM Demarcation Service
DEMODs Demodulators
DHCP Dynamic Host Configuration Protocol
DMA Dataminer Agent
DNS Domain Name Service
DRO Dielectric Resonator Oscillator
DSCP Differentiated Services Code Point
DSW Distribution Switch
DVB-S2 Digital Video Broadcasting - Satellite - version 2
ESC Escape

Abbreviations
ETCP Enhanced TCP
EU European Union
eNode Evolved Node B (Basestation/Node B/ eNodeB): name depending on the

generation of mobile network)
GPRS Global Packet Radio Service
GPS Global Positioning System
GTP GPRS Tunneling Protocol
GTP-U GTP carrying user data
GUI Graphical User Interface
HM Hub Module
HMGW Hub Module Gateway
HP Hewlett-Packard
HRC High Resolution Coding
HTTP Hyper Text Transfer Protocol
HTTPS HTTP Secure
I/O Input/Output
ICMP Internet Control Message Protocol (IETF)
ID Identifier
IEC International Electrotechnical Commission
IF-Band Intermediate Frequency Band
IFL L-Band Interface
IP Internet Protocol
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
LAN Local Area Network
LEDs Light Emitting Diode
LNB Low noise block downconverter

Abbreviations
LO Local Oscillator
MAC Medium Access Control
MCN Mobile Core Network
MF-TDMA Multi Frequency-Time Division Multiple Access
MHz Mega Hertz
MME Mobility Management Entity
MOD Modulator
MODCOD Modulation and Coding Combination
MonCon Monitoring & Control
MOTD Message Of the Day
Mx-DMA Cross-Dimensional Multiple Access
MRC Multiple Resolution Coding
N/A Not Applicable
NCR Network Clock Reference
NMS Network Management System
NOC Network Operations Center
NSSA Not So Stubby Area
NTP Network Time Protocol
NxtGen Mx-DMA Next Generation Cross-Dimensional Multiple Access
OA Onboard Administrator
OSPF Open Shortest Path First
PDN Packet Data Network Gateway: offers data connectivity (e.g. to the internet)
PDU Power Distribution Unit
PLL Phase Locked Loop
PSD Power Spectral Density
PSTN Public Switched Telephone Network
PSU Power Supply Unit

Abbreviations
QCI QoS Class Identifier
QoS Quality of Service
RAN Radio Access Network
RCM Return Controller Manager
REDCTL Redundancy Controller
REF Reference
Ref_SPL Reference Splitter
RF Radio Frequency
RMA Return Material Authorization
RTN Return
RTP Real-time Transport Protocol
SatNet Satellite Network
SGW Serving Gateway
SNR Signal to Noise Ratio
SR Symbol Rate
SRV Server
SSH Secure Shell
TAS Traffic Acceleration Server
TCP Transmission Control Protocol
TC-SPY Tellicast Spy Software
TX Transmit
UE User Equipment
UDP User Datagram Protocol
URL Uniform Resource Locator
USB Universal Serial Bus
USS Universal Switching System
UTC Universal Coordinated Time

Abbreviations
UTP Unshielded Twisted - Pair
VA Volt Ampere
VAC Volts Alternating Current
VGA Video Graphics Adapter
VLAN Virtual Local Area Network
VL-SNR Very Low Signal to Noise Ratio
VM Virtual Machine
VoIP Voice Over IP
VRF Virtual Routing Forwarding
VSAT Very Small Aperture Terminal

ST Engineering iDirect (Europe)
Laarstraat 5
9100 Sint-Niklaas Belgium
+32 3 780 6500
wwww.idirect.net

FunctionalDescription v1.0

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FunctionalDescription v1.0

Uploaded by

Copyright:

Available Formats

Functional Description

ST Engineering iDirect is a global leader in satellite communications (satcom) providing technology

Company Website: www.idirect.net | Main Phone: +32 3 780 6500

1 About This Guide ............................................................................................ 1

2 What is Newtec Dialog® ................................................................................. 2

3 Forward Link ................................................................................................... 7

4 Return Link .................................................................................................... 24

Functional Description v1.0 3/176

4.4.3 Encapsulation and Coding .............................................................................................................. 43

5 Quality Of Service ......................................................................................... 56

6 Satellite Link Optimization ........................................................................... 68

7 Data Path Optimization ................................................................................. 80

8 Time and Frequency Synchronization ........................................................ 97

9 Terminals ..................................................................................................... 103

Functional Description v1.0 4/176

9.2.1 Specifications ................................................................................................................................ 104

Functional Description v1.0 5/176

9.8.2.5.7 MCD Overbooking ............................................................................................................... 148

10 Abbreviations ............................................................................................ 172

Functional Description v1.0 6/176

1 About This Guide

1.1 Revision History

Version Date Reason of new version

1.0 December, 2020 Initial version of this release.

1.2 Cautions and Symbols

A reference message is used to direct to a location in a document with related document

Functional Description v1.0 1/176

2 What is Newtec Dialog®

Functional Description v1.0 2/176

Dialog R2.4.1 supports all modem types.

Functional Description v1.0 3/176

Functional Description v1.0 4/176

Functional Description v1.0 5/176

Functional Description v1.0 6/176

3.1 Forward Link Definition

Annex M specifies the implementation of a DVB-S2 profile suitable for operation in

DVB-S2/S2X Forward Carrier

DVB-S2X Annex M Forward Carrier (wideband)

Functional Description v1.0 7/176

3.2 DVB-S2(X) Key Concepts

Functional Description v1.0 8/176

50 bytes 37 Mbps 23 Mbps

100 bytes 47 Mbps 35 Mbps

250 bytes 57 Mbps 48 Mbps

500 bytes 60 Mbps 55 Mbps

1000 bytes 62 Mbps 60 Mbps

1500 bytes 63 Mbps 61 Mbps

50 bytes 2.9 Mbps 1.8 Mbps

100 bytes 3.6 Mbps 2.7 Mbps

250 bytes 4.3 Mbps 3.7 Mbps

500 bytes 4.7 Mbps 4.3 Mbps

1000 bytes 4.8 Mbps 4.6 Mbps

1500 bytes 4.9 Mbps 4.7 Mbps

3.2.2 Baseband Frames

Refer to Forward Link End-to-End on page 22 for more details about the CSE and

Functional Description v1.0 9/176

• Normal frames, which have a fixed size of 64800 bits.

Functional Description v1.0 10/176

Functional Description v1.0 11/176

Functional Description v1.0 12/176

3.2.4 Forward Error Correction

The 9/10 FEC rate cannot be applied on short BBF.

Functional Description v1.0 13/176