integration of systems and components - media networks laboratory

IST IMOSAN Deliverable D13

of 83

SIXTH FRAMEWORK PROGRAMME Integrated Multi-layer Optimization

in broadband DVB-S.2 SAtellite Networks FP6-027457

Deliverable D13

Integration of Systems and Components

Author(s) A. Chernilov, G.Gardikis, Y. Hadjadj Aoul, J. Lauterjung, J. Mouëza, J-F Roy.

Participant(s) CNES; TGV; R&S;PRS;OPT Work package WP5, Task 5.1 Dissemination Level Public Nature Report Version 1.0 Total number of pages 83


of 83

Table of Contents

1. INTRODUCTION .............................................................................................................................................. 4 2. SCOPE OF THE DOCUMENT ........................................................................................................................ 4 3. GLOSSARY AND ABBREVIATIONS ............................................................................................................ 5 4. MODULES DESCRIPTION ............................................................................................................................. 7

4.1. DVB-S2 MODULATOR................................................................................................................................. 7 4.2. DVB-S2 TEST RECEIVER............................................................................................................................. 7 4.3. BWMM....................................................................................................................................................... 8 4.4. SRMS........................................................................................................................................................ 11 4.5. ACM FEEDBACK LOOP MODULE............................................................................................................... 14 4.6. SA MODULE............................................................................................................................................... 15 4.7. ATM/IP CONVERTER................................................................................................................................. 16

5. TOOLS AND MEANS DESCRIPTION......................................................................................................... 17 5.1. A9780 GATEWAY ..................................................................................................................................... 17 5.2. EMULATOR PROPAGATION CHANNEL ........................................................................................................ 18 5.3. INTERFACE WITH THE GATEWAY ............................................................................................................... 18 5.4. IP SERVICES............................................................................................................................................... 20

6. INTEGRATION DESCRIPTION................................................................................................................... 20 6.1. ARCHITECTURE OF THE INTERCONNECTED COMPONENTS .......................................................................... 21

6.1.1. DVB-S2 Receivers and Modulator Architecture .................................................................................. 21 6.1.2. Service Adaptation Architecture .......................................................................................................... 21 6.1.3. IMOSAN FLSS Architecture................................................................................................................. 22

6.2. DVB-S2 MODULATOR AND DVB-S2 TEST RECEIVER INTEGRATION ........................................................ 24 6.2.1. Interoperability between the SRMS/ BWMM and the DVB-S2 modulator ........................................... 24 6.2.2. Interoperability between DVB-S2 modulator and DVB-S2 test receiver ............................................. 25 6.2.3. Connection of DVB-S2 test receiver to CNI reporting module ............................................................ 27 6.2.4. Connection of Data receiver to the testbed .......................................................................................... 27

6.3. ATM/IP AND BWM INTEGRATION............................................................................................................ 27 6.3.1.1. Test Plan.......................................................................................................................................... 28 6.3.1.2. Test environment ............................................................................................................................. 28 6.3.1.3. Hardware Configuration ................................................................................................................. 28 6.3.1.4. Software Configuration ................................................................................................................... 28 6.3.1.5. Description of the tests .................................................................................................................... 29

6.4. BWMM, SA AND SRMS INTEGRATION .................................................................................................... 35 6.4.1.1. Test Plan.......................................................................................................................................... 35 6.4.1.2. Test environment ............................................................................................................................. 37 6.4.1.3. Hardware Configuration ................................................................................................................. 38 6.4.1.4. Software Configuration ................................................................................................................... 38 6.4.1.5. Description of the tests .................................................................................................................... 38

6.5. ACM FEED BACK LOOP INTEGRATION...................................................................................................... 69 6.6. SA MODULE INTEGRATION ........................................................................................................................ 71

6.6.1. Web Service tests using Internet Explorer browser.............................................................................. 71 6.6.2. Web Service tests using Test Application ............................................................................................. 72 6.6.3. Configuration using test application.................................................................................................... 74 6.6.4. Configuration and control using SRMS ............................................................................................... 77

6.7. SYSTEM COMPLETE INTEGRATION............................................................................................................. 77 6.7.1. Integration Platform Overall Description............................................................................................ 77 6.7.2. Integration platform Tests and Results ................................................................................................ 81

6.8. WIFI/WIMAX ACCESS NETWORK INTEGRATION ....................................................................................... 82


of 83

7. CONCLUSION................................................................................................................................................. 83 8. REFERENCE ................................................................................................................................................... 83


of 83

1. Introduction WP5 aims to describe the integration of all the systems, components, hardware and software modules that have been developed in WP3 and WP4, into a complete system, in order to demonstrate in a satellite environment an integrated resource management system that spans across physical, network and service layers and allows optimum usage of satellite spectrum. Task 5.1 “Integration of systems and components” is one of the tasks related to WP5. We recall here from the Technical Annex, the objectives of this task:

1. To integrate Bandwidth Manager and Multiplexer in the Gateway 2. To integrate the DVB-S2 modulator, supporting ACM, in the Gateway and interconnect it

with the BWMM module 3. To integrate Service Adaptation modules (adaptative trans-coding and trans-rating) in the

Gateway and interconnect them with the SRMS and the Multiplexer. 4. To integrate SRMS in the GW and to interconnect it with BWMM, the SA modules and the

SNIR measurement module 5. To integrate STBs and STs into the system and interconnect them to the GW 6. To integrate the WiFi/WiMAX access network with ST and the overall system

2. Scope of the document The D13 deliverable contains the description of integration activities performed in the frame of Task 5.1 "Integration of systems and components". This document in Chapter 4 "Modules Description", briefly overviews the different modules, means and tools developed by the IMOSAN partners in the frame of WP3 and WP4:

• DVB-S2 Modulator and DVB-S2 Test Receiver are developed by R&S, • BWMM, SRMS, ATM/IP Converter are developed by TGV. • ACM Feed Back Loop module is developed by PRS. • Service Adaptation Module is developed by OPT.

Then, in Chapter 5 "Tools and Means Description", the following tools and means used for realizing the integration platform are described:

• The DVB-S2/RCS Gateway • The Emulator Propagation Channel (ECP) • The IP Services

Finally, the Chapter 6, “Integration description”, describes the tests and their results performed on the interconnected modules, up to the complete platform integration.


of 83

3. Glossary and Abbreviations

A ACM Adaptive coding and modulation ASI Asynchronous Serial Interface ATM Asynchronous Transfer Mode

B BWMM Bandwidth Manager and Multiplexer C CBR Constant Bit Rate D DVB-RCS Digital Video Broadband Return Channel for Satellite DVB-S2 DVB Satellite transmission 2nd generation CCM Constant Coding and Modulation CNI Carrier to Noise plus Interference Ratio

E ECP Emulator Channel Propagation F FLSS Forward Link Subsystem FLU Forward Link Unit I IP Internet Protocol L LAN Local Area Network M MAC Media Access Control MIB Management Information Base MMT Multicast Map Table MODCOD Modulation and Coding MPE Multi Protocol Encapsulation MPEG2 Motion / Moving Pictures Expert Group MSG Media Service Gateway

N NIT Network Information Table O OAM Operation And Maintenance P PAT Program Association Table PBX Private Branch eXchange PID Program Identifier PMT Program Map Table PSI Program System Information

R RMT RCS Map Table RLSS Return Link Sub-System RTA Real Time Analyzer

S SA Service Adaptation SDT Service Description Date SNIR Signal to Noise Ration plus Interference Ratio SPT Satellite Position Table SRMS Satellite Resource Manager System ST Satellite Terminal STB Set Top Box

T TCP Transmission Control Protocol TDT Time and Date Table TISS Terrestrial Interface Subsystem TS Transport Stream

U UDP User Data Protocol


of 83

ULE Ultra Lightweight Encapsulation V VBR Variable Bit Rate VPI/VCI Virtual Path Identifier / Virtual Channel Identifier

W WP Work Package


of 83

4. Modules Description

4.1. DVB-S2 Modulator The development and implementation of firmware and software for the DVB-S2 modulator has been completed prior to the most recent integration step. The modulator allows now for the setting of 'ACM MODE ON'. When operated in this mode, the stuffing that is normally used in CCM to obtain a constant bit rate for the modulator input so as to match exactly the bit rate required for a certain transmission mode, has to be switched off. Any rate adaptation or filling of the pipeline for the modulator is then done by inserting additional baseband frames. When the modulator is set to ACM ON, the MODCOD information is decoded and the internal settings are changed accordingly.

4.2. DVB-S2 Test Receiver Compared with the description given in deliverable D11-I, the DVB-S2 test receiver contains now a complete SNMP MIB that allows for the setting of all parameters of the test receiver and for retrieving the information of the measurement parameters. At this stage of the integration (October 2007), the most important measurement value is the C/N ratio which is read from the MIB by the CNI reporting module.


of 83

A new software version has been developed and implemented to increase the accuracy of the C/N measurements which are found to only deviate by 0.1 or 0.2 dB from the calibrated setting of the modulator.

4.3. BWMM The Bandwidth Manager and Multiplexer (BWMM) is composed of:

o The Encapsulator & Multiplexer (EMT) and o The Bandwidth Manager (BWM)

It is an IP to MPEG-2 gateway that can handle the filtering of the data arriving via one or several local area networks through one or two Ethernet boards, and encapsulate them into MPEG-2 packets. These packets are inserted into a stream (that can optionally gather data from other sources) and generated on an ASI board. The DVB-S2 Multiplexer is basically equipment able to generate a fixed bit rate output transport stream, from existing digital and already compressed video services, whatever their incoming bit rate (CBR or VBR).

Control/Supervision

MultiplexerInput Services

Source(DVB, IP) DVB MPEG-2 TS

Figure 4.3-a: BWMM overview

The DVB-S2 Multiplexer is based on:

• A variable number of inputs: the limit is fixed by the output rate. • Several kinds of input:

IP (data and video), network (TCP,UDP), PSI tables (DVB and MPEG2), DVB-RCS tables, DVB-S2 signalling tables,

• An independent and specific task bound to each one, • A complex encapsulator that will support simultaneously MPE/ULE and IPv4/IPv6, • an IP encapsulation into MPEG2-TS packets of 204 bytes over ASI, • A communication task dedicated to configuration and supervision. • Bit rate reduction with PID filtering, or service filtering,.. • An open control interface to enable the communication with the SRMS server, • Generation of DVB-RCS tables (SPT, …), • Generation of IP/MAC tables.


of 83

The following diagram depicts the input bandwidth management and output within the Bandwidth manager and DVB-S2 multiplexer.

Figure 4.3-b: Available inputs and output in the DVB-S2 multiplexer

ASI Board

MultiplexerTask

TS Output 1Management

Task

Network Socket Client

Input DVB-RCS

ManagementTask

Client/serverManagement

Task

IP InputManagement

Task

Input PID/MODCOD

ManagementTask

Input PSI/SIManagement

Task

IP frames

DVB-RCS Tables

DVB-S2 Signaling


of 83

Figure 4.3-c: IMOSAN architecture According to IMOSAN architecture (refer to Figure 4.3-c), the Bandwidth Manager interacts mainly with:

• The Satellite Resource Manager System, which provides DVB-RCS tables over IP for the forward link signalling,

• The Satellite Resource Manager System, which sends request to modify PID bitrate and provides PID information status,

• The Ethernet LAN, which computes in real time the bandwidth management of the IP traffic,

• The ATM to IP system, which computes in real time the bandwidth management of the IP traffic (OAM traffic to the ST),

• The encoder, which computes in real time the bandwidth management of the IP traffic (MPEG-2 over IP).

The DVB-S2 Multiplexer (EMT), as shown by 0c, interacts mainly with:

• The Bandwidth Manager, • The Satellite Resource Manager System, which computes in real time the S2 Table

signalling (association of PIDs and modulation code) for synchronization with the DVB-S2 modulator,

IMOSAN FORWARD LINK UNIT

TISS

From/to Internet,

Data center...

Time & Freq. Synchro LAN

Traffic Plane

S2MOD

ATM OC-3

IP Router PEP Performance Enhancement

3 4 1

L-band Fwd Tx IF

2 BWM EMT

ATM/IP

Input traffic Tx L-band output References Control flow

1

2

3

4

Web Service Controller

1 2

3

1

2

3 Control

Optical spliter

S2 Signaling Bit rate commands ST management

Return Link Controller (RLC) DVB-S2 / DVB-RCS GATEWAY (CNES)

Encoder SRMS S4100 (ST)

4

4

Ethernet LAN


of 83

• The DVB-S2 modulator, which encapsulates IP traffic into MPEG-TS packets of 204 bytes and broadcasts a CBR MPEG-2 TS over ASI.

4.4. SRMS The functional diagram of the SRMS server consists in 3 parts (refer to Figure 4.4). The Inputs block includes:

o The RCS block RCS, o The Service priority lists and o The Service adaptation list.

The Outputs block includes:

o The Terminal Controller, o The Unit Status message, o The network block, o DVB-RCS tables and o The S2 tables signalling.

Finally, the internal blocks are :

o MODCOD generation and o Bandwidth allocation.

The SRMS server receives :

o The forward signalling CNI measurement, o The modulation and code (MODCOD) per satellite terminal, any time a change in satellite

channel conditions occurs and o DVB-RCS tables from the RLSS.

It calculates the appropriate encoding parameters, defines a mapping association table (MAC address to PID) and provides to the EMT the MODCOD and PID couple to be applied by the DVB-S2 modulator. The SRMS allocates per video service (SA) the bandwidth requirement according to the prioritization list, the service adaptation list and the overall bandwidth of the BWM. The SRMS then sends the appropriate commands to the Web service controller corresponding to the required module transcoder or encoder.


of 83

S2 TablesSignaling

Forward Signaling CNI

SRMS manager

Controller Block

MODCOD

DVB-RCS Tables

To EMT

BandwidthAllocation

DVB-RCSTables

Networkblock

To Transcoder

To BWM

To EMT

Service prioritylist

RCS block

TerminalController

To ST

Unit StatusMessage

To RLC

SRMS Server

ServiceAdaptation list

Process blockInputblock

Outputblock

Figure 4.4: SRMS functional block diagram The SRMS server is based on:

• A client/server mechanism, • A bandwidth manager for services adaptation , • A management of the priority list, • A management of the service adaptation list, • A management of an IP input declared by the BWMM (stop and start), • A management of the DVB-S2 table signalling, • A webservice client to ask requests to the MSG webservice controller, • An open interface with the RLSS interface, • A management of the “Unit Status Message”, • A management of ST.

The SRMS manager is based on:

• A communication identification with the SRMS server,


of 83

• A configuration of the available MODCOD table and Modulator parameters according to the R&S modulator (S2),

• A configuration of the priority list for each PID, • A configuration of the service adaptation, • A global supervision, • A saving of the server configuration.

According to IMOSAN architecture (refer to Figure 4.3-c ), the Satellite Resource Manager System interacts mainly with:

• The RLC to receive the ST requirement, • The RLC to provide the unit status message, • The RLC to receive the DVB-RCS tables, • The BWMM to manage the IP input, • The BWMM to configure the SPT table, • The BWMM to provide S2 signalling, • The BWMM to provide the DVB-RCS table, • The Web Service controller to manage the SA bandwidth of encoder and transcoder, • The ST via SNMP agent to manage the reset command.


of 83

4.5. ACM Feedback Loop Module The ACM feedback loop module exploits an important feature of the DVB-S2 standard which is the Adaptive Coding and Modulation (ACM) mechanism. This optimization is notably achieved through the design and the development of a closed loop feedback mechanism. The ACM feedback loop module retrieves a sub-set of parameters selected as candidates for the feedback from the DVB-S2 test receiver to the SRMS. The SNIR measurement is the first candidate for a quality criterion at physical layer. It allows a direct comparison with the C/N value that is required for error-free reception with a specific transmission mode. Therefore, the ACM feedback loop module retrieves these parameters through sending an SNMP request to the R&S DVB-S2 test receiver. Afterwards, an SNMP response is received and processed to extract the values of the requested parameters. Thus, the optimized reception MODCOD is, then, deduced based on these parameters. Finally, the ACM feedback loop informs the SRMS about the forward channel condition (e.g. Signal to Noise and Interference ratio, SNIR) and the optimized configuration of each satellite terminal, via the DVB-RCS link by sending an appropriate signalling message (see deliverable D10-I for more details 0[1]).

Figure 4.5: ACM feedback loop messages sequencing


of 83

4.6. SA module One of the important components of IMOSAN architecture for the satellite spectrum usage optimization is a Service Adaptation module. Service Adaptation module works under SRMS module control and provides both static and dynamic content adaptation according to the current network conditions. SA modules of IMOSAN provide broadcast TV services in numerous formats. SA modules are capable of performing spatial, temporal and bandwidth adaptation.

Figure 4.6-a: Broadcast services generation platform.

Service adaptation modules are integrated in the system through the state of the art web service interface and use SOAP protocol to communicate with SRMS.


of 83

Figure 4.6-b: Software and hardware architecture.

4.7. ATM/IP Converter On the return link of the DVB-RCS Gateway, the output traffic from the RLSS is composed of ATM cells. According to the IMOSAN architecture (refer to Figure 3 - IMOSAN Architecture), an ATM to IP interface is needed to convert ATM traffic to IP traffic. The IP traffic is routed according to a routed map table into two traffics (each ST is assigned to a unique MAC address) :

o The return traffic IP signalling (OAM) for the ST which will feed the BWM and o The user traffic (LAN traffic).

To work in parallel with the IMOSAN FLU, an optical splitter is added and linked to the ATM to IP converter. The ATM to IP converter interface is able to:

• Receive the ATM cells (the return link traffic protocol stack is compliant with IP in AAL5 over ATM),

• Create multiple PVC configured with one VPI/VCI per terminal, • Generate IP traffic for the OAM and the return traffics, • Save or restore the configuration of the ATM to IP interface.


of 83

5. Tools and Means Description

