2Way-Sat

A DVB-RCS Satellite Access Network

by Dirk Breynaert, Newtec

Brussels - 23 September 2003

Abstract

The article describes a DVB-RCS compliant Satellite Access Network-concept called

"2Way-Sat". After describing the different players in the Business Model, an overview
of the total Network Architecture is given, with more details on the heart of the HUB
station : "The Carrier Blade". Several examples of services offered to end customers
are provided. With Satellite Bandwidth being quite expensive, adequate bandwidth
shaping and QoS-prioritisation is realised. Bench marking is foreseen in order to
verify the end performance.
Finally, some implementation aspects are described, for all elements of the Network.

Introduction
Newtec is active in DVB-RCS since 1998 and
delivered its first fully commercial network in
2002. During 2003, more networks are being
delivered worldwide.
Today, many end-customers have a daily real
broadband experience on our DVB-RCS
Satellite Access Networks.
- a set of services, which are offered
(e.g. Internet Access, Pre-fetching,
Web Caching, Software Download,
etc…)
- traffic volume (average, maximum, …)
- quality of service (priority, bandwidth,
availability)
- number of terminals.

DVB-RCS : "The Open Standard"
In 1999, the DVB-RCS was standardised [1],
[2] and complemented in 2003 by a new
standard for the Forward Link called DVB-S2
[3]. The DVB standardisation process is now
adopted by a large number of manufacturers,
operators, users and research institutes
assembled in the Satlabs Group [4] and the
DVB-RCS interoperability process is ongoing.
Satlabs certification procedures are being
developed. The standard has been field
proven in a commercial environment [5].
2 Way-Sat Business Model
The main players in the business model are :
(i) SAP
The Satellite Access Provider usually
sells transponder capacity and operates
the HUB. The SAP will guarantee a
certain performance / price for multiple
ISPs like :
(ii) ISPs
The Internet Service Providers (or
equivalent distributors) will sell Internet
Access and / or other Value Added
Services to End Customers.
The ISP will guarantee performance /
price for these End Customers and act as
a single point of contact to manage their
SIT (Satellite Interactive terminal).
(iii) End-customers
These are usually SMEs (Small and
Medium-sized Enterprises), Internet
Cafés and SOHOs which are in need of a
broadband return link (upload).
DVB-RCS will be most attractive for those
upload users who need a combination of
a high peak and a low-to-medium average
return rate, since in that case the
statistical multiplexing of the satellite is
most effective.
(iv) SIT-installers
Install SITs at the End-Customer on
behalf of the ISPs.
(v) Network Supplier
Delivers the HUB to the SAP.
(vi) SIT Supplier
Supplies SITs to the ISP. These SITs are
approved by the Network Supplier before
introduction into the Network.

1
The Network Architecture
A typical 2 Way-Sat Network consists of the
following elements (see Figure 1) :
(i) Satellite
For non-mass-market networks, Ku-band
has the advantage that existing satellites
can be used.
For the Forward-Link (“FW”), often the 13
GHz band is used in single or dual carrier
per transponder operation (low gain - ALC
activated).
For the Return-Link (“RT”), mainly the
14.0 - 14.25 GHz VSAT band is used in
multi-carrier, high-gain operation.
For mass-market networks (for example 1
Million users) Ka-band satellites with
multi-spot beams are recommended.
This will certainly require the realisation of
adaptive modulation and coding the FW-
link, as has been standardised in DVB-
S2.
(ii) SIT (Satellite Interactive Terminal)
A generic SIT consists of the following
elements :
- Outdoor Unit
(iii)
Consisting of a reflector (antenna), a
masthead and a front-end (amplifier,
LNA, up- and down-converter). In
absence of interference from adjacent
satellites at 2 Degree offset , reflector
diameters as small as 75 cm can be
used ; else 90, 120 or 180 cm are
required.
High peak RT rates (e.g. 600 to 1000
kbps) can already be achieved with 2
Watt front-ends.
- Indoor Unit
Consisting of a Demodulator (DVB-S
or DVB-S2), a Burst Modulator and a
DVB-RCS processor, which maps IP
packets (over Ethernet) to and from
the DVB-RCS air interface.
The Indoor Unit is managed via the
POP Router.
2
- POP Router
Allowing remote software updates via
the HUB and a series of services,
such as :
• DNS Caching
• HTTP Services (with Pre-fetching
and TCP acceleration)
• Web Caching
• E-mail relay
• NAT (Network Address Translation)
And Value Added Services, such as :
• DHCP (to automatically assign
an IP address to a host on the
customer’s LAN)
• Firewall
- Optionally, a VPN Router can be
provided by the End-customer.
- CPE LAN
HUB-station
A SIT will be assigned to one FW carrier,
and will return data to the HUB over a
pool of RT-carriers using MF-TDMA.
The HUB is realised in a modular way and
consists of the following parts :
- an RF Subsystem : which usually
consists of a large Antenna, a
Tracking SS (Sub-System), an HPA
SS and LNB SS.
- a Carrier Blade SS, which realises in
the FW-Link and corresponding RT -
Links :
- statistical multiplexing in FW & RT
- bandwidth shaping & prioritisation
of value added services specific to
Satellite Access, like HTTP Pre-
fetching & Acceleration and Web
Caching).
Note that during the HUB & SIT
lifetime, there will be constant
evolution in features (e.g. DVB-S2).
The Carrier Blades will support
upcoming features over the years to
come.
 - a Common SS with functionalities for
