Development of an

SNMP Managing Application for

Adaptation of Coding & Modulation on

DVB-S Satellite Modems

by

Dipl.-Ing. Dr.techn. Gerhard VRISK

Submitted in a partial fulfilment

of the requirements for the degree of

Master of Sciences

of the Post-graduate University Course Space Sciences

(Main Track: Space Communication and Navigation)

Karl-Franzens University of Graz

Graz, Austria

2009

2

Acknowledgments / Danksagung This master thesis has been written at the IKS (Institute of Communication Networks and Satellite Communications / Institut für Kommunikationsnetze und Satellitenkommunikation) at Graz University of Technology in the years 2009. First, I would like to thank my thesis advisor, Univ.-Prof. Dipl.-Ing. Dr. Otto Koudelka, Chair of the IKS, who offered me to work on this subject. Furthermore, I would like to thank (em.)Univ.-Prof. DDr. Willibald Riedler, retired Director of the former Institute of Communications and Wave Propagation at the Technical University of Graz and retired Director of the Space Research Institute of the Austrian Academy of Sciences, for his complaisant attendance to act as 2nd reviewer of this master thesis. Last but not least I would like to thank Univ.-Prof. Dr. Helmut Rucker, Research Director at the Space Research Institute of the Austrian Academy of Sciences, especially for his support during the course and generally for organization and managing the 4th MSc University Course Space Sciences. A big kiss goes to my wife Gerlinde for her support und patience during my studies and for the photographs, too. Am Schluss möchte ich mich noch bei meinen Eltern bedanken, für all die Förderung von früh an und für ihre Unterstützung während meinen Studienzeiten. Meinem Vater gewidmet († 2006). Graz, Winter 2008 - 2009

3

Abstract The aim of this master thesis was to develop a software for automated adaption of coding and modulation (called ACM), implemented for DVB-S (Digital Video Broadcasting over Satellite) satellite modems. This software should control transmission parameters and initiate a countermeasure when some fading on the satellite transmission channel appears (by rain, etc.). As satellite modem hardware PARADYN’s DMD20 Universal Satellite Modem was chosen, at which an enhanced set of the DVB-S protocol was yet available, namely DVB-DSNG (Digital Satellite News Gathering). In the first step as preliminary work the performance characteristics of the different feasible combinations of implemented modulations (BPSK, QPSK, 8PSK, 16QAM) and codes (Viterbi, Trellis) of the used satellite modem was to determine. For this reason a test setup was built. There the well-known characteristics of BER (Bit Error Rate) vs. Eb/N0 (Ratio between the Energy per Information Bit and Power Spectral Density) were measured. For this purpose a C++ class was written to communicate with the satellite modem via the IP protocol SNMP (Simple Network Management Protocol), based on a vendor-specific enterprise MIB (Message Information Base). The goal of these measuring series was to find the appropriate code and modulation pair for a specified bit error rate. However, a correction of these retrieved Eb/N0 values, which were estimated originally by the satellite modem, was necessary, depending on utilized modulation. As final step a more-or-less heuristic closed-loop controller strategy was programmed, based on the preliminary measurement data. There the controller distinguishes by means of the currently estimated Eb/N0 value and a look-up table of pre-defined reference Eb/N0 values about the used code and modulation pair to keep a particular bit error rate (e.g. 10-6). As implication the utilized bandwidth is manipulated indirectly to transmit a forced constant data rate. That means in this actual test scenario, when a transmission channel becomes worse there is more bandwidth, respectively a higher symbol rate necessary - to sustain a constant end-to-end stream of bits per seconds. To improve the stability of the controller behavior there were some enhancements implemented, like hysteresis or dampening. Also the trend of collected Eb/N0 values, accumulated in an observation interval, could be used as basis for follow-up statistical considerations. Accomplished performance improvement could be shown by a number of manual simulations in a simple test setup, whereas several optional parameters of the controller program were varied. On the other hand one can realize that this discrete out-of-band closed-loop implementation has a drawback compared to the high-performance intrinsic implementation of Adaptive Coding & Modulation (ACM) in the next-generation DVB-S2 standard. The reason is the recurrent down-time in the end-to-end transmission each time after changing the modulation or code type caused by new locking between transmitter and receiver.

4

Zusammenfassung Das Ziel der vorliegenden Master Thesis war die Entwicklung einer Software zur automatischen Adaptierung von Kodierung & Modulation eines DVB-S (Digital Video Broadcasting over Satellite) Satellitenmodems. Diese Software soll an Hand von Übertragungsparametern die Qualität des Übertragungskanals der Satellitenstrecke überwachen und Gegenmaßnahmen initiieren wenn dort ein Schwund (z.B. hervorgerufen durch Regen) auftritt. Als Hardware wurde das DMD20 Universal Satellite Modem der Fa. PARADYN ausgewählt, welches zusätzlich sogar über ein erweitertes DVB-S Protokoll, nämlich DVB-DSNG (Digital Satellite News Gathering), verfügte. Als Vorarbeit wurden die Kennlinien des verwendeten Satellitenmodems, in allen implementierten Kombinationsvarianten von Modulierung (BPSK, QPSK, 8PSK, 16QAM) und Kodierung (Viterbi, Trellis), ermittelt. Dafür wurde eine Testumgebung aufgebaut, in der die bekannten BER (Bitfehlerrate) vs. Eb/N0 (Verhältnis von Energie pro Informationsbit zu spektraler Leistungsdichte) Kennlinien gemessen wurden. Zum Zweck der Kommunikation mit dem Satellitenmodem wurde eine eigene C++ Klasse geschrieben, basierend auf dem IP Protokoll SNMP (Simple Network Management Protocol) und einer herstellerspezifischen MIB (Message Information Base). Das Ziel dieser Messreihen war nun die Bestimmung des passenden Kodierung & Modulation Paares jeweils zu einer vorgegebenen Bitfehlerrate. Jedoch war auch eine nachträgliche Korrektur dieser ausgelesenen Eb/N0 Werte, welche ja vom Satellitenmodem nur geschätzt werden, in Abhängigkeit der Modulation notwendig. Im zweiten Schritt wurde nun eine mehr oder weniger heuristische Strategie eines Reglers, basierend auf den vorher ermittelten Messdaten, programmiert. Der Regler entscheidet an Hand des momentanen Eb/N0 Wertes aus dem Satellitenmodem und einer vordefinierten Matrix von Referenzwerten über den passenden Kodierung- und Modulationstyp, um eine bestimmte Bitfehlerrate (z.B. 10-6) zu halten. Die Folge davon ist, dass jeweils die verwendete Bandbreite geändert wird um eine eingeprägte konstante Datenrate übertragen zu können. D.h. in diesem konkreten Testszenario, wenn der Übertragungskanal schlechter wird, wird mehr Bandbreite, bzw. eine höhere Symbolrate benötigt, um einen Datenstrom mit gleich bleibender Rate (d.h. Bits pro Sekunde) Ende-zu-Ende übertragen zu können. Zur Erhöhung der Stabilität des Reglerverhaltens wurden einige Eigenschaftsverbesserungen implementiert, wie z.B. eine Hysteresis oder auch eine Verzögerung der auftretenden Schaltzustände. Auch eine statistische Trendanalyse, basierend auf den ermittelten Werten in einem bestimmten Messintervall, kann herangezogen werden. An Hand einiger manuell durchgeführter einfacher Testläufe, wobei jeweils Parametrisierungen verändert worden sind, konnten die dadurch erreichten Verbesserungen im Verhalten des Reglers gezeigt werden. Jedoch sieht man auch den Nachteil einer externen Regelung im Vergleich zu einer inhärenten Adaptierung von Kodierung & Modulation wie im neuen DVB-S2 Standard beschrieben (ACM). Der Grund sind die auftretenden Unterbrechungen in der Ende-zu-Ende Kommunikation bei jedem Modulierungs- oder Kodierungswechsel, hervorgerufen durch das Neusynchronisieren von Sender und Empfänger.

5

Table of Contents Acknowledgments / Danksagung............................................................................................... 2 Abstract ...................................................................................................................................... 3 Zusammenfassung...................................................................................................................... 4 Table of Contents ....................................................................................................................... 5 References .................................................................................................................................. 6

ETSI Standards....................................................................................................................... 7 RFC Standards........................................................................................................................ 9

List of Abbreviations................................................................................................................ 10 1. Introduction ...................................................................................................................... 12

1.1. DVB History ............................................................................................................ 12 1.2. DVB Suite ................................................................................................................ 15

2. Satellite Communication.................................................................................................. 19 2.1. Digital Communications Overview.......................................................................... 19 2.2. Satellite Link Budget Calculations........................................................................... 23

3. Simple Network Management Protocol (SNMP)............................................................. 26 3.1. SNMP Introduction .................................................................................................. 26 3.2. SNMP Applications.................................................................................................. 28 3.3. Used MIB Object Identifications (OIDs) ................................................................. 30

3.3.1. WRITEable Values .......................................................................................... 31 3.3.2. READable Values ............................................................................................ 32

4. DVB-S.............................................................................................................................. 33 4.1. DVB-S System Architecture .................................................................................... 33 4.2. DVB-DSNG System Architecture ........................................................................... 35 4.3. DVB-S2 System Architecture .................................................................................. 36 4.4. Performance Comparison......................................................................................... 42

5. Managing the Satellite Modem ........................................................................................ 45 5.1. Basic Configurations ................................................................................................ 46 5.2. Data Collection......................................................................................................... 48

5.2.1. Developed Managing Application <mt1.exe > ............................................. 48 5.2.2. Measuring Series .............................................................................................. 50 5.2.3. Discussion of the Output Values of the Satellite Modem ................................ 56 5.2.4. Correcting the Estimator of the Satellite Modem............................................. 58 5.2.5. Resulting Eb/N0 Threshold................................................................................ 61

5.3. Controller Implementation ....................................................................................... 64 5.3.1. Developed Managing Application <mt2.exe> ............................................. 64 5.3.2. Controller Concept ........................................................................................... 69 5.3.3. Hardware-based Simulations............................................................................ 73

6. Conclusions and Outlook ................................................................................................. 75 Appendix A: SNMP MIBs ....................................................................................................... 77

Appendix A.1: DMD20 MIB Subtree Definitions ............................................................... 77 Appendix A.2: DMD20 MIB ............................................................................................... 81 Appendix A.3: RFC Default MIB ........................................................................................ 86

Appendix B: Modem Characteristics ....................................................................................... 89 Appendix B.1: RADYNE DMD20 Modem Reference Characteristics............................... 89 Appendix B.2: Listings of Measured Values ....................................................................... 89

Appendix C: Cookbook............................................................................................................ 99

6

References [ALBERTAZZI ] Albertazzi G., et al, “ON THE ADAPTIVE DVB-S2 PHYSICAL LAYER:

DESIGN AND PERFORMANCE“, IEEE Wireless Communications, December 2005

[ALBERTY ] Alberty E., et al, “ADAPTIVE CODING AND MODULATION FOR THE DVB-S2 STANDARD INTERACTIVE APPLICATIONS: CAPACITY ASSESSMENT AND KEY SYSTEM ISSUES“, Wireless Communications, IEEE Volume 14, Issue 4, August 2007, pp.61-69

[BREYNAERT ] Breynaert D., Lantremange M.d’O., “Analysis of the bandwidth efficiency of DVB-S2 in a typical data distribution network”, CCBN2005, Beijing, March 21-23 2005 (modified)

[DIG ] Digitalradiotech, “Introduction to Block FEC Coding for Broadcasting Applications”; http://digitalradiotech.co.uk/fec_coding.htm

[DVB] Digital Video Broadcasting Project, “History of the DVB Project”; www.dvb.org

[DVB-08a] Digital Video Broadcasting Project, “DVB Fact Sheets: DVB Project – An Introduction”, April 2008; www.dvb.org

[DVB-08b] Digital Video Broadcasting Project, “DVB Fact Sheets: DVB S2 – 2nd Generation Satellite”, April 2008; www.dvb.org

[FAIRHURST ] Fairhurst G., “A NETWORK-LAYER INTERFACE TO THE SECOND GENERATION STANDARD FOR DVB OVER SATELLITE“, printed and published by the Institution of Engineering and Technology, University of Aberdeen, UK

[GALLAGER-62 ] Gallager R.G., “Low-Density Parity-Check Codes”, IRE TRANSACTIONS ON INFORMATION THEORY, IT-9, pp. 21-28, January 1962

[GALLAGER-63 ] Gallager R.G., “Low-Density Parity-Check Codes”, Sc.D.thesis, Mass. Inst. Tech., Cambridge; September 1960; expanded and revised version, MIT Press, July 1963

[GARDIKIS ] Gardikis G., Zotos N., Kourtis A., “Triple Play Services Delivery over a DVB-S2/ RCS Satellite Network“, presented in 16th IST Mobile and Wireless Summit, Budapest, Hungary, July 1-5, 2007

[GEO] GEO-Orbit Quick Look, “Noise, Signal Loss and TI”; www.geo-orbit.org

[KOFLER ] Kofler Thomas, “Entwicklung eines Satellitensimulators”, Master Thesis, IKS / TU Graz, DA28 / 2005

[KOUDELKA-a ] Koudelka O., ”Information Theory and Coding”, Lecture Notes, IKS / TU Graz, 2007-2008

[KOUDELKA-b ] Koudelka O., ”Satellite Communications”, Lecture Notes, IKS / TU Graz, 2008

[LIOLIS ] Liolis K.P., Bolea-Alamanac A., Morlet C., Ginesi A., “ Applicability of Fade Mitigation Techniques to Mobile DVB-S2/RCS Satellite Systems: Accent on Railway Scenario“, International Workshop on Satellite and Space Communications, IWSSC '07, Salzburg, September 2007, pp.1-5

[MARAL ] Maral G., Bousquet M., “Satellite Communications Systems”, 4th ed., Wiley, 2006

[MAYER ] Mayer A., Collini-Nocker B., Vieira F., Lei J., Vaizquez Castro M.A., “Analytical and Experimental IP Encapsulation Efficiency Comparison of GSE, MPE and ULE over DVB-S2“, International Workshop on Satellite and Space Communications, IWSSC '07, Salzburg, September 2007, pp.114-118

7

[MORELLO ] Morello A, Mignone V., “DVB-S2: The Second Generation Standard for Satellite Broad-band Services“, PROCEEDINGS OF THE IEEE, Vol. 94/1, January 2006

[MORLET ] Morlet C., Ginesi A., “Introduction of Mobility Aspects for DVB-S2/RCS Broadband Systems“, International Workshop on Satellite and Space Communications, September 2006, pp.93-97

[PEREZ] Perez-Neira A., Campalans M.R., “Cross-Layer Resource Allocation in Wireless Communications”, Academic Press, 2008

[RAD-a] RADYNE, „DMD20/DMD20 LBST Universal Satellite Modem, Installation and Operation Manual, TM103, Revision 2.8”, http://www.radyne.net/tech_docs.aspx

[RAD-b] RADYNE, “Remote Protocol for the DMD20/ DMD50/ DMD2050/ DMD1050/ OM20 Manual, TM117, Revision 5.1”; http://www.radyne.net/tech_docs.aspx

[RIEDLER ] Riedler W., Leitgeb E., ”Antennen und Wellenausbreitung”, Lecture Notes, IKS / TU Graz, 2008-2009

[SKLAR ] Sklar B., “Digital Communications”, 2nd ed., Prentice-Hall, 2006

[STIENSTRA] Stienstra A., “Technologies for DVB Services on the Internet“, PROCEEDINGS OF THE IEEE, Vol. 94/1, January 2006

[ZKM ] Deutsche Bundespost, “Beschreibung des Labormessplatzes für das zusätzliche Kommunikationsmodul (ZKM) des DFS Kopernikus“, IKS / TU Graz

ETSI Standards Available at ETSI Publications Download Area: http://pda.etsi.org/pda/queryform.asp European Standard (Telecommunications series): [EN 300 421] “Digital Video Broadcasting (DVB); Framing structure, channel coding and

modulation for 11/12 GHz satellite services“, V1.1.2 (1997-08)

[EN 300 429] “Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for cable systems”, V1.2.1 (1998-04)

[EN 300 744] “Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for digital terrestrial television”, V1.5.1

[EN 301 192] “Digital Video Broadcasting (DVB); DVB specification for data broadcasting”, V1.4.2 (2008-04)

[EN 301 193] “Digital Video Broadcasting (DVB); Interaction channel through the Digital Enhanced Cordless Telecommunications (DECT)”, V1.1.1 (1998-07)

[EN 301 195] “Digital Video Broadcasting (DVB); Interaction channel through the Global System for Mobile communications (GSM)”, V1.1.1 (1999-02)

[EN 301 199] “Digital Video Broadcasting (DVB); Interaction channel for Local Multi-point Distribution Systems (LMDS)”, V1.2.1 (1999-06)

[EN 301 210] ”Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for Digital Satellite News Gathering (DSNG) and other contribution applications by satellite”, V1.1.1 (1999-03)

8

[EN 301 790] “Digital Video Broadcasting (DVB); Interaction channel for satellite distribution systems”, V1.4.1 (2005-09)

[EN 301 958] “Digital Video Broadcasting (DVB); Interaction channel for Digital Terrestrial Television (RCT) incorporating Multiple Access OFDM”, V1.1.1 (2002-03)