5.1. A9780 Gateway The A9780 DVB-RCS standard Gateway, designed and produce by Thales Alenia Space is designed for medium size to large size networks from few hundreds up to several thousands Terminals with high throughput or high number of return link carriers. One A9780 DVB-RCS network comprises one Gateway and a large number of Satellite Terminals. It supports star links between the Gateway and the Satellite Terminals, but also Satellite Terminals to Satellite Terminals connectivity through the Gateway. It is based on IPv4 protocol and provides access services. On top of the access services, end-user services such as Internet access, VPN, VoIP, etc are supported. The gateway fits in a single rack, which includes all the Gateway subsystems (modulators, demodulators, IP encapsulators, management and control servers, routers, TCP accelerators, etc …). The gateway is composed of the following sub-systems (Figure 5.1):

A Gateway Management Subsystem (GMSS) A Forward Link Subsystem (FLSS); A Return Link Subsystem (RLSS); A Time and Frequency Subsystem (TFSS); An Access Control Subsystem (ACSS); A Terrestrial Interface Subsystem (TISS).

Figure 5.1: Gateway Subsystems

The TISS is composed of an IP/ATM router and a TCP accelerator; the gateway is connected to external networks through this router. The Gateway handles the traffic between this external network and the satellite Terminals and manages the gateway component and services.

GMSS

RLSS

TFSS

ACSS

FLSS

TISS Forward link

Return link

External network

A9780 Gateway


of 83

The gateway will be interfaced and interconnected with new components developed in the frame of IMOSAN project. The components integration with the gateway is described in chapter 5.3 “Interface with the Gateway”.

5.2. Emulator Propagation Channel The Emulator Propagation Channel (ECP) synthesizes the principal phenomena of propagation occurring on RF links between earth and space. The EPC can simulate the following disturbances: the delay, the noise generator, the time jitter, the frequency doppler shift, the level fading. For the integration activities, the ECPs are used to test the complete integrate system. Here after is shown a view of the ECP:

Figure 5.2 : ECP system view

5.3. Interface with the Gateway The new FLSS, composed of the ATM-IP Converter, the BWMM-SRMS modules and the DVB-S2 Modulator, are designed to be connected to the Gateway. The new FLSS has been connected in parallel to the Gateway FLSS in order that the traffic data from the TISS can be split towards the two FLSS by the mean of an ATM Optical Tap. The ATM Optical Tap integration is shown in the following figure:

Noise generator #1

Noise generator #2

Spectrum Analyser

ECP_02

ECP_01


of 83

Figure 5.3-a: Gateway connection with the new components

Modules in grey belong to the A9780 Gateway. Module in yellow is the new FLSS developed in the frame of IMOSAN project. Module in blue is the selected solution to split the traffic to the new FLSS. The traffic data between the TISS and the FLSS are composed of ATM cells. The following figure shows the Tap connection with the Gateway component and the new FLSS.

Figure 5.3: Forward Link Connectivity

Here after is the Optical Tap Identification:

Equipment Contribution Manufacturer Product reference ATM Optical Tap CNES Net Optics TP-SR5-SCSLM

ATM Optical

Tap

ATM cells

GMSS

RLSS

TFSS

ACSS

FLSS

New FLSS Router

PEP

TISS

Tx Rx Tx Rx Tx A Tx B B A

ACME

MM with PEP or Router

PEP

MM to ACME

ATM-IP Converter

MM to ACME

DTE

To BWMM-SRMS

A 9780 Gateway

Optical Tap

IMOSAN FLSS


of 83

5.4. IP Services The following IP services use during the complete integration platform tests are the following: 1) Video Conferencing service E/pop Web Conferencing software is a rich media conferencing solution. It provides a full suite of real time collaboration features, plus multiparty, fully interactive VoIP desktop video conferencing. This software can be used for training, sales and events. The main features of this product are the following:

o Dynamic PowerPoint sharing o Desktop sharing o Multipoint VoIP Conferencing o Document sharing o Application sharing o White board o Chat o …

E/pop Web Conferencing software is implemented in the server connected to the gateway LAN, behind the Gateway TISS Router. 2) VoIP Service Asterisk is an open source/free software implementation of a telephone private branch exchange (PBX). Like any PBX, it allows a number of attached telephones to make calls to one another. Asterisk software is implemented in the server connected to the gateway LAN, behind the Gateway TISS Router.

6. Integration Description The integration activities have taken place in CNES premises, in a technical room where the Gateway, new modules, means and tools are installed. We apply the following method to validate the integration of the new modules:

• Initially, each new module has been individually tested in WP 3 and WP4. • The next step is the functioning validation between two modules (for example: between

BWMM and Modulator, between S2 Test Receiver and ACM Feed Back Loop, between Gateway and ATM/IP Converter)

• After the tests between two modules, we tested without the SRMS module, several modules interconnected through their interface (for example BWMM interconnected with a chain composed of the Modulator, the Test Receiver and the ACM Feed Back Loop).


of 83

• Then, we tested these modules with the SRMS module (for example: SA module with the SRMS, BWMM connected).

• At the stage of the integration, the complete system integration will be realized in an emulated satellite environment thank to the use of the ECP.

6.1. Architecture of the interconnected components The following sub-chapters describe the interconnected components architecture with their interfaces and their connectivity:

6.1.1. DVB-S2 Receivers and Modulator Architecture The following figure shows the connections and interfaces between the DVB-S2 receivers and the DVB-S2 Modulator:

Figure 6.1.1: DVB-S2 Modulator and Receivers Connections and Interfaces

In the following tables, the components are depicted:

Equipment Contribution Manufacturer Product reference Version DVB-S2 MOD R&S R&S SFU Broadcast Test

System V01.61.37.00

BETA

DVB-S2 Demod R&S Newtec NTC/2263.xT - DVB-S2 Test Rx R&S R&S DVM400 V4.43

Oct.11.2007 DVB-S2 ASI Rx DEM Digicast Media Router S2-ASI -

Table 6.1.1: Components Identification

6.1.2. Service Adaptation Architecture The following figure shows the Video service chain architecture:

DVB-S2 MOD

BWMM-SRMS

Ethernet

Splitter 1/2

RF Out 50Ω

TS Serial in

DVB-S2 Demod

DVB-S2 Test Rx

DVB-S2 ASI Rx

ASI-Rx

ASI-A out

IFL 1N

RF1 (QPSK/8PSK) TS


of 83

Figure 6.1.2: SA Connections

In the following tables, equipments and application programs are depicted:

Equipment Contribution Manufacturer Product ref. Notes HD Camera CNES SONY HVR-Z1E HD camera MPEG-2 Encoder CNES THOMSON DBE 4110 - H264 Encoder OPT OPTIBAS MGES5610 @IP: 192.168.1.93 Media Gateway Server OPT - - @IP:192.168.1.92 Switch CNES SynOptic Lattishub 2803 -

Table 6.1.2.a: Equipments Identification

Application-Program Version Machine MGWServices Web Service 1 Media Gateway Server

Table 6.1.2.b: Application Program Identification

6.1.3. IMOSAN FLSS Architecture The following figure shows the different components that constitute the new Forward Link Sub System ( IMOSAN FLSS) of the Gateway:

HD Camera

MPEG-2 Encoder

SAASI

Ethernet SwitchASI

Media Gateway Server


of 83

Figure 6.1.3: Architecture of the new IMOSAN FLSS

In the IMOSAN FLSS, before to be handled by the BWMM, the ATM cells are converted into IP data by the mean of an ATM-IP Converter developed in the frame of the project. In the following tables, equipments and application programs used in the IMOSAN FLSS are depicted:

Equipment Contribution Manufacturer Product ref. Notes

BWMM-SRMS Server TGV HP Proliant DL360

@IP: 200.1.2.0 Port 8400

ATM-IP Converter Server TGV HP Proliant DL360

@IP: 200.1.1.4 Port 4400

Converter Mgmt PC CNES - - @IP: 200.1.1.2 Ethernet Switch CNES Netgear GS108 -

Table 6.1.3-a: Equipments Identification

Application-Program Version Machine ATM-IP Converter V1.0.0 ATM-IP Converter Server

OpenMux - BWMM-EMT-SRMS Server OpalManager - BWMM-EMT-SRMS Server SrmsServer - BWMM-EMT-SRMS Server

SrmsManager - BWMM-EMT-SRMS Server NetTester V.4.2.0.0

Table 6.1.3-b: Application Program Identification

BWMM-EMT-SRMS

ASI 1A out

ATM-IP Converter ATM Cells DVB-S2 MOD IP

Ethernet Switch

TS Serial in

Converter Mgmt


of 83

6.2. DVB-S2 Modulator and DVB-S2 Test Receiver Integration The integration of the DVB-S2 modulator and the DVB-S2 test receiver consists of four steps:

1. Interoperability between the SRMS/ BWMM and the DVB-S2 modulator 2. Interoperability between DVB-S2 modulator and DVB-S2 test receiver 3. Connection of DVB-S2 test receiver to CNI reporting module 4. Connection of Data receiver to the testbed

6.2.1. Interoperability between the SRMS/ BWMM and the DVB-S2 modulator

