Functional Description v1

Newtec Dialog
R2.2.1
Functional Description v1.1

Table of Contents Functional Description v1.1 Newtec Dialog R2.2.1
Table of Contents
1 Preface ............................................................................................................. 1
1.1 About This Manual .................................................................................................................................. 1
1.2 Version History ....................................................................................................................................... 1
1.3 Cautions and Symbols ............................................................................................................................ 1
2 What is Newtec Dialog® ................................................................................. 2
3 Forward Link ................................................................................................... 6

3.1 Forward Link Definition ........................................................................................................................... 6
3.2 DVB-S2(X) Key Concepts ....................................................................................................................... 7
3.2.1 Baseband Frames ............................................................................................................................. 7
3.2.2 Modulation ........................................................................................................................................ 7
3.2.3 Forward Error Correction ................................................................................................................. 10
3.2.4 MODCOD ....................................................................................................................................... 10
3.2.5 Encapsulation ................................................................................................................................. 15
3.2.6 Pilots ............................................................................................................................................... 16
3.3 DVB-S2X Annex M ............................................................................................................................... 17
3.3.1 Wideband and Time Slicing ............................................................................................................ 17
3.3.2 Maximum Symbol Rates ................................................................................................................. 18
3.4 Forward Link End-to-End ...................................................................................................................... 19
3.5 Forward Link Configuration ................................................................................................................... 20
4 Return Link .................................................................................................... 21

4.1 Return Link Definition ............................................................................................................................ 21
4.2 MF-TDMA 4CPM .................................................................................................................................. 23
4.2.1 Definition ......................................................................................................................................... 23
4.2.2 Coding and Modulation ................................................................................................................... 23
4.2.3 Access Layer ................................................................................................................................... 24
4.2.4 Return Capacity Groups and Carrier Pools ..................................................................................... 27
4.2.5 Burst Demodulator .......................................................................................................................... 28
4.2.6 4CPM Return Link End-to-End ........................................................................................................ 31
4.3 SCPC DVB-S2 and S2 Extensions ....................................................................................................... 32
4.3.1 Definition ......................................................................................................................................... 32
4.3.2 Access Layer ................................................................................................................................... 32
4.3.3 DVB-S2 Return Link End-to-End ..................................................................................................... 33
4.4 High Resolution Coding™ ..................................................................................................................... 35
4.4.1 Access Layer ................................................................................................................................... 36
Confidentiality: Unrestricted
4.4.2 HRC SCPC ..................................................................................................................................... 37

4.4.3 HRC Mx-DMA ................................................................................................................................. 38
4.4.4 HRC Return Link End-to-End .......................................................................................................... 40
5 Satellite Link Optimizations ......................................................................... 42

5.1 Equalink® ............................................................................................................................................. 42
5.2 Clean Channel Technology® ................................................................................................................ 44
5.3 Adaptive Coding Modulation ................................................................................................................. 45
5.3.1 ACM in the Forward ........................................................................................................................ 46
5.3.2 ACM in the Return ........................................................................................................................... 51
5.4 Adaptive Return Link ............................................................................................................................. 53
5.5 Satellite Return Uplink Optimization Technology Handling ................................................................... 55
5.5.1 HRC ................................................................................................................................................ 55
5.5.2 MF-TDMA 4CPM ............................................................................................................................ 56
6 Quality Of Service ......................................................................................... 58

6.1 Classification ......................................................................................................................................... 58
6.1.1 Inherit QoS Classification ................................................................................................................ 59
6.2 Marking ................................................................................................................................................. 59
6.3 Mapping and Queuing .......................................................................................................................... 62
6.4 Shaping ................................................................................................................................................. 63
6.4.1 Allocation Type ............................................................................................................................... 66
6.5 QoS in Forward Link .............................................................................................................................. 68
6.6 QoS in Return Link ................................................................................................................................ 70
7 Network Layer Optimization ......................................................................... 77

7.1 IP Network Optimization ....................................................................................................................... 77
7.2 Network Optimization Parameters ......................................................................................................... 78
7.2.1 TCP Acceleration ............................................................................................................................ 78
7.2.2 TCP Payload Compression ............................................................................................................. 81
7.2.3 Header Compression ...................................................................................................................... 81
7.2.4 Packet Aggregation ......................................................................................................................... 83
7.2.5 Cross-Layer-Optimization™ (CLO) ................................................................................................. 84
7.2.6 GTP Acceleration ............................................................................................................................ 88
7.3 Performance Evaluation ....................................................................................................................... 93
7.3.1 Impact of TCP acceleration on bandwidth efficiency ...................................................................... 93
7.3.2 Impact of packet aggregation on bandwidth efficiency ................................................................... 93
7.3.3 Impact of TCP payload compression on bandwidth efficiency ....................................................... 93
7.3.4 Impact of header compression on bandwidth efficiency ................................................................ 93
7.3.5 Scalability and bandwidth efficiency ............................................................................................... 94
8 Time and Frequency Synchronization ........................................................ 95
9 Terminals ....................................................................................................... 99
9.1 Terminal Description ............................................................................................................................. 99
9.2 Modems ................................................................................................................................................ 99
9.2.1 Specifications ................................................................................................................................ 100
9.2.2 Markets ......................................................................................................................................... 101
9.3 Outdoor Units ...................................................................................................................................... 102
9.4 Terminal Installation and Initialization ................................................................................................. 104
9.4.1 Step 1: Terminal Installation ......................................................................................................... 105
9.4.2 Step 2: Satellite Network Lookup .................................................................................................. 109
9.4.3 Step 3: Forward Link Synchronization .......................................................................................... 110
9.4.4 Synchronized State ....................................................................................................................... 110
9.4.5 Step 4: Return Link Synchronization ............................................................................................. 110
9.4.5.1 4CPM Logon Procedure ............................................................................................................ 111
9.4.5.2 DVB-S2 Logon Procedure ......................................................................................................... 112
9.4.5.3 HRC Logon Procedure .............................................................................................................. 113
9.4.5.3.1 SCPC: Static Frequency Plan Mode .................................................................................... 113
9.4.5.3.2 Mx-DMA ............................................................................................................................... 113
9.4.5.3.2.1 Single Carrier Logon ..................................................................................................... 113
9.4.5.3.2.2 Logon Bandwidth .......................................................................................................... 114
9.4.5.3.2.3 Ulogon ........................................................................................................................... 117
9.4.5.3.2.4 Mx-DMA Terminal Logon Priority .................................................................................. 119
9.4.6 Step 5: Network Logon ................................................................................................................. 119
9.5 Return Technology Switching ............................................................................................................. 121
9.6 Terminal Provisioning ......................................................................................................................... 126
9.7 Terminal Usage ................................................................................................................................... 127
9.7.1 Terminology .................................................................................................................................. 127
9.7.1.1 Fixed or Mobile Terminal ........................................................................................................... 127
9.7.1.2 Single Beam or Multi-beam Operation ....................................................................................... 127
9.7.2 Attachment Profile ......................................................................................................................... 127
9.7.3 Use Cases ..................................................................................................................................... 128
9.7.3.1 Fixed or COTP Single Beam Terminal ....................................................................................... 128
9.7.3.2 COTM Single Beam Terminal .................................................................................................... 128
9.7.3.3 Fixed Terminal Provisioned in Multiple Beams .......................................................................... 129
9.7.3.3.1 Description ........................................................................................................................... 129
9.7.3.3.2 Terminal Pinning Procedure ................................................................................................. 131
9.7.3.4 COTP Terminal Operating in Multiple Beams ............................................................................ 132
9.7.3.5 COTM Terminal Operating in Multiple Beams ........................................................................... 134
9.7.3.5.1 Automatic Initial Beam Selection ......................................................................................... 136
9.7.3.5.2 Mobility API .......................................................................................................................... 139

9.7.3.5.3 Transponder-specific Power Offset during Logon ............................................................... 142
9.7.3.5.4 MCD Overbooking ............................................................................................................... 142
9.7.3.6 Summary ................................................................................................................................... 143
9.7.4 Terminal Usage Summary ............................................................................................................ 144
9.8 BUC and Modem Frequency Synchronization .................................................................................... 145
9.9 Doppler Effect on Terminals ............................................................................................................... 148
9.10 SNMP ................................................................................................................................................ 153
9.10.1 Used MIBs ................................................................................................................................... 155
10 Abbreviations ............................................................................................ 156
Preface Functional Description v1.1 Newtec Dialog R2.2.1
1 Preface
1.1 About This Manual

The Newtec Dialog Functional Description elaborates on the functionalities and concepts of a
Newtec Dialog system. It describes how they are implemented, how they work and what to consider
when using them.
1.2 Version History
Version Date Reason of new version
1.0 December 2019 Initial version of this release.
1.1 December 2019 Minor updates.
1.3 Cautions and Symbols

The following symbols appear in this manual:
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.
Confidentiality: Unrestricted 1/160

What is Newtec Dialog® Functional Description v1.1 Newtec Dialog R2.2.1
2 What is Newtec Dialog®

Newtec 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
Newtec 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 core of the Newtec 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. A satellite network
is associated with forward link capacity from one physical or virtual (in case of a wideband carrier)
forward carrier and with the corresponding return link capacity. The forward link is based on
DVB-S2, DVB-S2X or 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)
Network resources are configured on top of the physical satellite networks and are isolated from
each other using VLAN identifiers. The network resources can be grouped into:
• Layer 3 network resources
• Layer 2 network resources
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.

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.
A hub module is connected to an IP backbone at one side and to an RF interface at the other side.
Following types of hub modules exist:
• 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.
• 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.
• 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 HUB7303 or 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. Two types exist: HUB7308
and HUB7318. HUB7318 is deployed on the Newtec Private Cloud Infrastructure (NPCI).

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

Forward Link Functional Description v1.1 Newtec Dialog R2.2.1
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.
Each satellite network uses one forward link. The forward link is segmented into forward pools,
which divide the total forward bandwidth into chunks of IP capacity.
DVB-S2/S2X forward carrier
In DVB-S2 and DVB-S2X, a 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.
During terminal provisioning you must define which forward link, and hence satellite network, a
terminal should use.

3.2 DVB-S2(X) Key Concepts
3.2.1 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 19 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 on page 7 and Forward Error Correction on page 10.
Each baseband frame can be modulated with a different MODCOD on page 10 depending on the
signal to noise ratio of the forward signal and the ACM on page 46 configuration.
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:
• Normal frames, which have a fixed size of 64800 bits.
• Short frames, which have a fixed size of 16200 bits.
3.2.2 Modulation
The baseband frames are modulated into an analog signal using a modulation code.
The basic transmission signal components include the carrier wave and modulating signal. The
carrier wave is a continuous sinusoidal wave, which contains no information. The modulating signal
holds the data that needs to be transmitted over the carrier.
To transmit a digital signal over an analogue channel, the technique of keying is used. Keying is
characterized by the fact that the modulating signal has a limited number of states (or values), which
represent the corresponding digital states (basically 1 and 0). 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/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.

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 Newtec 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.
MDM2200/2210 only support an iLNB, which is not PLL. Therefore, it is not possible
to use a symbol rate less than 3.6 Mbaud for these modem types.