[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”, V1.1.2 (2006-06)

[ETS 300 800] “Digital Video Broadcasting (DVB); Interaction channel for Cable TV distribution systems (CATV)”, ed.1 (1998-07)

[ETS 300 801] “Digital Video Broadcasting (DVB); Interaction channel through Public Switched Telecommunications Network (PSTN)/ Integrated Services Digital Networks (ISDN)”, ed.1 (1997-08)

[ETS 300 802] “Digital Video Broadcasting (DVB); Network-independent protocols for DVB interactive services”, ed.1 (1997-11)

Technical Reports & Specifications: [ETR 154] “Digital Video Broadcasting (DVB); Implementation guidelines for the use of

MPEG-2 Systems, Video and Audio in satellite, cable and terrestrial broadcasting applications”, ed.3 (1997-09)

[TR 101 194] “Digital Video Broadcasting (DVB); Guidelines for implementation and usage of the specification of network independent protocols for DVB interactive services”, V1.1.1 (1997-06)

[TR 101 196] “Digital Video Broadcasting (DVB); Interaction channel for Cable TV distribution systems (CATV); Guidelines for the use of ETS 300 800”, V1.1.1 (1997-12)

[TR 101 200] ”Digital Video Broadcasting (DVB); A guideline for the use of DVB specifications and standards”, V1.1.1 (1997-09)

[TR 101 201] “Digital Video Broadcasting (DVB);Interaction channel for Satellite Master Antenna TV (SMATV) distribution systems; Guidelines for versions based on satellite and coaxial sections”, V1.1.1 (1997-10)

[TR 101 205] “Digital Video Broadcasting (DVB); LMDS Base Station and User Terminal Implementation Guidelines for ETSI EN 301 199“, V1.1.2 (2001-07)

[TR 101 221] “Digital Video Broadcasting (DVB); User guideline for Digital Satellite News Gathering (DSNG) and other contribution applications by satellite”, V1.1.1 (1999-03)

[TR 101 790] ”Digital Video Broadcasting (DVB); Interaction channel for Satellite Distribution Systems; Guidelines for the use of EN 301 790”, V1.3.1 (2006-09)

[TR 102 376] “Digital Video Broadcasting (DVB); User guidelines for the second generation system for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications (DVB-S2)”, V1.1.1 (2005-02)

[TS 102 034] “Digital Video Broadcasting (DVB); Transport of MPEG-2 based DVB Services over IP based Networks”, V1.3.1, (2007-10)

[TS 102 441] “Digital Video Broadcasting (DVB); DVB-S2 Adaptive Coding and Modulation for Broadband Hybrid Satellite Dialup Applications“, V1.1.1 (2005-10)

9

RFC Standards Available at RFC Editor Database: http://www.rfc-editor.org/rfc.html [RFC 1065] “Structure and Identification of Management Information for TCP/IP-based

Internets”

[RFC 1066] “Management Information Base for Network Management of TCP/IP-based Internets”

[RFC 1155] “Structure and Identification of Management Information for TCP/IP-based Internets”

[RFC 1157] “A Simple Network Management Protocol”

[RFC 1213] “Version 2 of Management Information Base (MIB-2) for Network Management of TCP/IP-based Internets”

10

List of Abbreviations 8PSK 8 Phase-shift Keying 16QAM 16 Quadrature Amplitude Modulation 16APSK 16 Amplitude and Phase-shift Keying 32APSK 32 Amplitude and Phase-shift Keying ACM Adaptive Coding & Modulation BB Base-Band BCH Bose-Chaudhuri-Hocquenghem Coder BER Bit Error Rate BPSK Binary Phase-shift Keying BSS Broadcast Satellite Service CATV Cable Television CCM Constant Coding & Modulation CM Coding & Modulation Pair CR Coding Rate DBS Direct Broadcast Satellite DECT Digital Enhanced Cordless Telecommunications DFS Deutscher Fernmeldesatellit DSM-CC Digital Storage Media Command and Control DSNG Digital Satellite News Gathering DTH Direct-To-Home DTVC/DSNG Digital TV Contribution and Satellite News Gathering DVB Digital Video Broadcasting DVB-ASI Digital Video Broadcasting – Asynchronous Serial Interface DVB-C Digital Video Broadcasting – Cable DVB-C2 Digital Video Broadcasting – Cable (2nd generation) DVB-DSNG Digital Video Broadcasting – Digital Satellite News Gathering DVB-H Digital Video Broadcasting – Handheld DVB-IPTV Digital Video Broadcasting – Internet Protocol Television DVB-MPEG Digital Video Broadcasting – MPEG DVB-NIP Digital Video Broadcasting – Network-independent protocols for DVB interactive services DVB-RC Digital Video Broadcasting – Return Channel DVB-RCC Digital Video Broadcasting – Return Channel via Cable DVB-RCCS Digital Video Broadcasting – Return Channel for satellite and Coax cable Sections DVB-RCD Digital Video Broadcasting – Return Channel via DECT DVB-RCG Digital Video Broadcasting – Return Channel via GSM DVB-RCL Digital Video Broadcasting – Return Channel via LMDS DVB-RCP Digital Video Broadcasting – Return Channel via PSTN DVB-RCS Digital Video Broadcasting – Return Channel via Satellite DVB-RCT Digital Video Broadcasting – Return Channel via Terrestrial DVB-S Digital Video Broadcasting – Satellite DVB-S2 Digital Video Broadcasting – Satellite (2nd generation) DVB-SH Digital Video Broadcasting – Satellite services to Handhelds DVB-SI Digital Video Broadcasting – Service Information DVB-SMATV Digital Video Broadcasting – Satellite Master Antenna Television DVB-SUB Digital Video Broadcasting – Subtitling DVB-T Digital Video Broadcasting – Terrestrial DVB-T2 Digital Video Broadcasting – Terrestrial (2nd generation) EIRP Equivalent Isotropic Radiated Power ETSI European Telecommunications Standards Institute FEC Forward Error Correction FSS Fixed Satellite Service GEO Geostationary Orbit GSM Global System for Mobile Communications HDTV High-definition Television IBS INTELSAT Business Service IF Intermediate Frequency

11

IKS Institut für Kommunikationsnetze und Satellitenkommunikation, TU Graz (Institute of Communication Networks and Satellite Communications, Technical University Graz) IP Internet Protocol IRD Integrated Receiver Decoders ISDN Integrated Services Digital Network LDPC Low-Density Parity-Check Coding LMDS Local Multipoint Distribution Service Mbps Megabits per Seconds MIB Management Information Base for SNMP MPEC Moving Picture Experts Group MSB Most Significant Bit OID MIB Object Identifier PER Packet Error Rate PSK Phase-shift Keying QAM Quadrature Amplitude Modulation QPSK Quadrature Phase-shift Keying PL Physical Layer PSTN Public Switched Telephone Network RFC Requests for Comments RS Reed-Salomon Block Coding RX Receiver SDTV Standard Digital Television SMATV Satellite Master Antenna Television SMI Structure of Management Information for SNMP SNMP Simple Network Management Protocol SNR Signal-to-Noise Ratio sps Symbols per Seconds TCP/IP Transmission Control Protocol of IP TDM Time Division Multiplexing TX Transmitter UDP User Datagram Protocol of IP VCM Variable Coding & Modulation xDSL Digital Subscriber Line ZKM Zusätzliches Kommunikationsmodul

12

his master thesis Development of an SNMP Managing Application for Adaptation of Coding & Modulation on DVB-S Satellite Modems is structured as follows. In the first section a short introduction is given to the genesis of the Digital Video Broadcasting

(DVB) project and an overview about the DVB suite. In the second section some theoretical aspects of satellite communications are presented briefly. In the third section a short introduction is given to the topic of managing remotely IP devices. In the fourth section the DVB-over-Satellite (DVB-S) protocol and two different flavors are described in detail. Finally, the practical work which was accomplished is described, comprises the task of the measurement of satellite modem characteristics and the objective to write and implement an adaptive code & modulation controller software. The last section presents the conclusions and outlook of this work.

1. Introduction

1.1. DVB History Towards the end of 1991, TV broadcasters, satellite equipment manufacturers and regulatory authorities in Europe came together to examine the formation of a working group that would supervise the introduction of Digital Television. That working group realised that a consensus-based framework, through which all of the key players could agree on the appropriate technologies to be used, would profit everybody involved. A Memorandum of Understanding was signed in September 1993 about Digital Video Broadcasting (DVB), setting out the base on which competitors in the market would come together (“in a spirit of trust and mutual respect”) - and the DVB Project was born [DVB]. A key report from the working group on Digital Television was also fundamental to setting out central concepts that would go on to profile the introduction of Digital TV in Europe, and finally worldwide. The success of the DVB Project is based on a number of key principles. The Commercial Module determines what specifications the market need, determine a set of commercial requirements for each specification, without considering how such requirements could be met technically. The Technical Module is tasked with determine a technical specification which meets these requirements. Each the Commercial and Technical Module has a set of sub-groups focused on each particular working area. Once a draft technical specification has been reviewed by the Commercial Module it is sent to the DVB Project’s steering board for final approval before being sent for formal standardisation, usually by ETSI (European Telecommunications Standards Institute)1. The first phase of DVB’s effort involved establishing standards to enable the delivery of digital TV to the consumer via “traditional” broadcast networks, i.e. diverse technical specifications for the transmission of baseband signals via all different kinds of broadcast delivery channels. Thus, the three key and core standards developed during this phase were DVB-S [EN 300 421] for satellite networks2, DVB-C [EN 300 429] for cable networks and DVB-T [EN 300 744] for terrestrial networks. In addition to these, a complete series of

1 Published by a Joint Technical Committee (JTC) of European Telecommunications Standards Institute (ETSI), European Committee for Electrotechnical Standardization (CENELEC) and European Broadcasting Union (EBU) 2 The world’s first digital satellite TV services were launched in Thailand and South Africa at the end of 1994 and both used the newly released DVB-S system [DVB-08a]

T

13

secondary supporting standards was essential covering areas such as service information (DVB-SI), subtitling (DVB-SUB), interfacing (e.g. DVB-ASI), etc. Interactive TV, one of the key advances enabled by the change from analogue to digital, required the design of a set of interaction (i.e. return) channel standards (DVB-RCx) and the Multimedia Home Platform (MHP), DVB’s open middleware specification1. However, many of the service offers promising in the DVB world will require some form of interaction between, e.g. the user and either the service provider or the network operator. This interaction may consist of the transmission of just few data but may be widespread and may be similar to interactive communication via the global internet. DVB then introduces network convergence through the development of standards using new technologies that allow the delivery of DVB services over fixed and wireless telecommunications networks (e.g. DVB-H for mobile TV, DVB-IPTV). In 2004 DVB approved the first edition of the DVB IP Handbook [TS 102 034], intended to support the first commercial deployments of Internet TV services. There the specifications standardize technologies at the receiver interface, to enable TV, radio, and generally interactive multimedia services over IP-based networks2. DVB-DSNG Around 1996 / 1997 many operators started using the successful DVB-S standard [DVB] for the deployment of special DSNG (Digital Satellite News Gathering) services over satellites. These DSNG and Digital TV contribution applications by satellite consist of point-to-point or point-to-multipoint transmissions, connecting fixed or mobile uplink and receiving stations, not intended to be received by public3. While not specifically designed for such operations, the DVB-S standard performed quite well. In July 1997, the Technical Module of the DVB Project established an informal group on Digital Satellite News Gathering under the chairmanship of the RAI4. Its objective was to define the specification of advanced modulation and channel coding for DSNG and other satellite contribution applications. As a matter of fact, the practical implementation led finally to DVB adding extensions to DVB-S, DVB-SI and MPEG by the DVB-DSNG Group to maintain these services, standardized in EN 301 210 and TR101 221. Now DSNG systems permit multiple signals to be transmitted simultaneously through the satellite transponders, increasing drastically the flexibility of the transponder access, and reducing the cost per channel. This flexibility of DSNG systems allows fulfilling different quality requirements by operating at the most appropriate bit rate. Moreover, the ruggedness of a digital system against noise and interference enables continuous picture and sound quality to be obtained at the receiving site, down to a certain signal level threshold. DVB-S2 Over time DVB-S has become the most popular system for the delivery of digital satellite television, with more than 100 million receivers5 deployed around the world. Nonetheless, with the system being more than ten years old, it is not surprising that the industry sooner or

1 Which allows applications that were written by different content providers to run on receivers and set-top-boxes of different manufacturers in a predictable form and with the same look and feel 2 An overview of the technologies for DVB services on the internet is described in [STIENSTRA]

3 Light-weight satellite news-gathering transmit terminals – with 90 to 150 cm antennas – offer a cost-effective solution to establishing rapid connections between outside broadcast vans and TV studios without requiring local access to the fixed telecom network 4 Radiotelevisione Italiana 5 Status April 2008 [DVB-08a]

14

later decided the time was right to update a legacy system. Thus DVB-S2 (standardized in ETSI European Standard EN 302 307, which was ratified in March 2005) was developed, with the DVB Technical Module sub-group responsible for the work being chaired by Dr. Alberto Morello of RAI. The objective was to take improvement of advanced techniques for modulation and error correction channel coding to create a new system that would make a set of new services commercially practical for the first time [MORELLO], e.g. when combined with the latest video compression technology, so DVB-S2 would enable the commercial launch of HDTV services. DVB-S2 will not replace DVB-S in the short or even the medium term, but makes possible the delivery of (multimedia) services that “could never have been delivered using DVB-S” [DVB-08], e.g. an increased variety of applications by combining the functionality of DVB-S for direct-to-home residential applications and DVB-DSNG for professional applications. Return Channel The DVB Project also works on providing interactivity to DVB systems. Interactivity permits a user to access to more complex services; some examples are TV on demand, internet access, etc. E.g. bi-directional internet services need to establish a communication between the user and the service provider over what is called an interactive or return channel. An interactive service thus accepts inputs from the end user and responds to him. This return channel must be different from the broadcast channel as the latter is a unidirectional channel. This will enable the user to react to interactive services by sending data back to the interactive service provider over this return channel. Besides audio and video transmission, DVB also defines data connections [EN 301 192] with return channels (DVB-RCx) for several transmission media (DECT, GSM, PSTN/ISDN, etc.) to create bi-directional communication. An interactive channel can also be set up for satellite distribution systems (DVB-RCS). Currently, this kind of system is used mainly in business-to-business environments as the transmission of data to a satellite needs a quite expensive satellite interactive terminal. Another key scenario for interactivity is for interactive point-to-point applications, such as IP unicasting, where a further increase in the spectrum utilization efficiency of DVB-S2 over DVB-S is possible: the Adaptive Coding & Modulation (ACM ) functionality allows optimizing the transmission parameters for each individual user on a frame-by-frame basis, dependent on path conditions, under closed-loop control via a return channel. Studies have shown that in a typical example of unicast solutions for Ku-band transmissions to multiple sites, the use of DVB-S2 with ACM allows an increase of overall satellite transmission capacity of up to 130%. In case of satellite Ka-band links to multiple sites in regions with heavy rainfall, the improvement could even be higher [BREYNAERT]. Furthermore, the combination of DVB-S2 and DVB-RCS provides a very efficient interactive access platform for IP-based satellite applications and approves the migration of triple play services (i.e. TV/video, data and voice telephony) to the satellite sector. Triple play is today implemented on the Last Mile mostly via terrestrial wired access infrastructures, like xDSL (ADSL2+). However, there exist a considerable percentage of customers living in rural or isolated areas which are not covered by these terrestrial infrastructures. The same holds for customers on the move1 and such passengers as in trains2, airplanes or ships. For all these cases, the satellite access solution is promising for the delivery of ubiquitous broadband integrated services [GARDIKIS]. 1 Compare mobility aspects for DVB-S2/RCS described in [MORLET] 2 About fade mitigation techniques in railway scenario see [LIOLIS]

15

1.2. DVB Suite DVB (Digital Video Broadcasting) is a suite of internationally accepted European consortium standards for digital television originally. These standards define the physical layer and data link layer of the distribution system. Primary MPEG-2 for source coding was selected, i.e. mostly all data are usually transmitted in MPEG-2 transport streams with some additional constraints (DVB-MPEG)1 [ETR 154]. DVB systems distribute data using a variety of approaches, including by satellite (DVB-S, DVB-S2 and DVB-SH; also DVB-SMATV for distribution via SMATV); cable (DVB-C, DVB-C2); terrestrial television (DVB-T, DVB-T2) and digital terrestrial television for handhelds (DVB-H, DVB-SH). These distribution systems differ mainly in the modulation schemes and error correcting codes used, due to different technical constraints (e.g. DVB-S uses PSK and DVB-C uses QAM for modulation / constellation). In addition to audio and video, DVB also defines data transmission [EN 301 192] with return channels (DVB-RCx) for several communication media (DECT, GSM, PSTN/ISDN, satellite) to create bi-directional communication. Table 1.1 lists the set of the different specifications for return channels specified in DVB. Additionally, referring standards and implementation guidelines are also listed.

DVB acronym Standard Implementation

guidelines Network independent DVB-NIP ETS 300 802 TR 101 194 PSTN / ISDN DVB-RCP ETS 300 801 DECT DVB-RCD EN 301 193 GSM DVB-RCG EN 301 195 CATV DVB-RCC ETS 300 800 TR 101 196 LMDS DVB-RCL EN 301 199 TR 101 205 Satellite DVB-RCS EN 301 790 TR 101 790 SMATV DVB-RCCS TR 101 201 Terrestrial DVB-RCT EN 301 958

Tab. 1.1: Set of specifications for return channels in DVB

Generally, in DVB the tools for enabling interaction have been split into two sets. One is network-independent (DVB-NIP) and can be regarded as a protocol stack which extends approximately via OSI layers two to three [ETS 300 802]. An important part of this stack was derived from the Digital Storage Media Command and Control protocols (DSM-CC) created by MPEG. The second group of DVB specifications relates to the lower layers (approximately one to two) of the OSI model and therefore specifies the network-dependent tools for interactivity - hence different specifications have been created (see Table 1.1): One describes ways how to use PSTN and ISDN as physical networks for interaction [ETS 300 801] (DVB-RCP). The next specification (DVB-RCD) describes how cordless telephone systems operating in compliance with the European standard for DECT can be used as return and interaction channels [EN 301 193]. EN 301 195 (DVB-RCG) describes how the mobile telecommunications system GSM can be used as a return and interaction channel 1 It includes restrictions to the syntax and parameter values described by MPEG-2 as well as recommendations for preferred values for the use in DVB applications

16

supplementary to DVB broadcasts. This specification is mainly relevant if the user is mobile like, for instance, in a car equipped with a DVB receiver. Another European standard (DVB-RCC) deals with a widespread solution for the use of CATV networks for bi-directional data communication [ETS 300 800]. Guidelines for the use of this system are described in TR 101 196. In EN 301 199 a subset of DVB-RCC is described (DVB-RCL) by which interactive services are being made possible in LMDS. Guidelines for a version of an interaction channel based on satellite and coaxial sections (DVB-RCCS), which can be used in some SMATV distribution systems, are available in TR 101 201. Furthermore, an interaction channel via satellite (DVB-RCS) has been developed and is described in EN 301 790.

DVB-S

The satellite member of the DVB family, DVB-S, is defined in European Standard EN 300 421. In particular it the modulation and channel coding system for satellite digital multi programme Television (TV) / High Definition Television (HDTV) services to be used for primary and secondary distribution in Fixed Satellite Service (FSS) and Broadcast Satellite Service (BSS)1 bands (Table 1.2).

Radiocommunications Service

Typical Frequency Bands (Uplink / Downlink)

Usual Terminology

6 / 4 GHz C band 8 / 7 GHz X band

14 / 12 - 11 GHz Ku band 30 / 20 GHz Ka band

Fixed Satellite Service (FSS)

50 / 40 GHz V band 2 / 2.2 GHz S band

12 GHz Ku band Broadcast Satellite

Service (BSS) 2.6 / 2.5 GHz S band

Tab. 1.2: Frequency allocations [MARAL]

DVB-S is intended to provide Direct-To-Home (DTH) services for residential consumer IRD’s (Integrated Receiver Decoder), as well as collective antenna systems and cable television head-end stations. DVB-S is suitable for use on different satellite transponder bandwidths and is compatible with MPEG-2 coded TV services. Flexibility defined within the specification enables the transmission capacity to be used for a variety of TV service configurations, including sound and data services. These DTH services via satellite are particularly affected by power limitations, therefore, ruggedness against noise and interference, is the main design objective, rather than spectrum efficiency. To achieve very high power efficiency without excessively penalizing the spectrum efficiency, DVB-S uses QPSK modulation and the concatenation of convolutional and block (Reed-Solomon) codes. The convolutional code rate is able to be configured flexibly, allowing the optimization of the system performance for a given satellite transponder bandwidth at setup.

1 Also referred to as Direct Broadcast Satellite (DBS) service

17

DVB-DSNG

One of the main features of the DVB-DSNG system is its flexibility. It allows, on a case-by-case basis, the selection of the modulation scheme, the symbol rate and the coding rate in order to better optimize the satellite link performance (i.e. the spectral occupancy of the satellite transponder and the power requirements). Maximum compatibility with DVB-S is maintained, such as concatenated error protection strategy based on Reed-Solomon coding, convolutional interleaving and inner convolutional coding. The baseline system compatibility includes as a subset all the transmission formats specified by DVB-S based on QPSK modulation and is suitable for DSNG services as well as for other contribution applications by satellite. Nevertheless, other optional transmission modes are added, using 8PSK and 16QAM modulation, in order to fulfil better bandwidth efficiency in certain contribution applications by satellite.

DVB-S2

The new DVB-S2 standard [EN 302 307] ratified in March 2005 represents a “giant leap” in term of bandwidth efficiency compared to the former DVB-S and DVB-DSNG standards. This extreme improvement is due not only to a new error correction code called Low-Density Parity-Check (LDPC) [GALLAGER-62, GALLAGER-63], but also to new high-order modulation schemes (16APSK and 32APSK) and new modes of operations called Variable Coding & Modulation (VCM) and Adaptive Coding & Modulation (ACM). While the conventional DVB-S Constant Coding & Modulation (CCM) forces the use of the same physical layer configuration for all ground stations receiving the same modulated carrier, VCM enables multiplexing in TDM frames with different physical layer configurations. ACM enables the configuration in a fully dynamic way of each TDM carrier physical layer frame. DVB-S2 is described in detail in [MORELLO].

In order to handle with an expanded choice of applications usual of DVB satellite channel coding & modulation, DVB-S2 is designed to be used in the following application areas:

• Broadcast Services (BS) Broadcast Services are covered today with DVB-S, but with the added flexibility of VCM enabling different levels of protection for each service (e.g. robust SDTV, with less-robust HDTV). There are also BC-BS (Backwards Compatible Broadcast Services) for added interoperability with DVB-S decoders, and a more optimised NBC-BS (Non-Backwards Compatible Broadcast Services).

• Interactive Services (IS) Interactive Services are designed to be used with existing DVB return channel standards (e.g. DVB-RCP, DVB-RCS, etc.), so DVB-S2 can operate in CCM (Constant Coding & Modulation) and ACM (Adaptive Coding & Modulation) modes. ACM enables each receiving station to control the protection around the traffic addressed to it.

• Digital TV Contribution and Satellite News Gathering (DTVC/DSNG) DTVC/DSNG builds on the DVB-DSNG standard, facilitating point-to-point, or point-to-multipoint communications of single or multiple MPEG transport streams using either CCM or ACM modes.

• Other Professional Applications (PS) These include for example data content distribution and trunking. This mode is generally reserved for professional point-to-point and point-to-multipoint applications using the CCM, VCM or ACM techniques.

18

Fig. 1.1: Block diagram of a DVB-S2 ACM link [MORELLO] Figure 1.1 shows schematically the implementation of a DVB-S2 ACM satellite link, consists of the ACM gateway, the ACM modulator, the satellite uplink station, the satellite and the satellite receiving terminal (modem) feedbacking to the ACM gateway via a return channel. E.g. the ACM modulator operates at constant symbol rate, since the available transponder bandwidth is assumed to be constant. ACM is implemented by the DVB-S2 modulator by transmitting, in time-division multiplex (TDM), a sequence of frames, where the coding and modulation format may change frame-by-frame. Therefore, service quality is achieved during rain fades by reducing user bits while increasing, at the same time, the Forward Error Correction (FEC) code redundancy and/or the modulation ruggedness. There the physical layer adaptation is achieved as follows: • Each satellite modem measures the channel status (available Signal-to-Noise Ratio) and

reports it via a return channel1 to the gateway • These reports are taken into account by the ACM gateway while selecting the assigned

protection level for data packets addressed to the satellite modem over this transmission channel

• In order to avoid information overflow during fades, a user bit rate control mechanism could be implemented optionally, adapting the offered traffic to the available channel capacity. E.g. a Backward Congestion Notification as source quenching could be performed.

1 Type of the return channel or modality of this feedback communication is not defined in DVB-S2 protocol

19

2. Satellite Communication In this chapter a short introduction to some aspects of satellite communication is given. The first subchapter (2.1.) gives an overview on digital communications where the second one (2.2.) deals with the subject of satellite communications link budget. These will summaries some basic understandings and formulas, as needed in following chapters.

2.1. Digital Communications Overview In general, when dealing in digital communications with a data rate R that means transmission of units (of bits) per second (bit transmission rate Rb):

]/[ sbitsRR b= (1.1) where every single bit lasts a finite time Tb = 1 / Rb. Starting from the well-known Signal-to-Noise Ratio (SNR – average signal carrier power C to average noise power N ratio = C/N) in analog communications, a normalized version of SNR is used in digital communications as figure of merit to standard quality measure of system performance. Eb is bit energy (in Watt-seconds) and can be described as signal power C times the above mentioned bit time Tb:

][WsTCE bb = (1.2) N0 is noise power spectral density and can be described as noise power N normalized by bandwidth W:

]/[0 HzWW

NN = (1.3)

The transformation formula is finally:

b

b

R

W

N

C

N

E=

0

(1.4)

That means the dimensionless ratio Eb/N0 is just a version of C/N, normalized by bandwidth W and bite rate Rb. The required Eb/N0 can be considered as a metric that characterizes the (error) performance of a digital communications system – the smaller the required Eb/N0 the more efficient is generally the detection process on receiver site for a given probability of error. As an example a plot of this bit error probability, respectively Bit Error Rate (BER) versus Eb/N0 of a satellite modem can be seen amongst others in Appendix B.1.

20

Modulation However, in a digital communications system transmitting and receiving digital messages (symbols) are done by using a transmission waveform within a window of time, the symbol time Ts, whereas one digital message can contain one or more bits, depending on utilized modulation schemes. One task of a modulation schema like M-ary Phase-shift Keying (PSK) is to group (map) bits together to one symbol, e.g. in QPSK modulations there are 2 bits (gives four-level or quaternary states)1 mapped together to one symbol, in 8PSK 3 bits (gives a symbol set of 8)2 to one symbol, etc. That means generally, the transmitter collects m bits at a time and for each symbol interval Ts = 1 / Rs the m sequential digits instruct the modulator as to which of the M = 2m waveforms to produce. As an example, in Figure 4.11 there can be seen the different constellations applied for DVB-S2. Then the transmitted signal Si(t) over a symbol interval (0, Ts) is represented by [SKLAR]:

Mi

TtM

it

T

EtS S

S

Si

,,1

0)2