The SRMS/ BWMM provides a single MPEG2 Transport Stream to the DVB-S2 modulator. The interface is ASI (Asynchronous Serial Interface). The Transport Stream packets are 204 byte long. The specification of the additional bytes was slightly modified in comparison with the description given in D9-I Section 2.2. Instead of originally 2 byte now 3 byte are used to also transport the information whether the respective packet is to be treated as a dummy packet or not. Dummy packets are inserted into the Transport Stream in addition to the useful packets which are grouped into Baseband frames by the modulator, to maintain a constant bit rate of the input Transport Stream (e.g. when a test stream is provided by an external TS generator). The dummy packets (identified by a '1' in the 3rd byte) are discarded at the modulator input. The following definition of the additional bytes is used:

Byte Bit Comment 0 (first) 7 (MSB) 1: start a new BBFRAME 0 6 0: normal frame

1: short frame 0 5 0: pilots off

1: pilots on 0 4 ~ 0 0: no change from previous packet

other: MODCOD information 1 7 ~ 0 reserved for future use; set to 0 2 7 ~ 0 0: useful packet

1: dummy packet other: reserved for future use

16 byte 4 byte 184 byte

3 byte 13 byte


of 83

The purpose of the first test was to verify that the information inserted by the SRMS/ BWMM into the 3 bytes is read and interpreted correctly by the modulator and that the modulation parameters and code rates are set accordingly. This has been achieved and the test was successfully completed.

6.2.2. Interoperability between DVB-S2 modulator and DVB-S2 test receiver

The interoperability between the modulator and the test receiver was tested with test streams provided by the SRMS/ BWMM. These test streams contain the information needed by the modulator to switch the MODCOD setting repeatedly, e.g. switching from 8PSK 3/4 to QPSK 8/9 and back.

Figure 6.2.2-a: Modulator setting 8PSK code rate 3/4


of 83

Figure 6.2.2-b: Received signal (constellation 8PSK at code rate 3/4)

Figure 6.2.2-c: Modulator setting QPSK code rate 8/9


of 83

Figure 6.2.2-d: Received signal (constellation QPSK at code rate 8/9)

The DVB-S2 test receiver follows to settings provided by the modulator via the RF signal.

6.2.3. Connection of DVB-S2 test receiver to CNI reporting module The CNI reporting module communicates with the test receiver over a LAN connection. It reads the C/N value from the test receiver MIB as described in section 6.3. The C/N values in the MIB are internally up-dated once per second. This delay has to be considered when the reaction time of the MODCOD adaptation is estimated. The interoperability between the test receiver and the CNI reporting module was successfully established.

6.2.4. Connection of Data receiver to the testbed At this stage of the integration (October 2007), an additional data receiver is operated in parallel to the test receiver processing the same RF signal. This data receiver provides the payload service as an output to an ASI/ IP converter that allows for the feeding of a set-top box capable of decoding the H.264 content and providing the decoded video and audio signal. The interoperability between the modulator and the data receiver was also successfully tested.

6.3. ATM/IP and BWM Integration The following chapter describes the tests that have been performed to validate the integration of the ATM to IP converter with the bandwidth management system.


of 83

6.3.1.1. Test Plan The test plan includes the following tests:

o Connect/disconnect tests : Connect to ATM to IP converter, Disconnect from ATM to IP converter.

o Configuration tests: Create a PVCs, Save a configuration, Load a configuration.

o Scalability tests : CPU load, Robustness.

6.3.1.2. Test environment

Figure 6.3.1.2: ATM to IP platform test

6.3.1.3. Hardware Configuration • ATM to IP converter,

• Optical splitter,

• RTA : Real time analyser,

• Bandwidth Manager and Multiplexer.

6.3.1.4. Software Configuration • ATM to IP server,

• ATM to IP manager,

• OPAL manager,

• OpenMux server

B W M M

A S I o u t

R T A

A T M /IP M a n a g e r

In te rp h a s eA d a p te r

A T M to IPc o n v e rte r

2 0 0 .1 .1 .3

2 0 0 .1 .1 .4 2 0 0 .1 .1 .2

O p tic a l S p lit te r


of 83

6.3.1.5. Description of the tests

Connect/Disconnect tests

Objective of the test Test case # Connect to ATM to IP converter Imosan_ATM2IP_01 Disconnect from ATM to IP converter Imosan_ATM2IP_02

Test Connect to ATM to IP converter Reference Imosan_ATM2IP_01 Involved partners TGV Description : Connect to ATM to IP converter

Validated function : ATM to IP management

Required test tools : None

Condition of test success ATM to IP converter server is running. Atm2Ip manager is running under ATM gateway.

Date : 04/25/07 Version : 1.0.0.0 Reference : Author : Test Result From ATM to IP manager select the connection parameters:

• Server address: 200.1.1.4, • Port Number: 4000.

And click on “Connect” button.

The view displays the status of the connection: “Connected to server 200.1.1.4 – Port 4000”. A new ATM file box appears.

Comment :


of 83

Test Disconnect to ATM to IP converter Reference Imosan_ATM2IP_02 Involved partners TGV Description : Disconnect from ATM to IP converter



Condition of test success ATM to IP converter server is running. Atm2Ip manager is running under ATM gateway and is connected to the ATM to Ip converter.

Date : 04/25/07 Version : 1.0.0.0 Reference : Author : Test Result From ATM to IP manager click on “Disconnect” button.

The view displays the status of the connection: “Disconnected”.

Comment :


of 83

Configuration tests

Objective of the test Test case #

Creation of a PVC Imosan_ATM2IP_03 Save a configuration Imosan_ATM2IP_04 Load a configuration Imosan_ATM2IP_05

Test Creation of a PVC Reference Imosan_ATM2IP_03 Involved partners TGV Description : Creation of a PVC



Condition of test success ATM to IP converter server is running. Atm2Ip manager is running under ATM gateway and connected to the ATM to IP converter server. OPAL manager is running. OpenMux server is running. Date : 04/25/07 Version : 1.0.0.0 Reference : Author : Test Result

• From ATM to IP manager select the ATM file view.

Define a PVC (VPi = 1 and VCi = 34) And click on “Apply” button.

• Configure Opal Manager: Ouput rate at 38.014.706 bits/s and mode 204. With a PSI management (PAT and, PMT). Add an Input: PID 100 and Pmt PID 150 at 2 Mbps and define IP filter 225.4.5.6.

• Configure the H264 encoder for multicast 225.1.1.1 at 1.5Mbps.

The view displays the status of the connection: “Connected to server 200.1.1.4 – Port 4000”. A new ATM file box appears. The IP traffic is monitored on Opal Manager.There is no synchronization lost on the RTA.

Comment :


of 83

Test Save a configuration Reference Imosan_ATM2IP_04 Involved partners TGV Description : Save a configuration



Condition of test success Last test Imosan_ATM2IP_03.

Date : 04/25/07 Version : 1.0.0.0 Reference : Author : Test Result Define the file name: c:\tmp\AtmFiltersFile.txt And click on Save Button.

Check that the file is created under the folder c:\tmp.

Comment :


of 83

Test Load a configuration Reference Imosan_ATM2IP_05 Involved partners TGV Description : Load a configuration



Condition of test success Atm2Ip manager is running under ATM gateway and connected to the ATM to IP converter server.

Date : 04/25/07 Version : 1.0.0.0 Reference : Author : Test Result Select the file name: c:\tmp\AtmFiltersFile.txt from “Finder” And click on “Load” Button.

The PVC(1/34) is displayed.

Comment :


of 83

Scalability tests forecast with Thales DVB-S2/RCS GW


CPU Load Imosan_ATM2IP_06 Robustness Imosan_ATM2IP_07

Test CPU Load Reference Imosan_ATM2IP_06 Involved partners TGV Description : Creation of 1000 PVCs and Test CPU Load



Condition of test success ATM to IP converter server is running. Atm2Ip manager is running under ATM gateway and connected to the ATM to IP converter server. OPAL manager is running. OpenMux server is running with output mux rate at 80 Mbps. Date : Version : 1.0.0.0 Reference : Author : Test Result Create 1000 PVCs. Generate multicast ATM traffics for a total 35 Mbps rate. Define Ip inputs for those PVCs.

The CPU load (ATM to IP converter) shouldn’t exceed 70% and there is no memory leak. The Ip traffic is monitor on Opal Manager. There is no synchronization lost on the RTA.

Comment :


of 83

Test Robustness Reference Imosan_ATM2IP_07 Involved partners TGV Description : Creation of 1000 PVCs and Test Robustness



Condition of test success ATM to IP converter server is running. Atm2Ip manager is running under ATM gateway and connected to the ATM to IP converter server. OPAL manager is running. OpenMux server is running with output mux rate at 80 Mbps. Date : Version : 1.0.0.0 Reference : Author : Test Result Create 1000 PVCs. Generate multicast ATM traffics for a total 35 Mbps rate. Define IP inputs for those PVCs. Leave the ATM to IP converter server and client without any change during several days.

The IP traffic is monitor on Opal Manager. There is no synchronization lost on the RTA.