3.2.3 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.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. For example, MODCOD 32APSK 9/10 has a spectral efficiency of 4.45
(bits/s)/Hz and MODCOD QPSK 1/4 has a spectral efficiency of 0.49 (bits/s)/Hz.
Following MODCODs are supported in Newtec 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 ✔ ✔
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
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 ✔ ✔
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 ✔ ✖
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 ✔ ✖
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 ✔ ✖
3.2.5 Encapsulation
All traffic sent through a Newtec Dialog system needs to be encapsulated in order to fit in baseband
frames. Baseband frames are the basic unit used in the DVB-S2(X) standard. It 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 Newtec 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.
Average packet Bitrate for which GSE is more Bitrate for which GSE is more
size 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.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
Time slicing is supported on MCM7500 modulators and MDMxx10 modems. The

MCM7500 modulator is supported in the XIF hub module.
High Transport Satellites use wide transponders, which results in forward carriers that can go up to
480 Mbaud or reach a throughput of ~ 2 Gbps. The use of wide carriers require complex and
expensive receivers. To avoid this expense, the concept of time slicing is introduced in Annex M of
the DVB-S2X standard.
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

The following table provides an overview of the maximum symbol rates in Mbaud per VC for a
number of satellite networks or VCs. For the time slice mode it is assumed that:
• The VC sizes are equal;
• The highest MODCOD is the same per VC;
• The sum of VC sizes equals 0.997 times the physical carrier size.
Non-time slice Time sliced mode (Annex M)

mode
Maximum Physical Carrier 1 VC 2 VC 3 VC 4 VC 5 VC 6 VC 7 VC

MODCOD = VC
within FWD
link
QPSK 127 148 144 135 120 NA NA NA
8PSK 82 148 144 135 120 NA NA NA
16APSK 64 132 110 102 108 96 NA NA
32 APSK 51 106 79 79 81 86 80 NA
64 APSK 43 88 NA 58 65 69 72 68
A time sliced forward carrier with only one virtual carrier can have higher rates than a
non-time sliced carrier.
The total symbol rates of the VCs must be smaller than or equal to the 0.997 times
the symbol rate of the physical carrier.

3.4 Forward Link End-to-End

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

Layer 3 unicast and layer 2 point-to-point traffic enter the Newtec Dialog system via the demarcation
service:
• DEM (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 is forwarded to the TAS or Traffic Acceleration Service and then to the
CSE or Controller Shaper Encapsulator. The layer 2 point-to-point traffic is forwarded to the CSE via
a GRE tunnel.
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.
• 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).
3.5 Forward Link Configuration

The forward link can be configured through the NMS or Network Management System, either via the
GUI or via the REST API.
For more information on how to configure the forward link and forward carrier via the
NMS GUI, refer to the Operational Manual: Configuration Management.

Return Link Functional Description v1.1 Newtec Dialog R2.2.1
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
Newtec Dialog supports following access and coding & modulation technologies:
• MF-TDMA - 4CPM
• SCPC - DVB-S2, S2 Extensions, and HRC
• Mx-DMA - HRC
The access technology allocates the return link resources to the terminals. The coding and
modulation technology transforms the data into a satellite signal.
The Newtec 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.

The supported return technologies depend on the type of modem:
Modem Type Supported Return Technologies
MDM2200 CPM
MDM2210 CPM
MDM2500 CPM
MDM2510 CPM, HRC
MDM3100 CPM, HRC
MDM3300 CPM, HRC, DVB-S2 and S2 Extensions

4.2 MF-TDMA 4CPM
4.2.1 Definition
4CPM (Quaternary Constant Phase Modulation) is a return link 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. This means
that 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).

4.2.3 Access Layer

The MF-TDMA 4CPM 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.

As mentioned in the Definition on page 23, 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.

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

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 Newtec Dialog system are organized in Return Capacity Groups. These 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 satellite network has a number of Common Signaling Channel (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.
Each Carrier Pool consists of Traffic (TRF) Carriers with the same carrier spacing and associated
modulation and coding (known as MODCOD). The type and number of TRF carriers depends on
your link budget. A carrier pool is characterized by a minimum and maximum C/N0 (Carrier to Noise
ratio). A terminal can use the carrier pool when the calculated C/N0 of its signal is within the C/N0
range of the carrier pool. A terminal can jump from one carrier pool to another thanks to the
Adaptive Return Link on page 53 technology.
4CPM is sensitive to Adjacent Channel Interference (ACI). This means that the slot assigned to
one terminal can be 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 balance between the
dynamic range of the carrier pool and the ACI degradation.
It is advised to use the default C/N0 thresholds for the carrier pools.
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, which
"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 Operational Manual: Configuration Management.
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 them.
Following demodulators support 4CPM:
• MCD7000
• MCD7500
• NTC2291
A BDM is characterized by a certain 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 specified carrier spacing and a specified frequency
of the first carrier. All carriers within the BDM channel are adjacent in frequency.
The carrier pools or carrier types you have in a return capacity group, the more BDM channels this
will require, potentially limiting 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 MCD7000 within the same return
capacity group.
Assigning carrier types to the Return Capacity Groups and Carrier Pools can be
done via the Return Link web interface. For more information, refer to the
Operational Manual: Configuration Management.
A BDM has following configuration limitations:

NTC2291 MCD7500 24 MHz MCD7000/MCD7500

48 MHz
MCD7000/MCD7500
16 MHz
Processing 16 MHz 24 MHz 48 MHz

window
Input frequency 950 - 2150 MHz 950 - 2150 MHz 950 - 2150 MHz
Max. IP 22.16 Mbps 33.24 Mbps 45.97 Mbps

throughput
Max. number of 80 144 144

carriers
Nr of RX 4 * 4.096 MHz 3 x 8 MHz 3 * 16 MHz

channels
Nr of BDM 1 or 2, total max 1 or 2 or 3, total 1,2 or 3

channels per RX 4.096 MHz max 8 MHz
channel 16 MHz when only
TRF sots
8 MHz when TRF +

CSC
Supported TRF carrier: TRF carrier: TRF carrier:

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

MODCOD 0, 1 MODCOD 0, 1 MODCOD 0, 1

Carriers per BDM 10 carriers 128 kHz 16 carriers 128 16 carriers 128 kHz
channel, single TRF or CSC kHz TRF or CSC TRF or CSC
MODCOD
10 carriers 192 kHz 16 carriers 192 16 carriers 192 kHz
TRF kHz TRF TRF

TRF or CSC kHz TRF or CSC TRF or CSC

kHz TRF TRF
8 carriers 512 kHz
TRF or CSC 16 carriers 512 16 carriers 512 kHz
kHz TRF or CSC TRF or CSC
5 carriers 768 kHz
TRF 10 carriers 768 10 carriers 768 kHz
kHz TRF TRF
4 carriers 1024 kHz
TRF or CSC 8 carriers 1024 8 carriers 1024 kHz
2 carriers 1536 kHz
kHz TRF TRF
2 carriers 2048 kHz
TR or CSC 4 carriers 2048 4 carriers 2048 kHz
1 carrier 2560 kHz
kHz TRF TRF
1 carrier 3072 kHz
2 carriers 3072
TRF 2 carriers 3072 kHz
kHz TRF
TRF
1 carrier 3584 kHz
2 carriers 3584
TRF 2 carriers 3584 kHz
kHz TRF
TRF
1 carrier 4096 kHz
2 carriers 4096
TRF or CSC 2 carriers 4096 kHz
kHz TRF or CSC
TRF or CSC

4.2.6 4CPM Return Link End-to-End

Following functional blocks are involved in the 4CPM return end-to-end link.

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 burst demodulator. The
burst demodulator is responsible for:
• Demodulating the 4CPM bursts and forwarding the GSE encapsulated data to the DCP.
• Forwarding 4CPM layer 2 return signaling to the CPMCTL. The signaling includes return
bandwidth requests and ACM feedback .
The DCP or decapsulator is responsible for:
• Decapsulating the GSE datagrams.
• In case of layer 3 unicast traffic, it will forward the IP packets to the TAS. This traffic is tunneled
and optionally accelerated, compressed or encrypted IPv4 and/or IPv6 unicast IP traffic, including
DNS traffic.
• In case of layer 2 point-to-point virtual connections, it will forward the Ethernet packets to the
L2DEM through a GRE tunnel. The traffic will leave the hub module over a dedicated VLAN per
VC.
• In case of layer 3 multicast traffic, the IP traffic is sent to the uplink VLAN dedicated to terminal
multicast of the satellite network.
The TAS will forward the layer 3 IP traffic to the DEM, where it will leave the hub module over a
dedicated VLAN per subnet.
The CPMCTL is responsible for:
• 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.

• Shaping the traffic.

• Inserting the burst time plan info into the forward signaling and sending it back to the modem via
the 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 ranges
can go from 1 Mbaud up to 20 Mbaud (MDM3x00) or up to 64 Mbaud (MDM3310 and
MDMDM5000) 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 carrier 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 controller is will adjust the power and
MODCOD. The frequency and symbol rate are still statically configured. The bit rate will change as
the MODCOD changes.
4.3.2 Access Layer

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

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.
Following modem types support DVB-S2 or S2 Extensions in the return link:

MDM3300, MDM3310, MDM5000 and MDM5010.
4.3.3 DVB-S2 Return Link End-to-End

Following functional blocks are involved in the S2 return end-to-end 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 demodulator. 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 S2XCTL.
• Sending ACM feedback messages (indicating the Forward Es/No and requested MODCOD)
towards the CSE.
• In case of layer 3 unicast traffic, it will forward the IP traffic to the TAS. This traffic is tunneled and
optionally accelerated, compressed or encrypted IPv4 and/or IPv6 unicast IP traffic, including DNS
traffic.
• In case of layer 2 point-to-point virtual connections, it will forward the IP traffic to the L2DEM,
where it will leave the hub module over a dedicated VLAN per VC.
The S2XCTL 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 return link layer 2 signaling (destined for the remote modem) to the CSE.
• Sending the DVB-S2 related layer 2 signaling back to the remote modem via the modulator.
• Informing the remote modem about the result of the processed ACM feedback.

4.4 High Resolution Coding™

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.
Following demodulators support HRC:
• MCD6000
• MCD7000
• MCD7500
HRC works with frequency slots. A frequency slot has a start and stop frequency and acts as a
frequency window in which HRC carriers are deployed.
The maximum frequency slot bandwidth is 36 MHz for MCD6000 and 36 MHz or 72 MHz for
MCD7000 and MCD7500. You need to assign the HRC demodulator 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. 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 on the same HRC
demodulator.

4.4.1 Access Layer

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.
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.
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. Padding is added to the BBF if the BBF is not completely
filled yet.
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.2 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 mode. 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 case
of MCD6000 and up to 20 Mbaud in case of MCD7000/7500, in 30 kbaud granularity steps, and
combined with a very extensive range of MODCODs from QPSK up-to 32APSK. This results in
carrier throughputs up to 20 Mbps for MCD6000 and up to 70 Mbps for MCD7000/7500.
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.
Make sure to run the HRC calibration procedure before enabling ACM.
During the HRC 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 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.
Please refer to the HRC Calibration section in the Operational Manual:

Configuration Management for more details on how to execute this procedure.

4.4.3 HRC Mx-DMA

Mx-DMA return link technology brings together the best of 2 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 case of MCD6000 and up to 20 Mbaud in
case of MCD7000/7500, in 30 kbaud granularity steps, and combined with a very extensive range
of MODCODs from very low SNR (VLSNR) QPSK up to 32 APSK with 5% roll-off. This results in
carrier throughputs up to 20 Mbps for MCD6000 and up to 70 Mbps for MCD7000/7500.
• 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.
• 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
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 following figure:

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. Please refer to
Time and Frequency Synchronization on page 95 for more details.

• Terminals do not exceed the contractual Power Flux Density of the satellite. For more information,
refer to Automated Uplink Power Control.
• 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.
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.4 HRC Return Link End-to-End

Following functional blocks are involved in the HRC return end-to-end link.


• Encapsulating data into GSE baseband packets.
• Applying HRC modulation.
The traffic travels over the satellite link to the hub module and enters the demodulator. 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.
• Sending ACM feedback messages (indicating the Forward Es/No and requested MODCOD)
towards the CSE.
• In case of layer 3 unicast traffic, it will forward the IP traffic to the TAS. This traffic is tunneled and
optionally accelerated, compressed or encrypted IPv4 and/or IPv6 unicast IP traffic, including DNS
traffic.
• In case of layer 2 point-to-point virtual connections, it will forward the IP traffic to the L2DEM,
where it will leave the hub module over a dedicated VLAN per VC.
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 modulator.
• Informing the remote modem about the result of the processed ACM feedback.

Satellite Link Optimizations Functional Description v1.1 Newtec Dialog R2.2.1
5 Satellite Link Optimizations
5.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 Operational Manual:
Configuration Management.

5.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 Newtec 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.
5.3 Adaptive Coding Modulation

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 (CCM or Constant Coding and 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.
The Newtec 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 is based on applying mathematical filters on
the margin 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 Newtec Dialog
system.
5.3.1 ACM in the Forward

The Newtec 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.
The distortion margin, modulation loss, Forward ACM In and Forward ACM Down parameters are
configurable via the Forward Link web interface in the MODCODs submenu. 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). However it is advised to use the following 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.
In certain conditions it can occur that there are intermediate MODCODs when moving from a low
MODCOD to a high MODCOD. When moving upwards, all intermediate MODCODs are used before
reaching the high MODCOD. When dropping from high to low, the intermediate MODCODs are
skipped (in other words, it falls back immediately to the low MODCOD).

5.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 the HRC Mx-DMA return capacity group. ACM can be enabled or
disabled for the HRC SCPC return capacity group. It is disabled by default.
You can define the following HRC 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
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.
• 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 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 HRC Mx-DMA Return Capacity Group). The parameter is set via the Service Profile
Interface.
• 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.


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

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
HRC and 4CPM return technology and is only supported when using the following Outdoor Unit
(ODU) types:
• BUCs using modem output power control : MDM3xxx, MDM5xxx, MDM25xx.
• iLB2220 (MUC): 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 HRC and 4CPM are the same but the target values are defined in a
different way:
• When using AUPC in HRC the target value is the RX Power Density [dBm/Hz].
• When using AUPC in 4CPM the target value is the maximum C/No [dB/Hz].
Successfully operating a network in 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 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.
5.5 Satellite Return Uplink Optimization Technology