cos(2

)( 0

K=

≤≤+= πϖ (1.5)

and the Power Spectral Density function3 G(f) by:

2sin

)(

=

S

SS Tf

TfTfG

ππ

(1.6)

Now the achieved symbol transmission rate Rs (in symbols-per-second) can be calculated in dependence of the utilized modulation complexity (efficiency) to:

M

RR b

s2log

= (1.7)

For different modulation schemes (as B/QPSK, 8PSK, 16QAM for DVB-S) there can be given closed solutions for bit error probability Pb as function of Eb/N0.

• For B/QPSK (M ≤ 4) [SKLAR]:

=

0

2

N

EerfcP b

b (1.8)

with Complementary Error Function given as:

1 QPSK: m=2, M=4 2 8PSK: m=3, M=8 3 It’s a real, even, nonnegative function of frequency that gives the distribution of the power of a periodic signal in the frequency domain

21

( ) dtexerfcx

t

∫∞

−=22

π (1.9)

• For 8PSK (M = 8) [PEREZ]: With the substitution:

MN

E

N

C b2

0

log≈=γ (1.10)

follows:

= )sin(log

1

2 Merfc

MPb

πγ (1.11)

• For 16QAM [PEREZ]:

−

−=)1(

log311

log

2 2

2M

Merfc

MMPb γ (1.12)

In Figure 5.8 (Raw BER vs. estimated Eb/N0 for DVB-DSNG) these curves are plotted, as pure uncoded characteristics. Coding In the next step to improve these transmission characteristics Forward Error Correction (FEC) can be used by adopting a channel coding strategy [KOUDELKA-a], either block codes (e.g. Reed-Solomon, BCH, LDPC) or convolutional codes (e.g. Viterbi, Trellis). Generally, there is some redundant information (that means k additional bits) added to each data word of n bits by the encoder to enlarge the data word to n + k bits. On the receiver site the decoder is then able to correct up to t appearing bit errors by mean of these k redundant bits and the applied coding procedure. As an example for (outer) block coding in DVB-S the padding of a redundancy block can be seen in Figure 4.3 (for Reed-Solomon). There n = 188 bits and k = 16 bits yield a t-error correction value of 8. As an another example (DVB-S2) the padding of two redundancy blocks after one data block when using two codes concatenated can be seen in Figure 4.10. There for the first (outer) BCH block code, n = 32208 bits and k = 192 bits yield a t-error correction value of 12 (see Table 4.1, FEC coding parameters for normal FECFRAME).

22

The code rate CR is defined by:

kn

nCR +

= (1.13)

The disadvantage is now that the information rate (i.e. net data rate) decreases in dependence of the code rate CR by the redundancy information, but on the other side the overall performance of the digital communications system is improved. In Figure 5.5, BER vs. estimated Eb/N0 characteristics for B/QPSK (DVB framing), right image, one can see measurement of error performances, where five different performance curves where plotted, related to code rate 1/2, 2/3, 3/4, 5/6, 7/8 and B/QPSK modulation and also the uncoded curve (with CR = 1). Now the information rate Ri (in bits/s) can be calculated in dependence of the obtained code rate CR and the modulation efficiency M to:

MCRR Rsi 2log= (1.14) The relationship between the required double-sideband signal1 bandwidth W (in Hz) to symbol transmission rate Rs is given by the square-root raised-cosine filter roll-off factor α [SKLAR]:

)1( α+= sRW (1.15)

Finally, the Eb/N0 to C/N conversion formula can be written as:

MCN

C

N

E

R

b

20 log

1 α+= (1.16)

In the test setting applied for this master thesis the information rate Ri was forced (i.e. fixed to a constant bit rate). Under this circumstance the utilized bandwidth W is varied eventually by the used modulation efficiency M and the code rate CR.

][log

1

2

HzMC

RWR

α+= (1.17)

It’s obvious that there is more bandwidth necessary when a transmission channel becomes worse to sustain a constant end-to-end stream of bits per seconds, at the expense of modulation efficiency and/or code rate. 1 Bandpass-modulated signals like PSK require twice the transmission bandwidth of the equivalent baseband signals

23

2.2. Satellite Link Budget Calculations Starting with the Inverse Square Law of antenna theory, the carrier power C on the receiver site is, in dependence of the distance l from the transmitter [KOUDELKA-b]:

24 l

AGPC effTT

π= (2.1)

with PT as the power of the transmitter, GT as antenna gain of the transmitter and Aeff the effective antenna aperture1. The product PT .GT can be seen as Equivalent Isotropic Radiated Power (EIRP) by an omnidirectional isotropic radiator. This effective antenna aperture can be quantified by help of a factor, called receiver antenna gain GR, in dependence of the used wavelength λ [RIEDLER]:

πλ

4

2R

eff

GA = (2.2)

This yields for the received carrier power:

S

RTTRTT

L

GGP

l

GGPC ==

2

2

)4( πλ

(2.3)

with the substitution:

24

=λπ l

LS (2.4)

LS represents now the factor of Free-Space Loss over the satellite link distance l. A characteristic value for this loss in Ku-band is of about 200 dB for a communication link between earth station and GEO satellite2 (see Figure 2.1).

Fig. 2.1: Free-Space Loss [GEO]

1 Respectively the effective capture area – the product of the physical aperture area and an aperture efficiency 2 Satellites in geostationary orbit are ca. 35,800 km above the earth surface

24

Additionally to this deterministic free-space loss in practice on a satellite link there appear some other degradation [KOUDELKA-b, SKLAR], such as:

• Losses due to the electrical implementation o Output loss, bandlimiting loss, modulation loss, multiple-carrier

intermodulation, adjacent channel interference, etc. • Losses due to geometric factors

o Pointing Loss - because antennas are not totally aligned o Contour Loss - because satellite antenna gain reduces at outer zones with

respect to beam center • Losses due to propagation effects influenced by ionosphere (80 km – 1000 km)

o Attenuation, Reflection and Polarization Loss (Faraday effect) • Losses due to propagation effects influenced by troposphere (up to 11 km)

o Attenuation due to atmospheric effects � Clear-Sky Attenuation � Precipitation/ Rain Fade

Subsequently these whole loss factors are to multiply additionally to LS in (2.4) to reach a total loss coefficient L = Π Li , respectively to subtract from the term (2.3) when calculation is done in dB-notation, to determine the effective signal power on receiver site. Because a satellite link path passes troposphere and ionosphere there appear some signal attenuations by atmospheric effects. Figure 2.2 shows from C-band on the occurring of additional attenuation by water vapor1 � 1st peak at about 23 GHz, and an oxygen (O2) resonance effect � 2nd peak at 60 GHz2. This occurring loss is called Clear-Weather (or Clear-Sky) Loss.

Fig. 2.2: Signal attenuation in troposphere and ionosphere [GEO]

Fig. 2.3: Rain attenuation per look angle and rain rate [GEO]

1 Usually humidity as function of pressure and temperature 2 In the troposphere there appear these attenuations by absorptions due to molecular resonance effects: for H20 peaks at 22.6 GHz and 183.3 GHz, and for O2 peaks at 60.6 GHz and 118.7 GHz [RIEDLER]

25

Cumulative to this loss there arises attenuation when precipitation happens - Rain Fade. The occurrence of precipitation is defined by percentage of time during which a given intensity is exceeded. It’s a function of the rain rate (in mm/h) and different climatic zones and presented in available zone maps for Europe, North America, etc. Rain fade is all about signal absorption, scattering and depolarization. Rain fade values (in dB/km) can be calculated based on available Nomograms (in relation to used frequency, polarization and intermittent rain rate). But rain only forms in the troposphere, which extends to 11 kilometers above the earth, a signal traveling through a rain cell will experience attenuation during only a small portion of its transmission path. In regards to diameter of the raindrop, signal attenuation is proportional to the wavelength of signal frequency and the size of the raindrop through which the signal has to pass. For example, a C-band frequency has a wavelength of approximately 7 cm, and a Ku-band frequency has a wavelength of approximately 2 cm. Any raindrop in the path of any signal which approached half the wavelength in diameter will cause attenuation. It is to be noted, Ku-band attenuation in rain is approximately nine times that of C-band or 9:1 dB [GEO]. Furthermore Figure 2.3 shows rain attenuation effects per rain rate (in mm/h) with different elevation angles - there is less loss at greater elevation angles. This look angle is dependent on the latitude and longitude of the earth station (elevation and azimuth angle). The lower the latitude of the earth stations the higher the elevation angle to the GEO satellite, and the less atmosphere through which signals travel. The higher the latitude, the lower the angle, and, therefore, there is more atmosphere through which a signal must pass and the greater the probability of it having to go through rain. To overcome varying weather conditions a usual Probability Rain Margin is to implement in link budget calculations as safety margin. E.g. when a minimal SNR value is calculated for Clear-Sky condition (with typical 95% availability) then there is to consider a rain margin of e.g. 3.5 dB to reach 99.85% availability tentatively [BREYNAERT]. [ALBERTY] specifies that in Ka-band over Europe, for a target availability of 99.7%, the range of the required margin over the coverage is nearly equal to 5 dB. However, this value does not represent heavy rain areas, where the rain margin can go up to 15 dB [BREYNAERT]. As example, considering a data distribution satellite network consist of one hub and a lot of remotes sites, which are geographically distributed over the satellite downlink beam. It is assumed that the Clear-Sky SNR is varying a bit from site to site. The 99.85% probability rain margin is varying from site to site too1. To decide which modulation and coding to use in DVB-S transmission, the minimum SNR at the worst site is to calculate. The resulting code and modulation is then fixed for all distributed downstream links. This gives as outcome poor total throughput efficiency. In this case a customizable adaptation of code and modulation can be favorable by the help of a feedback channel. It has been shown that next-generation DBV-S2 ACM implementation can increase the available total throughput of a given satellite channel up to 130% because of its flexibility and adaptiveness. A calculated working sample refers to [BREYNAERT]. [ALBERTY] describes a computer-based semi-analytic capacity analysis approach for the forward link of a multi-beam satellite broadband access network exploiting the ACM profile.

1 According to [BREYNAERT] for Ku-band the value is between 2.5 and 5.5 dB.

26

3. Simple Network Management Protocol (SNMP) In this chapter a short introduction into the topic of remote managing of IP devices by help of the Simple Network Management Protocol (SNMP) is given.

3.1. SNMP Introduction The Simple Network Management Protocol (SNMP) is a protocol on the application layer (OSI layer 7) that facilitates the exchange of management information between active network devices. It consists basically of the communication protocol part (SNMP, using UDP on ports 161 and 162) and a generic database schema, which was specified first in 1988 through two RFC groups: Structure of Management Information (SMI)1 and Management Information Base (MIB)2. SNMP presents management data in a structure of variables on the managed systems, which describe the system configuration, respectively the current status. These variables can be queried using a polling mechanism, or set if applicable by managing applications. An SNMP-managed network consists of three key components: managed devices (i.e. hosts), agents (i.e. software), and network-management systems (i.e. managing applications).

• Managed Device It is an active network node that contains an SNMP agent and that resides on a managed network. Managed devices collect and store management information and make this information available to network management systems (NMS) using SNMP. Managed devices, sometimes called network elements, can be routers and access servers, switches and bridges, hubs, or even modems.

• Agent It is a network-management software module that resides in a managed device. An agent has local knowledge of management information and translates that information into a form compatible with SNMP.

• Network Management System It executes applications that monitor and control managed devices and provides the bulk of the processing and memory resources required for network management.

Furthermore, a Management Information Base (MIB) is a collection of information that is organized hierarchically. They consist of managed objects and are identified by so called Object Identifiers (OID). Structure of Management Information (SMI) is used to define sets of related managed objects in a MIB.

1 RFC1065: “Structure and Identification of Management Information for TCP/IP-based internets”, obsolated by RFC1155 2 RFC1066: “Management Information Base for Network Management of TCP/IP-based internets”, obsolated by RCF1156

27

A Managed Object (sometimes called a MIB object, an object, or a MIB) packages one of many detailed characteristics of a managed device. Managed objects consist of one or more object instances, which are essentially variables. Two types of managed objects exist: scalar and tabular. Scalar objects define a single object instance. Tabular objects define multiple related object instances that are grouped in MIB tables. An example of a managed object is radDmd20TxModulationType, which is a scalar object that contains a single object instance, the integer value that indicates the modulation type of the transmitter (with the enumeration 1, 2, 3, 4 representing the modulation types QPSK, BPSK, 8PSK, 16QAM). An Object Identifier (OID) uniquely identifies a managed object in the MIB hierarchy. The MIB hierarchy can be drawn as a tree with a nameless root, the levels of which are assigned by diverse organizations. Figure 3.1 illustrates the MIB tree. The top-level MIB OIDs belong to different standard organizations, while lower-level OIDs are allocated by linked organizations. Vendors can define private branches that include managed objects for their own hardware (see as example the enterprise subtree radyne, highlighted in red in Figure 3.1).

Fig. 3.1: MIB tree hierarchy (including radyne subtree)

28

In this master thesis a vendor-specific private MIB definition was used (DMD20-MIB, for the listing see Appendix A.1), with predefined enterprise number 2591 for the RADYNE Corporation. In the next lower hierarchy the predefined subtree number of this particular hardware used (DMD20 Universal Satellite Modem) is 15. Furthermore, for example the managed object radDmd20TxModulationType and the belonging type enumeration are defined in this MIB file. The MIB variable names are represented in the format of ASN.1 1. There are several methods of representation. Each OID is given in the format of A.B.C.D..., where A, B, C, and D are sub identifiers in one of two forms of notation. Each sub identifier may be encoded as decimal integer, or as symbol as found in various available MIBs – or default in RFC1066 MIB2. If there is no leading ". " in the variable name, the name will be formed as if having been preceded with "iso.identified-organization.dod.internet.mgmt.mib.". One can see that the managed object radDmd20TxModulationType can be uniquely identified either by the object name

.iso.identified-organization.dod.internet.private.enterprise.radyne.dmd20.radDmd20ModNVStatus.radDmd20TxModulationType

or by the equivalent object descriptor .1.3.6.1.4.1.2591.15.1.1.8 (as defined in DMD20-MIB). At that time three different versions of SNMP exist: SNMP version 1 (SNMPv1), SNMP version 2 (SNMPv2) and SNMP version 3 (SNMPv3). Now SNMP is basically described by RFC1155 (Structure and Identification of Management Information for TCP/IP-based Internets), RFC1157 (Simple Network Management Protocol) and RFC1213 (Management Information Base for Network Management of TCP/IP-based internets: MIB-II). A simple community-based SNMP Version 2 (SNMPv2c, defined in RFC1901–RFC1908) includes SNMPv2 without the extended SNMPv2 security model, using as an alternative the straightforward clear text community-based security scheme of SNMPv1. While officially only a "Draft Standard", this is nowadays considered generally as the de facto SNMPv2 standard.

3.2. SNMP Applications

Three different frequently used standard SNMP applications from the Net-SNMP project3 are described below. These open-source WIN32 executables4 were used in this master thesis.

SNMPGET

The snmpget command is an SNMP application that uses SNMP GET requests to retrieve data from a managed device given its IP address, authentication information and an OID.

1 Abstract Syntax Notation One, ISO IS 8824 2 RFC1066: “Management Information Base for Network Management of TCP/IP-based internets”, updated to version 2 by RCF1213: “Management Information Base for Network Management of TCP/IP-based internets: MIB-II“ 3 http://www.net-snmp.org/ 4 Downloaded from http://www.elifulkerson.com/articles/net-snmp-windows-binary-unofficial.php

29

As an example:

%snmpget -c public -v 2c –M mibs 192.168.0.2 sysDescr.0

SNMPv2-MIB::sysDescr.0 = STRING: DMD20 Universal Sa tellite Modem

In the above example, 192.168.0.2 is the managed device IP address, using the SNMP version 2c and community string public for authentication, the string value of the OID sysDescr.0 was requested. The specific MIB files are located in the directory: “./mibs” (defines the relative path).

Or:

%snmpget -c public -v 2c –M mibs 192.168.0.2 DMD20-MIB::radDmd20TxModulationType.0

DMD20-MIB::radDmd20TxModulationType.0 = INTEGER: q psk(1)

In the above example the vendor-specific OIDs are defined in file DMD20-MIB.txt in directory “./mibs” . SNMPWALK The snmpwalk command is an SNMP application that uses SNMP GETNEXT requests to query the managed device for a tree (a hierarchy) of information. It’s very useful when browsing through a (unknown) MIB tree. An object identifier (OID) may be given on the command line. This OID specifies which part of the object identifier space will be searched using GETNEXT requests. All variables in the subtree below the given OID are queried and their values presented to the user. If no OID argument is present, snmpwalk will explore the subtree rooted at SNMPv2-SMI::mib-2 (this includes System, Interfaces, Address Translation, IP, ICMP, TCP, UDP, EGP, Transmission, and SNMP). Fetching the RFC MIBs (for the whole output list see Appendix A.2): %snmpwalk -c public -v 2c –M mibs 192.168.0.2 Browsing through the vendor-specific DMD20-MIB, the entry point of the tree is the enterprise number 2591 (for the whole output list see Appendix A.3): %snmpwalk -c public -v 2c –M mibs –m DMD20-MIB 192.168.0.2 1.3.6.1.4.1.2591 SNMPSET The snmpset command is an SNMP application that uses the SNMP SET request to set information on a managed device. One OID must be given as arguments on the command line, a type (for integer: ‘i’, for string: ‘s’, etc.) and a value to be set must come with each OID.

%snmpset -c public123 -v 2c –M mibs 192.168.0.2 DMD20-MIB::radDmd20TxModulationType.0 i 3

30

In the above example the modulation type of the transmitter is set to 8PSK (whereas the number 3 represents the modulation type 8PSK – for the enumeration of different modulation types sees Table 3.2). SNMP version 2c and read-write community string public123 was used.

3.3. Used MIB Object Identifications (OIDs) Exclusively OIDs from the vendor-specific MIB definition (RADYNE’s DMD20-MIB) [RAD-a] were applied in this master thesis. Three subtrees in the branch dmd20MibObjects where used (see Figure 3.1), namely radDmd20ModNVStatus ,

radDmd20DemodNVStatus and radDmd20DemodStatus . All used OID names are listed in Table 3.1, plus the related variable representation, respectively the enumerations (Table 3.2 and 3.3), to the diverse OIDs (marked in Table 3.1 by type enumeration or bit field). For variables of type float the applied number precision (Prec) is also listed.

Subtree No OID Type Prec Unit 3 radDmd20TxCarrierLeveldBmX100 float 1 dBm

7 radDmd20TxInnerFecRate enumeration radDmd20ModNVStatus(1)

8 radDmd20TxModulationType enumeration

5 radDmd20RxInnerFecRate enumeration radDmd20DemodNVStatus(3)

6 radDmd20RxModulationType enumeration

13 radDmd20RxBerEbnoStatus bit field

14 radDmd20RxEbno float 2 dB

16 radDmd20RxCarrierLeveldBmX100 float 0 dBm

17 radDmd20RxBitErrorCount integer

20 radDmd20RxSymbolRateHz integer sbs

30 radDmd20RxRawBerStatus float 2

radDmd20DemodStatus(4)

31 radDmd20RxCorrectedBerStatus float 2

Tab. 3.1: MIB definitions used (DMD20-MIB), writeable OIDs are highlighted

Modulation Enumeration BPSK 2 QPSK 1 8PSK 3

16QAM 4

Coding CR Enumeration 1/2 2 2/3 3 3/4 4

5/6 5

Viterbi

7/8 6 2/3 15 3/4 16 5/6 17 7/8 18

Trellis

8/9 19 Tab. 3.2: Enumerations of different modulation and coding types, plus code rates (CR) used

31

bin

3 2 1 0 dec Status

0 0 1 0 2 Invalid 0 0 1 1 3 Invalid 0 1 1 1 7 Valid 1 0 1 1 11 Underflow 1 1 1 1 15 Overflow

Tab. 3.3: Bit field (bin) and enumeration (dec) of different Eb/N0 states (DMD20-MIB)

3.3.1. WRITEable Values

Different parameters to configure the satellite modem can be set either on front panel manually by hand or can be put over the SNMP interface (authenticated by the SNMP read-write community). These writeable values are described below (in parenthesis the related OID):

• TX power level (radDmd20TxCarrierLeveldBmX100 ) Allows entering the transmit power level in the range 0 to -25 dBm

In SNMP/MIB data representation there is an implied decimal point (for example, a value of -123 represents a transmit power level of -12.3 dBm) • TX Modulation Type (radDmd20TxModulationType )

Allows selecting the modulation type1 • TX Inner FEC Coding Type (radDmd20TxInnerFecRate )

Allows selecting the TX type and rate of the (inner) FEC convolution encoding1

• RX Modulation Type (radDmd20RxModulationType ) Allows selecting the demodulation type1

• RX Inner FEC Coding Type (radDmd20RxInnerFecRate )

Allows selecting the RX type and rate of the (inner) FEC convolution decoding1 It’s obvious that both the TX and RX modulation type and the TX and RX coding type must be the same. However, not all possible modulation / coding combinations are feasible by the satellite modem. For the actual listing see Table 5.7 (Available coding & modulation (CM) pairs in DVB and IBS framing mode (DMD20)). 1 For data representation see Table 3.2

32

3.3.2. READable Values

The modem displays different state as well as performance parameters. These values can be seen interactively on the front panel (except “Eb/N0 Status”) and can also be retrieved by SNMP. These accessible values are described below (in parenthesis the related OID), whereas the hints on the data representation refer to [RAD-a]:

• Eb/N0 (radDmd20RxEbno ) Displays the estimated Eb/N0 value as seen by the demodulator (in dBm)

• Eb/N0 Status (radDmd20RxBerEbnoStatus ) Displays the status of the modem estimator, the value is stored as a bit field. On startup, the agent initializes this to the value bx00000000. If the status is not equal to digit “7” 1 then the estimated respectively displayed Eb/N0 value is not valid. Internal binary data representation: Bit 0 = Raw BER and corrected BER status. 1 = Val id Bit 1 = Test BER status. 1 = Valid Bit 2, 3 = Eb/No status 0 = Eb/No invalid 1 = Eb/No valid 2 = Eb/No is smaller than indicated value 3 = Eb/No is greater than indicated value Bit 4…7 = Reserved

• Input Level (radDmd20RxCarrierLeveldBmX100 )

Displays the estimated receive signal level as seen by the demodulator (in dBm)

• Symbol Rate (radDmd20RxSymbolRateHz ) Displays the effective symbol rate (in sps)

• Bit Errors (radDmd20RxBitErrorCount ) Displays the current error count from the Viterbi decoder (in counts)

• Raw BER (radDmd20RxRawBerStatus ) Displays the estimated channel error rate (before decoding) measured by the modem

• Corrected BER (radDmd20RxCorrectedBerStatus ) The Corrected BER display shows an estimated corrected bit error rate of the modem. Depending on the symbol rate the modem is running, the high-end performance scale of this display will vary (E-09, E-10 or E-11). At some symbol rates, a better than scale reading will appear as 0.00E-00. At other symbol rates, it will appear as E** . In either case, they both mean performance is better than the scale upper limit.

1 See Table 3.3

4. DVB-S The following subchapters deal with the different functional designs of DVB-S and the diverse enhanced DVB-S flavours. In the first one there are the functional blocks of DVB-S described basically, whereas a generic structure can be seen: as pre-process the multiplexing part and as core system the satellite channel adapter part. Again, this satellite channel adapter part consists typically of elements for concatenate coding (inner & outer coding) and modulation (constellation). Furthermore differences and developments referring to DVB-DSNG and DVB-S2 functional block designs are described in the next subchapters.

4.1. DVB-S System Architecture

Fig. 4.1: DVB-S functional block diagram Referring to EN 300 421 the DVB-S system is there defined as the functional block of elements performing the adaptation of the baseband signals - from the output of the MPEG-2 transport multiplexer to the satellite channel characteristics. The following elements of the satellite channel adapter are applied to the multiplexed data stream (see Figure 4.1):

o Scrambler o Outer Coder o Interleaver o Inner Coder o Bit Mapping / Constellation o Baseband Shaping o Modulator

This data stream, following the MPEG-2 transport multiplexer, is organized in fixed length packets, where the total packet length of the MPEG-2 transport multiplex packet is 188 bytes - this includes 1 sync-word byte (47HEX) used for synchronization.

34

Fig. 4.2: MPEG-2 transport MUX packet Scrambler As first step, in order to do a randomization for energy dispersal and to ensure adequate binary transitions, the 187 bytes of data of the input MPEG-2 multiplex packet are randomized by a Pseudo Random Binary Sequence generator with polynomial 1+ X14+ X15 . Outer Coder In the next step a Reed-Solomon RS(204,188, T=8) shortened block code1 is applied to each randomized 188 byte transport packet (more precisely, this packet consists of 1 sync byte plus 187 randomized data bytes) to generate an error protected packet (see Figure 4.3). This RS block coding mechanism expands the packet length to 204 bytes per pending a 16 byte (=204-188) check sequence, but this additional check sequence enables the decoder to correct up to 8 bit errors in this 188 byte payload.

Fig. 4.3: RS(204,188, T=8) error protected packet In Figure 4.3 one can see the packet structure after the outer coder process: 1 byte sync-word, randomized 187 byte data and the check sequence (parity check bits) trailer of 16 bits generated by the RS coder. Interleaver Generally, interleaving is used to protect the transmission against cumulatively appearing burst errors. These burst errors can overwrite a lot of bits in a row, so a typical error correction mechanism that expects errors to be more uniformly distributed can be overwhelmed. Therefore, to reduce this negative effect interleaving is used to spread error bursts. Referring to EN 300 421 convolutional interleaving with a depth of 12 is applied to the error protected packets - this finally results in an interleaved framing structure. Inner Coder Then these frames are directed to a convolutional coding mechanism for a second coding step (i.e. inner coding). Referring to EN 300 421 the DVB-S system defines an implementation set for the reason of flexibility of convolutional coding2 with code rates of 1/2, 2/3, 3/4, 5/6 and 7/8, and with constraint length3 K=7. Bit Mapping / Constellation Referring to EN 300 421 the DVB-S system employs conventional Gray-coded QPSK modulation (m = 2 bit), with absolute mapping (that means no differential coding is used).

1 Derived from the original RS(255,239, T=8) code 2 Based on a rate 1/2 convolutional code with constraint length K=7 3 Constraint length represents the number of K-tuple stages in a convolutional encoder shift register

35

The utilized bit mapping in the signal space can be seen in Figure 4.4, whereas the I and Q signals are mathematically represented by a succession of Dirac delta functions spaced by the symbol duration Ts = 1 / Rs , with correct sign.

Fig. 4.4: Bit mapping into QPSK constellation [EN 300 421] Baseband Shaping In the next step and prior to modulation, for shaping the resulting baseband signal, the I and Q signals are square-root raised-cosine filtered. This in EN 300 421 defined roll-off factor α is 0.35. Modulation As final step quadrature modulation is performed by multiplying the in-phase (I) and quadrature (Q) components (after baseband filtering) by sin(2πf0t) and cos(2πf0t), respectively (where f0 is the carrier frequency). The two resulting signals are added to get the modulated RF output signal.

4.2. DVB-DSNG System Architecture The baseline DVB-S includes compatibly as a subset all the format definitions specified by EN 300 421, based on QPSK modulation and is suitable for DSNG services as well as for other contribution applications by satellite. Nevertheless, other optional transmission modes are added [EN 301 210] in order to perform to specific requirements. These optional modes can be very efficient in certain contribution applications by satellite. With these increased flexibility requirements DVB-DSNG has now the following enhanced characteristics to DVB-S (whereas the functional block design remains the same): Bit Mapping / Constellation / Modulation Optional to QPSK now 8PSK (m = 3 bit) and 16QAM (m = 4 bit) modulation are defined and bit mapping into constellations is carried out by associating these m input bits (as an example for 8PSK - see Figure 4.5, and for 16QAM – see Figure 4.6). But as a disadvantage in practice, these optional modulation types are more sensitive to linear and non-linear distortions; in particular 16QAM cannot be used on transponders driven near saturation [TR 101 221].

36

Fig. 4.5: Bit mapping into 8PSK constellation (for rate 2/3) [EN 301 210]

Fig. 4.6: Bit mapping into 16QAM constellation [EN 301 210] Inner Coder Referring to EN 301 210, when using the optional 8PSK and 16QAM modulation types, "pragmatic" trellis coding is applied, optimizing the error protection of the convolutional code defined in EN 300 421. Following optional code rates are defined in EN 301 210, for:

o 8PSK: 2/3, 5/6, 8/9 o 16QAM: 3/4, 7/8

Baseband Shaping For tighter bandwidth shaping, DVB-DSNG adds roll-off factor of α = 0.25 to the DVB-S conventional roll-off factor of α = 0.35.

4.3. DVB-S2 System Architecture As mentioned earlier, with increased flexibility requirements, and the objective to design a system which would yield improved performance gains over DVB-S, the next-generation DVB-S2 standard was defined in EN 302 307, titled “Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications”. This far-reaching improvement was achieved by a new error correction code called Low-Density Parity-Check (LDPC) [GALLAGER-62, GALLAGER-63], new high-order modulation schemes (16APSK,

37

32APSK) and new modes of operations called Variable Coding & Modulation (VCM) and Adaptive Coding & Modulation (ACM), at which the code rates can be changed dynamically, even on a frame-by-frame basis. To take full advantage of the adaptive VCM and ACM methods requires using new methods for network-layer interfaces based on the Continuous Generic Stream. This Generic Stream Encapsulation allows a transmitter to directly transport network (IP) packets without to encapsulate MPEG-2 transport packets. The most significant benefit of this method is the flexibility that it will allow for operators to vary on a frame-by-frame basis too [FAIRHURST]. A comparison about different IP encapsulation efficiency (for Generic Stream, Multi Protocol, and Unidirectional Lightweight) can be found in [MAYER].

Fig. 4.7: DVB-S2 functional block diagram

Referring to EN 302 307 there the DVB-S2 system is defined as the functional block of elements (subsystems) performing (see Figure 4.7):

o Mode Adaption o Stream Adaption o FEC Coding o Mapping / Constellation / Modulation

Mode Adaption Subsystem Depending on the input DATA sequences (single ore multiple MPEG-2 packet transport streams, or single or multiple generic streams, which again could be either packetized or continuous) and the adopted mode adaptation format the output sub-frame sequence is a 10 byte Baseband Header (BBHEADER ) carrying this information followed by the DATA field. This BBHEADER is appended in front of the DATA field, to notify the receiver of the input stream format and mode adaptation type and built a sub-frame structure.

38

Fig. 4.8: Stream format at the output of the Mode Adapter [EN 302 307] In Figure 4.8 is shown how upper layer stream formats (either generic continuous or packetized stream) partitioned into the BBFRAME DATA field of the newly build Baseband Frame (BBFRAME), as well the different filled-in BBHEADER fields. E.g. MATYPE (2 bytes) describes the used input stream format, the type of mode adaptation (CCM / ACM) and the transmission roll-off factor. Furthermore the User Packet Length (UPL) and the Data Field Length (DFL) is stored. Stream Adaption Subsystem As next step stream adaptation provides padding to complete a constant length BBFRAME. Kbch - DFL - 80 zero bits will be appended after the DATA field as trailer. The resulting BBFRAME has now a constant length of Kbch bits, where the value Kbch depends on the FEC coding (see Table 4.1 and 4.2 – BCH Uncoded Block Kbch). This entire BBFRAME will then be randomized (scrambled).

Fig. 4.9: BBFRAME at the output of the Stream Adapter [EN 302 307]

FEC Coding

DVB-S2 uses a very powerful FEC coding based on concatenation of BCH (Bose-Chaudhuri-Hocquenghem) outer with LDPC (Low-Density Parity-Check) inner coding. The result is a performance which is only 0.7 dB to 1.2 dB from the Shannon limit1 [MORELLO]. The FEC parameter options depend on the system requirements, rather with adaption modes VCM and ACM, the FEC code rates can be changed dynamically.

1 This Shannon Bound is given by 1 / log2 e (this limit is approximatively -1.6 dB)

39

This FEC coding subsystem performs outer coding (BCH), inner coding (LDPC) and finally bit interleaving by a block interleaver. The input stream is composed of BBFRAMEs and the output stream of FECFRAMEs. Each BBFRAME of Kbch bits is expanded by the FEC coding subsystem to a FECFRAME of nldpc bits. The parity check bits (BCHFEC) of the systematic t-error correcting outer BCH coder are appended after the BBFRAME, and the parity check bits (LDPCFEC) of the inner LDPC coder are appended after the BCHFEC field, as shown in Figure 4.10.

Fig. 4.10: FECFRAME before bit interleaving [EN 302 307]

Depending on the area of applications, the FEC coded block can have a fixed length nldpc of 64800 bits or 16200 bits. The adapted code parameters can be seen in Table 4.1 for normal FECFRAME (nldpc = 64800 bits) and in Table 4.2 for short FECFRAME (nldpc = 16200 bits).

Tab. 4.1: FEC coding parameters for normal FECFRAME [EN 302 307]

Tab. 4.2: FEC coding parameters for short FECFRAME [EN 302 307]

40

Finally, for 8PSK, 16APSK and 32APSK modulation formats the output of the LDPC encoder is bit interleaved using a block interleaver, according to Table 4.3. Data is serially written into the interleaver column-wise, and serially read out row-wise, whereas the MSB of BBHEADER is read out first.

Tab. 4.3: Bit interleaving structure [EN 302 307] Mapping / Constellation / Modulation Referring to EN 302 307 in DVB-S2 there are four modulation / constellation modes defined: QPSK, 8PSK for broadcast applications through non-linear satellite transponders driven near to saturation. 16APSK and 32APSK are more focused on professional applications requiring semi-linear transponders.

QPSK signal constellation 8PSK signal constellation

16APSK signal constellation 32APSK signal constellation Fig. 4.11: DVB-S2 signal constellations [EN 302 307]

41

In the mapping process each FECFRAME is serial-to-parallel converted, with a parallelism level m = 2 for QPSK, 3 for 8PSK, 4 for 16APSK and 5 for 32APSK. Each parallel sequence will be mapped into a constellation, generating a (I,Q) sequence of variable length depending on the selected modulation efficiency. The input sequence is a FECFRAME, the output sequence is a XFECFRAME (compleX FECFRAME), composed of 64800 / m (normal XFECFRAME) or 16200 / m (short XFECFRAME) modulation symbols. Each modulation symbol is a complex vector in the format (I,Q) (I is the in-phase component and Q is the quadrature component). These four different types of bit mapping into constellations can be seen in Figure 4.11. In the next step this XFECFRAME will be partitioned into fixed-length frames (cells or named here as slots) of 90 symbols. Now this generated Physical-Layer Frame (PLFRAME) consists of an additional Physical-Layer Header (PLHEADER) and a number of S slots (the payload) - see Figure 4.12.

Fig. 4.12: Physical-Layer Framing (PLFRAME) [EN 302 307] Now the PLHEADER itself consists of a so-called Start-of-Frame (SOF) sequence (26 symbols) and a Physical-Layer Signaling Code (PLSCODE) of 64 symbols. Amongst others the PLSCODE consists of MODCOD (5 symbols), identifying the XFECFRAME modulation type & FEC code rate pairs (assignment see Table 4.4); and TYPE (2 symbols) – the MSB identifying the FECFRAME length (0=normal or 1=short).

Tab. 4.4: PLHEADER: MODCOD definitions [EN 302 307]

42

Hence the PLHEADER is responsible for receiver synchronization and physical layer signaling, that means that after decoding the PLHEADER, the receiver knows the PLFRAME duration and structure, the modulation and coding scheme of the XFECFRAME, etc. After inserting the physical layer signaling information, inserting of pilot blocks for synchronisation and scrambling the frame is completed by the physical layer framing subsystem and passed on to baseband shaping. There the signals is square-root raised-cosine filtered, with roll-off factors α = 0.35, 0.25 or 0.20, depending on the service requirements. As final step quadrature modulation is performed by multiplying the in-phase (I) and quadrature (Q) components (after baseband filtering) by sin(2πf0t) and cos(2πf0t), respectively (where f0 is the carrier frequency). The two resulting signals are added to get the modulated RF output signal.

4.4. Performance Comparison To give a performance overview of the DVB-S suite there is in the following a comparison of DVB-S and DVB-S2 performance characteristic curves listed. Figure 4.13 [DIG] shows for DVB-S different bit error rate (BER) performances: uncoded QPSK versus QPSK plus convolutional (Viterbi) coding - with different code rates (1/2, 3/4, 7/8) and each with and without additional outer Reed-Solomon block code concatenation.

Fig. 4.13: Error rate performance (BER vs. Eb/N0) for Viterbi and Viterbi+RS codings [DIG]

43

Obviously the needed Signal-to-Noise ratio to reach a certain BER value decreases with lower code rates (7/8 � 3/4 � 1/2), i.e. more parity bits are added for information redundancy to a data word. With additional RS block coding the overall performance increases again, the slope of the BER curves will be steeper.

To compare the Bit Error Rate (BER) with the Packet Error Rate (PER) a numerical conversion1 is calculated and depicted (Figure 4.14), based on data of Figure 4.13.

Error Rate Performance

1,00E-08

1,00E-07

1,00E-06

1,00E-05

1,00E-04

1,00E-03

1,00E-02

1,00E-01

1,00E+00

0 1 2 3 4 5 6 7 8

Eb/No [dB]

Bit

Err

or

Rat

e

Error Rate Performance

1,00E-08

1,00E-07

1,00E-06

1,00E-05

1,00E-04

1,00E-03

1,00E-02

1,00E-01

1,00E+00

0 1 2 3 4 5 6 7 8

Es/No [dB]

Pac

ket

Err

or

Rat

e Viterbi 1/2

Viterbi 3/4

Viterbi 7/8

Vit+RS 1/2

Vit+RS 3/4

Vit+RS 7/8

Fig. 4.14: Error rate performance (BER and PER) for Viterbi and Viterbi+RS codings (QPSK)

To compare DVB-S with DVB-S2 Figure 4.15 [TR 102 376] shows the PER performance for different DVB-S2 code rates & modulations (coding: inner LDBC & outer BCH, modulations: QPSK, 8PSK, 16APSK, 32APSK). Here the slopes of the performance curves become almost vertical.

Fig. 4.15: Error rate performance (PER vs. Eb/N0) of LDPC&BCH Codes (DVB-S2, nldpc = 64 800 bits) [TR 102 376] 1 A standard approximation conversion formula is PER=1-(1-BER)n , where n is the packet size (=64800/2 bits)

44

Figure 4.16 [EN 302 307] shows the required C/N (Carrier-to-Noise power ratio measured in a bandwidth equal to the symbol rate RS) versus the spectrum efficiency (useful bit rate R per unit symbol rate RS) of the different DVB-S flavours:

• DVB-S

o QPSK / code rates: 1/2, 2/3, 3/4, 5/6, 7/8

• DVB-DSNG

o QPSK: same curve as DVB-S

o 8PSK / code rates: 2/3, 5/6, 8/9

o 16QAM / code rates: 3/4, 7/8

• DVB-S2

o QPSK / code rates: 1/4, 1/3, 2/5, 1/2, 3/5, 2/3, 3/4, 4/5, 5/6, 8/9, 9/10

o 8PSK / code rates: 3/5, 2/3, 3/4, 5/6, 8/9, 9/10

o 16APSK / code rates: 2/3, 3/4, 4/5, 5/6, 8/9, 9/10

o 32APSK / code rates: 3/4, 4/5, 5/6, 8/9, 9/10

in contrast to the modulation-constrained, but just theoretically reachable, Shannon limits.

Fig. 4.16: DVB, spectrum efficiency versus required C/N on AWGN channel [EN 302 307]

These idealised reference curves were obtained by computer simulations on AWGN channel (ideal demodulator, no phase noise). The performance refers to the quality target PER = 10-7, C/N refers to average power [EN 302 307].

45

5. Managing the Satellite Modem Figure 5.1 depicts the measurement setup used for the collection of modem characteristics (BER vs. Eb/N0) and the subsequent realisation of the adaptive coding & modulation (ACM) closed-loop controller implementation. As satellite modem a RADYNE DMD20 with firmware version F05058-AN 5.0 was used. A BER tester (Wandel & Goltermann PFA-30 Digital Communications Analyser) was connected to the terrestrial interface of the modem via serial synchronous RS530/422/V.35 interface standard; a permanent transmission data rate of 2.048 Mbps was fixed. For BER testing the polynomial 215-1 was configured, a typical data collection (BER measuring) cycle lasted 60 seconds and resulted in the total bit error rate over the simulated IF (70 MHz) transmission channel. The egress IF/TX interface on 70 MHz was connected to a 2-way splitter where White Noise was added by a noise generator with variable attenuator (Micronetics Inc., Model Nod 5107). Then this spectrum was looped back to the IF/RX interface on the same modem hardware. On this channel as simple monitoring equipment a spectrum analyser (Rohde & Schwarz, FSP Spectrum Analyser) was patched in. Basic configuration of the satellite modem was done via the front panel; all ongoing changes of the configuration (e.g. modulation, coding, transmit power level) as well as reading out of parameters (e.g. BER counters, Eb/N0 values) was done via SNMP by the managing station (a Microsoft Windows laptop running Open Source MSYS1 and MinGW 2). Two managing applications (the first program was used for the collection of modem characteristics, the second program was the ACM control unit) were written in C++.

Fig. 5.1: Measurement setup

1 MSYS: A Minimal System providing a POSIX compatible Bourne shell environment, with a small collection of UNIX command line tools 2 MinGW: Minimalist GNU for WINDOWS provides a complete Open Source programming tool set for the GNU Compiler Collection (GCC)

46

5.1. Basic Configurations In Table 5.1 and 5.2 the basic configurations for the serial synchronous link between BER tester and modem are listed. For clocking the internal modem source was selected. Maximum date rate is specified to a fixed rate of 2.048 Mbps above this serial link.

Mode RX/TX Interface V.11 Framing OFF Emulation DEE Clock EXT

Tab. 5.1: Basic configuration of the serial interface (BER tester)

INTERFACE TX SETUP TERR Interface V.35 TX clk src SCT TX clk pol auto SCT clk src internal RX SETUP TERR Interface V.35 buff size 32 buff clk src SCT buff clk pol Normal TERR streaming byte output GENERAL ext clk src None ext fr 10 ref freq src Internal ref fr 10

Tab. 5.2: Basic configuration of the serial terrestrial interface (DMD20) For enabling SNMP out-of-band management facility over Ethernet on-board interface of the satellite modem a pre-configuration over the front panel of some parameters for IP and SNMP are necessary. Parameter setting is listed below [RAD-b]:

SYSTEM TCP/IP BOOT MODE NON-VOL IP ADDR MASK 255.255.255.0 Modem IP addr 192.168.0.2 SNMP Version V1&V2 RD community Public RDWR community public123

Tab. 5.3: Basic configuration of the IP/SNMP management interface (DMD20)

47

Starting from a default modem configuration there were no more basic pre-configurations over the front panel required, except for the sake of simplicity the setting of the differently used framing modes (DVB or IBS, see 5.2.2 Measuring Series) was not implemented in software but was handled over the front panel too.

MODULATOR NETWORK SPEC DVB SAT DEMODULATOR NETWORK SPEC DVB SAT

Tab. 5.4: Basic configuration of DVB framing mode (DMD20)

MODULATOR NETWORK SPEC IBS REED-SOLOMON Enabled DEMODULATOR NETWORK SPEC IBS REED-SOLOMON Enabled

Tab. 5.5: Basic configuration of IBS framing mode, plus outer RS coding (DMD20)

MODULATOR NETWORK SPEC IBS REED-SOLOMON Disabled DEMODULATOR NETWORK SPEC IBS REED-SOLOMON Disabled

Tab. 5.6: Basic configuration of IBS framing mode, without outer RS coding (DMD20) All further configurations (e.g. modulation and coding type, transmit power level) were done automated by the managing applications via SNMP.

48

5.2. Data Collection

5.2.1. Developed Managing Application <mt1.exe>

The first (mt1.exe) of two programs, all coded in C++, was written for the task to collect output data to distinguish the transmission characteristics of the used satellite modem. Mainly the well-known characteristic curve BER vs. Eb/N0 was to determine. For this reason the first program <mt1.exe > was developed to communicate with the modem via SNMP.

Fig. 5.2: Flow chart of <mt1.exe> Specific processing steps are (Figure 5.2):

• setup modem parameters (optional) o TX modulation & RX demodulation type MODnumber o TX/RX FEC code type CODnumber

• start measurement cycle o setup TX start power level POWER1

• measurement o bit error counts, bit error rates, estimated Eb/N0 ratio o write new info line to file <log1.txt>

• idle for SLEEP seconds • measurement

o bit error counts, bit error rates, estimated Eb/N0 ratio o write to file <log1.txt>

• increment TX power level until POWER2 is reached o setup new TX power level

49

In each step, one after the first and one after the second measure point, the relevant parameters were written to file <log1.txt> for logging purposes. It’s possible to configure this measuring steps in a loop, with variations of the transmit power level to reach different Eb/N0 values and bit error rates. Binary <mt1.exe> : USAGE: mt1 [OPTIONS] EXAMPLE: mt1 –m 1 –c 1 –p -9.0 -7.5 –n 4 –s 60 Setup modem parameters, wait and write again measur ed values to file <log1.txt> OPTIONS: -h displays this help message -m MODnumber set modulation and demodulation 1=QPSK | 2=BPSK | 3=8PSK | 4=16QAM -c CODnumber set FEC coding when MODnumber=1|2: 1=VITERBI1x2 | 2=VITERBI2x3 | 3=VITERBI3x4 |

4=VITERBI5x6 | 5=VITERBI7x8 when MODnumber=3: 1=TRELLIS2x3 | 2=TRELLIS5x6 | 3=TRELLIS8x9

when MODnumber=4: 1=TRELLIS3x4 | 2=TRELLIS7x8 -p POWER1 POWER2 set min and max transmit power l evel (in dB) -n STEPS set the number of steps between POWER1 and POWER2 -s SLEEP set the idle time between two steps (in seconds) -a concatenate output to existing file -d run in demo mode (in addition to –y) FILE FORMAT (per line) for <log1.txt>: indx;timestamp;MODtype;CODtype;symbolrate;TXpower;R Xpower;Eb/No_1;countBER1 ;rawBER1;corrBER1;idletime;Eb/No_status;Eb/No_2;cou ntBER2;rawBER2;corrBER2 EXAMPLE: 0;12:08:10;qpsk(1);viterbi1x2(2);2234182;-9.0;-22.0 ;3.37;8.081421E+007 ;1.66E-001;2.76E-004;61;7;3.29;4.968640E+008;1.66E- 001;2.74E-004 1;12:09:26;qpsk(1);viterbi1x2(2);2234182;-8.5;-22.0 ;3.78;5.761167E+008 ;1.36E-001;4.85E-004;62;7;3.84;9.143481E+008;1.36E- 001;4.83E-004 2;12:10:47;qpsk(1);viterbi1x2(2);2234182;-8.0;-21.0 ;4.42;8.198735E+007 ;1.10E-001;4.63E-004;61;7;4.40;3.576364E+008;1.11E- 001;4.68E-004 3;12:11:54;qpsk(1);viterbi1x2(2);2234182;-7.5;-21.0 ;5.07;3.819929E+008 ;1.02E-001;3.43E-004;62;7;5.15;5.989058E+008;8.70E- 002;1.07E-004 VALUES: indx consecutive counter timestamp timestamp at the beginning of the measu rement (hours:minutes:seconds) MODtype string value, representing current settin g (as defined in DMD20-MIB) CODtype string value, representing current settin g (as defined in DMD20-MIB) symbolrate (in symbols per seconds) TXpower transmit power level (in dB) RXpower estimated power level by the demodulator (in dB)

50

Eb/No_1 estimated Eb/No ratio countBER1 bit error counter (from convolution dec oder) rawBER1 estimated channel error rate (before deco ding) corrBER1 estimated corrected bit error rate idletime idle time between two measurements (in s econds) Eb/No_status status of the estimator (state defined in DMD20-MIB) Eb/No_2 estimated Eb/No ratio countBER2 bit error counter (from convolution dec oder) rawBER2 estimated channel error rate (before deco ding) corrBER2 estimated corrected bit error rate

5.2.2. Measuring Series

In the first measuring series modulation and coding type was each fixed, and the transmit power level on the satellite modem was varied in a specified interval (with STEPS steps between the minimum and maximum power level). This was done for all available coding & modulation (CM) pairs in DVB mode. The total set of all available CM pairs implemented is similar to the specification in DVB-DSNG 1. Furthermore to compare DVB’s standard concatenated FEC coding - outer Reed-Salomon (RS)2 block coding plus inner convolution coding - with pure FEC convolution coding a different specification was to used (namely INTELSAT’s IBS 3 / IESS-309 4 framing mode), by which it was possible to disable RS coding manually for some particular CM pairs. For the complete set of all available CM pairs used see Table 5.7 (where MODnumber and CODnumber are consecutive numbers which are used internally by the software, CODenumeration is related to the MIB representation5). Concurrently to the running software during a measurement the discrete BER tester measures the end-to-end bit errors over the simulated communication channel. The BER tester was operated manually and the results were written down manually, too. Additionally, the (C+N)/N ratio by the satellite modem were also monitored by the spectrum analyzer, respectively the Eb/N0 values. A typical measuring cycle lasts 60 seconds, in which 2047997 bits * 60 seconds were originated by the BER tester (gives totally 1.23 108 bits). The measurement was done for practical reason in an interval of BER between 10-3 and 10-6. The upper limit (10-3) is defined due to the decoder limit; the lower limit (10-6) was selected because of numerical respectively statistical reasons. Because a BER of 2.5 10-7 means just 30 uncorrectable bit errors in 1 minute, for example to compare a BER of 4.27 10-5 means 5244 bit errors in a stream of total 1.23 108 bits. And the accuracy in this values margin is acceptable, as example a subsequently second measuring over 60 seconds yields as new result 4.35 10-5 (5345 bit errors).

1 See 4.2 DVB-DSNG System Architecture 2 With a fixed code rate of 188/204 3 IBS: INTELSAT Business Service 4 IESS: INTELSAT Earth Station Standard 5 Tab 3.2: Enumerations of different modulation and coding types, plus code rates (CR) used

51

Mode Modulation Convolution Coding RS MOD number

COD number

COD enumeration

1/2 ena 2 1 2 2/3 ena 2 2 3 3/4 ena 2 3 4 5/6 ena 2 4 5

BPSK Viterbi

7/8 ena 2 5 6 1/2 ena 1 1 2 2/3 ena 1 2 3 3/4 ena 1 3 4 5/6 ena 1 4 5

QPSK Viterbi

7/8 ena 1 5 6 2/3 ena 3 1 15 5/6 ena 3 2 17 8PSK Trellis

8/9 ena 3 3 19 3/4 ena 4 1 16

DVB

16QAM Trellis 7/8 ena 4 2 18

1/2 X 2 1 2 BPSK Viterbi 3/4 X 2 3 4 1/2 X 1 1 2 QPSK Viterbi 3/4 X 1 3 4

8PSK Trellis 2/3 X 3 1 15 1/2 ena 2 1 2 BPSK Viterbi 3/4 ena 2 3 4 1/2 ena 1 1 2 QPSK Viterbi 3/4 ena 1 3 4

IBS

8PSK Trellis 2/3 ena 3 1 15

Tab. 5.7: Available coding & modulation (CM) pairs in DVB and IBS framing mode (DMD20) During the time when modulator and demodulator are unlocked - this effect occurs temporarily because of a high BER - the measuring was interrupted by the BER tester (signals “All Ones”) and this time interval was always excluded automatically from the calculation of the ratio by the BER tester. In a second measuring series the transmit power level was yet fixed, and the modulation & coding types were altered. Here one can see that there appeared different offsets in the Eb/N0 values by the demodulator / decoder of the satellite modem1. This was the pre-work for the item “Correction Factors”.

1 See 5.2.4 Correcting the Estimator of the Satellite Modem

52

BER vs. Estimated Eb/N0 Characteristics Below there are some measuring series shown graphically (Figure 5.3). The BER values were measured with the discrete BER tester, the Eb/N0 values came from the internal estimator (i.e. estimated). The curves with the values for rawBER, corrBER (from the satellite modem) and measuredBER (from the BER tester) were drawn over the Eb/N0 value (from the estimator). Additionally linear trend curves – more precisely in exponential style because the y (BER) - axis is in a logarithmic scaling - were calculated by Windows Excel. The related measured raw data can be all found in Appendix B.2 1. There one can see that not for all modulation types, respectively CM pairs, the corrBER values were available from the satellite modem.

DVB: BPSK / VITERBI_34 & RS

1,00E-07

1,00E-06

1,00E-05

1,00E-04

1,00E-03

1,00E-02

1,00E-01

1,00E+00

3 3,5 4 4,5 5

Eb/No (estimated)

BE

R

rawBER

corrBER

measuredBER

DVB: QPSK / VITERBI_34 & RS

1,00E-07

1,00E-06

1,00E-05

1,00E-04

1,00E-03

1,00E-02

1,00E-01

1,00E+00

3 3,5 4 4,5 5

Eb/No (estimated)

BE

R

rawBER

corrBER

measuredBER

Exponentiell

DVB: 8PSK / TRELLIS_89 & RS

1,00E-07

1,00E-06

1,00E-05

1,00E-04

1,00E-03

1,00E-02

1,00E-01

1,00E+00

6 6,5 7 7,5 8

Eb/No (estimated)

BE

R

rawBER

measuredBER

DVB: 16QAM / TRELLIS_78 & RS

1,00E-07

1,00E-06

1,00E-05

1,00E-04

1,00E-03

1,00E-02

1,00E-01

1,00E+009 9,5 10 10,5 11

Eb/No (estimated)

BE

R

rawBER

measuredBER

Fig. 5.3: Different BER values vs. estimated Eb/N0 for different CM pairs (DVB framing)

On the other hand there were same difficulties with two CM pairs, as one can compare with the raw data in Appendix B.2.

• For BPSK and CR 1/2 (DVB, BPSK, VITERBI_1/2) it was not possible to measure a slope in the BER curve, but the Eb/N0 status show an underflow (value “11” 2) at 3.93 dB.

1 Tab. B.1: Measured Values for BPSK (DVB framing), Tab. B.2: Measured Values for QPSK (DVB framing), Tab. B.3: Measured Values for 8PSK (DVB framing), Tab. B.4: Measured Values for 16QAM (DVB framing), Tab. B.5: Measured Values for IBS framing (pure convolution coding), Tab. B.6: Measured Values for IBS framing (concatenated coding) 2 Tab. 3.3: Bit field (bin) and enumeration (dec) of different Eb/N0 states (DMD20-MIB)

53

• For 8PSK and CR 2/3 (DVB, 8PSK, TRELLIS_2/3) there appeared a spurious hysteresic behavior. When decreasing values of Eb/N0 by lowering TXpower the break point was at 5.56 dB, and when increasing TXpower (Eb/N0) again the modem locked at 7.74 dB estimated Eb/N0 ratio.

Because of this existing problem in the firmware implementation of the satellite modem the CM pair 8PSK with CR 2/3 (DVB, 8PSK, TRELLIS_2/3) was excluded from further considerations in this master thesis! BER vs. Measured Eb/N0 Characteristics In a second step to compare estimated with measured Eb/N0, the BER values were measured with the discrete BER tester and the (C+N)/N ratios with the spectrum analyser. Then the values for (C+N)/N were converted to Eb/N0

1.However, the measuring of the difference of two signal levels with the spectrum analyzer - by setting two markers: one on C+N peek, one on N noise level - is more or less inaccurate because of heavy jitter of the lines. Therefore three (C+N)/N measurements were each sampled by hand to reach at least a tolerable average (for specific data see Appendix B.2 2).

DVB: B/QPSK & Viterbi (&RS)

1,00E-07

1,00E-06

1,00E-05

1,00E-04

1,00E-03

1,00E-02

1,00E-01

1,00E+00

3 4 5 6 7

Eb/No

BE

R

BPSK&VIT3/4(estimated)

BPSK&VIT3/4(measured)

QPSK&VIT3/4(estimated)

QPSK&VIT3/4(measured)

QPSK&VIT1/2(estimated)

QPSK&VIT1/2(measured)

DVB: 8PSK/16QAM & Trellis (&RS)

1,00E-07

1,00E-06

1,00E-05

1,00E-04

1,00E-03

1,00E-02

1,00E-01

1,00E+00

6 7 8 9 10 11

Eb/No

BE

R

8PSK&TRE8/9(estimated)

8PSK&TRE8/9(measured)

16QAM&TRE3/4(estimated)

16QAM&TRE3/4(measured)

Fig. 5.4: BER values for different CM pairs vs. estimated and measured Eb/N0 (DVB framing) In Figure 5.4 different BER curves are drawn over both estimated and measured Eb/N0, whereas the measured values fluctuate (e.g. in the QPSK measurement). There one can see that there appears a significant deviation between estimated and measured curves, but for the closed-loop controller implementation there is just the relative offset between the used CM pairs important (based on the estimated Eb/N0 value which is readable by SNMP). Nevertheless, these offsets can be balanced by using correction factors.

1 Conversion formula: C/N = 10 log [10^(C+N)/N/10 – 1) [dB] and equation (1.16) 2 Tab. B.7: Measured BER values vs. estimated and measured/calculated Eb/N0 for different CM pairs (DVB framing)

54

Characteristics Summary In Figure 5.5 the BER vs. estimated Eb/N0 characteristics for different Viterbi code rates (just for BPSK and QPSK modulation) are depicted. Also the curve of uncoded theory for B/QPSK is drawn.

DVB: B/QPSK

1,00E-07

1,00E-06

1,00E-05

1,00E-04

1,00E-03

1,00E-02

1,00E-01

1,00E+00

3 3,5 4 4,5 5 5,5 6

Eb/No (estimated)

BE

R

BPSK &VIT_2/3

BPSK &VIT_3/4

BPSK &VIT_5/6

BPSK &VIT_7/8

QPSK &VIT_1/2

QPSK &VIT_2/3

QPSK &VIT_3/4

QPSK &VIT_5/6

QPSK &VIT_7/8

UncodedTheory

DVB: B/QPSK

1,00E-07

1,00E-06

1,00E-05

1,00E-04

1,00E-03

1,00E-02

1,00E-01

1,00E+00

3 3,5 4 4,5 5 5,5 6

Eb/No (estimated)

BE

R

BPSK &VIT_2/3

BPSK &VIT_3/4

BPSK &VIT_5/6

BPSK &VIT_7/8

QPSK &VIT_1/2

QPSK &VIT_2/3

QPSK &VIT_3/4

QPSK &VIT_5/6

QPSK &VIT_7/8

UncodedTheory

BPSK offset = +0.2 dB Fig. 5.5: BER vs. estimated Eb/N0 characteristics for B/QPSK (DVB framing) Here one can see that in the left diagram the BPSK and QPSK curves are not aligned, as it is postulated by theory (that is same characteristics for BPSK and QPSK modulation). In the right diagram one offset parameter (adding 0.2 dB to all BPSK curves) was simply used to bring each BPSK curve into line with the corresponding QPSK curve (per coding rate). In Figure 5.6 there is as an example a more detailed picture - for BPSK and QPSK modulation with a particular coding (Viterbi with CR 3/4). Six groups are presented:

• DVB framing and concatenated coding (Viterbi + RS) - green • IBS framing and concatenated coding (Viterbi + RS) - blue • IBS framing and pure convolution inner coding (only Viterbi) - orange • Reference curves (specified in [RAD-a]) – gray • Uncoded theory curve [SKLAR] – black • For DVB/BPSK: measured (not the estimated) Eb/N0 – red

B/QPSK + Viterbi_34 (w & w/o RS)

1,00E-07

1,00E-06

1,00E-05

1,00E-04

1,00E-03

1,00E-02

1,00E-01

1,00E+00

3 4 5 6 7 8

Eb/No

BE

R

DVB: BPSK

DVB: QPSK

IBS: BPSK (w RS)

IBS: QPSK (w RS)

B/QBSK: Specificationw RS

IBS: BPSK (w/o RS)

IBS: QPSK (w/o RS)

B/QPSK: Specificationw/o RS

Uncoded Theory

BPSK: measured Eb/No

Fig. 5.6: BER vs. Eb/N0 for B/QPSK and Viterbi 3/4 (w & w/o RS)

B/QPSK

55

Here the same affect appears – the BPSK and QPSK curves are not aligned. Furthermore there is a discrepancy to pre-calculated specification characteristics, as presented in [RAD-a], too. In other words, the modem estimator diverts with his estimations from the reference curves of about 1 dB and more. Moreover the Eb/N0 ratios measured with the spectrum analyzer divert more than 1 dB.

B/QPSK + Viterbi_34 (w & w/o RS)

1,00E-07

1,00E-06

1,00E-05

1,00E-04

1,00E-03

1,00E-02

1,00E-01

1,00E+00

3 4 5 6 7 8

Eb/No

BE

R

DVB: BPSK

DVB: QPSK

IBS: BPSK (w RS)

IBS: QPSK (w RS)

B/QBSK: Specificationw RS

IBS: BPSK (w/o RS)

IBS: QPSK (w/o RS)

B/QPSK: Specificationw/o RS

Uncoded Theory

B/QPSK + Viterbi_34 (w & w/o RS)

1,00E-07

1,00E-06

1,00E-05

1,00E-04

1,00E-03

1,00E-02

1,00E-01

1,00E+00

3 4 5 6 7 8

Eb/No

BE

R

DVB: BPSK

DVB: QPSK

IBS: BPSK (w RS)

IBS: QPSK (w RS)

B/QBSK: Specificationw RS

IBS: BPSK (w/o RS)

IBS: QPSK (w/o RS)

B/QPSK: Specificationw/o RS

Uncoded Theory

BPSK+VITERBI+RS = +1,3dB QPSK+VITERBI+RS = +1,1dB

BPSK+VITERBI = +0,9dB QPSK+VITERBI = +1,3dB

Fig. 5.7: BER vs. estimated Eb/N0 for B/QPSK and Viterbi 3/4 (w & w/o RS) Nevertheless, different offset parameters can be applied to bring B/QPSK and the pre-calculated specification curves for concatenated coding (DVB framing) and pure inner coding (IBS framing with Viterbi coding and without RS) into line, as one can see easily in Figure 5.7. The offset parameters used to shift the different curves to the reference curves are:

Mode Modulation Conv. Coding Block Coding

Offset [dB]

BPSK Viterbi RS 1,3 DVB QPSK Viterbi RS 1,1 BPSK Viterbi X 0,9

IBS QPSK Viterbi X 1,3

Tab. 5.8: Offset values between BPSK and QPSK to Q/BPSK reference characteristics In Figure 5.8 there are all BER vs. Eb/N0 characteristics related to DVB-DSNG depicted: Eb/N0 ratios are estimated values as fetched in this measurement series from the satellite modem before correction. The three black envelopes drawn relate to uncoded theory curves for B/QPSK, 8PSK, 16QAM [SKLAR, PEREZ].

56

DVB - DSNG

1,00E-07

1,00E-06

1,00E-05

1,00E-04

1,00E-03

1,00E-02

1,00E-01

1,00E+00

3 4 5 6 7 8 9 10 11

Eb/No (estimated)

BE

R

BPSK & VIT_2/3

BPSK & VIT_3/4

BPSK & VIT_5/6

BPSK & VIT_7/8

QPSK & VIT_1/2

QPSK & VIT_2/3

QPSK & VIT_3/4

QPSK & VIT_5/6

QPSK & VIT_7/8

Uncoded Theory(B/QPSK,8PSK,16QAM)8PSK & TRE_5/6

8PSK & TRE_8/9

16QAM & TRE_3/4

16QAM & TRE_7/8

Fig. 5.8: BER vs. estimated Eb/N0 for DVB-DSNG As exemplification there are following differing Eb/N0 examples obtainable for BPSK and QPSK modulation with Viterbi (CR 3/4) and RS (CR 188/204) coding for BER=10-6, which all should be more or less equal:

• Estimated value by the satellite modem - Appendix B.2 o BPSK, DVB framing: 4.32 dB o QPSK, DVB framing: 4.44 dB o BPSK, IBS framing: 4.59 dB o QPSK, IBS framing: 4.11 dB

• Calculated value measured by the spectrum analyzer (3 samples) – Fig. 5.6, Tab. B.7 o BPSK, DVB framing: 6.03 dB o QPSK, DVB framing: 6.07 dB

• Reference value specified by the vendor - figure Appendix B.1, from [RAD-a] o B/QPSK, DVB framing: 4.9 dB

• Reference value of the standard - figure Appendix B.1, from [RAD-a] o B/QPSK, DVB framing: 5.6 dB

5.2.3. Discussion of the Output Values of the Satellite Modem

To keep the focus on the question which values could be used for the closed-loop controller implementation for ACM was one outcome of the analysis of the present measuring series, respectively the relevant raw data. For a software-based implementation it’s obvious that only communication to the hardware via SNMP could be applicable.

16QAM 8PSK B/QPSK

57

Hypothetically, there exist five readable MIB values, related to the RX part of the satellite modem, which could be used for that purpose1:

• Eb/N0: estimated Eb/N0 ratio as seen by the demodulator (in dB) • Input Level: estimated receive signal level as seen by the demodulator (in dBm) • Bit Errors: current error count from the Viterbi decoder (in counts) • Raw BER: estimated channel error rate (before decoding) • Corrected BER: estimated by FEC corrected bit error rate

In detail:

• Eb/N0: As described above the Eb/N0 estimator is not very well calibrated. However, only relative values between different CM pairs are necessary, in other words there is no need for an absolute reference to the characteristics specified.

• Input Level (RXpower): It’s just an integer value, and shows hardly an acceptable numerical resolution.

• Bit Errors (countBER): This value seems not to be reliable. Because as one can see comparing the raw data in Appendix B.2, for example for 8PSK and CR 5/6 (DVB, 8PSK, TRELLIS_5/6,) where values appear as zero. Furthermore in QPSK and CR 1/2 (DVB, QPSK, VITERBI_1/2), line TXpower=-9.9 dB, the difference of the two countBER values is negative, maybe caused by an internal counter overrun. On the other hand there seems to be a direct relation implemented, but undocumented, linking the value rawBER and the difference of error counts (countBER) between two measuring points:

rawBER = (countBER2 - countBER1) / (datarate * idletime * 20)

• Raw BER (rawBER): As shown in Figure 5.3 there is no significant numerical resolution. On the other side this curve seems to be strongly related to the measured BER characteristic.

• Corrected BER (corrBER): Just partly usable - neither for the Viterbi CR 2/3 and CR 5/6 (if B/QPSK modulation) nor for the modulation types 8PSK and 16QAM exist values differing from zero.

As a consequence of the above described only the Eb/N0 value of the satellite modem, corrected by a factor, will be used practically in the next step by the closed-loop controller implementation.

1 See 3.3.2 READable Values

58

5.2.4. Correcting the Estimator of the Satellite Modem

Figure 5.9 depicts the second measuring series where the transmit power level (TXpower) was fixed and the modulation and coding types (with DVB framing) were altered. There one can see that there appeared different deviations in the Eb/N0 values per CM pair - these values are estimations by the demodulator / decoder (receiver) part of the modem. The symbol rates (in sps), related to CM pairs, vs. raw Eb/N0 ratios are drawn in dotted line along the x- coordinate – from right to left: 4 points BPSK (CR from 2/3 to 7/8), 5 points QPSK (from 1/2 to 7/8), 2 points 8PSK (5/6, 8/9), 2 points 16QAM (3/4, 7/8). For the aim of comparison one curve (with TX power = -4.5 dBm) related to (C+N)/N (respectively Eb/N0) ratios1 measured by the spectrum analyzer is depicted additionally (“-4.5 msrd”). For that one curve the raw data can be found in Appendix B.2 2, the associated spectral images in Figure 5.10. Note that there the areas under these spectral image graphs are constant.

Raw & Corrected Estimator TXpower [dB]

5,006,007,00

8,009,00

10,0011,00

12,0013,00

0 1000000 2000000 3000000 4000000

Symbol Rate [sps]

Eb

/No

[d

B]

-4,5

-5,5

-6,0

-8,0

-4,5(msrd)Reihe

Fig. 5.9: Raw and corrected Eb/N0 values for different TX power (and different CM pairs) Next a correction is done based on the raw data by adding a specific offset value to the estimated Eb/N0 values per modulation type to make the different, measured values comparable, whereas the QPSK modulation type acts as the reference. Now the solid lines in Figure 5.9 show the different Eb/N0 curves after correction by offset values.

1 Conversion formula: C/N = 10 log [10^(C+N)/N/10 – 1) [dB] and equation (1.16) 2 Tab. B.8: Estimated and measured/calculated Eb/N0 values for fixed TX power (-4.5 dBm)

16QAM QPSK BPSK 8 P S K

7/8 3/4 8/9 5/6 7/8 5/6 3/4 2/3 1/2 7/8 5/6 3/4 2/3

59

BPSK CR 1/2: -7.99 dB BPSK CR 2/3: -9.11 dB BPSK CR 3/4: -9.50 dB

BPSK CR 5/6: -10.21 dB BPSK CR 7/8: -10.60 dB

QPSK CR 1/2: -9.82 dB QPSK CR 2/3: -11.20 dB QPSK CR 3/4: -11.57 dB

QPSK CR 5/6: -12.33 dB QPSK CR 7/8: -12.64 dB

8PSK CR 5/6: -14.08 dB 8PSK CR 8/9: -14.27 dB

16QAM CR 3/4: -15.20 dB 16QAM CR 7/8: -16.11 dB Fig. 5.10: Spectrum of different coding & modulations with measured (C+N)/N ratios (DVB)

60

Correction of the Estimator

7,008,00

9,0010,00

11,0012,00

13,0014,00

15,0016,00

17,00

0 1000000 2000000 3000000 4000000 5000000

Symbol Rate [sps]

Eb

/No

, C/N

[dB

]

Eb/Nocalculated

Eb/Noestimated

Eb/Nocorrected

C/N measured

C/N referenced(to 12,2dB)

Fig. 5.11: Measured and referenced C/N characteristics (for different CM pairs) To inspect and show the reason for the necessity of the implemented corrections, a calculation is done based on a forced constant Eb/N0 value of 12.2 dB to reach a C/N reference characteristic1. The contiguous characteristic of this C/N reference curve can be seen in Figure 5.11 (drawn in black). By contrast the measured C/N curve (drawn in red) has one noticeable discontinuity between BPSK and QPSK. This points to a problematic modem firmware, whereas the increasing carrier value jumps there. Following offset values are now applied to smooth the curves (related to QPSK):

Modulation Offset Value [dB]

BPSK -0.55 QPSK 0 8PSK 0.55

16QAM -1.2

Tab. 5.9: Offset values per modulation type to correct estimated Eb/N0 The result of these corrections can be seen finally in Figure 5.9. 1 For the data see Table B.9

16QAM QPSK BPSK 8 P S K

7/8 5/6 3/4 2/3 1/2 7/8 5/6 3/4 2/3 1/2 7/83/4 8/95/6

61

5.2.5. Resulting Eb/N0 Threshold

After collecting all modem characteristics a simple linear regression analysis (kx + d) of the (logarithmic) BER vs. (linear) Eb/N0 straight lines per CM pair was made with help of Windows Excel. In the next step inter- respectively extrapolations plus the necessary corrections yield the desired Eb/N0 threshold levels to reach a particular BER. In Table 5.10 the symbol rate RS and utilized absolute bandwidth W is also listed per CM pair (for a permanently impressed data rate of 2.048 Mbps), furthermore the required, corrected Eb/N0 ratio to reach a particular BER (for example 10-5, 10-6, 10-7).

Linear Regression

Eb/No [dB] (BER= )

Mode MOD Convolution Coding RS1 CR

Symbol rate Rs [sps]

Band-width [MHz]

d kx 10-5 10-6 10-7

1/2 ena 0,46 4468364 6,03 - - - - - 2/3 ena 0,61 3351273 4,52 3,155 -0,095 3,83 3,93 4,02 3/4 ena 0,69 2978909 4,02 3,330 -0,165 4,35 4,52 4,68 5/6 ena 0,77 2681018 3,62 3,988 -0,143 4,90 5,05 5,19

BPSK Viterbi

7/8 ena 0,81 2553351 3,45 4,421 -0,150 5,37 5,52 5,67 1/2 ena 0,46 2234182 3,02 2,881 -0,121 3,48 3,60 3,72 2/3 ena 0,61 1675636 2,26 3,285 -0,119 3,88 4,00 4,12 3/4 ena 0,69 1489455 2,01 3,604 -0,139 4,30 4,44 4,58 5/6 ena 0,83 1340509 1,81 4,137 -0,164 4,96 5,12 5,29

QPSK Viterbi

7/8 ena 0,81 1276675 1,72 4,708 -0,137 5,39 5,53 5,67 2/3 ena 0,61 1117091 1,51 - - - - - 5/6 ena 0,77 893673 1,21 5,490 -0,189 6,98 7,17 7,36 8PSK Trellis

8/9 ena 0,82 837818 1,13 6,369 -0,225 8,04 8,27 8,49 3/4 ena 0,69 744727 1,01 7,609 -0,174 7,28 7,45 7,63

DVB

16QAM Trellis 7/8 ena 0,81 638338 0,86 9,028 -0,221 8,93 9,15 9,37 1/2 X 0,50 4369067 5,90 1,860 -0,620 4,96 5,58 6,20 BPSK Viterbi 3/4 X 0,75 2912711 3,93 2,295 -0,718 5,89 6,60 7,32 1/2 X 0,50 2184533 2,95 1,031 -0,703 4,54 5,25 5,95 QPSK Viterbi 3/4 X 0,75 1456356 1,97 1,765 -0,741 5,47 6,21 6,95

8PSK Trellis 2/3 X 0,67 1092267 1,47 2,014 -0,978 6,91 7,88 8,86 1/2 ena 0,46 4760326 6,43 - - - - - BPSK Viterbi 3/4 ena 0,69 3173551 4,28 3,417 -0,195 4,39 4,59 4,78 1/2 ena 0,46 2380163 3,21 2,517 -0,130 3,17 3,30 3,43 QPSK Viterbi 3/4 ena 0,69 1586775 2,14 3,222 -0,149 3,97 4,11 4,26

IBS

8PSK Trellis 2/3 ena 0,61 1190082 1,61 - - - - - Tab. 5.10: Utilized Bandwidth vs. Eb/N0 (for different BER levels)

1 RS coding with fixed CR of 188/204

62

As one can see easily in the spectral images in Figure 5.10 the utilized symbol rate is equal the Nyquist bandwidth W0, whereas W0 represents the minimum bandwidth for rectangular spectrum (raised-cosine roll-off factor α=0) and “half-amplitude point” bandwidth for common raised-cosine spectra [SKLAR]. E.g. for QPSK CR 1/2 the “half-amplitude point” at -24.5 dBm (C/2 is C+N peak minus approximately 3 dB) is about 2 times 1.1 grid squares at the 70 MHz centre frequency. With the setting of spectrum span to 10 MHz, divided over the length of 10 squares, it makes for W0 2.2 MHz and for RS 2.2 106 symbols per second. In the bandwidth column in Table 5.10 the absolute bandwidth W is listed, which was calculated by multiplying factor 1.35 (1 + raised-cosine roll-off factor α 1) to the symbol rate2.

Performance Characteristics

0,00

1,00

2,00

3,00

4,00

5,00

6,00

2 3 4 5 6 7 8 9 10

Eb/No [dB]

Ban

dw

idth

[MH

z]

BPSK

(w/o RS)

QPSK

(w/o RS)

8PSK

(w/o RS)

16QAM

Fig. 5.12: Different performance curves: utilized bandwidth vs. corrected Eb/N0 per modulation type (solid lines for BER=10-6) In Figure 5.12 the solid lines show as result for BER=10-6 the utilized bandwidth vs. corrected Eb/N0 ratio as they will be used for the following closed-loop controller implementation - only the eight in Table 5.10 highlighted CM pairs will be applied, but:

• BPSK will be skipped because BPSK and QPSK modulation has the same BER vs. Eb/N0 characteristics, but BPSK needs double bandwidth (i.e. a higher symbol rate is needed to reach the permanently impressed data rate).

• CM pair 8PSK with CR 2/3 (DVB, 8PSK, TRELLIS_2/3) was excluded3. • CM pair 16QAM with CR 3/4 (DVB, 16QAM, TRELLIS_3/4) overlaps 8PSK with CR

8/9 (DVB, 8PSK, TRELLIS_8/9), so this 16QAM 3/4 pair was excluded.

1 DVB-S uses a fixed raised-cosine roll-off factor α of 0.35 [EN 300 421] 2 DMD20-MIB OID radDmd20RxSymbolRateHz 3 See 5.2.2 Measuring Series

1/2

2/3

2/3

3/4 5/6 7/8

3/4 5/6

7/8

7/8 3/4

5/6 8/9

3/4

3/4

1/2

1/2

2/3

63

• All IBS framing CM pairs are unconsidered because of two reasons: focusing generally to DVB and also downtime is too high when switching between DVB and IBS framing.

Additionally, in Figure 5.12 the dotted lines show for five CM pairs (with IBS framing, marked with +) the characteristics as it would appear tentatively without outer RS block coding. Furthermore for all points in the diagram the variation for BER=10-5 and BER=10-7 is also drawn - marked with two black or grey dashes left and right of the point.

64

5.3. Controller Implementation

5.3.1. Developed Managing Application <mt2.exe>

As second developed software program (mt2.exe) a more-or-less heuristic1 closed-loop implementation was written which controls the appearing BER level of a satellite modem when communication (satellite) channel characteristics changes (e.g. fading by rain) by an adaptive coding & modulation (ACM) strategy. The objective is here to correct as fast as feasible2 when a particular BER level will be exceeded to keep the quality of the satellite transmission! Because the lab setting implicated the utilization of a constant data (i.e. information) rate - the data were generated by the BER tester, the data rate is specified by the serial interface definition to 2.048 Mbps - the loss and gain can be shown in a changing symbol rate, i.e. in a need of bandwidth. That means when e.g. the channel quality is decreasing (go worse) more bandwidth is needed to keep the bit errors rate under a particular ratio. The basic concept of the ACM closed-loop implementation is a feedback n-step controller with different parametrizable strategies to improve the stability and to increase the convergence time. The internal data representation of Eb/N0 is normalized to QPSK mode by additive factors out of Table 5.9 (Offset Value). For the calculation of the necessary Eb/N0

thresholds (with BER as parameter) – utilized for the stepwise adaption of modulation and coding – the pre-defined modem characteristics of the linear regression calculation out of Table 5.10 (kx, d) were applied. These initial application values for kx , d and offset are stored in incrementing order per used CM pair (defined by MODnumber and CODenumeration 3) in file <ref.txt>. The different Eb/N0 thresholds (per CM pair) can then be calculated: Eb/N0 [dB] = kx * log10 BER + d + offset Figure 5.12 shows the performance curves as they will be used by the controller process. The controller algorithm “walks” along this line, with BER as parameter, in reference to the appeared estimated Eb/N0 ratio. Lowering the BER reference value shifts the curve just more to the right.

1 Heuristics stand for strategies using readily accessible, though loosely applicable, information to control problem-solving [Wikipedia] 2 Always the same problem: convergence time in contrast to stability! 3 Tab. 5.7: Available coding & modulation (CM) pairs in DVB and IBS framing mode (DMD20)

65

Performance Characteristics BER=

0,00

1,00

2,00

3,00

4,00

3 4 5 6 7 8 9 10 11

Eb/No [dB]

Ban

dw

idth

[MH

z]

1,0E-05

1,0E-06

1,0E-07

Fig. 5.12: Performance characteristics (bandwidth vs. Eb/N0) of the coding and modulation pairs used Figure 5.13 shows the flow chart of the application, itemized processing steps are:

• init program with o configuring data from file <conf.txt> o referencing CM pairs to Eb/N0 threshold from file <ref.txt>

• setup modem parameters (optional) o TX modulation & RX demodulation type MODnumber o TX/RX FEC code type CODnumber o TX power level POWER

• permanent measurement of o Eb/N0 status o estimated Eb/N0 value

• analyze measured Eb/N0 data o deciding about new CM pair by best matching to Eb/N0 thresholds o or if Eb/N0 state is not valid - decrement current CM pair to next lower one o write new info line to file <log2.txt>

• set new modulation and/or coding type in TX and RX part of the modem o waits a definite idle time to lock receiver

QPSK 3/4 QPSK

7/8 8PSK 5/6 8PSK

8/9 16QAM 7/8

QPSK 1/2

QPSK 2/3

QPSK 5/6

66

Fig. 5.13: Flow chart of <mt2.exe> Binary <mt2.exe> : USAGE: mt2 [OPTIONS] EXAMPLE: mt2 –m 1 –c 1 –p -9.0 –A –t Setup modem parameters (optional) and then controls the BER value (by adaptive variation of coding and modulation). Additional used files <ref.txt>, <conf.txt> and <lo g2.txt> OPTIONS: -h displays this help message -m MODnumber set start value for modulation and d emodulation 1=QPSK | 2=BPSK | 3=8PSK | 4=16QAM -c CODnumber set start value for FEC coding when MODnumber=1|2: 1=VITERBI1x2 | 2=VITERBI2x3 | 3=VITERBI3x4 |

4=VITERBI5x6 | 5=VITERBI7x8 when MODnumber=3: 1=TRELLIS2x3 | 2=TRELLIS5x6 | 3=TRELLIS8x9

when MODnumber=4: 1=TRELLIS3x4 | 2=TRELLIS7x8 -r BER set BER threshold (default=1.0E-6)

67

-p POWER set transmit power level (in dB) -o HIGH_WATER_MARK set high water mark (hysteresis ) -n LOOPS set the max number of steps -A toggles follow-up statistics (average) -M toggles follow-up statistics (median) -F switches off Eb/No=0 check (in NO_AVG_LOOP) -t infinite number of steps -d run in demo mode (in addition to –y or –x) a) FILE FORMAT (per line) for <log2.txt>: indx;timestamp;MODtype_1;CODtype_1;iCM_1;symbolrate _1;RXpower;Eb/No_status;Eb/No_raw;Eb/No_calibr;MODtype_2;CODtype_2;iCM_2;sy mbolrate_2;Eb/No_ref EXAMPLE: 5;19:00:41;psk8(3);trellis5x6(17);6;893673;-14.0;7; 8.76;9.31;psk8(3);trellis8x9(19);7;837818;7.72 VALUES: indx consecutive counter timestamp timestamp at the beginning of the measu rement (hours:minutes:seconds) MODtype_1 string value, representing current sett ing before (as defined in DMD20-MIB) CODtype_1 string value, representing current sett ing before (as defined in DMD20-MIB) iCM_1 consecutive number for CM pair, before symbolrate_1 (in symbols per seconds) RXpower estimated power level by the demodulator (in dB) Eb/No_status status of the estimator (state defined in DMD20-MIB) Eb/No_raw estimated Eb/No value Eb/No_calibr calibrated estimated Eb/No value MODtype_2 string value, representing current sett ing after (as defined in DMD20-MIB) CODtype_2 string value, representing current sett ing after (as defined in DMD20-MIB) iCM_2 consecutive number for CM pair, after symbolrate_2 (in symbols per seconds) Eb/No_ref uncalibrated reference Eb/No value (thr eshold) b) FILE FORMAT (per line) for <conf.txt>: DEFINITION values EXAMPLE: #[PARAMETER] : POWER_LEVEL -9.6 START_MOD 1 START_COD 1 BER_THRESHOLD 1.0E-7 HWM_EBNO 0.2 DAMP_INCR 40 DAMP_DECR 10 CORR_EBNO_8PSK 0.55 CORR_EBNO_16QAM -1.2 #[SLEEPs] : SLEEP_AFTER_MOD 10