Comment :

6.4. BWMM, SA and SRMS Integration The following chapter describes the tests that have been performed to validate the integration of the bandwidth manager, the multiplexer and the satellite resource manager system within the IMOSAN architecture.

6.4.1.1. Test Plan The test plan includes the following tests :

o Connect/disconnect tests : Local Connection to the SRMS server


of 83

Distant Connection to the SRMS server Disconnection from the SRMS server

o Configuration tests: Configuration of the modulation table Configuration of the priority list Configuration of the IP/MAC associations

o Interface configuration tests : Configuration of the Unit Status Message interface Configuration of the RLSS interface Configuration of the SA interface

o Input Management tests Add SPT input table Stop Start Delete SPT input table Add DVB-RCS input table

o PSI Management tests IP Input and PSI tables

o SA commands tests : SetConfiguration GetConfiguration GetStatus Start Stop Change on the fly the VBR

o ACM feed back loop tests: Multicast CNI&MODCOD_RQ reception Unicast CNI&MODCOD_RQ reception

o Scalability tests : CPU Load Memory leak Response time measurement Robustness


of 83

6.4.1.2. Test environment

Figure 6.4.1.2: SRMS integration test

SRMS

Ethereal (network analyser)

EMT (Multiplexer)

FLSS BWM

MSG

UDP/IP Unit status message

MODCOD & CNI UDP/IP

IP

IP

TCP/IP TCP/IP S2 Table signalling

Input management

SA commands

NetTester (IP generator)

RTA (TS analyzer)

MPEG2-TS

ACM Feedback loop

H264 encoder

NetTester (DVB-RCS generator)

IP


of 83

6.4.1.3. Hardware Configuration • A PC server under windows 2000 with 2 adapter boards (one for data and the other for

supervision),

• A client PC under windows 2000,

• The EMT server,

• RTA (Real Time Analyzer)

• IP switches.

6.4.1.4. Software Configuration • Network analyzer (Ethereal) ,

• Adonum software (TS analyzer),

• NetTester software (IP generator).

6.4.1.5. Description of the tests


of 83

Connect/Disconnect tests


Local Connection to SRMS server Imosan_SRMS_0001 Distant Connection to SRMS server Imosan_SRMS_0002 Disconnect from SRMS server Imosan_SRMS_0003

Test Local Connection to SRMS server Reference Imosan_SRMS_0001 Involved partners TGV Description : Local Connection to SRMS server

Validated function : SRMS management


Condition of test success OPEMUX server is running. OPAL Manager is connected to OPENMUX server. SRMS server is running. SRMS client is running. Date : Version : Reference : Author : Test Result

From SRMS Manager view click on button . Or From SRMS menu select “Connect Home”

A monitor view appears and the following status bar is displayed

SRMS server is in running state and the SRMS server is connected to the BWMM.

Comment :


of 83

Test Distant Connection to SRMS server Reference Imosan_SRMS_0002 Involved partners TGV Description : Distant Connection to SRMS server




From SRMS Manager view click on button . Or From SRMS menu select “Connect” Select the SRMS server parameters:

• Server Name, • Port.

Or Select the sever from the list.

A connect to a server view is displayed

A monitor view appears and the following status bar is displayed

SRMS server is in running state and the SRMS server is connected to the BWMM.

Comment :


of 83

Test Disconnection from SRMS server Reference Imosan_SRMS_0003 Involved partners TGV Description : Disconnection from SRMS server




From SRMS Manager view click on button . Or From SRMS menu select “Disconnect”

The Main view is displayed.

Comment :


of 83

Configuration tests

Objective of the test Test case # Configuration of the modulation table Imosan_SRMS_0004 Configuration of the priority list Imosan_SRMS_0005 Configuration of the IP/MAC associations Imosan_SRMS_0006

Test Configuration of the modulation table Reference Imosan_SRMS_0004 Involved partners TGV Description : Configuration of the modulation table and available modulation



Condition of test success OPEMUX server is running. OPAL Manager is connected to OPENMUX server. SRMS server is running. SRMS client is running and is connected to SRMS server. Date : Version : Reference : Author : Test Result From Configuration menu select “Modulation Table”. Fill from each modulation the following parameters:

• State (validity of the modulation), • Frame Size, • Pilot, • Spectral efficiency, • Es/No (dB).

Save the modulation table with ModulationFile.txt name. Configure the modulator parameters:

• Roll Of factor, • Symbol Rate.

And then click on “APPLY” button.

The modulation table settings view is displayed.

Check if the file is created.

Check in registry that those parameters are created.


of 83

Comment :

Test Configuration of the priority list Reference Imosan_SRMS_0005 Involved partners TGV Description : Configuration of the priority list table



Condition of test success OPEMUX server is running. OPAL Manager is connected to OPENMUX server. SRMS server is running. SRMS client is running and is connected to SRMS server. Date : Version : Reference : Author : Test Result From Configuration menu select “Priority list”. Add a PID with the following parameters:

• Priority, • Modulation Coding, • Mac Address, • SA service Id.

Save the modulation table under Priority&ModulationList.txt name. Delete a PID and save.

The Priority list settings view is displayed.

Check if the file is created. Edit this file and check the values. Check if the PID is deleted.


of 83

Change values in the file and load it. Click on apply for initial modulation coding send to the EMT.

Check the modification values. Check on the monitor view that the modulation is affected to a PID.

Comment :


of 83

Test Configuration of the IP/MAC associations Reference Imosan_SRMS_0006 Involved partners TGV Description : Configuration of IP/MAC associations



Condition of test success OPEMUX server is running. OPAL Manager is connected to OPENMUX server. SRMS server is running. SRMS client is running and is connected to SRMS server. Date : Version : Reference : Author : Test Result From Configuration menu select “IP/Mac associations”. Add a IP/MAC association with the following parameters:

• IP address, • IP mask, • Mac Address.

Save the modulation table under AssociationIpMac.txt name. Delete an association and save. Change values in the file and load it.

The IP/Mac associations settings view is displayed.

Check if the file is created. Edit this file and check the values. Check if the association is deleted. Check the modification values.

Comment :


of 83

Interface configuration tests

Objective of the test Test case # Configuration of the Unit Status Message interface Imosan_SRMS_0007 Configuration of the RLSS interface Imosan_SRMS_0008 Configuration of the SA interface Imosan_SRMS_0009

Test Configuration of the Unit Status Message interface Reference Imosan_SRMS_0007 Involved partners TGV Description : Configuration of the Unit Status Message interface


Required test tools : Network analyzer.

Condition of test success OPEMUX server is running. OPAL Manager is connected to OPENMUX server. SRMS server is running. SRMS client is running and is connected to SRMS server. Date : Version : Reference : Author : Test Result From SRMS menu select “Unit Status interface”. Select the following parameters:

• Adapter, • Multicast IP address, • Port Number.

Click on button to apply.

Click on button to stop.

The Unit Status Msg view is displayed.

Check on the network analyzer the UDP frame sent every 500ms. Check on the network analyzer that this frame is not sent any more.

Comment :


of 83

Test Configuration of the RLSS interface Reference Imosan_SRMS_0008 Involved partners TGV Description : Configuration of the RLSS interface



Condition of test success OPEMUX server is running. OPAL Manager is connected to OPENMUX server. SRMS server is running. SRMS client is running and is connected to SRMS server. Date : Version : Reference : Author : Test Result From SRMS menu select “Unit Status interface”. Select the following parameters:

• Adapter, • Multicast IP address, • Port Number.



The RLSS settings view is displayed.

The status bar displays the running state of the Rlss.

The Rlss is stopped.

Comment :


of 83

Test Configuration of the Service Adaptation interface Reference Imosan_SRMS_0009 Involved partners TGV Description : Configuration of the SA interface



Condition of test success OPEMUX server is running. OPAL Manager is connected to OPENMUX server. SRMS server is running. MGWServices soap server is running. SRMS client is running and is connected to SRMS server. Date : Version : Reference : Author : Test Result From SRMS menu select “SA interface”. Select the following parameters:

• Adapter, • IP address, • Port Number.


Click on button to stop.

The SA Settings view is displayed.

The status bar displays the running state of the SA.

The SA is stopped.

Comment :


of 83

Input management tests

Objective of the test Test case # Add SPT input table Imosan_SRMS_0010 Stop Imosan_SRMS_0011 Start Imosan_SRMS_0012 Delete SPT input table Imosan_SRMS_0013 Add DVB-RCS input table Imosan_SRMS_0014

Test Add SPT input table Reference Imosan_SRMS_0010 Involved partners TGV Description : Add SPT input table to the BWM

Validated function : BWM management

Required test tools : OpenMux.spt file RTA is running Condition of test success OPEMUX server is running. OPAL Manager is connected to OPENMUX server. SRMS server is running. SRMS client is running and is connected to SRMS server. Date : Version : Reference : Author : Test Result From SRMS menu select “Section Files Settings”. Define parameters for the polling file SPT:

• Input Name, • Pid number, • Rate for periodical polling file.

And click “Add” button. Check on the RTA:

• The Pid’s creation, • The rate applied.

The SRMS manager monitors the new input SPT table.


of 83

Comment :

Test Stop Reference Imosan_SRMS_0011 Involved partners TGV Description : Stop the management of an input


Required test tools : OpenMux.spt file RTA is running Condition of test success Previous test : Imosan_SRMS_0010

Date : Version : Reference : Author : Test Result From SRMS manager main view select SPT input. With the right click select stop Check on the RTA:

• The PID is not managed.

The State of Pid 200 is now in stop state.


of 83

Comment :


of 83

Test Start Reference Imosan_SRMS_0012 Involved partners TGV Description : Stop the management of an input


Required test tools : OpenMux.spt file RTA is running Condition of test success Previous test : Imosan_SRMS_0011

Date : Version : Reference : Author : Test Result From SRMS manager main view select SPT input. With the right click select start Check on the RTA:

• The Pid is managed.

The State of Pid 200 is now in start state.

Comment :


of 83

Test Delete SPT input table Reference Imosan_SRMS_0014 Involved partners TGV Description : Delete SPT input table to the BWM


Required test tools : OpenMux.spt file RTA is running Condition of test success OPEMUX server is running. OPAL Manager is connected to OPENMUX server. SRMS server is running. SRMS client is running and is connected to SRMS server. Date : Version : Reference : Author : Test Result From SRMS menu select “Section Files Settings” define the Id field to 3 and click on “Delete” button. Check on the RTA:

• The Pid 200 is removed.

In the SRMS manager view, the SPT input is removed.

Comment :


of 83

Test Add DVB-RCS input table Reference Imosan_SRMS_0015 Involved partners TGV Description : Add DVB-RCS input table to the BWM


Required test tools : RTA is running NetTester generates DVB-RCS table on UDP format (refer to the data format on D06I) at 500Kbps. Condition of test success OPEMUX server is running. OPAL Manager is connected to OPENMUX server. SRMS server is running. SRMS client is running and is connected to SRMS server. Date : Version : Reference : Author : Test Result From Opal Manager menu select “Import DVB-RCS Tables” and define the parameters:

• Adapter, • Rate, • Source filter, • Destination filter, • State.

Click on “Apply” button. Check on the RTA.

In the input list view, Opal manager displays the DVB-RCS tables input.

The Pid 300 is created.

Comment : This test should be forecast with Thales DVB-S2/RCS GW


of 83

PSI commands tests

Objective of the test Test case # Ip Input and PSI task(NIT, INT/RCS, TDT, PMT, PAT, SDT) Imosan_SRMS_0016

Test Ip Input and PSI task(NIT, INT/RCS, TDT, PMT, PAT, SDT) Reference Imosan_SRMS_0016 Involved partners TGV Description : Ip Input and PSI task(NIT, INT/RCS, TDT, PMT, PAT, SDT)


Required test tools : RTA

Condition of test success OPEMUX server is running. OPAL Manager is connected to OPENMUX server. SRMS server is running. SRMS client is running and is connected to SRMS server. Date : 09/18/07 Version : 1.0.0.0 Reference : Author : Test Result Copy the openmux.nit ,openmux.rmt and openmux.mmt into the folder where is located the OpenMux.exe application. From Opal Manager, Create the PSI task with the following tables (default values) :

• TDT : 10000 ms • PMT : 400 ms • PAT : 5000 ms • SDT : 500 ms • NIT : 5000 ms

Create INT/RCS tables (default values) • INT : 1000 ms • MMT : 1000 ms • RMT : 1000 ms

And then add an Ip input.

Check the tables TDT, PMT, PAT, SDT, NIT, INT, MMT and RMT with the RTA.

Comment :


of 83

SA commands tests

Objective of the test Test case # SetConfiguration Imosan_SRMS_0017 GetConfiguration Imosan_SRMS_0018 GetStatus Imosan_SRMS_0019 Start Imosan_SRMS_0020 Stop Imosan_SRMS_0021 Change on the fly the VBR Imosan_SRMS_0022

Test SetConfiguration Reference Imosan_SRMS_0017 Involved partners TGV Description : Set the encoder Configuration


Required test tools : Condition of test success OPEMUX server is running. OPAL Manager is connected to OPENMUX server. SRMS server is running. SRMS client is running and is connected to SRMS server. Date : 09/18/07 Version : 1.0.0.0 Reference : Author : Test Result From SRMS menu select “Test Web client SA”. Define the parameter “Endpoint” for the Media Service Controller. Configure the encoder “SetMGWServicesConfig.xml” file and copy it under the folder c:/temp/ Click on “SetConfiguration” button.

The OPTIBASE encoder loads the new configuration and a green light indicates that it is done.

Comment :


of 83

Test GetConfiguration Reference Imosan_SRMS_0018 Involved partners TGV Description : Get the encoder Configuration


Required test tools :

Condition of test success Previous test: Imosan_SRMS_0017

Date : 09/18/07 Version : 1.0.0.0 Reference : Author : Test Result From “Test Web client Service Adaptation” view click on “Get Services”.

After the answer of the Media Service Controller, open the xml file “GetServices.xml” under the folder c:/temp/ and edit it with an xml editor. This file provides parameters of the SA Service as:

• ServiceId : 198.168.1.93_1, • ServiceType: Encoding, • VideoBitRate: 1500000, • Current state : playing.

SRMS manager displays those parameters for the associated PID.

Comment :


of 83

Test GetStatus Reference Imosan_SRMS_0019 Involved partners TGV Description : Get Status of a service in the encoder




Date : 09/18/07 Version : 1.0.0.0 Reference : Author : Test Result From “Test Web client Service Adaptation” view select “Get Status”, Define the service Id and click on “Send Command”

After the answer of the Media Service Controller, open the xml file “GetStatus.xml” under the folder c:/temp/ and edit it with an xml editor. This file provides parameters of the SA Service as:

• ServiceId : 198.168.1.93_1, • Current state : playing.

Comment :


of 83

Test Stop Reference Imosan_SRMS_0020 Involved partners TGV Description : Stop a encoding service




Date : 09/18/07 Version : 1.0.0.0 Reference : Author : Test Result From “Test Web client Service Adaptation” view select “Stop”, Define the service Id and click on “Send Command” From “Test Web client Service Adaptation” view select “Get Status”, And click on “Send Command”


• ServiceId : 198.168.1.93_1, • Current state : stopped.

Comment :


of 83

Test Start Reference Imosan_SRMS_0021 Involved partners TGV Description : Get the encoder Configuration




Date : 09/18/07 Version : 1.0.0.0 Reference : Author : Test Result From “Test Web client Service Adaptation” view select “Start”, Define the service Id and click on “Send Command” From “Test Web client Service Adaptation” view select “Get Status”, And click on “Send Command”


• ServiceId : 198.168.1.93_1, • Current state : playing.

Comment :


of 83

Test Change on the fly theVBR Reference Imosan_SRMS_0022 Involved partners TGV Description : Change on the fly the video Bit Rate of a service




Date : 09/18/07 Version : 1.0.0.0 Reference : Author : Test Result From “Test Web client Service Adaptation” view select “Apply”, Define the service Id and the video bit rate and then click on “Send Command” After the answer of the Media Service Controller, click on “Get Services”.

After the answer of the Media Service Controller, open the xml file “GetServices.xml” under the folder c:/temp/ and edit it with an xml editor. This file provides parameters of the SA Service as:

• ServiceId : 198.168.1.93_1, • ServiceType: Encoding, • VideoBitRate: 1000000, • Current state : playing.

SRMS manager displays those parameters.

Comment :


of 83

ACM feedback loop tests


Multicast CNI&MODCOD_RQ reception Imosan_SRMS_0023 Unicast CNI&MODCOD_RQ reception Imosan_SRMS_0024

Test Multicast CNI&MODCOD_RQ reception Reference Imosan_SRMS_0023 Involved partners TGV Description : Multicast CNI&MODCOD_RQ reception


Required test tools : NetTester is generating multicast Ip traffic (225.1.2.3)

Condition of test success OPEMUX server is running. OPAL Manager is connected to OPENMUX server. SRMS server is running. SRMS client is running and is connected to SRMS server. An Ip Input is declared in Opal Manager with the PID 300, bitrate 400 Kbps and Ip filter 225.1.2.3. Date : Version : Reference : Author : Test Result Define the RLSS interface parameters:

• Adapter : physical [email protected] • Multicast Ip address : 224.0.0.1 • Port Number: 8400.

Click on “Create” button. From configuration menu, select “Priority List” and configure a service as:

• PID: 300, • Priority: 20, • Modulation: QPSK 1/2 • MAC @: 00-E0-33-43-05-07, • No SA ServiceId.

Click on “Save” and “Apply “button. Configure the ACM feedback loop with the parameters:

• Ip Server:Port: 224.0.0.1:8400, • Mac Address: 00:E0:33:43:05:07.

SRMS is ready to receive CNI&MODCOD per Satellite terminal. The monitoring SRMS manager displays:

QPSK ½ and CNI = 0. The monitoring SRMS manager displays:


of 83