Handling
5.5.1 HRC
When using HRC in the return link, following optimization technologies apply:
• AUPC
• ACM
When both optimization techniques are used, the system will:
• Increase the TX power using the AUPC technology. The maximum TX power is Co/No. This
maximum power can be looked up in the GUI by navigating to the HRC calibration configuration
environment via the IMS as shown in the figure. In this example, max. C0/N0 is 10 dB (=Co Mean
- No Mean).

• If AUPC did not solve the fading, decrease the MODCOD (reducing efficiency) using ACM
technology.
• If fading is still not solved, decrease the symbol rate using ACM technology.
5.5.2 MF-TDMA 4CPM

When using MF-TDMA 4CPM, following optimization technologies apply:
• AUPC
• ARL
These technologies run independently from each other.
The AUPC technology will adjust the output power of each terminal up to the point that the terminal's
C/N0 reaches the largest C/N0 of any carrier pool. The adjusting the output power is rather slow and
is not able to compensate for fast fades. To know the maximum C/No of a carrier pool, navigate in
the IMS to the Return Frequency Plan> 4CPM > Each Return Carrier Pool (one-by-one) > Edit
RCP. When editing the Return Carrier Pool, a pop-up appears, containing a.o. the max. C/No for
that Return Carrier Pool. Changing these settings, will impact the AUPC behavior.

The ARL technology will select the appropriate carrier pool for every terminal based on the actual
measured C/No value. This technology will react much faster than the 4CPM AUPC technology. The
desired ARL behavior can be achieved through appropriate configuration of the ARL carrier pools.
When detecting a fade, ARL will react first by dropping the MODCOD (reducing efficiency) or
spacing (reducing maximum bitrate). Once AUPC has stabilized in the new situation (by increasing
C/No again), ARL will increase again the MODCOD and/or spacing.

Quality Of Service Functional Description v1.1 Newtec Dialog R2.2.1
6 Quality Of Service
Quality of Service or QoS is the ability to identify different data flows and to assign a different
behavior to the identified data flows. It is used to prioritize certain traffic flows above other traffic
flows in case of congestion. QoS is applied in four different steps, independent of the application or
network device you use:
1. Classification
2. Marking
3. Mapping and Queuing
4. Shaping
6.1 Classification
Ingress traffic is classified into different traffic classes based on rules. A rule is a set of one or more
criteria such as protocol, source/destination IP addresses, source/destination ports, network service
labels, DSCP values, VLAN tag, ... The rule, which matches first is applied. If multiple criteria are
defined in a rule, all criteria (AND functionality) must match to apply that rule.
The rules are set in a classification profile. The terminal is configured with a forward and return
ingress classification profile during terminal provisioning.
Different rules apply for layer 3 unicast traffic and layer 2 point-to-point traffic.
It is not possible to have a layer 2 and layer 3 classification rule for the same traffic
class within a classification profile.
The table below shows a typical mapping between application and traffic class.
Application Traffic Class
Radio/video contribution and distribution Real Time 1 (RT1)
VoIP telephony and interactive Real Time 2 (RT2)
VoIP signaling Real Time 3 (RT3)
Transactional Data and bulk data Critical Data 1..3 (CD1..3)
Non-critical data Best Effort (BE)
A "best-effort-only" classification profile is by default defined on the system. This classification profile
classifies all ingress layer 3 traffic into the Best Effort traffic class. It cannot be removed from the
system.
Additionally, in any created classification profile there's always an implicit layer 3 rule, which
classifies layer 3 traffic that does not match the rules that you have created as Best Effort traffic.

6.1.1 Inherit QoS Classification

In some cases, a Deep Packet Inspection (DPI) device is placed between the Newtec Dialog system
and the Internet. A DPI device inspects traffic flows up to application level. Hence it can recognize a
traffic flow as an application and mark the DSCP value of the packets within this traffic flow.
It can take several packets before a flow is detected by the DPI device. The DPI device will re-mark
the packets and change the DSCP values of subsequent packets for that application. The Newtec
Dialog system will detect the change of the DSCP value and give the packet another QoS behavior.
DPI devices are rather expensive and it is very likely that such device is not used at the remote
modem side. However you want the remote modem to apply the same classification as set at the
hub side. In that case you can set the Remote Side QoS Classification parameter, which can be
found in the classification profile. If Remote Side QoS Classification is set to Inherit QoS
classification, QoS classification at the remote (receiving) side applies the same QoS classification
as the sending side for a certain flow of packets.
Consider the following example to illustrate this behavior.
Suppose a VoIP call is initiated from the Internet towards an IP phone behind a remote modem. The
first VoIP packets arrive at the hub and are classified according the rules of the forward ingress
classification profile. Hence the first VoIP packets end up in the BE queue. After the third VoIP
packet, the DPI device recognizes the traffic flow as VoIP and starts marking packets with a DSCP
value. The Newtec Dialog hub recognizes this change and now puts VoIP packets into the RT1
queue, based on the classification profile rules.
The first VoIP packets in the return link are classified according to the rules of the return ingress
classification profile (in the example, first VoIP packets end up in BE queue). As the DPI device at
the hub side detected the traffic flow as VoIP and modified the marking of VoIP packets, and
because Inherit QoS classification is enabled, all other VoIP packets in the return link are classified
the same as at the hub side. Consequently, in our example the remaining VoIP packets end up in
the RT1 queue.
There are some restrictions when using the Inherit QoS classification setting:
• Use separate classification profiles for the forward and return link. Using the same classification
profile with inherit QoS enabled on both forward and return link is not allowed as it could result in
a loop.
• Make sure the service profile of the terminal has CIR and/or PIR for the inherited QoS class.
6.2 Marking
After classification, the ingress traffic can be marked. The Newtec Dialog system supports marking
based on Differentiated Services or DiffServ. This is a computer networking architecture (defined in

RFC2475) that specifies a mechanism for classifying and managing network traffic and providing
Quality of Service (QoS) in IP networks. DiffServ uses the 6-bit Differentiated Services Code Point
(DSCP) field in the IP header for packet classification purposes.
Marking can be done by an external device (for example a packet shaper) or inside the Newtec
Dialog system.
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 policies exist:

• Transparent: Incoming traffic which is already marked, passes the Newtec Dialog system without
any modification. In other words, the same marking is still applied at egress.
When external DSCP marking is applied on the ingress traffic, you should
define rules that correspond to the applied DSCP marking.
• Mark: Incoming traffic, which is not yet marked, is marked by the Newtec Dialog system at egress
based upon the internal DSCP settings. Internal DSCP settings are set via the Forward Link web
interface (advanced settings) or the Return Link web interface.

6.3 Mapping and Queuing

Once packets have been classified and marked, they are mapped into different queues or QoS
classes. In Newtec Dialog, the following QoS classes with their specific priority are defined:
QoS Class Priority
Real Time 1 (RT1) Highest absolute priority
Real Time 2 (RT2) 2nd absolute priority
Real Time 3 (RT3) 3rd absolute priority
Critical Data 1 (CD1) 4th absolute priority (+ Weight)
Best Effort The default quality class, lowest priority
• Real Time is intended for traffic that requires very low jitter/delay. Traffic profiles for real-time
traffic are typically tailored in such a way that the quality of service of these selected uses is
guaranteed, or at least prioritized over other classes of traffic. There are three real-time traffic
classes, each having an individual priority: RT1 has highest priority; RT3 has the lowest priority.
• Critical Data is intended for traffic that requires low 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
three critical-data traffic classes available. All three have equal priority, but are differentiated by
their individual weight: CD1 has highest weight; CD3 has lowest weight.
• Best Effort is all other kind of traffic that does not require prioritization or guarantees,
consequently such traffic is treated with the lowest priority.
Each QoS class has a queue time and queue size.
QoS Class Max. Queue Size Max. Queue Time
Forward Return Forward Return
Real-Time 1,2 50 MB 2.56 MB 50 ms 90 ms
Real-Time 3 50 MB 2.56 MB 50 ms • 4CPM: 2 s

• HRC: 500 ms
• S2: 200 ms
Critical-Data 1..3 50 MB 2.56 MB 300 ms • 4CPM: 2 s

• HRC: 500 ms
• S2: 200 ms
Best-Effort 50 MB 2.56 MB 300 ms • 4CPM: 2 s

• HRC: 500 ms
• S2: 200 ms