68

SLEEP_AFTER_16QAM 30 SLEEP_AFTER_COD 5 DEFINITIONS: #[TEXT] : comment line (always beginning with #) POWER_LEVEL power set transmit power level (in dB) START_MOD MODnumber set start value for modulation and demodulation 1=QPSK | 2=BPSK | 3=8PSK | 4=16QAM START_COD CODnumber set start value for FEC coding when MODnumber=1|2: 1=VITERBI1x2 | 2=VITERBI2x3 | 3=VITERBI3x4 |

4=VITERBI5x6 | 5=VITERBI7x8 when MODnumber=3: 1=TRELLIS2x3 | 2=TRELLIS5x6 | 3=TRELLIS8x9

when MODnumber=4: 1=TRELLIS3x4 | 2=TRELLIS7x8 BER_THRESHOLD val set BER threshold HWM_EBNO val set high water mark (in dB) LWM_EBNO val set low water mark (in dB) DAMP_INCR val set penalty factor for dampening (i n dB/100) DAMP_DECR val set redemption factor for dampening (in dB/100) CORR_EBNO_BPSK val set correction factor for BPSK CORR_EBNO_QPSK val set correction factor for QPSK CORR_EBNO_8PSK val set correction factor for 8PSK CORR_EBNO_16QAM val set correction factor for 16QA M NO_AVG_LOOP n set number of measures to calculate an average SLEEP_AFTER_MOD sec set idle time after modulation change (generic) SLEEP_AFTER_8PSK sec set idle time after modulatio n change to 8PSK SLEEP_AFTER_16QAM sec set idle time after modulati on change to 16QAM SLEEP_AFTER_COD sec set idle time after coding cha nge SLEEP_LOOP sec set idle time between two steps SLEEP_AVG_LOOP sec set idle time in the average lo op c) FILE FORMAT (per line) for <ref.txt>: MODnumber;CODenumeration; kx;d; offset EXAMPLE: 1;2; -0.121;2.881; 0.0 1;3; -0.119;3.285; 0.0 1;4; -0.139;3.604; 0.0 1;5; -0.164;4.137; 0.0 1;6; -0.137;4.708; 0.0 3;17; -0.189;5.490; 0.55 3;19; -0.225;6.369; 0.55 4;18; -0.221;9.028; -1.2

