TR 102 768 - V1.1.1

ETSI TR 102 768 V1.1.1 (2009-04)
Technical Report
Digital Video Broadcasting (DVB);
Interaction channel for Satellite Distribution Systems;
Guidelines for the use of EN 301 790 in mobile scenarios
2
ETSI TR 102 768 V1.1.1 (2009-04)
Reference
DTR/JTC-DVB-237
Keywords
digital, DVB, satellite, TV
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2009.
All rights reserved.
TM
TM
TM
TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3
ETSI TR 102 768 V1.1.1 (2009-04)
Contents
Intellectual Property Rights ................................................................................................................................6
Foreword.............................................................................................................................................................6
Introduction ........................................................................................................................................................6
1
Scope ........................................................................................................................................................8
2
References ................................................................................................................................................8
2.1
2.2
3
Normative references ......................................................................................................................................... 8
Informative references ........................................................................................................................................ 8
Definitions, symbols and abbreviations .................................................................................................11
3.1
3.2
3.3
4
Definitions ........................................................................................................................................................ 11
Symbols ............................................................................................................................................................ 11
Abbreviations ................................................................................................................................................... 11
Reference model .....................................................................................................................................13
4.1
4.1.1
4.1.2
4.2
4.2.1
4.2.2
5
Line-Of-Sight Scenarios ................................................................................................................................... 14
Maritime ..................................................................................................................................................... 14
Aeronautical ................................................................................................................................................ 14
Non-LOS Scenarios .......................................................................................................................................... 14
Railway ....................................................................................................................................................... 14
Vehicular .................................................................................................................................................... 15
Forward link ...........................................................................................................................................16
5.1
5.1.1
5.1.1.1
5.1.1.1.1
5.1.1.1.2
5.1.1.1.3
5.2
5.2.1
5.2.1.1
5.2.1.2
5.2.1.3
5.2.1.3.1
5.2.1.3.2
5.2.1.3.3
5.2.1.4
5.2.1.5
5.3
5.3.1
5.3.2
5.3.2.1
5.3.2.2
5.3.2.3
5.3.2.4
5.3.2.4.1
5.3.2.4.2
5.3.2.5
5.3.2.5.1
5.3.2.5.2
5.3.2.5.3
5.3.3
5.4
6
6.1
Spectrum Spreading in the Forward Link......................................................................................................... 16
Spectrum Spreading in the Forward Link: code acquisition sub-system ................................................... 17
Acquisition performances in the railway scenario ................................................................................ 19
Cold start code acquisition design ................................................................................................... 20
Acquisition after a short interruption ............................................................................................... 23
Warm Start Acquisition ................................................................................................................... 24
Fast re-synchronization in mobile scenarios .................................................................................................... 25
Forward link re-synchronization issues in the Railway scenario ................................................................ 25
System assumptions for the analysis ..................................................................................................... 25
Forward link carrier stability analysis ................................................................................................... 26
Forward link timing instability analysis ................................................................................................ 26
Timing instabilities due to terminal acceleration ............................................................................. 26
Timing instabilities due to residual frequency jitter ........................................................................ 26
Conclusions on timing instabilities .................................................................................................. 26
Forward link frame acquisition analysis ............................................................................................... 26
Conclusions on Forward link re-synchronization.................................................................................. 27
Forward link countermeasures for Non-LOS mobile scenarios ....................................................................... 27
Proactive retransmission on the forward path for TCP traffic in Railway scenarios .................................. 27
Link layer FEC protection .......................................................................................................................... 28
General LL-FEC architecture ................................................................................................................ 28
Guidelines on Link Layer FEC parameters selection ............................................................................ 29
Guidelines for the selection of the LLFEC profile ................................................................................ 32
Selection of an elementary stream carrying LL-FEC ............................................................................ 34
Assignment of LL-FEC TS elementary stream to RCST ................................................................ 35
Assignment of LL-FEC stream gse_fec_id to RCST ...................................................................... 35
Use of LL-FEC on GSE generic streams .............................................................................................. 35
Application data transfer over GSE-FEC streams ........................................................................... 35
Carriage of parity data over GSE-FEC streams ............................................................................... 36
Use of the CRC_32 extension header .............................................................................................. 37
Protection of the signalling ......................................................................................................................... 38
Guidelines for the use of VCM/ACM in mobile scenarios .............................................................................. 38
Return link ..............................................................................................................................................39
Doppler drift and time correction ..................................................................................................................... 39
ETSI
4
6.1.1
6.1.1.1
6.1.1.2
6.1.2
6.1.3
6.1.3.1
6.1.3.2
6.2
6.2.1
6.2.2
6.3
6.3.1
6.3.1.1
6.3.2
6.3.3
7
7.1
7.2
8
ETSI TR 102 768 V1.1.1 (2009-04)
Carrier Frequency Doppler Shift ................................................................................................................ 40
Log-On .................................................................................................................................................. 40
Carrier Frequency Synchronisation Maintenance ................................................................................. 40
Symbol Rate Doppler Shift ......................................................................................................................... 40
Burst Timing ............................................................................................................................................... 40
Log-On .................................................................................................................................................. 40
Timing Synchronisation Maintenance................................................................................................... 42
Spectrum spreading in the return link............................................................................................................... 43
Spreading description ................................................................................................................................. 43
Despreading description ............................................................................................................................. 43
Return link countermeasures for Non-LOS mobile scenarios .......................................................................... 45
Proactive retransmission technique............................................................................................................. 45
Proactive retransmission performance in the railway scenario ............................................................. 46
Link Layer FEC protection in the return link.............................................................................................. 48
Protection of signalling in the return link ................................................................................................... 48
Synchronization procedures ...................................................................................................................48
Logon in the presence of a large timing uncertainty ........................................................................................ 48
Logoff procedure .............................................................................................................................................. 48
Control and management........................................................................................................................48
8.1
Control and monitoring functions for mobile terminals ................................................................................... 48
8.1.1
Interference Scenarios................................................................................................................................. 49
8.1.1.1
FSS Interference Environment .............................................................................................................. 49
8.1.1.2
Terrestrial and Scientific Interference Environment ............................................................................. 50
8.1.2
CMF and Interference Mitigation Techniques ............................................................................................ 50
8.1.2.1
Antenna Pointing and EIRP .................................................................................................................. 51
8.1.2.2
Exclusion Zones .................................................................................................................................... 51
8.1.2.3
Fault Detection ...................................................................................................................................... 52
8.2
Handover in Mobile Systems ........................................................................................................................... 52
8.2.1
Reference Network ..................................................................................................................................... 52
8.2.2
Beam Handover in Mobile Systems ........................................................................................................... 53
8.2.2.1
Handover Strategy................................................................................................................................. 53
8.2.2.2
Position Based Detection/Recommendation ......................................................................................... 54
8.2.2.2.1
Position Measurement ..................................................................................................................... 55
8.2.2.2.2
Geometrical Considerations ............................................................................................................ 56
8.2.2.2.3
Data Structures ................................................................................................................................ 58
8.2.2.2.4
Signalling of Handover Recommendation....................................................................................... 58
8.2.2.3
Centralized Handover Detection ........................................................................................................... 59
8.2.2.4
Example Handover Decision ................................................................................................................. 59
8.2.2.5
Handover Execution .............................................................................................................................. 60
8.2.2.5.1
Key Architectural Features / Assumptions ...................................................................................... 60
8.2.2.5.2
Overall Handover Procedure ........................................................................................................... 61
8.2.2.5.3
Forward Link Handover .................................................................................................................. 62
8.2.2.5.4
Return Link Handover ..................................................................................................................... 62
8.2.2.5.5
Beam Handover: Event Synchronisation / Handover Signalling ..................................................... 64
8.3
Gateway Handover in Mobile satellite systems................................................................................................ 73
8.3.1
Handover Detection .................................................................................................................................... 75
8.3.2
Handover Decision ..................................................................................................................................... 75
8.3.3
Handover Execution ................................................................................................................................... 75
9
9.1
9.2
9.3
9.3.1
9.3.1.1
9.3.1.2
9.3.1.3
9.3.2
9.4
9.4.1
9.4.2
Continuous Carrier Operation ................................................................................................................77
Architecture and Modes of Operation .............................................................................................................. 77
Bandwidth Management................................................................................................................................... 78
Signalling ......................................................................................................................................................... 79
Forward Link Signalling ............................................................................................................................. 79
Carrier Description ................................................................................................................................ 79
Carrier Assignment and Release ........................................................................................................... 82
Other Forward Link Signalling ............................................................................................................. 82
Return Link Signalling................................................................................................................................ 82
Physical Layer .................................................................................................................................................. 83
Synchronisation .......................................................................................................................................... 83
Encapsulation .............................................................................................................................................. 83
ETSI
5
9.4.3
9.4.4
9.4.4.1
9.4.4.2
9.4.4.3
9.4.5
9.4.5.1
9.4.5.1.1
9.4.5.1.2
9.4.5.1.3
9.4.5.1.4
9.4.6
9.4.6.1
9.4.6.1.1
9.4.6.2
9.4.6.3
10
Modulation and Coding .............................................................................................................................. 83
Adaptive Operation ..................................................................................................................................... 84
Transmit Power Control ........................................................................................................................ 84
VCM Controlled by the NCC................................................................................................................ 84
VCM with Distributed Control ............................................................................................................. 84
Spectrum Spreading .................................................................................................................................... 84
Return link continuous carrier code synchronization ............................................................................ 85
Phase noise sensitivity assessment .................................................................................................. 86
ROC performance in AWGN .......................................................................................................... 86
Mean Acquisition Time performance in AWGN ............................................................................ 87
Performance in Rice Fading Channels ............................................................................................ 89
Phase Noise impact ..................................................................................................................................... 90
Simulation conditions............................................................................................................................ 90
Phase noise generation and synchronization circuits ....................................................................... 91
Performance results ............................................................................................................................... 92
Conclusion ............................................................................................................................................ 93
System and performance requirements ..................................................................................................93
10.1
10.2
10.2.1
10.2.2
11
QoS requirements for user traffic ..................................................................................................................... 93
Analysis and recommendations for Signalling QoS ......................................................................................... 93
QoS requirement for the forward link signalling ........................................................................................ 94
QoS requirement for the return link signalling ........................................................................................... 94
Simulation results and performance .......................................................................................................95
11.1
11.1.1
11.2
11.2.1
11.2.2
Simulation scenarios......................................................................................................................................... 95
Channel model: Doppler Spectrum ............................................................................................................. 95
Performance in LOS channels .......................................................................................................................... 96
Forward link PER performance .................................................................................................................. 96
Forward link spectrum spreading performances ......................................................................................... 98
Annex A:
A.1
ETSI TR 102 768 V1.1.1 (2009-04)
Rate of Beam Roll-Off ........................................................................................................100
Basics ...................................................................................................................................................100
A.1.1
A.1.2
Rate of change ................................................................................................................................................ 100
Practical Example ........................................................................................................................................... 100
Annex B:
Continuous carrier mode vs. MF-TDMA mode comparison ..........................................102
B.1
Introduction ..........................................................................................................................................102
B.2
Hypothesis ............................................................................................................................................102
B.2.1
B.2.2
B.2.3
B.2.4
B.2.5
B.2.6
B.3
Satellite hypothesis ......................................................................................................................................... 102
Terminal hypothesis ....................................................................................................................................... 102
Regulation constraints .................................................................................................................................... 102
System Scenario definition ............................................................................................................................. 103
Return link budget hypothesis ........................................................................................................................ 103
Traffic scenarii ............................................................................................................................................... 104
Return link overall efficiency ...............................................................................................................104
B.3.1
B.3.2
B.4
MF-TDMA ..................................................................................................................................................... 104
Continuous Carrier spectral efficiency ........................................................................................................... 105
Capacity Analysis .................................................................................................................................106
B.4.1
B.4.2
B.4.2.1
B.4.2.2
B.5
Methodology .................................................................................................................................................. 106
Capacity comparison results ........................................................................................................................... 107
ETSI Context (European scenario) ........................................................................................................... 107
FCC Context (North American scenario) ................................................................................................. 108
Conclusions ..........................................................................................................................................110
History ............................................................................................................................................................111
ETSI
6
ETSI TR 102 768 V1.1.1 (2009-04)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by Joint Technical Committee (JTC) Broadcast of the European
Broadcasting Union (EBU), Comité Européen de Normalisation ELECtrotechnique (CENELEC) and the European
Telecommunications Standards Institute (ETSI).
NOTE:
The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body
by including in the Memorandum of Understanding also CENELEC, which is responsible for the
standardization of radio and television receivers. The EBU is a professional association of broadcasting
organizations whose work includes the co-ordination of its members' activities in the technical, legal,
programme-making and programme-exchange domains. The EBU has active members in about
60 countries in the European broadcasting area; its headquarters is in Geneva.
European Broadcasting Union
CH-1218 GRAND SACONNEX (Geneva)
Switzerland
Tel: +41 22 717 21 11
Fax: +41 22 717 24 81
Founded in September 1993, the DVB Project is a market-led consortium of public and private sector organizations in
the television industry. Its aim is to establish the framework for the introduction of MPEG-2 based digital television
services. Now comprising over 200 organizations from more than 25 countries around the world, DVB fosters
market-led systems, which meet the real needs, and economic circumstances, of the consumer electronics and the
broadcast industry.
Introduction
The present document gives guidelines for the implementation of Digital Video Broadcasting (DVB) interaction
channel for Satellite Distribution System (also known as DVB RCS: DVB Return Channel via Satellite) in mobile
scenarios.
DVB RCS specification [i.1] describes several mandatory and optional features for geostationary satellite interactive
system in mobile scenarios. Annex L of TR 101 790 [i.3] already defines guidelines for some mobility scenarios
characterized by Line-Of-Sight conditions with a channel that can be characterized as AWGN. This present document
draws attention to the technical questions that need to be answered in setting up a DVB RCS network that supports
mobility in Line of Sight and Non Line of Sight scenarios in different channel conditions and offers some guidance in
finding answers to them. The present document considers the DVB-S2 standard [i.2] for the forward link transmission
with the features to support mobility described in the DVB-RCS specification.
ETSI
7
ETSI TR 102 768 V1.1.1 (2009-04)
Outline of the present document
The present document provides some examples of implementation details related either with the physical layer
(e.g. spreading, frame length, link budget), the link layer (MPE-FEC) or the medium access control layer (e.g. use of
continuous carrier operation versus MF-TDMA, handover).
In order to ease the use of the present document, it shall be noted that from up to clause 8, the clause numbering is
similar to the one used in EN 301 790 [i.1]. Clause 9 maps with clause 10 in EN 301 790 [i.1] and clause 11 presents
performance results based on simulations
The present document only covers the extension to systems operating in mobile scenarios, guidelines for fixed scenarios
are found in TR 101 790 [i.3].
ETSI
8
1
ETSI TR 102 768 V1.1.1 (2009-04)
Scope
The present document should be read in conjunction with EN 301 790 [i.1] in order to assist network operators, systems
integrators, and equipment manufacturers in the realization of satellite based interactive services in mobile scenarios.
The present document should be interpreted as recommendations or good practices, but not as mandatory requirements.
It is anticipated, however, that future procurement documents may reference elements of the present document as part
of their system specification.
The present document is applicable to satellite systems as defined in EN 301 790 [i.1] that target the provision of
interactive services in mobile scenarios (maritime, aeronautical, railway and land-vehicular). In such a system, the
RCSTs receive a Forward Link signal based on the DVB-S2 (EN 302 307 [i.2]) specifications with the mobile
extensions defined in EN 301 790 [i.1].
The system as defined in EN 301 790 [i.1] may be used in all frequency bands allocated to FSS or BSS services.
2
References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
•
For a specific reference, subsequent revisions do not apply.
•
Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
-
if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
-
for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE:
2.1
While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
Not applicable.
2.2
Informative references
The following referenced documents are not essential to the use of the present document but they assist the user with
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including
any amendments) applies.
[i.1]
ETSI EN 301 790 (V1.5.1) (DVB BlueBook A054r4): "Digital Video Broadcasting (DVB);
Interaction channel for Satellite Distribution Systems".
[i.2]
ETSI EN 302 307: "Digital Video Broadcasting (DVB); Second generation framing structure,
channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering
and other broadband satellite applications".
ETSI
9
ETSI TR 102 768 V1.1.1 (2009-04)
[i.3]
ETSI TR 101 790 (V1.4.1) (DVB BlueBook A063r3): "Digital Video Broadcasting
(DVB);Interaction channel for Satellite Distribution Systems; Guidelines for the use of
EN 301 790".
[i.4]
M. Holzbock, A. Jahn, O. Gremillet, E. Lutz: "Aeronautical channel characterisation
measurements at K Band," in Proceedings 4th Ka Band Utilization Conference", Venice, Italy, pp.
263-269, Nov. 1998.
[i.5]
S. Scalise, H. Ernst, G. Harles: "Measurement and Modeling of the Land Mobile Satellite Channel
at Ku-Band", IEEE Transaction on Vehicular Technology, Vol. 57, No. 2 March 2008.
[i.6]
E. Kubista, F. Perez Fontan, M. A. Vazquez Castro, S. Buonomo, B. R. Arbesser-Rastburg,
J.P.V. Poiares Baptista: "Ka-Band Propagation Measurements and Statistics for Land Mobile
Satellite Applications", IEEE Transaction on Vehicular Technology, Vol. 49, No. 3 May 2000.
[i.7]
F. Perez Fontan, M. Vazquez Castro, C. Enjamio Cabado, J. Pita Garcia, and E. Kubista:
"Statistical modelling of the LMS channel," IEEE Transactions on Vehicular Technology, vol. 50,
pp. 1549-1567, Nov 2001.
[i.8]
S. Scalise, J. Huguet Guasch, V. Schena, and F. Ceprani: "Link Performance for a
Satellite-Based Communications System for Fast Trains: Analysis of Trials and Measurements,"
proceedings of the 6th European Mobile and Personal Satellite Workshop & 2nd Advanced
Satellite Mobile Ssystems Conference, Noordwijk, Holland, 2004.
[i.9]
Sciascia, G.; Scalise, S.; Ernst, H.; Mura, R.: "Statistical characterization of the railroad satellite
channel at Ku-band". In: Proceedings COST 272/280, International Workshop of COST
Actions 272 and 280, ESTEC, Noordwijk, The Netherlands, 26-28 May 2003.
[i.10]
G.E. Corazza, and R. Pedone: "Generalized and Average Post Detection Integration Methods for
Code Acquisition", IEEE International Symposium on Spread Spectrum Techniques and
Applications (ISSSTA04), Sydney, Australia, 30 Aug.-2 Sept. 2004.
[i.11]
G.E. Corazza: "On the MAX/TC criterion for code acquisition and its application to
DS-SSMA systems", IEEE Trans. on Comm., Vol. 44, n. 9, Sep. 1996, pp. 1173 - 1182.
[i.12]
G.E. Corazza, R. Pedone, and M. Villanti: "Frame Acquisition for Continuous and Discontinuous
Transmission in the Forward Link of Ka-band Satellite Systems", EMPS 2004 6th European
Workshop on Mobile/Personal Satcoms and ASMS 2004 2nd Advanced Satellite Mobile Systems
Conference, ESA-ESTEC, Noordwijk, The Netherlands, 21-22 Sept. 2004.
[i.13]
G. Acar and B. Evans: "Impact of Proactive Retransmissions on Forward TCP Throughput over
DVB-S/S2 Railroad Satellite Links with Power Arches", 4th Advanced Mobile Satellite Systems,
Bologna, 26-28 August, 2008.
[i.14]
ETSI TS 102 606 (V1.1.1): "Digital Video Broadcasting (DVB); Generic Stream Encapsulation
(GSE) Protocol".
[i.15]
"GSE implementation guidelines", DVB-GBS working document, gbs0520.
[i.16]
C.E. Gilchriest: "Signal to Noise Monitoring" JPL Space Programs Summary, No 37-27, Vol IV,
pp 169-176.
[i.17]
E. Matricciani: "Transformation of rain attenuation statistics from fixed to mobile satellite
communication systems", IEEE Transactions onVehicular Technology, vol.49, no.5,
pp. 565-569, August 1995.
[i.18]
K. P. Liolis, A. Bolea-Alamaniac, C. Morlet, and A. Ginesi: "Applicability of Fade Mitigation
Techniques to Mobile DVB-S2/RCS Satellite Systems: Accent on Railway Scenario",
International Workshop on Satellite ans Space Communications, IWSSC 2007.
[i.19]
ETSI EN 302 186: "Satellite Earth Stations and Systems (SES); Harmonized EN for satellite
mobile Aircraft Earth Stations (AESs) operating in the 11/12/14 GHz frequency bands covering
essential requirements under article 3.2 of the R&TTE Directive".
ETSI
10
ETSI TR 102 768 V1.1.1 (2009-04)
[i.20]
ETSI EN 301 427: "Satellite Earth Stations and Systems (SES); Harmonized EN for Low data rate
Mobile satellite Earth Stations (MESs) except aeronautical mobile satellite earth stations,
operating in the 11/12/14 GHz frequency bands covering essential requirements under article 3.2
of the R&TTE directive".
[i.21]
ETSI EN 302 340: "Satellite Earth Stations and Systems (SES); Harmonized EN for satellite Earth
Stations on board Vessels (ESVs) operating in the 11/12/14 GHz frequency bands allocated to the
Fixed Satellite Service (FSS) covering essential requirements under article 3Satellite Earth
Stations and Systems (SES); Harmonized EN for satellite Earth Stations on board Vessels (ESVs)
operating in the 11/12/14 GHz frequency bands allocated to the Fixed Satellite Service (FSS)
covering essential requirements under article 3.2 of the R&TTE directive".
[i.22]
ETSI EN 301 358: "Satellite Earth Stations and Systems (SES); Satellite User Terminals (SUT)
using satellites in geostationary orbit operating in the 19,7 GHz to 20,2 GHz
(space-to-earth) and 29,5 GHz to 30 GHz (earth-to-space) frequency bands".
[i.23]
ITU-R Recommendation M.1643: "Technical and operational requirements for aircraft earth
stations of aeronautical mobile-satellite service including those using fixed-satellite service
network transponders in the band 14-14.5 GHz (Earth-to-space)".
[i.24]
ITU-R Recommendation S.728: "Maximum permissible level of off-axis e.i.r.p density from very
small aperture terminals".
[i.25]
FCC CFR Title 47, Part 25, Section 25.209, "Antenna gain pattern envelope and section 25.134
input power density limit".
[i.26]
E. Casini, R. De Gaudenzi, A. Ginesi: "DVB-S2 modem algorithms design and performance over
typical satellite channels", Int. J. Satellite Commun. Network. 2004; 22:281-318.
[i.27]
C. Q. Xu, C. L. Law and S. Yoshida: "On the Doppler power spectrum at the mobile unit
employing a directional antenna", IEEE Communication Letters, Vol. 5, No. 1, pp. 13-15
(Jan. 2001).
[i.28]
Wee Teck Ng, V.K. Dubey: Comments on "On the Doppler spectrum at the mobile unit employing
a directional antenna" IEEE Communication Letters, Vol. 6, No. 11, pp. 472-474 (Nov. 2002).
[i.29]
ETSI TR 102 376 (V 1.1.1): "Digital Video Broadcasting (DVB) User guidelines for the second
generation system for Broadcasting, Interactive Services, News Gathering and other broadband
satellite applications (DVB-S2)".
[i.30]
G. Albertazzi, S. Cioni, G.E. Corazza, M. Neri, R. Pedone, P. Salmi, A. Vanelli-Coralli, and
M. Villanti: "On the Adaptive DVB-S2 Physical Layer: Design and Performance", IEEE Wireless
Communications, vol.12, no.6, pp. 62- 68, Dec. 2005.
[i.31]
Gardner FM.: "A BPSK/QPSK timing-error detector for sampled receivers". IEEE Transactions on
Communications 1986; 34:399-406.
[i.32]
Cioni S, Corazza GE, Bousquet M.: "An analytical characterization of maximum likelihood
signal-to-noise ratio estimation". Proceedings of the 2nd International Symposium on Wireless
Communications Systems (ISWCS), Siena, Italy, vol. 1, 5-9 September 2005; 827-830.
[i.33]
Kay SM.: "Fundamentals of Statistical Signal Processing Estimation Theory", Prentice-Hall:
Englewood Cliffs, NJ, 1992.
[i.34]
ITU-R Recommendation P.1623-1: "Prediction method of fade dynamics on Earth-space paths".
[i.35]
ITU-R Recommendation S.1428: "Reference FSS earth-station radiation patterns for use in
interference assessment involving non-GSO satellites in frequency bands between 10.7 GHz and
30 GHz".
ETSI
11
ETSI TR 102 768 V1.1.1 (2009-04)
3
Definitions, symbols and abbreviations
3.1
Definitions
For the purposes of the present document, the terms and definitions given in EN 301 790 [i.1] apply.
3.2
Symbols
For the purposes of the present document, the symbols given in EN 301 790 [i.1] and the following apply:
Δf
Es/N0
Pfa
Pmd
r
s
sqrt
3.3
Differential Frequency Offset
Energy per symbol per Noise Spectral Density
Probability of False Alarm
Probability of Missed Detection
Code rate
Seconds
Square Root
Abbreviations
For the purposes of the present document, the abbreviations given in EN 301 790 [i.1] and the following apply:
ACM
ACQ
AES
AGAC
AMSS
APP
ATM
AWGN
BSS
BTP
BW
CAC
CCM
CMF
CRA
CSC
DAMA
D-GPDI
DS
ECN
FCT
FDT
FEA
FIP
FL
FLS
FLSS
FMT
FS
FSS
GPDI
GS
GSE
HO
IBR
Adaptive Coding and Modulation
ACQuisition burst
Aeronatical Earth Station
Automatic Gain and Angle Control
Aeronautical Mobile Satellite Service
A Posteriori Probability
Asynchronous Transfer Mode
Additive White Gaussian Noise
Broadcasting Satellite Services
Burst Time Plan
Bandwidth
Connection Admission Control
Constant Coding and Modulation
Control and Monitoring Function
Constant-Rate Assignment
Common Signalling Channel
Demand Assigned Multiple Access
Diferential Generalised Post Detection Integration
Direct Sequence
Explicit Congestion Notification
Frame Composition Table
Forward error correction Data Table
Functional Entity Actions
Forward Interaction Path
Forward Link
Forward Link Signalling
Forward Link SubSystem
Fade Mitigation Technique
Fixed Service
Fixed Satellite Services
Generalised Post Detection Integration
Generic Stream
Generic Stream Encapsulation
Hand Over
In Band Request
ETSI
12
IMUX
IPSS
LDPC
LL-FEC
LOS
M&C
MAT
ML
MMT
MODCOD
MPE
MSL
MSS
MTBL
MTU
NCC
NCF
NCPDI
NLOS
NMS
NOC
OBR
OMUX
PDI
PEP
PFD
PL
PLR
PSD
QoS
RADIUS
RAS
RBDC
RCST
RLSS
ROC
SAC
SACK
SCT
SF
SLA
SOF
SR
SRS
SYNC
TBTP
TC
TCP
TCT
TIM
TS
TWTA
VBDC
VCM
VSAT
Input Multiplexer
IP SubSystem
Low Density Party Check
Link Layer Forward Error Correction
Line-of-Sight
Management and Control
Mean Acquisition Time
Maximum Likelyhood
Multicast Mapping Table
Modulation and Coding scheme
Multi Protocol Encapsulation
Minimum Scheduling Latency
Mobile Satellite System
Maximum Tolerable Burst Length
Maximum Transmission Unit
Network Control Centre
Network Control Facility
Non Coherent Post Detection Integration
Non-Line-of-Sight
Network Management Subsystem
Network Operation Center
Out of Band Request
Output Multiplexer
Post Detection Integration
Performance Enhancing Proxies
Power Flux Density
Physical Layer
Packet Loss Rate
Power Spectral Density
Quality of Service
Remote Autentification Dial-In User Service
Radio Astronomy Service
Rate-Based Dynamic Capacity
Return Channel Satellite Terminal
Return Link SubSystem
Receiver Operating Characteristics
Satellite Access Control
Selective ACKnowledgement
Superframe Composition Table
Spreading Factor
Service Level Agreement
Start Of Frame
Slope Ratio
Space Research Service
Synchronization burst
Terminal Burst Time Plan
Threshold Crossing
Transmission Control Protocol
Time-slot Composition Table
Terminal Information Message
Transport Stream
Travelling Wave Tube Amplifier
Volume-Based Dynamic Capacity
Variable Coding and Modulation
Very Small Aperture Terminal
ETSI
ETSI TR 102 768 V1.1.1 (2009-04)
13
4
ETSI TR 102 768 V1.1.1 (2009-04)
Reference model
The Reference Model for an interactive satellite network for the mobile scenario, depicted in EN 301 790 [i.1], includes
all interconnections among Network Control Centre, Traffic Gateway(s), Feeder(s) and Terminals, which are possible
from a functional viewpoint as well as all the possible mobile scenarios.
In practice, not all systems address all the mobile scenarios. This clause describes therefore the mobile scenarios that
are more likely to be implemented for the service provision and their associated architecture.
The reference mobile DVB-RCS system architecture, envisaged in EN 301 790 [i.1], is depicted in figure 1.
Figure 1: Overall system architecture for mobile interactive services via satellite
The space segment includes one or more GEO-satellites with a single or multi-beam configuration per satellite and with
performances equivalent to those used for classical Ku-band or Ka-band FSS services. Two service coverage scenarios
are identified: one for regional case (one country or part of continent covered); and one for global case (land coverage
complemented by oceanic coverage, e.g. transatlantic).
On the terminal segment, the terminal is in most cases mounted on a mobile platform operating as an access point for
multiple users. The RF characteristics (specifically, antenna minimum/maximum sizes) are adapted to the mobile
service requirements which depend on the applications but also on the regulatory and accommodations constraints.
Traffic aggregation at the RCST has to be considered due to the high number of users that can be attached to the same
RCST in a mobile platform. Therefore, both the MF-TDMA mode and the continuous carrier operation described in
[i.1] will need to be considered.
The telecommunications ground segment consists of the Network Operator Centre (NOC), the Network Control Centre
(NCC) compatible with the definition of the DVB-RCS NCC and the gateways, providing access to the terrestrial
networks. The NOC is in charge of sharing the satellite resources among network operators, allocating bandwidth to
NCCs and centralized management of satellite handover if relevant. The RCST is managed by a single NCC within the
satellite coverage area.
The different mobile scenarios that are envisaged in a mobile DVB-RCS system can be classified as follows:
•
LOS (Line-Of-Sight) scenarios: these correspond to low-fading scenarios, which are almost always in LOS or
close to LOS conditions. Aeronautical and maritime are the two main scenarios in this category.
ETSI
14
•
ETSI TR 102 768 V1.1.1 (2009-04)
Non-LOS (Non-Line-Of-Sight) scenarios: these correspond to land-based where the LOS is frequently affected
by frequent/deep/long signal blockages and shadowing. Railway and land- vehicular are the two main
scenarios in this category.
4.1
Line-Of-Sight Scenarios
4.1.1
Maritime
The maritime scenario comprises mainly: passenger transportation ships (e.g. ferries and cruises), commercial ships
(e.g. cargos and tankers), and private transportation ships (e.g. sailing boats).
Two coverage scenarios are particularly considered: a global one, corresponding to cruise routes (e.g. transatlantic
cruises), and a regional one, corresponding to ferry routes (e.g. European coastal regions).
Regarding the modelling of the LOS channel conditions encountered in the maritime scenario, considering the usage of
high directive antennas, presence of a strong LOS can be assumed, and the channel can be modelled as a pure Ricean
channel with a very high Rice factor; i.e. very close to a AWGN channel.
4.1.2
Aeronautical
The aeronautical scenario comprises mainly: passenger aircrafts (including wide-body and single aisle aircrafts); and
private aircrafts (e.g. executive jets).
Two coverage scenarios are particularly considered: a global one, corresponding to long-haul flights (e.g. transatlantic
flights), and a regional one, corresponding to short and medium haul flights (e.g. over Europe).
Regarding the modelling of the LOS channel conditions encountered in the aeronautical scenario, experimental results
at 18,6 GHz [i.4] show that the channel behaves like Ricean during normal flight situations and manoeuvres, with a
Rice factor well above 20 dB. Light fades in the order of 3 dB were observed for manoeuvres with roll angles up to 20°,
whereas only in case of extreme manoeuvres, with roll angles up to 45°, the influence of the aircraft structure resulted in
deep fades in the order of 15 dB. In conclusion, in aeronautical scenarios, LOS conditions can be assumed and the
channel can be fairly approximated by a AWGN channel for most of the time.
4.2
Non-LOS Scenarios
4.2.1
Railway
The railway scenario considered in the following comprises mainly high-speed long-distance trains.
Only the regional coverage scenario is considered since trains remain within one continent.
The mobility effects, such as multipath, shadowing and blockage, encountered due to the local environment in the
vicinity of the mobile RCST, such as adjacent buildings, vegetation, bridges, and tunnels, result in sporadic severe
fading.
Regarding the modelling of the railway channel conditions, different propagation measurements at Ku [i.6] and Ka
bands [i.6] and [i.7] were performed in the last decade, based on which, reference statistical channel models exist:
•
For Ku-band, the behaviour of the land mobile satellite channel can be modelled using a 3-state (namely LOS,
shadowed and blocked states) Markov chain model, where each state is further characterized by a Rice
distribution. The transition matrix coefficients and the distribution parameters can be found in [i.6].
•
For Ka-band, the behaviour of the land mobile satellite channel can be modelled using a 3-state (namely LOS,
shadowed and blocked states) Markov chain model, where each state is further characterized by a Loo
distribution. The corresponding parameters can be found in [i.6] and [i.7].
ETSI
15
ETSI TR 102 768 V1.1.1 (2009-04)
For the specific case of the railway environment, dedicated measurements were performed at Ku-Band in spring 2004
along the Italian railway in the framework of the EC co-funded project FIFTH [i.8]. As illustrated in figure 2, the
presence of several metallic obstacles along the railroad such as electrical trellises (power arch) and catenaries,
i.e. electrical cables, must be taken into account in addition to the presence of other obstacles such as isolated buildings,
tunnels or trees that may appear along railway lines. Following is a list of signal attenuations associated with different
obstacles:
•
Catenaries: typically attenuation of 2 dB to 3 dB.
•
Electrical trellises: up to 15 dB to 20 dB attenuation (depending on the geometry and layout of the obstacles
and on the orientation of the railway with respect to the position of the satellite): length ~0,5 m, distance
between two consecutive trellises ~43 m.
•
Bridges: high signal loss for a length between a few meters up to tens of meters -50 m.
•
Tunnels: long-term interruptions.
The railway channel can be modelled by superimposing this kind of deterministic and (space) periodic fades on a
statistical model accounting for unpredictable obstacles (such as the three-states Markov model with parameters similar
to the land mobile highway channel) [i.9].
In conclusion, the railroad satellite channel is in LOS state most of the time. However, short blockages due to power
arches as well as long blockages due to obstacles, such as buildings, vegetation, bridges, and tunnels, are also present
leading to non-LOS effects.
Figure 2: Examples of measured attenuation in dB caused by electrical trellises (left),
electrical posts with brackets (mid) and catenaries (right) at Ku-band [i.8]
The interruption caused by short bridges can last from 0,6 s (at 300 km/h) to 9 s for (20 km/h). For the purposes of the
analyses presented in the present document, short blockages are considered up to 1 s of duration and the assumptions
regarding trellis-induced fades are summarized in table 1.
Table 1: Period Time and Obstacle Time for the Railway scenario
Speed
Period Time (s)
Obstacle Time (s)
4.2.2
20 km/h
7,74
0,09
80 km/h
1,935
0,0225
120 km/h
1,29
0,015
160 km/h
0,9675
0,01125
240 km/h
0,645
0,0075
Vehicular
The land-vehicular scenario comprises mainly: passenger vehicles (e.g. buses); commercial vehicles (e.g. trucks); and
private vehicles (e.g. cars).
Only the regional coverage scenario is considered since land-vehicles remain within one continent.
Regarding the modelling of the non-LOS channel conditions encountered in the land vehicular scenario, the same
statistical channel models described above for the railway scenario apply here as well. However, the effect of
deterministic and (space) periodic fades due to power arches are not relevant here anymore, and hence, they shall not be
taken into account.
ETSI
16
5
ETSI TR 102 768 V1.1.1 (2009-04)
Forward link
In case of mobile scenarios, the forward link signal received by the RCST can be adapted to the mobile conditions with
the provisions adopted in [i.1].
The block diagram in figure 3 depicts the main functionalities of a DVB-S2 forward link, including the optional mobile
features. Although figure 3 depicts the case for MPEG transport stream, GSE is also supported by both DVB-S2 [i.2]
and the mobile features introduced in [i.1].
Figure 3: DVB-S2 high level block diagram (MPEG-TS case)
5.1
Spectrum Spreading in the Forward Link
A DVB-S2 forward link transmission can be spread in bandwidth using the provisions adopted in [i.1]. Figure 4 is
representative of a possible implementation of the spreading functionality that can be added to a DVB-S2 compliant
modulator and demodulator. This is considered representative of practical implementations (alternative schemes are
possible provided the signal transmitted is equivalent).
ETSI
17
ETSI TR 102 768 V1.1.1 (2009-04)
Figure 4: Block diagram of the demodulator with the spreading functionality
The block diagram in the figure 4 represents the typical modulator according to the DVB-S2 specification [i.2] with the
addition of the spreading functionality. The signal outgoing from the first pulse shaping is the classical DVB-S2 signal
and it is the input of the spreading chain. The first two blocks in the transmitter spreading chain, which are a Matched
Filter and a Sample Decimator, aim at producing the same symbol sequence generated by the DVB-S2 constellation
mapper. Symbols are then multiplied by the spreading sequence and scrambled, by using the same scrambling sequence
defined for physical layer scrambling in DVB-S2 [i.2]. The Scrambler Block is needed because it allows obtaining an
averaging effect on the spectral signal properties. Indeed, although the Spreading Factor is at most 4, the use of
scrambling makes the whole spreading effect similar to that obtained using a long spreading sequence. After
scrambling, chips are oversampled and filtered to produce a signal according to the DVB-S2 specification [i.2]. At the
receiver side, dual operations must be performed, and the despreading chain must be implemented. In this way, the
signal coming out from the receiver spreading chain can be processed by a classical DVB-S2 receiver. The adoption of
the Direct Sequence (DS) spreading technique imposes a code acquisition in order to perform efficient despreading. In
the following, the design and performance analysis of the acquisition subsystems are reported for both forward and
return links.
5.1.1
Spectrum Spreading in the Forward Link: code acquisition
sub-system
The adoption of the Direct Sequence (DS) spreading technique imposes a code acquisition in order to perform efficient
despreading. Because the receiver typically operates under different conditions, the high-level algorithm that drives the
code acquisition sub-system can be represented by the finite state machine shown in figure 5. In particular, the
following operation modes can be identified:
1)
S1 - Cold start acquisition: which is verified at terminal switch-on.
2)
S2 - Verification mode: which verifies the correctness of the frame acquisition decision.
3)
S3 - Frame tracking: which is in charge of continuous verification and detection of deep fade events.
ETSI
18
ETSI TR 102 768 V1.1.1 (2009-04)
4)
S4 - Re-acquisition after short interruptions: which is the procedure put in place to recover the code
alignment after a deep fade.
5)
S5 - Warm start acquisition: which takes place after long fading events.
Figure 5: Code acquisition finite state machine
The transitions between the different states are the following:
•
T(1-2) occurs when the cold start frame synchronization procedure is terminated with the indication of a
certain frame alignment, and the control is transferred to the verification mode that has to verify the
correctness of that outcome.
•
T(2-1) occurs when S2 reveals the incorrectness of the cold start frame acquisition decision, classifying the
outcome of S1 as a false alarm event.
•
T(2-3) occurs when S2 has completed the verification phase, having verified the correctness of the outcome of
S1.
•
T(3-3) is the loop transition of S3, which characterizes the normal operating state of the frame synchronization
subsystem.
•
T(3-4) occurs when the lock to the frame alignment is lost, e.g. as a result of a fade event.
•
T(4-2) occurs when S4 has managed to recover the frame alignment, and thus verification can restart.
•
T(4-5) occurs when S4 cannot recover the frame alignment with a limited delay, and thus the last
synchronization lock is no more reliable. In this case, warm start synchronization has to be initiated.
•
T(5-2) occurs when the warm start frame synchronization procedure is terminated with a certain frame
alignment indication to be verified by the verification state.
•
T(5-1) occurs when the warm start acquisition fails to recover the frame alignment within a tolerable time
delay, and thus cold start synchronization must be re-initiated.
For any state, the code acquisition subsystem is composed by a code sequence detector, a decision criterion, and a
controller that implements the control logic necessary to perform the acquisition procedure. Because of the large
uncertainty region, a Threshold Crossing (TC) criterion is selected, which compares the decision variable with a
threshold and declares the testing hypothesis to be synchronous when the threshold is crossed.
According to a conventional pilot-aided approach, code alignment is achieved by detecting in the transmission flow the
presence of the known preamble formed by the Start of Frame (SOF) spread with the spreading code and scrambled by
the scrambling sequence. The total preamble length is thus Lpreamble = LSOF SF, where LSOF = 26 according to the
DVB-S2 [i.2], and SF is the spreading factor.
ETSI
19
5.1.1.1
ETSI TR 102 768 V1.1.1 (2009-04)
Acquisition performances in the railway scenario
This clause presents solutions to enhance the code acquisition sub-system and shows the performance of these
techniques in an environment representative of the railway scenario. For the performance assessment, the following
assumptions are considered:
•
Modulations: QPSK 1/4 and QPSK 1/2.
•
FECFRAME size 64 K.
•
Chip rate: 28 Mcps.
•
Symbol rate: 7 Msps (SF = 4) and 14 Msps (SF = 2).
•
Channel: AWGN.
•
Linearized TWTA as in [i.29].
•
OMUX as in [i.29].
•
Phase noise mask representative of a professional equipment as in table 2.
Table 2: Phase noise mask for professional equipment
100 Hz
1 000 Hz
10 000 Hz
100 000 Hz
1e+006 Hz
> 1e+007 Hz
-45 dBc/Hz
-65 dBc/Hz
-80 dBc/Hz
-95dBc/Hz
-105 dBc/Hz
-115 dBc/Hz
For the cold start acquisition:
•
Carrier frequency error: 3 MHz.
•
Timing frequency error: 100 ppm.
•
Doppler rate = 1 300 Hz/s (representative of a Ka-band aeronautical scenario, i.e. worst case Doppler rate).
For the warm acquisition:
•
Carrier freq. error: 100 KHz.
•
Timing freq. error: 100 ppm.
•
Doppler rate = 1 300 Hz/s (Ka-band aeronautical).
For the acquisition after a short interruption (up to 1 sec) in the railway scenario:
•
Doppler rate = 200 Hz/s.
•
Carrier freq. error normalized to the symbol rate = 2 × 10 ^ (-4), (the first stage coarse carrier recovery loop
which is assumed almost frozen during steady state).
•
Timing freq. error: 1 ppm, (three times the standard deviation of a 2nd order Gardner loop with
BW = 10 ^ (-4) × Rs and critical damping).
•
Random timing phase (lost timing lock).
•
It is consider that, after a short interruption, the RCST needs to recover: timing, carrier frequency and phase.
ETSI
20
5.1.1.1.1
ETSI TR 102 768 V1.1.1 (2009-04)
Cold start code acquisition design
Code acquisition in the cold start state is the most critical procedure due to the maximum observed frequency offset.
Also, cold start acquisition is characterized by the maximum uncertainty region for the code epoch domain, which is
equal to SFLF h, where LF is the frame length, and h is the number of hypotheses per chip. Due to the low SNR before
despreading, chip timing recovery is not feasible with satisfactory performance before code acquisition, thus at least
h = 2 hypotheses per chip are tested in the synchronization subsystem.
In order to enhance the subsystem robustness against frequency offsets, two detectors based on Post Detection
Integration (PDI) can be adopted; namely, Generalized PDI (GPDI) and Differential GPDI (D-GPDI) [i.10]. In general,
PDI techniques foresee coherent integration over a code subsequence of length M, to increase SNR before applying
non-linear processing. In fact, the presence of a normalized frequency offset ν = ΔfTc (here equal to 3 MHz/27,5
Mcps = 0,11) determines an energy degradation equal to sinc2(M ν) after coherent accumulation over M chips, which
can be contained by appropriately selecting M, given the frequency offset. Thus, for all PDI-based detectors, correlation
over the code sequence is split in two parts: coherent accumulation over M chips followed by PDI over the residual
length L= Lpreamble/M. In particular, GPDI derives from the application of the generalized likelihood ratio test and, as
illustrated in figure 6, it results in the combination of Non Coherent PDI (NCPDI) and several differential terms,
identified as n-Span DPDI, which take the phase reference over the nth predecessor. The block diagrams of NCPDI, nSpan DPDI, GPDI, and D-GPDI are reported in figure 6. D-GPDI is a structured extension of GPDI able to enhance the
robustness against particularly penalizing frequency errors that force the selection of M = 1.
Received
signal
ΣM
MF
ΣL-n
nT
Sequence
Generator
·
ǀ ǀ
Decision
variable
( · )*
DPDI (n=1)
n-Span DPDI (n>1)
Received
signal
ΣM
MF
·2
ǀ ǀ
ΣL
Decision
variable
Sequence
Generator
NCPDI
NCPDI
DPDI
Received
signal
DPDI
·2
2-Span DPDI
·2
…
n-Span DPDI
2-Span DPDI
Σ
Decision
variable
·2
Received
signal
…
n-Span DPDI
Σ
Decision
variable
…
…
(L-1)-Span DPDI
(L-1)-Span DPDI
·2
D-GPDI
GPDI
Figure 6: Cold start code acquisition detectors block diagrams
A single dwell code acquisition procedure with serial search is considered to cope with the variable frame length
foreseen by the DVB-S2 standard [i.2], which can be modelled as a Markov chain as depicted in figure 7.
ETSI
21
ETSI TR 102 768 V1.1.1 (2009-04)
The overall false alarm state (FA) is modelled as non-absorbing, the recovery from which requires a penalty time Tp
that has been assumed to be constant. Uniform a priori probabilities πI = 1/(LF h) are considered. In order to limit the
delay of the acquisition procedure, passive implementation of the detectors is selected, at the cost of increased
complexity. This choice allows to reduce the testing time to half of the chip period if h = 2 cells per symbol are
exploited by the receiver. The large frequency error typical of cold start operation (3 MHz) suggests using D-GPDI with
M = 1 or GPDI with M = 2.
Finally, figure 7 also shows the flow chart corresponding to the control logic implementing the single-dwell TC
procedure described in the flow graph (figure 5). The Cells Selector serially selects the cells to be tested in order to
explore the entire uncertainty region. The procedure stops as soon as the spread SOF is detected.
Solving the flow-graph, the analytical expression for the mean and variance of the acquisition time can be obtained as a
function of the single cell missed detection and false alarm probabilities, according to the following expressions:
PD ⎞ ⎞
PD ⎞⎤
1 ⎡ ⎛
⎛
⎛
⎟⎥
⎟ ⎟⎟ + Tp Pfa ( N c − 2)⎜1 −
⎢Td ⎜⎜1 + ( N c − 2)⎜1 −
PD ⎣ ⎝
2 ⎠⎠
2 ⎠⎦
⎝
⎝
TA =
Var{TA } =
1
12PD2
{ [− 12( P
D
[
(1)
− 1) + N c ( N c − 2)(12 + PD ( PD − 12))] Td2 +
]
+ 2 − 12 + 2( N c − 2)( PD − 3) + ( N c − 2) 2 (12 + PD ( PD − 12)) PfaTd Tp +
[
+ PfaTp 12(−1 + ( N c − 2)( N c − 4)) PfaTp + ( N c − 2) P (−6 + ( N c − 6) Pfa ) Tp +
+ 12 PD (1 + ( N c − 2)(1 − ( N c − 2) Pfa )Tp )
2
D
]}
(2)
where PD = Pd (2 - Pd) is the correct detection probability of the collective synchronous state, Pd is the single test
correct detection probability, Pfa is the single test false alarm probability, Nc = h LF SF is the number of cells in the
uncertainty region, Td = Tc /h = Tc /2 is the dwell time, i.e. the time needed to perform a single test, h = 2 is the number
of hypotheses per symbol used by the receiver.
In order to minimize the acquisition time, the optimization of the decision threshold plays a fundamental role. In
particular, because the detection problem is strongly unbalanced (2 H1 hypotheses against Nc - 2 H0 cells) and the
detector has to test a very large number of H0 cells, Pfa has to be reduced in order to avoid an excessive number of
erroneous synchronizations. This optimization is performed by searching for the decision threshold that minimizes the
mean acquisition time. However, it is not possible to analytically express the mean acquisition time dependence on the
decision threshold, because the analytical characterization of GPDI and D-GPDI single cell performance is not
available. Thus, a semi-analytical approach is adopted that uses the analytical expression of the mean acquisition time
along with the simulated single cell performance Pfa and Pmd = 1 - Pd.
πNc-1
start
(1 − Pfa ) z Td
Cell
selection
No
πNc-3
(1 − Pfa ) z Td
H0
PD
(1 − Pfa ) z Td
H1
H0
Pfa
Pfa
z
Tp
π1
Pfa
Figure 7: Cold start acquisition procedure
ETSI
π2
(1 − Pfa ) z Td
···
FA
(1 − PD ) z Td
H0
Pfa
···
Verification mode
(1 − Pfa ) z Td
H0
Code
detection?
Yes
A
πNc-2
22
ETSI TR 102 768 V1.1.1 (2009-04)
Figure 8 shows the performance in terms of mean acquisition time for GPDI with M = 2 and D-GPDI with M = 1,
considering SF = 2 and SF = 4, with Ec/N0 = -8,35 dB and -5,35 dB respectively (corresponding to the DVB-S2 worst
case of Es/N0 = -2,35 dB). Non ideal chip timing recovery is assumed by accounting for a fixed worst case fractional
chip misalignment δTc = 0,25Tc with two hypotheses per symbol processed by the receiver (h = 2). The penalty time is
conservatively assumed equal to 2TF.
0.80
D-GPDI, SF = 4, EcN0 = -8.35, Delta = 0.25
0.70
GPDI, SF = 4, EcN0 = -8.35, Delta = 0.25
D-GPDI, SF = 2, EcN0 = -5.35, Delta = 0.25
0.60
GPDI, SF = 2, EcN0 = -5.35, Delta = 0.25
MAT[s]
0.50
0.40
0.30
0.20
0.10
0.00
1E-07
1E-06
1E-05
1E-04
Pfa
Figure 8: Mean acquisition time performance
Notably, with the large uncertainty region of the scenario analysed here (Nc = 133,128 for SF = 2 and
Nc = 266 256 for SF = 4) the optimal mean acquisition time occurs with a very low false alarm probability Pfa, in the
order of 10^(-6), and for D-GPDI it is equal to 0,067 s. with SF = 2 and 0,111 s. with SF = 4, while with GPDI it equals
0,090 s. with SF = 2 and 0,144 s. with SF = 4. The thresholds corresponding to these values are selected as operational
points.
To provide more conservative performance figures, the 99 % acquisition time percentile is also investigated. To this
aim, the probability density function (pdf) of the acquisition time is modelled using the one-sided central limit theorem
which yields a Gamma pdf [i.11]:
pTA (TA ) =
a −1
TA e −TA / b
b a Γ (a )
TA ≥ 0
(3)
where:
2
a=
TA
Var{TA }
b=
Var{TA }
TA
(4)
and Γ(x) is the Gamma function.
The computation of the Gamma pdf in correspondence of the optimal operational point discussed above yields the
cumulative distribution functions (cdf) shown in figure 9, where also the 99 % specification is highlighted.
ETSI
ETSI TR 102 768 V1.1.1 (2009-04)
1
1
0.99
0.99
0.98
0.98
Cumulative Distribution Function
Cumulative Distribution Function
23
0.97
D-GPDI SF =2
0.96
0.95
GPDI SF=2
0.94
0.93
0.92
0.91
0.97
D-GPDI SF =4
0.96
0.95
GPDI SF=4
0.94
0.93
0.92
0.91
0.9
0.15
0.9
0.2
0.25
0.3
0.35
0.4
0.45
0.5
0.2
0.25
0.3
0.35
Acquisition time [s]
0.4
0.45
0.5
0.55
0.6
0.65
0.7
Acquisition time [s]
Figure 9: Acquisition time cdf for D-GPDI and GPDI with SF = 2 and SF = 4
The abscissa points satisfying the 99 % constraint are finally summarized in table 3. GPDI allows to achieve a 99 %
acquisition time equals to 0,419 s. with SF = 2 and 0,669 s. with SF = 4. A further improvement is reached by D-GPDI,
which allows for 0,314 s. with SF = 2, and 0,518 s. with SF = 4.
Table 3: Acquisition time performance
SF
2
2
4
4
5.1.1.1.2
Detector
Pfa
Pmd
Mean Acq Time (s)
D-GPDI
3,30E-06
3,80E-06
1,00E-06
6,00E-07
0,96658
0,97317
0,96707
0,97803
0,067
GPDI
D-GPDI
GPDI
0,090
0,111
0,144
Var Acq Time
0,005
0,008
0,013
0,021
99 % Acq Time (s)
0,314
0,419
0,518
0,669
Acquisition after a short interruption
Acquisition after a short interruption is represented by the S4 state in figure 6. The maximum fade event duration is
assumed equal to 1 s (railway scenario), i.e. 500 frames with SF = 2 or 250 with SF = 4. After this period, considering
that all tracking circuits have been frozen in their last steady state operation, the frequency error is equal to 5 700 Hz
(clock instability, 5 500 Hz, plus Doppler rate, 200 Hz), i.e. 0,0002 normalized to the chip rate. In addition, the clock
drift introduces a time uncertainty equal to ± 28 chips. Accordingly, the code epoch domain is equal to:
•
56 chips for constant QPSK modulation.
•
The entire longest frame length for variable modulation, i.e. 33 282 × SF chips.
No chip timing recovery is feasible before despreading, thus a fractional displacement δ = 0,25 is assumed along with
h = 2.
A typical performance requirement for the acquisition time is 10 % of the fade duration at 99 % percentile,
i.e. 0,1 s.
In line with cold start acquisition, GPDI and D-GPDI are considered with the same (M, L), although this approach leads
to sub-optimum performance. Optimized performance is provided by M = LSOF x SF and L = 1, i.e. full coherent
correlation followed by energy detection (NCPDI).
With variable modulation, the single dwell TC procedure of [i.12] is adopted. The penalty time is assumed equal to one
frame, assuming that verification is done by exploiting the pilot fields, i.e.:
•
Tp = 8PSK frame duration (22 194·SF) with variable modulation.
•
Tp = QPSK frame duration (33 282·SF) with constant QPSK modulation.
ETSI
24
ETSI TR 102 768 V1.1.1 (2009-04)
Considering all possible impairments (non linear distortion, IMUX-OMUX linear distortion, phase noise, frequency
error, clock time drift) and pre-distortion, the mean acquisition time and variance are reported in table 4 along with the
99 % percentile acquisition time. Notably, all solutions provide in-spec performance, except for D-GPDI with SF = 4,
because of the reduced frequency error.
Table 4: Acquisition performance after deep fade events, variable modulation
SF
2
2
2
4
4
4
Detector
D-GPDI
GPDI
NCPDI
D-GPDI
GPDI
NCPDI
Pfa
2,60E-06
1,50E-06
1,04E-05
1,20E-06
3,40E-06
1,00E-06
Pmd
0,93
0,91
0,49
0,91
0,85
0,57
Mean Acq Time (s)
0,01993
0,01540
0,00382
0,03147
0,02466
0,00555
Var Acq Time
0,00040
0,00024
0,00001
0,00228
0,00063
0,00003
99 % Acq Time (s)
0,0930
0,0705
0,0180
0,2250
0,1155
0,0240
With constant QPSK modulation, performance can be further improved by exploiting a single dwell TC procedure with
a limited uncertainty region centered around the last frame lock, making the scenario less critical. The achievable mean
acquisition time is shown in table 5.
Table 5: Acquisition performance after deep fade events, constant QPSK modulation
SF
2
2
2
4
4
4
5.1.1.1.3
Detector
D-GPDI
GPDI
NCPDI
D-GPDI
GPDI
NCPDI
Pfa
2,60E-06
0,001674
0,000352
0,000768
0,001693
0,000332
Pmd
0,92785
0,49016
0,17402
0,67625
0,48872
0,13015
Mean Acq Time (s)
0,00190
0,00113
0,00013
0,00463
0,00225
0,00018
Warm Start Acquisition
Warm start acquisition takes place after long fading events or time slicing. The frequency offset is in this case increased
with respect to S4, albeit still strongly reduced with respect to cold start operation. In particular, a 100 kHz carrier
frequency error is considered, i.e. 0,0036 normalized to the chip rate. In addition, the typical 100 ppm clock drift
introduces a time uncertainty equal to ±2 750 chips. Accordingly, the code epoch domain is equal to:
•
5 500 chips for constant QPSK modulation;
•
the entire longest frame length for variable modulation, i.e. 33 282·SF chips.
Again, no chip timing recovery is feasible before despreading, thus a fractional displacement δ = 0,25 is assumed along
with h = 2.
In line with cold start acquisition, GPDI and D-GPDI are considered with the same (M, L), although this approach leads
to sub-optimum performance. Similarly to re-acquisition after short interruptions, optimized performance is provided by
M = LSOF · SF and L = 1, i.e. full coherent correlation followed by energy detection (NCPDI).
The single dwell TC procedure of [i.12] is considered with variable modulation, with a penalty time equal to one frame,
assuming that verification is done by exploiting the pilot fields, i.e.
•
Tp = 8PSK frame duration (22 194·SF) with variable modulation.
•
Tp = QPSK frame duration (33 282·SF) with constant QPSK modulation.
Considering all possible impairments (non linear distortion, IMUX-OMUX linear distortion, phase noise, frequency
error, clock time drift) and pre-distortion, the mean acquisition time and variance are reported in table 6 along with the
99 % percentile acquisition time.
ETSI
25
ETSI TR 102 768 V1.1.1 (2009-04)
Table 6: Acquisition performance for warm start operation, variable modulation
SF
2
2
2
4
4
4
Detector
D-GPDI
GPDI
NCPDI
D-GPDI
GPDI
NCPDI
Pfa
8,60E-06
3,10E-06
6,60E-06
2,10E-06
3,20E-06
2,40E-06
Pmd
0,90
0,89
0,66
0,91
0,85
0,86
Mean Acq Time (s)
0,02004
0,01369
0,00486
0,03522
0,02379
0,02365
Var Acq Time
0,00041
0,00019
0,00002
0,00126
0,00058
0,00057
99 % Acq Time (s)
0,0945
0,0630
0,0225
0,1635
0,1110
0,1095
Similarly to S4, with constant QPSK modulation, performance can be further improved by exploiting a single dwell TC
procedure with a limited uncertainty region centered around the last frame lock. The achievable mean acquisition time
is shown in table 7.
Table 7: Acquisition performance for warm start operation, constant QPSK modulation
SF
2
2
2
4
4
4
5.2
Detector
D-GPDI
GPDI
NCPDI
D-GPDI
GPDI
NCPDI
Pfa
2,36E-05
3,40E-05
3,09E-05
1,32E-05
4,38E-05
4,54E-05
Pmd
0,86
0,79
0,52
0,86
0,74
0,70
Mean Acq Time (s)
0,009
0,006
0,002
0,016
0,010
0,008
Fast re-synchronization in mobile scenarios
Some mobile channels are characterized by the presence of obstacles that can cause link outage (see clause 4.2). In
these circumstances, it is important to analyse the re-synchronization performances of the RCST. In the following, the
focus is on the railway scenario.
5.2.1
Forward link re-synchronization issues in the Railway scenario
As seen in clause 4.2.1, the railway channel is characterized by periodic fading. This clause analyses the
synchronization sub-system behaviour in the presence of this frequent fading.
5.2.1.1
System assumptions for the analysis
The following analysis considers only one antenna in order to minimize terminal cost and installation. The DVB-S2
forward link symbol rate ranges from 5 Msps to 25 Msps. It is assumed that pilot symbols are used. This analysis
considers that no spreading is required neither on the forward nor in the return links.
It is considered that the terminal receiver is equipped with a signal loss detector which is able to estimate the loss of the
signal within a short period of time (typically one frame if pilots are used). Additionally, a second order timing recovery
loop in considered in the receiver terminal.
ETSI
26
5.2.1.2
ETSI TR 102 768 V1.1.1 (2009-04)
Forward link carrier stability analysis
As long as the normalized frequency error (with respect to the symbol rate) accumulated during a signal loss is below
~3,5 × 10-4 (1 750 Hz at Rs = 5 Msps-8 750 Hz at Rs = 25 Msps) no carrier frequency re-training is needed. With a
Doppler rate of 100 Hz/s, an accumulated frequency error of 1 750 Hz is reached after 7,5 s, while 8 750 Hz is reached
after 87,5 s. Phase tracking is always performed on a frame-by-frame basis which implies a fast acquisition. Under these
conditions, it is considered that carrier re-training is not needed after interruptions due to trellises and bridges. Carrier
stability could be considered as a problem only in the case of 5 Msps carriers at low speeds (i.e. below 30 km/h).
5.2.1.3
5.2.1.3.1
Forward link timing instability analysis
Timing instabilities due to terminal acceleration
Assuming a worst- case acceleration of 2,5 m/s2, the timing error accumulation during a signal outage would amount to
0,8 × π × 10-8 × Rs × Tout2 radians where Tout is the outage duration.
Timing errors within 0,05/Rs are acceptable to limit the performance degradation. Taking into account these conditions,
the maximum outage time Tout can be calculated as follows:
Tout < sqrt(1,25 × 107/Rs).
That is 1,58 seconds at Rs = 5 Msps and 0,7 s at Rs = 25 Msps.
5.2.1.3.2
Timing instabilities due to residual frequency jitter
Even using a second-order timing recovery loop, the estimated clock frequency before signal interruption may be offset
with respect to the true frequency by several Hz. This frequency error would make the timing error to accumulate very
fast during the signal interruption even if no Doppler rate is present.
With a normalized bandwidth of 10 ^ (-4) × Rs and a critical damping ξ = 0,707, the jitter of the frequency state
variable of the loop is in the order of 3 × 10 ^ (-7)xRs Hz at an input SNR of the clock wave of 0 dB. Considering a
max error of 3 times the standard deviation, the error of 0,05/Rs is reached after 11 ms at Rs = 5 Msps and 2,2 ms at
Rs = 25 Msps.
A better choice of the damping factor (ξ = 10) would allow for a reduction of the steady state timing frequency error by
about a factor of 100 and still be able to track the timing frequency ramps typical of this scenario. Signal losses of
duration up to 1 s and 200 ms (for 5 Msps and 25 Msps, respectively) could be handled without re-synchronization.
5.2.1.3.3
Conclusions on timing instabilities
Considering the two effects (terminal acceleration and residual frequency jitter) it turns out that timing re-training is not
needed for interruptions of duration less than 1 second for Rs = 5 Msps and 200 ms for Rs = 25 Msps. Therefore
retraining of the receiver clock is not needed to cope with trellises interruptions.
Clock retraining is needed after interruptions due to bridges at all speeds for Rs = 25 Msps and for speeds lower than
about 200 Km/h at Rs = 5 Msps. Re-training of the clock takes up to 5 × 104 symbols, i.e. 100 ms at 5 Msps and 2 ms at
Rs = 25 Msps.
5.2.1.4
Forward link frame acquisition analysis
In CCM mode, if correct timing is not lost, there is no need to recover the right frame alignment. The receiver only
needs to correctly count the symbol periods during a signal outage. This guarantees that after the signal comes back up
the right frame alignment is maintained.
ETSI
27
ETSI TR 102 768 V1.1.1 (2009-04)
In ACM mode, regardless of whether the receiver clock has to be retrained or not, the right frame alignment has to be
re-acquired, because in ACM mode the frame alignment relies on the successful decoding of the PL header. In case only
one of these is lost, correct re-alignment is needed. Two situations can be considered in this case:
•
If timing is maintained, frame resynchronization can carried out within one frame. This may be done by
modifying the frame acquisition process in case a short interruption is detected. In such a case, taking into
account the smaller frequency error with respect to cold acquisition, coherent correlation could be used on the
SOF plus a number of pilot fields.
•
If timing is not maintained, clock retraining has to be performed first, followed by the procedure listed in the
preceding bullet point.
5.2.1.5
Conclusions on Forward link re-synchronization
With a proper demodulator design, interruptions due to trellises do not imply any need for the demodulator
re-acquisition. Interruptions due to bridges may require timing and/or frame re-acquisition for a maximum duration of
about 100 ms to 120 ms at 5 Msps, 5 ms to 8 ms at 25 Msps.
The use of the optional pilot symbols specified in [i.2] will increase system performance and is highly recommended in
the mobility scenario to help the channel state estimation, carrier recovery and frame acquisition in ACM mode.
The terminal demodulator should be designed to achieve a fast signal level detector to establish when to freeze and
re-activate the demodulator.
5.3
Forward link countermeasures for Non-LOS mobile
scenarios
5.3.1
Proactive retransmission on the forward path for TCP traffic in
Railway scenarios
In the absence of link-layer FEC-based mitigations (analysed in clause 5.3.2), deep fades caused by regularly placed
power arches along railways will significantly reduce the maximum achievable forward throughput by TCP
connections. This is due to the TCP congestion control algorithm's inability to distinguish corruption-caused segment
losses from congestion-caused segment losses. The mitigation explained in this clause dictates transmitting each TCP
segment twice at a retransmission delay, denoted as rtx_delay. The mitigation does not require any modification on the
underlying satellite system. Performance of this mitigation is evaluated in [i.13] for TCP variants, Reno, Newreno, and
SACK. The analyses in [i.13] consider various train velocities with corresponding fade durations and inter-fade
durations (see clause 4.2).
The simulation analyses presented in [i.13] used ns-2,30 TCP variants with DVB-RCS extensions in MAC layer. The
analyses considered zero FEC protection for data as well as control messages. Best performance was observed for TCP
SACK variant with delayed acknowledgment option. Retransmission delay, rtx_delay, values of 10 ms and 40 ms were
considered with 3 and 5 duplicate acknowledgment options. According to the results shown in [i.13], this technique
brings improvement when the fade duration is comparable with the rtx-delay, however this mitigation should only be
used with rtx_delay longer than the longest expected fade duration. Further throughput increase was attained by using
5 duplicate acknowledgement option instead of 3.
The throughput improvement achieved by this mitigation is obtained at 100 % redundancy, and hence, its use can only
be recommended in the absence of more sophisticated forward error correction mechanisms that operate at a lower
redundancy.
The implementation of this technique does not require modifications at layers below TCP. Neither does it need
modifications at the RCST-side TCP SACK protocol stack, unless 5 duplicate acknowledgement option is to be used.
Most TCP PEPs already use TCP variants that are based on TCP SACK. Forward proactive retransmission of TCP
segments should best be realized at TCP PEPs in gateways.
ETSI
28
5.3.2
ETSI TR 102 768 V1.1.1 (2009-04)
Link layer FEC protection
In clause 6.4.5 of [i.1] countermeasures for non-line-of-sight channels have been specified. RCSTs that declare support
for non-line-of-sight (NLOS) countermeasures in the CSC burst shall be able to receive and process Link Layer
Forward Error Correction (LL-FEC). This technique can also be applied to the optional continuous return link carrier
transmissions defined in [i.1].
LL-FEC has been introduced to support reception in situations of high Packet Loss Ratio (PLR) at the MPE section or
GSE packet level. Such high PLR may occur for example on mobile channels when the speed is too high and/or the
signal-to-noise ratio is too low and/or multi-path propagation results in fading. It may also occur due to obstruction,
blockage, or other situations in which the line of sight is interrupted. With the LL-FEC, a variable amount of capacity is
allocated to parity overhead.
Transmissions employing LL-FEC use the same basic data structures as other MPE/GSE transmissions. The use of
LL-FEC is optional and is defined separately for each elementary stream in the transport stream or GSE-FEC stream in
the generic stream. Each elementary/GSE-FEC stream may configure different code parameters, resulting in different
delays, level of protection and FEC overhead.
Hereafter, guidelines are given for the use of LL-FEC with a particular focus on the railway scenario.
5.3.2.1
General LL-FEC architecture
The use of LL-FEC is optional and is defined separately for each elementary stream in the transport stream, i.e. per PID,
in this way it is possible to choose whether or not LL-FEC is applied on each elementary stream. Each elementary
stream may be configured with different LL-FEC code parameters (LL-FEC code, LL-FEC frame size) resulting in
different levels of protection, as well as different delays and FEC overheads. The application and parity data from a
LL-FEC Frame are carried over the same elementary stream. For each elementary stream implementing LL-FEC, a
cyclic LL-FEC frame index, called fec_frame_number, is managed. It is incremented for each new LL-FEC frame
transmitted on the stream.
Similarly, for GSE generic streams, the use of LL-FEC is defined separately for each GSE-FEC stream in the generic
stream, and each GSE-FEC stream may be configured with different code parameters. A GSE-FEC stream represents a
sequence of GSE packets transmitted on the generic stream and carrying the application and parity data from the same
LL-FEC Frames. A GSE-FEC stream is identified by a 14-bit identifier called gse_fec_id (equivalent to the PID for
elementary streams). This identifier is present in the GSE packets carrying application and parity data. A cyclic LL-FEC
frame index, called fec_frame_number, is managed within each GSE-FEC stream. It is incremented for each new
LL-FEC frame transmitted on the stream.
Transmissions not requiring LL-FEC should use elementary streams in the transport stream different from the
elementary streams using LL-FEC. Indeed transmissions employing LL-FEC use the same basic data structures as other
MPE transmissions but with certain fields in the header interpreted in different ways. The possibility could exist that a
LL-FEC header may be interpreted as a regular DSM-CC header, addressed to a terminal that does not support LL-FEC.
For GSE generic stream, transmissions not requiring LL-FEC will be transmitted in a regular way in the generic stream.
The level of protection provided by LL-FEC on an elementary/GSE-FEC stream is dependent on the code parameters
configured on this stream (the code parameters are signalled in the LL-FEC descriptor). This level should be selected in
accordance with the level of protection required by the traffic transmitted on this stream. It is therefore recommended to
transmit on a same elementary/GSE-FEC stream services requiring a similar QoS class.
LL-FEC aims at protecting interactive unicast and multicast traffic data transmitted over the DVB-S2 forward link
against channel impairments such as short interruptions and shadowing. Unicast and multicast traffic requiring FEC
protection will be distributed over the different elementary streams implementing LL-FEC or GSE-FEC streams.
Assigning an Elementary Stream/ GSE-FEC stream on a RCST basis (e.g. one stream per RCST and per protection
level) is beneficial for RCST since the processing in the RCST is limited to its own traffic. However, this option is
clearly limited by the number of available PIDs/gse-fec-ids, which limits the number of terminals. Moreover this low
traffic aggregation may have several drawbacks such as an increase of the total buffering in the gateway, more overhead
generated by LL-FEC, longer delay and jitter.
ETSI
29
ETSI TR 102 768 V1.1.1 (2009-04)
It is therefore highly recommended to aggregate several traffic flows, i.e. flows destined to different RCSTs or from
different multicast groups, per elementary/GSE-FEC stream. This traffic aggregation should be performed per required
protection level as mentioned above. Concerning the level of traffic aggregation, EN 301 790 [i.1] does not enforce any
rules. This depends on the targeted system, and many solutions may be considered; e.g. traffic aggregation per
MODCOD and QoS. For the terminals, this traffic aggregation implies that they must decode more than their own
traffic. A terminal shall thus first filter traffic on PID/gse_fec_id identifier and perform LL-FEC decoding (it shall be
configured with the PID(s) and gse_fec_id identifier(s) of the corresponding elementary and GSE-FEC streams on
which its traffic is transmitted). It should then filter on the NLOS_RCST_ID for MPE sections and on the Label for
GSE packets. The NLOS_RCST_id has been defined to allow receivers to filter MPE section. This 22-bit field is a
unique identifier which is locally or statically configured in each NLOS-capable RCST in the network. It can be used
for filtering of the received data instead of the conventional MAC address, which is not available due to the carriage of
the LL_FEC real-time parameters.
5.3.2.2
Guidelines on Link Layer FEC parameters selection
The FEC can be configured by making use of the ll_fec_identifier descriptor as specified in clause 8.5.5.10.24 in [i.1].
This descriptor (see table 8) defines the characteristics of one or more link layer FEC frames.
The main configuration parameters for the LL_FEC identifier descript:
•
ll_fec: indicates whether the referenced elementary stream uses LL-FEC, and which algorithm is used, namely
Reed-Solomon or Raptor code;
•
frame_size: This field indicates the exact number of rows in each LL-FEC Frame. In addition, by using this
field the address granularity and the maximum LL-FEC ADT Size are signalled. For reference, the coding of
the field is repeated in table 8. In case of any ambiguity, the table 82 in [i.1] takes precedence.
Table 8: LL_FEC frame size coding
Value
0x00
0x01
0x02
0x03
0x04
0x05
0x06
0x07
NOTE:
•
LL-FEC Frame
LL-FEC Frame
Address Granularity
rows (RS)
rows (Raptor)
(Raptor)
256
256
2
512
512
4
768
768
6
1 024
1 024
8
reserved for future
64
1
use
reserved for future
2 048
16
use
reserved for future
4 080
32
use
reserved for future
reserved for future
reserved for future
use
use
use
The address granularity is 1 for all Reed-Solomon code options.
Max LL-FEC ADT Size
(Raptor, Informative)
16 777 216 bits = 16 Mbits
33 554 432 bits = 32 Mbits
50 331 648 bits = 48 Mbits
67 108 864 bits = 64 Mbits
4 194 304 bits = 4 Mbits
134 217 728 bits = 128 Mbits
267 386 880 bits = 255 Mbits
reserved for future use
buffer_timeout: This field indicates in milliseconds the maximum time interval between the transmission of
the first section with a given fec_frame_number (in general a data section) and the transmission of last section
with the same fec_frame_number (in general a parity section).
In addition to this, for each LL-FEC frame generated in the operation the transmitter can flexibly decide on the number
of LL-FEC ADT columns, no_adt_columns, to use for this specific LL-FEC frame and the number of
LL-FEC FDT columns, no_fdt_columns, to use for this specific LL-FEC frame.
ETSI
30
ETSI TR 102 768 V1.1.1 (2009-04)
Table 9 summarizes the main parameters for the LL-FEC for different codes.
Table 9: Summary of parameters for LL-FEC configuration
Value
RS Code
Minimum Maximum
LL-FEC Frame rows no_rows 256
1 024
no_adt_columns
1
191
no_fdt_columns
0
64
LL-FEC ADT Size
1 528 KBit
LL-FEC Frame Size
2 040 KBit
Minimum
64
4
0
-
Raptor Code
Maximum
4 080
8 192
65 536 - no_adt_columns
255 Mbit
2 040 Mbit
For the appropriate selection of the FEC code and the parameter, the following parameters should be taken into account:
•
The maximum service bit rate referred to as Rservice.
•
The maximum permitted latency for the service referred to as Δservice. The maximum permitted latency
depends for example on the QoS requirements of the service. For guidelines on the selection of this parameter
refer to clause 10.
•
The expected channel conditions and some resulting target code rate for the link layer referred to as rll. More
details on the selection of appropriate code rates are discussed below.
The LL-FEC obviously performs best if the code can make use of maximum time diversity. Therefore, the LL-FEC
should expand the size of the LL-FEC ADT Size to be as large as possible to get highest diversity. The maximum
tolerable LL-FEC ADT Size is obtained as the product of the service bit rate and the maximum permitted latency as
Rservice⋅Δservice.
If this product of the service bit rate and the maximum latency is less than or equal to 1 528 kBit, then either code,
Reed-Solomon or Raptor, may be chosen. If this product of the service bit rate and the maximum latency is greater than
1 528 kBit, then the Raptor code should be chosen. Furthermore, due to the restrictions of the LL-FEC Frame Size and
the no_fdt_columns only a certain set of minimum link layer code rates rll, min can be supported for specific codes. The
minimum link layer code rate results in
rll, min = min(no_adt_columnsmax, ceil(Rservice⋅Δservice/(no_rowsmax × 8)))/(no_adt_columnsmax+ no_fdt_columnsmax),
and is shown in table 10 for different codes and different combinations of Rservice and Δservice. Table 10 highlights in
green the combinations that can be supported with a minimum code rate below 2/9 and in yellow the ones between
2/9 and 1. For white areas indicated with "na", the code cannot support the corresponding combination. The ReedSolomon codes are not applicable when long latency (long protection time) and high data rates are considered. The
Raptor code allows the extension to use cases of higher bit-rates and larger latencies and covers the entire range of
service bit-rates up to 32 MBit/s and latencies of 10 s.
ETSI
31
ETSI TR 102 768 V1.1.1 (2009-04)
Table 10: Supported link layer code rates rll (in green if below 2/9, in yellow if between 2/9 and 1) for
different maximum service bit rates Rservice and latency Δservice in ms for RS codes and Raptor codes
RS Code
20
40
80
160
320
640
1280
2560
5120
32
0.02
0.02
0.02
0.02
0.02
0.03
0.04
0.07
0.14
0.24
0.38
na
na
na
64
0.02
0.02
0.02
0.02
0.03
0.04
0.07
0.14
0.24
0.38
na
na
na
na
128
0.02
0.02
0.02
0.03
0.04
0.07
0.14
0.24
0.38
na
na
na
na
na
256
0.02
0.02
0.03
0.04
0.07
0.14
0.24
0.38
na
na
na
na
na
na
10240
20480
40960
81920
512
0.02
0.03
0.04
0.07
0.14
0.24
0.38
na
na
na
na
na
na
na
1,024
0.03
0.04
0.07
0.14
0.24
0.38
na
na
na
na
na
na
na
na
2,048
0.04
0.07
0.14
0.24
0.38
na
na
na
na
na
na
na
na
na
4,096
0.07
0.14
0.24
0.38
na
na
na
na
na
na
na
na
na
na
8,192
0.14
0.24
0.38
na
na
na
na
na
na
na
na
na
na
na
16,384
0.24
0.38
na
na
na
na
na
na
na
na
na
na
na
na
32,768
0.38
na
na
na
na
na
na
na
na
na
na
na
na
na
65,536
na
na
na
na
na
na
na
na
na
na
na
na
na
na
131,072
na
na
na
na
na
na
na
na
na
na
na
na
na
na
262,144
na
na
na
na
na
na
na
na
na
na
na
na
na
na
524,288
na
na
na
na
na
na
na
na
na
na
na
na
na
na
1,048,576
na
na
na
na
na
na
na
na
na
na
na
na
na
na
Raptor Code
s/
ti
bk
ni
et
ar
ti
B
ec
iv
re
S
m
u
im
xa
M
Latency in ms
10
Latency in ms
10
20
40
80
160
320
640
1280
2560
5120
32
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
10240
0.00
20480
0.00
40960
0.00
81920
0.00
64
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
128
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
256
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.01
512
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.01
0.02
1,024
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.01
0.02
0.04
2,048
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.01
0.02
0.04
0.08
4,096
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.01
0.02
0.04
0.08
na
8,192
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.01
0.02
0.04
0.08
na
na
16,384
0.00
0.00
0.00
0.00
0.00
0.00
0.00
0.01
0.02
0.04
0.08
na
na
na
32,768
0.00
0.00
0.00
0.00
0.00
0.00
0.01
0.02
0.04
0.08
na
na
na
na
65,536
0.00
0.00
0.00
0.00
0.00
0.01
0.02
0.04
0.08
na
na
na
na
na
131,072
0.00
0.00
0.00
0.00
0.01
0.02
0.04
0.08
na
na
na
na
na
na
262,144
0.00
0.00
0.00
0.01
0.02
0.04
0.08
na
na
na
na
na
na
na
524,288
0.00
0.00
0.01
0.02
0.04
0.08
na
na
na
na
na
na
na
na
1,048,576
0.00
0.01
0.02
0.04
0.08
na
na
na
na
na
na
na
na
na
In addition to the code selection, also the LL_FEC frame size coding needs to be selected appropriately taking into
account the parameters maximum service bit rate Rservice, maximum permitted latency for the service Δservice, the target
link layer code rate rll.
For Reed-Solomon codes, the LL_FEC frame size coding should be chosen such that the three parameters can be
supported with the smallest available number of rows, no_rows, i.e. the smallest no_rows such that:
min(191, ceil(Rservice⋅Δservice/(no_rows × 8))/255 ≤ rll.
For Raptor codes, it is recommended that the maximum number of LL-FEC ADT columns is in the range between
1 000 and 2 000. The LL_FEC frame size coding should be chosen such the three parameters can be supported with the
smallest available number of rows, no_rows, i.e. the smallest no_rows such that
Rservice⋅Δservice/(no_rows × 8) ≥ 1000.
Note that if very small or very large values of the combinations of maximum service bit rate Rservice and maximum
permitted latency for the service Δservice are to be supported, the maximum number of LL-FEC ADT columns may also
be selected outside the range of 1 000 and 2 000 between 4 and 8 192. For very small values the frame size coding
should be 0x04, i.e. the number of rows is 64, and for very large values the frame size coding should be 0x06, i.e. the
number of rows is 4 080.
For both codes, the exact no_adt_columns may be different for each LL-FEC frame and usually depends on the IP
datagram inserted. The no_fdt_columns should be selected such that the target code rate for each LL-FEC frame is met.
Both values, no_adt_columns and no_fdt_columns can be signalled individually for each LL-FEC frame.
ETSI
32
ETSI TR 102 768 V1.1.1 (2009-04)
For Reed-Solomon codes, each column of the LL-FEC FDT shall be carried in a separate section/packet. For Raptor
codes, the number of columns carried in one section/packet may be one or several. The number of columns carried in
one section/packet can be selected individually for each section/packet and may be determined based on some mappings
onto lower layer units, or based on some overhead versus coding performance metrics. In general the header overhead
should not exceed 2 % to 3 % for each section and packet.
5.3.2.3
Guidelines for the selection of the LLFEC profile
The following methodology is proposed to select the most adequate LL-FEC profiles and it should be applied to size
each of the LL-FEC instances active in the satellite gateway. The number of LL-FEC instances depends on several
architectural choices and on the way QoS support is implemented and it represents a major issue for the system
complexity and scalability. In the following, it is assumed that there are different LL-FEC instances per QoS class (or
groups of QoS classes) and per ModCod. The first requirement permits to ensure that the maximum extra latency is kept
under control; the second requirement avoids wasting the LL-FEC correction capabilities.
The following parameters are defined. Index i indicates the ModCod, whereas index j the QoS class (or group of
classes).
•
(i , j )
Pout
[s]
desired protection for ModCod i and QoS class j.
•
Δ (i , j ) [s]
extra maximum latency due to the LL-FEC.
•
Rs [baud]
symbol rate.
•
ηi
physical layer efficiency of ModCod i according to table 13 of
[bit/s/Hz]
[AD-1].
•
η2
•
Si [%]
bandwidth share of ModCod i.
•
N R(i , j ) [bytes]
number of rows in the ADT for ModCod i and QoS class j.
•
N C(i , j )
number of columns in the ADT for ModCod i and QoS class j.
•
(i , j )
N CR
number of redundancy columns in the ADT for ModCod i and
[%]
average layer 2 encapsulation efficiency which will depend on
the adopted layer 2 encapsulation scheme (MPE/MPEG or
GSE) and on the typical size of IP packets.
QoS class j.
•
ηc
[%]
efficiency of the LL-FEC coding scheme. This is 100 % for
MDS codes like RS, typically around 98 % for Raptor or
LDPC codes.
With the above parameters, the following definitions apply:
R i = Si Rsηiη 2 [bps]
average equivalent data rate per ModCod after LL-FEC
encoding and prior to layer 2 encapsulation (assuming that
BBFrames of different ModCods are multiplexed uniformly if a different scheduling policy is implemented, the previous
equation might not be valid).
N C(i , j )
(i , j )
N C(i , j ) + N CR
•
r (i , j ) =
•
ADT (i , j ) = 8 N R(i , j ) N C(i , j ) [bits]
LL-FEC code rate for ModCod i and QoS class j.
size of ADT for ModCod i and QoS class j.
ETSI
33
ETSI TR 102 768 V1.1.1 (2009-04)
ADT (i , j )
1 − r (i , j ) ) [bits] maximum tolerable burst length for ModCod i and QoS class j.
(
(i , j )
r
•
MTBL(i , j ) = ηc
•
Using the previous 2 definitions, the latter can be also written as:
(i , j )
MTBL( i , j ) = 8ηc N R(i , j ) N CR
•
(i , j )
FECFR (i , j ) = 8 N R( i , j ) ( N C(i , j ) + N CR
) [bits] size of LL-FEC Frame for ModCod i and QoS class j
•
R
(i , j )
= R i w(i , j ) [bps]
average equivalent data rate per ModCod and QoS class
after LL-FEC encoding and prior to layer 2 encapsulation.
The factor
strategies:
w(i , j ) account for different possible scheduling
-
w( i , j ) = 1
means that the scheduler selects entire FEC Frames for
transmission.
-
w(i , j ) = 1/ N Q
(being
N Q the number of QoS classes) corresponds to a
round robin approach, resulting in a uniform multiplexing
of packets belonging to FEC Frames of different QoS
classes, under the assumption that the granularity of the
scheduler is much lower than the size of the smallest ADT.
With the definitions given above, and omitting indices i and j in the following for the sake of clarity whenever this is
not going to cause ambiguity, the problem of properly sizing the LL-FEC process (i.e. of selecting NR, NC and r) can be
analytically formulated by means of the two following equations:
(i , j )
MTBL ≥ Pout
R
FECFR ≤ Δ
(i , j )
(i, j )
R
⇒ N N ≥ P R / 8η
⇒ N (N + N ) ≤ Δ R
R
(i , j )
(i , j )
out
CR
(i, j )
c
(i , j )
R
C
(i , j )
CR
/8
The following considerations are in order:
•
The desired protection level and the extra maximum latency are guaranteed on an average basis by the above
equations, due to the fact that average data rates values are used because, in order to avoid a loss of generality,
an average value for the layer 2 encapsulation efficiency η 2 (which in reality depends on the size of the IP
datagrams) has been used. This does not make the present methodology especially suited for jitter-sensitive
applications, unless constant size IP datagrams can be assumed for the corresponding QoS classes.
•
NR shall be kept as low as possible to reduce the number of encoding/decoding processes running in parallel at
the gateway/terminal side, thus reducing the system complexity.
•
The code rate shall be maximized in order to increase the system efficiency. This means that NC /NCR shall be
as large as possible.
•
The fulfilment of the extra latency requirement expressed by the second equation is subject to the assumption
(i , j )
that the system is fully loaded (i.e. the service rate is roughly equal to R
). If this is not the case, NR shall
be reduced so that the extra delay requirement is still met (at the expenses of a lower efficiency). According to
[i.1], NR can be reduced on a frame-by-frame basis.
•
The methodology assumes a constant share of capacity between ModCods. When a significant change in the
share of capacity between ModCods occurs, the FEC Frame dimensioning needs to be adjusted. This implies
that the NCC shall distribute new TIMs whenever NC or NCR shall be changed.
ETSI
34
ETSI TR 102 768 V1.1.1 (2009-04)
The type of code shall be selected taking into account the parameters range reported in the table 9 in accordance with
[i.1].
1)
The type of code shall be selected considering that RS codes can be used only if:
Pout R
(i , j )
≤ 64 ⋅1024 ⋅ 8 = 512 kbps
otherwise Raptor shall be used.
2)
NR shall be hence initially determined as the minimum value according to those listed in the tables above
which is still greater or equal than:
Pout R
(i , j )
/ 8ηc max ( N CR )
where max(NCR) is 64 for RS and 65535 for Raptor.
3)
NCR shall be determined as the minimum value according to the ranges listed in the tables above which is still
greater or equal than:
Pout R
4)
(i , j )
/ 8ηc N R .
NC shall be determined as the maximum value according to the ranges listed in the tables above which is still
lower or equal than:
ΔR
(i, j )
/ 8 N R − N CR .
In this way, the highest possible code rate is selected, thus maximizing the overall efficiency.
In the case of Raptor codes, NC should lie in the range between 1 000 and 2 000 to achieve optimal
performance. It might be then necessary to re-iterate steps 1 to 4 by increasing NR in order to achieve this
optimal configuration.
5.3.2.4
Selection of an elementary stream carrying LL-FEC
LL-FEC is applied individually in the context of a TS or GS elementary stream. This allows some elementary streams
to apply LL-FEC and some to apply MPE/GSE.
[i.14] indicates directly and indirectly two methods that an RCST can use for selecting an elementary stream:
a)
By recognition of the elementary stream type in the PMT section in the Forward Link Signalling (FLS)
service.
b)
By explicit assignment of an elementary stream through the Forward Interaction Path (FIP) descriptor.
In addition, a Multicast Mapping Table (MMT) may be used to select elementary streams for multicast.
LL-FEC uses the MPE parameter fields in a way that is incompatible with standard MPE and may cause legacy RCSTs
to fail. It is thus necessary to avoid that a legacy RCST selects and attempts to decode an elementary stream that applies
LL-FEC, whereas an LL-FEC- capable RCST must be able to automatically acquire a stream that applies LL-FEC.
A legacy RCST cannot be expected to receive transmissions that apply LL-FEC due to possible 48- bit MAC
discrimination. Additionally, irrelevant IP traffic may pass the MAC address filter due to MAC address aliasing.
NOTE:
The same type of MAC address incompatibility will not occur with GSE.
ETSI
35
5.3.2.4.1
ETSI TR 102 768 V1.1.1 (2009-04)
Assignment of LL-FEC TS elementary stream to RCST
Primarily, the explicit method for assigning an elementary stream seems most feasible when applying LL-FEC for the
elementary stream. The RCST, even if LL-FEC compatible, should not be expected to autonomously select and receive
the LL-FEC elementary streams indicated in the PMT service description, and may initially choose not to receive any
LL-FEC elementary stream until explicitly instructed. There may be LL-FEC elementary streams listed in the PMT
service description that are not relevant for a specific RCST at a given time as they may be listed purely for the
declaration of the stream type that indicates that LL-FEC is applied.
An elementary stream applying LL-FEC can be recognized in the PMT section of the applicable FLS services by the
association of the specific stream type with the specific elementary stream. It is recommended that the value 0x8D (user
defined) is interpreted as indicating a LL-FEC stream type; and any value within the range administrated by
EN 301 790 [i.1] assigned to indicate the LL-FEC stream type should be understood as such an identifier as well, if the
meaning of the value is known.
The NCC may recognize the LL-FEC capability of the RCST at the logon request. It may then explicitly assign an
elementary stream carrying LL-FEC by use of the FIP in the logon response TIM. An associated declaration of the
stream type of each elementary stream in the PMT section with the associated FLS service description indicates
explicitly that an elementary stream applies LL-FEC, and hence, the RCST can configure the MAC discrimination
accordingly. Alternatively, the MMT may be used to indicate elementary streams used to carry LL-FEC. An associated
declaration of the stream type of each elementary stream in the MMT section with the associated FLS service
description indicates explicitly that an elementary stream applies LL-FEC, so that the RCST can configure the MAC
discrimination accordingly. By default, an RCST will assume that the MMT indicates elementary streams with stream
type 0x0D, i.e. carrying MPE with full 48 bit MAC address.
The reduced MAC address size indicated by the combination of an applicable broadcast descriptor and the specific
conventions for non-LOS use applies only for the elementary streams that are of a stream type that applies LL-FEC.
This concerns multicast traffic as well as unicast traffic.
5.3.2.4.2
Assignment of LL-FEC stream gse_fec_id to RCST
It is assumed that a GSE receiver will parse all GSE traffic and discriminate non-compatible protocols and irrelevant
MAC addresses. A specific assignment mechanism is not required.
5.3.2.5
5.3.2.5.1
Use of LL-FEC on GSE generic streams
Application data transfer over GSE-FEC streams
For the carriage of application data over GSE-FEC streams, EN 301 790 [i.1] defines a new optional GSE extension
header referred to as LL_RCS_FEC_ADT. This extension header carries the real-time parameters as well as the
gse_fec_id identifier of the GSE-FEC stream.
This extension header is inserted in GSE packets carrying a full datagram or, in case of fragmentation of the datagram,
in the GSE packet carrying the first fragment of the datagram (see figure 10), as specified by the GSE specification
[i.14]. The real- time parameters always make reference to the full datagram: the dt_position field indicates the position
in the LL-FEC frame of the first byte of the PDU, the table_boundary flag indicates whether or not the PDU is the last
PDU in the Application data table.
ETSI
36
S E
= =
1 0
Label
Type
GSE
length
Frag ID
Total
length
S E
= =
0 0
Label
Type
GSE
length
Frag ID
PDU
cont
S E
= =
0 1
Label
Type
GSE
length
Frag ID
PDU
end
ETSI TR 102 768 V1.1.1 (2009-04)
Protocol
Type
Label
LL_RCS_
FEC_ADT Type
ext hdr
PDU start
CRC
CRC computed on the
shaded fields
Figure 10: PDU fragmented over 3 GSE packets
A 2-Byte Type field will always be appended to the LL_RCS_FEC_ADT header (see figure 11), as for any GSE
optional extension header [i.15]. This Type field is identical to the Protocol Type/Extension field of the GSE Header
(with the same rules and semantic for values assignment). It indicates the type of the next header or the protocol type of
the encapsulated PDU for the last extension header in the packet.
GSE Header
Label GSE Protocol
Type
S E Type length
Label
LL_RCS
FEC_ADT Type
Ext
Hdr 2
Type
PDU
Figure 11: Use of the Type field in the LL_FEC_ADT_extension
5.3.2.5.2
Carriage of parity data over GSE-FEC streams
For the carriage of parity over GSE-FEC streams, EN 301 790 [i.1] defines a new mandatory GSE extension header
referred to as LL_RCS_FEC_FDT_extension. This extension header carries information related to the FEC frame and
the location of parity data in the FEC frame as well as the gse_fec_id identifier of the GSE-FEC stream.
The format of GSE packets carrying parity data is described in the figure 12.
As described, the label field is not present in the header of GSE packets carrying parity data (the label_type indicator is
set to "10"). Indeed Receivers only need to filter on the gse_fec_id identifier present in the extension header. They will
then perform LL-FEC decoding.
ETSI
37
ETSI TR 102 768 V1.1.1 (2009-04)
1. Parity Data carried over one GSE packet
S E
= =
1 1
Label
Type
Protocol
LL_RCS_FEC_FDT info
GSE
Type =
(gse_fec_id,
length LL_RCS_
RS or Raptor info)
FEC_FDT
Parity_
data_
CRC_
32
Parity Data
CRC computed on the
shaded fields
2. Parity Data fragmented over several GSE packets
Protocol
LL_RCS_FEC_FDT info
Type =
(gse_fec_id,
LL_RCS_
RS or Raptor info)
FEC_FDT
S E
= =
1 0
Label
Type
GSE
length
Frag ID
S E
= =
0 0
Label
Type
GSE
length
Frag ID
Parity Data
cont
S E
= =
0 1
Label
Type
GSE
length
Frag ID
Parity Data
end
Total
length
Parity Data Start
CRC
CRC computed on the
shaded fields
Figure 12: Carriage of parity data over GSE packets
The carriage of parity data will be realized as follows:
•
For Reed-Salomon parity data, LL_FEC will provide the GSE encapsulator with FDT columns (seen by the
encapsulator as separate PDUs). The GSE encapsulator will fragment if necessary, and encapsulate
independently each FDT column in GSE packets.
•
For Raptor code parity data, LL_FEC will provide the GSE encapsulator with repair symbols or groups of
repair symbols, i.e. one FDT column or a group of several consecutive FDT columns. The GSE encapsulator
will fragment if necessary, and encapsulate independently each repair symbol or group of repair symbol.
In case of fragmentation, the information related to the location of the Parity Data in the FDT table (which are inserted
in the GSE packet carrying the first fragment) always make reference to the "full parity data" (i.e. FDT column, repair
symbol or group of repair symbols).
5.3.2.5.3
Use of the CRC_32 extension header
GSE assumes that the physical/link layer below can ensure a sufficient error detection probability like in DVB-RCS/S2
fixed systems (DVB-S2 FEC code, based on BCH+LDPC, allows Quasi-Error-Free operation). However, in NLOS
conditions this assumption is not valid, and GSE packets may contain bit errors.
When received parity and application data are inserted by Receivers in the LL_FEC frame, they are marked by the
LL-FEC process as reliable. However as GSE packets may contain bit errors and the PDU reliability is not checked in
all cases, bit errors may be inserted (and marked as reliable) in the table. This could impair the LL-FEC performances.
The only case where the reliability of GSE packets is not checked is for packets carrying non-fragmented application
data. For fragmented application and parity data, the GSE native CRC-32, which is appended at the end of the GSE
packet containing the last fragment, allows checking the reliability of these data. For
non-fragmented parity data, a CRC-32 has been defined in the GSE packet format, part of the LL_RCS_FEC_FDT
extension header, and allows checking the reliability of these data.
In order to counteract this issue, EN 301 790 [i.1] defines a new optional GSE extension header referred to as
LL_CRC32. This extension header may be used in GSE packets carrying Application data, but only if they carry a nonfragmented PDU.
ETSI
38
ETSI TR 102 768 V1.1.1 (2009-04)
This CRC_32 value is computed using a method equivalent to that used for the CRC_32 defined by GSE and with a
similar scope (it is computed over all bytes be starting from the GSE length field (included) to the end of the PDU, but
not including the CRC extension header field).
Similar to the case the LL_RCS_FEC_ADT extension header, a 2-Byte Type field will be always appended to it. It will
indicate the type of the next header or PDU. This extension header may be equally inserted before or after the
LL_RCS_FEC_ADT extension header.
S E
= =
1 1
Label
Type
GSE
length
Protocol
Type
Label
LL_
CRC32
Ext hdr
LL_RCS_
Type FEC_ADT Type
Ext hdr
PDU
Figure 13: Use of the LL_CRC32 extension header in GSE packet carrying a non-fragmented
datagram (from application data)
NOTE:
5.3.3
The CRC 32 defined by GSE as well as those from the LL_CRC_32 and LL_RCS_FEC_FDT extension
headers (which have been defined with a scope of protection similar to the GSE CRCs scope) are not
computed over all the bytes of GSE packets (as shown on the previous figures). This may induce residual
errors (i.e. not detected), however this should barely affect the LL-FEC performances.
Protection of the signalling
No channel countermeasures have been adopted for the protection of signalling. As a general rule, the adoption of a link
margin of the same magnitude as the Rice channel amplitude variations is recommended in order to protect the
signalling from the losses due to these Rice channel variations both on forward and return paths.
QoS requirements for signalling are presented in clause 10.2.
5.4
Guidelines for the use of VCM/ACM in mobile scenarios
Fade Mitigation Techniques (FMTs) are a set of techniques that help a system adapt its physical layer to the propagation
channel variations due to tropospheric attenuation (e.g. rain, clouds etc.). These techniques (such as ACM) allow
maximizing the link capacity in clear sky while maintaining the required availability during unfavourable propagation
conditions. FMTs require a control mechanism, called "FMT control loop", to monitor the state of the channel and to
command the activation of the technique itself.
The mobility of the RCST introduces an additional time-dependency in the propagation channel. This needs to be taken
into account when designing the FMT control loop. In principle, FMTs cannot be used to counteract mobility effects
such as multipath, blockage and shadowing encountered due to the local environment in the vicinity of the mobile
RCST. Therefore, in mobile DVB-RCS reference scenarios, the FMTs can be applied to counteract only the
tropospheric attenuation, such as rain attenuation. Particularly, in the aeronautical scenario, where rain attenuation is not
relevant at cruising altitude, FMTs can be applied to track the satellite antenna EIRP variation over the coverage.
ETSI
39
ETSI TR 102 768 V1.1.1 (2009-04)
The design of a reliable FMT control loop is based on the knowledge of the actual dynamics (that is, second-order
statistics) of fading, such as the fade slope and fade duration. The ITU-R Recommendation P.1623-1 [i.34] proposes a
model for the prediction of the rain fade slope in classical Ku-band and Ka-band FSS. Based on this analysis and its
extrapolation to mobile conditions [i.17], it is possible to transform the second-order rain attenuation statistics from a
fixed to a mobile satellite system. This transformation is possible through the following extrapolation factor, here
termed as Slope Ratio (SR):
SR =
fade slope in mobile v M − v R ⋅ cos φ
=
fade slope in fixed
vR
r
r
where vM = vM exp ( iθ M ) is the velocity vector of the mobile RCST, vR = vR exp ( iθ R ) is the velocity vector of the
raincells movement (vR also called "advection" or "front speed") and φ is the angle between these two vectors.
Therefore, for the prediction of the FMT control loop margins in a mobile DVB-RCS system, it is important to know
the following items:
i)
the second-order rain attenuation statistics of a fixed satellite system operating under the same conditions
(i.e. geographic location and system characteristics;
ii)
the front speed, the mobile RCST speed, the relative direction of their motions and the kind of their motions
(i.e. rectilinear, zigzag, circular, etc.).
Based on the results shown in [i.18] (specifically for the railway scenario), the FMT control loop margin needs to be
increased in a mobile DVB-RCS system under LOS conditions, due to the relative increase of the rain fade slope by a
factor of SR=6. Moreover, the FMT control loop margin required due to mobility can be adaptive based on the actual
train speed and the rain attenuation level. In non-LOS conditions referring, particularly, to fast fades due to power
arches, the absence of channel estimation for few tens of milliseconds will not affect the FMT control loop. However, in
the case of long blockages due to tunnels, the use of a short-term rain fade prediction method allows estimation of rain
fading statistics after few seconds of outage. Assuming the worst case when the rain fading always keeps increasing
while the train is in blockage, the FMT control loop margin at the moment of the train's exit from the tunnel has been
calculated and shown to increase as the train speed, or the initial actual rain attenuation levels (at the train's entrance to
the tunnel), or the blockage duration increases. For example, for a train speed vM = 250 km/h, blockage of length 350 m
(that is, duration of 5 s) and 3 dB of actual rain attenuation level at the moment of the train's entrance to the tunnel, the
required FMT control loop margin at the moment of the train's exit from the tunnel is 1,5 dB.
In maritime scenario, rain fade can be counteracted in the same way as it is done for the FSS. The low speed of the
mobile RCST in this scenario leads to a slight increase in fade slope by a factor SR = 1,5. Therefore, only 0,5 dB of
margin due to this fade slope increase is required in the FMT control loop.
In aeronautical scenario, the link can be adapted to the different antenna gain over the coverage. The C/N variation
caused by the antenna roll-off is slow enough to be safely counteracted with a control loop based on the C/N estimation
without the need of additional margins. If the RCST position is known, this information can be used by the GW or by
the terminal to activate the appropriate MODCOD without the need of channel estimation or an FMT control loop.
6
Return link
6.1
Doppler drift and time correction
Annex L to the general DVB-RCS guidelines [i.3] presents a feasibility analysis on the use of EN 301 790 [i.1] on
mobile scenarios. As suggested there, few if any special considerations for mobility are necessary in the forward link.
There are however some considerations for the return link; these are addressed in general terms in [i.3] and in more
detail in the following.
ETSI
40
6.1.1
6.1.1.1
ETSI TR 102 768 V1.1.1 (2009-04)
Carrier Frequency Doppler Shift
Log-On
Annex L [i.3] derives lower limits for the symbol rates that can be supported without Doppler compensation. These are
determined by the carrier frequency tolerance of the hub, and are in some cases quite high. On the other hand, upper
bounds the symbol rates are set due to the EIRP limitations in combination with the anticipated space segment
characteristics. In some cases, there is only a narrow range of possible rates left. This is clearly unattractive in terms of
system design flexibility. It is difficult to increase the receiver's frequency tolerance substantially beyond the 3 %
assumed in [i.3]; hence, we recommend the use of Doppler pre-compensation in the return link where appropriate. This
can be implemented with relative ease, provided that navigation information is available. With such compensation,
bound on the symbol rate are set e.g. by phase noise considerations, just as they are in fixed implementations.
The Doppler shift in the return link can be determined from the link geometry and the velocities of the terminal and
satellite, using conventional solid geometry. The Doppler shift is proportional to the relative speed of the satellite and
terminal. It should be noted that the total frequency error at the hub receiver is determined not only by the Doppler shift
in the return link, but also has a contribution from the forward link, resulting from the Doppler shift on the NCR clock.
As shown in [i.3], the worst-case Doppler is experienced by aeronautical terminals. For these, the terminal motion
dominates the Doppler shift. In the worst case, the Doppler shift is therefore given by fv/c, where f is the frequency, v is
the terminal speed and c is the speed of light. With an initial frequency tolerance of 3 % as suggested in [i.3], a
100 kBaud carrier can tolerate an offset of 3 kHz. In turn, this corresponds to an error in the terminal's speed estimate of
30 m/s or 108 km/hr. This is well in excess of the error that can be expected, for example, from satellite navigation
equipment. Estimating the initial frequency offset due to Doppler with sufficient accuracy should therefore not be a
problem in practice.
6.1.1.2
Carrier Frequency Synchronisation Maintenance
Following logon, the terminal's transmit frequency can be controlled by closed-loop mechanisms already present in
DVB-RCS. The worst-case Doppler rate identified in [i.3] is 1 700 Hz/s. A closed-loop frequency control can therefore
maintain the carrier frequency within 3 kHz, provided the latency (update interval plus two-way propagation delay) of
the loop is less than approximately 1,75 s.
For typical implementations, these tolerances are relaxed in proportion to the return link symbol rate.
6.1.2
Symbol Rate Doppler Shift
According to [i.3], the worst-case relative Doppler shift, which is experienced by the aeronautical terminal, is 1 ppm.
This is considerably smaller than the 20 ppm symbol rate tolerance allowed by EN 301 790 [i.1] (clause 6.1.4), and is
therefore not an issue for system synchronisation.
6.1.3
6.1.3.1
Burst Timing
Log-On
The ordinary log-on process for DVB-RCS RCSTs relies on accurate knowledge of the position of both the RCST and
the satellite, in order to allow transmission of the CSC burst within a window that is at most one or two milliseconds
long. In certain mobile applications, it is highly desirable to allow a much wider acquisition window. Reasons for this
include a desire to be independent of for example accurate satellite ephemeris data and/or positioning information. It
can be noted that the timing uncertainty applies to all types of mobile terminals, including for example maritime
terminals that may not need the navigation information for correction of carrier frequency Doppler shift.
Large initial timing uncertainty may also arise where accurate ephemeris data is readily available. This includes, but is
not always limited to inclined-orbit satellites. It can be noted that use of inclined-orbit satellites is particularly attractive
for mobile applications, where the RCST most often needs a tracking antenna anyway.
ETSI
41
ETSI TR 102 768 V1.1.1 (2009-04)
The present document has some limitations that impede a straightforward extension of the initial timing tolerance. The
leading-edge guard interval (burst_start_offset) of the CSC slot is limited to ~1,42 ms, because the corresponding field
in the Timeslot Composition Table is only 16 bits wide. While the time slot can be up to 364 ms long, the leading-edge
guard interval limitation effectively limits the tolerance. In addition, the maximum time correction that is possible using
the Correction Message Descriptor is 127 × 27 PCR ticks, or ~439 μs.
Assuming that any NCC/satellite path delay variation is handled either by making use of the optional NCR packet
payload or by appropriate adjustments of the NCC timing, the uncertainty in the absence of positioning or ephemeris
information is determined by the path delay variation between possible terminal locations and that caused by satellite
motion. The one-way delay variation between a satellite directly overhead and one on the horizon is ~20 ms. The daily
delay variation of a satellite in a 10° inclined orbit is around 7,5 ms (for a user location that has the satellite on the
horizon). The worst-case uncertainty is therefore around 28 ms - i.e. much bigger than what can be handled by the
current method.
In the past, TDMA systems have employed techniques such as dedicated log-on carriers with completely open
acquisition windows in order to overcome the initial uncertainty. Adding such a feature is unattractive for DVB-RCS,
both in terms of modification of the standard and equipment, and because it requires dedicated bandwidth, which does
not generate revenue. Instead, the method described in the following has been adopted. Details are defined in
clause 7.3a of EN 301 790 [i.1].
The method is illustrated in Error! Unknown switch argument.. The system is configured with a number of
contiguous, normal-length CSC slots that together cover an interval at least as long as the anticipated uncertainty. When
operating in this mode, the RCST always aims for a CSC slot as close to the middle as possible. Due to the uncertainty,
the burst may however be received in another slot. To resolve this ambiguity, the Correction Message Extension
descriptor (clause 8.5.5.10.20 of EN 301 790 [i.1]) is sent in the logon TIM. This descriptor identifies the slot in which
the CSC burst was received. It is sent to the RCST in addition to the usual Correction Message Descriptor. This
information enables the RCST to compute the overall timing correction required before proceeding to coarse or fine
acquisition.
In order to prevent RCSTs that require this large initial uncertainty from attempting to log on to systems that do not
support it, NCC support for this feature is signalled in the Superframe Composition Table. The feature can thus be made
available on a per-superframe basis.
ETSI
42
ETSI TR 102 768 V1.1.1 (2009-04)
Figure 14: Log-on method for terminals with large initial uncertainty
The method is completely backwards compatible. RCSTs that do not need the extra tolerance can log on in exactly the
same way as they currently do, and will simply ignore the Correction Message Extension descriptor that tells them
which slot they hit.
It may happen that the CSC burst is transmitted across a slot boundary. Depending on the NCC receiver
implementation, this may result in the loss of the burst. This situation is handled by the regular CSC retransmission
scheme; however, the RCST should ideally use a back-off that is not an integer multiple of the slot duration, in order to
avoid continually selecting locations that cross slot boundaries.
6.1.3.2
Timing Synchronisation Maintenance
Once initial acquisition has been performed, the closed-loop timing of DVB-RCS can maintain synchronisation. The
worst-case timing drift identified in [i.3] is 1 100 ns/s. For a 4 Msps carrier and a loop latency (update interval + twoway propagation delay) of 1 second, the maximum drift is approximately 4 symbol periods. Uncertainties of this
magnitude can be accommodated by minor adjustments of the guard intervals, without dramatic effect on the spectral
efficiency. Expressed in symbol periods, the uncertainty is proportional to the data rate, so it is correspondingly smaller
for carriers with symbol rates lower than 4 Msps.
ETSI
43
6.2
ETSI TR 102 768 V1.1.1 (2009-04)
Spectrum spreading in the return link
In Mobile Line-of-sight scenarios, return link carriers may require the use of spectrum spreading in order to reduce the
spectral density and in particular off-axis.
Indeed, the use of very small antennas necessary to the mobile applications in Ku Band is incompatible with the off-axis
emissions defined in the ETSI and FCC rules with the existing DVB-RCS waveform.
The spreading technique to be used is described in clause 6.5.5 of [i.1].
6.2.1
Spreading description
The spectral spreading is achieved by two means. The first consists of the use of π/2-BPSK modulation. This is
equivalent to spreading a QPSK modulated signal by a factor 2.
The second solution consists in increasing the symbol rate of the signal by a factor N without increasing the power. This
modification reduces the Es/N0 at the receiver side. In order to recover the required Es/N0, the signal is repeated
N times at the transmitter side.
In the DVB-RCS application, the signal is repeated in a burst by burst basis.
Figure 15: Post-encoder processing with spectrum spreading
The signal after spreading looks like in figure 16.
Figure 16: Spectrum spreading by burst repetition
In order to avoid discrete lines in the output spectrum, a random phase shift shall be applied to each replica before
transmission. This has no impact on the despreading since the relative phases between replicas are estimated in the
receiver.
6.2.2
Despreading description
Despreading is achieved by summing together homologous signal samples of successive replicas.
Prerequisite of the approach is that the timing error and Doppler of the transmitter with respect to the gateway is lower
than what would cause an accumulated timing phase error during the duration of the burst replicas. This is actually the
case in typical operational scenarios. In fact, even considering the worst case Doppler experienced in the aeronautical
domain (1 100 ns/s), more than of 45 000 symbols would be required for timing errors to accumulate up to a value
larger than 10 % of the symbol period.
ETSI
44
ETSI TR 102 768 V1.1.1 (2009-04)
Obviously, the combining shall be such that homologous samples are added in phase. In this regard, a phase alignment
is required before combining.
The principle for the recombination is shown in figure 17.
Phase
compensation
Phase
compensation
Phase estimator
Phase
compensation
......
......
......
......
N copies
Figure 17: Coherent recombination
The despreading solution by recombination needs to memorize at least 2 replicas in order to perform the relative phase
estimation. This estimation can be done via a block correlator because what we need is exp(jΔφ) and not Δφ itself. An
iterative recombining scheme will minimize the required memory.
In order to have a good phase alignment, the differential frequency shift between replicas shall be as low as possible.
The corresponding frequency shift tolerance will depend on the burst size.
The frequency tolerance and the phase-shift tolerance are related by the following formula:
Δf ⋅ Ts =
Δϕ
π ⋅ Ns
(5)
where Ns is the number of symbols inside a replica, Ts is the symbol duration after spreading, Δϕ is the maximal phase
tolerance and Δf is the frequency tolerance between replicas.
The longer the burst, the lower the frequency tolerance.
Typically, in order to have negligible degradations, a 15° error phase between replicas have been considered.
Considering a 512 kBaud carrier and a 15° tolerance, the maximal frequency tolerance between 2 consecutive replicas
is 45 Hz for a burst of 1 000 symbols length. This value is compatible with a 1 kHz/s frequency drift in Ku-Band.
After the despreading, the estimations of the absolute delay, frequency and phase are done by conventional timing and
carrier recovery algorithms, so a classical DVB-RCS demodulator can be used as shown in figure 18.
ETSI
45
ETSI TR 102 768 V1.1.1 (2009-04)
De-spreading
DVB-RCS
Burst
Dem odulator
ADC
Nyquist
FIR Filter
DVB-RCS TPF
Estim ator
DVB-RCS
Dem od
QPSK Soft
Dem apping
Turbo Decoding
Figure 18: Receiver architecture including despreading
6.3
Return link countermeasures for Non-LOS mobile scenarios
The following techniques can be used to counteract signal blockage in Non-LOS scenarios. The first technique,
pro-active retransmission, is applicable for the MF-TDMA mode of DVB-RCS. The second technique, LLFEC, is
applicable for the continuous carrier mode operation.
6.3.1
Proactive retransmission technique
The Proactive Retransmission technique is an outage countermeasure suitable for the return link of a DVB-RCS system
operating in mobile scenarios.
In its basic form, it consists in the disabling of the RCS transmitter when an outage event is detected. During the fading
event, data are buffered in the transmitter and only transmitted when the fading event is over. In this form of the
technique only the physical layer of the terminal is involved. Variants to this mechanism, involving multiple protocol
layers, can be foreseen to further improve the performances and will be described briefly.
Proactive retransmission is made possible by the correlation of fading due to signal blockage or shadowing between FL
and RL. As the FL fading level can be readily estimated by suitable processing of the received DVB-S2 carrier, a
threshold on the measured FL fading can be set to trigger the Proactive Retransmission mechanism. In this regard, the
fading level measurement can be done by monitoring the FL carrier SNIR. A SNIR measurement averaged over a single
DVB-S2 frame (assuming the availability of the optional pilot symbols) is typically sufficient for the purpose as evident
in figure 19, which shows the mean and standard deviation of the DA-SNORE [i.16] SNIR estimator operating on the
pilot symbols of a single PLFRAME. In fact, an error standard deviation of about 0,27 dB would be achieved at 0 dB
input SNR. The standard deviation would increase to about 0,4 dB at an input SNR of -5 dB and 0,6 dB at -10 dB input
SNR.
Since the multipath component of the fading is uncorrelated between FL and RL, the error in the RL fading estimation
is obviously larger than the FL SNIR estimation error. However, for a C/M ratio of 17 dB the probability that the
multipath fading exceeds 2 dB is well below 10-3. Regardless, a suitable margin to overcome the multipath fading on
the RL shall be available to minimize the packet loss due to the multipath fading, which cannot be countered by the
Proactive scheme.
ETSI
46
ETSI TR 102 768 V1.1.1 (2009-04)
1
10
8
Std. Dev.
Mean
0.8
6
0.7
4
0.6
2
0.5
0
0.4
-2
0.3
-4
0.2
-6
0.1
-8
0
Mean (dB)
Standard Deviation (dB)
0.9
-10
-10
-5
0
5
10
Input SNR (dB)
Figure 19: DA-SNORE estimation error standard deviation
(for QPSK modulated normal FECFRAME)
The other condition necessary to enable this technique is that the FL DVB-S2 signal should be rapidly re-acquired after
a short deep fading event. If timing is maintained, frame resynchronization can be carried out within one frame with
suitable re-acquisition techniques implemented at the demodulator level. As the DVB-S2 frame time is in the order of
1 ms to 2 ms for typical system parameters we can neglect the time for DVB-S2 signal re-acquisition after short link
interruptions. In fact, re-acquisition time is less than or comparable with the typical length of a DVB-RCS burst.
The main advantage of the Proactive retransmission technique is that it may allow faster retransmission with respect to
what is possible if either standard TCP or I-PEP recovery mechanisms are relied upon instead. In particular, it is well
known that TCP recovery mechanisms may negatively affect the connection throughput and experienced latency
particularly if congestion control mechanisms like slow-start or congestion avoidance are triggered due to the packet
losses caused by the link fading instead than true congestion. Proactive retransmission has the capability to minimize
such events particularly when frequent short fading events are foreseen as it typically happens in the railway scenario
due to the effects of the power arches.
power
arch
power
arch
power
arch
Shadowing event
detector threshold
RT link channel SNIR evolution
zero margin
link threshold
i-th IP
packet
i-th IP
packet
i-th IP
packet
i+1-th IP i+2-th IP i+2-th IP i+2-th IP i+3-th IP
packet
packet
packet
packet
packet
Terminal TX
IP packets
Figure 20: Pictorial description of the proactive retransmission scheme in the railway scenario
6.3.1.1
Proactive retransmission performance in the railway scenario
In order to test the effectiveness of the proactive retransmission scheme a simple railway scenario has been simulated.
Figure 20 shows a pictorial description of the technique. A single GW station managing multiple trains was considered
in the following simulations. Also, in order to minimize the simulation time, a single DVB-RCS carrier is assumed
available in the system. The Reno TCP with SACK option has been used in addition to the ECN and large window
options.
ETSI
47
ETSI TR 102 768 V1.1.1 (2009-04)
An example result obtained in a scenario consisting of six terminals (trains) and a gateway is presented in figure 21 and
figure 22. A single MF-TDMA carrier was (512 Kbit/s bit rate) considered. Moreover, each train terminal was assumed
running an FTP application.
400
Throughput (kbit/s)
350
300
250
200
150
TCP SACK
TCP SACK + Proactive
MTU=568 bytes
100
0
20
40
60
80
100
120
140
160
180
Train Speed (Km/h)
Figure 21: Throughput Comparison of proactive versus conventional scheme.
TCP-SACK (MTU=568 bytes). Link Margin: 3 dB. RCS burst size: ATM-2
240
220
MTU=88 bytes
TCP SACK + Proactive
Throughput (kbit/s)
200
TCP SACK
180
160
140
120
100
0
20
40
60
80
100
120
Train Speed (Km/h)
Figure 22: Throughput Comparison of proactive versus conventional scheme.
TCP-SACK (MTU=88 bytes). Link Margin: 3 dB. RCS burst size: ATM-2
It shall be observed that, given the possible segmentation of an IP packet on multiple ATM cells / bursts and the lack of
mechanism in ATM/AAL5 IP encapsulation for supporting reassembly of IP packet in presence of out of order ATM
cells, proactive retransmission shall be performed in such a way that the whole IP packet is retransmitted even if a part
of that IP packet has been already successfully delivered to the receiving end.
The worst performance achieved with the shorter MTU (88 bytes) are due to the losses produced by multipath and are
thus related to the link margin on the up-link. Although the number of lost packets due to multipath is not higher than
those lost with MTU = 568, the effects of the loss are higher as the TCP slow start mechanism require more time for
shorter MTU to achieve the maximum link speed.
ETSI
48
ETSI TR 102 768 V1.1.1 (2009-04)
According to these results, proactive retransmission provides a clear advantage compared to the classical TCP.
However, to further improve the performance of the scheme when long outages are experienced some cross-layer
optimization is required. In fact, the efficiency of the Proactive retransmission can vanish in presence of long fading
events due to the fact that TCP retransmission timers will expire and trigger retransmission at the TCP layer. This will
trigger the congestion avoidance mechanisms which will reduce the throughput and hence the recovery when the outage
is over. An improved Proactive scheme can thus also envisage the freezing of the TCP retransmission timer to avoid the
kick-off of the congestion avoidance mechanisms.
6.3.2
Link Layer FEC protection in the return link
In continuous carrier mode, Link layer FEC can be used to counteract the effects of signal fading according to the
provisions described in [i.1]. Appropriate tailoring of the LL-FEC parameters is required to match the return link
symbol rate and channel dynamics.
6.3.3
Protection of signalling in the return link
No specific countermeasures have been adopted for the protection of signalling. As a general rule, the adoption of a link
margin of the same magnitude as the Rice channel amplitude variations is recommended in order to protect the
signalling (CSC, ACQ, SYNC) from the losses due to these Rice channel variations both on the forward and on the
return path.
QoS requirements for signalling are presented in clause 10.2.
7
Synchronization procedures
7.1
Logon in the presence of a large timing uncertainty
A procedure that allows log-on in the presence of a large initial timing uncertainty, in a completely backwards
compatible manner, is explained in clause 6.1. It should be noted that the method may have applicability beyond mobile
systems; e.g. to simplify terminal installation.
7.2
Logoff procedure
Loss of a number of consecutive CMTs is considered a failure of the synchronisation maintenance procedure and causes
the RCST to log off. A typical setting for fixed systems is to log the RCST off after three consecutive losses. The
number is primarily determined by the tolerable time and frequency drifts, which are corrected by the messages
contained in the TIM. For mobile systems, a suitable number of allowed losses before log-off is determined by the
equipment stability and factors such as the maximum terminal speed, which in turn determines Doppler shift and timing
drift rate.
8
Control and management
8.1
Control and monitoring functions for mobile terminals
The primary purpose of which Control and Monitoring functions (CMF) is to ensure that there is no harmful
interference to other MSS terminals or other services. Such interference could arise from either equipment malfunction
or from MSS terminal operation in proximity to other services with which it shares the spectrum allocation on
secondary basis in the Ku band, and both secondary and primary basis in the Ka band, depending on the radio region.
The mobile architectures and proposed methods to perform the required control and monitoring functions is described
in this guidelines clause. As background, this clause begins with a review of the interference scenarios from which the
requirement for CMF arises.
ETSI
49
8.1.1
ETSI TR 102 768 V1.1.1 (2009-04)
Interference Scenarios
The interference scenarios for the broadband MSS stems from the regulatory environment established by the ITU-R, in
particular for the Aeronautical Mobile Satellite Service (AMSS) [i.23]. Based on these regulatory requirements, the
resulting interference scenarios can be grouped into two general categories:
•
interference to FSS services, including VSATs;
•
interference to other services, including terrestrial fixed service (FS) and specialized scientific services.
The key proviso of these satellite mobile broadband services, especially for Ku band, is that they operate on a strictly
non-interference basis, secondary to FSS as well as all other primary or secondary services in the particular frequency
segment. For the aeronautical mobile satellite service in particular, ITU-R recommendation M.1643 [i.23] specifically
requires the use of interference mitigation measures including continuous monitoring and control by a Network Control
and monitoring facility, as well as mobile terminal self-monitoring, to prevent any harmful interference.
8.1.1.1
FSS Interference Environment
Sharing of the FSS spectrum on a secondary basis effectively places the equivalent requirement of fixed VSAT
terminals onto the mobile terminals; namely to operate within the off-axis EIRP density limits which in turn impacts on
antenna pointing and sidelobe performance. In general, the recommendations are based on 3° adjacent satellite spacing
for Europe and Asia and 2° for North America, although the interference levels are ultimately determined on a case by
case basis as part of the coordination process. For Ka band, the reference spacing is universally set at 2°. The applicable
FSS off-axis emission limits are specified by the ETSI mobile standards for 3° spacing [i.19], [i.20], [i.21] and [i.22] the
ITU-R FSS recommendations for 2° and 3° orbit spacing [i.24], and the FCC CFR Title 47 part 25 [i.25].
In general, spectrum sharing for the service-link involves the return path uplink and forward path downlink. The
geometry of the FSS interference scenarios is illustrated in figure 23, using an aeronautical terminal (Aeronautical Earth
Station, AES) for the mobile. However, this geometry applies equally to other types of mobiles.
W a n te d S a te llite
A d ja c e n t S a t e llit e
AES
In t e rf e rin g
S ig n a l
φ
AES
F S S u p lin k
in te rfe r e n c e
A d ja c e n t S a te llite
φ
FSS
d o w n lin k
In t e rf e re n c e
φ
ϕ
F S S [V s a t] T e r m in a ls
Figure 23: Mobile FSS interference Geometry
The uplink interference paths include the mutual off-axis emissions from the mobile and VSAT terminals into each
others' satellites. Since licensed fixed VSAT type terminals comply with the FSS off-axis emission limits, there will not
be any harmful interference into the mobile satellite. However, the use of mobile terminals with compact asymmetrical
apertures can result in harmful off-axis interference into the adjacent satellites, depending on the effective size of the
mobile transmitting aperture parallel to the geostationary arc. This is due to reduced sidelobe discrimination and to the
accuracy of antenna tracking and pointing.
On the downlink, the mobile terminal is susceptible to the interference from the adjacent satellite into the mobile
terminal, mainly due to the reduced sidelobe discrimination of the receiving mobile antenna aperture.
ETSI
50
ETSI TR 102 768 V1.1.1 (2009-04)
In order to mitigate the occurrence of harmful interference, the use of interference mitigation techniques are required to
reduce both the EIRP density and the interference susceptibility. One such technique is spectrum spreading. This is the
primary reason for the inclusion of this technique in EN 301 790 [i.1].
In order to prevent the occurrence of harmful interference due to the mobile return path uplink, even with interference
mitigation measures, a Network Control Center (NCC) continuously monitors and controls the operation of the mobile
terminals as described in clause 8.1.2.
8.1.1.2
Terrestrial and Scientific Interference Environment
The other category of interference scenarios involves the sharing by MSS with the other services, particularly in Ku
band, on a secondary or co-primary basis. The rules are particularly strict for the aeronautical mobile satellite service
(AMSS). All other services sharing the FSS allocation are protected, including Fixed Service (FS), Radio Astronomy
Service (RAS) and Space Research Service (SRS), as identified in [i.23]. These services - in particular the scientific
services - have strict Power Flux Density (PFD) limits. These services are not present in the Ka-band FSS segment.
The results of previous studies of these scenarios reveal that significant additional isolation is required to avoid harmful
interference into these other services from an MSS terminal operating in proximity to their stations. This is particularly
the case for aeronautical mobiles - even for aircrafts at cruising altitude. However, a key mitigating factor in these
interference scenarios is the fact that these other services are localized geographically. Moreover, in cases of RAS and
SRS, they are even limited to specific frequencies at specific time intervals.
Based on the previous studies, it is concluded that the most effective method of avoiding harmful interference is by
defining an exclusion zone around the stations of these services. Within the exclusion zones, all transmissions will cease
or - if possible - switch to other frequencies sufficiently separated from the frequencies used by these other services.
Note that the RAS interference scenario is not co-channel; and hence, using another frequency may not be sufficient.
The change in frequency can be augmented by a reduction in power. However, this will result in a reduction in
supported data rates. The signalling adopted in EN 301 790 [i.1] however allows for all these possibilities.
Obviously, another approach is to avoid the exclusion zones altogether if it is possible for the mobile terminal to alter its
path accordingly. Since the routes for many mobile systems are predetermined (such as railways and air traffic flight
paths), this may not in general be an effective measure.
8.1.2
CMF and Interference Mitigation Techniques
The reference architecture of the mobile satellite system consists of individual satellite sub-networks forming a global
network as illustrated in figure 24 for a two-satellite network.
Figure 24: Reference Global Mobile Architecture (2 satellites)
Figure 24 illustrates the different types of satellite sub-networks, including Sat1 with multi-beam coverage and two hub
stations, while Sat 2 has a single beam and one hub station. Each satellite sub-network includes its own hub stations that
perform the traffic gateway and network control functions. As for fixed DVB-RCS networks, the network control
functions are performed by an NCC (Network Control Center) or NCF (Network Control Facility) and include network
synchronisation, dynamic bandwidth allocation and the minimum control and monitoring functions as required for fixed
terminals. In particular, this includes the monitoring and control of the transmit power of the satellite terminal.
ETSI
51
ETSI TR 102 768 V1.1.1 (2009-04)
For mobile satellite networks, the CMF will need to be enhanced to be more dynamic and monitor the terminal
movement with respect to:
•
the satellite (antenna pointing);
•
the satellite beam coverage;
•
the location of the stations of the other services that need to be protected.
As described below, the baseline is to perform the control and monitoring functions in a distributed architecture which
includes the Network Control Facility and a CMF agent resident in the mobile terminal.
8.1.2.1
Antenna Pointing and EIRP
The antenna system of mobile terminals need to accommodate the movement of the mobile platform and maintain
pointing to the satellite within a given pointing accuracy. This tracking of the satellite is required to ensure that the
depointing losses are limited for the wanted link and to prevent excessive off-axis EIRP toward an adjacent FSS
satellite. The antenna positioning mechanism can either report its orientation continuously to the NCF, or it can keep
track of it locally and report any excessive pointing deviations and corrective actions taken locally.
In order to mitigate potentially harmful interference due to off-axis emissions into adjacent satellites, an interference
mitigation technique may need to be used in mobile DVB-RCS. The amount of mitigation will in general depend on a
number of factors, including: the terminal effective aperture size and on-axis EIRP, antenna pointing accuracy, the
orbital spacing and occupancy of other satellites adjacent to the broadband mobile satellite.
The NCC may need to control this amount of mitigation, so that the terminal transmission does not exceed the
prescribed mask for the off-axis EIRP density level toward the adjacent satellites. For a given antenna pointing error
and terminal aperture antenna pattern, the off-axis EIRP density of the return link transmission for the entire range of
off-axis angles can be characterized by the on-axis EIRP density, and the antenna orientation. The NCF can calculate
the EIRP density by using the received power measurement in the SYNC burst for a given terminal. The NCC can
control the EIRP density by adjusting either the transmit power level or mitigation level, such as the spreading factor, or
both.
The baseline approach is for the local control of antenna pointing and status monitoring by the NCF agent in the
terminal, coupled with the NCC monitoring of terminal transmit EIRP of received (SYNC) bursts. A polling/reporting
mechanism for transmission power and antenna pointing is included in EN 301 790 [i.1] to support this function. The
reporting mechanism uses the Mobility Control Descriptor in the TIM for queries and the Mobility Control Message in
the SAC field for reporting.
8.1.2.2
Exclusion Zones
The stations of the other services that share the Ku FSS band include the fixed service in Regions 1 and 3, and earth
stations for the Radio Astronomy Service (RAS) and Space Research Service (SRS). The locations of these stations are
known. In order to prevent interference to these stations, a contour is determined that enclose their locations and
establishes the minimum range required to ensure that the received PFD of the interference signal from the mobile
terminals does not exceed the prescribed limits. One possible approach is to define a reference contour for a reference
mobile terminal, and then, adjust the size of this contour according to the actual EIRP density mask of the mobile
terminal. However derived, this contour defines an "exclusion zone" around the station within which some form of
mitigation is necessary.
The control of transmissions involving exclusion zones is part of an overall control and monitoring facility (CMF),
including a centralized portion of the NCC but also supported by a semi-autonomous NCF agent in the terminals. A key
element of the CMF is the monitoring of the terminal location with respect to the exclusion zones, by the NCC in
conjunction with the NCF agent.
Since DVB-RCS terminals maintain a periodic synchronisation loop also used for "stay alive" signalling and terminal
status of health even for a fixed installation, the cessation of transmission in an exclusion zone may require the
complete shutdown of the terminal transmissions, thereby preventing the terminal from reporting its position to the
NCC while in the exclusion zone.
The baseline CMF technique uses position based detection involving the NCC and NCF agent in the mobile terminal. It
should be noted that EN 301 790 [i.1] does not exclude other methods, as long as these can be implemented using the
signalling that is mandated by EN 301 790 [i.1].
ETSI
52
ETSI TR 102 768 V1.1.1 (2009-04)
Position based detection relies on the measurement of the position of the mobile terminal (based on GPS/Galileo and/or
the navigational system of the mobile platform) and on the real-time knowledge of the service area, including the beam
coverage and the exclusion zones.
Position measurements take place in the terminal. A number of implementation alternatives are possible regarding the
detection process. A completely centralized implementation would require that the terminals send regular position
reports; with all the necessary processing located at the NCC.
A distributed approach is the baseline, since this provides the best compromise between the processing requirements
and the signalling overhead. The processing is distributed across the mobile terminals, while the signalling is reduced to
the signalling of the exclusion zone event. This arrangement is additionally justified by the fact that a terminal that has
been forced to terminate transmission when entering an exclusion zone will need some form of autonomous means of
determining when it is leaving the exclusion zone and can resume transmissions. We anticipate that this will be
implemented by carrying a database of exclusion zones in the terminal and perform entry/exit detection based on
position information that is available at the terminal.
The resources required for storage and maintenance of exclusion zone definitions in the terminal have been investigated
and are considered consistent with current technology and existing standard protocols for software updates (for example
using SatLabs Harmonized Management and Control recommendations).
8.1.2.3
Fault Detection
The requirements for fault detection and remedial action in mobile terminals are essentially the same as for fixed VSAT
systems. DVB-RCS already implements mechanisms and a terminal state diagram that comply with the relevant
regulations. Aside from the special interference mitigation mechanisms discussed above, we do therefore not anticipate
any need for special mechanisms to support these functions.
8.2
Handover in Mobile Systems
8.2.1
Reference Network
Figure 25 illustrates all mobility handover scenarios, including beam, gateway and satellite handover. Satellite handover
always entails beam and gateway handover. Gateway handover always entails beam handover, but can take place within
the same satellite delivery network.
SAT1
SAT2
GW1/
NCC1
GW2/
NCC2
Beam handover
Gateway handover
GW3/
NCC3
Satellite handover
RCST
Beam1
Beam2
Beam3
Figure 25: Handover Scenarios
ETSI
Beam4
53
8.2.2
ETSI TR 102 768 V1.1.1 (2009-04)
Beam Handover in Mobile Systems
Beam handover (HO) is the most common handover scenario, as part of the RCST mobility handover. Other scenarios
may include gateway handover, satellite handover and handover to a terrestrial network (gapfiller). Gateway and
satellite handovers are always entailing beam handover. They also entail network mobility handling aspects, e.g. routing
of traffic between gateways; these aspects are not relevant to beam handover and therefore not considered in this clause.
Beam handover is the preferred technique for mobility management in the case of Line of Sight (LOS) environment
specific to aeronautical applications, and also applicable in some cases to maritime applications and even to land
applications. Nevertheless it can also be used in the case of non-LOS environment. However, in non-LOS environment
mobility management would typically also include countermeasure techniques intended to combat the mobile channel
impairments, while the RCST remains within the same beam.
This clause concentrates on beam handover in LOS environment, but some of the proposed technical solutions will also
be applicable to the non-LOS environment. The clause provides background information and an example of a possible
implementation of the beam handover. It includes details on various aspects of the beam handover management, such as
handover detection/decision, handover execution; event synchronisation and the associated signalling.
For the purpose of the discussion in this clause, the term "area" is used to refer to a segment of return link capacity that
is managed by the NCC as a single entity, such that time slots within one area are equivalent. An area is thus in general
a subset of the return link bandwidth in one beam or of one transponder in one beam.
Also for the purpose of this clause, it is assumed that in general the NCC (integrated with the Gateway and also referred
to as Hub) includes a Forward Link SubSystem (FLSS), a Return Link SubSystem (FLSS), an IP SubSystem (IPSS) and
a Network Management System (NMS); their implementation is system specific and references to these subcomponents of the NCC are for illustration purposes only.
This clause concentrates on beam handover within the same interactive network. The interactive network is a
conventional regional multi-beam access network with a single Gateway (GW1), typically co-located / integrated with
the NCC (NCC1). Only two beams of this interactive network (carried by SAT1) are illustrated - Beam 1 and Beam 2.
Beam handover involves both forward path and return paths handover. Each path is associated with a transponder,
therefore beam handover is equivalent to a transponder handover and can ultimately be reduced to carrier switching
(forward path) / frequency band switching (return path). Note that Transponder handover can also take place within a
single beam, if the beam is equipped with multiple transponders (e.g. for different levels of protection against channel
impairments); this is not triggered by RCST motion across beams and is out of scope of the current discussion, though
the same mechanisms can be used to carry out an intra-beam transponder handover.
Recall that the operation in mobile environment sometimes requires bandwidth spreading of the forward link TDM
carriers and return link MF-TDMA carriers; this will have implications on RCST synchronisation. Each forward link
carrier is associated with either a MPEG2 transport stream (TS) or - in the case of DVB-S2 - one or several MPEG2
transport streams or generic streams (GSs) within the DVB-S2 multiplex.
A key feature of the beam handover is that the RCST remains attached to the same NCC as it moves from beam to beam
through the coverage area.
8.2.2.1
Handover Strategy
Beam handover involves the control and management of RCST handover from one beam to another, while trying to
preserve service continuity. The handover process includes:
•
Handover detection/recommendation.
•
Handover decision.
•
Handover execution.
•
Resource release / allocation associated with RCST handover.
•
Synchronisation of events taking place in RCST and NCC, and associated signalling.
The detection determines the need for the mobile RCST to be handed over and typically also determines a list of
handover beam candidates. It can take place in RCST or NCC and can be based on position measurements or link
quality measurements.
ETSI
54
ETSI TR 102 768 V1.1.1 (2009-04)
Handover decision is based primarily on the handover recommendation but also on considerations related to the higher
layers, in particular with regard to resource management, load balancing and QoS support. It consists of selecting the
target beam from the list of beam candidates and issuing the handover command. The handover decision is typically
implemented at the NCC, where all the relevant information can be easily made available.
Handover execution starts with the issuing of the handover command and consists of moving the RCST from a set of
resources in the current beam (which are released), to another set of resources allocated in the target beam. The
allocation of resources (physical, logical and bandwidth resources) relies on the forward link signalling (DVB-RCS FLS
service).
Handover execution implies the handover of forward link, return link or both. It is assumed that the Gateway is unique
in the interactive network and supports multiple forward links, at least one in each user beam. It is also assumed that the
return link resources in all user beams are controlled by the same NCC. The immediate consequence of these
assumptions is that the terminal remains attached during handover to the same Gateway/NCC (as point of access to the
satellite network).
Forward link handover entails switching the forward traffic and signalling from one transport stream / forward link
carrier to another (within the same Gateway). The streams can be of either DVB-S type or DVB-S2 type (CCM, VCM
or ACM - the DVB-S2 mode is not relevant as far as beam handover is concerned, since the handover always implies
carrier switching). With regard to DVB-S2, the forward link traffic can be carried in either MPEG2 TS format or
Generic Stream (GS) format.
Return link handover entails moving the RCST from one set of resources (scheduling area) to another, both under the
control of the same NCC.
The events taking place in NCC and RCST need to be tightly synchronized in order to attain a handover as seamless as
possible. Event synchronisation relies on return link and forward link DVB-RCS signalling.
8.2.2.2
Position Based Detection/Recommendation
Position based detection relies on the measurement of the position of the mobile RCST (based on GPS/Galileo and/or
the navigational system of the mobile platform) and on the real-time knowledge of the service area (beam coverage).
Though rather complex, it is a preferred detection approach and considered as baseline, since it eliminates the influence
of the propagation environment which affects the link quality based detection. However, the normative handover
process is independent of the criteria used to trigger the request.
Position measurements take place in the RCST. A number of implementation options are available regarding the
detection process. At one extreme, a centralized implementation requires that the RCSTs send regular position reports;
all processing being done at the NCC. At the other extreme, in a distributed implementation, the RCSTs themselves
perform the analysis of the position information and signal only their handover recommendation, together with a list of
beam candidates, to be used in the handover decision process (clause 8.2.2.4). A distributed approach is proposed as
baseline, since it provides the best compromise between the processing requirements and the signalling overhead. The
processing is being distributed across the mobile RCSTs, while the signalling is reduced to the handover
recommendation and the beam candidates. The fact that the coverage area (beam patterns) needs to be stored and
maintained (updated) in the RCST database is consistent with the current provisioning of storage resources in RCSTs
and the existing standard methods for software updates such as those provided by the SatLabs group. The SatLabs
Group is an international, not-for-profit association whose members are committed to bringing the deployment of the
DVB-RCS standard to large-scale adoption. SatLabs membership is comprised of service providers, satellite operators,
system integrators, terminal manufacturers and technology providers with an interest in DVB-RCS.
The key aspects / parameters associated with the position based detection include:
•
Position measurement (basic accuracy, rate of change, link margin allowance for handover, heading
information).
•
Geometrical considerations.
•
Detection algorithm.
•
Signalling of the handover information.
They are briefly reviewed in the following clauses.
ETSI
55
8.2.2.2.1
ETSI TR 102 768 V1.1.1 (2009-04)
Position Measurement
The primary parameter related to the position based detection is the accuracy with which the positions need to be
known. For a moving RCST, this is determined by the basic accuracy of the position fixes, as well as by the age of the
position reports: the older the report, the more the signal quality might have deteriorated.
Basic Accuracy
For a mobile RCST, assumed of professional or at least semi-professional quality, the assumption is made that
positioning information is available with an accuracy equivalent to that achievable with a civilian GPS receiver or, in
near-future, with a "Basic Service" Galileo receiver. For aircraft or ships, this information is likely to be available from
the vehicle's navigation system if not provided by sub-systems within the RCST itself.
Current typical GPS accuracies are of the order of 10m. However, an allowance of 200 m has been suggested in
previous studies for this component, to cover situation where the artificial degradation of the civilian GPS signal
("Selective Availability" - "SA") is re-introduced; this proved not to be a highly significant factor in the accuracy
budget.
A typical civilian GPS receiver is capable of producing a new position fix once per second.
Rate of Change
The worst-case antenna gain variation with position at the edge of a satellite beam is considered to be in the order of
0,068 dB/km. This is easily estimated by considering feasible beam sizes and main lobe roll-off patterns. The derivation
of this figure can be found in annex A.
Link Margin Allowance for Handovers
The link budget allowance for the handover process can be determined from the error budget constructed from RCST
characteristics and the handover time; a value of 10 s has conservatively been assumed for the latter parameter for
illustration purposes. The link budget allowance can then be used to derive the required position update interval; the
relationship is parametrically represented in figure 26 for four different classes of mobile RCSTs.
Allowed update interval, seconds
Maritime
Automotive
2
10
Train
Aeronautical
1
10
0
10
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
Link margin for handover, dB
0.8
0.9
1
Figure 26: Allowable position update interval as a function of link margin
For the illustration of the derivation process we consider the case of an aeronautical RCST. Given the worst-case gain
change for this RCST as it moves through the antenna coverage (0,02 dB/s, given roll-off rate and velocity), we need an
allowance of 0,2 dB when allowing 10 seconds for completion of the handover process. Considerations of the required
time are presented in clause 8.2.2.5.5. If new positions are available every 3 seconds, the maximum age of a position
report is 3+0,848+0,5 = 4,348 s, where 0,848 s is the assumed SYNC update interval and 0,5 s is the one-way
propagation/processing time. This gives a maximum change in gain of 0,082 dB.
ETSI
56
ETSI TR 102 768 V1.1.1 (2009-04)
Since the position accuracy of 200 m corresponds to an uncertainty of only 0,014 dB, the total required link margin
allowance for the handover process is dominated by the handover processing itself, and is equal to
(0,2 + 0,082 + 0,014) ~0,3 dB for the assumed example.
As shown in figure 26, a link margin of 0,3 dB requires position updates every 3 seconds for aeronautical RCST (as
calculated above), every 38 seconds for train RCSTs, every 63 seconds for cars and every 138 seconds for ships. These
figures include allowances for accuracy; therefore, there is no need for averaging or prediction in-between position
updates.
Other Supporting Information
As will be discussed in clause 8.2.2.2.2, the mobile heading information is desirable in order to facilitate certain aspects
of the handover detection/decision. In a distributed approach, the heading information is typically available directly
from the navigation equipment.
It is possible to add increased sophistication to the handover recommendation by including consideration of any other
available relevant information, such as for example programmed trajectories (flight plans) or known constraints
(railway line trajectories). Such sophistication may improve performance but should not create interoperability issues.
They are therefore left to the implementers of RCSTs and/or systems.
8.2.2.2.2
Geometrical Considerations
The previous clauses have demonstrated that a position-based handover algorithm is feasible from the point of view of
position measurement. This clause provides considerations of the geometry involved, leading to the detailed definition
of a possible detection algorithm in the next clause.
A quasi-seamless handover between beams inherently assumes some overlap between their coverages, so that
transmission in the "destination" beam can begin before it becomes unreliable in the "source" beam. An example of
beam arrangement in a "triangular grid" is illustrated in figure 27. This arrangement is in some respects a worst case and
is selected for convenience only; the example algorithm presented below does not make any assumptions in this respect.
A
B
A
C
B
C
"Nominal" coverage
"Extended" coverage
Figure 27: Example spot beam arrangements
For fixed service, the beams are usually arranged as shown on the left of the figure; i.e. with the minimal overlap
possible, given the need for contiguous coverage with minimum number of beams and minimum inter-beam
interference. In general, handovers can be carried out while the RCST is in one of the lens-shaped overlap regions.
There are however "singularity" points where the edges of three beams coincide, and where there is no overlap.
For mobile service a "handover margin", as determined in the previous clause, is made available when the RCST is
located at the nominal edge of a beam, so that sufficient time is available to carry out the handover. This is equivalent to
defining an "extended coverage", as illustrated on the right of figure 27: All routes between the interior of the beams
pass through "handover regions" and there is even a small, near-triangular, region where handover to more than one
beam is possible.
ETSI
57
ETSI TR 102 768 V1.1.1 (2009-04)
The following considerations can be made in order to determine some basic rules for handovers:
•
No handover is necessary as long as the RCST is inside the nominal coverage of a beam.
•
A handover is necessary as soon as the RCST leaves this coverage area.
•
A handover is possible whenever the RCST is inside one of the overlap regions inside the "extended
coverage".
More specifically, the region in which a handover between two beams is possible is bounded by the extended coverage
of the current beam and by the nominal coverage of the candidate destination beam. An example is shown in figure 28;
handovers from the left (current) beam to the right (candidate) beam are possible when the RCST is in the hatched area.
Note that the area for the inverse handover (right to left, not shown) will be different.
Extended
Nominal
Nominal
Current
Beam
Candidate
Beam
Figure 28: Handover region
There are some special situations:
•
If the RCST leaves the nominal coverage of the beam without being in a handover region, it is possible that it
is leaving the system coverage and that service will be lost. This is unavoidable; however, the algorithm
should issue a warning so that the RCST can be logged off or other appropriate action taken.
•
There can be several candidate destination beams; i.e. the RCST can be inside more than one handover region
at a given time, the maximum number is likely 6 - as encountered in regular-grid beam patterns. In that case
the algorithm should determine the most appropriate candidate from a geometrical point of view; this should
be the beam in which the RCST can expect to remain for the longest period. If the trajectory of the RCST is
known (e.g. in the case of fast trains), the candidate beam can be selected based on this knowledge. Since in
general the trajectory is not known, the beam selection can be based on an extrapolation of the past trajectory
(i.e. prediction), so that the number of beam candidates can be reduced (e.g. to three). As a simple initial rule,
handover destination candidates could be ranked and ordered according to how closely the recent heading of
the RCST points towards a defined "centre" of each candidate beam.
•
Immediately following a successful handover, the RCST will typically be in the handover region of the new
beam, which would allow the RCST hand back to the beam it just left. This could give rise to repeated
back-and-forth handovers (especially for slow-moving RCSTs) known as "ping-pong effect", which is highly
undesirable. The effect can be avoided by not recommending handovers unless the RCST is outside the
nominal coverage area and by proper design of the handover detection algorithm.
•
If the RCST happens to be stationary, the algorithm should not recommend handovers. This situation is also
covered by the above rule (i.e. do not recommend handovers when inside the nominal coverage).
•
The uplink and downlink beams can be different. Separate coverage geometries should be considered in this
case and the detection algorithm should issue separate handover request/recommendation for the forward link
and return link. This is a special handover situation; while possible, it is not considered very likely.
ETSI
58
ETSI TR 102 768 V1.1.1 (2009-04)
In summary, an appropriate algorithm can take as input the current position and headings of the RCST, identification of
the current beam and the database that defines the system coverage configuration. From this, it can produce an ordered
list of candidate beams, with the following properties:
•
As long as the RCST is inside the nominal coverage of the current beam, the recommendation shall be to
remain there.
•
Other handover candidates shall be ordered according to the rules as described above.
•
If the RCST is outside the nominal coverage with no handover destination candidates available, a
loss-of-service warning shall be issued. With the chosen signalling format, this will take the form of a
handover request with no valid candidate destination beams.
8.2.2.2.3
Data Structures
In our purely position-based example, we assume that the RCST and NCC each have copies of a database which
describes the system coverage.
The fundamental unit of information in the database needed for the handover algorithm describes a beam. The
following information is needed:
•
An identifier (so that the algorithm can distinguish between the current and handover candidate beams).
•
A definition of the outline of the nominal coverage area, for example in the form of a sequence of polygon
vertices.
•
Definitions of handover regions. Each definition describes the handover region to one beam, and contains:
-
The identity of the candidate beam, including a "short-form" identifier which is used to minimize the
amount of signalling. This short-form identifier is unique only within the current beam.
-
The outline of the handover region, for example in the form of a sequence of polygon vertices. As
described in clause 8.2.2.2.2, this region should be bounded by the extended coverage of the current
beam and the nominal coverage of the candidate beam. Note that two or more handover regions may
overlap.
The database may, of course, contain additional information which can aid the detection and prioritisation of candidate
beams. This is system-specific.
Maintenance of the database is outside the scope of EN 301 790 [i.1]. It can for example be carried out via the software
update mechanisms defined for Harmonized Management and Control by the SatLabs group.
8.2.2.2.4
Signalling of Handover Recommendation
The baseline for the beam handover scenario is to use the MAC layer signalling defined in EN 301 790 [i.1]. For
gateway/satellite handover scenarios, which may involve additional network components outside the NCC/NCC
(e.g. a global NOC), higher-layer protocols such as SNMP might be more appropriate for the communication between
NCCs and NOC.
The beam handover request can be communicated in a very compact form, as defined in the Mobility_Control_Message
SAC field. It is recalled that the recommendation takes the form of a flag that defines the type of handover required
(forward link, return link or both), plus an ordered list of candidate beams (limited in number). The candidate beams
can be defined in terms of the handover region within the current beam. 4 bits are allowed for the encoding of each
candidate beam.
With the candidates encoded in this manner, the 4-bit field can convey up to three candidate beams. This is considered
adequate, assuming some form of trajectory prediction. The value "1111" represents an invalid value; it can be used as
filler when there is fewer than 3 candidates altogether.
If there are no candidate beams at all, a loss of service is likely imminent. In such situations, transmission of the
handover request should be accompanied by a logoff request.
ETSI
59
ETSI TR 102 768 V1.1.1 (2009-04)
For robustness, it is suggested to repeat the handover request / recommendation until a TIM message with the handover
command has been received. The handover (execution) algorithm must accept multiple handover requests from a RCST
without inducing system instability.
It should be noted that the Mobility_Control_message field will normally be located in the SAC field carried in SYNC
bursts. These typically have sufficient room for a message of this nature, so there is in practice no additional overhead
associated with this type of signalling for mobility management purposes.
8.2.2.3
Centralized Handover Detection
The baseline handover detection method described in clause 8.2.2.2 uses a distributed approach and only generates
handover requests when the RCST determines that this is necessary. EN 301 790 [i.1] however also allows a centralized
approach, in which the NCC can poll the position of the RCST using the Mobility Control Descriptor for the query and
the Mobility Control Message SAC field as the reply; and subsequently use this information to make handover
decisions. Support for both methods is mandated for all RCSTs with mobility support, so the use of either method,
alone or in combination with the other, is a system implementation decision.
8.2.2.4
Example Handover Decision
The handover decision is typically based primarily on the handover recommendation arising from physical layer
considerations, whether this is made in the RCST (clause 8.2.2.2) or in the NCC itself (clause 8.2.2.3). However, the
decision can also include considerations related to the overall management of network resources and of the RCST
during handover. From this latter point of view, the assumption is made that in general the beam handover entails both
forward link handover and return link handover; handing over only one of the links is a special case applicable to some
particular situations (e.g. broad area downlink beams).
The process described here is an illustrative example only; intended to demonstrate the feasibility of the proposed
approach and associated signalling. Details are system-dependent. In any case, the example includes descriptions of
elements that are outside the scope of the DVB-RCS standard, but assumed present in all practical implementations.
Once the handover recommendation has been made and before the decision is taken and the handover command sent to
the RCST, the decision algorithm typically performs a number of tasks associated with the higher layers, in particular
with regard to resource management and handover start timing. A preliminary list may include the following steps:
1)
Check if the handover recommendation applies to the forward link, or return link, or both.
2)
Check the availability of resources in the list of ranked beam candidates, in order to preserve the level of
service for the RCST (i.e. its users). This may require the invocation of a connection admission control (CAC)
function for the existing connection, which could use either the current service commitments to the
corresponding application(s) or the requirements configured in the current Service Level Agreement (SLA).
3)
If the beam candidates are served by multiple forward and/or return link transponders, select the transponder
(forward link and/or return link) based on the following considerations:
4)
5)
-
The characteristics of the carriers configured for the transponder match RCSTs characteristics.
-
Load balancing.
Select the target beam from the list of candidate beams matching RCSTs characteristics, based on the
following criteria (in their priority order):
-
Rank of the beam in the list.
-
Availability of resources.
-
Load balancing when multiple options are available.
-
The selected target beam should be the highest in rank with matching characteristics, best satisfying the
service requirements and possibly complying with the load balancing needs.
If resources are not fully available in the selected target beam in order to maintain the current service level,
advise the users/passengers about the service degradation. Update the affected service parameters in the
relevant network components.
ETSI
60
ETSI TR 102 768 V1.1.1 (2009-04)
As a result of the above steps, the decision algorithm will typically return a data structure including the identity of the
target beam and the associated resources in this beam (e.g. Beam ID, forward link transponder ID / forward link
frequency, return link transponder ID / Superframe ID / frequency offset), and possibly a service degradation warning
flag that indicates that the current level of service cannot be maintained.
6)
7)
Once the handover decision has been taken, delay the handover command until a certain event or combination
of events occurs; this is intended to reduce the handover time. Potential events may include:
-
The occurrence of the composition tables distribution in the current beam.
-
The occurrence of a SYNC assignment to the RCST being handed over.
Send the handover command to the RCST, together with the appropriate information for operation in the target
beam, by relaying on a unicast TIM.
The handover command is sent by using the Mobility Control Descriptor in the TIM, while the information relative to
the target beam can be included in various descriptors, also in the TIM.
The above steps are captured as part of the overall handover protocol. They should be carried out for each logged-on
RCST for which the handover has been recommended.
The above task description assumes an NCC implementation of the decision algorithm, consistent with a distributed
approach to handover detection/decision. The choice of a distributed approach appears as the preferred approach when
the signalling (volume and rates, protocol), storage and processing needs are analysed. Furthermore, it is suggested to
implement the decision algorithm in NMS, which is the natural component for the storage of beam coverage databases
and for the execution of the Connection Admission Control (CAC) for the target beam, triggered by the detection
algorithm.
8.2.2.5
Handover Execution
Handover execution starts with the issuing of the handover command and consists of moving the RCST from a set of
resources in the current beam to another (new) set of resources corresponding to the target beam. For the purpose of
analysis in this clause it is assumed that the beam handover entails both forward link handover and return link handover
at the same time, therefore the resources in the target beam refers, respectively, to a forward link transponder and a
return link transponder in that beam.
8.2.2.5.1
Key Architectural Features / Assumptions
The single most important aspect regarding the beam handover is that there is a unique IP point of attachment of the
mobile RCST to the satellite interactive network, which is the GW/NCC (Hub). There are two major consequences of
this:
•
The RCST remains under the control of the same GW/NCC.
•
All network mobility issues are resolved by configuring RCST specific routes within the GW/NCC.
Since the population of mobile RCSTs is expected to be rather small, one can assume that all RCSTs are managed (for
the purpose of return link resource allocation) by a unique RLSS. The RLSS will control the return link resources in all
beams / transponders and the resources corresponding to each transponder can be configured as one or more scheduling
areas.
With regard to the forward link, the gateway should include at least one forward link processing chain (at IP layer and
MAC layer) for each user beam or for each transponder in a user beam.
Since the RCST can log-on from any beam of the interactive network, it should be configured with a set of start-up
forward link transponders (carrying the NIT), one for each beam. The RCST will acquire first the forward link in the
beam in which it is located (via the conventional table linkage process), and then it will acquire the return link burst
synchronisation. The NMS in the NCC can derive the location of the RCST (i.e. the return link transponder/beam) from
the Superframe_ID - Beam_ID table in its database, using as entry the Superframe_ID of the acquired return link.
Beyond these particularities, the logon and logoff processes are as in standard operation; it is noted, however, that the
logoff could be triggered by the RCST mobility, e.g. in case where no valid target beam has been identified.
ETSI
61
8.2.2.5.2
ETSI TR 102 768 V1.1.1 (2009-04)
Overall Handover Procedure
The beam handover involves a number of processes which take place in NCC and RCST. They are captured in flow
chart form in figure 29, which also includes the handover detection/decision processes. The flow chart reflects the
distributed approach suggested for detection/decision, with the (position based) handover detection implemented in
RCST and the handover decision implemented in NCC. This implies that the handover recommendation is signalled by
RCST to the NCC. After the handover decision has been made, the NCC initiates the handover of traffic and signalling
in Gateway and informs the RCST about the physical and logical resources to be used in the target beam. The RCST
responds by re-tuning its transmitter and receiver to the carriers in the new beam. During RCST re-tuning, the traffic
and signalling to/from RCST are discontinued. Signalling discontinuity will affect RCST frequency and burst timing
synchronisation and may trigger an RCST logoff, unless the synchronisation scheme is upgraded to accommodate the
discontinuity in PCR and the Doppler effects induced by RCST motion. Once the synchronisation in the new beam has
been achieved, the transmission/reception of the forward and return traffic and signalling can resume.
Start :
RCST
approaching
beam edge
Terminal executes the
detection algorithm and sends
the handover
recommendation to NCC /
Gateway
NCC /Gateway makes the
handover decision
NCC /Gateway initiates the
handover of traffic &
signalling in NCC /Gateway
NCC /Gateway sends the HO
command to terminal (with
information about resources
to be used in the new beam )
Terminal retunes and
acquires FL and RL
synchronisation in new beam
NCC /Gateway completes the
handover (RLSS , FLSS )
Terminal completes the
handover and starts using
resources in new beam
End :
Gateway &
Terminal resume
traffic in the new
beam
Figure 29: Overall Beam Handover Protocol
ETSI
62
ETSI TR 102 768 V1.1.1 (2009-04)
The beam/transponder handover entails the handover of both forward link and return link, which translates into forward
link carrier and return link MF-TDMA carrier group switching. Since forward link and return link handover are done in
parallel, there will be interactions/dependencies between the two processes, primarily at the physical layer but also at
MAC and upper layers. These interactions will be considered after reviewing the key aspects associated with the
forward link handover and return link handover.
8.2.2.5.3
Forward Link Handover
For illustration purposes the MPEG2 TS format is assumed in the discussion below.
Forward link handover consists primarily of switching the forward link traffic and signalling from one TS/carrier to
another. This will have a number of implications on the system operation:
•
The acquisition by the RCST of the new carrier/TS on which FLS service is distributed.
•
The acquisition consists of the re-tuning of the RCST receiver to the new forward link carrier and the
extraction of the FLS service (i.e. the DVB-RCS tables).
•
The carrier frequency (associated with a forward link transponder, uniquely identified in the interactive
network) is conveyed via a unicast TIM in the Satellite Forward Link Descriptor, which also includes the
identity of the new beam.
•
The extraction of the DVB-RCS tables relies on PID filtering of TS packets. A number of options have been
identified for conveying to RCST the signalling PID values for the new beam, namely the use of
RMT/PAT/PMT standard mechanism, the use of the Network Layer Information descriptor in TIM and the
configuration at logon time of the signalling PID values for all beams. Options 2 and 3 are faster than option 1,
therefore they are both good candidates; selecting one over the other will finally depend on implementer's
preferences. Regardless of the option used, the new PID values can be used as soon as the RCST has
synchronized to the new forward link.
•
Changes to the traffic PID values (if applicable, depending on traffic and signalling handling in Gateway at
handover time).
•
Traffic PID values can be changed, if needed, via the Forward Interaction Path descriptor in the TIM.
•
Whenever possible, it is desirable to maintain the same traffic PID values on all TSs in all beams. However, if
the PID values are used for local routing in Gateway (depending on the routing option), this might no be
possible unless the PIDs are re-stamped after routing.
•
All PID values used in the system for either traffic or signalling should be consistent with the system PID plan.
•
Buffering the traffic for the duration of handover (optional, depending on application/service).
•
Re-routing (within Gateway) of forward traffic and signalling from the current TS/beam to the target TS/beam.
•
Traffic re-routing can take place at either network layer or MAC layer. Both can be achieved with minimum
impact on traffic continuity. The choice of one option over the other is largely a system implementer's
decision.
8.2.2.5.4
Return Link Handover
Return link handover consists primarily of changing the MF-TDMA carrier group the RCST is authorized to use in the
target beam. This will have the following implications on the system operation:
•
Re-tuning of the RCST transmitter to the new MF-TDMA carriers.
•
The new MF-TDMA carrier group is associated with the Superframe_ID corresponding to the return link
transponder in the new beam. The RCST is notified about the new Superframe_ID and the corresponding
frequencies prior to the handover, via the Satellite Return Link Descriptor conveyed in a unicast TIM.
•
After re-tuning, the RCST will also need to acquire the return link synchronisation, which requires prior
establishment of the forward link signalling in the new beam (see clause 8.2.2.5.3).
ETSI
63
ETSI TR 102 768 V1.1.1 (2009-04)
•
Changes to the frame organisation to match the new Superframe_ID, i.e. the SCT, FCT and TCT, collectively
referred to as (static) Burst Time Plan (BTP).
•
A number of options are available, including static configuration in the RCSTs database of all composition
tables for all beams, downloading at the handover time (after re-tuning to the new TS/carrier) or distribution of
all BTPs in the system on all TSs:
-
Option 1, at one extreme, is storage intensive but fast (in terms of impact on the handover time).
-
Option 2, at the other extreme, will have minimum storage requirements but will increase the handover
time, since the BTP can only be downloaded after the RCST has been advised about the target beam (via
the TIM carrying the HO command) and has acquired the TS/carrier in that beam; the handover time may
be further degraded since the BTP is typically distributed every 10 seconds.
-
In the Option 3, the RCST can download the BTPs for the beam candidates (e.g. three beams) prior to the
start of the handover process, i.e. while still operating in the current beam.
-
Option 4 is derived from option 3, in this case, the transmission of the unicast TIM is synchronized with
the BTP distribution, i.e. the TIM is transmitted in advance, in order to allow the RCST to extract the
superframe ID for the target beam and to download from the SCT directly the section relevant to the
target beam.
•
Option 4 is seen as the best trade-off between storage and timing performance, therefore it is suggested as
baseline. Its potential for enhancing the timing performance at reduced storage exceeds the disadvantage of the
small increase in signalling overhead. The RCST will be required to store temporarily only two sets of
composition tables and it should start using the new tables and the new transmit parameters from a superframe
count associated with a well defined event (see clause 8.2.2.5.5). It should be noted that some margin should
be allowed in the synchronisation of events to account for possible uncertainties in the distribution of the
composition tables.
•
Assignment of SYNC slots and ACQ slots (if needed) in the new frame organisation, via the SYNC Assign
Descriptor and ACQ Assign Descriptor, respectively.
•
Changes to the Group ID and possibly Logon ID. These changes can also be carried via the TIM, in the Logon
Initialize descriptor.
Handing over the RCST from one beam to another requires the de-registration of the RCST from one set of return link
resources (MF-TDMA carriers) in the current beam and registration to an equivalent set of resources in the target beam,
i.e. from one scheduling area to another, with subsequent modifications to SYNC slot assignment, Group_ID,
Logon_ID, TBTP and CMT tables. It also requires moving the RCST attributes table from one scheduling segment/area
to another. The situation is illustrated in figure 30 for the case where both areas are managed by the same NCC.
ETSI
64
ETSI TR 102 768 V1.1.1 (2009-04)
Figure 30: Return link handover environment: single scheduler
The boxes in the figure with bold outline represent the mobile RCST-specific entities (the RCST itself and its attributes
table at the Scheduler). The left-hand side of the diagram corresponds to the situation before handover (current
area/beam), while the right-hand side is the new configuration after handover (target area/beam). The handover itself
requires the new dashed connections to be established, while the corresponding mirror-image solid lines are released.
Various linkages in the RLSS / DAMA Scheduler need to be changed in a synchronous fashion to match the delayed
reaction of the RCST. For a short period of time the RCST will continue to receive assignments in the old area but will
make requests (IBR and OBR) for capacity that will be considered for scheduling in the new area. The requests are
temporarily stored in the request table in order to be transferred between areas; they are used to update the RCST
attributes table (i.e. the VBDC Queue, last RBDC request and possibly the CRA parameter).
Since the RCST remains under the control of the same RLSS / DAMA Scheduler, the handover does not typically entail
changes to the return traffic and signalling outside the RLSS (i.e. between physical modules) and can therefore be
completed almost seamlessly. However, discontinuity regarding return traffic handling will happen due to the
disruptions in the distribution of assignments (TBTP), resulting from the forward link handover. During the disruption
neither capacity requests nor return link traffic can be sent. Nevertheless, the traffic could be buffered in RCSTs and
released after the links are restored in the new beam.
8.2.2.5.5
Beam Handover: Event Synchronisation / Handover Signalling
The management of the beam handover process relies on DVB-RCS specific signalling, i.e. DVB-RCS
tables/descriptors on the forward link and ACQ/SYNC bursts on the return link. Of particular relevance in the unicast
TIM, used to carry the handover command to RCST. The TIM also includes (in various descriptors) all the information
required for the RCST operation in the target beam.
The majority of tables/descriptors are used as in standard operation, with regard to their distribution and timing.
However, some changes/optimisations of the signalling are required, in order in order to improve the handover timing
performance. They will be identified as part of the event synchronisation, aimed at minimizing the handover time.
ETSI
65
ETSI TR 102 768 V1.1.1 (2009-04)
An overview of the handover events is provided in flowchart form in figure 31. The detailed analysis of signalling /
event synchronisation is discussed in the following. The assumptions used in the analysis can be are summarized as
follows:
•
The beam handover implies both forward link handover and return link handover.
•
A beam can be provisioned with several transponders.
•
The gateway supports multiple forward link carriers and multiple MF-TDMA carrier groups, associated with
different forward link and return link transponders, respectively.
•
Traffic routing in gateway is performed without changing the RCST IP addresses, so that the network and
upper layer are not affected. The result of this is that any IPSec and/or RADIUS sessions remain open.
•
Each forward link carrier transports packets of one MPEG-2 Transport Stream (DVB-S) or of a DVB-S2
multiplex stream in either MPEG2 TS format or Generic Stream format.
•
The handover detection/recommendation takes place in the RCST, while the handover decision is taken by the
NCC, which also controls the overall handover process.
•
For event sequencing/synchronisation and for the assessment of the handover time, the starting point is
considered the moment when the handover decision is taken. Prior to this moment the NCC executes the
decision algorithm, aimed at determining the optimum start of the handover.
Flowchart of Handover Events
The flow chart in figure 31 summarizes in graphical form the main activities to be performed in NCC and RCST during
handover. The activities (events) in the NCC are staggered with respect to those occurring in the RCST, to suggest the
approximate sequencing.
ETSI
66
ETSI TR 102 768 V1.1.1 (2009-04)
Gateway
RCST
Handover start event
(approaching the beam edge)
Perform detection algorithm.
Send SYNC (old) with handover
recommendation
Perform decision algorithm
NO
Degrade
service level
Resources
available in new
beam ?
YES
Start of handover
process
Reserve resources in the new beam
(capacity and logical identifiers)
Send TIM in old beam
(with handover cmd, new TDM, SF_id,
Group_id, Logon_id, PIDs, SYNC)
Send new frame structure
(SCT, FCT, SCT)
Stop sending traffic & signalling to
RCST. Start bufferring FL traffic.
Release resources in old beam.
Prepare RCST switchover to new
TDM & RLSS
Receive handover cmd. Extract all
information for the new beam. Start
buffering RL traffic. Tune Rx to the new
TDM carrier and Tx to new MF-TDMA
carriers and acquire RL synchronisation.
Move the RCST and the attributes
table to new area. Send first TBTP for
new area. Start sending FL traffic in
new beam.
Extract the first TBTP for new area and
start sending RL traffic & IBR in new
beam.
Send SYNC in new SF/beam
Send the first CMT in new beam
Handover completed
RL+FL
handover
Figure 31: Flow chart for beam handover
Example Event Synchronisation, Signalling and Timing Analysis
A possible sequencing of events for the purpose of signalling and timing analysis is illustrated in figure 32. It depicts
the activities in RCST and NCC and the associated times (not necessarily drawn to scale).
The illustration in figure 32 applies to a particular implementation of a DVB-RCS system, characterized by short
superframe/frame duration (e.g. 26,5 ms) and a single frame per superframe. In such implementations, the superframe is
the elementary period for all timing processes and for the control of return link resources. The occurrence of various
events is expressed in terms of superframe counter values (in PCR counts). The assumption is made that all superframes
in the system have the same duration (regardless of the Superframe ID), so that the same superframe counter applies to
all. The superframe counter (modulo 65536) is included in the SCT, TBTP and SYNC Assignment descriptor, in order
to remove any ambiguity concerning the superframe to which the requests, assignments and SYNC bursts apply.
ETSI
67
ETSI TR 102 768 V1.1.1 (2009-04)
The sequencing of events / timing may be different for other implementations and may lead to different handover
timing performance. The timing analysis in this contribution will therefore be performed in terms of relations/equations
rather than in terms of specific values for various parameters, with the emphasis on the events/processes and the
corresponding signalling; consequently no timing performance figure will be assessed.
The event sequencing/synchronisation and the required signalling are generically defined in terms of "old" (for current)
and "new" (for target) beams/transponders and associated resources. The signalling is indicated in the figure as
annotations to the propagation paths.
delta
Superfr ame period
Tpd (fw d)
d5
me
nd
ati
on
)
am
an
dI
BR
be
ne
w
ra
ffic
in
AC
Q
ld
La
st
o
Extract & store BTP.
d6
T x_tuning
Rx_tuning
Start retuning Rx and Tx. Let LO
free run. Make current resources
in new beam (e.g. BTP).
Extract & store FL/RL phys para,
TDM_id/freq, SF _id/freq, ACQ/
SYNC assign, Group_id, Logon_id
..
ACQ_u
Rx tuned. RCST can extract
PCR packets from new TS
and slave again the LO
(o l
d)
(H
O
are
at
rec
om
be
am
old
in
HO
Handover
Command
w)
ne
P(
BT
be
for
e
tT
SY
NC
firs
La
st
,
Q)
AC
SY
NC
to
Re
gu
lar
e
ns
....
po
es
w)
ne
R( )
PC (new
R
PC
d3 d 4
M SL
S tart of the hando ver
(H O) process
w)
(ne
Mobility (FL+RL)
Tpd (fw d)
R
PC
H an dover
R ecom m endation
w)
ne
or
,f
old
(on
CT
/T
s)
tor
CT
/F
crip
CT
es
,S
,d
d)
nd
(ol
cm
O
TP
H
(
TB
TIM
d)
(ol
MT
Tpd (rtn )
D etec tion
T (r
CM
st
La
C
st
La
RCST
e
d2
GW
Fir
st n
Decision
d1
Move RCST to new segment/area
and start scheduling in new area.
Start sending FL traffic in new beam;
Empty buffer.
d0
Continue forwarding RL traffic.
Update the RCST attributes table
After last T BT P, stop sending traffic
and signalling to RCST in old
beam. Start buffering traffic.
Change GW configuration for FL
switchover.
Assign physical and logical
resources in the new beam
Check availability of resources
and select the target (new) beam.
Process last SYNC (old)
(Extract HO recommendation)
Regular SYNC (old) processing
The approach described in the sequel is conservative in the sense that it ensures that the RCST is completely
synchronized in the target beam before even resuming forward link transmissions. Optimisations may be possible in
some situations; for example, it may be advantageous to resume forward link transmissions before return link
synchronisation is completed. This can be particularly useful for real-time, non-acknowledged traffic such as VoIP,
which would in any case be discarded during the handover.
H andover
com plete
Figure 32: Event sequencing and synchronisation
Tpd(fwd) and Tpd(rtn) in figure 32 refer to the forward link propagation delay and return link propagation delays,
respectively. Various processing times in the NCC and RCST are designated by di and expressed in number of
superframes.
MSL in figure 32 stands for the Minimum Scheduling Latency - the minimum time elapsed from issuing a capacity
request in RCST until the RCST can dispatch traffic in the slots assigned in response to that request. The MSL thus
includes the propagation times on the forward link and return link and the processing times in RCST and RLSS.
Considering typical processing times:
MSL = Tpd(fwd) + Tpd (rtn) + processing time.
The handover is initiated by the handover recommendation sent by the RCST (in a SYNC burst). The NCC then
executes the decision algorithm (clause 8.2.2.4), in order to select the target beam from the list of candidate beams.
ETSI
SYNC_u
MSL
68
ETSI TR 102 768 V1.1.1 (2009-04)
The handover detection / decision time is labelled as d0 in figure 32 and can take values from a few superframes to a
few seconds, depending on the method used, velocity of the mobile RCST etc. The last SYNC, before the start of the
handover process, carrying the handover recommendation, is shown in figure 32 together with the corresponding CMT
carrying the results of power measurements and time / frequency errors. The time d1 represents the time to demodulate
a SYNC burst, to extract the handover recommendation, to perform return link channel measurements (part of the
routine operation) and to encapsulate the results in the format appropriate for inclusion in the CMT. SYNC processing
is done in the RLSS.
As a precaution, the handover recommendation could be repeated in subsequent SYNC bursts, until the TIM carrying
the handover command is received (see below).
Once the decision algorithm has selected a target beam, the handover process can be triggered. The start of the handover
process is in general not synchronized with the transmission of the last SYNC/CMT. The delay between the start of the
d1 interval and the start of the handover process can be as high as the SYNC repetition interval, if the handover process
were to start just prior to the arrival of the next SYNC in the old beam. This delay is not relevant; it is part of the
detection/decision time, which typically is not included in the handover time since the system is operational during
handover detection/decision. It may instead be beneficial to synchronize the start of the handover process (and the
subsequent issuing of the handover command) with the broadcast time of the composition tables in the old beam; the
benefit will be the availability when needed of the composition tables for the target beam. Alternatively, as mentioned
elsewhere, all composition tables could be distributed at the same time (same superframe count) in all beams.
The sequencing of events (activities) associated with the execution of the handover process is as follows:
1)
The Gateway assigns physical resources and logical resources (identifiers) to the RCST in the new (target)
beam (see step 2 below). This activity is associated with the delay d2 in figure 32 and is estimated at
1-2 superframes.
2)
The Gateway sends to the RCST the last unicast TIM in the old beam with the handover (HO) command and a
number of descriptors defining the changes to the forward link and return link associated with the handover.
The changes will apply to a future time (see below). The assumption is made that the RLSS can generate and
transmit a TIM in the current beam with information pertinent to the resources in the target beam. The
following descriptors are included in the TIM:
-
Mobility Control descriptor, carrying the handover command.
-
Network Layer Information (NLI) Descriptor, for changes to the signalling PID values (if needed,
depending on the PID addressing scheme). The management of signalling (and also traffic) PIDs should
be under the responsibility of the NMS. They are assigned during the d1 interval (i.e. before the TIM is
sent), as part of resource reservation following the resource availability check.
-
Satellite Forward Link Descriptor, containing the new beam ID and the physical characteristics
(frequency, polarisation, modulation/coding) of the new forward link carrier. The knowledge of beam
ID / forward link carrier frequency could be used to derive the new TS ID. During RCST re-tuning the
RCST cannot receive traffic and signalling on either the old or the new forward link carriers.
-
Satellite Return Link Descriptor, containing the new beam ID, new Superframe ID with the associated
TX Frequency Offset; the remaining descriptor parameters must not change.
-
The new Superframe ID is associated with a new frame structure, defined by the composition tables
(SCT, FCT, TCT) corresponding to the new beam/transponder.
-
SYNC Assign descriptor, which gives the location (i.e. slot number), frame and start superframe of a
new static SYNC assignment (applicable to the new frame structure), together with the repeat period.
This automatically cancels any existing static assignment, from the SYNC_start_superframe on. The
SYNC_start_superframe should point to a time posterior to the transmission time of the handover
command. This descriptor is not used when SYNCs are assigned dynamically (i.e. via TBTP).
-
ACQ Assign descriptor, which gives the location (i.e. slot number), frame and start superframe of a
temporarily assigned ACQ slot (applicable to the new frame structure), together with the number of
repeats and the repeat period. The ACQ_start_superframe should point to a time posterior to the
transmission time of the handover command. For the need and usage of ACQ assignment during beam
handover please refer to step 9).
-
Forward Interaction Path Descriptor, containing the traffic PID values.
ETSI
69
ETSI TR 102 768 V1.1.1 (2009-04)
-
The Forward Interaction Path Descriptor is only used if not all PID values for all TSs are stored in the
RCST database at logon time. The RCST should start using the new PID(s) as soon as its receiver is
re-tuned to the new carrier.
-
Logon Initialize descriptor, containing the new Group ID, Logon ID. There is no time associated with
these logical identifiers in the descriptor. In standard operation they are assigned at logon time and used
throughout the duration of the connection. When they are changed as a result of RCST handover, they
should be used in association with the new frame structure (new Superframe ID), starting from a given
event (see step 4)). The RCST will be required to handle multiple sets of logical identifiers (Superframe
ID, Group ID, Logon ID,) and switch transparently from the current one to the next one. The Group ID
will be used by the RLSS for grouping the RCST capacity assignments and correction messages in the
appropriate sections of the TBTP and CMT, respectively; RCST-specific information from the relevant
CMT section will then be extracted based on the Logon ID. The management of the Group ID, Logon ID
is under the responsibility of the RLSS. They are assigned during the d1 interval, just before the TIM is
sent. The RCST needs to store all parameters received via the TIM in its database, for use at various
moments during the handover process (see below).
3)
A few superframes after sending the last TIM in the old beam, the Gateway sends the last TBTP for the old
beam/area and the composition tables (SCT, FCT, TCT) with sections for all superframe IDs, including the
Superframe ID for the target beam. The RCST should be allowed the time (interval d3) to extract, from the
Satellite Return Link Descriptor in TIM, the Superframe ID for the target beam (as per step 5)), so it can
afterwards extract from the SCT/FCT/TCT (during d4 interval) the section relative to this Superframe ID and
store it temporarily in the RCST database (as per step 6)). This presumes that the transmission of the TIM
carrying the handover command and all other descriptors is synchronized with the broadcast time of the
composition tables in the old beam (i.e. it is sent d3 superframes in advance). The implicit assumption is that
the handover command can be delayed for up to 10 seconds (SCT typical periodicity) after the handover
recommendation, without compromising the quality of the links in the old beam.
4)
Immediately after the last broadcast of the composition tables and TBTP in the old beam, the Gateway stops
sending forward link signalling and traffic to the RCST in the old beam, prepares for the forward link and
return link switch-over and starts buffering the traffic to the RCST (optional). These activities are associated
with the interval delta, from the transmission of the last TBTP (old) until a few superframes before the
transmission of the first TBTP (new). The delta interval is rather large and includes the uncertainties
associated with RCST re-tuning and ACQ/SYNC assignments (see steps 8) and 9)). During this interval the
Gateway broadcasts in the usual manner all general DVB-RCS tables in the new beam, including the PCR
Insertion packets. The preparation for forward link traffic and signalling switchover to the new TS consists in
the reconfiguration (by the NMS) of the relevant components for routing the forward link traffic and signalling
to the new forward path, as follows:
-
Notifies the Buffering System to start buffering traffic with the RCST IP Address.
-
Changes the routing table in the Edge Router, to re-route RCST traffic to the Buffering System (for the
duration of the handover).
-
Removes the triplet IP/MAC/PID from the IP Encapsulator in the old forward path (FLSS) and
configures the triplet in the IP Encapsulator in the new forward path.
-
The PID values should be changed according to the PID plan. The changes may or may not need to be
signalled to the RCST, depending on the implementation. Nevertheless, the signalling PIDs need to be
known in the NCC, which should generate the DVB-RCS tables for all TSs with the appropriate PID
values.
ETSI
70
ETSI TR 102 768 V1.1.1 (2009-04)
All forward link changes within the Gateway associated with step 4 will typically take 2-3 superframes, well within
the delta interval. Traffic buffering should continue for the entire duration of delta. With regard to the return link,
after sending the last TBTP (old) the RLSS:
-
Continues to receive traffic and capacity requests to the old area/beam for another MSL interval (i.e.
until the reception of the last traffic burst for the old area), but stops scheduling in the old area. The
traffic is passed to the IP components as usual, while the requests are used to update the RCST attributes
table (i.e. the VBDC queue is updated, while the last RBDC request is updated;) these requests are
tagged with the Group ID and Logon ID corresponding to the old area but will be used for assignments
in the new area, therefore they need to be re-tagged. At the end of this interval, return link traffic and
signalling are discontinued for a period commensurate with the return link acquisition time (including
RCST TX re-tuning and coarse synchronisation - see below).
-
Prepares to move the RCST and its attributes table to the new area but does not start scheduling in the
new area until a well defined event/time (the end of delta interval, as signalled by the reception of the
first ACQ or SYNC burst in the new beam, see step 9)). The new area is laid over the new superframe
structure (static BTP). The preparations include the de-registration of the RCST from the old area and the
registration with the new area, with the new Group ID and Logon ID. They also include the transfer of
the RCST attributes table to the new area. All these activities can be completed in general in a few
superframes (interval d5), prior to the start of scheduling in the new area and the transmission of the first
assignments in the new TBTP/beam. With regard to the RCST attributes table, it is noted that while the
VBDC queue is updated as long as the VBDC requests continue to arrive (up to a certain limit, given by
the buffer size in the Scheduler), all RBDC requests received in the same interval but the last one will be
discarded. Moreover, there will be no requests during the return link re-tuning / synchronisation,
therefore the impact on return link traffic will be rather serious; it can be reduced to a certain extent by
traffic buffering in RCST.
5)
After receiving the TIM, the RCST extracts and stores temporarily in its database the information needed for
operation in the new beam on both forward link and return link; this includes the identity and physical
characteristics of the new forward link carrier (frequency, polarisation, modulation/coding) and of the new
superframe (Superframe ID, TX_frequency_offset), the new ACQ and SYNC assignments and the new RCST
logical identifiers (Group ID, Logon ID, PIDs). The extraction of this information takes 2-3 superframes (d3).
At this time the RCST is ready to start re-tuning its receiver, but this is delayed until the reception and
extraction of the last TBTP and the new frame structure (step 6)).
6)
After receiving the last TBTP (old) and the new SCT (and FCT, TCT), the RCST extracts from SCT the
section relative to the Superframe ID derived in the previous step and stores temporarily the composition
tables for the new beam in the RCST database. The extraction of this information takes 2 frames to 3 frames
(d4 interval). After this step the RCST shall stop sending SYNC bursts to the old area/beam.
7)
The RCST sends the last traffic and capacity requests (IBRs) for the old area/beam and starts buffering the
traffic in the RCST queues.
8)
After d4 superframes the RCST starts tuning its receiver and transmitter and prepares for the handover. More
specifically, the RCST:
-
Tunes its receiver to the new forward link carrier frequency extracted in step 5) from the Satellite
Forward Link Descriptor.
-
Tunes its transmitter to the new TX frequency, determined by the centre frequency of the new
MF-TDMA carrier group (extracted in step 6) from the SCT), adjusted by the TX_frequency_offset
obtained in step 5) from the Satellite Return Link Descriptor, in order to send traffic (and requests) for
the new area.
-
Since the knowledge of the centre frequency of the new MF-TDMA carrier group is a must for TX
re-tuning, transmitting the composition tables (for the new beam) in the old beam appears even more
beneficial: the TX re-tuning can start in parallel with RX re-tuning, so that the overall re-tuning time can
be reduced.
ETSI
71
ETSI TR 102 768 V1.1.1 (2009-04)
Both TX and RX tuning times are subject to uncertainties. Typical RX re-tuning time (including the spectrum
spreading code acquisition) is about the same as the typical TX re-tuning time, probably about 500 ms. However,
RX re-tuning may take longer (up to 1 s to 2 s, depending on the interference environment) than TX re-tuning,
which should never exceed 1 s (according to the requirements in the DVB-RCS standard). This is the situation
illustrated in figure 32, but the other situation can also happen.
The next step of the event synchronisation process can only be taken after completing both TX and RX re-tuning
(see step 9)), so the largest of the re-tuning times should be considered for the handover timing performance.
TX re-tuning time refers to the settling time of the transmit oscillator, i.e. the time needed to adjust the TX
frequency to the programmed value with a predefined tolerance. For burst transmission the RCST must also
achieve burst (timing) synchronisation (step 9)).
During TX re-tuning the RCST activates the composition tables and all other parameters associated with the new
beam.
9)
Once the receiver re-tuning and transmitter re-tuning have been completed, the RCST acquires the burst
(timing) synchronisation.:
-
Burst synchronisation relies on a closed loop involving PCR packets and CSC/ACQ/SYNC bursts and
CMT replies; this implies the existence of an operational forward link (in order to receive PCR Insertion
packets and CMTs) and a return link capable of transmitting return link signalling bursts. The PCR are
used for fine synchronisation of the local PCR clock, while the return link signalling bursts are used,
together with CMT, to track the variations in RCST-satellite range.
-
After achieving RX synchronisation, the RCST can start decoding the PCR Insertion packets and use the
global PCR to resynchronize (slave) its local PCR clock. A flag in the RCST data base is set after
achieving the required accuracy. The corresponding time is considered part of the TX_tuning time. The
RCST is now ready to transmit return link signalling bursts, in order to complete the burst
synchronisation.
-
Due to RCST movement it is possible that SYNC bursts, for which the guard times are rather small,
would fall outside the receive window in the RLSS; ACQ bursts, for which the guard time is larger,
could be used instead for coarse synchronisation. The need for ACQ bursts (temporarily assigned via the
TIM) will depend on the accuracy with which the effects of RCST movement are compensated. For a
generally applicable solution, it is considered safer and therefore suggested to use ACQ burst for time
synchronisation (as illustrated in figure 32); it is expected that one ACQ burst will be enough to bring the
system within the fine synchronisation range.
-
The accurate estimation of the return link synchronisation time is further complicated by the uncertainty
related to ACQ assignment (ACQ_u in figure 32) in the new frame organisation with regard to
start_superframe, frame_number and slot_number within the repeat_period. Since the
ACQ_start_superframe is difficult to anticipate (due to uncertainties in TX/RX tuning times), any time
after the start of re-tuning is possible. The uncertainty could therefore be as high as the repeat_period,
which should be equal or greater than MSL. Similar uncertainty is defined with respect to the SYNC
assignment (SYNC_u) (to be used in a future step). The SYNC_repeat_period is typically not smaller
than approximately one second; one can adopt the same value for the ACQ_repeat_period. The number
of ACQ_repeats in the ACQ Assignment Descriptor should be set large enough (e.g. 5 to 6) to account
for the largest re-tuning time (e.g. 1 s to 2 s) and to allow for multiple coarse synchronisation attempts, if
needed. Note that any ACQ slot assigned during the re-tuning interval will be wasted.
-
The RCST will get the CMT reply in response to the ACQ burst after MSL (which includes the
processing time d5), so that the total re-tuning / return link synchronisation time is given by:
Ts = max {TX_tuning, RX_tuning} + ACQ_uncertainty +MSL
One ACQ_repeat_period should be added for each supplementary ACQ burst, if more than one is
needed.
ETSI
72
ETSI TR 102 768 V1.1.1 (2009-04)
10) The Gateway transmits the first assignments to the RCST in the TBTP corresponding to the new area/beam, at
the end of delta interval (i.e. d5 superframes after the receipt of the ACQ burst), and also resumes the
transmission of forward link traffic (in the new beam). As already mentioned, during the d5 interval the
Gateway transfers the RCST to an area in the new beam, with new Group ID and Logon ID and new
assignment of SYNC space. In the same time the RCST attributes table is transferred to the new area. The
implicit assumption is that fine synchronisation has been achieved. The Gateway can derive the
synchronisation status from the results of measurements performed in the RLSS on the ACQ
(Burst_time_correction, to be included in the CMT) and the knowledge of the fine synchronisation threshold
(as defined/used in the coarse synchronisation procedure). The fine synchronisation threshold can be obtained
from the RCST database in Gateway (NMS). The Gateway may decide to include the first assignments to the
RCST in the new area/TBTP even if the Burst_time_correction is not within the fine synchronisation
threshold, but close enough so that it can be expected that the RCST will bring the burst time within the fine
synchronisation threshold before the transmission of TRF and/or SYNC bursts, by applying the
Burst_time_correction. If the Burst_time_ correction is judged to be too high, the Gateway may decide to
postpone the assignments in the new TBTP/beam, and the correction message will be used to trigger additional
ACQ bursts; this will automatically add one ACQ_repeat_period to the handover time for each transmitted
ACQ burst.
The above description refers to a somewhat unconventional NCC behaviour. If the synchronisation status is
not checked by the Gateway, the Gateway will typically wait for the first SYNC burst with the
fine_synchronisation_achieved flag set in the SAC field before including the first assignments in the TBTP for
the new area. This would add a substantial delay of (MSL + SYNC_uncertainty).
It is noted that the new area (and the corresponding TBTP) are new only with regard to the RCST being
handed-over to that area/beam. The TBTP was being transmitted since the activation of that area/beam; new is
the fact the handed-over RCST starts getting the assignments in this TBTP.
The resumption of the forward link traffic will start with the depletion of the Buffer System and the inclusion
of new traffic (especially of real time nature).
11) Upon the receipt of the first TBTP and after the processing delay d6 (2 to 3 superframes), the RCST sends the
first traffic bursts (and IBRs) for the new area.
With the transmission of the first packets in the assignments provided by the TBTP for the new area/beam the
handover process itself is completed.
12) After the reception and processing of the CMT (generated in response to the ACQ burst) the RCST will start
sending SYNC bursts for fine synchronisation maintenance. The first SYNC is sent after SYNC_uncertainty,
which can be as high as SYNC_repeat_period.
This step is needed in order to check that the RCST has not been deprived of SYNC burst / CMT replies for
longer than tolerated by the RCST synchronisation scheme.
Based on the above analysis, the handover time (i.e. the interval during which the forward link and/or return link traffic
are discontinued) is given by:
T_HO = d4 + Max {TX_tuning, RX_tuning} + ACQ_ uncertainty + MSL + d6
Typically, best and worst-case values can be derived based on the typical values/ranges of the parameters in this
equation.
If the Gateway only sends the first TBTP after receiving a SYNC with the fine_sync_achieved flag set (which is
recommended for system operational robustness), an additional term (SYNC_repeat_period + MSL) should be included
in T_HO. The timing performance will be further degraded if the return link synchronisation cannot be achieved with
only one ACQ burst / CMT reply.
ETSI
73
ETSI TR 102 768 V1.1.1 (2009-04)
In summary, the beam handover cannot be seamless in the described scenario, where the RCST is assumed to have only
one transmitter and one receiver. The handover time is primarily determined by the RCSTs re-tuning time and return
link fine synchronisation time and takes a few seconds. During this time some packets can be lost (even with buffering)
or delayed. This will have impact in particular on real-time applications, but may be less noticeable for non-real time
applications relying on best-effort service. Buffering does not make much sense for delay/jitter-sensitive applications;
since the off-time is rather high, it is difficult if not impossible to compensate for the delay introduced by buffering,
therefore it is felt that the real time traffic should not be buffered at all (but discarded) and the Buffer System is
considered optional. As mentioned above, it may be possible to reduce the handover duration for real-time traffic that
would be discarded in any case, at least in the forward link.
One way to circumvent the inconveniences resulting from a handover is to advice the users (passengers) of the
imminence of the handover, so that they can refrain momentarily from being engaged in real time sessions; this can be
achieved via some broadcast messages from the mobile platform controller.
8.3
Gateway Handover in Mobile satellite systems
Figure 33 shows the scenario for gateway handover. It is considered that the source gateway and the target gateway are
associated with the same NCC and with the same satellite. A gateway handover always entails a beam handover, so the
beam handover procedure is tightly integrated and synchronized with the gateway handover.
Gateway Handover
Satellite
NCC
RCST
Source Scheduling Area
Target Scheduling Area
Target Gateway
Source Gateway
Figure 33: Gateway Handover scenario
The flow chart of a gateway handover procedure is shown in figure 34. The following clauses explain the whole
handover procedure.
ETSI
74
Figure 34: Gateway Handover procedure
ETSI
ETSI TR 102 768 V1.1.1 (2009-04)
75
8.3.1
ETSI TR 102 768 V1.1.1 (2009-04)
Handover Detection
The handover detection is the same as that of beam handover. Various approaches can be used for the detection of a
beam handover including position based detection, link quality based detection. This can be performed either centrally
at the NCC or in a distributed manner by the RCSTs. The handover detection algorithm is outside the scope of the
present document, although the position-based detection is the preferred mechanism for train applications where it is
highly likely that a GPS receiver or other navigation system is installed. If the position-based approach is adopted, it is
assumed that the NCC contains a database that includes all beam, gateway and satellite profiles and this same database
will be passed from the NCC to the RCST at its logon phase or at regular intervals. The RCST will combine its position
information and the beam profile information together with the pre-defined train route for handover detection. If a beam
handover is required, the RCST sends a handover recommendation to the NCC. The handover recommendation will
include a list of candidate beams. The recommendation message is encapsulated within the Mobility_Control_Message
as defined in the beam handover procedure, which is carried in DVB-RCS SYNC burst.
8.3.2
Handover Decision
In the handover decision phase, the resource availability of the candidate beams, the SLA and QoS of the session to be
handed over will be checked by the NCC. The handover decision will also take into account the mobility trajectory if it
is known, such as the case of a train route or a flight path. Once a target beam is chosen, the NCC will check if the
chosen target beam belongs to another gateway. If the target beam belongs to a new gateway, a gateway handover is
decided. Normally it is assumed that the FL and RL have the same beam coverage and gateway configuration so that FL
and RL handovers happen simultaneously.
Once a handover is decided, the NCC will update its SI tables, which include the TBTP, SCT, FCT and TCT. Signalling
will be carried out between the NCC, the source and the target GWs for the preparation of handover. The NCC will
send an SNMP Set-Request message to the target gateway for events synchronisation to ensure that the target GW gets
ready for connection with the RCST. The updated SI tables, together with the routing update information of the RCST
will be included in this message. The routing update information is generally implemented by sending the location
change information to the broadcaster, which is generally handled by the location management scheme. Upon reception
of the Set-Request signalling, the target GW will allocate bandwidth resources for the RCST according to the new burst
time plan sent by the NCC. This will be followed by an acknowledgement Get-Response message sent from the target
GW to the NCC. The NCC will then send a Set-Request message to the source GW, which includes the RCST identity
and the SI tables. At the source GW, after receiving the NCC signalling, it will buffer the FL user traffic to be
forwarded to the target GW during handover. The source GW updated its route mapping table and released resources
used by the RCST. The source GW will then acknowledge the NCC by sending it a Get-Response message.
8.3.3
Handover Execution
Upon reception of the Get-Response message from the source GW, a gateway handover command is issued to the
RCST from the NCC in a Mobility Control Descriptor carried in a TIMu message. Upon reception of the handover
command, the RCST synchronizes with the NCC and the target GW, retunes itself to the new beam and receives traffic
from the new beam which comes through the new gateway. In the FW direction, the traffic to the RCST is redirected to
the new gateway and then through the new FL to the moving-in RCST. On the RT direction, the RCST sends return
traffic and signalling on the new RL and through the new RL to the new gateway. The gateway handover is complete
when the RCST sends an ACQ message to the NCC after it finishes the retuning process and receives the CMT message
from the NCC.
The signalling sequence flows as depicted in figure 35, where the Functional Entity Actions (FEAs) are also shown.
FEAs are internal actions of the functional entities in preparation for or in response to their associated signalling
messages (see table 11). In order to facilitate M&C message communication, DVB-RCS management is extended with
newly defined SNMP messages in the format of Trap, Set-Request and Get-Response. The higher layer SNMP
interaction (indicated by solid lines) and DVB FL/RL signalling (indicated by dotted lines) are synchronized and
coordinated to accomplish the entire HO management.
ETSI
76
ETSI TR 102 768 V1.1.1 (2009-04)
Figure 35: Gateway Handover Signalling Sequence
Table 11: Gateway Handover Functional Entity Actions
FEA Number
FEA1
FEA2
FEA3
FEA4
FEA5
FEA6
FEA7
FEA8
FEA9
FEA10
FEA11
FEA12
FEA13
FEA14
FEA15
FEA16
FEA17
FEA18
FEA description
Periodically check the positioning/link quality
information, triggering HO Recommendation on
criteria agreements.
Make HO decision, identifying it's HO type, i.e. beam
HO, GW HO or SAT HO.
Set resource arrangement taking account to the new
moved-in RCST.
Arrange resources for moving-in RCST.
Send resource allocation update response to the
NCC.
Set resource arrangement taking account to the
moved-out RCST.
Send Set-Request for moving-out RCST to forward
the traffic.
Prepare to release resources for the moving-out
RCST, forward the traffic.
Send resource allocation update response to the
NCC.
Receive resource allocation update response.
Issue HO CMD in source beam, indicating Target
beam/GW/SAT.
Retune to target beam. Switch to new link.
Issue general SI tables in target beam.
Use new resources in target beam.
Send ACQ in target beam.
Receive ACQ in target beam, indicating RCST
re-synchronisation.
Send CMT to moved-in RCST in target beam,
confirming the HO complete.
Receive HO confirmation indicated by CMT.
ETSI
Comments
Refer to beam HO mechanisms [RD-3]
Refer to beam HO mechanisms
Refer to beam HO mechanisms
Refer to beam HO mechanisms
Refer to beam HO mechanisms
Refer to beam HO mechanisms
Refer to beam HO mechanisms
Refer to beam HO mechanisms
77
9
ETSI TR 102 768 V1.1.1 (2009-04)
Continuous Carrier Operation
The use of continuous carriers in the return link has been adopted as a simple and robust access mechanism for mobile
DVB-RCS networks; in particular for RCSTs with substantial traffic aggregation such as those serving trains, cruise
ships and wide-body commercial aircrafts. Such RCSTs may have a sufficient number of users behind to allow for an
efficient use of the continuous carrier mode which has a better physical layer spectral efficiency (see annex B).
Continuous carrier mode has advantages in other situations as well. For example, demand assignment mechanisms can
break down in terrestrial-mobile applications that experience frequent channel blockages. This happens when the
capacity requests and/or the assignment messages experience a high loss probability. Alternative access schemes for
such problematic channels include the use of random access as well as continuous carriers. Continuous carriers have the
advantage over random access that some measure of Quality-of-Service provisioning is possible, at least when the
channel is not blocked.
The continuous carrier mode can be seen as an add-on to the classical DVB-RCS system, as illustrated in figure 36.
Figure 36: DVB-RCS system with DVB-S2 return link in continuous mode
The following clauses assess the system architecture and signalling implications for the operation of a DVB-RCS
network that employs both continuous carriers and MF-TDMA.
9.1
Architecture and Modes of Operation
In any given network, it is unlikely that all terminals operate in continuous carrier mode all the time. The provisions in
EN 301 790 [i.1] are therefore designed to support a hybrid architecture that retains all the characteristics of a classical
MF-TDMA DVB-RCS network, while adding continuous carrier operation as an overlay. This approach has several
additional advantages, including:
•
The forward link is unchanged, except for the addition of some signalling elements needed to control the
continuous carrier mode.
•
RCSTs can maintain the existing NCR synchronisation scheme, relaxing the requirement for high-stability,
high-cost reference oscillators otherwise needed for terminals in continuous carrier systems.
•
A forward signalling path for controlling the RCST operation exists at all times. This simplifies management.
In order to ensure the maximum flexibility for RCST operation while retaining backwards compatibility, continuous
carrier operation is defined in terms of a number of functional states that complement the existing RCST state diagram
defined in clause 7.1 of EN 301 790 [i.1]. The steady-state mode corresponding to MF-TDMA operation is called "Fine
Sync" mode. The additional mode of operation is called "Continuous". Therefore, there are four modes of operation:
a)
Fine Sync: As defined for MF-TDMA operation; this is the existing MF-TDMA operational mode.
b)
Continuous: Operation with a continuous carrier only.
ETSI
78
ETSI TR 102 768 V1.1.1 (2009-04)
c)
Continuous + Fine Sync (Optional): Simultaneous operation of continuous carrier and MF-TDMA.
d)
Off/Standby: As defined for MF-TDMA operation; the terminal is not operating.
Mode c) is optional and it requires two transmitters in the RCST. The possible transitions between these four states, and
the events that trigger these transitions, are defined in detail in clause 10.1 of EN 301 790 [i.1]. The basic trigger
mechanisms are the assignment and release of continuous carriers, and DVB-RCS logon and logoff events.
Any RCST must be able to log on in mode a), corresponding to conventional MF-TDMA DVB-RCS. Once logged on,
requests and/or commands can be used to assign a continuous carrier to the RCST. Depending on the terminal
capabilities, such an assignment may be accompanied by a log-off. If the DVB-RCS session is maintained, the RCST
moves to mode c). If the RCS session is cancelled, it moves to mode b).
A terminal in mode b) is not logged on in the real sense of DVB-RCS, since it does not operate a regular return link
with SYNC bursts etc. However, the terminal is still logged on in the sense that it exchanges traffic and signalling with
the NCC. Return link signalling required in this mode can be sent using DULM on the continuous carrier, as discussed
below. The NCC may need some specific functionality to be able to accept and process this signalling.
Any terminal-specific configuration parameters required for operation of the continuous carrier can be sent through the
forward link signalling (Unicast TIM).
In some systems, primarily very small ones, it may be appropriate that the RCST starts directly in continuous mode on a
pre-assigned carrier, without going through a DVB-RCS log-on process. To facilitate this, while maintaining the
flexibility to change the operational mode later, EN 301 790 [i.1] includes requests and commands to assign a carrier
semi-permanently to an RCST. At the next "logon", the RCST will immediately start using this carrier, rather than
going through the RCS logon process. There are similarly requests/commands to revoke this "permanent" carrier
assignment, so that the RCST will attempt its next log on in normal RCS mode. Depending on the implementation, it
may also be possible to configure these parameters directly in the terminal, so that an RCST can start directly in
continuous mode, without ever going into RCS mode.
9.2
Bandwidth Management
Continuous carrier based systems can be operated with different degrees of sophistication, chosen in accordance with
the size of the network and the activity level of individual terminals. At one extreme, each terminal can be permanently
assigned to a carrier. This is obviously the simplest scenario in terms of management, but it may be very inefficient if
the terminal is inactive for extended periods. Given that signalling paths exist in the DVB-RCS network, it is relatively
easy to implement a simple, carrier-switched multiple access scheme, in which continuous carriers are dynamically
assigned to RCSTs. The primary justification for such a dynamic assignment is the usage profile of the mobile
terminals: trains and aircraft, for example, routinely spend extended periods out of service.
The continuous carrier assignment can be done in response to terminal requests. In this case, the scheme becomes a
simple demand-assignment scheme. Once the basics of such a mechanism are in place, it becomes simple to extend it to
cover also the adaptation of the continuous carrier characteristics, for example to accommodate fluctuations in traffic
demand or to change the level of protection to adapt to changing channel conditions.
A carrier-based demand assignment scheme is much less responsive and flexible than the full MF-TDMA scheme; it
only really applies at the session/connection level. Once the demand variability reaches a certain degree, it will become
advantageous to switch to MF-TDMA mode. Such decisions, as well as any admission control functions required for the
carrier-switched demand assignment.
The set of continuous carriers supported by the NCC is signalled to the RCSTs using the broadcast signalling in a
manner analogous to that used for MF-TDMA time slots. Carriers are assigned, modified and revoked by signalling
between the NCC and the RCST. The RCST can request carriers by type, allowing the NCC to manage "pools" of
equivalent carriers.
ETSI
79
9.3
ETSI TR 102 768 V1.1.1 (2009-04)
Signalling
Control of the system is implemented by exchange of signalling messages between the RCST and NCC. In the RCS
system architecture, a forward link signalling path always exists. The definition of the characteristics of the available
continuous carriers and the assignment/revocation process are handled within the existing signalling framework,
i.e. using the SCT, FCT, TCT and TBTP. The specific interpretation of these tables necessary for continuous carrier
operation is described in the corresponding clauses of EN 301 790 [i.1] and is summarized below.
The existence of a return link signalling path depends on the mode of operation. If the RCST is in mode a) or c), the
MF-TDMA return link provides a signalling path. DULM has been chosen for the return link signalling associated with
continuous carrier operation. Usually, such signalling will be relatively infrequent. The potential delay associated with
the DULM method, caused by the need to request and be granted capacity before a message can be issued, is therefore
likely to be acceptable. Since the signalling frequency requirement is low, any signalling mechanism permanently
assigned within the MF-TDMA system (e.g. in the SAC field of SYNC or traffic bursts) are likely to be bandwidth
inefficient.
RCSTs operating in mode b) do not necessarily have an obvious return link MAC layer signalling path. This may be the
case if the continuous carrier traffic is dedicated to real-time applications with tight delay and jitter constraints. In such
case, an arbitrary injection of signalling messages in the return link stream can be disruptive. In other situations this
may not be a problem, for example where the continuous carrier aggregates best-effort traffic. The methods used to
solve this trade-off are system dependent. Here, two examples are described:
•
RCSTs capable of operating in mode c) can logon in MF-TDMA mode without disrupting the continuous
carrier and transmit the signalling there.
•
RCSTs not capable of mode c) operation can make some provision for signalling within the continuous carrier,
for example by setting aside a small amount of bandwidth for this purpose (e.g. assign one MAC layer packet
out of every N, which is permanently dedicated to DULM messages).
This aspect need not be standardized, since the management of the bandwidth within the continuous carrier is
system-dependent. The NCC must however be able to accept signalling messages from the RCST through either of
these channels.
9.3.1
9.3.1.1
Forward Link Signalling
Carrier Description
Continuous carriers are defined in the forward link broadcast signalling through the same hierarchy of tables as
MF-TDMA time slots. A continuous carrier is fundamentally identified in the TCT as a "time slot" with zero duration.
This is not a valid value for genuine MF-TDMA time slots, so this signalling method does not interfere with normal
system operation or with terminals that are unaware of the continuous carriers.
When the zero-duration option is chosen, certain physical layer parameters are interpreted slightly differently than they
are for MF-TDMA time slots. The details are provided in clause 8.5.5.4 of EN 301 790 [i.1].
The basic transmission scheme is DVB-S2, but the signalling provides "user space" for defining other air interfaces.
Also, a number of parameters in the TCT entry are irrelevant for continuous carriers. These include burst_start_offset,
inner_code_type, inner_code_ordering, outer_coding, Route_ID_flag, ACM_flag, SAC_length, request_flag,
M_and_C_flag, Group_ID_flag, Logon_ID_flag, capacity-requests_number, New_permutation, P0, P1, P2, P3,
preamble_length and preamble_symbol.
ETSI
80
ETSI TR 102 768 V1.1.1 (2009-04)
The following fields in the Time Composition Table are relevant for continuous carrier mode.
Table 12: TCT table use for continuous carrier mode
TCT
Continuous Carrier
Timeslot_composition_section(){
X
SI_private_section_header
X
timeslot_loop_count
X
For(i=0;i <= timeslot_loop_count;i++){
X
timeslot_id
X
symbol_rate
X
timeslot_duration
X (see note)
burst_start_offset
inner_code_type
inner_code_ordering
outer_coding
inner_code_puncturing
X
modulation
X
baseband_shaping
X
timeslot_payload_type
X
Route_ID_flag
ACM_flag
MOB-flag
SAC_length
request_flag
M_and_C_flag
Group_ID_flag
Logon_ID_flag
capacity_requests_number
New_permutation
If( (Inner_code_type == 1) and (New_permutation == 1) ) {
P0
P1
P2
P3
}
preamble_length
for (j=0;j<preamble_length;j++){
preamble_symbol
}
while (!bytealigned){
X
stuffing_bit }
}
CRC_32
X
}
NOTE:
The field "timeslot_duration" shall be equal to 0. This field identifies the continuous carrier
mode and allows the enumeration of the timeslots.
ETSI
81
ETSI TR 102 768 V1.1.1 (2009-04)
The following fields in the Frame Composition table are relevant for continuous carrier mode.
Table 13: FCT table use for continuous carrier mode
FCT
Frame_composition_section(){
SI_private_section_header
frame_ID_loop_count
for(i=0;i<=frame_ID_loop_count;i++){
frame_id
frame_duration
total_timeslot_count
start_timeslot_number
timeslot_loop_count
for(j=0;j<=timeslot_loop_count;j++){
timeslot_frequency_offset
timeslot_time_offset
timeslot_id
repeat_count
}
}
CRC_32
}
Continuous Carrier
X
X
X
X
X
X (see below 1))
X
X
X
X
X
X (see below 2))
X
X (see below 3))
X
X
X
X
Instantiation of the continuous carrier "time slot" in the FCT is done as for MF-TDMA time slots, with the observations
that:
1)
The frame_duration parameter is used only to identify frames; it does not indicate any physical property of the
continuous carriers defined in the frame.
2)
The timeslot_time_offset parameter is used only to define the order of time slots within the frame as per the
normal counting rules and hence to identify the time slot for assignment purposes. It does not indicate any
physical property of the continuous carrier.
3)
The repeat_count must be set to 0 (1 instance) for the continuous carrier "time slot".
Details are given in clause 8.5.5.3 of EN 301 790 [i.1].
Instantiation of frames containing continuous carriers is done in the SCT in the same basic manner as for any other
frame. It is noted however that the frame_start_time parameter is used only to define the order of frames within the
superframe as per the normal counting rules and hence to identify the frame for assignment purposes.
A number of parameters in an SCT entry are irrelevant for continuous carrier aspects of the frame. These include
superframe_start_time_base, superframe_start_time_ext and superframe_duration. Details are given in clause 8.5.5.2 of
the present document. The following fields in the Superframe Composition table are relevant for continuous carrier
mode.
ETSI
82
ETSI TR 102 768 V1.1.1 (2009-04)
Table 14: SCT table use for continuous carrier mode
Continuous
Carrier
X
X
X
X
X
X
Syntax
Superframe_composition_section(){
SI_private_section_header
superframe_loop_count
for(i=0;i<=superframe_loop_count;i++){
superframe_id
Large_Timing_Uncertainty_Flag
uplink_polarization
superframe_start_time_base
superframe_start_time_ext
superframe_duration
X
superframe_centre_frequency
superframe_counter
X
frame_loop_count
X
for(j=0;j<=frame_loop_count;j++) {
X
frame_id
X
frame_start_time
X (see note)
frame_centre_frequency_offset
X
}
X
}
X
CRC_32
X
}
X
NOTE:
The field "frame_start_time" is only used for the
enumeration of the frames.
9.3.1.2
Carrier Assignment and Release
Assignment and revocation of continuous carriers is carried out using the TBTP, in the same manner as for MF-TDMA
time slots. The only difference is the interpretation of the assignment_type parameter, which is modified for continuous
carrier "time slots" in order to reflect the selection of operations applicable to this type of transmission. Clause 10.4.5 of
EN 301 790 [i.1] provides detailed specifications of the RCSTs behaviour. It should be noted that assignment and
release of carriers may cause the RCST to change its operational mode.
9.3.1.3
Other Forward Link Signalling
Forward link signalling other than the carrier definition and assignment/release described above is generally either
irrelevant for the continuous carrier operation or applicable to the entire RCST. Therefore, in most cases, no special
provisions are required in order to distinguish between the MF-TDMA and continuous carrier air interfaces of the
RCST. There are three exceptions to this: The Logon Initialize Descriptor, the Mesh Logon Initialize descriptor and the
Return Interaction Path Descriptor contain definitions of the VPI/VCI or PID to be used for traffic and signalling. In
order to allow signalling of these parameters to be handled within the existing mechanisms, without imposing a need for
distinct MAC addresses for the two air interfaces, previously reserved bits are used to allow distinction between the
continuous carrier and MF-TDMA air interfaces for these two descriptors. Details are provided in clauses 8.5.5.10.4 and
8.5.5.10.17 of EN 301 790 [i.1].
9.3.2
Return Link Signalling
As described above, DULM has been selected as the signalling method of choice for return link messages relevant to
continuous carrier operation. A single information element is used for this purpose; this is defined in clause 10.4.4 of
EN 301 790 [i.1]. This information element can carry all the required messages from the RCST to the NCC, including:
•
Temporary carrier assignment / release requests.
•
Permanent carrier assignment / release requests.
•
Acknowledgement of assignment messages, including accept/reject of assignment.
ETSI
83
9.4
Physical Layer
9.4.1
Synchronisation
ETSI TR 102 768 V1.1.1 (2009-04)
System synchronisation is based on NCR distribution in the same manner as for MF-TDMA operation. Depending on
system requirements, this open-loop synchronisation can be augmented by closed-loop control. It is further noted that
burst timing control is not applicable to continuous carriers. Power control is addressed in clause 46.
9.4.2
Encapsulation
The stream format of the continuous carrier is defined in clause 10.4.3 of EN 301 790 [i.1] as a single, packetized
generic stream. ATM is mandatory; MPEG encapsulation must be supported if the RCST supports this in MF-TDMA
mode. It should be noted that, when MPEG is used, the stream is a sequence of MPEG packets and therefore somewhat
reminiscent of a Transport Stream. However, it lacks the basic signalling used for transport streams and is therefore still
characterized as a generic stream.
Generic stream encapsulation may be supported in the future.
9.4.3
Modulation and Coding
The outer BCH codes adopted for each of the three inner LDPC codes are specified in table C.2 of [i.1], reported
hereafter for the sake of clarity. For the (4 096, 3 072) LDPC code, the outer code is a (3 072, 3 000) BCH code
obtained by shortening of a (4 095, 4 023) 6-errors correcting BCH code. For the (4 096, 2 048) and for the (4 096,
1 024), the outer codes are extended BCH codes with respective parameters (2 048, 1 992) and (1 024, 993). The first
one is obtained by the 1-bit extension of a (2 047, 1 992) 5-errors correcting BCH code, the second one is obtained by
the 1-bit extension of a (1 023, 993) 3-errors correcting BCH code. The extension is performed by computing the
additional parity bit as modulo-2 sum of all the codeword bits generated by the BCH encoder. The 1-bit extension
increases the error correction capability of the code: for the (1 023, 993) the minimum distance is 7, while for its
extended version the minimum distance is 8. Similarly, for the (2 043, 1 992) BCH code the minimum distance is 11,
while its extended version possesses minimum distance 12. The additional bit in these two cases can be either used for
enhancing the outer error correction, or to increase the error detection capabilities of the outer code (i.e. sequences with
odd Hamming weight at the output of the BCH decoder will be detected as erroneous).
Table 15: BCH code specification for very short FECFRAME
Outer code for the (4 096, 3 072) LDPCC
Shortened
BCH
g(x)
coefficients
(g0…g72)
(3 072, 3 000, t=6) from shortening of a (4 095, 4 023) BCH
1011101011010010100111001100010011001100100010111101000100111010010001001
Outer code for the (4 096, 2 048) LDPCC
Extended
BCH
g(x)
coefficients
(g0…g55)
(2 048, 1 992, t=5)
10110011011110011000100100000000001000010101010010101011
Outer code for the (4 096, 1 024) LDPCC
Extended
BCH
g(x)
coefficients
(g0…g30)
(1 024, 993, t=3)
1100100010001000100101010000101
All provisions reported in [i.2] for the BCH code which are not in contradiction with the above apply also to the very
short FECFRAME.
ETSI
84
9.4.4
ETSI TR 102 768 V1.1.1 (2009-04)
Adaptive Operation
The provisions in [i.1] are intended to allow three types of adaptation to signal variations. This does not prevent the use
of other techniques that can be implemented using the available signalling mechanisms. The three types of adaptivity
foreseen are:
•
RCST transmit power control.
•
Variable Coding and Modulation (VCM) under control of the NCC.
•
VCM with distributed control.
These are described in the following clauses.
9.4.4.1
Transmit Power Control
Transmit power control can be implemented in essentially the same manner as for MF-TDMA. For the same reasons as
described in clause 9.4.1, it is recommended to use the TIM for correction messages. Furthermore, in order to facilitate
the use of power control in combination with VCM, it is recommended to use the Es/N0 reporting option of the
correction message.
9.4.4.2
VCM Controlled by the NCC
Variable Coding and Modulation (VCM) under the complete control of the NCC can be implemented using the carrier
assignment and release mechanisms described in clause 9.3.1.2. As also noted in clause 10.4.1.1 of EN 301 790 [i.1],
such VCM operation can be performed "in place", i.e. effectively changing the modulation/coding parameters of a given
carrier, if the NCC receiver allows this. To achieve this "in-place" operation, the various modulation/coding
combinations are defined in the broadcast signalling as different "time slot" types, which are subsequently instantiated
at the same carrier frequency in the FCT. It is the responsibility of the NCC to ensure that only one such "time slot" is
assigned at any time.
The NCC will typically base decisions to change the modulation and coding on the signal quality measured on the
received continuous carrier.
9.4.4.3
VCM with Distributed Control
As an alternative to the NCC-controlled VCM operation, it is possible to distribute parts of the control to the RCST. To
facilitate this, the NCC can broadcast a list of modulation/coding combinations supported in its receiver. This list is
contained in the Return Transmission Modes (RTM) descriptor, which is defined in clause 8.5.5.10.21 of
EN 301 790 [i.1]. The list is organized per superframe; this allows management of a bank of receivers with different
capabilities. The list may additionally contain threshold values, defining the minimum Es/N0 required at the NCC for
reception of each modulation/coding combination.
RCSTs that support this option must indicate this by using the "Continuous ACM" flag in the CSC burst when logging
on as MF-TDMA terminals. They can subsequently use any of the listed modes at any time, without signalling changes.
RCSTs will typically use the signal quality (Es/N0) reported in the TIM as a basis for the decision to change.
RCSTs that do not support the distributed VCM technique must use the modulation/coding parameters given in the TCT
and implied by the assignment received in the TBTP. The same is true if no RTM descriptor is broadcast.
9.4.5
Spectrum Spreading
Return link continuous carriers may require the use of spectrum spreading for the same reasons as MF-TDMA
transmissions; i.e. to reduce the spectral density, in particular off-axis. The spreading technique to be used is derived
from that defined for DVB-S2 forward link transmissions and is described in clause 10.4.2 of EN 301 790 [i.1]. Details
of the spreading parameters are included as part of the modulation/coding definition in the TCT entry for the carrier.
ETSI
85
9.4.5.1
ETSI TR 102 768 V1.1.1 (2009-04)
Return link continuous carrier code synchronization
Frame/code acquisition in the continuous mode return link is the first operation to be performed, i.e. before carrier and
timing estimation. In fact, in the presence of direct sequence spread spectrum it is difficult to perform parameter
estimation with sufficient accuracy before code acquisition. In the following, results on the code synchronization
performances are shown taking into account the following assumptions:
•
Symbol Rate (information symbol rate after coding & modulation) = 1 Msps.
•
Spreading factor (SF) = 1, 2, 3, 4, 8.
•
Chip rate = Symbol Rate * SF.
•
Modulation: QPSK.
•
Framing:
•
•
•
•
-
Short FEC frame (16 200 coded symbols).
-
Data payload length: 16 200/2 = 8 100 QPSK symbols.
-
Unique Word length: 26 symbols, DVB pattern.
-
Pilot: 11 fields of 36 symbols each.
-
Frame Length = SF × (8100 + 11 × 36 + 26 + 64) = SF × 8 586 [chips].
Operating points:
-
Es/N0 = 0,7 dB, r = 1/2; Es/N0 = -1 dB, r = 1/3.
-
Ec/N0 = Es/N0 - 10 log10(SF).
Propagation conditions:
-
LOS AWGN.
-
Frequency uncertainty = 3,0 kHz (oscillator mismatch + Doppler).
Timing recovery:
-
No timing recovery prior to frame synchronization.
-
Two hypotheses per chip are considered, worst case fractional timing delay of 0,25 Tc.
-
Timing frequency error = 100 ppm.
Phase recovery:
-
Phase noise: the same as for the FL scenario.
ETSI
86
9.4.5.1.1
ETSI TR 102 768 V1.1.1 (2009-04)
Phase noise sensitivity assessment
In figure 37, it can be seen that the spectrum spreading technique is insensitive to phase noise, which is therefore
neglected in the analysis hereafter.
1E+00
1E-01
Pmd
1E-02
1E-03
SF = 1, EsN0 = 0.7, Delta = 0.25 - phase noise
1E-04
SF = 2, EsN0 = 0.7, Delta = 0.25 - phase noise
1E-05
SF = 1, EsN0 = 0.7, Delta = 0.25
SF = 2, EsN0 = 0.7, EcN0 = -2.3, Delta = 0.25
1E-06
1E-06
1E-05
1E-04
1E-03
1E-02
1E-01
1E+00
Pfa
Figure 37: Performance evaluation in the presence of phase noise
9.4.5.1.2
ROC performance in AWGN
In figure 38, analytical and simulated ROCs are presented in AWGN with Es/N0 = 0,7 dB and chip time misalignment
δ = 0,25, in the exemplary scenarios with SF = 1, 2, 8. Notably, the analytical curves well validate the simulation
results. This conclusion is further extendable to all possible SF values, allowing in the following to consider only
simulation results. By comparing the different SF, it clearly emerges that the introduction of DS spreading improves
ROC performance because the interference introduced by the unknown information data (self-noise) during the Start of
Frame (SoF) search procedure is attenuated in this case.
1E+00
1E-01
Pmd
1E-02
1E-03
1E-04
SF = 1, EsN0 = 0.7, Delta = 0.25
SF = 1, EsN0 = 0.7, Delta = 0.25, Analytical
SF = 2, EsN0 = 0.7, EcN0 = -2.3, Delta = 0.25
1E-05
SF = 2, EsN0 = 0.7, EcN0 = -2.3, Delta = 0.25, Analytical
SF = 8, EsN0 = 0.7, EcN0 = -8.3, Delta = 0.25
1E-06
1E-07
SF = 8, EsN0 = 0.7, EcN0 = -8.3, Delta = 0.25, Analytical
1E-06
1E-05
1E-04
1E-03
1E-02
1E-01
1E+00
Pfa
Figure 38: Simulated and analytical ROC performance at Es/N0 = 0,7 dB, with non ideal sampling
(δ = 0,25) considering spreading factors SF = 1, 2, 8
By considering all possible SF values, the simulated ROC curves at Es/N0 = 0,7 dB reported in figure 39 are obtained,
where the same considerations with increasing SF still hold. Similarly, the performance at Es/N0 = -1 dB are reported in
figure 40.
ETSI
87
ETSI TR 102 768 V1.1.1 (2009-04)
1E+00
1E-01
1E-02
Pmd
1E-03
1E-04
SF = 1, EsN0 = 0.7, Delta = 0.25
1E-05
SF = 2, EsN0 = 0.7, EcN0 = -2.3, Delta = 0.25
SF = 3, EsN0 = 0.7, EcN0 = -4.1, Delta = 0.25
SF = 4, EsN0 = 0.7, EcN0 = -5.3, Delta = 0.25
1E-06
SF = 8, EsN0 = 0.7, EcN0 = -8.3, Delta = 0.25
SF = 16, EsN0 = 0.7, EcN0 = -11.3, Delta = 0.25
1E-07
1E-07
1E-06
1E-05
1E-04
1E-03
1E-02
1E-01
1E+00
Pfa
Figure 39: Simulated ROC performance at Es/N0 = 0,7 dB, with non ideal sampling (δ = 0,25)
considering spreading factors SF = 1, 2, 3, 4, 8, 16
1E+00
1E-01
Pmd
1E-02
1E-03
SF = 1, EsN0 = -1, Delta = 0.25
SF = 2, EsN0 = -1, EcN0 = -4, Delta = 0.25
SF = 3, EsN0 = -1, EcN0 = -5.8, Delta = 0.25
1E-04
SF = 4, EsN0 = -1, EcN0 = -7, Delta = 0.25
SF = 8, EsN0 = -1, EcN0 = -10, Delta = 0.25
SF = 16, EsN0 = -1, EcN0 = -13, Delta = 0.25
1E-05
1E-07
1E-06
1E-05
1E-04
1E-03
1E-02
1E-01
1E+00
Pfa
Figure 40: Simulated ROC performance at Es/N0 = -1 dB, with non ideal sampling (δ = 0,25)
considering spreading factors SF = 1, 2, 3, 4, 8, 16
9.4.5.1.3
Mean Acquisition Time performance in AWGN
In figure 41 and figure 42, the Mean Acquisition Time (MAT) is reported vs. the false alarm probability, considering a
single dwell serial search procedure [i.12], with two hypotheses per symbol to contrast the chip timing uncertainty. In
particular, the worst case condition for the sampling error is assumed, considering a symbol/chip timing misalignment
δ = 0,25. The procedure terminates when the correct alignment has been detected. In case of false alarms, the procedure
restarts after a penalty time Tp = 2 TF (non-absorbing false alarm), being TF the frame duration.
ETSI
88
ETSI TR 102 768 V1.1.1 (2009-04)
0.05
SF
SF
SF
SF
SF
SF
0.045
0.04
0.035
=
=
=
=
=
=
1, EsN0 = 0.7, Delta = 0.25
2, EsN0 = 0.7, EcN0 = -2.3, Delta = 0.25
3, EsN0 = 0.7, EcN0 = -4.1, Delta = 0.25
4, EsN0 = 0.7, EcN0 = -5.3, Delta = 0.25
8, EsN0 = 0.7, EcN0 = -8.3, Delta = 0.25
16, EsN0 = 0.7, EcN0 = -11.3, Delta = 0.25
MAT [s]
0.03
0.025
0.02
0.015
0.01
0.005
0
1E-08
1E-07
1E-06
1E-05
1E-04
1E-03
Pfa
Figure 41: Mean Acquisition Time performance in AWGN at Es/N0 = 0,7 dB,
with non ideal sampling (δ = 0,25) considering spreading factors SF = 1, 2, 3, 4, 8, 16
0.05
0.045
0.04
SF = 1, EsN0 = -1, Delta = 0.25
SF = 2, EsN0 = -1, EcN0 = -4, Delta = 0.25
SF = 3, EsN0 = -1, EcN0 = -5.8, Delta = 0.25
SF = 4, EsN0 = -1, EcN0 = -7, Delta = 0.25
0.035
SF = 8, EsN0 = -1, EcN0 = -10, Delta = 0.25
SF = 16, EsN0 = -1, EcN0 = -13, Delta = 0.25
MAT [s]
0.03
0.025
0.02
0.015
0.01
0.005
0
1E-08
1E-07
1E-06
Pfa
1E-05
1E-04
1E-03
Figure 42: Mean Acquisition Time performance in AWGN at Es/N0 = -1 dB, with non ideal sampling
(δ = 0,25) considering spreading factors SF = 1, 2, 3, 4, 8, 16
The MAT performance confirms the results shown by ROC, i.e. performance improves by increasing the spreading
factor. The best performance is achieved in correspondence of the minimum points of the MAT curves, which are
summarized in table 16. In any case, the worst case performance, which is 15 ms for SF =1 and Es/N0 = -1 dB appears
to be satisfactory.
ETSI
89
ETSI TR 102 768 V1.1.1 (2009-04)
Table 16: Minimum MAT in AWGN at Es/N0 = 0,7 and -1 dB, with non ideal sampling (δ = 0,25)
considering spreading factors SF = 1, 2, 3, 4, 8, 16
Es/N0 (dB)
0,7
-1
SF
1
2
3
4
8
16
1
2
3
4
8
16
Ec/N0 (dB)
0,7
-2,3
-4,1
-5,3
-8,3
-11,3
-1,0
-4,0
-5,8
-7,0
-10,0
-13,0
Pfa
1,9E-05
1,7E-06
8,0E-07
6,0E-07
2,0E-07
5,0E-07
1,4E-05
3,7E-06
8,0E-07
1,0E-06
4,0E-07
2,0E-07
Pmd
0,34
0,24
0,17
0,16
0,12
0,06
0,64
0,50
0,48
0,46
0,44
0,38
MAT (s)
0,0082
0,0054
0,0049
0,0049
0,0047
0,0055
0,0150
0,0090
0,0075
0,0075
0,0071
0,0064
Finally, figure 43 shows the performance in terms of MAT for a smaller signal to noise ratio, Es/N0 = -3dB, and
SF = 2. The resulting MAT equal to 0.024s confirms that the requirements are largely satisfied, also in a scenario like
this.
0.1
0.09
SF = 2, EsN0 = -3, EcN0 = -6, Delta = 0.25
0.08
MAT [s]
0.07
0.06
0.05
0.04
0.03
0.02
0.01
0
1E-06
1E-05
1E-04
1E-03
1E-02
Pfa
Figure 43: MAT in AWGN at Es/N0 =-3dB with SF = 2 and non ideal sampling
9.4.5.1.4
Performance in Rice Fading Channels
To conclude the performance analysis, in figure 44 and figure 45 ROC and MAT are respectively reported in the
presence of Rice fading channel with Rice factor K = 17,4 dB and Es/N0 = 0 dB. The reported results are obtained
adopting a semi-analytical approach that is valid for a channel coherence time larger than the SoF duration, but shorter
than the frame duration. The proposed approach allows to achieve code/frame synchronization on average in 5 ms for
SF = 4 and 10 ms for SF = 1.
ETSI
90
ETSI TR 102 768 V1.1.1 (2009-04)
1E+00
Pmd
1E-01
1E-02
1E-03
Rice ROC - cold start - SF=4
Rice ROC - cold start - SF=1
1E-04
1E-06
1E-05
1E-04
1E-03
1E-02
1E-01
1E+00
Pfa
Figure 44: ROC performance in the presence of Rice fading channel, K = 17,4, Es/N0 = 0 dB
0.050
0.045
Mean Acquisition Time [s]
0.040
Rice MAT - Tp=2TF - SF=4
Rice MAT - Tp=2TF - SF=1
0.035
0.030
0.025
0.020
0.015
0.010
0.005
0.000
1E-06
1E-05
1E-04
1E-03
Pfa
Figure 45: MAT performance in the presence of Rice fading channel, K = 17,4, Es/N0 = 0 dB.
Two values of penalty time are considered for comparison
9.4.6
Phase Noise impact
This clause analyses the performance of the return link continues carrier mode against the phase noise.
9.4.6.1
Simulation conditions
The DVB-S2 physical layer standard is assumed in the return link of a mobile RCS terminal with "high user traffic
aggregation" with a baud rate of 1 Msps and FECFRAME length of 64 800 symbols. Lower baud rates are most likely
less interesting as the application of DVB-S2 SCPC solution pertains mainly to high rate systems. Both QPSK and
8PSK modulations are considered. Pilot blocks are insert in the XFECFRAME as per the DVB-S2 standard,
i.e. 36 QPSK pilot symbols every 1 440 X FECFRAME symbols. These pilot symbols are meant to be used to help the
carrier recovery circuits. However, DVB-S2 systems not employing pilots may also exist (pilot symbols are optional in
DVB-S2) and would certainly be more prone to performance degradation due to phase noise.
In the computer simulations the satellite channel is consider ideal (AWGN) with the addition of phase noise.
The DVB-S2 demodulator is a typical proprietary design and constitutes a key aspect of the receiver terminal. A
possible implementation has been proposed in [i.26] and is depicted in figure 46.
The demodulator of figure 1 includes several synchronization sub-systems which cover coarse and fine carrier
phase/frequency and timing recovery assuming typical initial synchronization errors. However, in the contest of this
analysis, carrier frequency offset and timing are assumed known so that only the phase noise and the thermal noise
affect the receiver's performance.
ETSI
91
ETSI TR 102 768 V1.1.1 (2009-04)
Figure 46: DVB-S2 demodulator according to the design in [i.26]
9.4.6.1.1
Phase noise generation and synchronization circuits
A phase noise process is generated to model the instabilities of the return link upconverter block according to the [i.3],
for symbol rates greater than 128 Ksps. Figure 47 reports the power spectral density (PSD) of the reference mask and
the one of the actual synthesized phase noise process.
Figure 47: Phase noise Power Spectral Density: RCS model and
actual synthesized phase noise PSD
ETSI
92
ETSI TR 102 768 V1.1.1 (2009-04)
To counteract the phase noise impact, a carrier phase recovery circuit is considered based on the design proposed in
[i.26]. It consists of pilot-aided phase estimator coupled with a linear interpolator. The phase is estimated on each pilot
block and then a linear phase interpolator estimates the carrier phase over the symbols between two consecutive pilot
fields. Figure 48 depicts a block diagram of such phase estimator.
NOTE:
Circles represent the phase estimated on the pilot blocks whereas the lines are the carrier phase value
estimated through linear interpolation.
Figure 48: Phase linear interpolator
9.4.6.2
Performance results
Figure 49 shows the BER performance of the a return link based on DVB-S2 with 1 Msps symbol rate and with and
without the phase noise, for three MODCODS, QPSK 1/2, QPSK 3/4 and 8PSK 2/3.
Figure 49: DVB-S2 BER performance in the presence of a typical DVB-RCS phase noise
ETSI
93
9.4.6.3
ETSI TR 102 768 V1.1.1 (2009-04)
Conclusion
From the previous results, it can be concluded that the impact of the phase noise on the performance of the continuous
carrier in the range of symbol rate of interest is quite limited.
10
System and performance requirements
10.1
QoS requirements for user traffic
Table 17 shows some basic services and the basic QoS features for each service as general performance parameters,
independent of the context and technology.
Table 17: Target QoS per Service
Service
Web browsing
File download
E-mail
Symmetry
Mostly
one-way
Mostly
one-way
Mostly
one-way
Instant
Messaging
Two-party
VoIP
Typical
Downlink
Capacity
50 kbps to
200 kbps
50 kbps to 1 Mbps
Typical
Uplink
Capacity
A few kbps
A few kbps
10 kbps to
100 kbps
10 kbps to
100 kbps
Mostly
symmetric
Symmetric
unless VAD
used
N-party
Symmetric or
VoIP
asymmetric
N-party
Symmetric or
Videoconference asymmetric
P2P Networks
Mostly
asymmetric
250 bytes/message 250
bytes/message
6 kbps to 30 kbps
6 kbps to
30 kbps
Video streaming
16 kbps to
A few kbps
384 kbps
16 kbps to
A few kbps
128 kbps
8 kbps to 128 kbps 8 kbps to
128 kbps
4 kbps to 64 kbps
A few kbps
Mostly
one-way
Audio streaming Mostly
one-way
Interactive
Mostly
gaming
Symmetrical
Real time remote Mostly
control
one-way
applications
10.2
(N-1) × 6 kbps to
30 kbps
(N-1) × 50 kbps to
460 kbps
10 kbps to
200 kbps
6 kbps to
30 kbps
50 kbps to
400 kbps
10 kbps to
50 kbps
Max
Delay
< 2 s to 4 s
Jitter
Packet Loss
Tolerance
Target
N/A
Zero
Several
N/A
seconds
acceptable
Several
N/A
Seconds
acceptable
< 2 seconds N/A
Zero
Zero
< 400 ms
< 75 ms
<3%
< 400 ms
< 75 ms
<3%
< 400 ms
< 75 ms
<1%
Several
Seconds
acceptable
< 10 s
N/A
Zero
< 1ms
<1%
< 10 s
< 1 ms
<1%
400 ms
Small
Zero
400 ms
< 75 ms
Zero
Zero
Analysis and recommendations for Signalling QoS
The signalling system in DVB-RCS is designed for channels with relatively low probability of loss or errors in both
forward and return link. Mobile satellite channels can substantially increase the probability of loss of signalling
elements. In particular, the railway propagation environment is characterized by a Rice channel with amplitude
variations (typically 2 dB in Ku band), with some interruptions due to short obstacles, power arches and tunnels.
Non-line-of sight channels can substantially increase the probability of loss of signalling elements. Acceptable loss
ratios and patterns are system dependent and can be set depending on equipment performance, tolerances and
acceptable capacity losses. This clause summarizes the major impacts of imperfect signalling delivery. These issues
should be considered when designing or configuring a system to operate with specific equipment and in a specific
environment.
ETSI
94
10.2.1
ETSI TR 102 768 V1.1.1 (2009-04)
QoS requirement for the forward link signalling
•
NCR distribution: The RCST must cease transmission when the variation of the local NCR replica is such that
its transmission frequency and timing exceed the system's tolerances. For conventional fixed systems, a typical
maximum time that the RCST can "free-wheel" is about 6 s. This period can be extended by using a
high-quality local oscillator in the RCST.
•
Broadcast signalling (e.g. PMT, SCT, FCT, TCT, SPT, bTIM): In fixed systems, the repetition interval of this
signalling is typically of the order of several seconds. The main impact of loss of this signalling is an increase
in the log-on time corresponding to one repetition interval. Depending on whether the system implements
"warm-start" features, the repetition period can be adjusted within the limits given in EN 301 790 [i.1].
•
Unicast signalling (e.g. uTIM, TBTP, CMT): Loss of a unicast TIM may result in failure of the RCST to
behave in the expected manner. Most systems will already have mechanisms in place to monitor the RCSTs
behaviour and take corrective action as required, for example in the form of re-transmission of the TIM. Such
mechanisms should certainly be applied to mobile systems.
Loss of the TBTP is largely a performance issue; the RCST will not receive capacity assignments. Applications using
return link bandwidth will suffer accordingly, and the system utilisation will be reduced since the capacity described in
the lost TBTP will essentially be wasted. The actual impact on performance will depend on the duration of the TBTP
loss and the TBTP refresh rate.
Loss of a number of consecutive CMTs is considered a failure of the synchronisation maintenance procedure and causes
the RCST to log off. A typical setting for fixed systems is to log the RCST off after three consecutive losses. The
number is primarily determined by the tolerable time and frequency drifts, which are corrected by the messages
contained in the TIM. For mobile systems, a suitable number of allowed losses before log-off is determined by the
equipment stability and factors such as the maximum terminal speed, which in turn determines Doppler shift and timing
drift rate.
10.2.2
QoS requirement for the return link signalling
•
CSC bursts: Loss of a CSC burst will result in a longer log-on time, but will not normally have any other
detrimental effects.
•
ACQ bursts: Loss of a number of consecutive ACQs is considered a failure of the coarse synchronisation
procedure and causes the RCST to go to the off/standby state, where the CSC transmission is attempted anew.
This will result in a longer log-on time, but will not normally have any other detrimental effects. The tolerated
number of consecutive losses can be set according to the expected channel characteristics.
•
SYNC bursts: Loss of a number of consecutive SYNCs is considered a failure of the fine synchronisation
procedure or of the synchronisation maintenance and causes the RCST be logged off. It must then logon anew,
either through a "cold start" or a "warm start", depending on its capabilities. A typical setting for fixed systems
is to log the RCST off after three consecutive SYNC losses. The number is primarily determined by the
tolerable time and frequency drifts, which may be corrected based on measurements on the SYNC bursts. For
mobile systems, a suitable number of allowed losses before log-off is determined by the equipment stability
and factors such as the maximum terminal speed, which in turn determines Doppler shift and timing drift rate.
The loss of SYNC bursts can also have a performance impact, since:
-
the NCC does not receive the capacity requests they may carry; and
-
the power, timing and frequency measurements based on the SYNC burst are interrupted.
Applications using return link bandwidth will suffer accordingly. Also, the request queues in the RCST and NCC can
become de-synchronized by the loss of SYNC bursts. Most systems will already have mechanisms in place to remedy
this, for example by the periodic use of AVBDC. Such mechanisms should certainly be applied to mobile systems.
Interruptions of the measurements can cause the failure of return path rain fade mitigation schemes during rapid fading
events.
•
In-band signalling: Loss of a the signalling carried in traffic bursts can have performance impacts in the same
manner as the loss of SYNC bursts described above.
ETSI
95
11
Simulation results and performance
11.1
Simulation scenarios
ETSI TR 102 768 V1.1.1 (2009-04)
In the following clause, performance results are reported based on simulations on selected channels. The selected
channel models are representative of LOS situations: AWGN and Correlated Ricean (with K > 17 dB). Doppler
spectrum impact is modelled according to the following clause.
11.1.1
Channel model: Doppler Spectrum
Multipath propagation in the mobile channel causes a fast fading phenomena superimposed to the short fading effects
originated by the trellises, power arches and bridges or tunnels as seen in clause 4.2. This phenomenon can be
characterized in the frequency domain by the Doppler Power Spectral Density (PSD), also referred to as Doppler
Spectrum. Jakes PSD model is widely accepted to characterize this Doppler spectrum, however it is based on the
assumption of omnidirectional antenna in both ends. In the Railroad Satellite channel, a highly directional terminal
antenna in the train is considered and therefore the Doppler PSD function will be different from the Jakes spectrum.
The Doppler power spectrum received on the directional antenna is defined by the intensity of the received multipath
components with their Doppler shift. We assumed that the azimuth Direction of Arrival (DOA) of multipath
components is uniformly distributed over (0, 2π ] . Only part of the multipath components will be received by the train
terminal antenna due to the directional geometry. The Doppler shift components varies between f d cos (α − φ ) and
f d cos (α + φ ) , where α is the angle between the direction of movement and the direct Line-Of-Sight (LOS)
component and 2φ is the beamwidth of the directional antenna, as depicted in figure 50.
Figure 50: Multipath Geometry
For a detailed derivation of the Doppler PSD for directional antennas refer to [i.27] and [i.28]. Here we restrict to
present the equation for sake of completeness without providing further details:
•
if 0 ≤ α ≤ φ
A
⎧
⎪
2
⎛ f ⎞
⎪
⎪ fd 1 − ⎜ f ⎟
⎝ d⎠
⎪
⎪
2A
S1 ( f ) = ⎨
2
⎪
⎛ f ⎞
⎪ fd 1 − ⎜ ⎟
⎝ fd ⎠
⎪
⎪0 otherwise
⎪
⎪⎩
if f d cos(φ + α ) < f < f d cos(φ − α )
if f d cos(φ − α ) ≤ f < f d
ETSI
96
•
if π − φ ≤ α ≤ π
A
⎧
⎪
2
⎛ f ⎞
⎪
⎪ fd 1 − ⎜ f ⎟
⎝ d⎠
⎪
⎪
2A
S1 ( f ) = ⎨
2
⎪
⎛ f ⎞
⎪ fd 1 − ⎜ ⎟
⎝ fd ⎠
⎪
⎪0 otherwise
⎪
⎪
⎩
•
ETSI TR 102 768 V1.1.1 (2009-04)
if - f d cos(φ − α ) < f < − f d cos(φ + α )
if − f d < f ≤ − f d cos(φ − α )
if φ < α < π − φ
A
⎧
⎪
2
⎛ f ⎞
⎪
S1 ( f ) = ⎨ f d 1 − ⎜ ⎟
⎝ fd ⎠
⎪
⎪0 otherwise
⎩
if f d cos(φ + α ) < f < f d cos(φ − α )
where f d ≈ vf 0 / c denotes the maximum Doppler shift ( v : train velocity, f 0 : carrier frequency, c : speed of light).
11.2
Performance in LOS channels
11.2.1
Forward link PER performance
Physical layer performance has been carried out considering the complete DVB-S2 transmit-receive chain in a railway
environment. LOS channel condition (Rice factor K = 17,4 dB) is assumed. Two different train speeds have been
considered: 30 km/h and 300 km/h. Simulations have been carried out under the hypothesis of a receiving antenna with
high directivity. In other words, the Doppler spectrum is reduced with respect to the Jakes model to take into account
the decreased multi-path power captured by the receiving antenna (see clause11.1.1). The carrier phase noise is
generated according to the phase noise mask reported in the DVB-S2 implementation guidelines [i.29] and the
non-linear distortion introduced by the HPA has been kept into consideration according to the data reported in
clause 5.1.1.1. The predistortion technique applied in the following is based on a fractional approach (post matched
filter) described in [i.30].
Table 18: HPA related parameters
Modulation
QPSK
8-PSK
16-APSK
IBO (dB)
0,5
1
2
OBO (dB)
0,33
0,43
1,08
For the performance analysis purposes, the digital receiver architecture depicted in figure 51 has been considered. It is
worthwhile noting that since this analysis is focused on the data detection performance of the receiver, the initial
frequency acquisition and frame synchronization operations are assumed to be successfully accomplished, (see
clause 5.1). Hence, the white block of figure 51 has not been considered in the software simulations for this analysis.
ETSI
97
ETSI TR 102 768 V1.1.1 (2009-04)
In the following, a brief description of the different sub-subsystems is reported in order to ease the understanding of the
performance results reported in this clause. The carrier frequency coarse correction is firstly performed to allow
matched filtering with minimal inter-symbol interference re-growth; then the clock recovery for timing adjustment is
performed by a digital interpolator. A demultiplexer is used to separate pilots from data symbols carried in the
PLFRAME. The pilot symbol stream is used by the following four sub-systems: the noise level estimator, the digital
Automatic Gain and Angle Control (AGAC), the block in charge of tracking the residual frequency offset and carrier
phase and, finally, the coarse frequency acquisition loop (not performed in hot start). On the other path, the data
symbols feed the hard/soft demodulator. The demodulator provides the hard decisions on data symbols as a feed-back
for carrier frequency and phase tracking, and computes the soft initial A Posteriori Probability (APP) on the received
information bits. Finally, the APPs are de-interleaved and provided to the LDPC-BCH decoder. From the point of view
of the sequential order of operations, during initial acquisition, the first operating sub-system is the clock recovery;
since it can operate in the presence of large carrier frequency errors. For example, the Gardner timing detector [i.31]
exhibits good estimation performance also in the presence of rather high-carrier frequency mismatch. Then, after the
frame synchronization algorithm, the pilot symbols can be used to initiate the frequency recovery loop. Upon reaching
the steady state, the fine channel tracking operations is run. In particular, the adopted noise level estimation algorithm is
derived from the maximum likelihood (ML) theory [i.32]. The data-aided (DA) version is considered, since the
estimator operates on the PLHEADER (90 known symbols: 26 from the SOF field and 64 from the MODCOD
information). The digital AGAC sub-system [i.33] is a feed-forward algorithm based on an ML approach which exploits
the presence of the pilot symbols by estimate the channel coefficients as follows:
P −1
cˆk =
∑d r
* ( p)
i i
i =0
P −1
∑d
2
i
i =0
where P is the number of pilot symbols,
d i is the known pilot symbol, and finally
ri( p )
is the received pilot symbol.
Each fading estimate is then linearly interpolated between consecutive pilot fields to better tracking the channel
propagation fluctuations. This solution is supported by the fact that the channel coherence time is always longer (90 μs;
at least) than the time distance between two consecutive pilot slots (50 μs at 27,5 Msps). Finally, the AGAC angle
estimate initializes the block in charge of tracking the residual frequency offset and carrier phase-noise fluctuations. For
this purpose, a well-known second-order loop filter is implemented.
Frame
Synch
Matched
Filter
Frequency
Acquisition
Symbol
Sampling
Timing
Recovery
Data
DeMUX
Buffer
Preamble /
Pilots
θˆ0
Noise level
Estimation
Hard/Soft
Demodulator
( )2
Digital
AGAC
θˆ0
Buffer
N̂ 0
1
ak
Lock
Detector
θˆk
DeInterleaver
Freq/Phase
Tracking
LDPC/BCH
Decoder
Figure 51: Block diagram of the digital receiver
Figure 52 and figure 53 report packet error performance measured on the DVB-S2 DATAFIELD (see figure 3) without
spreading, for 30 km/h and 300 km/h, respectively, confirming that in LOS conditions, the detection performance is still
satisfactory for both high and low train speed.
ETSI
98
ETSI TR 102 768 V1.1.1 (2009-04)
1.E+00
1/4 QPSK - LOS, 30 km/h
1/3 QPSK - LOS, 30 km/h
1/2 QPSK - LOS, 30 km/h
3/4 QPSK - LOS, 30 km/h
3/5 8PSK - LOS, 30 km/h
3/4 8PSK - LOS, 30 km/h
2/3 16APSK - LOS, 30 km/h
3/4 16APSK - LOS, 30 km/h
1.E-01
PER
1.E-02
1.E-03
1.E-04
1.E-05
-3 -2 -1 0
1
2
3
4
5
6
7
8
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Es/N0 [dB]
Figure 52: DVB-S2 performance for several MODCODs, in LOS channel condition,
Ku band, no spreading, low train speed
1.E+00
1/4 QPSK - LOS, 300 km/h
1/3 QPSK - LOS, 300 km/h
1/2 QPSK - LOS, 300 km/h
3/4 QPSK - LOS, 300 km/h
3/5 8PSK - LOS, 300 km/h
3/4 8PSK - LOS, 300 km/h
2/3 16APSK - LOS, 300 km/h
3/4 16APSK - LOS, 300 km/h
1.E-01
PER
1.E-02
1.E-03
1.E-04
1.E-05
-3 -2 -1 0
1
2
3
4
5
6
7
8
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Es/N0 [dB]
Figure 53: DVB-S2 performance for several MODCODs, in LOS channel condition,
Ku band, no spreading, with and high train speed
11.2.2
Forward link spectrum spreading performances
In the following, the impact on performance of the introduction of spread spectrum techniques is presented in terms of
BER and PER. In particular, the following system parameters have been considered:
•
MODCOD: 1/4-QPSK.
•
Chip rate = 27,5Mchip/sec.
•
Symbol rate = Chip rate / Spreading factor.
•
Train speed = 300 km/h.
•
Propagation channel: AWGN and correlated ricean channel with Rice factor = 17 dB.
ETSI
99
•
Satellite HPA IBO = 0,5 dB.
•
No interference from adjacent satellites.
ETSI TR 102 768 V1.1.1 (2009-04)
First of all, the robustness of the DVB-S2 spread signal with respect to non-linear distortion is presented in figure 54
with AWGN channel. The comparison between the spread and non-spread signals highlights that the signal spreading
slightly increases the robustness to non-linear distortion.
Spreading vs No Spreading with non linear HPA
1.00E+00
QPSK 1/4 IBO=2 - SPREADING FACTOR=2
QPSK 1/4 IBO=2 - NOSPREADING
1.00E-01
QPSK 1/4 IBO=0.5 - SPREADING FACTOR=2
QPSK 1/4 IBO=0.5 - NOSPREADING
1.00E-02
BER
1.00E-03
1.00E-04
1.00E-05
1.00E-06
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Eb/N0 [dB]
Figure 54: Comparison between spread and not spread signal in AWGN channel
with the presence of non-linear HPA
The terminal mobility impact on spread waveform performance is analysed in figure 55. The same chip-rate has been
considered, thus the transmission symbol rate is 13,75 Msps and 6,85 Msps for SF = 2 and SF = 4, respectively. As
noted before, spectrum spreading introduces a slight gain with respect to the unspread signal. The real benefit of the
introduction of the spreading factor is in term of link budget, showing a gain of 3 dB and 6 dB for spreading factor 2
and 4, respectively.
1.E+00
1/4 QPSK - LOS, 300 km/h
1.E-01
1/4 QPSK - SF=2
1/4 QPSK - SF=4
PER
1.E-02
1.E-03
1.E-04
1.E-05
-3
-2
-1
0
1
2
3
4
5
6
7
8
Es/N0 [dB]
Figure 55: Comparison between spread and not spread signal in LoS channel
with the presence of non-linear HPA
ETSI
100
ETSI TR 102 768 V1.1.1 (2009-04)
Annex A:
Rate of Beam Roll-Off
A.1
Basics
This annex derives the rate of change of gain experienced when a user moves in a satellite spot beam. Figure A.1 shows
a cross section of the main lobe of a typical beam. For simplicity, we assume that the beam has a Gaussian main lobe.
This is a good approximation for simple circular and elliptical beams. For irregularly shaped beams, the roll-off near the
edge - which is the region of most interest for the present investigation - can often be approximated by a Gaussian
(parabolic in dB) shape.
In a Gaussian beam with 3-dB beam width B3, the gain loss G(Θ) at a position offset from the boresight by an angle Θ
is given by:
⎛Θ⎞
G (Θ ) = 12⎜⎜ ⎟⎟
⎝ B3 ⎠
2
(A.1)
Let Geoc be the contour corresponding to the loss that defines the edge of the beam. Typically, Geoc is between 2 and 6
dB. From (A.1), the edge-of-coverage off-axis distance is:
Θeoc =
Geoc
B3
12
(A.2)
In Figure A.1, the useful beamwidth Bu is illustrated. This is of course given by Bu = 2 Θeoc.
A.1.1
Rate of change
From (A.1), the variation of the gain with Θ is:
G ' (Θ ) =
∂ G (Θ ) 24Θ
= 2
∂Θ
B3
(A.3)
This is the slope in the radial direction. The maximum rate of change occurs at the edge of the beam:
G ' (Θ eoc ) =
NOTE:
A.1.2
24Θeoc 4 3 Geoc
=
B32
B3
(A.4)
These expressions are independent of the units used to express the off-axis distances.
Practical Example
The smallest spot beams produced by current geostationary satellites are of the order of 0,7°. Current limitations on
attitude control accuracy are of the order of ±0,05°. It is therefore unlikely that we will see spot beams much smaller
than, say, 0,4° in the near or medium term. This is particularly the case in Ku-band, which is the main target for this
investigation. At 11 GHz, a beam width of 0,4° requires an aperture diameter of at least 4,8 m. Such a large aperture is
difficult to launch; and the accuracy necessary at this frequency is difficult to achieve with inflatable or unfurlable
apertures. We therefore use 0,4° as a worst-case example of the 3 dB beam width. From geostationary orbit, a
0,4° beam has a diameter of 250 km.
ETSI
101
ETSI TR 102 768 V1.1.1 (2009-04)
We also assume, as a worst case, that the beams are used to the 6 dB contour (This corresponds to a useful diameter Bu
of ~350 km). From (A.4), the gain variation in the radial direction at the 6 dB contour is ~0,068 dB/km. For an aircraft
flying at 1 000 km/hr (0,278 km/s), this corresponds to a maximum slope of just under 0,02 dB/s. In other words; if a
handover can be carried out in 10 seconds, a margin of 0,2 dB for gain variations is sufficient.
A more typical example of current Ku-band satellites has beams with 3 dB width of 1,5°, used to the 4 dB contour. In
such a beam, the maximum slope is 0,015 dB/km, or 0,004 dB/s for the aircraft at 1 000 km/hr.
G(Θ)
B3
3 dB
Geoc
Bu
Θ
Figure A.1: Cross-section of beam with Gaussian shape main lobe
ETSI
102
ETSI TR 102 768 V1.1.1 (2009-04)
Annex B:
Continuous carrier mode vs. MF-TDMA mode comparison
B.1
Introduction
The following clause aims at comparing the DVB-RCS MF-TDMA scheme with the new optional continuous carrier
mode. It gives guidelines on the way to determine when the continuous carrier mode is more efficient compared to the
standard MF-TDMA. It indicates on some concrete scenarios the needed bandwidth for both the cases.
B.2
Hypothesis
B.2.1
Satellite hypothesis
The assumptions for the satellite are the following:
•
Continental Ku spot (5 000 km).
•
Channel Bandwidth 36 MHz.
•
Satellite G/T:
•
-
0 dB/K (End of Coverage) for an Aircraft and Maritime mobile coverage up to 10 dB/K (Center of
Coverage).
-
4 dB/K (End of Coverage) for a Train mobile coverage up to 10 dB/K (Center of Coverage).
High Power Amplifier (HPA) mode:
-
B.2.2
Return link: Fixed Gain Mode (FGM) mode with Noise Power Ratio (NPR) of 18 dB and typically
OBO = 4,0 dB (linearized TWTA).
Terminal hypothesis
The assumptions for the satellite terminal are the following:
•
Satellite terminal antenna size: range from 0,3 m to 1,2 m (long axis size if elliptical).
•
Antenna Tx efficiency of 58 % (typical average value for satellite mobile terminal).
•
Satellite terminal system temperature of 160 K (typical average value for satellite mobile terminal).
•
Antenna radiation pattern based on recommendation ITU-R Recommendation S.1428 [i.35] (applicable for the
Gateway and also applied for the mobile terminal in this analysis).
•
HPA and feeder losses of 1,5 dB.
B.2.3
Regulation constraints
The regulatory constraints [i.19], [i.20], [i.21], [i.22], [i.23], [i.24] and [i.25] are taken into account in the system
dimensioning and they will be considered for the preliminary and final system dimensioning.
They are applicable to the HUB, the satellite and to the satellite terminal with specific constraints for aircraft (AES:
Aircraft Earth Station [i.19]) and Vessel (ESV: Earth Stations on board Vessel [i.21]). These constraints are defined in
terms of limitation on emission at ground level and satellite level in terms of EIRP density.
ETSI
103
ETSI TR 102 768 V1.1.1 (2009-04)
The constraint for the HUB or satellite terminal are defined in terms of:
•
Off-axis EIRP density towards adjacent systems (mobile, fixed and radio astronomic).
•
Minimum elevation angle.
•
Minimum antenna diameter (only for Vessel (ESV)).
•
EIRP and EIRP density towards the horizon.
And interference received at:
•
Ground level: HUB or satellite terminal in terms of Off-axis EIRP density from adjacent satellite ground
system.
•
Satellite level in terms of EIRP density from adjacent satellite.
For each identified constraints per regulatory instance, the reference of the applicable rules has been used. Two
distinctive scenarios in terms of regulatory constrains are analysed: ETSI (European) and FCC (North American).
To be noted that some identified constraints concerning the interference received coming from other terrestrial services
cannot be clearly defined yet. No specific hypotheses have been defined at this time of this analysis.
Moreover, the regulatory constraints defined and used for the system dimensioning are only known general limitations.
Local limitations on emission are identified but as they are specific to the country and the type of interfering services no
specific hypotheses have been taken into account.
B.2.4
System Scenario definition
For the comparison of the different systems, a fixed number of mobiles is considered and then the corresponding needed
bandwidth is computed.
In the following, a pool of 100 mobiles in the system is considered.
The following 3 markets are studied:
•
Aeronautical case: Antenna size of 60 cm and satellite G/T of 0 dB/K.
•
Railway case: Antenna size of 80 cm and satellite G/T of 4 dB/K.
•
Maritime case: Antenna size of 80 cm and satellite G/T of 0 dB/K.
The FCC and ETSI regulation context will be addressed in the analysis.
The 2 possible return link systems are analysed and compared:
•
Classical DVB-RCS system with MF-TDMA access. For FCC regulation compatibility, spectral spreading on
the DVB-RCS waveform is considered. The dimensioning of the system is based on the mean data rate per
mobile.
•
DVB-S2 system with SCPC access method. The dimensioning of the system is based on the peak data rate per
mobile.
B.2.5
Return link budget hypothesis
The general hypotheses for the return link are the following:
•
The link budget is supposed to be in AWGN LOS condition for all mobile type.
•
Symbol rate of up to 2 Msymb/s.
•
System margin of 1,5 dB (corresponding to RF impairments).
ETSI
104
•
ETSI TR 102 768 V1.1.1 (2009-04)
Rain margin of 3 dB for Europe (worst case value in Europe for 99,8 % of availability) and 5 dB for USA
(worst case value in USA for 99,8 % of availability).
For the return link, under rain conditions, the useful terminal to adjacent satellite path is affected by the same rain
attenuation as nominal path.
B.2.6
Traffic scenarii
The considered traffic hypothesis are the following:
•
A mean traffic of 7 kb/s per active end user (Web usage).
•
The number of active users per mobile is around few tens of users.
•
The number of active users per mobile is variable in time and supposed to be independent between mobiles.
Different hypothesis on the number of active users per mobile are considered. They are summarized in table B.1.
Table B.1: Traffic profiles
Traffic
Case
1
2
3
4
5
6
Mean Number of
users
40
60
100
20
30
50
Peak Number of
users
120
120
120
60
60
60
Typical capacity of the
mobile
500 passengers
500 passengers
500 passengers
250 passengers
250 passengers
250 passengers
System usage
(Load per mobile)
Low
Medium
High
Low
Medium
High
The corresponding mean and peak data rate per mobile is given in table B.2.
Table B.2: Traffic Profiles data rate
Traffic Case
1
2
3
4
5
6
Mean data rate per mobile (kb/s)
280
420
700
140
210
350
Peak data rate per mobile (kb/s)
840
840
840
420
420
420
B.3
Return link overall efficiency
B.3.1
MF-TDMA
Peak/Mean data rate ratio
3
2
1,2
3
2
1.2
The global forward link spectral efficiency takes into account:
•
The carrier filtering specified by the roll-off. The following analysis assumes 0,35 for the roll-off.
•
The spectral spreading allowing compliance with the regulation constraints for small antennas. Spreading
factor from 1 to 8 will be considered in the analysis.
•
The MODCOD efficiency depending on the modulation (QPSK) and the coding rate (1/2, 2/3, etc.).
•
The frame efficiency taking into account the bursts guard times, the pre-ambles and the signalling bursts (CSC
and SYNC). It also depends on the carrier symbol rate and the size of the bursts. A typical value is 85 %.
ETSI
105
ETSI TR 102 768 V1.1.1 (2009-04)
•
The IP packets to ATM packets encapsulation efficiency. This efficiency depends on the size of the IP packets.
For the analysis, a mean IP packet size of 1 400 bytes is considered. So, the encapsulation efficiency is around
85 %.
•
The DAMA efficiency. The MF-TDMA access scheme allows to have a very good statistical multiplexing. A
typical value for the DAMA efficiency is 90 %.
The overall efficiency is computed by:
γ Overall =
γ MODCOD ⋅ γ Fra min g ⋅ γ IP / ATM ⋅ γ DAMA
(1 + RollOff ) ⋅ SpreadingFactor
Finally, taking into account all the efficiencies, the overall efficiency is given in table B.3.
Table B.3: MF-TDMA overall efficiency
B.3.2
MODCOD
MODCOD
Efficiency
(Bit/Symb)
Spreading
factor
Spectral
Efficiency
(Bit/s/Hz)
Es/N0 (dB) (PER
= 10-5) a ATM
cells
Spreaded QPSK 1/2
1,00
8,00
0,06
-5,4
Spreaded QPSK 1/2
1,00
6,00
0,08
-4,2
Spreaded QPSK 1/2
1,00
5,00
0,09
-3,4
Spreaded QPSK 1/2
1,00
4,00
0,11
-2,4
Spreaded QPSK 1/2
1,00
3,00
0,15
-1,2
Spreaded QPSK 1/2
or BPSK 1/2
1,00
2,00
0,23
0,6
Spreaded QPSK 2/3
or BPSK 2/3
1,33
2,00
0,30
2,4
QPSK 1/2
1,00
1,00
0.45
3,6
QPSK 2/3
1,33
1,00
0,,61
5,4
QPSK 3/4
1,50
1,00
0,68
6,3
QPSK 4/5
1,60
1,00
0,73
7,3
QPSK 6/7
1,71
1,00
0,78
8,5
Continuous Carrier spectral efficiency
The global spectral efficiency for the continuous carrier mode in the return link takes into account:
•
The carrier filtering specified by the roll-off. We will take 0,2 for the roll-off.
•
The MODCOD efficiency depending on the modulation (QPSK, 8PSK, etc.) the coding rate (1/4, 1/3, 1/2,
etc.), the pilots and the PLHeader.
•
The MPEG-2 packets to BBFrame encapsulation efficiency. This efficiency depends on the data rate variations
(Peak data rate over mean data rate ratio). These ratio depends on the number of users per terminal at a given
time. For the analysis, a raw spectral efficiency is computed taking a value of 1 for the MPEG-2 to BBFrame
encapsulation.
•
The IP packets to MPEG 2 packets encapsulation efficiency. This efficiency depends on the size of the IP
packets and the use (or not) of the section packing technique. For the analysis, a mean IP packet size of
1 400 bytes is considered. Considering the use of the section packing option, the encapsulation efficiency is
around 90 %.
ETSI
106
ETSI TR 102 768 V1.1.1 (2009-04)
The overall efficiency is computed by:
γ Overall =
γ MODCOD ⋅ γ MPEG / BBFrame ⋅ γ IP / MPEG
(1 + RollOff )
Finally, taking into account all the efficiencies, the overall efficiency is given hereunder.
Table B.4: DVB-RCS Continuous Carrier mode overall spectral efficiency
MODCOD
MODCOD
Efficiency
(Bit/Symb)
Overall Spectral
Efficiency
(Bit/s/Hz)
Es/N0 (dB)
QPSK 1/8
0,24
0,18
-,00
QPSK 1/6
0,32
0,24
-3,90
QPSK 1/5
0,38
0,29
-2,57
QPSK 1/4
QPSK 1/3
QPSK 2/5
QPSK 1/2
QPSK 3/5
QPSK 2/3
QPSK 3/4
QPSK 4/5
QPSK 5/6
8PSK 3/5
8PSK 2/3
8PSK 3/4
16APSK 2/3
16APSK 3/4
16APSK 4/5
16APSK 5/6
16APSK 8/9
16APSK 9/10
0,48
0,64
0,77
0,97
1,16
1,29
1,45
1,55
1,62
1,74
1,94
2,18
2,57
2,90
3,09
3,22
3,44
3,48
0,36
0,48
0,58
0,72
0,87
0,97
1.09
1,16
1,21
1,30
1,5
1,63
1.93
2,17
2,32
2,42
2.58
2.61
-1,6
-1
0
1,3
2,5
3,4
4,3
5
5,5
6,2
7
8,3
9,6
10,7
11,6
12,1
13,4
13,6
B.4
Capacity Analysis
B.4.1
Methodology
In order to evaluate the return link capacity, the following methodology is considered:
•
The link budget is constrained by the uplink path (Terminal to satellite), so the main parameters are the
terminal EIRP and the satellite G/T. Another main constraint is the regulation limits. It defines the terminal
maximum power spectral density toward the satellite depending on the terminal antenna size.
•
Taking into account the adjacent system interferences power density, the achievable Es/N0 (Link budget) is
computed at satellite level depending on the terminal antenna size and the satellite G/T.
•
For the train and the maritime case, the rain margin for the achievable Es/N0 is considered.
ETSI
107
ETSI TR 102 768 V1.1.1 (2009-04)
•
After that, using the values in the overall spectral efficiencies, the MODCOD is determined and then the
global spectral efficiency. Considering a transponder of 36 MHz, one can compute easily the useful aggregated
data rate at IP level.
•
Finally, the needed bandwidth for each case considering a fixed system size is computed. The maximum
number of simultaneous mobiles to be considered will be 100. The assessment is done for the 3 markets
(Aeronautical, Railway and Maritime), the 6 traffic load cases and the 2 regulation context (ETSI and FCC).
As far the adjacent satellite terminal interference is considered on the return link, the receive interference power density
at the satellite level over thermal noise ratio is computed from the adjacent system terminal EIRP spectral density level
and the useful satellite G/T in the direction of the adjacent system terminal. The Io/No ratio gives a degradation of the
Es/N0 which is used for the link budget.
B.4.2
Capacity comparison results
B.4.2.1 ETSI Context (European scenario)
The overall spectral efficiency for antenna size from 0,5 m to 0,8 m in the ETSI context is shown in figure B.1.
Total Spectral efficiency vs. Satellite G/T (ETSI Context)
For antenna size from 0,5 to 0,8 m
3.00
DVB-RCS, D = 0.5 m
DVB-RCS, D = 0.6 m
DVB-RCS, D = 0.8 m
2.50
T o t a l s p e c t r a l e f f ic i e n c y ( B i t /s / H z )
DVB-S2 (Raw), D = 0.5 m
DVB-S2 (Raw), D = 0.6 m
2.00
DVB-S2 (Raw), D = 0.8 m
1.50
1.00
0.50
0.00
0
1
2
3
4
5
6
7
8
9
10
Satellite G/T (dB/K)
Figure B.1: Spectral efficiency versus Satellite G/T (for MF-TDMA=DVB-RCS and
Continuous carrier mode = DVB-S2) in the ETSI context
The DVB-S2 based continuous carrier mode shows the best potential capacity with a gain (up to 2,5 Bits/s/Hz)
compared to the classical MF-TDMA DVB-RCS system. But the real capacity depends mainly on the traffic profile
hypothesis. The load of the continuous carrier mode has to be higher than 40 % in order to be more efficient than the
MF-TDMA.
ETSI
108
ETSI TR 102 768 V1.1.1 (2009-04)
The corresponding needed bandwidth for 100 mobiles is given in table B.5.
Table B.5: Required Bandwidth (ETSI context)
la
cit
ua
no
re
A
es
ac
es
ac
ya
w
li
aR
es
ac
e
m
iit
ra
M
The use of continuous carrier in the return link can reduce significantly the needed bandwidth when compared with the
classical DVB-RCS system. The reduction depends on the traffic profile. For high traffic load cases, the continuous
carrier mode reduces the needed bandwidth by a factor 2. But in the case of low traffic loads, this mode can be less
efficient than the MF-TDMA DVB-RCS system.
The aeronautical scenario is the most demanding scenario in terms of bandwidth. This is consistent with the fact that the
antenna size is only 60 cm and the worst case satellite G/T is 0 dB/K. The train scenario is less bandwidth demanding. It
needs only half of the bandwidth needed for the aeronautical scenario.
B.4.2.2 FCC Context (North American scenario)
The overall spectral efficiency for antenna size from 0,5 m to 0,8 m in the ETSI context is in figure B.2.
ETSI
109
ETSI TR 102 768 V1.1.1 (2009-04)
Total Spectral efficiency vs. Satellite G/T (FCC Context)
For antenna size from 0,5 to 0,8 m
1.80
DVB-RCS, D = 0.5 m
DVB-RCS, D = 0.6 m
1.60
DVB-RCS, D = 0.8 m
T o ta l s p e c tr a l e ffic ie n c y (B it/s /H z )
1.40
DVB-S2 (Raw), D = 0.5 m
DVB-S2 (Raw), D = 0.6 m
1.20
DVB-S2 (Raw), D = 0.8 m
1.00
0.80
0.60
0.40
0.20
0.00
0
1
2
3
4
5
6
7
8
9
10
Satellite G/T (dB/K)
Figure B.2: Spectral efficiency vs. satellite G/T (for MF-TDMA=DVB-RCS and
Continuous carrier mode=DVB-S2) in the FCC context
The corresponding needed bandwidth for 100 mobiles is given in table B.6.
Table B.6: Needed Bandwidth (FCC Case)
la
ict
ua
no
re
A
es
ac
es
ac
ya
w
li
aR
es
ac
e
im
tir
a
M
The conclusions are similar to the ETSI case when we compare the different systems. The only difference is that the
needed bandwidth is increased by a factor 3 up to 8 depending on the terminal. The corresponding satellite bandwidth
cost will be also increased by the same factor.
ETSI
110
B.5
ETSI TR 102 768 V1.1.1 (2009-04)
Conclusions
The comparison between standard MF-TDMA and optional continuous carrier mode shows that the efficiency can be
improved by a factor up to 2,5. But, the real efficiency will strongly depends on the traffic load. The carriers shall be
dimensioned with the peak data rate of the mobile terminal but if the mean data rate (load) is lower than 40 % of the full
load, the system is less efficient than the classical MF-TDMA one.
In conclusion, the continuous carrier mode is only well suited to systems with low burstness on the traffic profile.
ETSI
111
History
Document history
V1.1.1
April 2009
Publication
ETSI
ETSI TR 102 768 V1.1.1 (2009-04)