6.4 Shaping
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 with the entire satellite network or forward link.
The root of the return shaping tree corresponds with the return capacity group.
The root pool is divided in one or more child nodes or forward/return pools. Two types of pools exist:
class-based pool and transport-based pool. The type of pool defines the shaping model. The
forward/return pools can be dedicated to a VNO or shared between VNOs.
• 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 an aggregate level, the applications of
the terminals will contend for bandwidth in case of congestion. On the individual terminal level, the
applications are classified and mapped to QoS classes and the QoS classes 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.
• Transport-based: In a transport-based service, a customer rather buys a bandwidth pipe that has
a committed rate, sometimes burstable to a higher rate. The 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
transport-based service profile defines the shaping settings of the terminal circuit and the
individual QoS classes. This type of service is comparable with the concept of a leased line
(except that unused bandwidth within a pipe can be distributed amongst other transport-based
customers if necessary).
The shaping tree for both shaping models is represented here:

You can distinguish four shaping levels:

• Shaping Level 1: At this level the total capacity is represented; for the forward link this
corresponds with the entire satellite network; for the return link this corresponds with the return
capacity group.
• Shaping Level 2: At this level the root pool or container capacity is divided over forward/return
(and multicast) pools.
• Shaping Level 3: In case the pool is class-based, shaping level 3 represents the QoS pools. In
case of transport-based pools, shaping level 3 represents the terminal circuits. In case of multicast
pools, shaping level 3 represents the multicast circuits.
• Shaping Level 4: This shaping level represents the QoS classes.
There are no return pools when using the SCPC return technology. In this case, the
terminal circuits are directly linked to the return capacity group.
In the example above:

VNO1 is assigned to use the class-based pool, and VNO2 is assigned to both a class-based pool
and a transport-based pool. Applications classified as Best Effort on Terminal 1 and 2 use the
Shared BE QoS pool. Real Time 1 applications of Terminal 1 use the dedicated RT1 QoS pool and
Real Time 2 applications of Terminal 1 use the dedicated RT2 QoS pool. Applications classified as
Critical Data on Terminal 1 will be treated as Best Effort as Terminal 1 is not linked to a CD QoS
pool.
The shaping model is defined in the forward and return QoS plans and service profiles. The QoS
plan specifies the forward/return pools and QoS pools (class-based) and their shaping settings. The
service pool specifies the shaping settings for the QoS classes and terminal circuits
(transport-based). Terminals are linked to a forward and return pool and to a service profile.
Following shaping parameters can be set:

• Committed Information Rate or CIR specifies the data rate, which is always granted during data
rate distribution as long as the total available data rate is not exceeded.
• Peak Information Rate or PIR specifies the upper data rate limit.

• Weighted Rate is used as a ratio mechanism for "fair" distribution of the excess data rate after the
committed and peak rates have been applied.
It is possible to enable or disable CIR overbooking. If CIR overbooking is disabled, then the sum of
all CIR values of the child nodes cannot exceed the CIR value of the parent node. If CIR
overbooking is allowed, then the sum of the CIR values of the child(ren) can be greater than the CIR
value of the parent node.
Always pay attention when using CIR overbooking as this can have an impact on the
data rate a terminal receives. By enabling CIR overbooking the rate is no longer
guaranteed and can be less than expected (see example below).
CIR overbooking should only be applied if one can predict the average number of
concurrent capacity requests.
There are two Child Pool Shaping Modes available:

• Bit Rate Shaping: The unit of CIR and PIR in both root pool and child pools is Mbps. In this case,
two terminals with the same IP rates but different MODCOD will consume different bandwidth.
• Symbol Rate Shaping: The unit of CIR and PIR in the child pools is Mbaud. In the root pool the
unit of PIR is still Mbps and CIR cannot be set.
When entering the shaping values, the impact of applied header compression and
packet size needs to be taken into account. For example: a terminal has a Best-Effort
PIR of 1 Mbps defined in its service profile. When measuring the actual received bit
rate, it can differ from the value set in the service profile because of the impact of
encapsulation and/or compression. It is advised to use the IP rate calculator to
determine the actual bit rate which will be received.
Other fundamental shaping parameters are:

• Priority (static): Priority is defined by the QoS class. Keep in mind that Real Time 1 = highest
priority, and Best Effort = lowest priority.
• Shaping Volume (dynamic): Determined by the capacity requests coming from the terminal. The
capacity requests are triggered by the ingress traffic on the modem's LAN interface.
The allocation of bandwidth happens in two steps:
1. Distribute all configured CIR values.
2. Distribute all configured PIR values.
During these steps, the priority of QoS classes are taken into account.
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
class-pool level and finally the CIR values at terminal level. If there is still capacity left, the controller
distributes capacity based upon PIR values.
For all Real Time classes, the CIR value equals the PIR value. This implies that Real Time traffic is
not taken into account during the second bandwidth allocation step (distribution based on PIR).
Critical Data uses both a CIR and PIR value, and a weight value. All Critical Data QoS classes have
the same priority but different weight values. The weight factor indicates how bandwidth for Critical
Data is distributed in case of congestion. The following formula applies: weight factor = weight *
PIR. For example: if CD1 has a weight of 2, and CD2 has a weight of 1, then during congestion CD1
will get double as much bandwidth as CD2. It is the ratio between weight values that determines the
bandwidth allocation.
Best Effort only has a PIR value. This implies that best-effort traffic is not taken into account during
the first bandwidth allocation step.

If there is still capacity left after these two bandwidth allocation steps, this amount of capacity goes to
the Best Effort QoS class.
6.4.1 Allocation Type
The allocation type only exists for 4CPM MF-TDMA and HRC Mx-DMA return
technologies.
The allocation type has an influence on the assignment of return bandwidth. The following allocation
types exist:
• Static: Terminal receives the configured capacity, even if no requests are sent by the terminal. A
use case for this allocation type is video streaming, for which a continuous channel needs to be
available.
• Dynamic Ingress Rate or DIR: Terminal receives only the amount of capacity it requests (from
the total configured capacity). This allocation type can be used for traffic types which have the
ability to buffer data. Hence the capacity requests from one or more terminals are determined by
the (variable) size of buffered data. When using this allocation type and HRC Mx-DMA, it is
possible to specify a 'request margin' (in kbps). This is considered as an extra amount of
bandwidth a terminal always receives, on top of the requested amount.
• Dynamic Full Rate or DFR: Terminal receives all of the configured capacity as soon as any
capacity is requested. This allocation type is useful for VoIP traffic, as the terminal needs to have
the CIR at the moment the call is ongoing. When the call is finished, the bandwidth becomes
available again for others (so no need for a "continuous" link as would be the case with a
permanent video streaming).
The allocation type is set in the service profile. It can be specified for:
• Transport-based service profiles;
• Real Time 1 and Real Time 2 QoS classes in a class-based service profile. For the other QoS
classes, the allocation type is always DIR.
Following examples show the effect and (dis)advantages of the allocation types.
Suppose CIR is defined to support up to two simultaneous voice calls, and a second call sets up
during an active first call.
In case of the static allocation type, the required bandwidth is always available, even when there are
no active calls. There is enough bandwidth available at the setup of each call and during
simultaneous calls. However this is not efficient bandwidth usage, as the bandwidth is allocated but
unused when no calls are active.

In case of the dynamic full rate allocation type, the full CIR capacity becomes available but only
after the first call setup. This has the disadvantage that at the start of the first call, there is no
bandwidth available yet (available bandwidth lags behind the call). The advantage of this allocation
type is that there is already bandwidth available when the second call needs to start. At the end of
the second call, the resources are no longer required and become available for other requests.
In case of the dynamic ingress rate allocation type, only the requested amount of capacity for the
first call becomes available after the first call setup. At the start of the call, there is also no
bandwidth available yet. But this can be countered by using the request margin (only available for
HRC Mx-DMA), allowing to have bandwidth already available at the setup of the first call as well as
the second call. At the end of the second call, the resources are no longer required and become
available for other requests (except the requested margin, which remains allocated and hence can
be considered as 'wasted' when no calls are active).

6.5 QoS in Forward Link

The following functional blocks are involved in the forward QoS end-to-end link.

Layer 3 unicast traffic enters the Newtec Dialog hub module via the DEM. The DEM provides the
interface towards the customer infrastructure for layer 3 traffic and forwards the DSCP marked traffic
to the TAS. The TAS applies the layer 3 classification rules and marking (if needed). Traffic that is not
dropped is tunneled and optionally accelerated, compressed and encrypted and forwarded to the
CSE.
Layer 2 point-to-point traffic enters the Newtec Dialog hub module via the L2DEM. The L2DEM
provides the interface towards the customer infrastructure for layer 2 traffic and applies the layer 2
classification rules and marking (if needed). Traffic that is not dropped is forwarded to the CSE.
Multicast traffic is not classified and enters the Newtec Dialog system via the CSE.
The CSE applies the shaping model, which is defined through the forward pools and service profile.
After shaping, the traffic is encapsulated in baseband frames and forwarded to the modulator.
The modulator or MOD sends a DVB-S2(X) modulated RF signal over satellite towards the remote
terminal(s).
The remote terminal demodulates and decapsulates the received forward link signal. The enhanced
TCP (eTCP) tunnel, which was setup by the TAS is terminated on the TAS client of the modem.
Finally all traffic leaves the network interface of the modem.
Forward Shaping Tree

The forward link capacity is divided into different forward pools and multicast pools. The forward
pools can be class-based or transport-based, and dedicated to a VNO or shared by multiple VNOs.
The class-based pools are further divided into QoS pools. Terminals are either linked to a forward
pool (in case of a transport-based model) or to the QoS pools (in case of a class-based model).
This results in the following forward shaping tree.

• Shaping Level 1: At this level the total forward link capacity is represented.
• Shaping Level 2: At this level the forward link capacity is divided over forward (and multicast)
pools.
• Shaping Level 3: In case the forward pool is class-based, shaping level 3 represents the QoS
pools. In case of transport-based forward pools, shaping level 3 represents the terminal circuits. In
case of multicast pools, shaping level 3 represents the multicast circuits.
• Shaping Level 4: This shaping level represents the QoS classes.
Per shaping level different QoS shaping values can be set:
• Committed Information Rate (CIR): Specifies the data rate, which is always granted during data
rate distribution as long as the total available data rate is not exceeded.
• Peak Information Rate (PIR): Specifies the upper data rate limit.
• Weighted rate: Used as a ratio mechanism for "fair" distribution of the excess data rate after
guaranteed and prioritized rates are applied. This "fair" manner is controlled by the Weight
parameter.

6.6 QoS in Return Link
MF-TDMA 4CPM
The following functional blocks are involved in the 4CPM return QoS end-to-end link.

All traffic enters the remote terminal via the network interface. The remote terminal:
• Classifies and marks (if needed) the ingress data on its LAN port.
• Applies the shaping based on its service profile.
• Encapsulates the data into GSE baseband frames and applies 4CPM modulation.
• Requests bandwidth to transmit.
burst demodulator:
• Demodulates the 4CPM bursts and forwards the GSE encapsulated data to the DCP.
• Forwards 4CPM return signaling to the CPM controller or CPMCTL. The signaling includes return
bandwidth requests and ACM feedback.
The CPM controller applies the shaping model defined by the return pools and service profile, to
assign bandwidth capacity to the terminals based on the received bandwidth requests. The way
bandwidth is allocated depends on the selected Allocation Type on page 66 set in the service profile.
The DCP or decapsulator decapsulates the GSE packets and forwards the traffic.
• Layer 3 unicast traffic is forwarded to the TAS. The TAS will forward the traffic to the DEM, where
it will leave the hub module over a dedicated VLAN per subnet.
• Layer 2 point-to-point traffic is forwarded to the L2DEM, where it will leave the hub module over a
dedicated VLAN per virtual connection.
• Layer 3 multicast traffic is forwarded to the uplink VLAN dedicated to terminal multicast of the
satellite network.