VALUES: MODnumber type of modulation 1=QPSK | 2=BPSK | 3=8PSK | 4=16QAM CODenumeration type of FEC coding when MODnumber=1|2: 1=VITERBI1x2 | 2=VITERBI2x3 | 3=VITERBI3x4 |

4=VITERBI5x6 | 5=VITERBI7x8 when MODnumber=3: 15=TRELLIS2x3 | 17=TRELLIS5x6 | 19=TRELLIS8x9

when MODnumber=4: 16=TRELLIS3x4 | 18=TRELLIS7x8 kx modem characteristics (linear regression) d modem characteristics (linear regression) offset calibration factor for Eb/No

69

5.3.2. Controller Concept

As solution for the task to protect a particular BER level a straightforward closed-loop feedback n-step controller1 was implemented (Figure 5.14). As command variable the estimated and corrected Eb/N0 ratio was selected, the output of the controller is indirectly the resulting CM pair which is applied to satellite modem TX and RX part. Generally, the Eb/N0 value itself is a function of BER and CM pair. As initial set value a particular BER level value is to choose (e.g. BER_THRESHOLD = 1.0E-6 ). This value is converted by help of the BER vs. Eb/N0 characteristic curves with particular CM pair as parameter, the resulting Eb/N0 value acts than as reference input. Now the actuator has to vary the n available CM pairs to minimize the Eb/N0 difference between pre-calculated reference Eb/N0 and feedbacked Eb/N0 ratio, estimated by the satellite modem. In other words, when the system deviation reaches a specific threshold the controller has to swap to a newly best matching CM pair (i.e. changing of modulation and/or coding type) in an acceptable time. It’s important to make these stepping not to fast but rather to delay the controller with a finite observation (test) interval (NO_AVG_LOOP * SLEEP_AVG_LOOP) and some hold (idle) timer to improve the stability, but for the cost of convergence time. Cumulative timers are:

• After each change of modulation: SLEEP_AFTER_MOD seconds o Or more specific

� After change to 8PSK: SLEEP_AFTER_8PSK seconds � After change to 16QAM: SLEEP_AFTER_16QAM seconds

• After each change of coding: SLEEP_AFTER_COD seconds • After each step: SLEEP_LOOP seconds

Fig. 5.14: Controller and controlled system

1 In control theory, a controller is a device which monitors and affects the operational conditions of a given dynamical system [Wikipedia]

70

As a first step to check the behavior of <mt2.exe > the program did run in a software-simulated environment. Two different implemented strategies (Hysteresis, Dampening) to improve stability could be tested firstly. Hysteresis In Figure 5.15 the effect of using different high-water marks for the stability can be seen, whereas the low-water mark is always set to zero. High-water and low-water marks are used generally to emulate a particular hysteresis characteristic whereat the aim is to reduce the number of triggered controller actions (i.e. changes of CM pairs) when feedbacked input (Eb/N0) tends to fluctuate.

High Water mark = 0.0 [dB]

0

500000

1000000

1500000

2000000

2500000

Number of Steps

Sym

bo

l R

ate

[sp

s]

3

3,5

4

4,5

5

5,5

6

Eb

/No

[d

B]

Symbol rate

Eb/No

High Water mark = 0.1 [dB]

0

500000

1000000

1500000

2000000

2500000

Number of Steps

Sym

bo

l R

ate

[sp

s]

3

3,5

4

4,5

5

5,5

6

Eb

/No

[d

B]

Symbol rate

Eb/No

High Water mark = 0.2 [dB]

0

500000

1000000

1500000

2000000

2500000

Number of Steps

Sym

bo

l R

ate

[sp

s]

3

3,5

4

4,5

5

5,5

6

Eb

/No

[d

B]

Symbol rate

Eb/No

High Water mark = 0.3 [dB]

0

500000

1000000

1500000

2000000

2500000

Number of Steps

Sym

bol

Rat

e [s

ps]

3

3,5

4

4,5

5

5,5

6

Eb/

No

[d

B]

Symbol rate

Eb/No

Fig. 5.15: Controller steps parameterized with different high-water-marks In this simulation a slowly increase of the Eb/N0 ratio from 4 dB to 5 dB (blue line) was assumed, but the progression was superimposed by some jitter. Four different high-water marks were applied. In the picture top left the high-water mark was zero, thereby the controller alters the CM pair totally 10 times - using 4 different code rates between 1/2 and 5/6 with QPSK. As one can see with rising the high-water mark (from 0.1 dB to 0.3 dB) the number of controller actions decrease (from 7 to 3 changes). However as one can see also, the overall performance decreases: at the beginning when no high-water mark was specified the controller starts with CR 2/3 (1.67 Msps), but when this mark applied is greater than zero the initial CR is just set to 1/2 (2.23 Msps).

71

In Figure 5.15 the CM pairs used are drawn on the left y-axis with the referring symbol rates out of Table 5.10. The high-water and the low-water mark can be set in configuration file <conf.txt> by the key word HWM_EBNO and LWM_EBNO. Dampening Now in Figure 5.16 the effect of using a dampening strategy for the stability can be seen. Dampening means when feedbacked input (Eb/N0 ratio) alters around a more or less constant level then resulting flapping changes are suppressed. Dampening can also mitigate temporarily an appearing dead-lock situation. This strategy implemented is just simple: when a CM pair chances downwards the predecessor CM pair is marked with a penalty value (DAMP_INCR). After each cycle of the controller the penalties are lowered linearly by a definite redemption factor (DAMP_DECR). These two factors modifying Eb/N0 are in the range of hundredth of dB. In other words the two factors of modification applied define height and width of the dampening.

Damping: INCR=0 / DECR=0

1350000

1400000

1450000

1500000

1550000

1600000

1650000

1700000

Number of Steps

Sym

bo

l R

ate

[sp

s]

4

4,1

4,2

4,3

4,4

4,5

4,6

4,7

4,8

4,9

5

Eb

/No

[d

B]

Symbol rate

Eb/No

Damping: INCR=40 / DECR=10

1350000

1400000

1450000

1500000

1550000

1600000

1650000

1700000

Number of Steps

Sym

bo

l R

ate

[sp

s]

4

4,1

4,2

4,3

4,4

4,5

4,6

4,7

4,8

4,9

5

Eb

/No

[d

B]

Symbol rate

Eb/No

Damping: INCR=40 / DECR=5

1350000

1400000

1450000

1500000

1550000

1600000

1650000

1700000

Number of Steps

Sym

bo

l R

ate

[sp

s]

4

4,1

4,2

4,3

4,4

4,5

4,6

4,7

4,8

4,9

5

Eb

/No

[d

B]

Symbol rate

Eb/No

Damping: INCR=80 / DECR=10

1350000

1400000

1450000

1500000

1550000

1600000

1650000

1700000

Number of Steps

Sym

bo

l R

ate

[sp

s]

4

4,1

4,2

4,3

4,4

4,5

4,6

4,7

4,8

4,9

5

Eb

/No

[d

B]

Symbol rate

Eb/No

Fig. 5.16: Controller steps parameterized with different dampening factors In this simulation a constant Eb/N0 level of 4.45 dB with a fluctuation of about 0.15 dB was assumed (blue line). Four different dampening factors were applied. In the picture top left the dampening factors were all zero, thereby the controller alters the CM pair totally 9 times (using alternately the two code rates 2/3 and 3/4 with QPSK). As one can see with increasing the dampening penalty factor DAMP_INCR (from 0 to 40) and/or decreasing the redemption

72

factor DAMP_DECR the number of controller actions decrease (from 9 to 3 changes). However, the dampening factors have an impact on the convergence time: with the factor combination 40/5 there is a faster recovery from CR 2/3 (1.67 Msps) to CR 3/4 (1.49 Msps) as with 80/10. In Figure 5.16 the CM pairs used are drawn on the left y-axis with the referring symbol rates out of Table 5.10. The dampening penalty and redemption factor can be set in configuration file <conf.txt> by the key word DAMP_INCR and DAMP_DECR. Follow-Up Statistics During the observation loop an accumulation of measuring samples is done. These samples, respectively the trend of these samples, can be analyzed by help of numerical statistics (e.g. calculation of the average value, median, variance, etc.) and also weighted. Furthermore the effect when synchronization is partially respectively temporarily lost and the estimated Eb/N0

is null during this observation period can be concerned in different ways. Then the resulting value can be used as enhanced criterion for the decision process of the controller, compared to the uncertainty only using one (snapshot) measuring value. Four different flavors are implemented:

• Null Values If synchronization is partially respectively temporarily lost, the estimated Eb/N0 values will also be partially zero during this observation period. If this effect appears cumulatively (i.e. not each null value can be cleared by a non-null value) it will be a good strategy to improve stability to mark the resulting value anyway as zero, that means the decision process matches newly a next better CM pair. This strategy can be switched off generally by setting -F in command line

• Average Value Here the average over all samples is calculated (except null values) Can be toggled by -A in command line (mutually exclusive to –M )

• Median Here the 50% median of all samples is calculated (including null values) Can be toggled by -M in command line (mutually exclusive to –A )

• Default Behavior The last sampled Eb/N0 value is used (but only when more specific measured Eb/N0 values are present than null values in the observation loop)

73

5.3.3. Hardware-based Simulations

Now as next step the Micronetics noise generator from Figure 5.1 (Measurement Setup) was replaced by a more practical, continuously adjustable discrete noise source, which was manufactured in-house at the IKS. Noise power level could be tuned manually by a potentiometer in a particular range. So the trend of signal fading could be coarsely played through by hand to test the controller actions. In the next two testing examples (Figure 5.17 and 5.18) one can see the controller steps: floating of the estimated Eb/N0 ratio measured by the satellite modem vs. readjusting of CM pairs. Generally, the blue line (estimated Eb/N0) has to be always over the threshold bars to avoid bit errors. However, it can happen that the decoder looses locking (discontinuous line) because of a rapid event (see in Figure 5.17, step 7) or the Eb/N0 value is at all under the minimum limit for QPSK with a CR 1/2 as last resort (see in Figure 5.18, between step 25 and 28). Also some bit errors appeared sporadically during this testing because of the set time period of the observation interval (see in Figure 5.17, step 26 and in Figure 5.18, step 20) as well as of the downtime between every executed modulation and coding swap, which are obviously as an essential problem not seamless.

TEST (0.4/0.0, 60/10)

0

1

2

3

4

5

6

7

8

0 5 10 15 20 25 30 35 40

Number of Steps ->

Eb

/No

[d

B]

CM pairs(reference)