Reception of an ACM request from the satellite terminal. 8PSK ¾ and CNI = 125.

Comment :

Test Unicast CNI&MODCOD_RQ reception Reference Imosan_SRMS_0024 Involved partners TGV Description : Unicast CNI&MODCOD_RQ reception


Required test tools : NetTester is generating multicast Ip traffic (225.1.2.3)

Condition of test success OPEMUX server is running. OPAL Manager is connected to OPENMUX server. SRMS server is running. SRMS client is running and is connected to SRMS server. An Ip Input is declared in Opal Manager with the PID 300, bitrate 400 Kbps and Ip filter 225.1.2.3. Date : Version : Reference : Author : Test Result Define the RLSS interface parameters:

• Adapter : physical [email protected] • Unicast Ip address : 200.1.1.2 • Port Number: 5000.

Click on “Create” button. From configuration menu, select “Priority List” and configure a service as:

• PID: 300, • Priority: 20, • Modulation: QPSK 1/2 • MAC @: 00-E0-33-43-05-07, • No SA ServiceId.

Click on “Save” and “Apply “button. Configure the ACM feedback loop with the parameters:

• Ip Server:Port: 200.1.1.2:5000,

SRMS is ready to receive CNI&MODCOD per Satellite terminal.

The monitoring SRMS manager displays:

QPSK ½ and CNI = 0.


of 83

• Mac Address: 00:E0:33:43:05:07. Reception of an ACM request from the satellite terminal.

The monitoring SRMS manager displays:

QPSK 8/9 and CNI = 87.

Comment : Noise is added to the modulation to get new value of CNI measurement and modulation request.


of 83

Scalability tests


CPU Load Imosan_SRMS_0025 Memory leak Imosan_SRMS_0026 Response time measurement Imosan_SRMS_0027 Robustness Imosan_SRMS_0028

Test CPU Load Reference Imosan_SRMS_0025 Involved partners TGV Description : CPU Load



Condition of test success OPEMUX server is running. OPAL Manager is connected to OPENMUX server. SRMS server is running. MGWServices soap server is running. SRMS client is running and is connected to SRMS server. Date : Version : Reference : Author : Test Result Reception of ACM requests from a large number of terminal. Some constraint:

• 2 PIDs per terminal, • UDP format size is 1500 bytes, • CNI measurement per terminal is 8

bytes. It’s included CNI&MODCOD and MAC@.

The CPU load shouldn’t exceed 70%.

Comment : This test is forecasted with Thales DVB-S2/RCS GW


of 83

Test Memory leak Reference Imosan_SRMS_0026 Involved partners TGV Description : Memory leak


Required test tools : Task manager.

Condition of test success OPEMUX server is running. OPAL Manager is connected to OPENMUX server. SRMS server is running. MGWServices soap server is running. SRMS client is running and is connected to SRMS server. Date : Version : Reference : Author : Test Result Reception of ACM requests from a large number of terminal. Some constraint:



There is no memory leak and SRMS is working properly.



of 83

Test Response time measurement Reference Imosan_SRMS_0027 Involved partners TGV Description : Response time measurement



Condition of test success OPEMUX server is running. OPAL Manager is connected to OPENMUX server. The SRMS server is stopped. Define the registry Key “ResponseTimeMeasurement” to 1000. Start the SRMS server. MGWServices soap server is running. SRMS client is running and is connected to SRMS server. Date : Version : Reference : Author : Test Result Reception of ACM requests from a large number of terminal. Some constraint:



Check is the “ResponseTimeMeasurement.txt” is created.Define the latency from the start time (CNI measurement received) and the end time (S2 table sent to the EMT).



of 83

Test Robustness Reference Imosan_SRMS_0028 Involved partners TGV Description : Robustness



Condition of test success OPEMUX server is running. OPAL Manager is connected to OPENMUX server. SRMS server is stopped. Define the registry Key “ResponseTimeMeasurement” to 0 (no measurement). Start the SRMS server. MGWServices soap server is running. SRMS client is running and is connected to SRMS server. Date : Version : Reference : Author : Test Result Emulate ACM requests from a large number of terminals. Some constraint:



Leave the SRMS server and client without any change during several days.

The CPU load shouldn’t exceed 70% and there is no memory leak. SRMS Client and Manager are working properly.



of 83

6.5. ACM Feed Back Loop Integration The integration of the ACM feedback loop into the IMOSAN test platform required the following four steps:

- The first step consisted on retrieving the SNIR value from the test receiver MIB (R&S equipment) (see 6.5-a and Figure 6.5-b). Thus, we launched our software which sent SNMP requests and received SNMP responses from the MIB. By checking the output of our module we verified that we received the good values.

6.5-a: Screen shot of the test receiver MIB

R&S Test Receiver

CNI Reportingmodule

MIB

SNMP Request (SNIR, …)

SNMP Response (SNIR:value, ...)

1

2

3 Optimal MODCOD

6.5-b: Necessary operations to deduce the optimal MODCOD


of 83

- The second step consisted to verify our interaction with the SRMS. This test was validated by introducing a benchmark test that modified automatically the requested MODCOD values. This permitted checking that the SRMS received the good values and reacted well to these values. This also permitted to tune a number of parameters such as the time interval between to MODCOD requests.

- The third step consisted to check the whole chain. Thus, we connected the SRMS and the

test receiver into the same network. Then, we launched our module. By varying artificially the noise level into the modulator, we validated the whole chain in the same network.

6.5-c: ACM feedback loop module

- The fourth step consisted to introduce the satellite emulator to validate the whole chain.


of 83

6.5-d: Detailed topology

These tests allowed tuning some key parameters into our module while enabled validating our module in almost-real conditions.

Table 1: Summary of integration Steps of integration Validation status CNI Reporting module with R&S test terminal ok CNI Reporting module with SRMS ok whole chain ok whole chain satellite emulator ok

6.6. SA module Integration During the SA module integration the following tests were performed:

6.6.1. Web Service tests using Internet Explorer browser. First test performed on Web Service interface of the Service Adaptation platform was accessing the interface using IE browser. As depicted in Figure 6.6.1, the platform exposes the interface methods and their brief descriptions.


of 83

Figure 6.6.1: Web Service interface on IE.

Next, by invoking the Web Service methods, some of the platform functionality may be controlled using only IE.

Test description Comments Pass 1

Receiving current configuration information using GetServices method.

√

2

Receiving current status information using GetServices method.

√

3

Sending command to the platform using Command method.

√

Table 6.6.1: Web Service tests using Internet Explorer browser.

6.6.2. Web Service tests using Test Application


of 83

A special test application has been developed to allow full control over the platform and simulate the SRMS behavior. There are few special views that filter the data provided by the service and present the information to the user. A first one provides all the data in the XML format.

Figure 6.6.2-a: Web Service tests using Test Application – XML view.

The second one, as shown on the Figure 6.6.2-b provides only high level data to the user.


of 83

Figure 6.6.2-b. Web Service tests using Test Application - Main View.

6.6.3. Configuration using test application Next step was accessing the platform over SOAP protocol using a test application.

Test description Comments Pass 1

Configuration of the H.264 encoding services.

√

2

Retrieving configuration status information using GetServices method.

√

3

Sending Start command to the platform using Command method.

√

3

Sending GetStatus command to the platform using Command method.

√

Table 6.6.3-a: Configuration tests. Table shows a configuration data that has been used for the above tests.


of 83

<MGW_SERVICES xsi:schemaLocation="http://www.optibase.com/BTV/MGW ./MGW_Services.xsd" xmlns="http://www.optibase.com/BTV/MGW" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:epg="http://www.optibase.com/BTV/MGW_EPG"> <Service Version="1.55"> <ServiceId>200.100.100.101_1</ServiceId> <SourceParams> <Live> <Video> <VideoType>Composite</VideoType> <ColorSystem>PAL</ColorSystem> </Video> <Audio> <SampleRate>48000</SampleRate> <Analog> <Interface>1</Interface> <AudioInterfaceType>UnBalanced</AudioInterfaceType> </Analog> </Audio> </Live> </SourceParams> <ProcessingParams> <InterfaceNo>1</InterfaceNo> <TransportStream> <Program> <ElementaryStreams> <ElementaryStream> <Type>Video</Type> <VideoParams> <VideoBitRate>1500000</VideoBitRate> <VideoResolution HorizontalSize="720" VerticalSize="576"/> </VideoParams> </ElementaryStream> </ElementaryStreams> <ElementaryStreams> <ElementaryStream> <Type>Audio</Type> <AudioParams> <AudioCoding>MPEG1 Layer 2</AudioCoding> <AudioMode>Stereo</AudioMode> <SampleRate>48000</SampleRate> <AudioBitrate>128000</AudioBitrate> </AudioParams> </ElementaryStream> </ElementaryStreams> </Program> </TransportStream> </ProcessingParams> <TargetParams> <StreamingProtocol_IP> <IP_Out> <NetInterfaceIndex>1</NetInterfaceIndex> <IP>225.1.1.1</IP> <Port>11111</Port> <PacketSize>1316</PacketSize> <TTL>10</TTL> </IP_Out> </StreamingProtocol_IP> </TargetParams> </Service> </MGW_SERVICES>