SCPC and Mx-DMA HRC

The following functional blocks are involved in the HRC return QoS end-to-end link.

• Encapsulates the data into GSE baseband frames and applies HRC modulation.
• Requests bandwidth to transmit in case of HRC Mx-DMA.
demodulator:
• Demodulates the return signal and forwards the GSE encapsulated data to the DCP.
• Sends HRC modulation statistics and metrics to the HRC controller or HRCCTL.
In case of Mx-DMA, the HRC controller applies the shaping model defined by the return pools and
service profile, to assign bandwidth capacity to the terminals. The way bandwidth is allocated
depends on the selected Allocation Type on page 66 set in the service profile.
In case of SCPC, there are no bandwidth requests and shaping is done at return capacity group level
and at terminal level.
satellite network.
The DCP also sends ACM feedback messages (indicating the forward Es/No and requested
MODCOD) to the CSE.

SCPC DVB-S2 and S2 Extensions

The following functional blocks are involved in the DVB-S2 and S2 Extensions return QoS
end-to-end link.

• Encapsulates the data into GSE baseband frames and applies DVB-S2 or S2 Extensions
modulation.
demodulator:
• Demodulates the return signal and forwards the GSE encapsulated data to the DCP.
• Sends DVB-S2 modulation statistics and metrics to the S2 controller or S2XCTL.
The S2 controller applies the shaping model. In SCPC DVB-S2 or S2 Extensions, there are no
bandwidth requests and shaping is done at return capacity group level and at terminal level.
satellite network.
The DCP also sends ACM feedback messages (indicating the forward Es/No and requested
MODCOD) to the CSE.

Return Shaping Tree

Each return technology has its own shaping hierarchy.
MF-TDMA 4CPM
• Shaping Level 1: At this level the total 4CPM return capacity group is represented.
• Shaping Level 2: At this level the return capacity group is divided over return pools. The return
pools can be class-based or transport-based, and dedicated to a VNO or shared by multiple
VNOs.
• Shaping Level 3: In case the return pool is class-based, shaping level 3 represents the QoS
pools. In case of transport-based return pools, shaping level 3 represents the terminal circuits.
• Shaping Level 4: This shaping level represents the QoS classes. At this level the class-based
terminal circuit is also defined by a PIR value.

Mx-DMA HRC
• Shaping Level 1: At this level the total HRC return capacity group is represented.
• Shaping Level 2: At this level the return capacity group is divided over return pools. The return
pools can be class-based or transport-based, and dedicated to a VNO or shared by multiple
VNOs.
• Shaping Level 3: In case the return pool is class-based, shaping level 3 represents the QoS
pools. In case of transport-based return pools, shaping level 3 represents the terminal circuits.
• Shaping Level 4: This shaping level represents the QoS classes. At this level the class-based
terminal circuit is also defined by a PIR value.

SCPC HRC
• Shaping Level 1: At this level the total HRC return capacity group is represented.
• Shaping Level 2: At this level the return capacity group is divided over always-on SCPC carriers.
One terminal is linked to one SCPC carrier.
• Shaping Level 3: In case of class-based shaping, shaping level 3 represents the QoS classes. In
case of transport-based shaping, shaping level 3 represents the terminal circuits.
• Shaping Level 4: In case of transport-based shaping, shaping level 4 represents the QoS
classes.

SCPC S2
SCPC HRC and S2 do not use the concept of QoS class pools. In such cases, terminals are linked
with an SCPC circuit, and those circuits use the weight parameter in case of congestion.
• Shaping Level 1: At this level the total S2 return capacity group is represented.
• Shaping Level 2: At this level the return capacity group is divided over always-on SCPC carriers.
One terminal is linked to one SCPC carrier.
• Shaping Level 3: In case of class-based shaping, shaping level 3 represents the QoS classes. In
case of transport-based shaping, shaping level 3 represents the terminal circuits.
• Shaping Level 4: In case of transport-based shaping, shaping level 4 represents the QoS
classes.

Network Layer Optimization Functional Description v1.1 Newtec Dialog R2.2.1
7 Network Layer Optimization
7.1 IP Network Optimization

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 ile
downloads.
Network optimization techniques can be classified into TCP optimization and non-TCP optimization
approaches in Dialog platform. TCP optimization techniques include:
1. Acceleration
2. Compression
3. Aggregation
4. Cross-Layer-Optimization.
Non-TCP optimization consists of header compression and packet aggregation of non-TCP contents.

7.2 Network Optimization Parameters
7.2.1 TCP Acceleration

The TCP protocol is known to have some disadvantages in high latency and lossy networks, such as
long connection setup (aka TCP three-way handshake), slow throughput ramp-up (aka TCP slow
start), sensitivity to packet losses and high jitter (aka TCP congestion control) and the limitation of
throughput for one connection (aka TCP flow control). Moreover, TCP is a ‘chatty’ protocol which
generates a high amount of control data (e.g. TCP ACK packets) 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 Newtec Dialog, ETCP protocol is used to tunnel the data payload (for TCP) or the IP
fragments (for non-TCP) on 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).
When IP packets are captured and routed to the acceleration component, the packets are tunneled
via the ETCP reliable stream transmission to the remote peer.
For TCP-based traffic, ETCP protocol significantly reduces the amount of control data overhead (e.g.
from TCP ACKs). 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 connections (e.g. HTTP)
in the ETCP SYN are significantly speed
packet)

up (saving 1 RTT per

session)
Connection Slow start Fast start up to the Fast start allows to use
Startup (doubles rate maximum the available bandwidth
per RTT only), instantly
may differ
depending on
TCP 'flavor'
Acknowledgm Cumulative Aggregated ACKs, With aggregated ACKs

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

Length (IPv4+TCP header) bandwidth on the
header) satellite link
Bandwidth Every session Virtual circuit concept, A fair connection

Sharing competes with i.e. cooperative scheduler makes sure
others for the bandwidth usage that every TCP session
bandwidth between sessions with gets the same amount of
a fair session scheduler available bandwidth
to be TCP-Fair (i.e.
every session gets the
same amount of the
available bandwidth)
Resilience to May result in Tolerates high jitter of A robustness against

Jitter unneeded TCP several 100ms w/o high jitter is important for
segment unneeded VSAT systems with
re-transmission re-transmissions TDMA return links where
s 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.
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.
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 (On or Off) 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.

7.2.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 Newtec Dialog is based on lossless scheme.
It’s important to note that many content types are already compressed by design. E.g. 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.2.3 Header Compression

Header compression is introduced to convert the large header into a smaller header of a few bytes.
The Newtec Dialog platform supports IP, IP/TCP, IP/UDP and IP/UDP/RTP header compression of
unicast IPv4 as well as IPv6 traffic.
The header compression schemes 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 shows which header is compressed when a specific compression is enabled:
Compression / Traffic IP IP + IP + IP + UDP + IP + UDP +

UDP TCP RTP GTP
IP header x
compression
UDP header x
compression
TCP header x
compression
RTP header x
compression
GTP header x
compression
For example:

If only IP header compression is enabled, only the IP header of a packet is compressed. If IP and
UDP header compression are enabled, then the IP+UDP headers of a UDP packet and the IP
header of non-UDP packets are compressed.
If only RTP header compression is enabled, the IP+UDP+RTP header of an RTP packet are
compressed. The headers of UDP packets or IP packets, which are not RTP, are not compressed.
These schemes are complementary and not mutually exclusive. For example: If IP
header compression and IP/UDP header compression is activated, IP header
compression is applied to IP/UDP traffic and also to other IP traffic, for example
IP/ESP.
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 (because compression of headers consumes CPU), hence the lower
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.
It should be noted that header compression is most effective for stream-like applications like voice,
video, or file transfers.

7.2.4 Packet Aggregation

In order to maximize the payload of the IP packet being sent over satellite (up to the configured
MTU), several smaller IP packets are aggregated into a larger packet. By doing this there is a gain in
the amount of payload bytes.
In Newtec Dialog small packets are aggregated to be sent via the eTCP tunnel. The aggregation is
completed when either a maximum packet size or the aggregation timeout is reached. The timeout
for the aggregation can be configured in order to avoid long waiting times. The packet size and the
packet aggregation timeout can be configured per QoS class.
The aggregation layer is responsible for putting several upper layer packets into one lower layer
packet to save overhead of the lower layer protocols (including the eTCP security and protocol
adaption layer). Typically this is used for back-hauling systems where there are several simultaneous
phone calls. Using packet aggregation optimizes the frame rate and the satellite bandwidth usage.
This is displayed in the following example. In this example we visualize the aggregation of 3 calls
and as can be seen there is already a gain for a few calls. 6 separate packets are aggregated to 1
packet. So instead of using 6 headers only 1 header is used. In practice (VoIP case), even more
than 20 packets (60-bytes each) fit in one IP packet being sent over satellite.
To set this value a trade-off between delay and extra overhead has to be taken into account. Smaller
value decreases delay because there is a shorter waiting time to fill up the buffer. However, the
overhead will be increased since the buffer may not be completely full by the timeout.
The default value of packet buffer delay for all QoS classes is 20 ms. However, for jitter sensitive
real-time applications (typically in RT1 or RT2 QoS class) it is advised to set the timeout value to 1
ms.
We recommend to use the default values for non-real-time applications.

7.2.5 Cross-Layer-Optimization™ (CLO)

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 systems 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.
The essential facts with satellite communication is that the effective network capacity is changing
over time due to bad weather conditions. The main characteristic of dialog system is that the whole
system can be centrally controlled. 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 and this helps
to avoid the congestion of TCP traffic. CLO ensures that the satellite links are not overloaded. In
doing so, the congestion-based packet-loss of TCP traffic can be eliminated.
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 (also known as backpressure).
Terminology
Flow control: is an end-to-end control function that limits the sender's speed to the receiver's
speed. Imagine a fast sender and fast network, but a slow receiver (old computer, slow CPU,
complex computations, ...). If the sender does not slow down to match the receiver's speed, then the
amount of data received and waiting to be processed at the receiver would grow without bound.
Congestion control: refers to a sender-side function that limits the sender's speed to the speed of
the network. Senders use congestion control to learn about the speed of the slowest link on the
end-to-end path (called "bottleneck"). If a sender does not slow down to the bottleneck's speed, the
bottleneck router has to drop packets when "too much" data has been received and is waiting
("queued") for transmission over the bottleneck link.
Packet-loss: occurs when one or more packets of data fail to reach their destination. In general, in
IP-based computer networks, packet-loss may happen due to either congestion or network errors.
Why TCP gains more benefits

TCP is a broadly-used protocol, provides a reliable, end-to-end data service to applications.
However, in general, it does not perform well over satellite links. Low speed and occasionally high
error rates on satellite channels provide TCP with a challenging environment in which to operate.
Despite the progress on improving TCP, there remains some characteristics of the protocol syntax
and semantics that impair performance over satellite links, such as 3-way handshaking, slow start,
fair bandwidth allocation and congestion avoidance mechanisms. In dialog systems, the TCP
protocol can be replaced by the ETCP protocol, which is called TCP acceleration technique.
Moreover, since we know how much capacity we have in satellite communication system and by
using CLO, flow control of TCP traffic can be effectively performed.
Congestion and flow control
If a TCP connection is established over a satellite link, this slow link is the bottleneck of the TCP
connection. If there is no TCP acceleration and no CLO, then the speed of the TCP sender would be
determined by congestion control. The satellite router would drop packets when the sender's rate
exceeds the speed of the satellite link. The TCP sender reduces its speed when it detects the drops.
With TCP acceleration and CLO, the TCP connection ends at the TAS. Suddenly, to the TCP
sender, the satellite link looks like a slow TCP receiver. TCP sender speed is then determined by