all Carrier Blades : such as Time &
Frequency Generation, Satellite
Position Tracking, Customer
Configuration Management, POP
Management, etc… .
- an Internet Edge Router, performing
terrestrial interconnection to the
Internet Backbone, is usually
provided by the SAP.
Carrier Blade Architecture
The general block diagram of a Carrier Blade
SS is shown in Figure 2.
(i) The FW-Link is consisting of following
elements :
- the SLR (Satellite Link Router), which
performs bandwidth shaping and QoS
prioritisation (DiffServ) in combination
with access services like HPS (HTTP
Pre-fetching Server) and WCS (Web
Caching Server).
- The FLE ( Forward Link Combiner &
IP Encapsulator) will combine the FW
traffic from the SLR and signalling
information from the RLP-Scheduler
and encapsulate both into a DVB-S
stream.
- the FW_MOD (Forward Modulator),
will combine the encapsulated data
with NCR (Network Clock Reference)
information and modulate the FW
carrier according DVB-S(2). Accurate
time information is also sent to the
BDMs (Burst Demodulators) in the
Return Link via an ASI-signal.
(ii) The RT-Link is consisting of :
- the BDM-bank (Burst Demodulator) in
an N+1 redundancy configuration. A
pool of RT carriers (in MF-TDMA) are
sent to the SLR via ATM-AAL5-OC3.
An ATM_MUX is required to combine
several BDMs. The capacity requests
from the SITs are sent by the BDM-
bank to an RLP-bank (Return Link
Processor) via Ethernet. Note that the
BDMs are outperforming competition
in link budget performance.
- the RLP-bank will calculate the
optimum RT-burst time every
superframe (around 140 msec), and
sends this to all SITs via the FLE. The
RLP-Statistical Multiplexing algorithms
are very performing and suitable for a
mix of bursty traffic (like HTTP) and
real-time constant traffic (like VoIP
and Video Conference).
The RLP will realise bandwidth
Shaping & QoS prioritisation in the
Return Link.
- the SLR will realise ATM-AAL5
termination for the Return Link).
3
(iii) IP Value Added Services
To minimise the effect of satellite delay,
which is very annoying when browsing
multi-object pages, a combination of HPS
(HTTP Pre-fetching Server), TCP
enhancement and WCS (Web Caching
Server) is realised. For reasons of
scalability, this is done in each Carrier
Blade and not in the Common SS.
(iv) Management Services
Include following parts :
- The SEMS (Satellite Earth Station
Management) handles possible fault
management of each element of each
Carrier Blade and configures the RF
layer equipment, as well as the
Access Equipment (except FLE and
Scheduler).
- SDR (SIT Drive)
The SDR collects performance data
from the BDM-bank and generates a
correlation with the scheduled burst
time plan it receives from the RLP.
This quasi-real time SIT & RLP
performance data is sent to the PMT
for further management.
- PMT (Performance Monitor Tool)
The PMT collects performance data
from several elements (SDR, PMS,
etc..) in the Carrier Blade (the
Common part of the PMT functionality
will be hosted in the CCMT).
- PMS (POP Management Server)
The PMS performs fault &
configuration management of the SITs
and sends performance data to the
PMT for further processing.
- CCMT (Customer Configuration
Management Tool)
This unit is located in the
Common_SS only.
The CCMT performs configuration,
service and resource management
tasks like e.g. enabling and disabling
SITs, FW & RT bandwidth selection,
etc; in interaction with a Customer
Configuration Centre (CCC).
User Access Service Examples
(i) DHCP service
PCs connected to the Customer’s LAN
can automatically obtain an IP address, a
DNS server address and a default
Gateway address (of the POP Router).
(ii) DNS Cache service
The POP Router has an integrated DNS
Proxy Server, which communicates with
the DNS Server at the HUB (located at
PMS).
(iii) E-mail transfer service
The End-Customer's outgoing mails are
forwarded to the Mail Transfer Server
located at the Internet. Incoming mails
are forwarded to the Mail Server of the
End-Customer.
(iv) Firewall service
Default Firewall rules can be enabled.
(v) VPN transparent service
Creation of virtual private networks by
opening the ports and protocols of the
POP Router (PPTP or IPsec) is allowed.
This can be used in combination with a
customer provided VPN Router.
(vi) BW reservation service
The SAP can reserve a bandwidth on FW
& RT link for real-time traffic. (This type
of traffic has highest priority).
(vii) Static Multicast service
This allows End-Customers to join an
active multicast session via their web-
browser.
(viii) Video Conference service
This allows End-Customers to connect a
Video Conference client box to their LAN
and get access to the Video Conference
Servers connected to the HUB (future
service).
(ix) VoIP service
By providing one or more connection
points to the local PSTN network via a
SIT and a Media Gateway, cost effective
international phone calls can be realized
(future service).
Bandwidth Shaping & QoS prioritisation
Each end-user will experience the following
QoS performance, based on :
(i) The FW-pool to which he has been
assigned. The FW capacity is split into
several pools. In each pool, a certain
peak and average bandwidth is
guaranteed, with fair sharing by all users
in the same pool.
(ii) The HPS (HTTP–Pre-fetching Server)
class, to which it has been assigned. Pre-
fetching will use push technology at
certain rates.
(iii) The FW-SIT bandwidth is configurable for
each SIT/POP Router.
4
(iv) The RT bandwidth, configurable for each
SIT in the RLP.
Prioritisation in RT is possible via DiffServ
mechanism in the POP Router, which is
mapped to DVB-RCS allocation classes in
the RLP, like VBDC (Volume Based
Dynamic Capacity) and CRA (Constant
Rate Assignment).
(v) To increase the RT-availability in regions
with large fading, ACM (Adaptive Coding
& Modulation) is realised ; whereby the
SIT will dynamically change between
carrier pools to maintain a quasi-error-free
RT-link.
Bench Marking of Satellite Access
Performance
(i) End-Customer Experience
One of the success factors of 2Way-Sat is
the real Broadband experience the
customers must feel. It is well known that
the satellite delay (250 msec one-way)
results in a throughput limit up to around
300 kbps for typical TCP connections.
TCP accelerators help to overcome this
effect and increase throughput speed,
however a non-Broadband response
experience (e.g. 40 sec) is normally felt
when multi-object pages have to be
downloaded. A typical example of such a
page is " www.nytimes.com", with appr.
50 objects and around 200 Kbytes of
contents to transfer. To solve this
problem, an HPS (HTTP Pre-fetching
Server) in installed in the HUB.
When a user downloads this page, the
HPS will “fetch” it over the IP Backbone
(very wideband and low delay) and when
it is complete, it will push it over the
Access Network to the end customer.
The typical result is that in 50% of the
cases, the download time is below 6 sec,
in 90% below 10 sec, in 99% below 15
sec. For this typical page a cumulative
histogram of the HTTP Download test can
easily be made over several access
networks. Another important Broadband
Experience is how fast files can be
uploaded. A typical example is an FTP
upload of a 1 MByte file. In case of a
maximum RT-speed of 400 kbps, this
upload will be minimum around 20 sec.
Performance in case of low load is shown
in Table 1 hereafter.
Probability HTTP FTP
Download Upload
"nytimes.com" (1 MByte )
50% 7 sec 20 sec
90% 11 sec 24 sec
99% 13 sec 28 sec
Table 1 : Bench marking performance of
2Way-Sat (under low load condition)
 When the load is increasing, the response