Table 6.6.3-b: Platform configuration XML. Table 6.6.3-c shows a control message that has been used in order to launch the service.


of 83

MGW_SERVICES xsi:schemaLocation="http://www.optibase.com/BTV/MGW ./MGW_Services.xsd" xmlns="http://www.optibase.com/BTV/MGW" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:epg="http://www.optibase.com/BTV/MGW_EPG"> <Service Version="1.55"> <ServiceControl Version="1.44" xmlns="http://www.optibase.com/BTV/MGW_SC"> <ServiceId>200.100.100.101_1</ServiceId> <Command> <CommandCode>START</CommandCode> </Command> </ServiceControl> </Service> </MGW_SERVICES>

Table 6.6.3-c: Start command XML.

Table 6.6.3-d describes a message used for applying video bitrate change on the fly parameter to the platform.

<MGW_SERVICES xsi:schemaLocation="http://www.optibase.com/BTV/MGW ./MGW_Services.xsd" xmlns="http://www.optibase.com/BTV/MGW" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:epg="http://www.optibase.com/BTV/MGW_EPG"> <Service Version="1.55"> <ServiceId>200.100.100.101_1</ServiceId> <ProcessingParams> <InterfaceNo>1</InterfaceNo> <TransportStream> <Program> <ElementaryStreams> <ElementaryStream> <Type>Video</Type> <VideoParams> <VideoBitRate>1000000</VideoBitRate> </VideoParams> </ElementaryStream> </ElementaryStreams> </Program> </TransportStream> </ProcessingParams> <ServiceControl Version="1.44" xmlns="http://www.optibase.com/BTV/MGW_SC"> <ServiceId>200.100.100.101_1</ServiceId> <Command> <CommandCode>APPLY</CommandCode> </Command> </ServiceControl> </Service> </MGW_SERVICES>

Table 6.6.3-d Bitrate change on the fly XML.

The results of the above operation are shown in the Figure 6.6.3-e:


of 83

Figure 6.6.3-e: Bit rate change on the fly graph.

6.6.4. Configuration and control using SRMS After all the tests described above have been performed, a Service Adaptation platform was put online, allowing SRMS access. All tests that have been done using the test application were repeated under SRMS control. Positive results indicated successful integration of the SA platform into IMOSAN architecture.

6.7. System Complete Integration

6.7.1. Integration Platform Overall Description As aforementioned, the integration process took part in the premises of partner CNES, in Toulouse. The new IMOSAN modules were integrated around the already existing and fully functional Thales A9780 DVB-S2/DVB-RCS Gateway. As shown in Figure 6.7.1-a, the IMOSAN Forward Link (FL), comprising of the SRMS, the BWMM and the DVB-S2 Modulator was installed “in parallel” with the existing A9780 FLSS (Forward Link SubSystem). The proper attachment points within the Gateway were identified, where the new modules were connected. The SRMS and the BWMM, although being separate software components, co-exist in the same hardware module. MODCOD commands do not follow a separate path, they are issued by the SRMS to the BWMM, and the latter includes them in the Transport Stream to be received and decoded by the ACM Modulator.


of 83

Figure 6.7.1-a. Simplified block diagram of current network configuration in CNES lab. IMOSAN new modules are marked in yellow.

The system was integrated in logical stages, having as a core the existing operational network (i.e. the A9780 Gateway, the satellite emulator and the DVB-S2/RCS Gateway. The integration proceeded in steps, each time verifying the proper operation of the current configuration. The following steps were taken:

1. Connection of the videoconferencing server and client 2. Connection of the Service Adaptation modules and the H.264 decoder 3. Integration of the DVB-S2 Modulator and Test Receiver (separately) 4. Integration of the BWMM and SRMS 5. Integration of the BWMM/SRMS and the DVB-S2 Modulator 6. Integration of the CNI report module and realization of the ACM feedback loop 7. Interconnection of the IMOSAN FL with the Gateway 8. Overall tests and validation

Figure 6.7.1-b shows in detail the topology of the current configuration. A coherent private IP addressing scheme was adopted, to comply with the addressing rules of the Gateway. The proper tap point at which the IMOSAN FL should be attached to the Gateway was identified by the manufacturer (TASF) to be the interface between the PEP (Performance Enhancement Proxy) and the ACME (Encapsulator and Multiplexer). As this interface is an optical ATM one, an optical tap-splitter was used, along with an ATM-to-IP converter/filter developed by TGV. Special attention was paid so as not to interrupt the operation of the Gateway. The converter was configured to trap the multicast H.264 traffic generated by the SA and passing through the Gateway, and to forward it to the BWMM.


of 83

At the satellite node part (connected to the Gateway and the new FL via the Satellite Emulator), it was decided that a pair of receivers is used, one for receiving the data and the other for stream and RF analysis. The latter provides the CNI reporting module with a CNI reception report, which is then dispatched to the SRMS via the RCS return link. Finally, a H.264 decoding module is used to display the multicast stream produced by the SA and transmitted via the IMOSAN FL.


of 83

Figure 6.7.1-b: Detailed topology of the current configuration


of 83

6.7.2. Integration platform Tests and Results After performing the modules integration tests, the system overall tests including the Emulator Channel Propagation are performing. The objectives of the tests over the complete integration platform are to evaluate the system running triple play services, taking account of the space environment, and the modifications of MODCOD requested by the Test Receiver. The triple play services consist of using a video service, a VoIP service and a conference service. At this step of the development, two services are performing using the CCM mode: the conference service and the VoIP service, i.e the MODCOD applied to these two services are constant. These two services are handled by the Gateway FLSS. During the video broadcast, the simulation of the ACM mode is applied to the video service. The video service is handled by the IMOSAN FLSS. The quality of a service should not be disturbed by the others services, even during MODCOD modifications requested by the DVB-S2 Test Receiver. The results are evaluated in relation ship with the video quality displayed on the screen of the H264 STB and on the videoconference system by the users. Losses of packets during a MODCOD change have a degraded effect on the video. The following table provides the main tests performed on the complete integration platform:

N° Test description Comments Pass1 Perform a Web and Video conferencing √ 2 Perform a phone call √

3 Broadcast a video service without MODCOD modification √

4 Perform triple play services with constant MODCOD

5 Broadcast a video service by switching the MODCOD (ACM mode simulation)

6 Perform triple play services by switching the MODCOD on video service

Table 6.7.2: list of tests performed on the complete integration platform


of 83

6.8. WiFi/WiMAX access network integration The WiFi/WiMAX access network has been developed in Athens in the premises of partner DEM. It includes a WiMAX infrastructure for the long-range terrestrial interconnection, and a WiFi hot-spot for the local redistribution of services around the WiMAX Subscriber Unit (SU). Although on-air tests with the IMOSAN platform have not been carried out yet, the integration has been partially pre-verified via the interconnection of the WiFi/WiMAX infrastructure with an interactive satellite terminal utilising a commercial connection (HellasSat-Net). Local redistribution of services stemming from the satellite has been verified. The configuration of the integrated terrestrial access network (figure 6.8) shows how end-users have the ability to receive the triple play services (Interactive services, Television, VoIP Telephone) of the satellite bouquet.

Figure 6.8: Integration of WiMAX/WiFi access network An IP Gateway has been included as a router between the terrestrial network and the satellite modules. Since two satellite interfaces will be used (a test receiver for receiving the downlink data from the IMOSAN FL and an interactive DVB-S2/RCS terminal to communicate with the A9780 Gateway), the router takes the decision which packet should forwarded through


of 83

the WiMAX link and which through the DVB-S2/RCS. The downlink traffic is routed via the WiMAX link. The BU (Base Unit) forwards the traffic to the WiMAX SU (Subscriber Unit). Afterwards, the wireless 802.11 router which has been interconnected next to the WiMAX SU collects the traffic and sends it to each hot-spot user. Three scenarios of triple play enabled users have been realised: 1. A client with a Desktop pc and a separate IP phone which are connected via an Ethernet switch to each other and through a wireless 802.11 SA (Station Adapter) to the WiFi router. 2. A laptop computer with an embedded 802.11 adapter, having a software ip phone for the VoIP service. 3. A smartphone with a WiFi SA. Proper connectivity was tested with all three end user terminals via two types of services a) Web access via the satellite to a remote (public) Web server and b) Voice connections to a remote VoIP Gateway, interfaced to the public PSTN Network.

7. Conclusion As described in this document, the integration activities performed in CNES premises by the partners responsible of each corresponding module, have allowed the IMOSAN engineers to validate the expected behavior of each group of interconnected modules, and the test platform as a whole. The complete integration tests have also demonstrated that the IMOSAN platform can now deliver triple play services using the ACM feedback loop and the real-time cross-layer adaptation, without disturbing the nominal functioning of the A9780 Gateway.

8. Reference [1] FP6 IMOSAN Deliverable D10-I: « Development of ACM feedback loop mechanism - I ». available on http://www.ist-imosan.gr/ (December 2006)

integration of systems and components - media networks laboratory

Documents