flow control. In doing so, no packet loss occurs. TAS can use CLO to transmit data over the sat link
at optimal speed. Again, no congestion-based packet-Loss occurs.
Furthermore, it takes some times for the congestion control mechanism to learn about the
bottleneck speed. With TCP acceleration, the sender learns it much faster.
Packet-loss
With TCP, the root of packet-loss cannot be detected. Thus, the protocol always assumes that the
packet-loss is due to the congestion. To recover the lost data and avoid future losses, the rate of
transfers is reduced and the lost data is resent.
However, in the case of packet-loss with ETCP, thanks to the Cross-Layer-Optimization™
mechanism, the effective network capacity can be constantly monitored and the traffic rate
controlling feedback can be effectively sent back between different traffic and congestion
management components. In doing so, the protocol ensures that this is not due to congestion and
therefore the throughput won’t be reduced and data won’t be resent. Therefore, congestion-based
packet-loss of TCP packets can be avoided. However, it should be noted that the error-based
packet-loss is still inevitable.
How Cross-Layer-Optimization™ works

Cross-Layer-Optimization™ auto-optimizes the data link by continuous interaction between satellite
equipment, bandwidth management, shaping and acceleration technologies.
As can be seen in figure below, several components are collaborating sequentially to improve the
performance of satellite communication traffic:
• TAS: Acceleration, aggregation and compression are performed in TAS to increase bandwidth
efficiency and user satisfaction.
• CSE (Shaper): is in charge of queuing, shaping and prioritization of IP traffic.
• CSE (Encapsulator): is responsible for symbol rate to IP rate translation, ACM control and
encapsulation to Base Band Frame (BBF).
TAS is in charge of TCP acceleration and payload compression, packet aggregation, header
compression and encryption. There exists a few configuration parameters in the Dialog NMS to
manage these techniques. Activation/deactivation of acceleration is configurable on a per-service
profile-basis and configuration of Packet Aggregation on page 83 and Header Compression on page
81 are per QoS class.
As has been shown in the following figure, the IP traffic from Internet is read by the acceleration and
compression software on the TAS. According to the type of traffic and activation/deactivation of
different parameters, optimization techniques can be applied.

TAS translates TCP to the accelerated protocol (ETCP) and 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 and the shaping software on CSE translates the MODCOD to
bitrate and sends this information to the acceleration and compression software in the TAS server. In
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 being used to avoid having the sender send data too fast toward the TCP receiver, which is TAS in
this case. In such a case, TAS can be seen as a slow TCP 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. The TCP sender on the Internet will never send data more than the available
TCP queue size (~ 64K).
Ingress and egress rates of TAS may deviate slightly due to applying optimization
techniques, i.e. compression, acceleration and aggregation.
CSE (Shaper) anticipates the congestion and forecasts the rate per QoS queue based on the
current and historical traffic situations. CSE applies flow control toward TAS (also known as
backpressure). 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.

CLO provides a chain of feedback information from the satellite link to the shaper software on CSE
and then from acceleration and compression software on TAS to the original TCP sender. In short,
CLO enforces end-to-end QoS for IP traffic, enables flexible service profile (CIR/PIR) and adapts the
IP traffic throughput on-the-fly according to the service profile and weather conditions. The main
functionality of CLO is to improve the performance of TCP traffic over high-latency satellite links. In
Dialog systems, the TCP is replaced by ETCP protocol and the functionally of CLO can be
considered as flow control mechanism for ETCP protocol. This mainly results in an improvement in
the performance of TCP congestion control mechanism for TCP data over low-speed satellite
communication system.
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.

7.2.6 GTP Acceleration

GTP acceleration in the Newtec Dialog platform allows for traffic optimization (TCP acceleration and
header compression on UDP, IP and RTP traffic) inside GTP-U tunnels between a terminal and the
hub when using the Newtec Dialog solution in a mobile backhauling set-up.
Mobile users need to connect to networks such as the Internet. End-user devices (such as
smartphones and tablets) in a mobile network are located in a specific radio cell, which offers
connection within the mobile network and to external networks. The radio cells of the mobile network
define the RAN (Radio Access Network). The RAN is connected to the Mobile Core Network or
MCN, which is the part of the mobile network that carries out call switching and mobility
management functions and connection to external networks such as the Internet and PSTN (Public
Switched Telephone Networks). The cells are connected to the MCN via a ‘Serving Gateway’ which
is a.o. connected to external networks via a ‘Packet Data Network Gateway’ that offers the data
connectivity. The ‘Serving Gateway’ is also connected to a MME (Mobility Management Entity) which
his used by the end-user devices to register themselves on in the mobile network.
Newtec Dialog offers a satellite connection between the Radio Access Network (RAN) and the
Mobile Core Network, as an alternative to point-to-point radio or terrestrial connections. Data
between the RAN equipment in each cell and the Serving Gateway is handled through a
‘GTP-U-tunnel’. GTP is the abbreviation of GPRS tunneling protocol, where GPRS is the
abbreviation for General Packet Radio Service which is a mobile network data standard. Every
end-user device sets up at least one GTP-U tunnel. It is possible that one end-user device results in
more than one GTP-U tunnel (e.g. a GTP-U-tunnel for voice, and another one for data, or for a
specific application running on the end-user device). The Newtec Dialog platform does not recognize
the QCI (Quality of Service Class Identifier) in the mobile network but it does recognize the DSCP
values linked to the QCI.

The Newtec Dialog platform does not interfere with the signaling plane of the mobile network. The
signaling data of the mobile network goes over the network (via the RAN infrastructure over satellite
to the MME) in a transparent way. Each end-user device connecting to the network will register itself
via the MME. The associated user is identified via the Home Subscriber Subsystem (HSS) which is
connected to the MME. Every operator has this MME and HSS functionality in its network.
GTP-U Tunnel Correlation

For one TCP-connection between the end-user device in the mobile network and an external
network such as the Internet, two GTP-U tunnels are established:
• One uplink GTP-U tunnel from the end-user device via the RAN towards the Mobile Core
Network.
• One downlink GTP-U tunnel from the Mobile Core Network over the RAN towards the end-user
device.
The forward and return GTP-U tunnels must be linked to each other for a correct functioning. A
unique TCP 5-tuple is assumed at any one time in only one bi-directional GTP-U tunnel. A 5-tuple
refers to a set of five different values. It includes following parameters of the TCP connection: the
source IP address and port number, the destination IP address and port number next to the TCP
protocol in use. The Dialog user-plane is divided into several separated virtual networks (VRFs).
TCP connections are tracked for uniqueness across GTP-U tunnels within the same VRF.
The resulting scope for TCP acceleration processing is reflected in this figure:

This allows reusing the full IP-address pool in the user plane of different Newtec Dialog virtual
networks without any conflict. The data traffic going through the satellite Terminal shall pass through
a single virtual network. This virtual network is dedicated for mobile backhaul traffic and is not shared
with other mobile technology, neither with enterprise traffic or B2C (business to consumer) traffic. At
transport level one or more of virtual networks shall carry the mobile backhaul transport plane.
For the specific network, the traffic is marked as Mobile Backhaul Network traffic containing a
specific service label. This service label must correspond with the service label of the network in the
modem handling the traffic. The network must also be a 'Dedicated' network, since there are
typically multiple IP-addresses behind one terminal.
Mobility
Assuming that in a specific TCP connection a 5 tuple occurs at any one time in only one bidirectional
GTP tunnel allows to follow movement of TCP connections to new tunnels. It also facilitates tunnel
learning as we can easily associate TCP segments of the same connection in forward and return
directions. When a user equipment (UE) moves from one to another cell in the mobile network, a
new GTP-U tunnel to the new cell is set up and the new created tunnel are correlated. A UE going
idle and coming back is technically similar.

GTP Classifier
The GTP classifier associates received packets to a configured traffic class. Traffic classes are
learned per end-to-end connection, and the class determined for a forward packet is be reused for
packets in return direction. End-to-end connections are identified and classified based on the
standard internet headers, but also TCP connections inside GTP-U tunnels can be identified, and
packets can be classified based on fields from both tunnel and connection headers.
A tunnel is encrypted or not encrypted outside the Dialog system. If the tunnel is not encrypted by
external devices we can accelerated. If the tunnel is encrypted, it will pass by not accelerated.
The GTP classifier settings mark for each QoS class whether or not:
• GTP header compression as described in following section must be executed
• GTP acceleration as described in following section must be executed
Header Compression
For more generic information on header compression, we refer to Header compression. on page 81
Header compression reduces the number of bytes on the satellite link, by compressing a sequence
of one or more protocol headers at the beginning of a packet.
The methodology can not only compress IP, UDP, RTP, and TCP headers but also GTP-U tunnel
headers, IP, UDP, RTP and TCP headers inside GTP-U tunnels. For GTP-U tunnels, as a guideline,
the destination port is always 2152.
An example voice packet inside a GTP tunnel:

An example TCP header compression inside a GTP tunnel:
GTP packets with sequence number can be header compressed.
TCP Acceleration
For more information on generic TCP-acceleration, we refer to TCP acceleration. on page 78
TCP connections inside GTP-U tunnels are accelerated. TCP in GTP, where GTP uses sequence
numbers, cannot be accelerated (for now).
Between the Dialog terminal and hub module a bi-directional ETCP acceleration is used. The GTP
tunnel is intercepted transparently by both client and server. Since GTP is implemented on top of
UDP, a specific UDP port number shall be used (typically port 2152). The GTP tunnel will be opened
and detect the enclosed TCP sessions. In accordance to the configuration settings, header
compression and TCP acceleration is executed.
The TCP encapsulation is removed at the sending side and the payload data is transmitted through
the ETCP connection to the other side where the data is re-encapsulated.
GTP acceleration for a specific traffic class is activated in the user interface as described in the
Operational Manual: Configuration Management.

7.3 Performance Evaluation

This section provides an analysis on the impact of different network optimization techniques on the
network performance in terms of bandwidth efficiency.
7.3.1 Impact of TCP acceleration on bandwidth efficiency

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.
7.3.2 Impact of packet aggregation on bandwidth efficiency

The traffic classes in TelliNet are mapped to one of the 7 Dialog QoS classes and directed to the
corresponding shaping queue for scheduling. TelliNet tries to aggregate all packets belonged to a
same QoS class. There is only one aggregation buffer per QoS class.
The aggregation buffer will be flushed, when the configured packet aggregation time is reached for
the oldest packet in the buffer (a packet aggregation time of 0 ms will completely disable
aggregation for the traffic class). The buffer will also be flushed if the next packet differs in ETCP
label, DSCP code value or feedback shaping queue.
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.3.3 Impact of TCP payload compression on bandwidth

efficiency
In Newtec Dialog system, on average, TCP payload compression savings is 25% to 40%.
7.3.4 Impact of header compression on bandwidth efficiency

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

7.3.5 Scalability and bandwidth efficiency

Currently, the max 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.

Time and Frequency Functional Description v1.1 Newtec Dialog R2.2.1
Synchronization
8 Time and Frequency Synchronization