time will increase also ; for example when
the load increases from 0 to “full forward
carrier capacity”, the mean download time
“nytimes.com” increases from 7 seconds
to 9 seconds.
When at this load, the number of users
would be doubled, the response time
would also be doubled to 18 seconds.
So, by monitoring the mean download
time, the virtual requesting load can be
measured.
The response time increase limits are to
be decided by each ISP.
(ii) ISP Experience
The ISP of course is also interested in the
End Customer Broadband Experience,
but he also has to pay the SAP for HUB
use and satellite bandwidth consumption.
So “price experience” will be very
important. The SAP cost is mainly
relative to the traffic volume and not that
much to bandwidth experience (on
condition that enough clients are present
to allow the use of an efficient statistical
multiplexing).
For example :
SAP cost =
X1 x (GByte-FW) + X2 x (Gbyte -RT)
e.g. X1 = 60 Euro/GByte - FW
X2 = 90 Euro/GByte - RT
The challenge of the 2Way-Sat design
has been to realise a good compromise
between efficient transponder usage and
still good End-Customer Broadband
Experience.
The transmission efficiency can be
measured by logging the total FW & RT
traffic every day and compare it to the
transponder limits. In general, it is
expected that the transmission limits will
be updated every month in order to follow
the measured growing traffic.
An example is shown hereafter in Fig. 3.
2Way-Sat Implementation Aspects
(i) HUB Implementations
The basic implementation is a 2Way-
Sat.Plus version, which supports max. 8
Carrier Blades and up to max. 32000
SITs.
Being a scalable system, it means that
the satellite bandwidth and number of
terminals can grow by simply adding more
equipment, without interrupting the normal
operation of the network. Note that for
such operational systems, full automatic
redundancy is foreseen, resulting into an
availability better than 99.99%.
A simpler implementation is the 2Way-
Sat.Light version, which supports only 1
5
Carrier Blade and a max. of 1000 SITs.
2Way-Sat Light cannot grow over 1000
SITs without rewiring and reconfiguration
of the HUB.
A third implementation will be a 2Way-
Sat.Consumer version. It will require
further development of adaptive
modulation and coding in the FW link, as
presently foreseen in the DVB-S2
standard. It is expected to be
commercially deployed from 2005
onwards.
(ii) SIT Implementation
- For professional End-Customers (cfr.
2Way-Sat.Plus), the most successful
networks [5] are using Ku-band, since
many satellites are available and
antenna sizes can be as small as 75
cm. However, depending on the
satellite contours and potential
interference from and to adjacent
satellites, 90 cm - 120 cm and even 180
cm could be required.
- Presently, 2 front-ends are available :
one non-integrated front-end, where
Feed, OMT, Block Up Converter and
LNB are separate units ; and an
integrated front-end, where OMT, BUC
and LNB are mechanically integrated.
The integrated version is suitable for
networks using a large volume of
identical outdoor units.
The IDU and POP Router are
separately housed units. In specific
cases (higher volumes, same
applications), it will be possible to have
both integrated.
- It is possible to install SITs on ships, by
using conventionally 3-axis stabilised
antennas, or on transportable platforms.
This however requires the permanent
update of the SIT position (via local
GPS), and calculation of the changing
transmit time.
- Interoperability with other SIT
manufacturers is progressing quite well
and reporting of this activity is given via
the SATLABS organisation.
(iii) Satellites
It is not required that the HUB receives its
own FW link signal or accurate Satellite
Position Tables from the Satellite
Provider, since it will track the Satellite
Position itself.
In general, satellites stay within a 0.1
degree variation box. Larger variations
can be allowed as long as the satellite
stays within the beam-width of the SIT
antennas.
Security Aspects References