Eb/No(estimated

Fig. 5.17: Example of a controller run (HWM_EBNO=0.4, DAMP_INCR=60, DAMP_DECR=10)

Typical locking downtime when coding changes previously till re-synchronization is 1 to 2 seconds. Unfortunately, when modulation changes this locking downtime increases to a quite noticeable value. For switching from QPSK to 8PSK it is around 5 to 10 seconds, switching to

- QPSK 1/2 - QPSK 2/3 - QPSK 3/4

- QPSK 5/6

- QPSK 7/8

- 8PSK 5/6

74

16QAM can lasts till 30 seconds. It’s obvious that for this period the communication over the channel is disrupted. Appearing bit errors are marked with colored red, locking downtime with colored orange bars.

TEST (0.5/0.0, 60/5)

0

1

2

3

4

5

6

7

8

9

10

11

12

0 5 10 15 20 25 30 35 40 45

Number of Steps ->

Eb

/No

[dB

]

CM pairs(reference)

Eb/No(estimated)

Fig. 5.18: Example of a controller run (HWM_EBNO=0.5, DAMP_INCR=60, DAMP_DECR=5)

Of course, these behaviors are just snapshots related to the parameters applied. Further testing should be done in an improved automated testing environment which permits varied parameterizations (high-water mark, dampening and statistics appliance) or as well reduced number of CM pairs to examine different aspects of stability and convergence.

- QPSK 1/2

- QPSK 5/6

- QPSK 3/4

- QPSK 7/8

- 8PSK 5/6

- 8PSK 8/9

- 16QAM 7/8

75

6. Conclusions and Outlook For more sophisticated lab simulations of the developed controller software the engineering model of a real communication satellite, called DFS (Deutscher Fernmeldesatellit) Kopernikus, should be accomplished on IKS. This engineering model is called ZKM (Zusätzliches Kommunikationsmodul) and has from the telecommunication point of view identical operational properties due to the original satellite hardware. The DFS Kopernikus was a German communication satellite of the Deutsche Bundespost, designed as multiplexing transparent transponder working in Ku-band (14/11-12 GHz). Three 11-GHz transponders operate with 90 MHz bandwidth; seven 12-GHz transponders operate with 44 MHz bandwidth. For test purposes the DFS was equipped additionally with one experimental Ka-band transponder (30/20 GHz with 90 MHz bandwidth). The first DFS (first of three) was launched successfully to GEO orbit by ARIANE4 in 1989 and had operated till 1994. The last DFS (DFS Kopernikus 3) had operated in the field of telecommunications until 2002 over Germany. For lab simulations the Deutsche Bundespost developed a test bench around this ZKM, simulating the ground communication stations with two sending channels and one receiving channel [ZKM]. This makes it possible to connect modulators and demodulators with 70 MHz or 140 MHz to the selected transponder channels of the ZKM. The ZKM can be operated remotely (e.g. switching the transponders) by a telemetry simulating control panel. Discrete fade simulators are looped-in the experimental 30 GHz uplink and 20 GHz downlink to simulate fading effects by variations of attenuation.

Fig. 6.1: Block diagram of the test bench (only the used 30/20 GHz transponder path is depicted)

76

This test bench, including the ZKM, was decommissioned by the Deutsche Bundespost and is now located at IKS on TU Graz. Furthermore an external fade simulator controller was developed at IKS [KOFLER] to call and run stored live fade effects on the test bench by the help of a PC. Figure 6.1 shows a feasible setting for an advanced testing of the managed 70 MHz DMD20 satellite modem interfacing the transponder test bench. Unfortunately, in the ZKM transponder test bench there occurred a malfunctioning frequency converter, thus no ultimate realistic testing could be made in the course of this master thesis. However, a practical way to implement an adaptation strategy of coding and modulation for satellite modems could be shown and performance improvements by a number of manual simulations in a simple test setup were demonstrated. Nevertheless, the comparison of the developed closed-loop controller software for adaptive code and modulation manipulation of a DVB-S satellite modem with the intrinsic implementation of the next-generation DVB-S2 standard of ACM (with the challenges of symbol timing recovery, frame synchronization, etc.1) must be passed to further studies. As well the improvement of the closed-loop controller by self-learning artificial intelligence strategies (like neuronal network, fuzzy logic, etc.). Finally, from a practical viewpoint the reachable asset for different services through this developed adaptive strategy should be investigated in a next step.

1 [ALBERTAZZI] describes the design complexity of the entire DVB-S2 communication chain, considering practical algorithms for coding, modulation, pre-distortion, carrier and SNR estimation, frame synchronization and data recovery

77

Appendix A: SNMP MIBs

Appendix A.1: DMD20 MIB Subtree Definitions MIB enterprise subtree definitions implemented in RADYNE’s DMD20 satellite modem hardware (but only the relevant parts of the definitions used of the entire subtree are listed). He whole definitions can be found in [RAD-a]. DMD20-MIB DEFINITIONS ::= BEGIN IMPORTS enterprises FROM SNMPv2-SMI MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, NOTIFICAT ION-TYPE, Counter32, Counter64 FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF; radyne OBJECT IDENTIFIER ::= { enterprises 2591 } dmd20 MODULE-IDENTITY LAST-UPDATED "200803101600Z" ORGANIZATION "Radyne Corp" CONTACT-INFO "Customer Service Postal: Radyne Corporation 3138 E. Elwood Street Phoenix, AZ 85034 USA Tel: (602) 437-9620 Fax: (602) 437-4811 Website: www.radn.com" DESCRIPTION "Radyne MIB module." REVISION "200709171600Z" DESCRIPTION "DMD20 MIB Object Identifiers description. This documents cont ents are subject to change without prior notice. The pri vate enterprise number 2591 is a unique identifier assigned to Rady ne by the Internet Assigned Numbers Authority (IANA). This number is used to uniquely define vendor speci fic information such as private MIBs." ::= { radyne 15 } -- groups in Radyne specific MIB -- radyne OBJECT IDENTIFIER ::= { enterprises 2591 } dmd20MibObjects OBJECT IDENTIFIER ::= { dmd20 1 } radDmd20ModNVStatus OBJECT IDENTIFIER ::= { dmd20Mi bObjects 1 } radDmd20ModStatus OBJECT IDENTIFIER ::= { dmd20MibO bjects 2 } radDmd20DemodNVStatus OBJECT IDENTIFIER ::= { dmd20 MibObjects 3 } radDmd20DemodStatus OBJECT IDENTIFIER ::= { dmd20Mi bObjects 4 } radDmd20CommonNVStatus OBJECT IDENTIFIER ::= { dmd2 0MibObjects 5 } radDmd20CommonStatus OBJECT IDENTIFIER ::= { dmd20M ibObjects 6 } radDmd20Traps OBJECT IDENTIFIER ::= { dmd20MibObjec ts 7 } radDmd20Lbst OBJECT IDENTIFIER ::= { dmd20MibObject s 8 } -- -- Textual Conventions

78

-- RadTransmitPowerLevel ::= TEXTUAL-CONVENTION DISPLAY-HINT "d-1" STATUS current DESCRIPTION "Power level in tenths of a dBm. DMD20 = -250..0 (-25.0 to 0 dBm) OM20 = -450..0 (-45.0 to -20.0 dBm)” SYNTAX INTEGER (-450..0) RadReceivePowerLevel ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Receive power level in dBm." SYNTAX INTEGER (-100..0) EbnoType ::= TEXTUAL-CONVENTION DISPLAY-HINT "d-2" STATUS current DESCRIPTION "EbNo in db. There is an implied decima l point." SYNTAX INTEGER (0..2500) BerStatusStringType ::= TEXTUAL-CONVENTION DISPLAY-HINT "8a" STATUS current DESCRIPTION "Raw BER status" SYNTAX OCTET STRING (SIZE (10)) -- -- Dmd20 modem non-volatile status information -- radDmd20TxCarrierLeveldBmX100 OBJECT-TYPE SYNTAX RadTransmitPowerLevel MAX-ACCESS read-write STATUS current DESCRIPTION "Selects the Tx power level in dBm. There is an imp lied decimal point. For example, a value of -100 represents a transmit power level of -10.0 dBm." ::= { radDmd20ModNVStatus 3 } -- radDmd20TxInnerFecRate OBJECT-TYPE SYNTAX INTEGER { none(1), viterbi1x2(2), viterbi2x3(3), viterbi3x4(4), viterbi5x6(5), viterbi7x8(6), reserved7(7), sequential1x2(8), reserved9(9), sequential3x4(10), reserved11(11), sequential7x8(12 ), reserved13(13), reserved14(14), trellis2x3(15), trellis3x4(16), trellis5x6(17), trellis7x8(18), trellis8x9(19), comstream3x4(20), tpc793x2d(21), tpc495x3d(22), tpc1x2(23), tpc3x4(24), tpc7x8(25), tpc21x44(26), tpc750(27), tpc875(28) } MAX-ACCESS read-write STATUS current DESCRIPTION "Selects Tx code rate and type. The reserved select ions are unimplemented types reserved for future use." ::= { radDmd20ModNVStatus 7 } -- radDmd20TxModulationType OBJECT-TYPE SYNTAX INTEGER { qpsk(1), bpsk(2), psk8(3), qam16(4), oqpsk(5) }

79

MAX-ACCESS read-write STATUS current DESCRIPTION "Selects the modulation type." ::= { radDmd20ModNVStatus 8 } -- radDmd20RxInnerFecRate OBJECT-TYPE SYNTAX INTEGER { none(1), viterbi1x2(2), viterbi2x3(3), viterbi3x4(4), viterbi5x6(5), viterbi7x8(6), reserved7(7), sequential1x2(8), reserved9(9), sequential3x4(10), reserved11(11), sequential7x8(12 ), reserved13(13), reserved14(14), trellis2x3(15), trellis3x4(16), trellis5x6(17), trellis7x8(18), trellis8x9(19), comstream3x4(20), tpc793x2d(21), tpc495x3d(22), tpc1x2(23), tpc3x4(24), tpc7x8(25), tpc21x44(26), tpc750(27), tpc875(28) } MAX-ACCESS read-write STATUS current DESCRIPTION "Selects Rx code rate and type. The reserved select ions are unimplemented types reserved for future use." ::= { radDmd20DemodNVStatus 5 } -- radDmd20RxModulationType OBJECT-TYPE SYNTAX INTEGER { qpsk(1), bpsk(2), psk8(3), qam16(4), oqpsk(5) } MAX-ACCESS read-write STATUS current DESCRIPTION "Selects the demodulation type." ::= { radDmd20DemodNVStatus 6 } -- radDmd20RxBerEbnoStatus OBJECT-TYPE SYNTAX INTEGER (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "A bit field. On startup, the agent initializes thi s to the value '00000000'B Bit 0 = Raw BER and corrected BER status. 1 = Valid Bit 1 = Test BER status 1 = Valid Bit 2,3 = EbNo status 0 = EbNo invalid 1 = EbNo valid 2 = EbNo is smaller than indicated value 3 = EbNo is greater than indicated value Bit 4..7 = Reserved" ::= { radDmd20DemodStatus 13 } -- radDmd20RxEbno OBJECT-TYPE SYNTAX EbnoType MAX-ACCESS read-only STATUS current DESCRIPTION "Estimated EbNo as seen by the demodulator, 2 impli ed decimal places."

80

::= { radDmd20DemodStatus 14 } -- radDmd20RxCarrierLeveldBmX100 OBJECT-TYPE SYNTAX RadReceivePowerLevel MAX-ACCESS read-only STATUS current DESCRIPTION "Estimated receive signal level, implied decimal po int" ::= { radDmd20DemodStatus 16 } -- radDmd20RxBitErrorCount OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Shows the number of errors detected in the data st ream" ::= { radDmd20DemodStatus 17 } -- radDmd20RxSymbolRateHz OBJECT-TYPE SYNTAX Unsigned32 (9600..10000000) MAX-ACCESS read-only STATUS current DESCRIPTION "Demodulator symbol rate." ::= { radDmd20DemodStatus 20 } -- radDmd20RxRawBerStatus OBJECT-TYPE SYNTAX BerStatusStringType MAX-ACCESS read-only STATUS current DESCRIPTION "Raw BER status" ::= { radDmd20DemodStatus 30 } -- radDmd20RxCorrectedBerStatus OBJECT-TYPE SYNTAX BerStatusStringType MAX-ACCESS read-only STATUS current DESCRIPTION "Corrected BER status" ::= { radDmd20DemodStatus 31 }

81

Appendix A.2: DMD20 MIB Example of the content of the DMD20-MIB subtree. The used OIDs are depicted in bold. %snmpwalk -c public -v 2c –M mibs –m DMD20-MIB 192.168.0.2 1.3.6.1.4.1.2591

DMD20-MIB::radDmd20TxCarrierControl.0 = INTEGER: au to(3) DMD20-MIB::radDmd20TxNetworkSpec.0 = INTEGER: dvbSa t(5) DMD20-MIB::radDmd20TxCarrierLeveldBmX100.0 = INTEGER: -6.0 DMD20-MIB::radDmd20TxCarrierFrequencyHz.0 = Wrong T ype (should be Gauge32 or Unsigned32): INTEGER: 70000000 DMD20-MIB::radDmd20TxTerrDataRateHz.0 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 2048000 DMD20-MIB::radDmd20TxStrapCode.0 = INTEGER: 0 DMD20-MIB::radDmd20TxInnerFecRate.0 = INTEGER: viterbi7x8(6) DMD20-MIB::radDmd20TxModulationType.0 = INTEGER: qpsk(1) DMD20-MIB::radDmd20TxSatFraming.0 = INTEGER: framin gDvb(5) DMD20-MIB::radDmd20TxOuterFecEnable.0 = INTEGER: en able(2) DMD20-MIB::radDmd20TxOuterFecRate.0 = INTEGER: rsCu stomNK(6) DMD20-MIB::radDmd20TxInterleaverDepth.0 = INTEGER: interleaverDepth12(3) DMD20-MIB::radDmd20TxDropMode.0 = INTEGER: disable( 1) DMD20-MIB::radDmd20TxDropMap.0 = Hex-STRING: 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F DMD20-MIB::radDmd20TxClockSource.0 = INTEGER: inter nalSct(2) DMD20-MIB::radDmd20TxClockPolarity.0 = INTEGER: aut o(3) DMD20-MIB::radDmd20TxSctClockSource.0 = INTEGER: in ternal(1) DMD20-MIB::radDmd20TxDataPolarity.0 = INTEGER: none (1) DMD20-MIB::radDmd20TxSpectrum.0 = INTEGER: normal(1 ) DMD20-MIB::radDmd20TxScramblingEnable.0 = INTEGER: enable(2) DMD20-MIB::radDmd20TxScramblingType.0 = INTEGER: dv bScrambler(11) DMD20-MIB::radDmd20TxDifferentialEncoder.0 = INTEGE R: disable(1) DMD20-MIB::radDmd20TxBpskSymbolPairingSwap.0 = INTE GER: normal(1) DMD20-MIB::radDmd20TxEscOverheadType.0 = INTEGER: d ata(2) DMD20-MIB::radDmd20TxEsc1GaindBX100.0 = INTEGER: 5 DMD20-MIB::radDmd20TxEsc2GaindBX100.0 = INTEGER: 7 DMD20-MIB::radDmd20TxTerrInterfaceType.0 = INTEGER: v35(9) DMD20-MIB::radDmd20TxAupcLocalMode.0 = INTEGER: dis abled(1) DMD20-MIB::radDmd20TxAupcRemoteMode.0 = INTEGER: di sabled(1) DMD20-MIB::radDmd20TxAupcLocalCarrierLossAction.0 = INTEGER: hold(1) DMD20-MIB::radDmd20TxAupcRemoteCarrierLossAction.0 = INTEGER: hold(1) DMD20-MIB::radDmd20TxAupcTrackingRate.0 = INTEGER: zeroPointFivedbPerMin(1) DMD20-MIB::radDmd20TxAupcRemoteBasebandLoopback.0 = INTEGER: disable(1) DMD20-MIB::radDmd20TxAupcRemoteTestPattern.0 = INTE GER: disable(1) DMD20-MIB::radDmd20TxAupcTargetEbnoDbX100.0 = INTEG ER: 400 DMD20-MIB::radDmd20TxAupcMinCarrierLeveldBmX100.0 = INTEGER: 0 DMD20-MIB::radDmd20TxAupcMaxCarrierLeveldBmX100.0 = INTEGER: 0 DMD20-MIB::radDmd20TxAupcNomCarrierLeveldBmX100.0 = INTEGER: 0 DMD20-MIB::radDmd20TxTestPattern.0 = INTEGER: norma l(1) DMD20-MIB::radDmd20TxCircuitName.0 = Hex-STRING: 00 00 00 00 00 00 00 00 00 00 00 DMD20-MIB::radDmd20TxAlarms1Mask.0 = BITS: A8 00 00 00 txFpgaFault(0) txSymbolClockLock(2) ifLBandSynthesizerLock(4) DMD20-MIB::radDmd20TxAlarms2Mask.0 = BITS: FE 00 00 00 terrClockActivity(0) internalClockActivity(1) satClockActivity(2) dataAc tivity(3) dataAISFault(4) clockFallbackFault(5) dvbFrameFault (6)

82

DMD20-MIB::radDmd20TxForcedAlarms.0 = BITS: 01 00 0 0 00 ibsServiceAlarm(7) DMD20-MIB::radDmd20TxDropStatusMask.0 = BITS: C0 00 00 00 terrFrameFault(0) terrMultiframeFault(1) DMD20-MIB::radDmd20TxTerrestrialFraming.0 = INTEGER : noFraming(1) DMD20-MIB::radDmd20TxSpectralMask.0 = INTEGER: dvbS at035(3) DMD20-MIB::radDmd20TxAlarms4Mask.0 = BITS: E0 00 00 00 bucCurrentFault(0) bucVoltageFault(1) ethernetWanMajorAlarm(2) DMD20-MIB::radDmd20TxEthFlowControl.0 = INTEGER: di sable(1) DMD20-MIB::radDmd20TxEthDaisyChain.0 = INTEGER: dis able(1) DMD20-MIB::radDmd20TxRsOfecRate.0 = INTEGER: 204188 DMD20-MIB::radDmd20TxTpcInterleaver.0 = INTEGER: di sable(1) DMD20-MIB::radDmd20TxEsEnhancedEnable.0 = INTEGER: normal(1) DMD20-MIB::radDmd20TxEsSerialControlInterface.0 = I NTEGER: rs232(1) DMD20-MIB::radDmd20TxEsBaudRate.0 = INTEGER: baud96 00(7) DMD20-MIB::radDmd20TxEsBitsPerChar.0 = INTEGER: sev en(1) DMD20-MIB::radDmd20TxCarrierDelaySec.0 = INTEGER: 0 DMD20-MIB::radDmd20TxSccCtlRatio.0 = INTEGER: ratio 1(1) DMD20-MIB::radDmd20TxSccInbandRate.0 = Wrong Type ( should be Gauge32 or Unsigned32): INTEGER: 300 DMD20-MIB::radDmd20TxSctClockPolarity.0 = INTEGER: normal(1) DMD20-MIB::radDmd20TxAlarms1.0 = BITS: 28 00 00 00 txSymbolClockLock(2) ifLBandSynthesizerLock(4) DMD20-MIB::radDmd20TxAlarms2.0 = BITS: F0 00 00 00 terrClockActivity(0) internalClockActivity(1) satClockActivity(2) dataAc tivity(3) DMD20-MIB::radDmd20TxDropStatus.0 = BITS: 00 00 00 00 DMD20-MIB::radDmd20TxBackwardAlarms.0 = BITS: 00 00 00 00 DMD20-MIB::radDmd20TxLatchedAlarms1.0 = BITS: 20 00 00 00 txSymbolClockLock(2) DMD20-MIB::radDmd20TxLatchedAlarms2.0 = BITS: 1A 00 00 00 dataActivity(3) dataAISFault(4) dvbFrameFault(6) DMD20-MIB::radDmd20TxSymbolRateHz.0 = Wrong Type (s hould be Gauge32 or Unsigned32): INTEGER: 1276675 DMD20-MIB::radDmd20TxAlarms4.0 = BITS: 00 00 00 00 DMD20-MIB::radDmd20TxLatchedAlarms4.0 = BITS: 00 00 00 00 DMD20-MIB::radDmd20RxNetworkSpec.0 = INTEGER: dvbSa t(5) DMD20-MIB::radDmd20RxCarrierFrequencyHz.0 = Wrong T ype (should be Gauge32 or Unsigned32): INTEGER: 70000000 DMD20-MIB::radDmd20RxTerrDataRateHz.0 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 2048000 DMD20-MIB::radDmd20RxStrapCode.0 = INTEGER: 0 DMD20-MIB::radDmd20RxInnerFecRate.0 = INTEGER: viterbi7x8(6) DMD20-MIB::radDmd20RxModulationType.0 = INTEGER: qpsk(1) DMD20-MIB::radDmd20RxSatFraming.0 = INTEGER: framin gDvb(5) DMD20-MIB::radDmd20RxOuterFecEnable.0 = INTEGER: en able(2) DMD20-MIB::radDmd20RxOuterFecRate.0 = INTEGER: rsCu stomNK(6) DMD20-MIB::radDmd20RxInterleaverDepth.0 = INTEGER: interleaverDepth12(3) DMD20-MIB::radDmd20RxInsertMode.0 = INTEGER: disabl e(1) DMD20-MIB::radDmd20RxInsertMap.0 = Hex-STRING: 00 0 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 DMD20-MIB::radDmd20RxBufferClockSource.0 = INTEGER: internalSct(2) DMD20-MIB::radDmd20RxBufferClockPolarity.0 = INTEGE R: normal(1) DMD20-MIB::radDmd20RxBufferSize.0 = INTEGER: 32 DMD20-MIB::radDmd20RxDataPolarity.0 = INTEGER: none (1) DMD20-MIB::radDmd20RxSpectrum.0 = INTEGER: normal(1 ) DMD20-MIB::radDmd20RxDescramblingEnable.0 = INTEGER : enable(2) DMD20-MIB::radDmd20RxDescramblingType.0 = INTEGER: dvbDescrambler(11) DMD20-MIB::radDmd20RxDifferentialDecoder.0 = INTEGE R: disable(1) DMD20-MIB::radDmd20RxBpskSymbolPairingSwap.0 = INTE GER: normal(1) DMD20-MIB::radDmd20RxT1E1FrameSource.0 = INTEGER: i nternal(1) DMD20-MIB::radDmd20RxExtClockSource.0 = INTEGER: ex ternalScte(1) DMD20-MIB::radDmd20RxCarrierSweepRange.0 = INTEGER: 255 DMD20-MIB::radDmd20RxCarrierLevelLimitdBmX100.0 = I NTEGER: 30

83

DMD20-MIB::radDmd20RxEscOverheadType.0 = INTEGER: d ata(2) DMD20-MIB::radDmd20RxEsc1GaindBX100.0 = INTEGER: 5 DMD20-MIB::radDmd20RxEsc2GaindBX100.0 = INTEGER: 5 DMD20-MIB::radDmd20RxTerrInterfaceType.0 = INTEGER: v35(9) DMD20-MIB::radDmd20RxEsEnhancedEnable.0 = INTEGER: normal(1) DMD20-MIB::radDmd20RxEsSerialControlInterface.0 = I NTEGER: rs232(1) DMD20-MIB::radDmd20RxEsBaudRate.0 = INTEGER: baud96 00(7) DMD20-MIB::radDmd20RxEsBitsPerChar.0 = INTEGER: sev en(1) DMD20-MIB::radDmd20RxTestPattern.0 = INTEGER: norma l(1) DMD20-MIB::radDmd20RxCircuitName.0 = Hex-STRING: 00 00 00 00 00 00 00 00 00 00 00 DMD20-MIB::radDmd20RxForcedAlarms.0 = BITS: 00 00 0 0 00 DMD20-MIB::radDmd20RxAlarms1Mask.0 = BITS: FF 00 00 00 rxFpgaFault(0) carrierFault(1) multiframeSyncFault(2) frameSyncFau lt(3) ibsBerFault(4) satelliteAisFault(5) dataActivity(6) agcLevelFault( 7) DMD20-MIB::radDmd20RxAlarms2Mask.0 = BITS: FE 00 00 00 bufferUnderflow(0) bufferOverflow(1) bufferNearEmpty(2) bufferNearFull (3) ofecDecoderFault(4) deinterleaverFault(5) uncorrectedWordFault(6) DMD20-MIB::radDmd20RxAlarms3Mask.0 = BITS: BE 00 00 00 lBandSynthesizerLock(0) bufferClockLock(2) viterbiD ecoderLock(3) sequentialDecoderLock(4) testPatternLock(5) externa lReferenceLock(6) DMD20-MIB::radDmd20RxAlarms4Mask.0 = BITS: FD 00 00 00 bufferClockActivity(0) externalBncActivity(1) satel liteClockActivity(2) externalIdiClockActivity(3) externalReferenceActivi ty(4) hsReferenceActivity(5) ebnoFault(7) DMD20-MIB::radDmd20RxAlarms5Mask.0 = BITS: B2 00 00 00 trellisDecoderLock(0) insertSignalingFault(2) turbo Ifec(3) dvbFrameFault(6) DMD20-MIB::radDmd20RxInsertStatusMask.0 = BITS: E0 00 00 00 terrFrameFault(0) terrMultiframeFault(1) terrCrcFau lt(2) DMD20-MIB::radDmd20RxTerrestrialFraming.0 = INTEGER : noFraming(1) DMD20-MIB::radDmd20RxTerrestrialStreaming.0 = INTEG ER: byteOutput(2) DMD20-MIB::radDmd20RxAlarms6Mask.0 = BITS: E0 00 00 00 lnbCurrentFault(0) lnbVoltageFault(1) ethernetWanMajorAlarm(2) DMD20-MIB::radDmd20RxCarrierReacqRange.0 = INTEGER: 0 DMD20-MIB::radDmd20RxRsOfecRate.0 = INTEGER: 204188 DMD20-MIB::radDmd20RxTpcInterleaver.0 = INTEGER: di sable(1) DMD20-MIB::radDmd20RxCarrierSweepDelay.0 = INTEGER: .5 DMD20-MIB::radDmd20RxEbnoAlarmThreshold.0 = INTEGER : .00 DMD20-MIB::radDmd20RxBufferReset.0 = Wrong Type (sh ould be Gauge32 or Unsigned32): INTEGER: 0 DMD20-MIB::radDmd20RxRestartTestPattern.0 = Wrong T ype (should be Gauge32 or Unsigned32): INTEGER: 0 DMD20-MIB::radDmd20RxSccCtlRatio.0 = INTEGER: ratio 1(1) DMD20-MIB::radDmd20RxSccInbandRate.0 = Wrong Type ( should be Gauge32 or Unsigned32): INTEGER: 300 DMD20-MIB::radDmd20RxFastAcquisition.0 = INTEGER: d isable(1) DMD20-MIB::radDmd20RxSpectralMask.0 = INTEGER: dvbS at035(3) DMD20-MIB::radDmd20RxAlarms1.0 = BITS: 02 00 00 00 dataActivity(6) DMD20-MIB::radDmd20RxAlarms2.0 = BITS: 00 00 00 00 DMD20-MIB::radDmd20RxAlarms3.0 = BITS: BE 00 00 00 lBandSynthesizerLock(0) bufferClockLock(2) viterbiDecoderLock(3) sequential DecoderLock(4) testPatternLock(5) externalReferenceLock(6) DMD20-MIB::radDmd20RxAlarms4.0 = BITS: F8 00 00 00 bufferClockActivity(0) externalBncActivity(1) satelliteClockActivity(2) externalIdiClockActivity(3) externalReferenceActivi ty(4) DMD20-MIB::radDmd20RxAlarms5.0 = BITS: 80 00 00 00 trellisDecoderLock(0) DMD20-MIB::radDmd20RxInsertStatus.0 = BITS: 00 00 0 0 00 DMD20-MIB::radDmd20RxBackwardAlarms.0 = BITS: 00 00 00 00 DMD20-MIB::radDmd20RxLatchedAlarms1.0 = BITS: 46 00 00 00 carrierFault(1) satelliteAisFault(5) dataActivity(6) DMD20-MIB::radDmd20RxLatchedAlarms2.0 = BITS: AE 00 00 00 bufferUnderflow(0) bufferNearEmpty(2) ofecDecoderFa ult(4) deinterleaverFault(5) uncorrectedWordFault(6)

84

DMD20-MIB::radDmd20RxLatchedAlarms3.0 = BITS: 10 00 00 00 viterbiDecoderLock(3) DMD20-MIB::radDmd20RxLatchedAlarms4.0 = BITS: 01 00 00 00 ebnoFault(7) DMD20-MIB::radDmd20RxLatchedAlarms5.0 = BITS: 02 00 00 00 dvbFrameFault(6) DMD20-MIB::radDmd20RxBerEbnoStatus.0 = INTEGER: 7 DMD20-MIB::radDmd20RxEbno.0 = INTEGER: 5.47 DMD20-MIB::radDmd20RxBufferLevel.0 = INTEGER: 50 DMD20-MIB::radDmd20RxCarrierLeveldBmX100.0 = INTEGER: -20 DMD20-MIB::radDmd20RxBitErrorCount.0 = Counter32: 2978170 DMD20-MIB::radDmd20RxTestPatternErrorCount.0 = Coun ter32: 0 DMD20-MIB::radDmd20RxLossOfTerrInputSignal.0 = INTE GER: normal(1) DMD20-MIB::radDmd20RxSymbolRateHz.0 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 1276675 DMD20-MIB::radDmd20RxAlarms6.0 = BITS: 00 00 00 00 DMD20-MIB::radDmd20RxLatchedAlarms6.0 = BITS: 00 00 00 00 DMD20-MIB::radDmd20RxEthPktErrorCount.0 = Counter32 : 0 DMD20-MIB::radDmd20RxEthPktTotalCount.0 = Counter32 : 0 DMD20-MIB::radDmd20RxEthJs1PortStatus.0 = INTEGER: down(1) DMD20-MIB::radDmd20RxEthJs2PortStatus.0 = INTEGER: down(1) DMD20-MIB::radDmd20RxEthJs3PortStatus.0 = INTEGER: down(1) DMD20-MIB::radDmd20RxEthJs4PortStatus.0 = INTEGER: down(1) DMD20-MIB::radDmd20RxEthWanStatus.0 = INTEGER: down (1) DMD20-MIB::radDmd20RxRawBerStatus.0 = STRING: 9.08E-03 DMD20-MIB::radDmd20RxCorrectedBerStatus.0 = STRING: 3.11E-04 DMD20-MIB::radDmd20RxTestPatternBerStatus.0 = STRIN G: 0.00E-00 DMD20-MIB::radDmd20RxAupcRemoteBerStatus.0 = STRING : 0.00E-00 DMD20-MIB::radDmd20RxCarrierFrequencyOffset.0 = INT EGER: 0 DMD20-MIB::radDmd20CommonExternalExcClock.0 = INTEG ER: 10000000 DMD20-MIB::radDmd20CommonExternalReference.0 = INTE GER: 10000000 DMD20-MIB::radDmd20CommonFrequencyReferenceSource.0 = INTEGER: internal(1) DMD20-MIB::radDmd20CommonAlarms1Mask.0 = BITS: E0 0 0 00 00 minus12VoltAlarm(0) plus12VoltAlarm(1) plus5VoltAla rm(2) DMD20-MIB::radDmd20CommonAlarms2Mask.0 = BITS: 00 0 0 00 00 DMD20-MIB::radDmd20CommonCarrierType.0 = INTEGER: n ormal(1) DMD20-MIB::radDmd20CommonLoopback.0 = INTEGER: none (1) DMD20-MIB::radDmd20CommonSerialRemoteControl.0 = IN TEGER: terminal(2) DMD20-MIB::radDmd20CommonTerminalBaudRate.0 = INTEG ER: baud9600(7) DMD20-MIB::radDmd20CommonTerminalEmulation.0 = INTE GER: vt100(2) DMD20-MIB::radDmd20CommonRemoteAddress.0 = INTEGER: 32 DMD20-MIB::radDmd20CommonRemoteBaudRate.0 = INTEGER : baud9600(7) DMD20-MIB::radDmd20CommonRemoteInterface.0 = INTEGE R: rs232(1) DMD20-MIB::radDmd20CommonEventClear.0 = Wrong Type (should be Gauge32 or Unsigned32): INTEGER: 0 DMD20-MIB::radDmd20CommonLatchedAlarmsClear.0 = Wro ng Type (should be Gauge32 or Unsigned32): INTEGER: 0 DMD20-MIB::radDmd20CommonAlarms1.0 = BITS: 00 00 00 00 DMD20-MIB::radDmd20CommonAlarms2.0 = BITS: 00 00 00 00 DMD20-MIB::radDmd20CommonLatchedAlarms1.0 = BITS: 0 0 00 00 00 DMD20-MIB::radDmd20CommonLatchedAlarms2.0 = BITS: 0 0 00 00 00 DMD20-MIB::radDmd20CommonPos5VDcX10.0 = INTEGER: 4. 9 DMD20-MIB::radDmd20CommonPos12VDcX10.0 = INTEGER: 1 2.2 DMD20-MIB::radDmd20CommonNeg12VDcX10.0 = INTEGER: - 12.6 DMD20-MIB::radDmd20CommonFirmwareName.0 = STRING: F 05058-AN 5.0 DMD20-MIB::radDmd20TxMajorAlarmTrap.0 = OID: ccitt DMD20-MIB::radDmd20TxMinorAlarmTrap.0 = OID: ccitt DMD20-MIB::radDmd20RxMajorAlarmTrap.0 = OID: ccitt DMD20-MIB::radDmd20RxMinorAlarmTrap.0 = OID: ccitt DMD20-MIB::radDmd20CommonAlarmTrap.0 = OID: ccitt DMD20-MIB::radDmd20LbstTxUplinkFrequencyHz.0 = Coun ter64: 2050000000 DMD20-MIB::radDmd20LbstTxLoFrequencyHz.0 = Counter6 4: 97949999999 DMD20-MIB::radDmd20LbstTxSideBand.0 = INTEGER: lowS ide(2) DMD20-MIB::radDmd20LbstTx10MhzReferenceEnable.0 = I NTEGER: disable(1) DMD20-MIB::radDmd20LbstTxVoltageEnable.0 = INTEGER: disable(1)

85

DMD20-MIB::radDmd20LbstTxBucVoltageX10.0 = INTEGER: .0 DMD20-MIB::radDmd20LbstTxBucCurrentX1000.0 = INTEGE R: .000 DMD20-MIB::radDmd20LbstRxDownlinkFrequencyHz.0 = Co unter64: 2050000000 DMD20-MIB::radDmd20LbstRxLoFrequencyHz.0 = Counter6 4: 97949999999 DMD20-MIB::radDmd20LbstRxSideBand.0 = INTEGER: lowS ide(2) DMD20-MIB::radDmd20LbstRx10MhzReferenceEnable.0 = I NTEGER: disable(1) DMD20-MIB::radDmd20LbstRxVoltageEnable.0 = INTEGER: disable(1) DMD20-MIB::radDmd20LbstRxVoltageSelect.0 = INTEGER: 2675244 DMD20-MIB::radDmd20LbstRxLnbVoltageX10.0 = INTEGER: .0 DMD20-MIB::radDmd20LbstRxLnbCurrentX1000.0 = INTEGE R: .000

86

Appendix A.3: RFC Default MIB Example of the content of the default RFC MIBs. %snmpwalk -c public -v 2c –M mibs 192.168.0.2

SNMPv2-MIB::sysDescr.0 = STRING: DMD20 Universal Sa tellite Modem SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterp rises.2591 DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1 44083) 0:24:00.83 SNMPv2-MIB::sysContact.0 = STRING: RadyneComstream Support (602) 437-9620 SNMPv2-MIB::sysName.0 = STRING: DMD20 SNMPv2-MIB::sysLocation.0 = STRING: 3138 E. Elwood Phoenix, AZ 85034 SNMPv2-MIB::sysServices.0 = INTEGER: 79 IF-MIB::ifNumber.0 = INTEGER: 1 IF-MIB::ifIndex.1 = INTEGER: 1 IF-MIB::ifDescr.1 = STRING: IF-MIB::ifType.1 = INTEGER: ethernetCsmacd(6) IF-MIB::ifMtu.1 = INTEGER: 1500 IF-MIB::ifSpeed.1 = Gauge32: 10000000 IF-MIB::ifPhysAddress.1 = STRING: 0:10:65:41:15:fc IF-MIB::ifAdminStatus.1 = INTEGER: 0 IF-MIB::ifOperStatus.1 = INTEGER: up(1) IF-MIB::ifLastChange.1 = Timeticks: (0) 0:00:00.00 IF-MIB::ifInOctets.1 = Counter32: 112220 IF-MIB::ifInUcastPkts.1 = Counter32: 1194 IF-MIB::ifInNUcastPkts.1 = Counter32: 83 IF-MIB::ifInDiscards.1 = Counter32: 0 IF-MIB::ifInErrors.1 = Counter32: 0 IF-MIB::ifInUnknownProtos.1 = Counter32: 0 IF-MIB::ifOutOctets.1 = Counter32: 105773 IF-MIB::ifOutUcastPkts.1 = Counter32: 0 IF-MIB::ifOutNUcastPkts.1 = Counter32: 1197 IF-MIB::ifOutDiscards.1 = Counter32: 0 IF-MIB::ifOutErrors.1 = Counter32: 0 IF-MIB::ifOutQLen.1 = Gauge32: 0 IF-MIB::ifSpecific.1 = OID: SNMPv2-SMI::zeroDotZero .0 RFC1213-MIB::atIfIndex.1.192.168.0.2 = INTEGER: 1 RFC1213-MIB::atIfIndex.1.192.168.0.3 = INTEGER: 1 RFC1213-MIB::atPhysAddress.1.192.168.0.2 = Hex-STRI NG: 00 10 65 41 15 FC RFC1213-MIB::atPhysAddress.1.192.168.0.3 = Hex-STRI NG: 00 1F 29 8A E8 94 RFC1213-MIB::atNetAddress.1.192.168.0.2 = Network A ddress: C0:A8:00:02 RFC1213-MIB::atNetAddress.1.192.168.0.3 = Network A ddress: C0:A8:00:03 IP-MIB::ipForwarding.0 = INTEGER: notForwarding(2) IP-MIB::ipDefaultTTL.0 = INTEGER: 64 IP-MIB::ipInReceives.0 = Counter32: 1275 IP-MIB::ipInHdrErrors.0 = Counter32: 38 IP-MIB::ipInAddrErrors.0 = Counter32: 31 IP-MIB::ipForwDatagrams.0 = Counter32: 0 IP-MIB::ipInUnknownProtos.0 = Counter32: 0 IP-MIB::ipInDiscards.0 = Counter32: 0 IP-MIB::ipInDelivers.0 = Counter32: 1243 IP-MIB::ipOutRequests.0 = Counter32: 1214 IP-MIB::ipOutDiscards.0 = Counter32: 0 IP-MIB::ipOutNoRoutes.0 = Counter32: 0 IP-MIB::ipReasmTimeout.0 = INTEGER: 64 seconds IP-MIB::ipReasmReqds.0 = Counter32: 0 IP-MIB::ipReasmOKs.0 = Counter32: 0

87

IP-MIB::ipReasmFails.0 = Counter32: 0 IP-MIB::ipFragOKs.0 = Counter32: 0 IP-MIB::ipFragFails.0 = Counter32: 0 IP-MIB::ipFragCreates.0 = Counter32: 0 IP-MIB::ipAdEntAddr.192.168.0.2 = IpAddress: 192.16 8.0.2 IP-MIB::ipAdEntIfIndex.192.168.0.2 = INTEGER: 1 IP-MIB::ipAdEntNetMask.192.168.0.2 = IpAddress: 255 .255.255.0 IP-MIB::ipAdEntBcastAddr.192.168.0.2 = INTEGER: 1 IP-MIB::ipAdEntReasmMaxSize.192.168.0.2 = INTEGER: 1500 RFC1213-MIB::ipRouteDest.169.254.146.127 = IpAddres s: 169.254.146.127 RFC1213-MIB::ipRouteDest.192.168.0.1 = IpAddress: 1 92.168.0.1 RFC1213-MIB::ipRouteDest.192.168.0.3 = IpAddress: 1 92.168.0.3 RFC1213-MIB::ipRouteIfIndex.169.254.146.127 = INTEG ER: 1 RFC1213-MIB::ipRouteIfIndex.192.168.0.1 = INTEGER: 1 RFC1213-MIB::ipRouteIfIndex.192.168.0.3 = INTEGER: 1 RFC1213-MIB::ipRouteMetric1.169.254.146.127 = INTEG ER: 2 RFC1213-MIB::ipRouteMetric1.192.168.0.1 = INTEGER: 1 RFC1213-MIB::ipRouteMetric1.192.168.0.3 = INTEGER: 1 RFC1213-MIB::ipRouteMetric2.169.254.146.127 = INTEG ER: -1 RFC1213-MIB::ipRouteMetric2.192.168.0.1 = INTEGER: -1 RFC1213-MIB::ipRouteMetric2.192.168.0.3 = INTEGER: -1 RFC1213-MIB::ipRouteMetric3.169.254.146.127 = INTEG ER: -1 RFC1213-MIB::ipRouteMetric3.192.168.0.1 = INTEGER: -1 RFC1213-MIB::ipRouteMetric3.192.168.0.3 = INTEGER: -1 RFC1213-MIB::ipRouteMetric4.169.254.146.127 = INTEG ER: -1 RFC1213-MIB::ipRouteMetric4.192.168.0.1 = INTEGER: -1 RFC1213-MIB::ipRouteMetric4.192.168.0.3 = INTEGER: -1 RFC1213-MIB::ipRouteNextHop.169.254.146.127 = IpAdd ress: 169.254.146.127 RFC1213-MIB::ipRouteNextHop.192.168.0.1 = IpAddress : 192.168.0.1 RFC1213-MIB::ipRouteNextHop.192.168.0.3 = IpAddress : 192.168.0.3 RFC1213-MIB::ipRouteType.169.254.146.127 = INTEGER: direct(3) RFC1213-MIB::ipRouteType.192.168.0.1 = INTEGER: dir ect(3) RFC1213-MIB::ipRouteType.192.168.0.3 = INTEGER: dir ect(3) RFC1213-MIB::ipRouteProto.169.254.146.127 = INTEGER : local(2) RFC1213-MIB::ipRouteProto.192.168.0.1 = INTEGER: lo cal(2) RFC1213-MIB::ipRouteProto.192.168.0.3 = INTEGER: lo cal(2) RFC1213-MIB::ipRouteAge.169.254.146.127 = INTEGER: 0 RFC1213-MIB::ipRouteAge.192.168.0.1 = INTEGER: 0 RFC1213-MIB::ipRouteAge.192.168.0.3 = INTEGER: 0 RFC1213-MIB::ipRouteMask.169.254.146.127 = IpAddres s: 0.0.0.0 RFC1213-MIB::ipRouteMask.192.168.0.1 = IpAddress: 2 55.255.255.0 RFC1213-MIB::ipRouteMask.192.168.0.3 = IpAddress: 2 55.255.255.0 RFC1213-MIB::ipRouteMetric5.169.254.146.127 = INTEG ER: -1 RFC1213-MIB::ipRouteMetric5.192.168.0.1 = INTEGER: -1 RFC1213-MIB::ipRouteMetric5.192.168.0.3 = INTEGER: -1 RFC1213-MIB::ipRouteInfo.169.254.146.127 = OID: SNM Pv2-SMI::zeroDotZero.0 RFC1213-MIB::ipRouteInfo.192.168.0.1 = OID: SNMPv2- SMI::zeroDotZero.0 RFC1213-MIB::ipRouteInfo.192.168.0.3 = OID: SNMPv2- SMI::zeroDotZero.0 IP-MIB::ipNetToMediaIfIndex.1.192.168.0.2 = INTEGER : 1 IP-MIB::ipNetToMediaIfIndex.1.192.168.0.3 = INTEGER : 1 IP-MIB::ipNetToMediaPhysAddress.1.192.168.0.2 = STR ING: 0:10:65:41:15:fc IP-MIB::ipNetToMediaPhysAddress.1.192.168.0.3 = STR ING: 0:1f:29:8a:e8:94 IP-MIB::ipNetToMediaNetAddress.1.192.168.0.2 = IpAd dress: 192.168.0.2 IP-MIB::ipNetToMediaNetAddress.1.192.168.0.3 = IpAd dress: 192.168.0.3 IP-MIB::ipNetToMediaType.1.192.168.0.2 = INTEGER: s tatic(4) IP-MIB::ipNetToMediaType.1.192.168.0.3 = INTEGER: s tatic(4) IP-MIB::ipRoutingDiscards.0 = Counter32: 0 IP-MIB::icmpInMsgs.0 = Counter32: 2 IP-MIB::icmpInErrors.0 = Counter32: 0 IP-MIB::icmpInDestUnreachs.0 = Counter32: 0 IP-MIB::icmpInTimeExcds.0 = Counter32: 0 IP-MIB::icmpInParmProbs.0 = Counter32: 0 IP-MIB::icmpInSrcQuenchs.0 = Counter32: 0

88

IP-MIB::icmpInRedirects.0 = Counter32: 0 IP-MIB::icmpInEchos.0 = Counter32: 2 IP-MIB::icmpInEchoReps.0 = Counter32: 0 IP-MIB::icmpInTimestamps.0 = Counter32: 0 IP-MIB::icmpInTimestampReps.0 = Counter32: 0 IP-MIB::icmpInAddrMasks.0 = Counter32: 0 IP-MIB::icmpInAddrMaskReps.0 = Counter32: 0 IP-MIB::icmpOutMsgs.0 = Counter32: 2 IP-MIB::icmpOutErrors.0 = Counter32: 0 IP-MIB::icmpOutDestUnreachs.0 = Counter32: 0 IP-MIB::icmpOutTimeExcds.0 = Counter32: 0 IP-MIB::icmpOutParmProbs.0 = Counter32: 0 IP-MIB::icmpOutSrcQuenchs.0 = Counter32: 0 IP-MIB::icmpOutRedirects.0 = Counter32: 0 IP-MIB::icmpOutEchos.0 = Counter32: 0 IP-MIB::icmpOutEchoReps.0 = Counter32: 2 IP-MIB::icmpOutTimestamps.0 = Counter32: 0 IP-MIB::icmpOutTimestampReps.0 = Counter32: 0 IP-MIB::icmpOutAddrMasks.0 = Counter32: 0 IP-MIB::icmpOutAddrMaskReps.0 = Counter32: 0 UDP-MIB::udpInDatagrams.0 = Counter32: 1302 UDP-MIB::udpNoPorts.0 = Counter32: 29 UDP-MIB::udpInErrors.0 = Counter32: 0 UDP-MIB::udpOutDatagrams.0 = Counter32: 1304 UDP-MIB::udpLocalAddress.192.168.0.2.161 = IpAddres s: 192.168.0.2 UDP-MIB::udpLocalPort.192.168.0.2.161 = INTEGER: 16 1 SNMPv2-MIB::snmpInPkts.0 = Counter32: 1308 SNMPv2-MIB::snmpOutPkts.0 = Counter32: 1308 SNMPv2-MIB::snmpInBadVersions.0 = Counter32: 0 SNMPv2-MIB::snmpInBadCommunityNames.0 = Counter32: 0 SNMPv2-MIB::snmpInBadCommunityUses.0 = Counter32: 0 SNMPv2-MIB::snmpInASNParseErrs.0 = Counter32: 0 SNMPv2-MIB::snmpInTooBigs.0 = Counter32: 0 SNMPv2-MIB::snmpInNoSuchNames.0 = Counter32: 0 SNMPv2-MIB::snmpInBadValues.0 = Counter32: 0 SNMPv2-MIB::snmpInReadOnlys.0 = Counter32: 0 SNMPv2-MIB::snmpInGenErrs.0 = Counter32: 0 SNMPv2-MIB::snmpInTotalReqVars.0 = Counter32: 1316 SNMPv2-MIB::snmpInTotalSetVars.0 = Counter32: 0 SNMPv2-MIB::snmpInGetRequests.0 = Counter32: 3 SNMPv2-MIB::snmpInGetNexts.0 = Counter32: 1314 SNMPv2-MIB::snmpInSetRequests.0 = Counter32: 0 SNMPv2-MIB::snmpInGetResponses.0 = Counter32: 0 SNMPv2-MIB::snmpInTraps.0 = Counter32: 0 SNMPv2-MIB::snmpOutTooBigs.0 = Counter32: 0 SNMPv2-MIB::snmpOutNoSuchNames.0 = Counter32: 0 SNMPv2-MIB::snmpOutBadValues.0 = Counter32: 0 SNMPv2-MIB::snmpOutGenErrs.0 = Counter32: 0 SNMPv2-MIB::snmpOutGetRequests.0 = Counter32: 0 SNMPv2-MIB::snmpOutGetNexts.0 = Counter32: 0 SNMPv2-MIB::snmpOutSetRequests.0 = Counter32: 0 SNMPv2-MIB::snmpOutGetResponses.0 = Counter32: 1332 SNMPv2-MIB::snmpOutTraps.0 = Counter32: 0 SNMPv2-MIB::snmpEnableAuthenTraps.0 = INTEGER: disa bled(2)

89

Appendix B: Modem Characteristics

Appendix B.1: RADYNE DMD20 Modem Reference Characteristics

Fig. B.1: Reference Characteristics, printed from [RAD-a]

Appendix B.2: Listings of Measured Values Tab. B.1: Measured Values for BPSK (DVB framing) Tab. B.2: Measured Values for QPSK (DVB framing) Tab. B.3: Measured Values for 8PSK (DVB framing) Tab. B.4: Measured Values for 16QAM (DVB framing) Tab. B.5: Measured Values for IBS framing (pure convolution coding) Tab. B.6: Measured Values for IBS framing (concatenated coding) Tab. B.7: Measured BER values vs. estimated and measured/calculated Eb/N0 for different CM pairs (DVB framing) Tab. B.8: Estimated and measured/calculated Eb/N0 values for fixed TX power (-4.5 dBm) Tab. B.9: C/N values related to a fixed Eb/N0 value (12.2 dB)

90

TX

power

RX

power

Eb/No

_1 countBER1 rawBER1 corrBER1

idle

time

Eb/No

status

Eb/No

_2 countBER2 rawBER2 corrBER2

measured

BER

-10,8 -19 3,93 4,04E+06 8,65E-02 2,35E-04 62 11 3,93 0,00E+00 1,10E-01 3,66E-04 1,00E+00

-10,6 -18 3,93 7,33E+06 1,45E-01 4,98E-04 63 11 3,93 4,37E+07 1,55E-01 3,49E-04 9,00E-04

-10,5 -18 3,93 6,05E+07 1,69E-01 2,56E-04 63 11 3,93 3,67E+08 1,68E-01 2,57E-04 4,44E-05

-10,4 -18 3,93 4,91E+08 1,63E-01 2,96E-04 63 11 3,93 3,42E+08 1,64E-01 2,91E-04 7,70E-06

-10,3 -18 3,93 4,04E+08 1,58E-01 3,26E-04 61 11 3,93 7,94E+08 1,58E-01 3,30E-04 4,39E-07

-10,1 -18 3,93 9,37E+08 1,47E-01 4,06E-04 64 11 3,93 1,31E+09 1,47E-01 4,04E-04 0,00E+00

DVB BPSK

VITERBI_1/2

-9,5 -18 4,26 6,09E+07 1,18E-01 5,81E-04 62 7 4,21 3,53E+08 1,18E-01 5,81E-04 0,00E+00

-10,4 -18 3,11 5,63E+08 8,13E-02 0,00E+00 61 7 3,24 7,64E+08 8,14E-02 0,00E+00 1,00E+00

-10,3 -18 3,32 8,06E+08 7,78E-02 0,00E+00 63 7 3,43 1,00E+09 7,76E-02 0,00E+00 7,45E-04

-10,1 -18 3,63 1,03E+09 7,10E-02 0,00E+00 63 7 3,64 1,21E+09 7,08E-02 0,00E+00 2,49E-05

-10 -18 3,7 1,24E+09 6,75E-02 0,00E+00 63 7 3,68 1,41E+09 6,79E-02 0,00E+00 2,68E-06

-9,9 -18 3,8 1,65E+09 6,49E-02 0,00E+00 62 7 3,74 1,81E+09 6,49E-02 0,00E+00 4,89E-07

DVB BPSK

VITERBI_2/3

-9,8 -18 3,82 1,84E+09 6,22E-02 0,00E+00 62 7 3,85 2,00E+09 6,14E-02 0,00E+00 0,00E+00

-10,1 -18 3,68 1,43E+09 5,04E-02 9,74E-04 61 7 3,66 1,56E+09 5,07E-02 1,09E-03 1,00E+00

-10 -18 3,79 3,16E+08 4,76E-02 7,12E-04 63 7 3,79 4,34E+08 4,74E-02 7,07E-04 1,86E-03

-9,9 -18 4 4,52E+08 4,52E-02 6,33E-04 62 7 3,9 5,65E+08 4,51E-02 6,26E-04 4,74E-04

-9,8 -18 3,97 5,81E+08 4,29E-02 5,52E-04 62 7 3,94 6,88E+08 4,36E-02 5,74E-04 1,10E-04

-9,6 -18 4,25 7,41E+08 3,95E-02 4,33E-04 62 7 4,25 8,39E+08 3,90E-02 4,15E-04 2,86E-06

-9,5 -18 4,42 1,08E+09 3,61E-02 3,15E-04 63 7 4,4 1,17E+09 3,62E-02 3,19E-04 3,58E-07

DVB BPSK

VITERBI_3/4

-9,3 -17 4,59 1,18E+09 3,20E-02 1,73E-04 64 7 4,58 1,27E+09 3,24E-02 1,86E-04 0,00E+00

-9,6 -18 4,3 2,83E+08 2,67E-02 0,00E+00 62 7 4,28 3,49E+08 2,70E-02 0,00E+00 5,39E-03

-9,5 -18 4,35 4,43E+08 2,51E-02 0,00E+00 62 7 4,37 5,05E+08 2,50E-02 0,00E+00 2,28E-03

-9,4 -17 4,5 5,17E+08 2,33E-02 0,00E+00 64 7 4,5 5,76E+08 2,33E-02 0,00E+00 6,46E-04

-9,2 -17 4,79 5,87E+08 2,05E-02 0,00E+00 63 7 4,61 6,38E+08 2,05E-02 0,00E+00 2,07E-05

-9,1 -17 4,78 6,44E+08 1,94E-02 0,00E+00 62 7 4,79 6,92E+08 1,93E-02 0,00E+00 3,31E-06

DVB BPSK

VITERBI_5/6

-9 -17 5,05 6,99E+08 1,71E-02 0,00E+00 63 7 4,99 7,43E+08 1,73E-02 0,00E+00 0,00E+00

91

-9 -17 4,87 4,04E+06 1,23E-02 7,34E-04 63 7 4,78 6,33E+06 1,59E-02 3,56E-03 1,80E-03

-8,9 -17 4,97 6,64E+06 1,59E-02 3,45E-03 62 7 4,95 8,74E+06 1,43E-02 2,33E-03 5,05E-04

-8,7 -17 5,24 2,82E+05 5,45E-03 9,87E-05 62 7 5,2 2,08E+06 6,33E-03 4,54E-05 1,21E-05

-8,6 -17 5,29 2,33E+06 7,10E-03 8,32E-05 61 7 5,29 3,99E+06 1,21E-02 7,70E-04 1,72E-06

-8,5 -16 5,43 4,21E+06 1,19E-02 8,44E-04 63 7 5,38 5,73E+06 1,11E-02 8,07E-04 2,28E-07

DVB BPSK

VITERBI_7/8

-8,4 -16 5,49 7,05E+06 1,07E-02 7,37E-04 63 7 5,59 8,45E+06 1,02E-02 6,66E-04 0,00E+00

Tab. B.1: Measured Values for BPSK (DVB framing)

TX

power

RX

power

Eb/No

_1 countBER1 rawBER1 corrBER1

idle

time

Eb/No

status

Eb/No

_2 countBER2 rawBER2 corrBER2

measured

BER

-10,5 -22 3,02 7,03E+08 1,87E-01 1,80E-04 63 7 3 1,18E+09 1,87E-01 1,80E-04 1,00E+00

-10,4 -22 3 1,31E+09 1,82E-01 1,80E-04 61 7 3,14 1,77E+09 1,82E-01 1,80E-04 7,75E-03

-10,3 -22 3,19 1,89E+09 1,76E-01 2,03E-04 64 7 3,19 2,33E+09 1,76E-01 2,05E-04 3,09E-03

-10,1 -22 3,32 2,52E+09 1,66E-01 2,76E-04 61 7 3,33 2,94E+09 1,65E-01 2,78E-04 2,30E-04

-10 -22 3,45 3,02E+09 1,60E-01 3,14E-04 62 7 3,4 3,42E+09 1,60E-01 3,13E-04 4,35E-05

-9,9 -22 3,48 4,19E+09 1,56E-01 3,47E-04 62 7 3,44 2,81E+08 1,56E-01 3,46E-04 9,43E-06

-9,7 -22 3,62 3,92E+08 1,46E-01 4,14E-04 62 7 3,67 7,64E+08 1,46E-01 4,15E-04 5,21E-07

DVB QPSK

VITERBI_1/2

-9,6 -21 3,71 8,34E+08 1,41E-01 4,50E-04 63 7 3,78 1,19E+09 1,41E-01 4,49E-04 0,00E+00

-10 -22 3,32 6,74E+08 8,23E-02 0,00E+00 63 7 3,3 8,77E+08 8,27E-02 0,00E+00 1,00E+00

-9,9 -22 3,47 9,10E+08 7,88E-02 0,00E+00 61 7 3,56 1,11E+09 7,91E-02 0,00E+00 5,34E-03

-9,8 -22 3,54 1,16E+09 7,59E-02 0,00E+00 62 7 3,61 1,35E+09 7,53E-02 0,00E+00 1,72E-03

-9,6 -22 3,87 1,38E+09 6,95E-02 0,00E+00 63 7 3,75 1,56E+09 6,94E-02 0,00E+00 7,89E-05

-9,5 -21 3,87 1,82E+09 6,61E-02 0,00E+00 62 7 3,91 1,98E+09 6,64E-02 0,00E+00 1,00E-05

DVB QPSK

VITERBI_2/3

-9,3 -21 4,15 2,09E+09 6,06E-02 0,00E+00 63 7 4,06 2,24E+09 6,04E-02 0,00E+00 2,52E-07

-9,8 -22 3,83 9,64E+07 4,97E-02 7,82E-04 62 7 3,81 1,14E+08 4,98E-02 7,91E-04 1,00E+00

-9,7 -22 3,95 1,39E+08 4,73E-02 7,00E-04 63 7 3,9 2,57E+08 4,72E-02 7,01E-04 5,03E-03

-9,6 -21 3,93 2,76E+08 4,50E-02 6,21E-04 62 7 3,92 3,88E+08 4,54E-02 6,35E-04 1,70E-03

-9,5 -21 4,09 4,11E+08 4,31E-02 5,56E-04 61 7 4,13 5,17E+08 4,32E-02 5,60E-04 4,67E-04

-9,4 -21 4,21 5,36E+08 4,10E-02 4,82E-04 62 7 4,23 6,39E+08 4,10E-02 4,85E-04 9,76E-05

-9,3 -21 4,27 6,53E+08 3,91E-02 4,19E-04 62 7 4,26 7,51E+08 3,90E-02 4,14E-04 1,86E-05

DVB QPSK

VITERBI_3/4

-9,1 -21 4,55 7,77E+08 3,51E-02 2,78E-04 63 7 4,5 8,64E+08 3,52E-02 2,84E-04 2,20E-07

92

-9 -21 4,58 8,78E+08 3,23E-02 1,84E-04 62 7 4,61 9,59E+08 3,25E-02 1,91E-04 0,00E+00

-9,3 -21 4,36 1,83E+07 2,69E-02 0,00E+00 62 7 4,3 8,58E+07 2,72E-02 0,00E+00 1,00E+00

-9,2 -21 4,42 1,01E+08 2,53E-02 0,00E+00 62 7 4,48 1,64E+08 2,57E-02 0,00E+00 6,61E-03

-9,1 -21 4,54 1,87E+08 2,42E-02 0,00E+00 62 7 4,54 2,47E+08 2,45E-02 0,00E+00 2,56E-03

-9 -21 4,75 2,55E+08 2,24E-02 0,00E+00 62 7 4,7 3,09E+08 2,24E-02 0,00E+00 3,98E-04

-8,9 -21 4,88 3,19E+08 2,07E-02 0,00E+00 62 7 4,88 3,70E+08 2,08E-02 0,00E+00 9,15E-05

-8,8 -20 4,89 3,79E+08 1,93E-02 0,00E+00 62 7 4,9 4,28E+08 1,95E-02 0,00E+00 1,39E-05

-8,6 -20 5,11 4,41E+08 1,72E-02 0,00E+00 63 7 5,13 4,84E+08 1,71E-02 0,00E+00 7,32E-07

DVB QPSK

VITERBI_5/6

-8,5 -20 5,21 5,56E+08 1,59E-02 0,00E+00 63 7 5,19 5,96E+08 1,61E-02 0,00E+00 0,00E+00

-8,8 -20 4,75 1,14E+06 1,52E-02 2,28E-03 63 7 4,81 1,68E+06 1,46E-02 1,64E-03 1,00E+00

-8,6 -20 4,96 2,76E+08 1,60E-02 3,24E-03 62 7 5,02 3,16E+08 1,59E-02 3,10E-03 3,60E-03

-8,5 -20 5,1 1,85E+08 1,47E-02 1,93E-03 62 7 5,14 2,22E+08 1,48E-02 1,98E-03 9,77E-04

-8,4 -20 5,27 1,44E+08 1,36E-02 1,14E-03 62 7 5,21 1,78E+08 1,34E-02 1,14E-03 2,69E-04

-8,3 -20 5,32 1,06E+08 1,24E-02 9,77E-04 61 7 5,29 1,37E+08 1,24E-02 9,83E-04 5,21E-05

-8,1 -20 5,49 7,38E+07 1,06E-02 7,04E-04 64 7 5,48 1,01E+08 1,09E-02 7,53E-04 2,11E-06

DVB QPSK

VITERBI_7/8

-8 -20 5,61 4,33E+07 9,87E-03 5,91E-04 62 7 5,61 6,77E+07 9,95E-03 6,09E-04 0,00E+00

Tab. B.2: Measured Values for QPSK (DVB framing)

TX

power

RX

power

Eb/No

_1 countBER1 rawBER1 corrBER1

idle

time

Eb/No

status

Eb/No

_2 countBER2 rawBER2 corrBER2

measured

BER

-6 -15 7,31 9,31E+07 2,84E-01 1,22E-03 62 7 7,18 1,34E+08 4,09E-01 1,22E-03 0,00E+00

-6,5 -15 6,66 1,75E+08 5,02E-01 1,22E-03 63 7 6,68 2,06E+08 5,01E-01 1,22E-03 0,00E+00

-7 -16 6,1 2,27E+08 5,01E-01 1,22E-03 62 7 6,07 2,68E+08 5,01E-01 1,22E-03 0,00E+00

-7,5 -16 5,56 3,09E+08 5,02E-01 1,22E-03 61 7 5,56 3,40E+08 5,02E-01 1,22E-03 0,00E+00

-8 -17 4,91 3,92E+08 5,03E-01 1,22E-03 62 2 0 0,00E+00 0,00E+00 0,00E+00 1,00E+00

-7,5 -17 0 0,00E+00 0,00E+00 0,00E+00 62 2 0 0,00E+00 0,00E+00 0,00E+00 1,00E+00

-7 -16 0 0,00E+00 0,00E+00 0,00E+00 61 2 0 0,00E+00 0,00E+00 0,00E+00 1,00E+00

-6,5 -15 0 0,00E+00 0,00E+00 0,00E+00 61 2 0 0,00E+00 0,00E+00 0,00E+00 1,00E+00

-6 -16 0 0,00E+00 0,00E+00 0,00E+00 62 2 0 0,00E+00 0,00E+00 0,00E+00 1,00E+00

DVB 8PSK

TRELLIS_2/3

-5,5 -14 0 0,00E+00 0,00E+00 0,00E+00 63 7 7,74 2,16E+07 6,58E-02 1,22E-03 0,00E+00

93

-5 -13 8,19 5,23E+07 1,59E-01 1,22E-03 63 7 8,22 9,32E+07 2,84E-01 1,22E-03 0,00E+00

-7,2 -16 5,84 4,25E+06 1,29E-02 0,00E+00 62 3 5,77 0,00E+00 0,00E+00 0,00E+00 1,00E+00

-7 -15 6 4,35E+06 1,32E-02 0,00E+00 63 7 6,01 0,00E+00 1,22E-02 0,00E+00 1,93E-03

-6,7 -15 6,2 0,00E+00 0,00E+00 0,00E+00 64 7 6,26 7,43E+06 2,26E-02 0,00E+00 6,96E-05

-6,5 -15 6,54 7,43E+06 2,26E-02 0,00E+00 61 7 6,48 1,08E+07 3,30E-02 0,00E+00 6,25E-06

-6,4 -15 6,58 1,08E+07 3,30E-02 0,00E+00 61 7 6,58 1,74E+07 5,31E-02 0,00E+00 1,75E-06

DVB 8PSK

TRELLIS_5/6

-6,2 -15 6,73 1,74E+07 5,31E-02 0,00E+00 63 7 6,75 2,05E+07 6,25E-02 0,00E+00 0,00E+00

-6,7 -15 6,93 1,80E+07 5,50E-02 0,00E+00 62 7 6,96 2,01E+07 6,13E-02 0,00E+00 2,83E-03

-6,6 -15 7,02 2,21E+07 6,74E-02 0,00E+00 62 7 7 2,41E+07 7,34E-02 0,00E+00 1,21E-03

-6,5 -15 7,18 2,60E+07 7,94E-02 0,00E+00 62 7 7,15 2,79E+07 8,51E-02 0,00E+00 4,77E-04

-6,4 -15 7,22 2,79E+07 8,51E-02 0,00E+00 62 7 7,16 3,16E+07 9,04E-02 0,00E+00 2,38E-04

-6,2 -14 7,39 3,34E+07 9,13E-02 0,00E+00 63 7 7,37 3,51E+07 9,26E-02 0,00E+00 3,41E-05

-6 -14 7,62 3,85E+07 9,25E-02 0,00E+00 63 7 7,54 4,16E+07 9,07E-02 0,00E+00 3,22E-06

DVB 8PSK

TRELLIS_8/9

-5,9 -14 7,67 4,47E+07 8,76E-02 0,00E+00 63 7 7,75 4,62E+07 8,59E-02 0,00E+00 1,29E-06

Tab. B.3: Measured Values for 8PSK (DVB framing)

TX

power

RX

power

Eb/No

_1 countBER1 rawBER1 corrBER1

idle

time

Eb/No

status

Eb/No

_2 countBER2 rawBER2 corrBER2

measured

BER

-7 -15 8,13 1,26E+08 1,90E-02 0,00E+00 62 7 8,05 1,73E+08 1,91E-02 0,00E+00 2,24E-03

-6,9 -15 8,14 1,79E+08 1,85E-02 0,00E+00 62 7 8,13 2,25E+08 1,85E-02 0,00E+00 9,11E-04

-6,7 -15 8,39 2,33E+08 1,71E-02 0,00E+00 61 7 8,34 2,75E+08 1,72E-02 0,00E+00 1,15E-04

-6,5 -15 8,5 3,86E+08 1,59E-02 0,00E+00 63 7 8,48 4,26E+08 1,59E-02 0,00E+00 1,05E-05

-6,4 -14 8,54 4,34E+08 1,53E-02 0,00E+00 63 7 8,62 4,72E+08 1,52E-02 0,00E+00 1,21E-06

DVB 16QAM

TRELLIS_3/4

-6,2 -15 8,81 4,78E+08 1,42E-02 0,00E+00 62 7 8,71 5,14E+08 1,42E-02 0,00E+00 0,00E+00

-5,4 -13 9,43 6,29E+07 5,02E-03 0,00E+00 61 7 9,45 7,54E+07 5,03E-03 0,00E+00 1,00E+00

-5,3 -13 9,51 7,80E+07 4,87E-03 0,00E+00 64 7 9,61 8,98E+07 4,83E-03 0,00E+00 1,97E-03

-5,2 -13 9,68 9,21E+07 4,50E-03 0,00E+00 63 7 9,74 1,03E+08 4,58E-03 0,00E+00 9,42E-04

-5,1 -13 9,77 1,05E+08 4,34E-03 0,00E+00 63 7 9,76 1,16E+08 4,29E-03 0,00E+00 3,90E-04

-5 -13 9,82 1,18E+08 4,01E-03 0,00E+00 62 7 9,89 1,28E+08 4,02E-03 0,00E+00 1,59E-04

DVB 16QAM

TRELLIS_7/8

-4,9 -13 9,88 1,30E+08 3,89E-03 0,00E+00 63 7 9,93 1,40E+08 3,92E-03 0,00E+00 6,62E-05

94

-4,7 -12 10,2 1,52E+08 3,51E-03 0,00E+00 63 7 10,08 1,61E+08 3,56E-03 0,00E+00 7,80E-06

-4,5 -12 10,36 1,69E+08 3,10E-03 0,00E+00 62 7 10,35 1,76E+08 3,07E-03 0,00E+00 1,90E-06

-4,2 -12 10,76 1,86E+08 2,49E-03 0,00E+00 62 7 10,74 1,92E+08 2,59E-03 0,00E+00 0,00E+00

Tab. B.4: Measured Values for 16QAM (DVB framing)

TX

power

RX

power

Eb/No

_1 countBER1 rawBER1 corrBER1

idle

time

Eb/No

status

Eb/No

_2 countBER2 rawBER2 corrBER2

measured

BER

-8,5 -18 4,09 1,53E+09 1,37E-01 4,87E-04 62 11 4,04 1,88E+09 1,38E-01 4,70E-04 3,15E-04

-8 -18 4,52 1,20E+09 1,11E-01 4,70E-04 61 7 4,51 1,48E+09 1,11E-01 4,69E-04 4,34E-05

-7,5 -17 5,18 9,23E+08 8,51E-02 8,06E-05 62 7 5,19 1,14E+09 8,52E-02 8,08E-05 4,42E-06

-7 -17 5,83 7,13E+08 6,51E-02 1,04E-06 62 7 5,89 8,74E+08 6,49E-02 1,02E-06 4,48E-07

-6,5 -16 6,45 5,48E+08 4,86E-02 6,52E-08 63 7 6,44 6,68E+08 4,86E-02 6,53E-08 3,25E-08

IBS BPSK

VITERBI_1/2

-6 -16 7 4,22E+08 3,55E-02 2,54E-08 62 7 7,05 5,10E+08 3,49E-02 2,35E-08 0,00E+00

-9,8 -18 4,07 9,10E+07 4,40E-02 5,90E-04 61 7 4,07 2,00E+08 4,40E-02 5,86E-04 3,00E-03

-9,7 -18 4,16 2,18E+08 4,15E-02 5,02E-04 62 7 4,14 3,20E+08 4,15E-02 5,02E-04 2,13E-03

-9,6 -18 4,33 3,93E+08 3,95E-02 4,33E-04 62 7 4,34 4,93E+08 3,97E-02 4,38E-04 1,62E-03

-9,5 -18 4,37 5,10E+08 3,74E-02 3,59E-04 62 7 4,45 6,02E+08 3,71E-02 3,49E-04 1,15E-03

-9,4 -18 4,55 6,23E+08 3,56E-02 2,99E-04 64 7 4,55 7,13E+08 3,46E-02 2,65E-04 8,42E-04

-9,3 -17 4,65 7,28E+08 3,27E-02 2,01E-04 62 7 4,68 8,09E+08 3,25E-02 1,93E-04 5,76E-04

-9,1 -17 4,82 8,45E+08 2,91E-02 7,52E-05 62 7 4,77 9,17E+08 2,91E-02 7,40E-05 2,93E-04

-9 -17 5 2,17E+08 2,66E-02 3,17E-05 63 7 4,98 2,83E+08 2,66E-02 3,17E-05 1,70E-04

-8,8 -17 5,3 2,94E+08 2,32E-02 2,35E-05 63 7 5,23 3,53E+08 2,33E-02 2,38E-05 8,52E-05

-8,5 -17 5,55 3,62E+08 1,89E-02 1,34E-05 63 7 5,51 4,10E+08 1,89E-02 1,34E-05 3,31E-05

-8,4 -16 5,69 4,19E+08 1,75E-02 1,02E-05 63 7 5,63 4,63E+08 1,76E-02 1,03E-05 2,19E-05

-8,1 -16 5,97 4,69E+08 1,40E-02 2,27E-06 63 7 6,01 5,04E+08 1,41E-02 2,13E-06 7,15E-06

IBS BPSK

VITERBI_3/4

-8 -16 6,12 5,09E+08 1,30E-02 1,64E-06 62 7 6,13 5,41E+08 1,30E-02 1,64E-06 4,40E-06

-9 -22 2,76 1,35E+09 1,81E-01 1,80E-04 62 7 2,72 1,81E+09 1,82E-01 1,80E-04 3,75E-03

-8,5 -22 3,26 8,17E+08 1,49E-01 3,90E-04 63 7 3,27 1,19E+09 1,49E-01 3,91E-04 6,13E-04

-8 -21 3,77 3,77E+08 1,22E-01 5,79E-04 62 7 3,86 6,86E+08 1,22E-01 5,79E-04 1,02E-04

IBS QPSK

VITERBI_1/2

-7,5 -21 4,62 5,55E+07 9,65E-02 2,48E-04 61 7 4,53 2,97E+08 9,65E-02 2,49E-04 1,25E-05

95

-7 -20 5,19 4,09E+09 7,11E-02 1,42E-06 62 7 5,23 4,26E+09 7,11E-02 1,42E-06 8,95E-07

-6,5 -20 5,76 3,48E+09 5,49E-02 3,75E-07 62 7 5,73 3,62E+09 5,45E-02 3,52E-07 2,10E-07

-6 -19 6,29 3,34E+09 4,11E-02 4,26E-08 63 7 6,33 3,45E+09 4,11E-02 4,24E-08 0,00E+00

-9,6 -22 3,59 2,49E+08 4,60E-02 6,59E-04 63 7 3,54 3,65E+08 4,60E-02 6,58E-04 3,66E-03

-9,5 -21 3,61 5,12E+08 4,39E-02 5,85E-04 62 7 3,69 6,21E+08 4,39E-02 5,85E-04 2,75E-03

-9,4 -21 3,72 6,40E+08 4,19E-02 5,14E-04 61 7 3,75 7,44E+08 4,20E-02 5,18E-04 2,08E-03

-9,2 -21 3,91 7,64E+08 3,77E-02 3,72E-04 62 7 3,96 8,57E+08 3,81E-02 3,83E-04 1,16E-03

-9,1 -21 4,09 8,80E+08 3,59E-02 3,08E-04 61 7 4,03 9,69E+08 3,59E-02 3,12E-04 8,63E-04

-9 -21 4,26 9,82E+08 3,25E-02 2,21E-04 62 7 4,18 1,06E+09 3,32E-02 2,15E-04 5,22E-04

-8,8 -20 4,35 1,18E+09 2,97E-02 9,54E-05 63 7 4,39 1,25E+09 2,96E-02 9,05E-05 2,87E-04

-8,6 -20 4,61 1,27E+09 2,64E-02 3,12E-05 63 7 4,64 1,34E+09 2,64E-02 3,12E-05 1,55E-04

-8,4 -20 4,79 8,68E+06 2,34E-02 2,42E-05 61 7 4,76 6,66E+07 2,37E-02 2,49E-05 8,56E-05

-8,1 -20 5,14 7,85E+07 1,94E-02 1,46E-05 62 7 5,13 1,27E+08 1,94E-02 1,47E-05 2,90E-05

-8 -20 5,17 1,35E+08 1,81E-02 1,16E-05 61 7 5,2 1,81E+08 1,82E-02 1,18E-05 2,08E-05

-7,7 -19 5,51 2,25E+08 1,48E-02 3,70E-06 61 7 5,55 2,62E+08 1,49E-02 4,03E-06 8,34E-06

IBS QPSK

VITERBI_3/4

-7,5 -19 5,82 5,94E+06 1,24E-02 1,58E-06 62 7 5,82 3,69E+07 1,24E-02 1,58E-06 3,39E-06

-8 -17 5,16 1,22E+06 3,73E-03 1,22E-03 64 7 5,31 1,93E+06 5,88E-03 1,22E-03 4,40E-04

-7,5 -16 5,92 0,00E+00 5,37E-04 0,00E+00 62 7 5,83 3,48E+05 1,06E-03 4,89E-06 8,62E-05

-7 -15 6,93 0,00E+00 0,00E+00 0,00E+00 61 7 6,86 2,62E+05 8,00E-04 1,47E-06 1,93E-05

-6,5 -15 7,27 2,62E+05 8,00E-04 1,47E-06 63 7 7,16 4,16E+05 1,26E-03 6,32E-06 5,27E-06

DVB 8PSK

TRELLIS_2/3

-6 -14 7,6 4,16E+05 1,26E-03 6,32E-06 63 7 7,71 4,80E+05 1,46E-03 1,00E-05 1,29E-06

Tab. B.5: Measured Values for IBS framing (pure convolution coding)

TX

power

RX

power

Eb/No

_1 countBER1 rawBER1 corrBER1

idle

time

Eb/No

status

Eb/No

_2 countBER2 rawBER2 corrBER2

measured

BER

-8,5 -18 4,41 2,26E+07 1,27E-01 5,42E-04 63 11 4,41 6,48E+07 1,57E-01 3,33E-04 1,00E+00

-8,2 -18 4,43 1,13E+09 1,38E-01 4,71E-04 63 7 4,41 1,49E+09 1,39E-01 4,64E-04 0,00E+00

-8 -18 4,49 7,43E+08 1,26E-01 5,51E-04 62 7 4,54 1,06E+09 1,27E-01 5,50E-04 0,00E+00

-9 -18 4,68 7,75E+08 1,22E-01 5,82E-04 62 7 4,65 1,08E+09 1,22E-01 5,83E-04 0,00E+00

IBS BPSK

VITERBI_1/2 + RS

-7,7 -17 4,87 3,66E+08 1,10E-01 4,63E-04 63 7 4,85 6,48E+08 1,10E-01 4,64E-04 0,00E+00

96

-7,5 -17 5,16 3,42E+07 9,89E-02 2,78E-04 62 7 5,13 2,83E+08 9,89E-02 2,83E-04 0,00E+00

-9,8 -18 4,19 4,32E+07 5,04E-02 9,03E-04 62 7 4,08 8,36E+06 3,83E-02 3,91E-04 1,00E+00

-9,7 -18 4,15 1,02E+08 4,83E-02 7,37E-04 61 7 4,12 9,59E+07 4,79E-02 7,22E-04 1,88E-04

-9,6 -18 4,35 2,18E+08 4,60E-02 6,55E-04 64 7 4,29 3,32E+08 4,55E-02 6,37E-04 3,14E-05

-9,5 -18 4,44 2,47E+08 4,29E-02 5,48E-04 61 7 4,48 3,54E+08 4,28E-02 5,45E-04 7,39E-06

-9,4 -18 4,67 3,86E+08 4,03E-02 4,61E-04 63 7 4,59 4,86E+08 4,04E-02 4,66E-04 7,57E-07

-9,3 -17 4,71 5,01E+08 3,83E-02 3,94E-04 62 7 4,72 5,98E+08 3,84E-02 3,93E-04 1,87E-07

IBS BPSK

VITERBI_3/4 + RS

-9,1 -17 4,94 6,12E+08 3,43E-02 2,59E-04 62 7 4,99 6,98E+08 3,41E-02 2,46E-04 0,00E+00

-8,8 -22 3,04 7,86E+08 1,87E-01 1,80E-04 63 7 3 1,26E+09 1,87E-01 1,80E-04 1,53E-04

-8,6 -22 3,24 7,82E+07 1,73E-01 2,23E-04 63 7 3,25 5,13E+08 1,74E-01 2,20E-04 4,13E-06

-8,5 -22 3,33 2,77E+09 1,67E-01 2,66E-04 63 7 3,38 3,19E+09 1,67E-01 2,66E-04 1,79E-07

-8,2 -21 3,56 2,32E+09 1,50E-01 3,89E-04 63 7 3,63 2,70E+09 1,50E-01 3,87E-04 0,00E+00

-8 -21 3,78 1,85E+09 1,38E-01 4,68E-04 62 7 3,84 2,19E+09 1,38E-01 4,69E-04 0,00E+00

-7,7 -21 4,09 1,44E+09 1,22E-01 5,80E-04 62 7 4,17 1,74E+09 1,23E-01 5,79E-04 0,00E+00

IBS QPSK

VITERBI_1/2 + RS

-7,5 -21 4,4 1,04E+09 1,09E-01 4,31E-04 61 7 4,41 1,31E+09 1,11E-01 4,68E-04 0,00E+00

-9,6 -21 0 0,00E+00 4,96E-02 1,04E-03 62 7 3,7 8,68E+06 4,63E-02 6,66E-04 1,00E+00

-9,5 -21 3,81 2,03E+08 5,07E-02 1,03E-03 63 7 3,69 1,97E+07 5,05E-02 9,82E-04 3,73E-04

-9,4 -21 3,78 4,46E+07 4,83E-02 7,36E-04 62 7 3,82 1,66E+08 4,86E-02 7,46E-04 1,17E-04

-9,2 -21 4,05 1,82E+08 4,43E-02 6,02E-04 62 7 4 2,93E+08 4,41E-02 5,90E-04 1,12E-05

-9,1 -21 4,18 3,15E+08 4,21E-02 5,23E-04 63 7 4,08 4,20E+08 4,22E-02 5,26E-04 2,39E-06

IBS QPSK

VITERBI_3/4 + RS

-9 -21 4,29 4,34E+08 3,89E-02 4,21E-04 61 7 4,2 5,32E+08 3,90E-02 4,18E-04 1,55E-07

Tab. B.6: Measured Values for IBS framing (concatenated coding)

97

(C/N)/N [dB]

TX power [dBm]

estim. Eb/No [dB] 1st 2nd 3rd Avg

C/N [dB]

calc. Eb/No [dB]

measured BER

-9,9 3,88 6,88 6,27 7,03 6,727 5,69 5,59 8,56E-03

-9,8 4,03 6,3 6,68 6,23 6,403 5,27 5,17 3,20E-03

-9,7 4,01 6,76 6,28 6,51 6,517 5,42 5,32 9,21E-04

-9,5 4,22 6,75 7 6,65 6,800 5,78 5,68 3,12E-05

-9,4 4,27 6,61 7,75 7,6 7,320 6,43 6,33 4,18E-06

-9,3 4,45 7,16 6,99 7,05 7,067 6,12 6,01 2,69E-07

-9,1 4,69 7,08 7,29 7,48 7,283 6,38 6,28 0,00E+00

DVB QPSK

VITERBI_3/4 + RS

-9 4,76 7,53 7,84 7,44 7,603 6,77 6,67 0,00E+00

-10,3 3,73 4,13 4,06 4,39 4,193 2,11 5,02 3,28E-03

-10,2 3,8 4,42 4,31 4,6 4,443 2,51 5,42 8,59E-04

-10,1 4,03 4,51 4,6 4,12 4,410 2,46 5,36 1,70E-04

-10 4,02 4,27 4,76 4,88 4,637 2,81 5,71 2,33E-05

-9,9 4,18 4,35 4,87 4,97 4,730 2,95 5,86 3,79E-06

-9,8 4,35 4,42 4,66 4,74 4,607 2,76 5,67 0,00E+00

DVB BPSK

VITERBI_3/4 + RS

-9,6 4,53 5,4 4,73 4,74 4,957 3,29 6,19 0,00E+00

-10,8 3,17 4,5 4,45 4,42 4,457 2,53 4,19 3,45E-03

-10,7 3,22 4,62 4,9 4,55 4,690 2,89 4,55 1,08E-03

-10,6 3,39 4,89 4,58 4,69 4,720 2,93 4,59 2,49E-04

-10,5 3,39 5,24 5,03 4,56 4,943 3,27 4,92 1,91E-05

-10,4 3,62 5,18 5,21 4,69 5,027 3,39 5,05 3,25E-06

-10,3 3,58 4,49 4,8 5,22 4,837 3,11 4,77 6,92E-07

DVB QPSK

VITERBI_1/2 + RS

-10,1 3,81 5,55 4,89 5 5,147 3,56 5,22 0,00E+00

-6,7 6,93 12,31 12,4 12,25 12,320 12,06 9,46 2,83E-03

-6,6 7,02 12,46 12,61 12,53 12,533 12,28 9,68 1,21E-03

-6,5 7,18 12,72 12,62 12,61 12,650 12,41 9,81 4,77E-04

-6,4 7,22 12,76 12,23 12,2 12,397 12,14 9,54 2,38E-04

-6,2 7,39 12,59 12,67 12,3 12,520 12,27 9,67 3,41E-05

-6 7,62 13,23 12,73 12,78 12,913 12,69 10,08 3,22E-06

DVB 8PSK

TRELLIS_8/9 + RS

-5,9 7,67 12,8 13 13,05 12,950 12,72 10,12 1,29E-06

-7,2 8,12 12,63 12,71 12,23 12,523 12,27 9,16 2,36E-03

-7,1 8,17 12,8 12,99 12,75 12,847 12,62 9,50 9,03E-04

-7 8,23 12,91 12,89 12,76 12,853 12,62 9,51 3,87E-04

-6,9 8,37 12,34 12,85 13,13 12,773 12,54 9,42 1,25E-04

-6,7 8,58 12,91 13,17 13,22 13,100 12,88 9,77 8,64E-06

-6,6 8,67 13,44 13,14 13,01 13,197 12,98 9,87 1,74E-06

-6,5 8,7 13,3 12,95 13,29 13,180 12,97 9,85 4,48E-07

-6,4 8,76 13,69 13,8 13,78 13,757 13,57 10,46 1,46E-07

DVB 16QAM

TRELLIS_3/4 + RS

-6,2 9,08 13,73 13,3 13,97 13,667 13,48 10,36 0,00E+00

Tab. B.7: Measured BER values vs. estimated and measured/calculated Eb/N0 for different CM pairs (DVB framing)

98

(C/N)/N [dB] MOD COD CR

estim. Eb/No [dB] 1st 2nd 3rd Avg

C/N [dB]

calc. Eb/No [dB]

Viterbi+RS 2/3 10,27 9,28 9,47 9,5 9,417 8,89 12,31

Viterbi+RS 3/4 10,22 10,1 9,4 9,7 9,733 9,25 12,15

Viterbi+RS 5/6 10,22 10,48 10,69 10,18 10,450 10,04 12,49 BPSK

Viterbi+RS 7/8 10,29 10,4 10,5 10,47 10,457 10,05 12,28

Viterbi+RS 1/2 9,56 10,08 9,85 9,69 9,873 9,40 11,06

Viterbi+RS 2/3 9,62 11,2 11,25 11,09 11,180 10,84 11,24

Viterbi+RS 3/4 9,64 11,65 11,46 11,4 11,503 11,18 11,08

Viterbi+RS 5/6 9,57 12,59 11,83 12,41 12,277 12,01 11,45

QPSK

Viterbi+RS 7/8 9,55 12,66 12,74 12,47 12,623 12,38 11,61

Trellis+RS 5/6 9,01 13,73 14,35 13,92 14,000 13,82 11,50 8PSK Trellis+RS 8/9 8,84 14,36 14,1 14,04 14,167 14,00 11,40

Trellis+RS 3/4 10,8 15,08 15,15 15,26 15,163 15,03 11,92 16QAM Trellis+RS 7/8 10,71 15,7 16,15 16,04 15,963 15,85 12,07

Tab. B.8: Estimated and measured/calculated Eb/N0 values for fixed TX power (-4.5 dBm)

MOD COD CR ref. C/N [dB]

ref. (C+N)/N

[dB]

Viterbi+RS 2/3 8,78 9,32

Viterbi+RS 3/4 9,29 9,78

Viterbi+RS 5/6 9,75 10,19 BPSK

Viterbi+RS 7/8 9,96 10,38

Viterbi+RS 1/2 10,54 10,91

Viterbi+RS 2/3 11,79 12,07

Viterbi+RS 3/4 12,30 12,55

Viterbi+RS 5/6 12,76 12,98

QPSK

Viterbi+RS 7/8 12,97 13,19

Trellis+RS 5/6 14,52 14,67 8PSK Trellis+RS 8/9 14,80 14,94

Trellis+RS 3/4 15,31 15,44 16QAM Trellis+RS 7/8 15,98 16,09

Tab. B.9: C/N values related to a fixed Eb/N0 (12.2 dB)

99

Appendix C: Cookbook 1. Hardware Setup � Fig. 5.1

1.1. Basic configuration of the serial interface (BER tester) � Tab. 5.1 1.2. Basic configuration of the serial terrestrial interface (DMD20) � Tab. 5.2 1.3. Basic configuration of DVB framing mode (DMD20) � Tab. 5.4 1.4. Basic configuration of the IP/SNMP management interface (DMD20) � Tab. 5.3 1.5. Basic configuration of the IP/SNMP management interface (Managing Station) �

IP=10.0.0.3/24 2. Software Setup of the Managing Station

2.1. Prerequisite � POSIX compatible environment, SNMP enabled, C++ compiler 2.2. Copy vendor specific MIB � DMD20-MIB.txt into directory ./mibs 2.3. Optional: Build Measuring Executable (mt1.exe ) � make –f makefile1 2.4. Build Managing Executable (mt2.exe ) � make –f Makefile

3. Customize Managing Executable

3.1. Set initial start values � conf.txt (for the file format see chapter 5.3)

3.2. Set reference values for the controller � ref.txt (for the file format see chapter 5.3)

3.3. Start controller � mt2 -t

100