Shared access return link technologies, such as MF-TDMA and 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 Newtec 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

Synchronization
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 or 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 applies 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.
• 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 M6100 modulator has a very high stability, oven-controlled crystal oscillator and is well suited to
be used as the clock reference for the network. 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)
• 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.

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

Synchronization
• 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 148 and

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

Terminals Functional Description v1.1 Newtec Dialog R2.2.1
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 Modems
This chapter will discuss following modem types:
The legacy modem types MDM2200, MDM2500, MDM3x00 and MDM5000 are still
supported.

9.2.1 Specifications
The table below gives an overview of the performance, supported forward and return technologies,
supported ODUs and additional features:
MDM2210 MDM2510 MDM3310 MDM5010
Performance
Peak 100/5 Mbit/s 150/20 Mbit/s 125/70 Mbit/s 400/250 Mbit/s

throughput
Conc. 50/5 Mbit/s 75/10 Mbit/s 100/25 Mbit/s 400/200 Mbit/s

throughput
TCP sessions 2.000 16.000 24.000 75.000
PPS 10.000 28.000 90.000 250.000
GTP - - Yes Yes

acceleration
Supported Forward Technologies
DVB-S2 64 Mbaud 64 Mbaud 64 Mbaud 64 Mbaud

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

64 APSK 64 APSK 64 APSK 256 APSK
DVB-S2X 480 Mbaud 480 Mbaud 480 Mbaud 480 Mbaud

Annex M 64 APSK 64 APSK 64 APSK 64 APSK
Supported Return Technologies
MF-TDMA Yes Yes Yes Yes

4CPM
Mx-TDMA HRC - Yes Yes Yes
SCPC HRC - Yes Yes Yes
SCPC - - Yes Yes

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

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

-48Vdc mains - - Yes Yes

support
Additional Features
OpenAMIP - Yes Yes Yes
AIBS - Yes Yes Yes
#VLAN 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
9.2.2 Markets
The table below shows which markets the different modem types serve:

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 MDM2210 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:
MDM2210* Ku-band Ka-band
75cm 1m 1.2m 75cm 1m 1.2m

ANT2010 ANT2025 ANT2035 ANT2010 ANT2025 ANT2035
0.8W ILB2120 ILB2120 ILB2121
2W ILB2140 ILB2140 ILB2141 ILB2220 ILB2220 ILB2221
2W Quad ILB2145 ILB2145
*MDM2210 also supports ILB2210 and ILB2110. However, these ODUs are no longer in production.
The MDM2510 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:
MDM2510 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
2W Quad ILB2145 ILB2145

The MDM2510 and MDM3310 IP Satellite Modem 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
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.

9.4 Terminal Installation and Initialization

The terminal installation and initialization process can be divided in the following steps:
The following paragraphs describe these steps in more details.

9.4.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 102 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 136 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.

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.

Automatic Pointing
The automatic pointing method can be used for all modems except 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.

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

9.4.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 processes / 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 110.
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 105.
• 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.
• 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.4.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.4.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 110), which allows a fast convergence towards an
operational state.
9.4.5 Step 4: Return Link Synchronization

A terminal supports multiple return link technologies: 4CPM, HRC and DVB-S2. The actual used
return link technology is determined during terminal provisioning. Please refer to Modems on page
99 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 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.

9.4.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.
Please refer to MF-TDMA 4CPM on page 23 for more details about this return link
technology.

9.4.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
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
Please refer to SCPC DVB-S2 and S2 Extensions on page 32 for more details about

this return link technology.

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

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
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.
HRC Limitations
• An HRC demodulator can demodulate a maximum of 24 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 for MCD6000 and 70 MHz for MCD7000
and MCD7500. 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 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.
Please 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.
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. This is a huge optimization compared to the previous logon modes where
the hub polls all terminals (also the off-line ones).

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 = -10dB.
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
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.4.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
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.


9.5 Return Technology Switching

A terminal supports multiple return link technologies: 4CPM, HRC and DVB-S2(Ext). The actual used
return link technology is determined during terminal provisioning. Please refer to Modems on page
99 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 (especially in HRC).





9.6 Terminal Provisioning

Terminals only have access to the Newtec Dialog platform when they are provisioning at the hub
side. Both the hub network operator or HNO and the virtual network operator or VNO can perform
the provisioning actions. This 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.
Please refer to the Terminal Provisioning chapter in the Operational Manual:

Configuration Management for more details.

9.7 Terminal Usage

The following paragraphs describe the different scenarios for terminal usage and applicable
features.
9.7.1 Terminology
9.7.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 or 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 148).
9.7.1.2 Single Beam or Multi-beam Operation

A second distinction is whether the terminal operates in a single beam or in multiple beams:
• Single beam: A fixed or mobile terminal operates within a single beam and is provisioned in one
satellite network. Such terminals are linked with one pair of forward and return link resources via a
static attachment profile.
• Multi-beam: A fixed or mobile terminal can operate in multiple beams. Such terminals are linked
to forward and return link resources of each potential satellite network via a dynamic attachment
profile.
9.7.2 Attachment Profile

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 includes a beam, a satellite network, a forward pool (from that satellite
network) and a return pool (from that satellite network).
• 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 a dynamic attachment profile.

– A dynamic attachment profile includes a number of beams, satellite networks, a forward

pool (from each associated satellite network) and a return pool (from each associated
satellite network).
9.7.3 Use Cases

The figure below shows the possible terminal usage scenarios.
These scenarios are described in the following section:

• Fixed or COTP single beam terminal
• COTM single beam terminal
• Fixed terminal provisioned in multiple beams
• COTP terminal operating in multiple beams
• COTM terminal operating in multiple beams
9.7.3.1 Fixed or COTP Single Beam Terminal

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.
The fixed or COTP terminals can be subject to movement; for example when they are located on an
oil rig. For these terminals, the average speed still equals zero as they remain at the same
geographical location, 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. Refer to Doppler Effect on Terminals
on page 148 for more details.
9.7.3.2 COTM Single Beam Terminal

A COTM terminal operating in a single beam remains operational during its route within the beam.
Hence the terminal has a certain speed or acceleration when it is operational.
This is valid only for HRC Mx-DMA return link controllers.
For these terminals, COTM needs to be enabled (via the Mobility tab of the terminal provisioning
interface).

9.7.3.3 Fixed Terminal Provisioned in Multiple Beams
9.7.3.3.1 Description
This scenario concerns fixed terminals of which you do not know the physical location up front. In
that case you can "pre-provision" the terminal on multiple beams using an attachment profile. Once
the terminal is operational, it can be "pinned" to a single beam.
An attachment profile is a group of attachments and each attachment defines a beam, a satellite
network, a forward pool and a return pool.
The beams in the attachment profile are neighboring (adjacent) beams. Neighboring beams are
configured via the beam provisioning interface.
Following example is used to explain this functionality:

A satellite has four beams: A,B,C and D. Terminal T has coverage in three beams: A,B and C.

Each beam has its specific settings for (amongst others):

– NIT
– RMT
– Initial receive carrier
The terminal configuration contains an initial receive carrier, which is typically set in factory. This can
be the initial receive carrier of beam A, B or C. The terminal receives the signaling tables (NIT, RMT)
via this initial carrier. These signaling tables 'redirect' the terminal to its final traffic carrier. Each
forward traffic carrier has a data carrousel which contains the MAC addresses of all terminals
provisioned within the beam. If the terminal recognizes its MAC address it will become operational
on the traffic carrier of that specific beam.
Let's assume that the terminal is provisioned in beam C and that it uses the initial receive carrier of
beam A. Once pointed to the satellite and locked on the forward link, it receives the NIT table of
beam A and it will parse RMT table A which directs it to traffic carrier A. As terminal T is not
provisioned on beam A, it will not become operational. By configuring beams B and C as
neighbors of beam A, the RMT table of beam A will also contain the traffic carriers of beams
B and C. After trying traffic carrier A, it will try traffic carrier B. Again the terminal will not detect its
MAC address within the carrousel of traffic carrier B, so it will try forward carrier C. Now it will
recognize its MAC address and become operational on the traffic carrier of beam C.
If required (for reasons of load balancing for example), the operator can assign the terminal to a
different beam. Refer to Terminal Pinning Procedure on page 131 for more details.

9.7.3.3.2 Terminal Pinning Procedure
1. Click the info icon next to the attachment profile name to display the satellite networks
belonging to that attachment profile.
2. Select the beam to which the terminal must be pinned from the list and click the pin icon
3. The terminal is now pinned to the beam. The attachment type has been changed from dynamic
to static. The terminal is now de-provisioned from the other satellite networks (freeing up
capacity, addresses and roles).

9.7.3.4 COTP Terminal Operating in Multiple Beams

Terminals can also travel from one beam to another beam, for example in FNG (Fast News
Gathering) or SNG (Satellite News Gathering) cases. These COTP terminals are not operational
when traveling.
To explain this scenario, let's assume we have a COTP terminal provisioned to operate in HRC and
which can operate in SatNet 1 and SatNet 2. The COTP terminal needs to be able to operate in
multiple satellite networks, without having to delete or create the terminal when moving from one
satellite network to the other. The IP address range behind the terminal needs to be advertised via
the satellite network in which the terminal is operational.
The following prerequisites apply:

• 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 an attachment for
each satellite network ( (beam, satellite network, forward pool and return pool).
Provisioning the terminal on multiple satellite networks implies that the HRC
controller reserves capacity on each involved HRC demodulator. In this case,
MCD overbooking needs to be enabled. See MCD Overbooking on page 142 for
more information.
• In the Mobility tab of the terminal provisioning interface, beam roaming must be enabled
• 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 then selects the
beam identifier of the beam it is moving to.
The terminal can also automatically select the initial beam. Please refer to
Automatic Initial Beam Selection on page 136.

If the required beam settings are not yet available in the modem, then the
terminal operator can add the required beam settings via the modem GUI as well.
Please 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. It then receives a trigger from the hub to
logon using the HRC login carrier. As soon as the terminal has established return link connectivity,
the Newtec Dialog NMS notifies the DEM of SatNet1 to stop advertising the terminal network, and
instructs the DEM of SatNet2 to start advertising the terminal network. Route advertisement can be
done via OSPF or BGP.
To allow this 'dynamic' route advertisement, the Logon state based radio button must be enabled in
the Layer 3 Network tab when provisioning the modem. The Dedicated Subnet network type needs
to be used as well.
During this whole process, the terminal continues to use the same IP addresses.
9.7.3.5 COTM Terminal Operating in Multiple Beams

COTM terminals are terminals which move during operation. They have a certain speed and/or
acceleration and they can pass multiple satellite beam areas during their journey. COTM terminals
are able to switch between different satellite beam areas without losing the satellite connection.
Additionally, a mobile terminal can become operational at any moment in time during its route. It is
unpredictable in which beam a terminal resides when logging on.

Mobile terminals need to inform the hub where they are positioned by sending their GPS
coordinates. Based on that, the hub can track the route of the mobile terminals and instruct the
terminal to switch to another beam when necessary. The hub is also responsible for the automatic
network connectivity setup (beam assignment) when a terminal initially acquires the network.
The following elements are available on a Newtec Dialog platform to achieve these goals:
• Automatic Initial Beam Selection (AIBS)
• Mobility API
These elements interact as follows:
• AIBS controls the initial network acquisition process of a COTM terminal.
• Once the COTM terminal is online, all subsequent beam switching actions are based upon the
GPS coordinates sent by the terminal.
• All the mechanics of beam switching are handled by the Newtec Dialog NMS, including
provisioning/de-provisioning of terminals and coordination between hubs and satellite networks.
• The actual beam switching logic and business rules are implemented in a Mobility Manager, which
interfaces with the Newtec Dialog NMS via the Mobility API.
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.
ST Engineering iDirect provides a mobility manager. It is however possible to create

your own mobility manager using the mobility API description.

9.7.3.5.1 Automatic Initial Beam Selection
An important mobility aspect is the ability for the satellite modem to autonomously acquire the
network.
As you cannot predict in which beam a mobile terminal resides when logging on, Newtec Dialog
implements the Automatic Initial Beam Selection or AIBS, which is used to control the initial network
acquisition process.
AIBS is supported on all modems, except MDM2200 and MDM2210.
You can configure multiple beams via the terminal modem GUI and per beam you can define the
initial carriers and pointing carriers. With AIBS the modem can automatically select the best satellite
beam from the list of configured beams at startup of the modem.
Refer to the modem user manual for more details about adding beams via the
modem GUI.
To enable AIBS, select Auto as Spot Beam value during the installation of the terminal.
To automatically select a beam, the terminal needs to know its location on earth. Therefore, it
receives its GPS coordinates from an Antenna Control Unit (ACU). Communication between modem
and ACU is based on OpenAMIP protocol. Refer to the 'automatic pointing' section in
Terminal Installation for more details.
Once the modem knows its GPS coordinates, it parses all the configured beams to find out which
beams are eligible. The modem uses the GXT files, which contain beam contour data, to verify if its
GPS coordinates are loacted inside the contours of a beam.

GXT is a standardized file format from the International Telecommunication Union

(ITU).
A GXT file can contain information of multiple beams, which 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.
The modem GUI allows you to link a GXT file with a satellite beam. GXT files are typically provided
by the satellite operators.

GIMS is free software offered by ITU which allows you to visualize the beam
contours based on a GXT file.
Following requirements exist for the beam contour files generated from the satellite operator GXT
data:
• 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 simply connected.
• Contours shall be closed (if necessary by adding a segment of the satellite horizon).
• 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 process.
After parsing the local database of beams, multiple beams can be eligible to be used as initial beam.
If this is the case, then a ‘cost’ criteria can be set in order to select the preferred beam. This is useful
in situations where spot beams overlap. Following beam selection criteria are applied:
• First criteria is cost. The beam with the lowest cost is the preferred beam.
• If cost is equal, then the elevation angle is compared. However this only applies if the available
beams are on different satellites. The elevation angle determines which beam/satellite is closest to
the modem. Highest elevation means closest in longitude. A higher elevation has better link
quality than lower elevation.
• In case of equal cost and elevation, then the configured order is used to select the preferred beam.
The final result of the AIBS process is the selection of the initial beam. The modem then triggers the
ACU with corresponding antenna pointing data. If the parsing of the beams results in no eligible
beams, 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
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).
Refer to the modem user manual for more details on setting the initial receive
carrier.
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).
9.7.3.5.2 Mobility API
A mobile terminal uses AIBS to determine in which beam it can become operational. Once it is
operational, the hub starts tracking the terminal. The hub uses a Mobility API in order to get mobility
related data.
The mobility API is an application on the CMS, which is a virtual machine running on the NMS. It
collects modem state data from multiple sources inside the Newtec Dialog system. Some examples
of collected data are:
• Log in status (coming from the HRC Controller)
• Satellite beams and corresponding GXT files
• GPS coordinates (coming from the modem)
• HRC demodulation statistics (coming from the HRC MCDs)
• Beam congestion levels
The mobility API does not decide which beam a COTM terminal has to use. The decision to switch a
COTM terminal to another beam is taken by the Mobility Manager. The mobility manager
communicates with the mobility API of the hub via REST calls. Based on the data collected from the
hub and potentially other external relevant information, the mobility manager can decide to do a
beam handover and initiate it towards the Newtec Dialog platform through the mobility API.
The mobility manager software can be provided by ST Engineering iDirect or by a 3rd party.
The mobility API is also used to orchestrate the HRC logon behavior across all eligible beams, by
communicating with the HRC controller. A COTM terminal is typically provisioned on multiple satellite
networks via a dynamic attachment profile. Provisioning the terminal on multiple satellite networks
implies that the HRC controller reserves capacity on each involved HRC demodulator in all satellite
networks. To avoid “waste” of logon capacity on other HRC demodulators, the HRC controller is
instructed to lock the modem on unused beams. If the COTM terminal then switches to another
beam, then the previous 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 locked on other beams if it is logged in on a beam. If the modem is not logged on
any beam, then logon capacity for the modem is available on all satellite networks (HRC MCDs).

The hub knows on which beam a modem is connected because it communicates via the mobility
API with the HRC controller.
Terminals that are instructed to switch to another beam are prioritized for logon. No prioritization is
applied for terminals that have lost forward link connectivity for some reason and thus have returned
to AIBS state.
Hub controlled beam switching is only supported for terminals that use HRC Mx-DMA
as return link technology.
The following interactions occur between the involved components when switching beams:
• The mobility manager polls mobility related information (coordinates, beam) from the mobility API
and terminal statistics (signal to noise ratio) from the DMA.
• Based on the collected data, the mobility manager instructs the mobility API to switch a terminal to
another target beam.
• The HRC controller of the target beam satellite network unlocks the terminal and notifies the
mobility API of the new terminal state (LOGGING IN).
• The mobility API instructs the Forward Table Broadcaster (FTB) of the active beam satellite
network to request the terminal to switch to the target beam. Hence the terminal is signaled about
the request via its forward link.
If terminal is logged out of the active beam
• The HRC controller of the active beam notifies the mobility API of the new terminal state
(LOGGED OUT).
• The NMS disables the announcement of the terminal's IP address range via the previously active
beam. The DEM of the previously active satellite network stops announcing this route.
If terminal is logged in to the target beam
• The HRC controller of the target beam notifies the mobility API of the new terminal state
(LOGGED IN) and instructs the HRC controller of the previously active beam satellite network to
lock the terminal.
• The NMS enables the announcement of the terminal's IP address range via the target beam. The
DEM of the "new" satellite network starts announcing the terminal's IP address range.
The announcement of the IP address range can be done via OSPF or BGP, depending on the
routing protocol set for the virtual network.

In case BGP is selected and BGP is also enables between the modem and the hub, the routes in
the DEM are no longer static and can be automatically announced without instructions from the
NMS.
Whether BGP is used between the modem and the network behind it has no impact on the
behavior.

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

9.7.3.6 Summary
The table below shows a summary of the different use cases
Beam
UC Description Attachment COTM Route Advertisement
Roaming
Fixed or COTP
1 Static N N Static
single beam terminal
COTM single beam

2 Static Y N Static
terminal
Fixed terminal
3 Dynamic N N Static
(multiple beams)
COTP terminal
4 Dynamic N Y Dynamic
(multiple beams)
COTM terminal
5 Dynamic Y Y Dynamic
(multiple beams)
Where:
• Attachment
– Static: the terminal is provisioned in a single beam
– Dynamic: the terminal is provisioned in multiple beams. This is done by linking the terminal
to 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.
Consequently such terminals will be known within the mobility API.
– N: Beam roaming is disabled, the terminal operates in a single beam.
• Route advertisement
– Static
– Dynamic (log-on state based)
Note: dynamic is only possible for modems using HRC Mx-DMA return technology

9.7.4 Terminal Usage Summary

The following table shows the compatibility between modem type and terminal use scenario:
MDM2xx0 MDM3xx0 MDM5000/5010
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

9.8 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 95, 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.
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 95) to protect the network from the uncertainties
introduced.
The HRC and DVB-S2 return link controllers in the hub need to take these 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
return link technology, following formulas exist to determine the additional guard bands.
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 148 for the impact of terminal

movements.

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.

9.9 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 95 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 HRC and DVB-S2 return link controllers in the hub need to take these guard times into account
when allocating return link resources to the COTM terminals. The main requirement of controllers is
to avoid overlap of frequency ranges or carriers. For the HRC and the DVB-S2 return link
technology, following formulas exist to determine the additional guard bands.
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.

Via the Mobility tab of the Terminal Provisioning interface, it is possible to define whether or not the
modem uses "communication on the move".

The following table provides rule of thumb values for the maximum speed and acceleration
parameter to use in COTM scenarios.
Application Max Speed Max 4CPM HRC DVB-S2/S2Ext

(m/s) Acceleration
(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 (>2 Mbaud)
KU or
C-band
Aeronautical airliner 350 6 ✖ ✔ ✔

midflight (>2 Mbaud)
Aeronautical airliner 17 ✖ ✔ ✔
all conditions (>10 Mbaud)
Refer to the Operational Manual for more details about setting parameters for
"Communication on the Move".

The effect of setting the maximum speed in the Terminal Provisioning interface is visible in the
Return Link Frequency Plan.

The effect of changing the maximum speed and the maximum frequency uncertainty in the Terminal
Provisioning interface is visible in the Return Link Frequency Plan.

9.10 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 NMS

MIB.
get next Readout the current value of the next object in the NMS
MIB.
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.
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.10.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
• 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 Functional Description v1.1 Newtec Dialog R2.2.1
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
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
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
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
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

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

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

Functional Description v1

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Functional Description v1

Hochgeladen von

Copyright:

Verfügbare Formate

Newtec Dialog

Functional Description v1.1

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

3 Forward Link ................................................................................................... 6

4 Return Link .................................................................................................... 21

4.4.2 HRC SCPC ..................................................................................................................................... 37

5 Satellite Link Optimizations ......................................................................... 42

6 Quality Of Service ......................................................................................... 58

7 Network Layer Optimization ......................................................................... 77

8 Time and Frequency Synchronization ........................................................ 95

9.7.3.5.2 Mobility API .......................................................................................................................... 139

10 Abbreviations ............................................................................................ 156

1.1 About This Manual

1.2 Version History

Version Date Reason of new version

1.0 December 2019 Initial version of this release.

1.1 December 2019 Minor updates.

1.3 Cautions and Symbols

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

Confidentiality: Unrestricted 1/160

2 What is Newtec Dialog®

Confidentiality: Unrestricted 2/160

Confidentiality: Unrestricted 3/160

Confidentiality: Unrestricted 4/160

Confidentiality: Unrestricted 5/160

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)

Confidentiality: Unrestricted 6/160

3.2 DVB-S2(X) Key Concepts

3.2.1 Baseband Frames

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

Confidentiality: Unrestricted 7/160

• BPSK: 1 bit per symbol.

Confidentiality: Unrestricted 8/160

Confidentiality: Unrestricted 9/160

3.2.3 Forward Error Correction

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

ID Modulation Coding Normal Frame Short Frame

Confidentiality: Unrestricted 10/160

ID Modulation Coding Normal Frame Short Frame

Confidentiality: Unrestricted 11/160

ID Modulation Coding Normal Frame Short Frame

Confidentiality: Unrestricted 12/160

ID Modulation Coding Normal Frame Short Frame

Confidentiality: Unrestricted 13/160

ID Modulation Coding Normal Frame Short Frame

Confidentiality: Unrestricted 14/160

ID Modulation Coding Normal Frame Short Frame

Confidentiality: Unrestricted 15/160

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

Confidentiality: Unrestricted 16/160