The system has built-in security like "Static [1]
Routing & Firewalls". However for those End-
Customers, accessing the www.security is not
a too big issue. [2]
When business clients are communicating with
each other, often VPNs are created. 2Way-Sat
has the possibility to realise a solution whereby [3]
security (VPN & IPsec, controlled by ISP) and
broadband experience (acceleration) are
combined. However, those clients, who want [4]
to have full control over the security part, can
do this outside the 2Way-Sat domain. Due to
the satellite delay, they should combine
security and acceleration (or even Pre-fetching) [5]
themselves.
DVB-RCS Standard : EN 301790 V131
Mar-03
DVB-RCS Guideline : TR 101790 v121
Jan-03
DVB-S2 DRAFT Next Generation Satellite
Modulation / Coding Standard TM2860
Satlabs Group
http://telecom.esa.int/telecom
→ Special Internet groups → Satlabs
www.aramiska.com

List of Acronyms About Newtec and the author

ACM : Adaptive Coding & Modulation Newtec is a leading SATCOM supplier for
ALC : Automatic Level Control Broadband Access Networks, for Professional
BDM : Burst Demodulator SATCOM systems and for iTV Solutions.
BUC : Block Up Converter Dirk Breynaert is one of the founders and CEO
CCC : Customer Care Centre of Newtec Cy.
CCMT : Customer Configuration
Management Tool Contact information :
CPE : Customer Premises Equipment Tel : +32 3 780 65 00
CRA : Constant Rate Assignment Fax : +32 3 780 65 49
web : www.newtec.be
DHCP : Dynamic Host Configuration
Protocol
DNS : Domain Name Server
DVB : Digital Video Broadcast
FLE : FW Combiner & IP Encapsulator
FW : Forward (Link)
GPS : General Positioning System
HPS : HTTP Pre-fetching Server
HTTP : Hyper Text Transfer protocol
IP : Internet Protocol
ISP : Internet Service Provider
LNA : Low Noise Amplifier
LNB : Low Noise Block Converter
MF-TDMA : Multi Frequency-Time Division
Multiple Access
NAT : Network Address Translation
NCR : Network Clock Reference
OMT : Ortho Mode Transducer
PMS : POP Management Server
PMT : Performance Monitor Tool
QoS : Quality of Service
RCS : Return Channel by Satellite
RLP : Return Link Processor
RT : Return (Link)
SAP : Satellite Access Provider
SDR : Sit Drive
SIT : Satellite Interactive Terminal
SLR : Satellite LInk Router
SME : Small-Medium-Sized Enterprise
SOHO : Small Office Home Office
TCP : Transmission Control Protocol
VBDC : Volume Based Dynamic Capacity
VPN : Virtual Private Network
VSAT : Very Small Aperture Terminal
WCS : Web Caching Server

6
 Satellite

Return
Forward

Outdoor Outdoor Outdoor

Common SS RF SS
Unit Unit Unit

Carrier
Blade SS1
Indoor Indoor Indoor
Carrier Unit Unit Unit
Blade SS2 POP POP POP
Box Box Box

Carrier Optional Optional Optional

Blade SS8 VPN Router VPN Router VPN Router

CPE LAN CPE LAN CPE LAN

Edge
Router PC1 PCn PC1 PCn PC1 PCn

HUB SIT 1 SIT 2 SIT n

IP
Backbone

Figure 1 : 2Way-Sat Network Architecture

FW MOD Tx to RF SS
FLE
Incl.NCR Inserter
To/from
Edge SLR 1 SLR 2 ASI
Router SDR RLP
HPS ETH BDM-Bank Rx from RF SS
Incl.ATM MUX
WCS OC3

PMS PMT SEMS

CCMT ( in Common SS)

Figure 2 : Carrier Blade SS Architecture

7
 Transponder Loading- FW.CAR1 & RT.RLP1.1 (Yearly)
January February March April May June July August September October November December
14000
Average over 1 day (kbps)

12000 Forward
WEEKLY LIMIT IN SLR1 Carrier1
10000 (kbps)
8000 Return
RLP1.1
6000 (kbps)
4000 FWlimit
Weekly
2000 (kbps)
0
1 31 61 91 121 151 181 211 241 271 301 331
Day of the Year

Figure 3 : Typical example of yearly traffic growth