![SATLIFE-IST-1-507675 D424 DRAFT Real System Trials Test ...€¦ · Devices Design Report. [5] SATLIFE D322, DVB-RCS regenerative (and transparent) System Services Provision and Devices](https://static.fdocuments.net/doc/165x107/603cc37853f7720b3950deca/satlife-ist-1-507675-d424-draft-real-system-trials-test-devices-design-report.jpg)
SATLIFE-IST-1-507675 D422 Real System Trials Test Procedures · 2007. 1. 22. ·...
151
SATLIFE-IST-1-507675 D422 Real System Trials Test Procedures Contractual Date of Delivery to the CEC:01/04/06 Actual Date of Delivery to the CEC: 30/09/06 Author(s): José Antonio Guerra, Juan R. López, Miriam Catalán, Isaac Moreno, Fernando Vallejo, Elisa Callejo, Carlos Miguel, Victor Huertas, Lorena Albiol, Francisco Recacha, David Douglas, Neil Musgrave, Jose A. Torrijos, Jaime Ruiz, Carlos Gil, Antonio J. Sánchez. Participant(s): AAS-E, AAS-F, EMS, HSA, NERA, SHIRON, THALES, TID, UOS, UPM. Workpackage: WP4200 Est. person months: 12 Security: PU Nature: R Version: 1.2 Total number of pages: 151 Abstract: This document provides the specification of the SATLIFE test set-up and the definition of the procedures for the real system to validate the DVB-RCS subsystem and the new services. Therefore, the goal of this document is to establish a clear guideline with the procedures that will be needed to certify the whole design and development with the real system during the in-orbit tests phase. This document covers the test procedures for the transparent and regenerative platforms, additionally, it is described the test platform used in each scenario, their participants and their function and responsibility. The real system trials test results and the integration conclusions will be detailed in document D424. Keyword list: DVB-RCS, Satellite network, Multimedia, Broadcasting, Interactive services, Video on Demand, QoS in satellite access
Transcript of SATLIFE-IST-1-507675 D422 Real System Trials Test Procedures · 2007. 1. 22. ·...
SATLIFE-IST-1-507675
D422
Real System Trials Test Procedures
Contractual Date of Delivery to the CEC:01/04/06
Actual Date of Delivery to the CEC: 30/09/06
Author(s): José Antonio Guerra, Juan R. López, Mir iam Catalán, Isaac Moreno, Fernando Vallejo, Elisa Callejo, Car los Miguel, Victor Huertas, Lorena Albiol, Francisco Recacha, David Douglas, Neil Musgrave, Jose A. Torr ijos, Jaime Ruiz, Car los Gil, Antonio J. Sánchez.
Par ticipant(s): AAS-E, AAS-F, EMS, HSA, NERA, SHIRON, THALES, TID, UOS, UPM.
Workpackage: WP4200
Est. person months: 12
Secur ity: PU
Nature: R
Version: 1.2
Total number of pages: 151
Abstract: This document provides the specification of the SATLIFE test set-up and the definition of the procedures for the real system to validate the DVB-RCS subsystem and the new services. Therefore, the goal of this document is to establish a clear guideline with the procedures that will be needed to certify the whole design and development with the real system during the in-orbit tests phase. This document covers the test procedures for the transparent and regenerative platforms, additionally, it is described the test platform used in each scenario, their participants and their function and responsibility. The real system trials test results and the integration conclusions will be detailed in document D424. Keyword list: DVB-RCS, Satellite network, Multimedia, Broadcasting, Interactive services, Video on Demand, QoS in satellite access
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
2 / 151
CHANGE RECORD
VERSION DATE AUTHOR CHANGE
Draft v0.1 05/04/2006 SATLIFE PARTNERS First draft with Index. Draft v0.2 05/05/2006 SATLIFE PARTNERS Template adaptation, test template. Draft v1.0 31/05/2006 SATLIFE PARTNERS Indra’s chapters added.
Alcatel Alenia Space Spain’s chapters added. TID’s chapters added. UPM’s chapters added. EMS’s chapters added.
Draft v1.1 30/06/2006 SATLIFE PARTNERS Executive summary updated. Management chapter updated. Security chapter updated. EMS test platform updated. Multiconference tests updated. Home gateway, Digital TV and SW download test added. Risks and contingency plans section added. Test matrix has been moved to DE442 to include the tests results
v1.2 30/09/2006 SATLIFE PARTNERS Nomadic terminal test cases using regenerative platform Partners and equipment involved in test cases Low cost terminal integration updated Hispasat transparent platform description. Add GMM Management test procedure Update multicast, Internet access, SIP and H.323 test setup
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
3 / 151
TABLE OF CONTENTS
1. EXECUTIVE SUMMARY.............................................................................................................9
2. REFERENCES..............................................................................................................................11
3. ABBREVIATIONS.......................................................................................................................12
4. ORGANIZATION OF THE VALIDATION PROCESS..........................................................15
4.1 TEST NUMBERING ....................................................................................................................15 4.2 TEST STRUCTURE.....................................................................................................................15 4.3 TEST BED DESCRIPTION ............................................................................................................15
5. TEST ARCHITECTURE.............................................................................................................16
5.1 TEST ENVIRONMENT.........................................................................................................16 5.1.1 Hispasat Transparent Platform......................................................................................16 5.1.2 AmerHis Regenerative Platform.....................................................................................18
5.1.2.1 Equipment.............................................................................................................................................................. 18 5.1.2.2 Software tools........................................................................................................................................................ 19
5.2 PARTICIPANTS....................................................................................................................23
6. TEST SCENARIOS DESCRIPTION .........................................................................................24
6.1 LOGICAL LAYOUT..............................................................................................................24 6.2 NETWORK LAYOUT ...........................................................................................................26 6.3 CONFIGURATION................................................................................................................26
6.3.1 Service Configuration.....................................................................................................27 6.3.2 VSN Configuration..........................................................................................................27
6.4 TIME AND FREQUENCY TIMESLOT ASSIGNMENT .....................................................28 6.4.1 OBP Configuration.........................................................................................................28 6.4.2 Routes..............................................................................................................................30
7. TRANSPARENT PLATFORM TEST PROCEDURES...........................................................31
7.1 NOMADIC TERMINAL INTEGRATION ............................................................................31 7.1.1 Test Platform...................................................................................................................31 7.1.2 Expected Schedule...........................................................................................................32 7.1.3 Technical requirements...................................................................................................32 7.1.4 Test procedures for satellite access and physical layer tests..........................................32
7.1.4.1 Acquisition of Satellite .......................................................................................................................................... 33 7.1.5 Test procedures for interoperability ...............................................................................33
7.1.5.1 Forward Link Acquisition...................................................................................................................................... 33 7.1.5.2 Receive Sync State................................................................................................................................................. 33 7.1.5.3 Ready for Fine Sync............................................................................................................................................... 34 7.1.5.4 Fine Sync State...................................................................................................................................................... 35 7.1.5.5 Application Testing................................................................................................................................................ 36
8. RENENERATIVE PLATFORM TEST PROCEDURES.........................................................39
8.1 MANAGEMENT....................................................................................................................39
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
4 / 151
8.1.1 Test Platform...................................................................................................................39 8.1.2 Expected Schedule...........................................................................................................40 8.1.3 Technical requirements...................................................................................................41 8.1.4 Test procedures...............................................................................................................41
8.1.4.1 Multicast Routes Management............................................................................................................................... 41 8.1.4.2 Terminal Management ........................................................................................................................................... 41 8.1.4.3 GMM Management................................................................................................................................................ 42
8.2 SECURITY .............................................................................................................................43 8.2.1 Test Platform...................................................................................................................44 8.2.2 Expected Schedule...........................................................................................................46 8.2.3 Technical requirements...................................................................................................46 8.2.4 Test procedures...............................................................................................................46
8.2.4.1 RCST authentication procedure............................................................................................................................. 46 8.2.4.2 RSGW authentication ............................................................................................................................................ 47
8.3 MULTICAST TRAFFIC.........................................................................................................48 8.3.1 Test Platform...................................................................................................................48 8.3.2 Expected Schedule...........................................................................................................49 8.3.3 Technical requirements...................................................................................................49 8.3.4 Test procedures...............................................................................................................49
8.3.4.1 RSGW Multicast reception.................................................................................................................................... 49 8.3.4.2 RSGW Multicast forwarding towards Internet....................................................................................................... 50
8.4 INTERNET ACCESS.............................................................................................................52 8.4.1 Test Platform...................................................................................................................52 8.4.2 Expected Schedule...........................................................................................................53 8.4.3 Technical requirements...................................................................................................53 8.4.4 Test Procedures...............................................................................................................53
8.4.4.1 Internet service....................................................................................................................................................... 53 8.5 INTRANET ACCESS.............................................................................................................55
8.5.1 Test Platform...................................................................................................................55 8.5.2 Expected schedule...........................................................................................................56 8.5.3 Technical requirements...................................................................................................56 8.5.4 Test Procedures...............................................................................................................56
8.5.4.1 Intranet service....................................................................................................................................................... 56 8.6 SIP...........................................................................................................................................57
8.6.1 Test Platform...................................................................................................................57 8.6.2 Expected schedule...........................................................................................................58 8.6.3 Technical requirements...................................................................................................58 8.6.4 Test Procedures...............................................................................................................59
8.6.4.1 SIP internal calls.................................................................................................................................................... 59 8.6.4.2 SIP external calls to the ISDN ............................................................................................................................... 60 8.6.4.3 SIP external calls to the Internet ............................................................................................................................ 61 8.6.4.4 SIP calls with NATed users................................................................................................................................... 62
8.7 H.323 ENHANCEMENTS.....................................................................................................63 8.7.1 Test Platform...................................................................................................................63 8.7.2 Expected schedule...........................................................................................................64 8.7.3 Technical requirements...................................................................................................64 8.7.4 Test procedures...............................................................................................................64
8.7.4.1 H.323 calls with NATed users............................................................................................................................... 64
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
5 / 151
8.7.4.2 H.323 call to external ITSP.................................................................................................................................... 65 8.7.4.3 H.323 calls using GK Proxy Mode........................................................................................................................ 66
8.8 VIDEO ON-DEMAND...........................................................................................................68 8.8.1 Test Platform...................................................................................................................68 8.8.2 Expected schedule...........................................................................................................69 8.8.3 Technical requirements...................................................................................................69 8.8.4 Test procedures...............................................................................................................69
8.8.4.1 Browse the web server searching a content............................................................................................................ 69 8.8.4.2 Selecting a content and start a new VOD session .................................................................................................. 70 8.8.4.3 User Video Operations........................................................................................................................................... 70
8.9 NEAR VIDEO ON-DEMAND...............................................................................................72 8.9.1 Test Platform...................................................................................................................72 8.9.2 Expected schedule...........................................................................................................73 8.9.3 Technical requirements...................................................................................................73 8.9.4 Test procedures...............................................................................................................73
8.9.4.1 Start a new NVOD session..................................................................................................................................... 73 8.9.4.2 Selecting a content and join to a NVOD session.................................................................................................... 74 8.9.4.3 Leave from a NVOD session ................................................................................................................................. 75 8.9.4.4 Stop the NVOD session ......................................................................................................................................... 76
8.10 STREAMING .........................................................................................................................77 8.10.1 Test Platform...................................................................................................................77 8.10.2 Expected schedule...........................................................................................................78 8.10.3 Technical requirements...................................................................................................79 8.10.4 Windows Media test procedures.....................................................................................79
8.10.4.1 On-demand publishing points................................................................................................................................ 79 8.10.4.2 Multicast publishing points.................................................................................................................................... 80 8.10.4.3 Multi-bitrate unicast............................................................................................................................................... 81
8.10.5 Real Networks test procedures........................................................................................83 8.10.5.1 Unicast with stored files......................................................................................................................................... 83 8.10.5.2 Streaming video to more than one person.............................................................................................................. 84
8.10.6 Darwin test procedures...................................................................................................85 8.10.6.1 Unicast with stored files......................................................................................................................................... 85
8.10.7 Telefónica I+D test procedures......................................................................................86 8.10.7.1 Unicast with stored files......................................................................................................................................... 86 8.10.7.2 Multicast with stored files...................................................................................................................................... 87
8.11 E-LEARNING ........................................................................................................................88 8.11.1 Test Platform...................................................................................................................88
8.11.1.1 Tests Setup............................................................................................................................................................. 89 8.11.2 Expected schedule...........................................................................................................89 8.11.3 Technical requirements...................................................................................................89 8.11.4 Test procedures...............................................................................................................89
8.11.4.1 Tele-service: Live Events/Courses Tests ............................................................................................................... 90 8.11.4.2 Tele-service: Deferred Events/Courses Tests......................................................................................................... 91 8.11.4.3 Tele-service: On-Demand Express Tests............................................................................................................... 92 8.11.4.4 Tele-service: On-Demand Multimedia Repository Tests....................................................................................... 93 8.11.4.5 Supplementary service: Multi-Platform Tests........................................................................................................ 93 8.11.4.6 Supplementary service: Low interactivity service based on integrated Chat service Tests.................................... 94 8.11.4.7 Supplementary service: Simultaneous Translation Tests & Multilingual Contents Tests..................................... 95 8.11.4.8 Supplementary service: Synchronised content presentation and information downloading Tests ......................... 95
8.12 MULTICONFERENCE..........................................................................................................96 8.12.1 Expected schedule...........................................................................................................96
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
6 / 151
8.12.2 Technical requirements...................................................................................................97 8.12.3 Test procedures...............................................................................................................97
8.12.3.1 Mesh Mode Multiconference................................................................................................................................. 97 8.12.3.2 Star Mode Multiconference ISDN/PSTN Connectivity ........................................................................................ 98 8.12.3.3 Star Mode Multiconference Internet Connectivity.............................................................................................. 100 8.12.3.4 Star Mode Multiconference ................................................................................................................................. 102 8.12.3.5 Six-user star multiconference............................................................................................................................... 104 8.12.3.6 Multiconference with NAT`s users...................................................................................................................... 106
8.13 NOMADIC TERMINAL INTEGRATION ..........................................................................107 8.13.1 Test Platform.................................................................................................................107 8.13.2 Expected Schedule.........................................................................................................108 8.13.3 Technical requirements.................................................................................................108 8.13.4 Test procedures for interoperability .............................................................................109
8.13.4.1 Logon................................................................................................................................................................... 109 8.13.4.2 Multicast Transmission........................................................................................................................................ 109 8.13.4.3 IP Pinging ............................................................................................................................................................ 110 8.13.4.4 FTP File transfer .................................................................................................................................................. 110 8.13.4.5 Web Browsing ..................................................................................................................................................... 111
8.14 LOW-COST TERMINAL INTEGRATION.........................................................................112 8.14.1 Test platform.................................................................................................................112 8.14.2 Expected schedule.........................................................................................................112 8.14.3 Technical requirements.................................................................................................112 8.14.4 Test procedures.............................................................................................................112
8.14.4.1 Low cost terminal interoperability ....................................................................................................................... 112 8.15 MIDDLEWARE ...................................................................................................................114
8.15.1 Test Platform.................................................................................................................114 8.15.2 Expected schedule.........................................................................................................115 8.15.3 Technical requirements.................................................................................................115 8.15.4 Test procedures.............................................................................................................115
8.15.4.1 Middleware in a VOD application STLF_IO_DEV_MID................................................................................... 115 8.15.4.2 Middleware in a web browser application ........................................................................................................... 117 8.15.4.3 Middleware in a multicast TV application........................................................................................................... 118
8.16 ADSL & SATELLITE INTERNETWORKING...................................................................119 8.16.1 Test Platform.................................................................................................................119 8.16.2 Expected schedule.........................................................................................................120 8.16.3 Technical requirements.................................................................................................120 8.16.4 Test procedures.............................................................................................................121
8.16.4.1 PPPoE single-user scenario.................................................................................................................................. 121 8.16.4.2 PPPoE multi-user scenario................................................................................................................................... 122 8.16.4.3 Routing single-user scenario................................................................................................................................ 123 8.16.4.4 Routing multi-user scenario................................................................................................................................. 124
8.17 HOME GATEWAY ..............................................................................................................125 8.17.1 Test Platform.................................................................................................................125 8.17.2 Expected schedule.........................................................................................................126 8.17.3 Technical requirements.................................................................................................127 8.17.4 Test procedures.............................................................................................................127
8.17.4.1 Check the status of a domotic device................................................................................................................... 127 8.17.4.2 Telecontrol of a domotic device........................................................................................................................... 128 8.17.4.3 Streaming video from the surveillance camera.................................................................................................... 129 8.17.4.4 View the motion detection alarms........................................................................................................................ 130
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
7 / 151
8.18 DIGITAL TV ........................................................................................................................131 8.18.1 Test Platform.................................................................................................................131 8.18.2 Expected schedule.........................................................................................................133 8.18.3 Technical requirements.................................................................................................133 8.18.4 Common test procedures...............................................................................................133
8.18.4.1 Multi-VSP Management ...................................................................................................................................... 133 8.18.4.2 SP-RCST Management ........................................................................................................................................ 134
8.18.5 Broadcast Digital TV test procedures...........................................................................135 8.18.5.1 Start/Stop the flow server..................................................................................................................................... 135 8.18.5.2 Add/configure and start a new flow to the flow server ........................................................................................ 135 8.18.5.3 Stop a flow........................................................................................................................................................... 137 8.18.5.4 Delete an existing flow ........................................................................................................................................ 138
8.18.6 Broadcast interactive applications procedures............................................................139 8.18.6.1 Start/Stop the flow server..................................................................................................................................... 139 8.18.6.2 Add/configure and start a new interactive application in the flow server ............................................................ 139 8.18.6.3 Load of an application ......................................................................................................................................... 141 8.18.6.4 Stop an interactive application............................................................................................................................. 141 8.18.6.5 Delete an existing interactive application in the flow server................................................................................ 142
8.19 SOFTWARE DOWNLOAD.................................................................................................144 8.19.1 Test Platform.................................................................................................................144 8.19.2 Expected schedule.........................................................................................................145 8.19.3 Technical requirements.................................................................................................145 8.19.4 Test procedures.............................................................................................................145
8.19.4.1 Content transmission............................................................................................................................................ 145 8.19.4.2 Program guide reception...................................................................................................................................... 147 8.19.4.3 Content download................................................................................................................................................ 148
9. RISKS AND CONTINGENCY PLANS...................................................................................149
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
8 / 151
FIGURE INDEX Figure 4-1. Test template........................................................................................................................15 Figure 5-1. Hispasat transparent platform...............................................................................................16 Figure 5-2. Generic block diagram of the hub........................................................................................17 Figure 5-3. Functional block diagram of the hub....................................................................................18 Figure 6-1. Logical layout.......................................................................................................................25 Figure 6-2. Network layout.....................................................................................................................26 Figure 6-3. Beam 1, sub channel 1..........................................................................................................29 Figure 6-4. Beam 1, sub channel 4..........................................................................................................30 Figure 7-1. Nomadic terminal test platform............................................................................................32 Figure 8-1. Management test platform....................................................................................................40 Figure 8-2. Flow diagram for the authentication service........................................................................44 Figure 8-3. Security test platform...........................................................................................................45 Figure 8-4. Multicast test platform .........................................................................................................49 Figure 8-5. Internet access test platform.................................................................................................52 Figure 8-6. Intranet access test platform.................................................................................................55 Figure 8-7. SIP test platform...................................................................................................................57 Figure 8-8. H.323 test platform...............................................................................................................63 Figure 8-9 Video On Demand test platform ...........................................................................................68 Figure 8-10 Near Video On Demand test platform.................................................................................72 Figure 8-11 Streaming test platform.......................................................................................................78 Figure 8-12 Test platform for real system (Webcast-E-Learning Service) ............................................88 Figure 8-13 Multiconference test platform.............................................................................................96 Figure 8-14. Nomadic terminal test platform........................................................................................108 Figure 8-15: Low-cost terminal integration platform...........................................................................112 Figure 8-16 Middleware test platform..................................................................................................114 Figure 8-17 ADSL and satellite internetworking test platform ............................................................119 Figure 8-18 Home gateway test platform .............................................................................................126 Figure 8-19 Digital TV test platform....................................................................................................132 Figure 8-20 Software Download test platform .....................................................................................145
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
9 / 151
EXECUTIVE SUMMARY Document D422 describes the set of tests that will be performed using the real system to validate the services and applications developed within the framework of SATLIFE. It includes some test procedures that were not be tested using the laboratory model because they no added value by testing in that phase. During this phase all tests procedures are oriented to face directly the interworking with the satellite. In SATLIFE project, new advanced technological features have been added to AMERHIS and IBIS projects to allow the integration of new services and applications, enhance the DVB-RCS network, the features of the DVB-RCS terminals operating in regenerative and transparent modes and the integration with terrestrial networks. For its carrying out, it has been taken into account all know-how stemmed from the IBIS and AMERHIS projects development. This document is divided into several chapters with the details of the environment used for the tests and with the details of the test produces that will be done during the real system test phase of SATLIFE project in the different subsystems:
• Chapter 2 lists the references used in this document. • Chapter 3 collects the abbreviations used in this document. • Chapter 4 describes how are organised the test procedures, with indications about test
numbering, test structure and test bed description. • Chapter 5 describes the test architecture, presenting for each of the platforms (Hispasat
transparent platform and AmerHis regenerative one), the equipment and software tools used, together with the participants involved.
• Chapter 6 explains the logical and network layout of the environment used for the real system test phase, the network configuration and the time and frequency timeslot assignment.
• Chapter 7 collects the test procedures for the different subsystems related with the satellite transparent platform. For the transparent platform, tests planned are in the frame of Nomadic Terminal integration. Tests are split into two main sections: one covering satellite access and physical layers tests and the other covering interoperability between the EMS Nomadic Terminal and the Hispasat hub.
• Chapter 8 collects the test procedures for the different subsystems, services and devices related with the satellite regenerative platform. For the regenerative platform, test procedures are detailed for management, security, multicast traffic, internet access, intranet access, SIP, H.323 enhancements, Video-On-Demand, near video-on-demand, streaming, e-learning, multiconference, Nomadic Terminal integration, low-cost integration, middleware, ADSL & Satellite network, home gateway, and digital TV & Software download, corresponding to a set of services offered to satellite subscribers through the regenerative platform. Although most of them will be tested in a meshed scenario, they are also available through the system RSGWs, in case that the Content Service Providers are only accessible through the Internet. Moreover, some of the services are only given by means of the RSGW, such as ISDN or Internet Access
• Finally, chapter 9 describes the foreseen risks and the contingency plans to resolve them.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
10 / 151
More details on each of the tests are hereafter given as a summary of this document:
• For the management test procedure, features to be tested are going to be Multicast Routes Management to verify that multicast routes can be configured in the NCC and Terminal Management.
• In Security, RCST authentication procedure will verify the new authentication procedure supported by the authentication application plug in, as well as for the RSGW.
• For the case of Multicast traffic, RSGW Multicast reception whose source is located at Internet and RSGW Multicast forwarding towards Internet only if an Internet user request the multicast flow, are going to be tested.
• For Internet access, internet service verifying that the system continues working properly with the added features for the star connectivity will be tested.
• Besides, for Intranet access, a verification of the intranet service getting access to the corporate network through the RSGW will be carried out.
• SIP test procedures will consist of test of internal calls, performing VoIP and video calls in several scenarios involving various users. In the same way, H323 enhancements will be tested.
• For the video-on-demand feature, the objective is the verification in-orbit of all the service capabilities defined in D321 and D3222 for this service. In the same way, NVOD services test procedures and streaming service tests procedures will be implemented.
• For e-learning, Tele-services will be tested such as live events/courses tests, deferred events/courses tests, on-demand express tests and on demand multimedia repository tests.
• Nomadic Terminal Integration will verify the correct behavior of a Nomadic terminal within Satlife network, and Low Cost terminal integration will verify that a low cost RCST can operate in the system.
• Test procedures for Middleware will consist of tests in a VOD application, in a web browser application and TV multicast application.
• ADSL & Satellite internetworking test procedures will verify the connectivity using a PPPoE multi-user scenario, a single-user scenario and a routing multi-user scenario.
• For Digital TV and Software download features, multi-VSP Management will be tested, verifying that two SP RCST can be provisioned with the necessary information in the same VSN. Besides, SP-RCST Management will verify that the SP RCST can be provisioned with the necessary information to logon, and that management operations can be performed against it.
Thus, the objective of this document is to plan and control all the in-orbit tests, to keep all the information updated for each of the trials, knowing all the needed resources in terms of bandwidth capacity, human resources, equipment…to be sure that everything will be in place when each of the test is going to be carried out. To conclude the validation process, the complete results will be described in document D424 Real System Trials Test Results.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
11 / 151
REFERENCES [1] SATLIFE D210, DVB-RCS, Regenerative (and Transparent) System Services Requirements
Report. [2] SATLIFE D220, DVB-RCS, Regenerative (and Transparent) Network Aspects Report. [3] SATLIFE D230, DVB-RCS regenerative (and transparent) Technology and Subsystems
Requirements Report [4] SATLIFE D321, DVB-RCS, Regenerative (and Transparent) System Services Provision and
Devices Design Report. [5] SATLIFE D322, DVB-RCS regenerative (and transparent) System Services Provision and Devices
Development. [6] SATLIFE D331, Plan for laboratory test.
[7] SATLIFE D332, In-factory Prototypes Validation Test Results. Laboratory System Prototype Test Set-up and Procedures.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
12 / 151
ABBREVIATIONS For the purposes of the present document the following abbreviations apply: AAL ATM Adaptation Layer AES Advanced Encryption Standard AIT Application Information Table ASI Asynchronous Serial Interface ATM Asynchronous Transfer Mode AVBDC Absolute Volume Based Dynamic AVC Advanced Video Coding BBP Base Band Processor BE Best Effort BER Bit Error Rate BTP Burst Time Plan BUC Block Up-Converter C2P Connection Control Protocol CAT Conditional Access Table CBR Constant Bit Rate CLI Command Line Interface CMT Correction Message Table CPE Customer Premises Equipment CR Capacity Request CRA Continuous Rate Assignment CRC Cyclic Redundancy Check CSC Common Signalling Channel DHCP Dynamic Host Configuration Protocol DIFFSERV Internet Differentiated Services DSCP DiffServ Code Point DSLAM Digital Subscriber Line Access Multiplexer DSM-CC Digital Storage Medium – Command and Control DULM Data Unit Labelling Method DVB Digital Video Broadcast DVB-RCS DVB Return Channel via Satellite DVB-S Digital Video Broadcast by Satellite EIT Event Information Table ETSI European Telecommunications Standards Institute FCA Free capacity assignment FCT Frequency Correction Table / Frame Composition Table FDMA Frequency Division Multiplex Access FTP File Transfer Protocol GEO Geostationary Earth Orbit GPS Global Positioning System
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
13 / 151
GRE General Routing Encapsulation GW GateWay HTTP Hyper-Text Transfer Protocol ICMP Internet Control Message Protocol IDU In-Door Unit IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics Engineers IGMP Internet Groups Management Protocol IP Internet Protocol Iperf IP Network Performance Test Tool – SW application IPSec IP Security – according to IETF IRD Integrated Receiver Decoder ISO International Standards Organization ISP Internet Service Provider LAN Local Area Network LNB Low Noise Block down-converter MAC Medium Access Control MBS Maximum Burst Size MCR Minimum cell rate MCU Multiconference Control Unit MF-TDMA Multi-Frequency Time Division Multiple Access MHP Multimedia Home Platform MIB Management Information Base MMT Multicast Map Table MPE Multiprotocol Encapsulation MPEG Moving Picture Experts Group MPH Miles per Hour MS Microsoft MSB Most Significant Bit MTU Maximum Transmission unit NAT Network Address Translation NCC Network Control Center NCC-S Network Control Center –Simulator NCR Network Clock Reference NG NetGain (Product family from Flash Networks) NIT Network Information Table NMC Network Management Center NVOD Near-Video On Demand OBP On Board Processor OBP-S On-Board Processor Simulator PAT Program Association Table PCR Program Clock Reference / Peak Cell Rate PDM Power Distribution Module PDU Protocol Data Unit PEP Performance Enhancement Proxy
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
14 / 151
PID Packet Identifier PMT Program Map Table PSI Program Specific Information QoS Quality of Service RBDC Rate Based Dynamic Capacity (RBDC) RCST Return Channel Satellite Terminal RF Radio Frequency RMT RCS Map Table RRM Radio Resource Management RS Reed-Solomon RSGW Return Satellite GateWay RSGW-S Return Satellite GateWay Simulator RST Running Status Table RSVP ReSource reserVation Protocol RTP Real Time transport Protocol RTSP Real Time Streaming Protocol SAC Satellite Access Control SATLIFE Satellite Access Technologies: Leading Improvements For Europe SCR Sustained cell rate SCT Superframe Composition Table SDP Session Description Protocol SDT Service Definition Table SI Service Information SIT Service Information Table SIT Satellite Interactive Terminal SNMP Simple Network Management Protocol SPT Satellite Position Table ST Satellite terminal SW SoftWare TBTP Terminal Burst Time Plan TCP Transmission Control Protocol TCT Time-slot Composition Table TDMA Time-Division Multiple Access TDT Time and Date Table TIM Terminal Information Message TRF Traffic (burst type) TS Transport Stream UDP User Datagram Protocol URL Uniform Resource Locator USB Universal Serial Bus VBDC Volume Based Dynamic Capacity VBR Variable Bit Rate VoD Video on Demand VoIP Voice over IP VPN Virtual Private Network
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
15 / 151
ORGANIZATION OF THE VALIDATION PROCESS
TEST NUMBERING The names of the tests all start with STLF_IO_XXXX where: • STLF is the acronym of SATLIFE. • IO is the acronym of IN-ORBIT. • XXXX is a brief acronym for the definition of the test.
TEST STRUCTURE For the definition of the test the next template will be used: Test Reference: STLF_IO_XXXX Subsystem: subsystems involved
in the test. Pre-Requisite Tests: None / Any that must be tested before Test Platform: Reference type of
platform used for test: elements, terminals, architecture, etc
Objectives: Objectives of the test and expected impact. Test Setup: Reference to General Test Setup (resources required and their setup) Constraints and Initial Conditions Test Descr iption: Description of the steps that must be given to perform the tests. Results Expected: List of the results expected when passing the test.
Figure 0-1. Test template
TEST BED DESCRIPTION For a description of the test architecture see chapter 0 TEST ARCHITECTURE where it is described the platform used to integrate and perform the real system testing of SATLIFE.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
16 / 151
TEST ARCHITECTURE
TEST ENVIRONMENT Two different platforms are going to be used during the tests: • Hispasat Transparent Platform. • AmerHis Regenerative Platform.
1.1.1 Hispasat Transparent Platform Hispasat Multimedia Platform is based on the Satlink System, fully DVB-RCS standard compliant. The platform, placed in the Hispasat Satellite Control Centre, in Arganda del Rey (Madrid), is fully operative since March 2003. The network has a typical star topology. The central node or Hub contains the NMS, the satellite front-end, IP infrastructure and terrestrial networks interfaces. User terminals provide bi-directional services through the satellite network. These terminals consist of an InDoor and an OutDoor Units, DVB-RCS standard compliant too.
Figure 0-1. Hispasat transparent platform
The platform offers bi-directional IP connectivity between terminals and between terminals and terrestrial networks, always through the Hub, allowing different services such Internet access, Intranets/VPNs, VoIP and multicast. On the other hand, MPEG2/DVB-S unidirectional services are available from Hub to the terminals.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
17 / 151
The system must be interoperable, since it is DVB-RCS standard compliant. Currently, Hispasat is making tests to assure such interoperability with other Hub and terminals manufacturers, by means of the Satlab Group1. The DVB-RCS Hub consists of an antenna pointing to the satellite, RF equipment and the Gateway with terrestrial networks interfaces, as shown in the next figure.
Figure 0-2. Gener ic block diagram of the hub
The operational frequency band is the Ku band, for both forward and return links, with both Europe-Europe and American-Europe connectivities. As shown in the functional block diagram of the following figure, the Gateway is mainly composed of the following subsystems:
• Network Management System (NMS). Interfaces between ISP/operator and Hub. It manages the users’ traffic and services provision. NMS also performs the control and supervision of HUB equipment, network and terminals.
• Forward L ink Subsystem (FLS). Encapsulates IP packets in MPEG-2 frames and transmits these frames on a TDM carrier, base-band modulated. In the RF equipment, the modulated bitstream is upconverted and sent to the antenna, which transmits it up to the satellite at frequencies in the Ku band.
• Return L ink Subsystem (RLS). The Gateway antenna receives the downlink signal at Ku band and downconverts it to the 950-1450 MHz IF band. Thereafter, RLS filters the different
1 Group promoted by the European Space Agency (ESA) in which Hispasat is an active member since 2002, along with other satellite operators and manufacturers
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
18 / 151
return channels that compose a superframe, demodulates the signal, decodes the TDMA bursts form the terminal and extracts the frames containing the IP packets and sends them to the Hub station Ethernet.
• Reference and Synchronization Subsystem (REFS). Receives time signals from GPS and provides synchronization and timing for the different Gateway subsystems.
• IP infrastructure, that makes possible the establishment of the management and traffic networks as well as the routing between Internet and the different subsystems.
Figure 0-3. Functional block diagram of the hub
1.1.2 AmerHis Regenerative Platform
1.1.2.1 Equipment Apart from the OBP, the SATLIFE In Orbit validation contour will include the following types of equipment: • One Operational RSGW (with two RCST IDUs and no ODUs) which interfaces the SATLIFE
system: o With telephony oriented ground networks such as PSTN or ISDN, o With Internet oriented ground networks.
• Operational user RCST IDUs which allow the users to access: o Other SATLIFE users either in single satellite hop or with a double satellite hop through
the RSGW, o PSTN or ISDN users through the RSGW in single satellite hop, o The World Wide Web (WWW) servers and users through the RSGW in single satellite hop.
• The Management Station (MS) with whole redundancy, based on:
o The Network Control Center (NCC) which controls the Interactive Network, serves requests from the users of the system, and manages the BBP configuration.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
19 / 151
o The NCC-RCST IDU, which supports the modulation and demodulation functions to access to the BBP.
o The NMC (Network Management Center), which performs the system management. It consists of two different systems:. (These two components share a File Server with the NCC (and its Mediation Device):
- Element Manager: Responsible of the EML management of the redundant NCC and the GWs. No access to Service Providers is provided.
- Network and Service Manager (NSM): responsible of the management of the VSNs, Service Providers, RCSTs and telecom service (permanent connections).
• - SPs – SP-RCSTs to provide VoD.
1.1.2.2 Software tools Operating Systems Microsoft Windows XP Professional Service Pack 1 will be used as end user’s operating system. Some tunning options for optimizing the system for satellite environments will be employed. Optionally, some Windows XP Professional features may be used for the traffic transmissions, such as IPsec, L2PT VPN client, QoS handling or NAT traversal. Microsoft Windows 2003 Server Standard Edition will be used to test corporate access services through AmerHis System, such as LDAP, mail server, web server, VPNs … SuSe Linux 8.2/9.0 is going to be tested as alternative operating system. The software applications running on Linux will be the same than the windows ones, when possible. Network Analyzers • Ethereal: Ethereal is a free network protocol analyzer for Unix and Windows. The captured data
can interactively browsed, viewing summary and detail information for each packet. Ethereal has several powerful features, including a rich display filter language and the ability to view the reconstructed stream of a TCP session.
• TCPview: TCPView is a Windows program that shows detailed listings of all TCP and UDP endpoints of the system, including the local and remote addresses and state of TCP connections. On Windows XP, TCPView also reports the name of the process that owns the endpoint. When TCPView is started, it will enumerate all active TCP and UDP endpoints, resolving all IP addresses to their domain name versions. A toolbar button or menu item can be used to toggle the display of resolved names. On Windows XP systems, TCPView shows the name of the process that owns each endpoint. By default, TCPView updates every second, the ‘Options|Refresh Rate’ menu item can be used to change the rate. Endpoints that change state from one update to the next are highlighted in different colours. Established TCP/IP connections can be closed by selecting ‘File|Close Connections’ , or by right-clicking on a connection and choosing ‘Close Connections’ from the resulting context menu.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
20 / 151
TCPView's output window can be saved to a file. • NetStat Live: TCP/IP protocol monitor which can be used to see the exact throughput on both
incoming and outgoing data from/to a computer. • NetPerSec: Another windows tool that allows to measure the connection speed in real time. Web Browsers: • Internet Explorer: Microsoft Internet Explorer will be used for Web browsing in Windows
Operating System user terminals. • Internet Konqueror: Internet Konqueror will be the browser used for Linux user terminals. Audio/Video conferencing • NetMeeting : NetMeeting is a windows tool to hold video conference calls, send text messages,
collaborate on shared documents, and draw on an electronic whiteboard over the Internet or an intranet. It uses the H.323 protocol for the voice/video conferences.
• OpenPhone: Open H.323 client for audio/video conferencing. • Ohphone : Command line tool for establishing audio/video conferences on Linux-based systems. • OpenGK: Gatekeeper tool to be used together with the Open H.323 tools • OpenMCU: H.323 conference server. • VIC: VIC is a unicast and multicast videoconferencing tool. When joining a conference with video
using SDR, VIC will start up automatically. • RAT: Robust-Audio Tool (RAT) is an audio conferencing tool which can be used for either unicast
or multicast conferencing. When joining a conference with audio using SDR, RAT will start up automatically.
Traffic generators • MGEN: This tool generates real-time traffic patterns so that the network can be loaded in a variety
of ways. The generated traffic can also be received and logged for analyses. Script files are used to drive the generated loading patterns over the course of time. These script files can be used to emulate the traffic patterns of unicast and/or multicast UDP/IP applications. The receive portion of this tool set can be scripted to dynamically join and leave IP multicast groups. MGEN log data can be used to calculate performance statistics on throughput, packet loss rates, communication delay, and more. MGEN currently runs on various Unix-based (including MacOS X) and WIN32 platforms.
• CallGen323: H.323 call generator. This call generator allows the following: o spawning an exact number of calls per batch. o receiving an exact number of calls. o adjust the delay between each batch of calls. o set the number of batches to repeat. o only support G.711 64k Alaw o gatekeeper functionality.
Multicast tools • SDR: SDR (Multicast Session Directory) is a tool which assists the user in setting up and joining
conferences.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
21 / 151
• This tools enables creating and advertising secure conferences, and inviting other people to join if
they wish. It provides a framework for setting up conference session announcements and automatically configures the relevant tools.
• SDR can receive and send encrypted and authentication session announcements using technologies such as DES, PGP and X509.
• Mping: Mping is a simple command line application that sends and receives multicast packets. • Fcast. File Multicastig (Fcast) is a scalable reliable multicast file transfer protocol based on FEC
(Forward Error Correction). Fcast combines multicast with FEC to address reliability and bandwidth efficiency, and is able to both send and receive.
• PowerPoint multicast add-in: Utility to multicast PowerPoint slides (including animations and effects) to a group of viewers.
Unicast tools • Ping: Ping is a utility used to verify if a network data packet is capable of being distributed to an
address without errors. The ping utility is commonly used to check for network errors. • Ftp: FTP is a standard way to transfer files between computers. The method has built-in error
checking. AmerHis Protocol analyzers • ATP Analyzer: It is an extension to ethereal (see section 0) developed in AAS-E. It implements a
dissector called ATP2. This tool is able to analyze the different ATP messages exchanged between the NCC and the NCC-RCST.
• Verisat FLA (Forward Link Analyzer ): This tool allows the analysis of PSI/SI and DVB-RCS tables contained in a DVB-S stream.
• PSD (Private Signaling Decoder): It is an extension to the Verisat FLA tool developed by AAS-E and Verisat. It analyzes specific AmerHis signaling such as Connection Control Protocol messages (C2P), AmerHis MMT or AmerHis logon TIM unicast message.
• Dvbtables: Based on dvbsnoop v1.3.0. This tool decodes transfer streams and sections contained in a DVB-S stream: PIDs = 0x0c (DULM), 0x825 (TBTP), 0x827 (TIMu), 0x1ff9 (SYNC) and allows to specify more than one pid to be filtered simultaneously.
• It includes scripts to process these DVB-RCS tables information in text files in order to obtain specific forms and graphics.
Summary of SW tools SW APPLICATION Descr iption Version Platform Operating Systems Windows XP Professional
Edition SP1 Windows
Windows 2003 server Standard Edition Windows SuSe Linux 8.2/9.0 Linux Analyzers
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
22 / 151
Ethereal network protocol analyzer 0.10.2 Windows/Lin
ux TCPview TCP/UDP endpoints listing 2.33 Windows NSL Displays speed of active
connections 2.11 Windows
NetPerSec Displays speed of active connections
1.1 Windows
Web Browsing Internet Explorer Windows browser 6 Windows Internet Konqueror Linux browser 3.1.1 Linux Audio/Video conferencing
NetMeeting H.323 conferencing tool 3.0.1 Windows OpenPhone H.323 client 1.9.1 Windows Ohphone command line H.323 client 1.4.1 Linux OpenGK H.323 gatekeeper 1.3.4 Windows/Lin
ux OpenMCU H.323 conferencing server 1.1.7 Windows/Lin
ux VIC unicast/multicast video
conferencing tool 2.8 Windows/Lin
ux RAT unicast/multicast audio
conferencing tool 4.2 Windows/Lin
ux Traffic generators Mgen real-time multicast/unicast
traffic generator 3.3 & 4.0 Windows/Lin
ux/FreeBSD CallGen323 H.323 call generator 1.2.6 Windows/Lin
ux Multicast SDR Multicast Session Directory 2.5 Windows/Lin
ux Mping Multicast Ping tool 2.0 Windows Fcast Multicast File Transfer tool Windows PowerPoint mcast add-in Tool for multicasting
PowerPoint slides 1.31 Windows
Unicast Ping ICMP unicast conectivity
tool Windows/Lin
ux GuildFTPd FTP server 0.999.9 Windows Proftpd FTP server 1.29 Linux AmerHis Protocol Analyzers
ATP Analyzer ATP ethereal like analyzer 1.0 Windows/Linux
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
23 / 151
Verisat FLA PSI/SI and RCS table
analyzer 1.3.6.1 Windows
PSD C2P/MMT/TIMu analyzer 1.0 Windows dvbtables SPI/SI/RCS tables analyzer 0.1 Linux Other PowerPoint 97 / XP Windows Apache Web server 2.0.48 Windows/Lin
ux OpenH323 Open H.323 DLL libraries 1.12.2 Windows PWLib Open H.323 DLL libraries 1.5.2 Windows WinPcap Packet capture library 2.3 Windows Libpcap Packet capture library 0.7.1 Linux GTK+ GUI creation library 1.2.10 Linux Glib GUI creation library 1.2.10 Linux Webmin Web-based interface for
stem administration 1.121 Linux
PARTICIPANTS All the SATLIFE partners are involved in the SATLIFE in orbit tests. Many partners will provide with intensive participation during the tests phase: • AASE will coordinate all the tests involving the regenerative platform, with support from HSA
which host the Management Station. • HSA will coordinate all the tests involving the transparent platform. • EMS participates in the nomadic tests. • INDRA collaborates in the tests involving the RSGW. • TID participates on new services and applications tests. • TEL and TPD will collaborate on traffic and service tests. • UPM participates on tele-education service. The participation of some partners consists in giving support during the test phase for the equipment or applications they are responsible for. This is the case of: • AASF, for NCC support. • UoS, for support on authentication tests. • Thales, giving support on tests involving the SP. • Shiron, for support on the SP-RCST. • Nera will provide support for the RCSTs.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
24 / 151
TEST SCENARIOS DESCRIPTION Subscribers are organised in Virtual Satellite Network (VSN). Each VSN is associated to a service provider or a (large) company. A VSN has allocated a guaranteed amount of physical resources. Each subscriber is within one and only one VSN and can communicate only with subscribers or RSGWs of the same VSN (a RSGW may be shared by several VSNs). In SATLIFE a number of VSNs will be defined to test the different services following the next description: VSN 1 LAN Interconnection with NERA and EMS terminals (E-learning, Nomadic Access, Mesh Multicast, VoD, PEP Acceleration, Intranet Access, VoIP…) VSN2 Video Service Provider 1 (Video broadcast and Software application download) VSN3 Video Service Provider 2 (Video broadcast)
LOGICAL LAYOUT Uplink Downlink VSN Number of
Subnets STLF-AASE1 1 1 1 2 STLF-AASE2 1 1 1 1 STLF-AASE3 1 1 1 1 STLF-AASE-LC 1 1 1 1 GW-RCST-AASE 1 1 1 - GW-RCST-INDRA 1 1 1 - STLF-TID1 1 1 1 1 STLF-TID2 1 1 1 1 NOMADIC 1 1 1 1 BRASIL 2 2 1 1 STH-AMERICA 3 3 1 1 SHIRON 1 1 1 2 1 SHIRON 2 1 1 3 1
Table 0-1 Terminal layout in VSNs
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
25 / 151
BRASIL
VSN 1
MS
NCC-RCST
NCC
NMC
GW-RCST-AASEUPLINK
FUNCTION
UPLINK 1
UPLINK 2
UPLINK 3
DOWNLINKFUNCTION
DOWNLINK 1
DOWNLINK 2
DOWNLINK 3
STLF-AASE1
STLF-AASE-LC
STH-AMERICA
STLF-TID2
STLF-AASE2
STLF-AASE3
STLF-TID1
GW-RCST-INDRA
DOWNLINKFUNCTION
DOWNLINK 1
DOWNLINK 2
DOWNLINK 3
NOMADIC
SHIRON 1
VSN 2
SHIRON 2
VSN 3VSN 2
Figure 0-1. Logical layout
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
26 / 151
NETWORK LAYOUT
STLF-AASE1LAR-EMS1
Subnetwork 1
Subnetwork 2
STLF-AASE3Subnetwork 1
VSN 1
Other Devices
VSN 3ERI-SHIRON1
SP 1
VSN 2Subnetwork 1
ERI-SHIRON2SP 2
Subnetwork 1
IRD&TVDVB-SCard
ApplicationServers
MonitoringUnit
STLF-AASE2Subnetwork 1 BRASILSubnetwork 1
STLF-TID1Subnetwork 1
STLF-TID2Subnetwork 1
STH-AMERICASubnetwork 1
STLF-AASE2Subnetwork 1
STLF-AASE-LCSubnetwork 1
NOMADIC Subnetwork 1
GW-RCST-INDRA
GW-RCST-AASE
Figure 0-2. Network layout
The application servers can be: software download, NVoD, VoD, E-learning,…
CONFIGURATION The configuration is done using different services (that are usually defined by the INAP). Afterwards a VSN or group of terminals is assigned a service which share a set of resources. In a deeper level the RCST is configured with special characteristics.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
27 / 151
1.1.3 Service Configuration At least five services are needed: one for the RCST connectivity and for the Video Service (a different carrier implies a different service):
Parameter SP 1 SP 2 SP 3 SP 4 SP 5 Id 1 2 Name STLFSP1 STLFSP2 STLFSP3 STLFSP4 STLFSP5 Managed RCST Number
4 0 0 0
List of VSNs VSN1 VSN2, VSN3
VSN2, VSN3
VSN2, VSN3
VSN2, VSN3
RCST Class C2 C1 C2 C3 C4 Max Star PDR Fwd 0 0 0 0 0 Max Star SDR Rtn 0 0 0 0 0 Max Star PDR Rtn 0 0 0 0 0 Max Mesh PDR Fwd 1024 0 0 0 0 Max Mesh SDR Rtn 512 0 0 0 0 Max Mesh PDR Rtn 1024 0 0 0 0 Default Star Values 0 0 0 0 0 Alpha fwd 0 0 0 0 0 Cnx max number 20 0 0 0 0 On demand cnx multicat /j itter sensitive
20 0 0 0 0
CRA/RBDC sig 0/24 512/0 1024/0 2048/0 4096/0
Table 0-2 Service Configuration Parameters
In the case of the Video Service Providers no capacity is assigned for star and mesh. All resources are given in the signaling connection.
1.1.4 VSN Configuration The parameters to be configured in the VSN are the following:
Parameter VSN 1 VSN 2 VSN 3 IN ID 1 1 1 VSN ID 1 2 3 VSN Name SatLife1 SatLifeVSP2 SatLifeVSP3 Cnx Max Number 20 0 0 Connected RCST Max Number
4 1 1
MMT PID 900 Not used Not used Carr ier Type C2 C1,C2,C3 or C4 C1,C2,C3 or C4
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
28 / 151
Minimum guaranteed capacity
512 kbps 512,1024,2048, 4096 512,1024,2048, 4096
Max capacity 1024 kbps 512,1024,2048, 4096 512,1024,2048, 4096 On demand booking factor
0.8 1.0 1.0
Permanent booking factor
0.2 0.0 0.0
Default routing entry name
RCST or GW-RCST MAC
Null Null
Table 0-3 VSN Configuration Parameters
TIME AND FREQUENCY TIMESLOT ASSIGNMENT
1.1.5 OBP Configuration Each beam in the OBP has 4 different sub channels, and each of them can be configured using carriers in C1, C2, C3 and C4 classes. Next captures show the configuration used in the first and fourth sub channel of the first beam (Europe). The first sub channel is configured in C4, it has two carriers, the second used for the transmission of the NCC. The second picture shows the fourth sub channel, that is configured in C3, its capacity is assigned to the different RCSTs in the system for transmitting traffic. In the picture are detailed the number of bursts contained in each carrier and the capacity associated.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
29 / 151
Figure 0-3. Beam 1, sub channel 1
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
30 / 151
Figure 0-4. Beam 1, sub channel 4
1.1.6 Routes These bursts will be grouped in routes depending on the timeslot type (carrier, turbo code, number of mpeg packets), source and destination. For example a route could be defined as: • Bursts going from uplink 1 to downlink 2. • 1 Carrier in C2, ¾ • 1 packet per burst (36 packets in a superframe). A route with 1024 kbps from uplink 1 to downlink 2 could be defined for VSN 1 to be used by STLF-AASE1 or STLF-AASE2.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
31 / 151
TRANSPARENT PLATFORM TEST PROCEDURES
NOMADIC TERMINAL INTEGRATION This chapter defines the tests to be performed on the Nomadic Terminal using the transparent platform. The tests split into two main sections one covering satellite access and physical layers tests and the other covering interoperability between the EMS Nomadic Terminal and the Hispasat hub.
1.1.7 Test Platform The nomadic test platform comprises:
• A vehicle fitted with a one button auto-deploy antenna. • A portable rack comprising:
o DVB-RCS Modem o Antenna controller o UPS
• Portable Generator The antenna is an AvL Technologies mobile VSAT antenna system. The DVB-RCS modem is an EMS Technologies Satellite Networks E2020. An APC UPS is integrated into the system. A Honda portable generator supplies the power. The antenna comprises Compass, GPS, Inclinometer and a beacon receiver. Once activated the antenna reads the compass heading confirms the incline of the antenna is acceptable starts to obtain a GPS position. Once the controller has done this the antenna is deployed to the pre-selected satellite. Once the antenna has been deployed to the pre-selected satellite it auto-tracks to obtain the best signal. When this has been archived the controller indicates that is has obtained lock and then starts to send the GPS position to the DVB-RCS modem. The DVB-RCS modem takes the GPS position from the antenna controller and inserts this data into its configuration to enable full Forward and Return Link lock. Par tners involved: Alcatel Alenia Space Spain EMS Satcom (supported by EMS Satellite Networks)
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
32 / 151
Static Terminals
Static Nomadic
Satellite
HUB
Return Link to Satellite
Return Link Satellite - Hub
Fowrad Link Satelite to Terminal
Forwrard Return LinkMesh configuration
Figure 0-1. Nomadic terminal test platform
1.1.8 Expected Schedule In order to perform these tests, the following scheduling aspects are: Number of days: 2 days Pre-requisite tested services: 5 days
1.1.9 Technical requirements The technical requirements to perform the nomadic terminal tests are the following: Available return link bandwidth - 512KB/s
1.1.10 Test procedures for satellite access and physical layer tests Please see document D331 section 6 for list of physical layer tests performed on the equipment.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
33 / 151
1.1.10.1 Acquisition of Satellite Test Reference: STLF_IO_NOM_TRA_ACQ_SAT Subsystem:
Pre-Requisite Tests:
Test Platform:
Nomadic system Objectives: Measure the time taken for the Nomadic terminal to acquire the satellite Test Setup: Not Applicable Test Descr iption: From stow position measure the time taken for the SIT to acquire both Forward and Return Links Results: Average time taken less then 5 minutes
1.1.11 Test procedures for interoperability
1.1.11.1 Forward Link Acquisition
1.1.11.1.1 Acquire Forward Link
Test Reference: STLF_IO_NOM_TRA_ACQ_FWDLK Subsystem:
DVB-RCS Modem Pre-Requisite Tests:
Test Platform:
Nomadic System Objectives: Check that RCST is capable of receiving and reading all DVB-RCS specific tables Test Setup: Test Descr iption: Confirm RCST is capable of receiving and reading all DVB-RCS specific tables Results: Show tables as received by the RCST
1.1.11.2 Receive Sync State
1.1.11.2.1 CSC Burst Transmission
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
34 / 151
Test Reference: STLF_IO_NOM_TRA_CSC_Busrt Subsystem:
DVB-RCS Modem Pre-Requisite Tests:
Test Platform:
Nomadic System Objectives: Verify correct reception and formatting of CSC burst. This test requires that some means of performing coarse synchronization exist so that the CSC burst is transmitted in the correct time-slot. Test Setup: Test Descr iption: Dump the CSC burst at hub side and verify that its formatting is in accordance with the TCT table transmitted over the forward link. If this is not possible, verify that the RCST receives the correct unicast TIM as a response to the CSC (TIM reception test). Results: Show the RCST sends a CSC burst to the Hub and receives a unicast TIM in response
1.1.11.2.2 TIM reception
Test Reference: STLF_IO_NOM_TRA_TIM_RECP Subsystem:
DVB-RCS Modem Pre-Requisite Tests:
Test Platform:
Nomadic System Objectives: Verify correct reception of unicast TIM at RCST in response to CSC burst transmission. Test Setup: Test Descr iption: Dump unicast TIM message at RCST side and verify that addressing is correct and that the RCST transitions to the ‘Ready for Fine Sync’ state. Results: Show RCST sends CSC burst to Hub and receives unicast TIM in response. RCST is promoted to SYNC.
1.1.11.3 Ready for Fine Sync
1.1.11.3.1 SYNC Burst Transmission
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
35 / 151
Test Reference: STLF_IO_NOM_TRA_SYNC_BURST Subsystem:
DVB-RCS Modem Pre-Requisite Tests:
Test Platform:
Nomadic System Objectives: Verify correct SYNC burst reception and formatting at Hub side. Test Setup: Test Descr iption: Dump SYNC burst at the hub side, and verify that formatting is in accordance with information transmitted in the TCT table over the forward link. If this is not possible, verify that RCST receives the correct CMT with adequate timing correction as a response to the SYNC burst. Results: RCST sends SYNC bursts to Hub and receives CMT in response
1.1.11.3.2 CMT
Test Reference: STLF_IO_NOM_TRA_CMT_RECP Subsystem:
DVB-RCS Modem Pre-Requisite Tests:
Test Platform:
Nomadic System Objectives: Verify correct reception of CMT at RCST side in response to SYNC transmission Test Setup: . Test Descr iption: Dump CMT table received by the RCST in response to a SYNC burst. Verify correct reception and that RCST enters Fine Sync State on receiving CMT with timing errors below the thresholds stated in the SYNC Assign Descriptor transmitted over the forward link. Results: Show RCST sends SYNC bursts to Hub and receives CMT in response.
1.1.11.4 Fine Sync State
1.1.11.4.1 Sync Maintenance
Test Reference: STLF_IO_NOM_TRA_SYNC_MAINT Subsystem:
DVB-RCS Modem Pre-Requisite Tests: Test Platform:
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
36 / 151
Nomadic System
Objectives: Verify stable Sync Maintenance behaviour. Test Setup: Test Descr iption: Verify that RCST stays in Fine Sync State through the Sync maintenance procedure for one hour without being logged off by the hub. Results: Confirm RCST remains synchronized for one hour.
1.1.11.5 Application Testing
1.1.11.5.1 Multicast Transmission
Test Reference: STLF_IO_NOM_TRA_MCAST_TX Subsystem:
DVB-RCS Modem Pre-Requisite Tests:
Test Platform:
Nomadic System
Objectives: Transmit a Multicast and verify it’s received error-free. Test Setup: Test Descr iption: SNR on Forward link >= 10dB. Verify Multicast is received error-free. Results: Multicast transmitted and received error-free.
1.1.11.5.2 Multicast Receive
Test Reference: STLF_IO_NOM_TRA_MCAST_RX Subsystem:
DVB-RCS Modem Pre-Requisite Tests:
Test Platform:
Nomadic System
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
37 / 151
Objectives: Receive a Multicast and verify it’s received error-free. Test Setup: Test Descr iption: SNR on Forward link >= 10dB. Verify Multicast is received error-free. Results: Multicast received error-free.
1.1.11.5.3 IP Pinging
Test Reference: STLF_IO_NOM_TRA_IP_PING Subsystem:
DVB-RCS Modem Pre-Requisite Tests:
Test Platform:
Nomadic System
Objectives: Basic IP connectivity: Ping and verify packet transmission over the return link. Test Setup: Test Descr iption: SNR on return link shall be >= 10dB. Verify that all packets are received error-free Results: Compliant
1.1.11.5.4 FTP File transfer
Test Reference: STLF_IO_NOM_TRA_FTP_TRANS Subsystem:
DVB-RCS Modem Pre-Requisite Tests:
Test Platform:
Nomadic System
Objectives: Verify file transfers over TCP/IP. Test Setup: Test Descr iption: Perform FTP file transfers in both directions with RCST logged-on at 512kbps. File transfer duration should be less than 10 minutes, and no re-transmissions allowed. Results: Compliant
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
38 / 151
1.1.11.5.5 Web Browsing
Test Reference: STLF_IO_NOM_TRA_WEB_BROWS Subsystem:
DVB-RCS Modem Pre-Requisite Tests:
Test Platform:
Nomadic System Objectives: To test basic Internet connectivity Test Setup: Test Descr iption: RCST logged-on at 512kbps, true Internet access or Web server at Hub side. Verify stable operation for at least 10 minutes while doing the following operations: • Browse different pages • IP Pinging • FTP transfer • Multicast Transmit • Multicast Receive Results: Compliant
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
39 / 151
RENENERATIVE PLATFORM TEST PROCEDURES This group of test specifications correspond to a rich set of services, offered to satellite subscribers through the regenerative platform. Although most of them will be tested in a meshed scenario, they are also available through the System RSGWs, in case that the Content Service Providers are only accessible through the Internet. Moreover, some of the services are only given by means of the RSGW, such as ISDN or Internet Access.
MANAGEMENT Management of multicast routes A route is defined by a identical uplink timeslots that are switched by the OBP to the same downlink TDM or group of downlink TDMs. According to the number of destination downlinks, they can be unicast (1 destination TDM), broadcast (all destination TDMs) or multicast (several destination TDMs). Multicast routes are a new feature in the frame of SatLife project and this chapter defines a test to check the correct management of this new functionality. RCST management The management of an RCSTs performed using the management connection that communicates the NMC and the RCST. The management from the MS of an RCST comprises: - RCST provisioning in the NMC - Lock/Unlock DVB-RCS commands - RCST logon and synchronization maintenance - Mib browsing (get/set snmp commands): access to MIB objects in private MIBs and MIB-II groups (including blind commands).
1.1.12 Test Platform In order to perform the Management tests In-Orbit Testing a test setup has to be defined. See below the Test environment proposed:
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
40 / 151
Error !
Figure 0-1. Management test platform
RCSTs: The RCSTs must be manageable. They will transmit and receive multicast flows to test the new multicast routes. MS: This block performs the management operations (get, set…) against the RCSTs. The NCC routes to the NSM the packets send to its management interface. In this block are also defined the multicast routes. Taking this scenario, the partners involved and equipment to be provided by them in these tests are the following ones: • NERA Satcom: it is in charge of provide the RCSTs to be managed with its new MIB and that will
also transmit and receive multicast. • Alcatel Alenia Space Spain: it must perform the tests. • Hispamar and TPD: must perform the tests
1.1.13 Expected Schedule In order to perform these security tests, the following scheduling aspects are: Number of days: 4 days Pre-requisite tested services: None.
NCC
NSM
RCST 3
BEAM 2
RCST 1
RCST 2
BEAM 1
RCST 4
BEAM 3
Multicast Route
MS EM
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
41 / 151
1.1.14 Technical requirements The technical requirements to perform these tests are the following: • RCSTs operative in 3 beams: Europe, Brazil and South America • RSGW operative to check GW-RCST management • Available satellite bandwidth for the management and multicast connections of the RCSTs:
Capacity to be used for RCST management: o CRAsig capacity: 0 Kbps o RBDCsig capacity: 64 Kbps
Capacity needed for multicast routes test: o Mcast route #1 (EUR->EUR-BRA-SA) capacity: 100 Kbps o Mcast route #2 (EUR->EUR-BRA) capacity: 100 Kbps o Mcast route #3 (BRA->EUR-BRA-SA) capacity: 100 Kbps o Mcast route #4 (BRA->BRA-SA) capacity: 100 Kbps
1.1.15 Test procedures
1.1.15.1 Multicast Routes Management Test Reference: STLF_IO_MGT_ROUT Subsystem: NCC Pre-Requisite Tests: None Test Platform: In Orbit
Objectives: This test verifies that multicast routes can be configured in the NCC. Verify that the NCC performs the right assignment of bursts to the RCST transmitting multicast and that the data is replicated only in downlinks set for multicast. Test Setup: VSN1 Test Descr iption: An RCST transmits multicast traffic, other RCSTs from two beams belonging to the multicast route listen to the multicast flow, while other RCST belonging to a beam not included in the multicast route cannot listen to the multicast flow although it is provisioned in the same VSN. Results Expected: The NCC allows the configuration of multicast (not broadcast) routes. The traffic is replicated only in the downlinks of the multicast route.
1.1.15.2 Terminal Management Test Reference: STLF_IO_MGMT_RCST Subsystem: RCST
Pre-Requisite Tests: None Test Platform: In Orbit Objectives: This test verifies the basic functionality of AmerHis remains for RCST remote management, as
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
42 / 151
well as new management operations supported by the RCST, that implies MIB browsing to RCST´s Satlife MIB objects. . Test Setup: VSN1 Test Descr iption: This minimum set of tests will verify the communication between NMC and RCST: • RCST provisioning in the NMC • Lock/Unlock DVB-RCS commands • RCST logon and synchronization maintenance • Mib browsing (get/set snmp commands): access to MIB objects in private MIBs and MIB-II
groups • Blind commands (set snmp commands): change GPS position, send a restart. • Repeat tetst procedure for the GW-RCST. Results Expected: RCST successful logon according to DVB-RCS standard Successful remote management operations from the NMC
1.1.15.3 GMM Management Test Reference: STLF_IO_MGMT_GMM Subsystem: RSGW
Pre-Requisite Tests: None Test Platform: In Orbit
Objectives: RSGW management. Test Setup: RSGW in VSN 1 GMM NE created in the EM console. GW accounting from the EM ready (GMM FTP server configuration) Test Descr iption: Establish a remote FTP connection between MS and GMM. Download RSGW accounting CDR (SIP calls included). Results Expected: The FTP connection is established and CDR files can be downloaded including the SIP calls CDR files.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
43 / 151
SECURITY Authentication service The authentication service allows to authenticate an RCST or GW-RCST and to authorize them to operate in the system. If the authentication process indicates that the RCST is not authorized in the SatLife system, it will be blocked. The authentication process should be done after the logon of the terminal. After the CSC burst is received and the RCST logs on successfully in the system the NCC informs the NMC about the RCST. At that time the NMC could automatically send a SNMP SET on a new OID of the MIB of the terminal to the RCST. This SET actually contains a QKE message sent to the RCST (OID defined as octet string). It represents an authentication operation using a pre-defined algorithm and a secret key shared between the NMC operator and the user of the terminal. The RCST uses the string to decode the QKE packet, to execute the authentication procedure and change the value of the OID to the new one so that the NMC can get it afterwards. The RCST will reply in the second get SNMP message the QKE response. The NMC will process it and it will take one of the following options: • Allow the normal functioning of the new terminal. • Raise an alarm to inform the operator about the failure of the authentication (because the SNMP
process didn’ t work, e.g. the first reply was not received, or because the QKE response was not the one expected). The operator should then block the terminal.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
44 / 151
LOCK
SNMP set-response()
SNMP SET (OID= Auth:Octet String)
INFORM
SYNC
TIM
CSC
RCST NCC NMC
IF Failed
Operatoraction
Fine SyncAchieved
SNMP get - response(Auth:OctetString)
SNMP GET (OID= Auth)
Execute Algorithm
Figure 0-2. Flow diagram for the authentication service
1.1.16 Test Platform In order to perform the Authentication Service test for In-Orbit Testing a test setup has to be defined. See below the Test environment proposed:
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
45 / 151
Error !
Figure 0-3. Secur ity test platform
RCST/GW-RCST: The specific RCST/GW-RCST to be authenticated. They include a secret key and the enhanced MIB with new OIDs. The following terminal will be used:
• The GW-RCST will be located in Barcelona (Indra). • A RCST located in Madrid (Alcatel Alenia Space Spain) using the European beam.
NCC: This block informs the NSM that the RCST/GW-RCST is synchronized and routes to the NSM the packets send to its management interface. NSM : The operator starts the authentication procedure from the NSM. I has the authentication toolkit installed. Taking this scenario, the partners involved and equipment to be provided by them in these tests are the following ones: • NERA Satcom: it is in charge of provide an RCST to be installed in Madrid (Alcatel Alenia Space
Spain site) and the MIB of the RCST/GW-RCST. • Alcatel Alenia Space Spain: it must install the authentication toolkit in the NSM, configure the
RCST with a cookie (the secret key), and perform the tests. • Surrey: it must provide the authentication toolkit and give support during the installation and
performance phases.
SATLIFE
RSGW
RCST
NCC
NSM
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
46 / 151
• Indra: It hosts the GW-RCST, which must be configured with the secret key and they will also
give support for STLF_IO_SEC_RSGW test. • Hispamar: performs the test.
1.1.17 Expected Schedule In order to perform these security tests, the following scheduling aspects are: Number of days: 4 days Pre-requisite tested services: STLF_IO_MGMT_RCST.
1.1.18 Technical requirements The technical requirements to perform these security tests are the following: • NET-SNMP toolkit installed in the NSM. • Available satellite bandwidth for the management connection of the RCSTs: 20 Kbps • Available satellite bandwidth for the management connection of the GW-RCST: 20 Kbps
1.1.19 Test procedures
1.1.19.1 RCST authentication procedure Test Reference: STLF_IO_SEC_RCST Subsystem: RCST
Pre-Requisite Tests: STLF_IO_MGMT_RCST Test Platform: In Orbit Objectives: This test verifies the new authentication procedure supported by the authentication application plug in. Test Setup: VSN 1 Test Descr iption: The test checks the authentication procedure of an RCST. This procedure is automatically controlled by the authentication application. This application runs on a PC that belongs to the NMC subnetwork. The authentication application will take as input the RCST profile list provided by the NMC. Once the application is started for a specific RCST: - a first SNMP command is transmitted by the NCC and will set the NMC_nonce object in the RCST MIB - the RCST should then calculate the QKE response and prepare it in QKE OID - the QKE OID is requested from the NCC by a get SNMP The application will get this value, and should give the authentication result: RCST belongs to the satellite network, or it is an intruder. The management operator should then take the necessary actions. Results Expected:
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
47 / 151
Successful RCST authentication process, being able to distinguish between an RCST that belongs to the satellite network from an intruder.
1.1.19.2 RSGW authentication Test Reference: STLF_IO_SEC_RSGW Subsystem: RCST
Pre-Requisite Tests: STLF_IO_MGMT_RCST, STLF_IO_SEC_RCST
Test Platform: In Orbit
Objectives: This test verifies the new authentication procedure supported by the authentication application plug in. Test Setup: VSN 1 Test Descr iption: The test checks the authentication procedure of a GW-RCST. This procedure is automatically controlled by the authentication application. This application runs on a PC that belongs to the NMC subnetwork. The authentication application will take as input the GW-RCST profile list provided by the NMC. Once the application is started for a specific GW-RCST: - a first SNMP command is transmitted by the NCC and will set the NMC_nonce object in the GW-RCST MIB - the GW-RCST should then calculate the QKE response and prepare it in QKE OID - the QKE OID is requested from the NCC by a get SNMP The application will get this value, and should give the authentication result: GW-RCST belongs to the satellite network, or it is an intruder. The management operator should then take the necessary actions. Results Expected: Successful GW-RCST authentication process, being able to distinguish between a GW-RCST that belongs to the satellite network from an intruder.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
48 / 151
MULTICAST TRAFFIC Star IP Multicast service The RSGW provide its subscribers with access to IP multicast flows generated or received by a multicast enabled terrestrial network. The RSGW delivers these multicast flows dynamically on user request. The multicast enabled network may be directly the ISP/Corporate network. Alternatively, if the directly connected network does not support multicast protocols, the RSGW may connect to the multicast enabled network through a GRE tunnel. Only one RSGW per VSN can support the start multicast service. Furthermore, although it is considered as a mere demonstration and not as a official service for SatL ife, Multicast forwarding towards Internet is presented. That is, those multicast flows generated by a user behind an RCST not only will SatLife users be able to receive this multicast flow (mesh multicast) but also potential receivers located at Internet. Thus, the RSGW is in charge of forwarding these multicast flows towards the Multicast backbone according to the PIM-Sparse Mode protocol.
1.1.20 Test Platform In order to perform the Multicast Service test for In-Orbit Testing a test setup has to be defined. To design an organized testing environment, the test setup has been structured breaking it down in to emulation blocks that jointly emulate real tested equipment contour. See below the Test environment proposed: Error !
RSGW
SATLIFE Internet
Emulation Block
Multicast RX Block
Multicast TX Block
NI
Multicast Receiver/
Transmiter
Multicast Receiver
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
49 / 151
Figure 0-4. Multicast test platform
Internet Emulation Block: This emulation block represents the public Internet. Emulation is accomplished through a connection to the Internet and computers connected to it. In particular for these Multicast Tests, this block performs the Multicast Backbone for the multicast routing protocol PIM-Sparse Mode. In this block Rendezvous Point is implemented. Multicast RX Block: This emulation block represents a user wanting to receive a multicast flow whose source is placed behind an RCST (being at the same time a subscriber of the RSGW) in SatLife. Multicast TX Block: This emulation block represents a user sending a multicast flow whose source is placed beyond the RSGW. Taking this scenario, the partners involved and equipment to be provided by them in these tests are the following ones: • NERA Satcom: it is in charge of provide at least two RCSTs to be installed in Madrid (both
Alcatel Alenia Space Spain site) • Alcatel Alenia Space Spain: it must install the RCSTs and provide at least two PCs (one for each
RCST) with the proper software installed to request and send multicast flows. • Indra Espacio: it must provide the RSGW (installed in Barcelona) conveniently configured and
adapted to perform these tests. Moreover this partner is responsible for providing a simulated Internet connection to the RSGW in which PIM-SP multicast routing protocol is supported along with one PC which should be able to send and receive multicast flows.
1.1.21 Expected Schedule In order to perform these multicast traffic tests, the following scheduling aspects are: Number of days: 1 day Pre-requisite tested services: Multicast route management (STLF_IO_MGT_ROUT)
1.1.22 Technical requirements The technical requirements to perform these multicast tests are the following: • Available satellite bandwidth for both RCSTs: 256 Kbps (multicast traffic). • Avaliable satellite bandwidth for the RSGW: No capacity needed.
1.1.23 Test procedures
1.1.23.1 RSGW Multicast reception Test Reference: STLF_IO_MCAST_RSGWRX Subsystem: RCST, RSGW Pre-Requisite Tests: STLF_IO_MGT_ROUT Test Platform: Satlife
connections through RSGW over
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
50 / 151
real Satllite system using Multicast TX and RX block at the simulated Internet
Objectives: Verify that the system continues receiving multicast flows whose source is located at Internet with the new features for the star connectivity. Test Setup: Test tool: VLC application or Iperf. Configure a Multicast flow source in a PC beyond the RSGW (Multicast TX Block). Make sure that the ISP router (Internet Emulation Block) connected to the RSGW supports PIM Sparse Mode Multicast routing protocol. Using the Subscriber Management Tool at the GMM create a new subscriber with the Network Address: “Subscriber 1” . This Network Address will be a private one belonging to the RCST in use. Configure a Multicast flow receiver software in a PC behind the selected RCST.. Test Descr iption: Run the application to start sending multicast flow from the Multicast TX Block. Join the Multicast flow from a PC behind the RCST. Results Expected: The requested Multicast flow is properly forwarded and received by the PC behind the RCST.
1.1.23.2 RSGW Multicast forwarding towards Internet
Test Reference: STLF_IO_MCAST_RSGWFWD_INT Subsystem: RCST, RSGW Pre-Requisite Tests: STLF_IO_MGT_ROUT, “PIMSP.exe” application running in the RSGW
Test Platform: Satlife connections through RSGW over real Satllite system using Multicast TX and RX blocks at the simulated Internet
Objectives: Validate that multicast traffic generated by a subscriber is forwarded towards the Internet only if an Internet user requests the multicast flow. Test Setup: Test tool: Ethereal, to capture IP packets. Using the Subscriber Management Tool at the GMM edit “Subscriber 1” , In this case add a new Network Address which will be a public one. Configure a Multicast flow source in a PC behind the User RCST. This PC must have a public IP address belonging to the Network Address just added. Execute Ethereal to capture multicast packets. Make sure that the DVB-S receiver is configured to forward only mesh multicast flows. Make sure that the ISP router (Internet Emulation Block) connected to the RSGW supports PIM Sparse Mode Multicast routing protocol and IGMP.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
51 / 151
Make sure that the PIM-SP application is running and well configured at the GMM. Configure a Multicast flow receiver software in a PC beyond the RSGW (Multicast RX Block). Test Descr iption: Capture packets at the PC which is going to received the multicast flow. Start sending the multicast flow from the source. Join the Multicast flow from the PC beyond the RSGW (Multicast RX Block) using the corresponding program. Stop packet capture. Results Expected: The multicast flow is not forwarded to the Internet when no user has requested this multicast flow. The requested Multicast flow is properly forwarded and received by the PC beyond the RSGW as soon as this queries it. Packet capture confirms the correct result of the test.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
52 / 151
INTERNET ACCESS Star Internet Access The Internet access service (for full weight RSGWs) provides SATLIFE users with a wide range of new services related to Internet, apart from the basic ones such as: • Accessing to the Internet at rates up to 4 Mbps, with asymmetric rates being possible. • Internet access provided to users with private IP addresses (NATed in the RSGW) • Internet access provided to users with public IP addresses • Internet access may be also initiated from the Internet side for the latter subscribers. The RSGW Service Provider is the responsible for selecting an ISP, which will provide the required Internet access link and supply a range of public IP addresses. The new services (which are located at Internet) includes E-mail, Server Access and Audio Video among others and are intimately related to protocols to be transparently forwarded by the RSGW towards SATLIFE subscribers.
1.1.24 Test Platform In order to perform the Internet Access Service test for In-Orbit Testing a test setup has to be defined. To design an organized testing environment, the test setup has been structured breaking it down in to emulation blocks that jointly emulate real tested equipment contour. See below the Test environment proposed:
Figure 0-5. Internet access test platform
Multiservice Client Block: This block gathers all the client software for all the new multimedia services and applications to be tested. In fact, the HW platform can be just a PC behind the RCST. The client block will be tested with two RCST located in different beams, one in the European beam (Alcatel Alenia Space Spain in Madrid) and other in the Brazilian beam (Hispamar in Guaratiba).
RSGW
SATLIFE
Internet Emulation
Block
Multiservice Server Block
NI
Multiservice Client Block
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
53 / 151
Internet Emulation Block: This emulation block represents the public Internet. Emulation is accomplished through a connection to the Internet and computers connected to it. Multiservice Server Block: This block gathers all the server software for all the new multimedia services and applications to be tested. As before, the HW platform can be just a PC beyond the Internet Emulation Block. Taking this scenario, the partners involved and equipment to be provided by them in these tests are the following ones: • NERA Satcom: it is in charge of provide one RCSTs to be installed in Madrid (Telefonica I+D
site) • Telefonica I+D: it must install the RCSTs and provide at least two PCs: one for Multiservice
Client Block, located at Madrid TID’s facilities, ant the other one for Multiservice Server Block, located at Barcelona Indra’s facilities, both PCs with the proper software installed to perform all the different tests regarding these new multimedia services.
• Indra Espacio: it must provide the RSGW (installed in Barcelona) conveniently configured to perform these tests. Moreover this partner is responsible for providing a simulated Internet connection to the RSGW.
• Hispamar and TPD will perform the tests with the RCSTs located in Brazil and South America.
1.1.25 Expected Schedule In order to perform these tests, the following scheduling aspects are: Number of days: 1 day Pre-requisite tested services: STLF_IF_SERV_NONREGR_STAR
1.1.26 Technical requirements The technical requirements to perform STLF_IO_INTER test are the following: • Available satellite bandwidth for both RCSTs: 150Kbps. • Avaliable satellite bandwidth for the RSGW: 150Kbps.
1.1.27 Test Procedures
1.1.27.1 Internet service Test Reference: STLF_IO_INTER Subsystem: RCST, RSGW Pre-Requisite Tests: STLF_IF_SERV_NONREGR_STAR Test Platform: Satlife
connections through RSGW over real Satllite system using Mulservice client block behind the user RCST and Multiservice server block at the simulated Internet
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
54 / 151
Objectives: Verify that the system continues working properly with the added features for the star connectivity. Test Setup: Configure the VSN with the RSGW. Use a PC behind the RCST belonging to the “Subscriber 1” created before. Install and configure all the necessary software at this PC to build Multiservice Client Block. Install and configure all the necessary software at another PC beyond the RSGW to build Multiservice Server Block. Use PEP if available in the RSGW Test Descr iption: Run the client and server software en each PC of each Multiservice Block. Test the performance of the following common Internet applications, in terms of delay, symmetry of traffic, and minimum required bandwidth:
Web browsing, downloading the test page (using and not using star PEP): http://demo.astra-net.com/download/images2/index.htm
Email Audio/Video Streaming File Transfer Instant Messaging
Results Expected: All the services will work normally. The performance having PEP mesh enabled between two RCSTs is better than without PEP.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
55 / 151
INTRANET ACCESS The Intranet access service provides SATLIFE enterprise users several corporate services like remote desktop management, netmeeting applications, FTP and web browsing using a mesh connectivity. Other services like streaming of video and audio contents will be tested in chapter 0 STREAMING.
1.1.28 Test Platform In order to perform the Intranet Access Service test for In-Orbit Testing a test setup has to be defined. To design an organized testing environment, the test setup has been structured breaking it down in to emulation blocks that jointly emulate real tested equipment contour. See below the Test environment proposed:
Figure 0-6. Intranet access test platform
Multiservice Client Block: This block gathers all the client software for all the new multimedia services and applications to be tested. In fact, the HW platform can be just a PC behind the RCST. The client block will be tested with two RCST located in different beams, one in the European beam (Alcatel Alenia Space Spain in Madrid) and other in the Brazilian beam (Hispamar in Guaratiba). Multiservice Server Block: This block gathers all the server software for all the new multimedia services and applications to be tested. As before, the HW platform can be just a PC beyond the enterprise’s RCST. The partners involved in the following test are: • Telefónica I+D: which provides the server environment. • Alcatel Alenia Space Spain: which provides the client environment for the European beam. • Hispasat: which provides the satellite bandwidth and the RCSTs. • Hispamar and TPD: which provides the client environment for the Brazilian and South American
beam.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
56 / 151
The partners involved are in charge of: • Setup the scenario. • Perform the proposed test procedures. • Analyse and document their results.
1.1.29 Expected schedule The excepted duration for the following tests are 2 days.
1.1.30 Technical requirements The satellite bandwidth needed for Intranet test procedures is 200Kbps.
1.1.31 Test Procedures
1.1.31.1 Intranet service Test Reference: STLF_IO_INTRA_MESH Subsystem: RCST
Pre-Requisite Tests: Test Platform: In Orbit Objectives: Verification of the intranet service, access to the corporate network through the SATLIFE network. Test Setup: VSN1 Test Descr iption: The test will check connectivity access from different PCs and RCSTs to their corporate network. Simple connectivity and also access to different servers should be verified. Two different applications performance will be compared with and without PEP mesh. This two applications are ftp and web browsing. Remote desktop and management between 2 computers placed in different locations/divisions of the same company will be performed. Also a netmeeting communication between the employees of the 2 companies whose LANs are interconnected Results Expected: Successful intranet access, remote desktop connection and netmeeting communication between LANs in different location. The performance having PEP mesh enabled between two RCSTs is better than without PEP.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
57 / 151
SIP SIP stands for Session Initiation Protocol. It is an application-layer control protocol that has been developed and designed within the IETF with easy implementation, good scalability, and flexibility in mind. The SIP protocol is used for creating, modifying and terminating sessions with other participants. By sessions, we understand a sender and a receiver (or user agents) that communicate and the state kept during the communication. The SATLIFE RSGW supports SIP services using a SIP proxy. These SIP services are: • SIP voice calls with ISDN/PSTN terminals • SIP voice/video with SIP terminals located at the Internet • Voice/Video calls with SIP terminals within the same VSN • NATed endpoint support to make voice/video calls being registered in the RSGW SIP proxy
1.1.32 Test Platform In order to perform the SIP VoIP service test for In-Orbit Testing a test setup has to be defined. To design an organized testing environment, the test setup has been structured breaking it down in to emulation blocks that jointly emulate real tested equipment contour. See below the test environment proposed:
Figure 0-7. SIP test platform
RSGW
SATLIFE
Internet
Emulation Block
SIP User Agent
Block #3
ISDN Emulation
Block
NI
SIP User Agent
Block #2
SIP User Agent
Block #1
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
58 / 151
Internet Emulation Block: This emulation block represents the public Internet. Emulation is accomplished through a connection to the Internet and computers connected to it. ISDN Emulation Block: Emulates ISDN functionalities allowing interconnection between endpoints and RSGW. SIP User Agent Block #1: It basically contains two multimedia PCs with SIP softphones installed to make and/or receive SIP VoIP/VC calls: STLF-NERA11 and STLF-NERA12. SIP User Agent Block #2: It basically contains one multimedia PC with a SIP softphone installed to make and/or receive SIP VoIP/VC calls: STLF-NERA21. SIP User Agent Block #3: It basically contains two PCs with a SIP softphone installed to make and/or receive SIP VoIP calls: STLF-IND11 and STLF-IND12. Taking this scenario, the partners involved and equipment to be provided by them in these tests are the following ones: • NERA Satcom: it is in charge of provide two RCSTs to be installed in Madrid (and Alcatel Alenia
Space Spain and Telefonica I+D sites) • Alcatel Alenia Space Spain: it shall have one RCST installed and provide two PCs for with a SIP
User Agent installed (SIP softphone) in each one. • Telefonica I+D: it shall have the RCST installed and provide one PC with a SIP User Agent
installed (SIP softphone). • Indra Espacio: it must provide the RSGW (installed in Barcelona) conveniently configured to
perform these tests. Moreover this partner is responsible for providing a simulated Internet connection and ISDN PRI emulated connection to the RSGW. Along with this, two more PCs with SIP softphones installed shall be provided as well.
1.1.33 Expected schedule In order to perform these tests, the following scheduling aspects are: Number of days: 1 day Pre-requisite tested services: STLF_IF_SERV_NONREGR_STAR
1.1.34 Technical requirements The technical requirements to perform STLF_IO_SIP_SAT test are the following: • Available satellite bandwidth for STLF-NERA11 RCST: SDR=PDR= 400 Kbps • Avaliable satellite bandwidth for STLF-NERA21 RCST: SDR=PDR= 400 Kbps The technical requirements to perform STLF_IO_SIP_ISDN test are the following: • Available satellite bandwidth for STLF-NERA11 and 12 RCST: SDR=PDR= 160 Kbps The technical requirements to perform STLF_IO_SIP_INTER test are the following:
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
59 / 151
• Available satellite bandwidth for STLF-NERA11 and 12 RCST: SDR=PDR= 160 Kbps The technical requirements to perform STLF_IO_SIP_NAT test are the following: • Available satellite bandwidth for STLF-NERA11 and 12 RCST: SDR=PDR= 80 Kbps
1.1.35 Test Procedures
1.1.35.1 SIP internal calls Test Reference: STLF_IO_SIP_SAT Subsystem: RCST, RSGW,
NCC, NMC Pre-Requisite Tests: STLF_IF_SERV_NONREGR_STAR Test Platform: Satlife
connections through RSGW over real Satllite system using SIP User Agent blocks behind the user RCSTs and SIP User Agent block at the simulated Internet. Also the ISDN Emulation block is used for ISDN VoIP calls.
Objectives: Perform VoIP and video calls between to SIP endpoints located behind two different RCSTs and registered at the RSGW SIP proxy. Test Setup: Edit “Subscriber 1” in the Subscriber Management Tool. Enable “Subscriber 1” with H.323/SIP calls and pre-register the STLF-NERA11 SIP user agent. STLF-NERA11 SIP user agent (PC with private IP address) registered in the RSGW SIP proxy. Create “Subscriber 2” in the Subscriber Management Tool. Assign it a public Network Address. Enable “Subscriber 2” with H.323/SIP calls and pre-register the STLF-NERA21 SIP user agent. STLF-NERA21 SIP user agent (PC with public IP address) registered in the RSGW SIP proxy. Test Descr iption: Test tool: Windows Messenger (version 4.7 recommended), Eyebeam or TID Softphone. Set up a SIP voice call from STLF-NERA11 to STLF-NERA21 alias. Hang up the call. Set up a SIP voice call from STLF-NERA21 to STLF-NERA11 alias. Hang up the call. Set up a SIP video call from STLF-NERA11 to STLF-NERA21 alias. Hang up the call. Set up a SIP video call from STLF-NERA21 to STLF-NERA11 alias. Hang up the call. Results Expected: The SIP endpoints can establish the VoIP using SIP alias addresses. The RSGW generates a CDR for the SIP call.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
60 / 151
1.1.35.2 SIP external calls to the ISDN
Test Reference STLF_IO_SIP_ISDN Subsystem: RCST, RSGW, NCC, NMC
Pre-Requisite Tests: STLF_IF_SERV_NONREGR_STAR Test Platform: Satlife connections through RSGW over real Satllite system using SIP User Agent blocks behind the user RCSTs and SIP User Agent block at the simulated Internet. Also the ISDN Emulation block is used for ISDN VoIP calls.
Objectives: Perform a VoIP call between a SIP user behind a SatLife RCST and an ISDN/PSTN user. Test Setup: Edit “Subscriber 1” in the Subscriber Management Tool. Pre-register the STLF-NERA12 SIP user agent and enable this subscriber to make calls towards ISDN. STLF-NERA11 and STLF-NERA12 registered in the RSGW SIP Proxy (as RSGW subscribers with rights to register in the SIP proxy and make calls towards ISDN). It doesn’ t matter if the IP address is public or private. Test Descr iption: Test tool: Windows Messenger (version 4.7 recommended), Eyebeam or TID Softphone. Ethereal to capture VoIP packets. Start packet capture (Ethereal) at PC STLF-NERA11. Perform an outgoing audio call from PC STLF-NERA11 towards an ISDN phone. Stop packet capture (Ethereal) at PC STLF-NERA11 and work out the call establishment by measuring the time difference between the INVITE packet and the ACK packet. Hang up the established call. Perform an audio call from the ISDN towards the SIP user agent in STLF-NERA11. Measure call establishment time. Check perceptual voice quality. Measure voice quality (Impairment Factor provided by the RSGW’s MIB). Perform an outgoing audio call from PC STLF-NERA12 towards an ISDN phone. Check perceptual voice quality. Results Expected: Outgoing call successfully established. Incoming call successfully established. The call establishment takes no longer than 10 sec. The perceptual quality of the call is acceptable. The Impairment Factor of the voice packets is less than 0. A second call can be established from another endpoint behind the same RCST towards ISDN. The perceptual quality of both calls is acceptable.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
61 / 151
1.1.35.3 SIP external calls to the Internet
Test Reference: STLF_IO_SIP_INTER Subsystem: RCST, RSGW, NCC, NMC
Pre-Requisite Tests: STLF_IF_SERV_NONREGR_STAR Test Platform: Satlife connections through RSGW over real Satllite system using SIP User Agent blocks behind the user RCSTs and SIP User Agent block at the simulated Internet. Also the ISDN Emulation block is used for ISDN VoIP calls.
Objectives: To establish a SIP call between two SIP endpoints, one of them located behind an RCST and registered at the RSGW, and the second located in the Internet and registered in an Internet SIP proxy. Test Setup: Test tool: Windows Messenger (version 4.7 recommended), Eyebeam or TID Softphone. Ethereal to capture VoIP packets. SIP proxy installed in a PC behind the RSGW network interface (it represents an external ITSP). SIP user agent in PC STLF-NERA11 and PC STLF-NERA12 are registered at RSGW SIP proxy (as RSGW subscribers with rights to only register in the SIP proxy). Make sure that its IP address is public. The Internet user agent is registered in a different SIP proxy (ITSP), external to SATLIFE network. Test Descr iption: Start packet capture (Ethereal) at PC STLF-NERA11. Set up a voice call from STLF-NERA11 to STLF-IND11 located behind the RSGW NI. Check perceptual voice quality. Stop packet capture (Ethereal) at PC STLF-NERA11 and work out the call establishment by measuring the time difference between the INVITE packet and the ACK packet. Hang up the established call. Set up a voice call from STLF-IND11 located behind the RSGW NI towards STLF-NERA11 Check perceptual voice quality. Set up a voice call from STLF-NERA12 to STLF-IND12 located behind the RSGW NI. Check perceptual voice quality. Results Expected: The call is established when the caller is the Satlife user. The call is established when the caller is the Internet SIP endpoint. The call establishment takes no longer than 10 sec. The perceptual quality of the call is acceptable. A second call can be established for another endpoint behind the same RCST. The perceptual quality of both calls is acceptable.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
62 / 151
1.1.35.4 SIP calls with NATed users
Test Reference STLF_IO_SIP_NAT Subsystem: RCST, RSGW, NCC, NMC
Pre-Requisite Tests: STLF_IF_SERV_NONREGR_STAR Test Platform: Satlife connections through RSGW over real Satllite system using SIP User Agent blocks behind the user RCSTs and SIP User Agent block at the simulated Internet. Also the ISDN Emulation block is used for ISDN VoIP calls.
Objectives: Perform VoIP calls between Satlife subscribers and towards the Internet and ISDN from NATed SIP SATLIFE users while being registered at the RSGW SIP Proxy. Test Setup: Test tool: Windows Messenger (version 4.7 recommended), Eyebeam or TID Softphone. SIP user agents are registered in the RSGW SIP proxy (as RSGW subscribers with rights to register in the SIP proxy). ISDN PRI emulator is connected to the RSGW’s VoIP GW STLF-NERA11, NATed in the RCST STLF-NERA12, non-NATed in the RCST Test Descr iption: Set up a voice call from PC STLF-NERA11 towards STLF-IND11 located in the Internet. Hang up the call. Set up a voice call from PC STLF-NERA11 towards a host located in the ISDN. Hang up the call. Set up a voice call from PC STLF-NERA11 towards PC STLF-NERA12. Hang up the call. Results Expected: A user NATed in the RCST can make a call towards an Internet user. A user NATed in the RCST can make a call towards an ISDN user. A user NATed in the RCST can make a call towards an non-NATed Satlife user.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
63 / 151
H.323 ENHANCEMENTS In SATLIFE project, new H.323 features and improvements are added to the old ones already offered in AmerHis network. These new features can be summarized that way: • NATed endpoints support: it supports NAT traversal when it is placed at the RCST, allowing a
H.323 terminal, which is NATed at the subscriber RCST, to make voice/video calls towards ISDN/PSTN, Internet H.323 endpoints and non-NATed H.323 endpoints within the same VSN.
• Call termination optimization for ISDN/PSTN voice/video calls (external ITSPs): it allows optimizing the termination of the H.323 voice/video service by not terminating an ISDN/PSTN call initiated by a SATLIFE user necessarily in the subscriber’s RSGW, but by using a collaborating external ITSP node.
• Internet calls improvements (GK proxy mode): thanks to improved NAT traversal functionality, a SATLIFE H.323 endpoint with private IP address (NATed in the RSGW) can be actively registered with the RSGW Gatekeeper while placing calls towards H.323 users located in the Internet.
1.1.36 Test Platform In order to perform the H.323 enhancements test for In-Orbit Testing a test setup has to be defined. To design an organized testing environment, the test setup has been structured breaking it down in to emulation blocks that jointly emulate real tested equipment contour. See below the test environment proposed:
Figure 0-8. H.323 test platform
Internet Emulation Block: This emulation block represents the public Internet. Emulation is accomplished through a connection to the Internet and computers connected to it.
RSGW
SATLIFE
Internet Emulation
Block
H.323 ITSP Block
ISDN Emulation
Block
NI
H.323 Endpoint
Block
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
64 / 151
ISDN Emulation Block: Emulates ISDN functionalities allowing interconnection between endpoints and RSGW. H.323 Endpoint Block: It basically contains two multimedia PCs with H.323 softphones installed to make and/or receive h.323 VoIP/VC calls: STLF-NERA11 and STLF-NERA12. H.323 ITSP Block: It is composed by two PCs emulating an external ITSP (GK+ISDN VoIP GW): STLF-IND11 and STLF-IND12. Taking this scenario, the partners involved and equipment to be provided by them in these tests are the following ones: • NERA Satcom: it is in charge of provide one RCST to be installed in Madrid (and Alcatel Alenia
Space Spain site) • Alcatel Alenia Space Spain: it shall have one RCST installed and provide two PCs for with a
H.323 endpoint installed (H.323 softphone) in each one. • Indra Espacio: it must provide the RSGW (installed in Barcelona) conveniently configured to
perform these tests. Moreover this partner is responsible for providing a simulated Internet connection and ISDN PRI emulated connection to the RSGW. Along with this, two more PCs in order to implement an external ITSP.
1.1.37 Expected schedule In order to perform these tests, the following scheduling aspects are: Number of days: 1 day Pre-requisite tested services: STLF_IF_SERV_NONREGR_STAR
1.1.38 Technical requirements The technical requirements to perform STLF_IO_H323_NAT test are the following: • Available satellite bandwidth for STLF-NERA11 and 12 RCST: SDR=PDR= 80 Kbps The technical requirements to perform STLF_IO_H323_ITSP test are the following: • Available satellite bandwidth for STLF-NERA11 RCST: SDR=PDR= 80 Kbps The technical requirements to perform STLF_IO_H323_PROX test are the following: • Available satellite bandwidth for STLF-NERA11 and 12 RCST: SDR=PDR= 80 Kbps
1.1.39 Test procedures
1.1.39.1 H.323 calls with NATed users Test Reference STLF_IO_H323_NAT Subsystem: RCST, RSGW,
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
65 / 151
NCC, NMC Pre-Requisite Tests: STLF_IF_SERV_NONREGR_STAR Test Platform: Satlife
connections through RSGW over real Satllite system using H.323 Endpoints block behind the user RCST and H.323 ITSP block at the simulated Internet. Also the ISDN Emulation block is used for ISDN VoIP calls.
Objectives: Perform VoIP calls between Satlife subscribers and towards the Internet and ISDN from NATed H.323 SATLIFE users while being registered at the RSGW GK. Test Setup: Test tools: Openphone. Edit “Subscriber 1” in the Subscriber Management Tool. Pre-register the STLF-NERA11 H.323 endpoint in the Gatekeeper with an private IP address which we know that is NATed at the RCST. Pre-register the STLF-NERA12 H.323 endpoint in the Gatekeeper with private IP address non-NATed in the RCST. Make sure that “Subscriber 1” has “ ISDN calls” enabled. ISDN PRI emulator is connected to the RSGW’s VoIP GW. Test Descr iption: Set up a voice call from PC STLF-NERA11 towards a host located in the Internet. Hang up the call. Set up a voice call from PC STLF-NERA11 towards a host located in the ISDN. Hang up the call. Set up a voice call from PC STLF-NERA11 towards PC STLF-NERA12. Hang up the call. Results Expected: A user NATed in the RCST can make a call towards an Internet user. A user NATed in the RCST can make a call towards an ISDN user. A user NATed in the RCST can make a call towards an non-NATed Satlife user.
1.1.39.2 H.323 call to external ITSP
Test Reference STLF_IO_H323_ITSP Subsystem: RCST, RSGW, NCC, NMC
Pre-Requisite Tests: STLF_IF_SERV_NONREGR_STAR Test Platform: Satlife connections through RSGW over real Satllite system using H.323 Endpoints block behind the user RCST and H.323 ITSP block at the simulated Internet. Also the ISDN Emulation block is used for
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
66 / 151
ISDN VoIP calls. Objectives: Termination of a call initiated from SATLIFE H.323 user in an external ITSP. Test Setup: Test tool: Netmeeting or Openphone. Open the RSGW Management Tool and then enter the H.323 ITSP configuration. Configure RSGW to locally terminate voice calls beginning with 00 34. Configure external ITSP data to route international prefix 81. This ITSP shall be the first option and the default one the RSGW. Configure external ITSP in order to be able to receive calls from a particular international prefix (00 81). Place a PC (H.323 endpoint) which represents the destination number and register the endpoint in the external ITSP Gatekeeper. Edit “Subscriber 1” in the Subscriber Management Tool. Change the IP address of STLF-NERA11 PC to a IP public address belonging to the configured public Network Address. Pre-register the STLF-NERA11 H.323 endpoint in the Gatekeeper with an public IP address. Test Descr iption: Place a voice call from STLF-NERA11 towards a destination with prefix 0034. Hang up the call. Place a voice call from the same endpoint directed to an external ITSP by dialling an international prefix to be routed by this particular ITSP (00 81). Results Expected: Call termination (locally or externally) does depend on the dialed prefix.
1.1.39.3 H.323 calls using GK Proxy Mode
Test Reference STLF_IO_H323_PROX Subsystem: RCST, RSGW, NCC, NMC
Pre-Requisite Tests: STLF_IF_SERV_NONREGR_STAR Test Platform: Satlife connections through RSGW over real Satllite system using H.323 Endpoints block behind the user RCST and H.323 ITSP block at the simulated Internet. Also the ISDN Emulation block is used for ISDN VoIP calls.
Objectives: The H.323 endpoints with IP private addresses and NATed at the Access Router can make a call towards Internet being actively registered in the Gatekeeper. Test Setup: Test tool: Openphone. Open the RSGW Management Tool and then enter the GK proxy configuration. Insert the Network Addresses of the “Subscriber 1” (private and public) into the corresponding field. So H.323 STLF-NERA11 endpoint (with private IP address) is configured to use GK ‘proxy’
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
67 / 151
mode and H.323 STLF-NERA12 endpoint (with public IP address) configured to use GK ‘proxy’ mode as well. Open the Subscriber Management Tool and edit “Subscriber 1” . Disable the option for “ ISDN calls” and leave the “GK registration” as the only enabled one. Make sure that the SFLF-NERA11 IP address is not NATed at the RCST but in the Access Router NAT. Test Descr iption: Set up a voice call from STLF-NERA11 (private IP) towards an H.323 endpoint located in the Internet. Hang up the call. Set up a voice call from STLF-NERA12 (public IP) towards an H.323 endpoint located in the Internet. Hang up the call. Set up a voice call from STLF-NERA11 towards STLF-NERA12. Results Expected: For calls initiated from endpoint 1 towards an Internet host the GK proxy mode is used. For calls initiated from endpoint 2 towards an Internet host the GK proxy mode is used. For calls initiated from endpoint 1 towards endpoint 2, GK proxy mode is not used.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
68 / 151
VIDEO ON-DEMAND The objective of the real system tests is the verification in-orbit of all the service capabilities defined in D321 and D322 for the Video on Demand service, which are accessed through the different interfaces provided to the service components. Trough this set of test procedures, IP, UDP, TCP, RTSP protocols will be checked between the VOD server and the set-top-box using the satellite in regenerative mode.
1.1.40 Test Platform The test platform used for the real system tests is a Unix machine with the VOD server connected to a RCST in the server side and another RCST connected to an IP set-top-box that will be used to visualize the videos in a TV set. We will use the same IP set-top-box for MPEG-2 and MPEG-4 AVC / H.264 contents: an ADB model 3100. The list with the needed equipment for the Video on demand test is composed by: • A PC with Linux S.O. with the VOD and web servers installed. • Two DVB-RCSTs configured in regenerative mode, one for the server side and another for the
client side. • The Amazonas satellite. • An ADB 3100 set-top-box and a TV set.
Figure 0-9 Video On Demand test platform
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
69 / 151
The partners involved in the following test are: • TID: which provides the servers and the set-top-box. • AAS-E: which provides the SATLIFE network configuration. • HIS: which provides the satellite bandwidth and the RCST. TID and AAS-E are in charge of: • Setup the scenario. • Perform the proposed test procedures. • Analyse and document their results.
1.1.41 Expected schedule The excepted duration for the following tests are 3 days. This service should be tested with the NVOD service because both services share the same test platform.
1.1.42 Technical requirements The satellite bandwidth needed for VOD test procedures is 2Mbps.
1.1.43 Test procedures
1.1.43.1 Browse the web server searching a content Test Reference: STLF_IO_CSP_VOD_001 Subsystem:
Content Service Provider VOD, RCST, NCC.
Pre-Requisite Tests:
Test Platform:
In-orbit VOD test platform Objectives: The purpose of the test is to verify the access to the VOD web server. Test Setup: Set up and start the VOD test platform Test Descr iption: - Connect to the set-top-box. Automatically the main page of the web server will appear. - Navigate through the options and menus dispatched by the server. Results: The set-top-box will display the options available within current VOD contents that could be accessed by the user. Each content will have a link on it to request such content to the VOD server
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
70 / 151
1.1.43.2 Selecting a content and start a new VOD session Test Reference: STLF_IO_CSP_VOD_002 Subsystem:
Content Service Provide r VOD, RCST, NCC.
Pre-Requisite Tests: STLF_LS_CSP_VOD_001
Test Platform:
In-orbit VOD test platform Objectives: The purpose of the test is to verify the selection process of a VOD content Test Setup: Set up and start the VOD test platform Test Descr iption: - Select with the remote control the link or picture that represents the ‘VOD Contents’ in the
web server. - Select the first content in the list and click OK in the remote control. Results: The set-top-box will create a new RTSP client and will send DESCRIBE, SETUP and PLAY commands to the VOD server. It will be possible to run a network sniffer to check these commands. The set-top-box will begin to display the selected content in the TV screen. It will be possible to run a network sniffer or snoop command in the VOD server in order to check that there are many UDP packets going from the VOD server to the set-top-box IP.
1.1.43.3 User Video Operations Test Reference: STLF_IO_CSP_VOD_003 Subsystem:
Content Service Provider VOD, RCST, NCC.
Pre-Requisite Tests: STLF_LS_CSP_VOD_002
Test Platform:
In-orbit VOD test platform
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
71 / 151
Objectives: The purpose of the test is to verify the user video command in a VOD session, including the pause, start, fast-forward, fast-rewind and stop (end of VoD session). Test Setup: Set up and start the VOD test platform Test Descr iption: - Press the pause button in the remote control. - Press the play button in the remote control. - Wait several minutes and disconnect the Ethernet cable from the set-top-box. - Connect the Ethernet cable again. - Press the fast forward button in the remote control. - Press the fast rewind button in the remote control. - Press the stop button in the remote control. Results: Pause. The set-top-box will freeze the current image that is displayed at this moment on the TV screen. It will be possible to run a network sniffer or snoop command in the VOD server in order to check that there isn't any UDP packet going from the VOD server to the set-top-box's IP address. Play. The set-top-box will unfreeze the current image that is displaying at this moment in the TV screen and will begin to visualize the content at this specific point. It will be possible to run a network sniffer or snoop command in the VOD server in order to check that there are many UDP packets going from the VOD server to the set-top-box IP address. When the Ethernet cable is disconnected the video and audio stream will be lost, but they will be recovered in a few seconds when the Ethernet cable is connected again. Fast-forward (reverse). The set-top-box will visualize individual I frames in a (reverse) chronological order from the current content at the same bitrate than in normal mode. It will be possible to run a network sniffer or snoop command in the VOD server in order to check that there are many UDP packets going from the VOD server to the set-top-box IP address. Stop, end a existing VoD session. The set-top-box will stop to visualize the current content. It will be possible to run a network sniffer or snoop command in the VOD server in order to check that there is any UDP packet going from the VOD server to the set-top-box IP address.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
72 / 151
NEAR VIDEO ON-DEMAND The objective of the real system tests is the verification in-orbit of all the service capabilities defined in D321 and D322 for the Near Video on Demand service, which are accessed through the different interfaces provided to the service components. This set of test procedures will use the satellite in regenerative mode.
1.1.44 Test Platform The test platform used for the NVOD real system tests is similar than VOD platform, it is composed by a Unix machine and a RCST in the server side and another RCST and an IP set-top-box that will be used to visualize the videos in a TV set. We will use the same IP set-top-box for MPEG-2 and MPEG-4 AVC / H.264 contents: an ADB model 3100. The list with the needed equipment for the Video on demand test is composed by: • A PC with Linux S.O. with the NVOD server installed. • Two DVB-RCSTs configured in regenerative mode, one for the server side and another for the
client side. • The Amazonas satellite. • An ADB 3100 set-top-box and a TV set.
Figure 0-10 Near Video On Demand test platform
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
73 / 151
The partners involved in the following test are: • TID: which provides the servers and the set-top-box. • AAS-E: which provides the SATLIFE network configuration. • HIS: which provides the satellite bandwidth and the RCST. TID and AAS-E are in charge of: • Setup the scenario. • Perform the proposed test procedures. • Analyse and document their results.
1.1.45 Expected schedule The excepted duration for the following tests are 2 days. This service should be tested with the VOD service because both services share the same test platform.
1.1.46 Technical requirements The satellite bandwidth needed for NVOD test procedures is 2Mbps.
1.1.47 Test procedures
1.1.47.1 Start a new NVOD session Test Reference: STLF_IO_CSP_NVOD_001 Subsystem:
Content Service Provider NVOD, RCST, NCC.
Pre-Requisite Tests:
Test Platform:
In-orbit NVOD test platform
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
74 / 151
Objectives: The purpose of the test is to verify the launch of a new NVOD session Test Setup: Set up and start the NVOD test platform Test Descr iption: - Start a new NVOD session specifying the multicast IP address and a content file. Results: The NVOD server start a new session writing the multicast UDP packets that contains the requested content at the appropriate bitrate. It will be possible to run a network sniffer or snoop command in the server’s LAN in order to check that the NVOD server is writing these UDP packets. Perform this test with MPEG-2 and H.264 contents.
1.1.47.2 Selecting a content and join to a NVOD session Test Reference: STLF_IO_CSP_NVOD_002 Subsystem:
Content Service Provider NVOD, RCST, NCC.
Pre-Requisite Tests: STLF_IO_CSP_NVOD_001
Test Platform:
In-orbit NVOD test platform Objectives: The purpose of the test is to verify the selection process of a NVOD content Test Setup: Set up and start the NVOD test platform Test Descr iption: - Select with the remote control the link or picture that represents the NVOD section in the STB. Results: The set-top-box will join to the multicast group which the NVOD server is sending its content. The set-top-box will begin to display the selected content in the TV screen. It will be possible to run a network sniffer or snoop command in the LAN in order to check that the STB has sent a JOIN multicast command to the specific multicast IP address of the requested content. Perform this test with MPEG-2 and H.264 contents.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
75 / 151
1.1.47.3 Leave from a NVOD session Test Reference: STLF_IO_CSP_NVOD_003 Subsystem:
Content Service Provider NVOD, RCST, NCC.
Pre-Requisite Tests: STLF_IO_CSP_NVOD_002
Test Platform:
In-orbit NVOD test platform Objectives: The purpose of the test is to verify that the STB leaves the NVOD session. Test Setup: Set up and start the NVOD test platform Test Descr iption: - Select with the remote control the link the stop button to finalize the NVOD session. Results: The set-top-box will leave from the multicast group which the NVOD server is sending its content. The set-top-box will stop to display the selected content in the TV screen. It will be possible to run a network sniffer or snoop command in the LAN in order to check that the STB has sent a LEAVE multicast command to the specific multicast IP address of the requested content.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
76 / 151
1.1.47.4 Stop the NVOD session Test Reference: STLF_IO_CSP_NVOD_004 Subsystem:
Content Service Provider NVOD, RCST, NCC.
Pre-Requisite Tests: STLF_IO_CSP_NVOD_003
Test Platform:
In-orbit NVOD test platform Objectives: The purpose of the test is to verify the end of a NVOD session. Test Setup: Set up and start the NVOD test platform Test Descr iption: - Finish the open NVOD session from the NVOD server. Results: Stop the current NVOD session. It will be possible to run a network sniffer or snoop command in the LAN in order to check that the NVOD server is not writing any UDP packet. Perform this test with MPEG-2 and H.264 contents.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
77 / 151
STREAMING The objective of the real system tests is the verification in-orbit of all the service capabilities defined in D321 and D322 for the streaming service. This service is composed by several scenarios that contain Windows Media, Real Networks, Darwin and Telefónica I+D video streaming servers. All these scenarios will be tested in-orbit using the satellite in regenerative mode. The scenarios that will be considered are:
• Windows Media Streaming Server • Real Networks Streaming Server • Darwin Streaming Server • Telefónica I+D Streaming Server
1.1.48 Test Platform The test platform used for the real system tests is composed by several windows and Linux machines connected to a RCST in the server side and another RCST connected to a PC that will be used to visualize the streaming contents. The list with the needed equipment for the streaming tests is composed by: • The Amazonas satellite. • For the server side:
o Windows Media specific equipment: - One PC with Windows O.S with Windows Media Services 9.
o Real Networks specific equipment: - One PC with Linux O.S and the TID capturer software. - One PC with Linux O.S with Helix Universal Server version 9.04. - An IP camera for the real time contributions.
o Darwin specific equipment - One PC with Linux with Darwin Streaming Server version 3.0.1 and the web
administration. o Telefónica I+D specific equipment:
- One PC with Linux O.S with the Telefónica I+D Streaming Server. o Common server side equipment:
- One RCST configured in regenerative mode. • For the client side:
o One PC with Windows O.S. and Windows media player version 10, Real player version 10, QuickTime version 7 and VLC player.
o One RCST configured in regenerative mode. The proposed test platform is depicted in the following figure:
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
78 / 151
Figure 0-11 Streaming test platform
The partners involved in the following test are: • TID: which provides the servers, cameras and the configuration of the client. • AAS-E: which provides the SATLIFE network configuration and perform the tests in the client
side with a RCST located in Madrid that uses the European beam. • Hispasat: which provides the satellite bandwidth and the RCST. • Hispamar and TPD: which perform the tests in the client side with a RCST located in Guaratiba
that uses the Brazilian beam and another one in Sao Paulo. The partners involved are in charge of: • Setup the scenario. • Perform the proposed test procedures. • Analyse and document their results.
1.1.49 Expected schedule The excepted duration for the following tests are 3 days. There are no dependences with other tests.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
79 / 151
1.1.50 Technical requirements The satellite bandwidth needed for NVOD test procedures will depend on the specific test, and it will be from 100Kbps to 2Mbps.
1.1.51 Windows Media test procedures
1.1.51.1 On-demand publishing points Test Reference: STLF_IO_CSP_STREAM_001 Subsystem:
Content Service Provider Streaming, RCST, NCC.
Pre-Requisite Tests:
Test Platform:
In-orbit streaming test platform
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
80 / 151
Objectives: The purpose of this test is to verify the Windows Media streaming test platform and the on-demand publishing points all the way from the server to the client side. Test Setup: Set up and start the streaming test platform Test Descr iption: - Log-on into the Windows Media server as Administrator O.S. user. - Create a new on-demand publishing point. On-demand publishing points are used when you
want the client to be able control playback of the stream. You will need to specify an alias, a path and the maximum number of users and bandwidth.
- Load any Windows Media content inside the contents directory. - Open the Windows Media player and select Open URL. Input the specific content URL. This
URL will be in the form mms://192.168.100.2/videotest.wm Where 192.168.100.2 is the Windows Media server IP and videotest.wm the name of the requested video file.
Results: The Windows Media player will resize its window to the specific content resolution and will load the initial seconds of this content into its buffer in order to continue working when the video or audio bitrate decreases due to networks problems. After that, Windows Media player will visualize the requested content. It will be possible to do the following actions. Each of them will produce a specific dialog with the server: Pause the content, Restart the content, Stop the content and Move the actual position to an ahead or previous section It will be possible to check the bitrate received, the packet loss ratio, and the frame rate in the statistics window. It will be possible to select video files in Windows Media formats. It will be possible to use HTTP transmission in order to work with firewalls configurations.
1.1.51.2 Multicast publishing points Test Reference: STLF_IO_CSP_STREAM_003 Subsystem:
Content Service Provider Streaming, RCST, NCC.
Pre-Requisite Tests: STLF_IO_CSP_STREAM_002
Test Platform:
In-orbit streaming test platform
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
81 / 151
Objectives: The purpose of the test is to verify the Windows Media streaming test bed and the multicast publishing points Test Setup: Set up and start the streaming test platform Test Descr iption: - Log-on into the Windows Media server as Administrator S.O. user. - Create a new multicast publishing point. Multicast publishing points are a kind of broadcast
publishing point but with unicast streaming disable and running a multicast writer plug-in that push data towards an multicast IP address. Multicast configuration is very similar to Broadcast, except it must be announced since Media Player can only connect to a server IP address not a multicast one.
- Associate a file as the Input source of the transmission. - Start the transmission. - Open the Windows Media player and select Open URL. Input the specific content URL. This
URL will be in the form http://wmserv:port/slife_mcast.nsc. Where wmserv is the Windows Media Services server IP address and port is the TCP port where the associated web server is listening to.
Results: The Windows Media player will resize its window to the specific content resolution and will load the initial seconds of this content into its buffer in order to continue working when the video or audio bitrate decreases due to networks problems. After that, Windows Media player will visualize the requested content. It will be possible to check the bitrate received, the packet loss ratio, and the frame rate in the statistics window. This test is oriented to content with Windows Media formats.
1.1.51.3 Multi-bitrate unicast Test Reference: STLF_IO_CSP_STREAM_004 Subsystem:
Content Service Provider Streaming, RCST, NCC.
Pre-Requisite Tests: STLF_IO_CSP_STREAM_003
Test Platform:
In-orbit streaming test platform
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
82 / 151
Objectives: The purpose of the test is to verify the Windows Media streaming test bed and the multi bitrate unicast publishing points Test Setup: Set up and start the streaming test platform Test Descr iption: - Log-on into the Windows Media server as Administrator S.O. user. - Create a new unicast publishing point. Unlike the previous publishing point modes, MBR
unicast is not a publishing mode itself but a different performance mode. When an MBR file is used for a publishing point, if the player has detected a suboptimal network condition (low bitrate, jamming, etc.) the server is able to strike back at these shortfalls, broadcasting a lower bitrate version of the original content. This adaptive behaviour allows to reach higher levels of service usage over even the worst circumstances.
- You will need a file previously encoded in a multi-bitrate fashion. - Open the Windows Media player and select Open URL. Input the specific content URL. This
URL will be in the form mms://wmserv/slife_mrate. Where wmserv is the Windows Media Services server IP address and port is the TCP port where the associated web server is listening to.
Results: The Windows Media player will resize its window to the specific content resolution and will load the initial seconds of this content into its buffer in order to continue working when the video or audio bitrate decreases due to networks problems. On that first stage, media bitrate is negotiated according to the network conditions or Media Player network settings. After that, Windows Media player will visualize the requested content. It will be possible to check the bitrate received, the packet loss ratio, and the frame rate in the statistics window. This test is oriented to content with Windows Media formats.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
83 / 151
1.1.52 Real Networks test procedures
1.1.52.1 Unicast with stored files Test Reference: STLF_IO_CSP_STREAM_005 Subsystem:
Content Service Provider Streaming, RCST, NCC.
Pre-Requisite Tests:
Test Platform:
In-orbit streaming test platform Objectives: The purpose of the test is to verify the Helix streaming test bed and the unicast transmissions all the line from the server to the client side using stored local files Test Setup: Set up and start the streaming test platform Test Descr iption: - Log-on into the Helix streaming server as root S.O. user. - Load any RM content inside the contents directory. - Check that the Helix streaming server is running. - Open Real player and select Open URL. Input the specific content URL. This URL will be in
the form rtsp://192.168.100.2/videotest.rm Where 192.168.100.2 is the video server IP and videotest.rm the name of the requested video file.
Results: Real player will resize its window to the specific content resolution and will load the initial seconds of this content into its buffer in order to continue working when the video or audio bitrate decreases due to networks problems. After that, Real player will visualize the requested content. It will be possible to do the following actions. Each of them will produce an RTSP dialog with the server.
− Pause the content − Restart the content − Stop the content
Move the actual position to an ahead or previous section It will be possible to select video files in Real Media and MPEG-4 formats. It will be possible to use HTTP transmission in order to work with firewalls configurations.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
84 / 151
1.1.52.2 Streaming video to more than one person Test Reference: STLF_IO_CSP_STREAM_006 Subsystem:
Content Service Provider Streaming, RCST, NCC.
Pre-Requisite Tests: STLF_IO_CSP_STREAM_005
Test Platform:
In-orbit streaming test platform Objectives: The purpose of the test is to verify the Helix streaming test bed and the unicast transmissions using real time contributions Test Setup: Set up and start the streaming test platform Test Descr iption: - Log-on into the Helix streaming server as root O.S. user. - Start the capturer software using the camera IP address and port 554. The connection string
will be rtsp://192.168.0.4:554/live.sdp. Where 192.168.100.4 is the camera IP address, 554 is the RTSP port and live.sdp the SDP file that describes the content.
- Configure the capturer software to send all RTP packets to a specific port of the Helix server. - Check with any traffic sniffer that there are UDP packets going from the IP camera to the
capturer and from the capturer to the Helix server. - Configure a new SDP file in the Helix server to receive the RTP packets. It will be needed 2
ports for audio and 2 for video. - Open the Real player and select Open URL. Input the specific content URL. This URL will be
in the form rtsp://192.168.0.1/mystream.sdp Where 192.168.0.1 is the Helix server IP address and mystream.sdp is the specific SDP created for this test procedure.
Results: Real player will resize its window to the specific content resolution and will load into its buffer the initial seconds of this content in order to continue working when the video or audio bitrate decreases due to networks problems. After that, Real player will visualize the requested content. It will be possible to do the following actions. Each of them will produce an RTSP dialog with the server. - Pause the content - Restart the content - Stop the content This test is oriented to content with MPEG-4 formats. It will be possible to use HTTP transmission in order to work with firewalls configurations. Almost real-time live broadcasting (less than 1 second)can be achieved by changing some settings at the IP camera, Helix Universal Server as well as the Real Player.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
85 / 151
1.1.53 Darwin test procedures
1.1.53.1 Unicast with stored files Test Reference: STLF_IO_CSP_STREAM_008 Subsystem:
Content Service Provider Streaming, RCST, NCC.
Pre-Requisite Tests:
Test Platform:
In-orbit streaming test platform Objectives: The purpose of this test is to verify the Darwin streaming test bed and the unicast transmissions using stored local files Test Setup: Set up and start the streaming test platform Test Descr iption: - Log-on into the Darwin streaming server as root S.O. user. - Load any QT content inside the contents directory. - Check that the Darwin streaming server is running. - Open the QT player and select Open URL. Input the specific content URL. This URL will be
in the form rtsp://192.168.100.2/videotest.mov Where 192.168.100.2 is the video server IP and videotest.mov the name of the requested video file.
Results: The QT player will resize its window to the specific content resolution and will load the initial seconds of this content into its buffer in order to continue working when the video or audio bitrate decreases due to networks problems. After that, QT player will visualize the requested content. It will be possible to do the following actions. Each of them will produce an RTSP dialog with the server: Pause the content, Restart the content, Stop the content, Move the actual position to an ahead or previous section. It will be possible to check the bitrate received, the packet loss ratio, and the buffer size in the QT player. For that, select the film properties. It will be possible to select video files in QT and MPEG-4 formats. It will be possible to use HTTP transmission in order to work with firewalls configurations.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
86 / 151
1.1.54 Telefónica I+D test procedures
1.1.54.1 Unicast with stored files Test Reference: STLF_IO_CSP_STREAM_0010 Subsystem:
Content Service Provider Streaming, RCST, NCC.
Pre-Requisite Tests:
Test Platform:
In-orbit streaming test platform Objectives: The purpose of the test is to verify the unicast transmission mode of the Telefónica I+D server using stored local files Test Setup: Set up and start the streaming test platform Test Descr iption: - Log-on into the Telefónica I+D server as root S.O. user. - Load any MPEG-2 or H264 content inside the contents directory. This content must have
MPEG-2 TS format. - Check that server processes are running. - Open VLC media player v0.8.2 and select Open URL. Input the specific content URL. This
URL will be in the form rtsp://192.168.100.2/videotest Where 192.168.100.2 is the video server IP and videotest the name of the requested video file.
Results: The player will resize its window to the specific content resolution and will load into its buffer the initial seconds of this content in order to continue working when the video or audio bitrate decreases due to networks problems. After that, the player will visualize the requested content. It will be possible to do the following actions. Each of them will produce an RTSP dialog with the server: Pause the content, Restart the content, Stop the content, Move forward and rewind the video position.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
87 / 151
1.1.54.2 Multicast with stored files Test Reference: STLF_IO_CSP_STREAM_011 Subsystem:
Content Service Provider Streaming, RCST, NCC.
Pre-Requisite Tests: STLF_IO_CSP_STREAM_010
Test Platform:
In-orbit streaming test platform Objectives: The purpose of the test is to verify the multicast transmission mode of the Telefónica I+D server using stored local files Test Setup: Set up and start the streaming test platform Test Descr iption: - Log-on into the Telefónica I+D server as root S.O. user. - Load any MPEG-2 or H264 content inside the contents directory. This content must have
MPEG-2 TS format. - Begin a multicast transmission selecting one content and its bitrate. - Open VLC media player v0.8.2 and select Open URL. Input the specific content URL. This
URL will be in the form udp://224.0.0.1:1234 Where 224.0.01 is the selected multicast IP address and 1234 is the port related with this multicast transmission.
Results: The player will resize its window to the specific content resolution and will load into its buffer the initial seconds of this content in order to continue working when the video or audio bitrate decreases due to networks problems. After that, Real player will visualize the requested content. It will be possible to do the following actions: Pause the content, Restart the content, Stop the content.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
88 / 151
E-LEARNING This section will provide a Test Plan for the “Webcast with Low Interactivity for Corporative Services (e-Learning, …)” defined in SATLIFE deliverables D321/D322. This test plan comprises the test design, test cases definition, and test procedures. The objective of the real system tests is the verification in-orbit of all the service capabilities defined in D321 and D322 for this service, which are accessed through the different interfaces provided to the service components. The multicast SATLIFE network capabilities are fully exploited.
1.1.55 Test Platform The test platform used for the real system tests is a based on VSN1 configuration, which includes the equipments for the Webcast service:
• “Server” , • “Live Event station (Encoder+M&C)” , • TID RCST configured in regenerative mode. • End users (Multimedia PCs). At least two End users are requires:
o 1 connected to a terrestrial network reachable from the GW in multicast o 1 Connected to a RCST configured in regenerative mode. It will be several RCST
connected to different beams: European (TID/AAS-E), Brazilian (Hispamar/TPD) and South America (Hispamar/TPD)
This platform is shown in the figure below:
MR RSGWk
SPi Multicast EUs
BR Users
Users
EU1
EU2
EU3
EUn
RCST
Users
DVB-S
Sat. Network Domain
Speaker/Teacher
Multicast to Satellite and ter restr ial users (Througth the RSGW/MR).
Server
Encoder+M&C
RCSTk
TID Premises
DIT-UPM Premises
Terrestrial Connection
(Tunnel or ISDN)
Figure 0-12 Test platform for real system (Webcast-E-Learning Service)
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
89 / 151
The partners involved in the following test are: • AAS-E: which provides the SATLIFE network configuration, including one end-user. • HIS: which provides the satellite bandwidth and the RCST. • UPM: which provides the service equipments and performs the M&C of the service. UPM will
install and configure the e-learning servers in the AAS-E premises. • TID: which collaborates in the tests and includes one end-user. • Hispamar/TPD: which collaborates in the tests and includes two end-user. The partners involved in these tests are in charge of: • Setup the scenario. • Perform the proposed test procedures. • Analyse and document their results.
1.1.55.1 Tests Setup
• Make sure that the “Live Event Station (Encoder+M&C)” and the “Server” are properly installed following the manufacturing manuals.
• After installation, some demo contents are available for at least two demo companies. These contents will be used in the tests.
• Pass all the test cases specified in service test procedures section. All the test cases are executed sequentially without restarting of any machine.
1.1.56 Expected schedule The excepted duration for the following tests are 3 days.
1.1.57 Technical requirements The satellite bandwidth needed for these test procedures is 2Mbps.
1.1.58 Test procedures The objective of this real system testing plan is verification of all the service capabilities defined in D321/D322 which are acceded through the different interfaces provided to the service agents. Therefore, all this capabilities and interfaces are tested in a real system environment. The service capabilities to be tested the same as the in laboratory tests (D331), they are organised as: Tele-Services Testing:
• Live Events/Courses Tests • Deferred Events/Courses Tests • On-Demand Express Tests • On-Demand Multimedia Repository Tests
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
90 / 151
Supplementary Services:
• Multi-Platform Tests • Low interactivity service based on integrated Chat service (for live events) Tests. • Simultaneous Translation Tests. • Multilingual Contents Tests. • Synchronised content presentation Tests • Downloading of additional conference information Tests
The test cases and procedures are based on the in-laboratory tests defined in D331.
1.1.58.1 Tele-service: Live Events/Courses Tests The main objective of this test group is to evaluate this service capability checking the Content Acquisition Portal interface (CAP), the Multimedia Contents Load interface (CLP), the live event announcement though the user application interfaces (UAP), and the live course occurrence on which most of the system components are involved. Test Reference: STLF_IO_CSP_ELRN_ Live.001 Subsystem:
Webcasting with low interactivity for corporative services, RCST, NCC.
Pre-Requisite Tests:
Test Platform:
In-orbit E-Learning test platform Objectives: The main objective of this test is to evaluate the Content Acquisition Portal interface (CAP), the
Multimedia Contents Load interface (CLP), and the live event announcement though the user application interfaces (UAP).
Test Setup: Set up and start the E-Learning test platform. Test Descr iption: Input: Simple course material including slides. Testing procedure:
1. Perform the material acquisition through the CAP interface. 2. Perform the Content Load through the CLP interface. 3. Check the event announcement using the UAP.
Results: The course announcement should appear in the UAP with correct definition and material.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
91 / 151
Test Reference: STLF_IO_CSP_ELRN_ Live.002 Subsystem:
Webcasting with low interactivity for corporative services, RCST, NCC.
Pre-Requisite Tests:
Test Platform:
In-orbit E-Learning test platform Objectives: The main objective of this test is to evaluate the live course occurrence on which most of the
system components are involved. Test Setup: Set up and start the E-Learning test platform. Test Descr iption: Input: none (an already loaded demo event, at installation phase). Testing procedure:
1. Run the Live event station for the configured DEMO1 event of Corporation1, checking the audio and video capture.
2. An emulation of a complete event is executed, using the slides and text. 3. Check that the user receives the complete event using the UAP.
Results: The complete live event/lecture is executed with short conferences (5 minutes each).
1.1.58.2 Tele-service: Deferred Events/Courses Tests The main objective of this test group is to evaluate this service capability checking the deferred event announcement though the user application interfaces (UAP), and the deferred course occurrence on which most of the system components are involved.
Test Reference: STLF_IO_CSP_ELRN_ Def.001 Subsystem: Webcasting with low interactivity for corporative services, RCST, NCC.
Pre-Requisite Tests: STLF_IO_CSP_ELRN_Live.002
Test Platform:
In-orbit E-Learning test platform
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
92 / 151
Objectives: The previous live even is published for deferred transmission. Test Setup: Set up and start the E-Learning test platform. Test Descr iption: Input: The content of the previous test group. Testing procedure:
1. From the user station, check that the deferred event has been announced. 2. Run the deferred event in the server. 3. Check that the user receives the complete event using the UAP.
Results: The deferred event is announced and the complete deferred event is executed.
1.1.58.3 Tele-service: On-Demand Express Tests The main objective of this test group is to evaluate this service capability checking the access to “Express” contents when a live event is ongoing. Test Reference: STLF_IO_CSP_ELRN_ Exp.001 Subsystem:
Webcasting with low interactivity for corporative services, RCST, NCC.
Pre-Requisite Tests: STLF_IO_CSP_ELRN_Live.002
Test Platform:
In-orbit E-Learning test platform Objectives: The previous live even conferences are published On-demand express. Test Setup: Set up and start the E-Learning test platform. Test Descr iption: Input: The content of the previous test group. Testing procedure:
1. The content manager must configure the express content. 2. From the user station, check that the express content is available.
Results: The express content is available for on-demand access.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
93 / 151
1.1.58.4 Tele-service: On-Demand Multimedia Repository Tests The main objective of this test group is to evaluate this service capability checking the cataloguing and searching capabilities of it though the user application interfaces (UAP). Test Reference: STLF_IO_CSP_ELRN_ OnD.001 Subsystem:
Webcasting with low interactivity for corporative services, RCST, NCC.
Pre-Requisite Tests:
Test Platform:
In-orbit E-Learning test platform Objectives: The installed content catalogue is checked, as well as the searching capabilities though the user
application interfaces (UAP). Test Setup: Set up and start the E-Learning test platform. Test Descr iption: Input: The demo contents installed in the server. Testing procedure:
1. From the user station and using the UAP interface, access as Corporation1. 2. Check that Demo events for this corporation are properly presented. 3. Check the searching functions of the interface.
Results: All the cataloguing and searching functions output the proper results.
1.1.58.5 Supplementary service: Multi-Platform Tests The main objective of this test group is to evaluate this simultaneous existence of different corporative clients with contents loaded in the system. Test Reference: STLF_IO_CSP_ELRN_MP.001 Subsystem:
Webcasting with low interactivity for corporative services, RCST, NCC.
Pre-Requisite Tests: STLF_IO_CSP_ELRN_OnD.001
Test Platform:
In-orbit E-Learning test platform
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
94 / 151
Objectives: The main objective of this test group is to evaluate this simultaneous existence of different
corporative clients with contents loaded in the system. Test Setup: Set up and start the E-Learning test platform. Test Descr iption: Input: The demo contents installed in the server. Testing procedure: Same as STLF_IO_CSP_ELRN_OnD.001 but accessing as Corporative1, and afterwards as Corporative2. Results: All the cataloguing and searching functions output the proper results (different for each corporation).
1.1.58.6 Supplementary service: Low interactivity service based on integrated Chat service Tests The main objective of this test group is to evaluate this service capability checking user interaction in a live course. Test Reference: STLF_IO_CSP_ELRN_LowI.001 Subsystem:
Webcasting with low interactivity for corporative services, RCST, NCC.
Pre-Requisite Tests: STLF_IO_CSP_ELRN_Live.002
Test Platform:
In-orbit E-Learning test platform Objectives: The main objective of this test group is to evaluate this service capability checking user interaction
in a live course. Test Setup: Set up and start the E-Learning test platform. Test Descr iption: Input: Same as STLF_IO_CSP_ELRN_Live.002. Testing procedure: The same as STLF_IO_CSP_ELRN_Live.002 including the access to the chat room in one of the Demo event conferences. Results: Chat interaction is done during the event.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
95 / 151
1.1.58.7 Supplementary service: Simultaneous Translation Tests & Multilingual Contents Tests The main objective of this test group is to evaluate the capability of the system to provide a simultaneous translation in a live event, and multilingual audio content. This test group is properly tested within the test case: STLF_IO_CSP_ELRN_Live.002 where some conferences have simultaneous translation.
1.1.58.8 Supplementary service: Synchronised content presentation and information downloading Tests The main objective of this test group is to evaluate the capability of the system to provide synchronized contents in live and on-demand events, as well as the download of event materials. This test group is properly tested within the test cases: STLF_IO_CSP_ELRN_OnD.001 and STLF_IO_CSP_ELRN_Live.002. where synchronized materials are checked for on-demand and live services.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
96 / 151
MULTICONFERENCE The test platform used in the real system tests for the multiconference service is represented in the next figure. The minimum equipment needed is formed by: 4 PCs for users in three different RCSTs, 3 PCs for 3 MCUs in one RCST each (nevertheless it is not mandatory there is just one MCU in each RCST), 2 PC for the 2 SIP Proxy Servers, a PC connected to Internet, and at least two telephone terminals connected to the PTSN. 4 web cams, 4 earphones and 4 microphones are also needed.
Figure 0-13 Multiconference test platform
RCST A and RCST B could be in the same or in different beams. During the following tests will be used several RCSTs in the European beam (AAS-E/TID), in the Brazilian beam (Hispamar) and in the South American beam (TPD). The RSGW used will be located in the European beam (Indra).
1.1.59 Expected schedule The excepted duration for the following tests are 3 days.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
97 / 151
1.1.60 Technical requirements The satellite bandwidth needed for multiconference test procedures is 2Mbps.
1.1.61 Test procedures
1.1.61.1 Mesh Mode Multiconference
1.1.61.1.1 Mesh mode multiconference operation tests
Test Reference STLF_IO_MC_MESH_OP Subsystem: RCST, RSGW,
NCC, NMC Pre-Requisite Tests: STLF_IF_SERV_NONREGR_MESH Test Platform: In Orbit Objectives: Establishment of an audio/video multiconference among 3 Satlife participants verifying the correct registration process of each terminal user and MCU to the corresponding SIP Proxy Server, checking the time of establishing and terminating the conference, and measuring the duration of the process of joining a new participant to an established multiconference. Test Setup: Test tool: TID Softphone User 1 behind RCST1 registered in the RSGW SIP Proxy. User 2 behind RCST2 registered in the RSGW SIP Proxy. User 3 behind RCST3 registered in the RSGW SIP Proxy. Test Descr iption: Perform an audio multiconference among the three endpoints. Perform a video multiconference among the three endpoints. Measure the time it takes to establish the conference. Measure the time it takes a new participant joining the conference. Measure the time it takes the third participant leaving the multiconference. Measure the time it takes to terminate the multiconference. Results Expected: Acknowledgment by the SIP Proxy Server of the registration of each user. The time it takes to establish the multiconference is reasonable. The time it takes the third participant joining the conference does not exceed 10 sec. The time it takes the third participant leaving the multiconference is reasonable. The time it takes to terminate the multiconference is reasonable.
1.1.61.1.2 Mesh mode multiconference QoS tests
Test Reference STLF_IO_MC_MESH_QoS Subsystem: RCST, RSGW,
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
98 / 151
NCC, NMC Pre-Requisite Tests: STLF_IF_SERV_NONREGR_MESH Test Platform: In Orbit Objectives: Audio/Video multiconference with 3 Satlife participants in order to study how different conditions or parameters influence the perceptual quality (MOS score) in audio and video streams. Comparing the results with the ones obtained in [7], it is possible to have an estimation of the impact of satellite communication in the QoS. Test Setup: Test tool: TID Softphone User 1 behind RCST1 registered in the RSGW SIP Proxy. User 2 behind RCST2 registered in the RSGW SIP Proxy. User 3 behind RCST3 registered in the RSGW SIP Proxy. Test Descr iption: Perform an audio multiconference among the three endpoints. Perform a video multiconference among the three endpoints. Check perceptual voice quality. Check perceptual video quality. Examine the effect of several audio codecs to the multimedia conference when no video is transmitted. Examine the effect of several audio codecs to the multimedia conference under bandwith restriction when video is also transmitted. Examine the effect of several video codecs in video quality. Verify echo supression. Check audio/video syncronization. Results Expected: Determine which audio codec has the best behaviour in terms of MOS score for Satlife Network conditions when no video is transmitted. Determine which audio codec better supports bandwidth restriction when video is also transmitted. Determine which video codec is more suitable for Satlife conditions. Echo is suppressed. Video and audio are synchronized.
1.1.61.2 Star Mode Multiconference ISDN/PSTN Connectivity
1.1.61.2.1 Star mode multiconference PSTN connectivity operation tests
Test Reference STLF_IO_MC_STAR_PSTN_OP Subsystem: RCST, RSGW,
NCC, NMC, VoIP Gateway, ISTP
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
99 / 151
Pre-Requisite Tests: STLF_IF_SERV_NONREGR_STAR Test Platform: In Orbit Objectives: Establishment of an audio/video multiconference among 3 participants where the multiconference is initiated from a PSTN user. The objective is to verify the correct registration process of each terminal user and MCU to the corresponding SIP Proxy Server, checking the time of establishing and terminating the conference, and measuring the duration of the process of joining a new participant to an established multiconference. Test Setup: Test tool: TID Softphone User 1 behind RCST1 registered in the RSGW SIP Proxy. User 2 behind RCST2 registered in the RSGW SIP Proxy. User 3 located in the PSTN registered in the ITSP SIP Proxy. Test Descr iption: Perform an audio multiconference among the three endpoints. Perform a video multiconference among the three endpoints. Measure the time it takes to establish the conference. Measure the time it takes the third participant joining the conference. Measure the time it takes a participant leaving the multiconference. Measure the time it takes to terminate the multiconference. Results Expected: Acknowledgment by the SIP Proxy Server of the registration of each user. The time it takes to establish the multiconference is reasonable. The time it takes the third participant joining the conference does not exceed 10 sec. The time it takes the third participant leaving the multiconference is reasonable. The time it takes to terminate the multiconference is reasonable.
1.1.61.2.2 Star mode multiconference PSTN connectivity QoS tests
Test Reference STLF_IO_MC_STAR_PSTN_QoS Subsystem: RCST, RSGW,
NCC, NMC, VoIP Gateway, ISTP
Pre-Requisite Tests: STLF_IF_SERV_NONREGR_STAR Test Platform: In Orbit Objectives: Audio/Video multiconference with 3 participants where the multiconference is initiated from a PSTN user, in order to study how different conditions or parameters influence the perceptual quality (MOS score) in audio and video streams. Test Setup:
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
100 / 151
Test tool: TID Softphone User 1 behind RCST1 registered in the RSGW SIP Proxy. User 2 behind RCST2 registered in the RSGW SIP Proxy. User 3 located in the PSTN registered in the ITSP SIP Proxy. Test Descr iption: Perform an audio multiconference among the three endpoints. Perform a video multiconference among the three endpoints. Check perceptual voice quality. Check perceptual video quality. Examine the effect of several audio codecs to the multimedia conference when no video is transmitted. Examine the effect of several audio codecs to the multimedia conference under bandwith restriction when video is also transmitted. Examine the effect of several video codecs in video quality. Verify echo supression. Check audio/video syncronization. Results Expected: Determine which audio codec has the best behaviour in terms of MOS score for Satlife Network conditions when no video is transmitted. Determine which audio codec better supports bandwidth restriction when video is also transmitted. Determine which video codec is more suitable for Satlife conditions. Echo is suppressed. Video and audio are synchronized.
1.1.61.3 Star Mode Multiconference Internet Connectivity
1.1.61.3.1 Star mode multiconference Internet connectivity operation tests
Test Reference STLF_IO_MC_STAR_INTER_OP Subsystem: RCST, RSGW,
NCC, NMC, ISTP Pre-Requisite Tests: STLF_IF_SERV_NONREGR_STAR Test Platform: In Orbit Objectives: Establishment of an audio/video multiconference among 3 participants where the multiconference is initiated from an Internet user. The objective is to verify the correct registration process of each terminal user and MCU to the corresponding SIP Proxy Server, checking the time of establishing and terminating the conference, and measuring the duration of the process of joining a new participant to an established multiconference. Test Setup:
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
101 / 151
Test tool: TID Softphone User 1 behind RCST1 registered in the RSGW SIP Proxy. User 2 behind RCST2 registered in the RSGW SIP Proxy. User 3 is a Internet user agent registered in a different SIP proxy (ITSP), external to SATLIFE network. Test Descr iption: Perform an audio multiconference among the three endpoints. Perform a video multiconference among the three endpoints. Measure the time it takes to establish the conference. Measure the time it takes the third participant joining the conference. Measure the time it takes a participant leaving the multiconference. Measure the time it takes to terminate the multiconference. Results Expected: Acknowledgment by the SIP Proxy Server of the registration of each user. The time it takes to establish the multiconference is reasonable. The time it takes the third participant joining the conference does not exceed 10 sec. The time it takes the third participant leaving the multiconference is reasonable. The time it takes to terminate the multiconference is reasonable.
1.1.61.3.2 Star mode multiconference Internet connectivity QoS tests
Test Reference STLF_IO_MC_STAR_INTER_QoS Subsystem: RCST, RSGW,
NCC, NMC, VoIP Gateway, ISTP
Pre-Requisite Tests: STLF_IF_SERV_NONREGR_STAR Test Platform: In Orbit Objectives: Audio/Video multiconference with 3 participants where the multiconference is initiated from an Internet user, in order to study how different conditions or parameters influence the perceptual quality (MOS score) in audio and video streams. Test Setup: Test tool: TID Softphone User 1 behind RCST1 registered in the RSGW SIP Proxy. User 2 behind RCST2 registered in the RSGW SIP Proxy. User 3 is a Internet user agent registered in a different SIP proxy (ITSP), external to SATLIFE network. Test Descr iption: Perform an audio multiconference among the three endpoints.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
102 / 151
Perform a video multiconference among the three endpoints. Check perceptual voice quality. Check perceptual video quality. Examine the effect of several audio codecs to the multimedia conference when no video is transmitted. Examine the effect of several audio codecs to the multimedia conference under bandwith restriction when video is also transmitted. Examine the effect of several video codecs in video quality. Verify echo supression. Check audio/video syncronization. Results Expected: Determine which audio codec has the best behaviour in terms of MOS score for Satlife Network conditions when no video is transmitted. Determine which audio codec better supports bandwidth restriction when video is also transmitted. Determine which video codec is more suitable for Satlife conditions. Echo is suppressed. Video and audio are synchronized.
1.1.61.4 Star Mode Multiconference
1.1.61.4.1 Star mode multiconference operation tests
Test Reference STLF_IO_MC_STAR_OP Subsystem: RCST, RSGW,
NCC, NMC, VoIP Gateway, ISTP
Pre-Requisite Tests: STLF_IF_SERV_NONREGR_STAR Test Platform: In Orbit Objectives: Establishment of an audio/video multiconference among 3 participants (Satlife user, PSTN user and Internet user) verifying the correct registration process of each terminal user and MCU to the corresponding SIP Proxy Server, checking the time of establishing and terminating the conference, and measuring the duration of the process of joining a new participant to an established multiconference. Test Setup: Test tool: TID Softphone User 1 behind RCST1 registered in the RSGW SIP Proxy. User 2 located in the ISDN registered in the ITSP SIP Proxy. User 3 is a Internet user agent registered in a different SIP proxy (ITSP), external to SATLIFE network.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
103 / 151
Test Descr iption: Perform an audio multiconference among the three endpoints. Perform a video multiconference among the three endpoints. Measure the time it takes to establish the conference. Measure the time it takes the third participant joining the conference. Measure the time it takes a participant leaving the multiconference. Measure the time it takes to terminate the multiconference. Results Expected: Acknowledgment by the SIP Proxy Server of the registration of each user. The time it takes to establish the multiconference is reasonable. The time it takes the third participant joining the conference does not exceed 10 sec. The time it takes the third participant leaving the multiconference is reasonable. The time it takes to terminate the multiconference is reasonable.
1.1.61.4.2 Star mode multiconference QoS tests
Test Reference STLF_IO_MC_STAR_QoS Subsystem: RCST, RSGW,
NCC, NMC, VoIP Gateway, ISTP
Pre-Requisite Tests: STLF_IF_SERV_NONREGR_STAR Test Platform: In Orbit Objectives: Audio/Video multiconference with 3 participants (Satlife user, PSTN user and Internet user) in order to study how different conditions or parameters influence the perceptual quality (MOS score) in audio and video streams. Test Setup: Test tool: TID Softphone User 1 behind RCST1 registered in the RSGW SIP Proxy. User 2 located in the ISDN registered in the ITSP SIP Proxy. User 3 is a Internet user agent registered in a different SIP proxy (ITSP), external to SATLIFE network. Test Descr iption: Perform an audio multiconference among the three endpoints. Perform a video multiconference among the three endpoints. Check perceptual voice quality. Check perceptual video quality. Examine the effect of several audio codecs to the multimedia conference when no video is transmitted. Examine the effect of several audio codecs to the multimedia conference under bandwith restriction when video is also transmitted. Examine the effect of several video codecs in video quality.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
104 / 151
Verify echo supression. Check audio/video syncronization. Results Expected: Determine which audio codec has the best behaviour in terms of MOS score for Satlife Network conditions when no video is transmitted. Determine which audio codec better supports bandwidth restriction when video is also transmitted. Determine which video codec is more suitable for Satlife conditions. Echo is suppressed. Video and audio are synchronized.
1.1.61.5 Six-user star multiconference
1.1.61.5.1 Six-user star multiconference operation tests
Test Reference STLF_IO_MC_STAR_OP Subsystem: RCST, RSGW,
NCC, NMC, VoIP Gateway, ISTP
Pre-Requisite Tests: STLF_IF_SERV_NONREGR_STAR Test Platform: In Orbit Objectives: This test aims to achieve understanding about the multiconference service performance when the conference goes to be big in terms of participant number. Test Setup: Test tool: TID Softphone User 1 behind RCST1 registered in the RSGW SIP Proxy. User 2 behind RCST1 registered in the RSGW SIP Proxy. User 3 behind RCST2 registered in the RSGW SIP Proxy. User 4 located in the ISDN registered in the ITSP SIP Proxy. User 5 is a Internet user agent registered in a different SIP proxy (ITSP), external to SATLIFE network. User 6 is a Internet user agent registered in a different SIP proxy (ITSP), external to SATLIFE network. Test Descr iption: Perform an audio multiconference among the six endpoints. Perform a video multiconference among the six endpoints. Measure the time it takes to establish the conference. Measure the time it takes a new participant joining the conference. Measure the time it takes a participant leaving the multiconference. Measure the time it takes to terminate the multiconference. Results Expected: Acknowledgment by the SIP Proxy Server of the registration of each user.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
105 / 151
The time it takes to establish the multiconference is reasonable. The time it takes a new participant joining the conference does not exceed 10 sec. The time it takes the third participant leaving the multiconference is reasonable. The time it takes to terminate the multiconference is reasonable.
1.1.61.5.2 Six-user star mode multiconference QoS tests
Test Reference STLF_IO_MC_STAR_QoS Subsystem: RCST, RSGW,
NCC, NMC, VoIP Gateway, ISTP
Pre-Requisite Tests: STLF_IF_SERV_NONREGR_STAR Test Platform: In Orbit Objectives: This test aims to achieve understanding about the network performance in multiconference service when the conference goes to be big in terms of participant number. Test Setup: Test tool: TID Softphone User 1 behind RCST1 registered in the RSGW SIP Proxy. User 2 behind RCST1 registered in the RSGW SIP Proxy. User 3 behind RCST2 registered in the RSGW SIP Proxy. User 4 located in the ISDN registered in the ITSP SIP Proxy. User 5 is a Internet user agent registered in a different SIP proxy (ITSP), external to SATLIFE network. User 6 is a Internet user agent registered in a different SIP proxy (ITSP), external to SATLIFE network. Test Descr iption: Perform an audio multiconference among the six endpoints. Perform a video multiconference among the six endpoints. Check perceptual voice quality. Check perceptual video quality. Examine the effect of several audio codecs to the multimedia conference when no video is transmitted. Examine the effect of several audio codecs to the multimedia conference under bandwidth restriction when video is also transmitted. Examine the effect of several video codecs in video quality. Verify echo supression. Check audio/video syncronization. Results Expected: Determine which audio codec has the best behaviour in terms of MOS score for Satlife Network
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
106 / 151
conditions when no video is transmitted. Determine which audio codec better supports bandwidth restriction when video is also transmitted. Determine which video codec is more suitable for Satlife conditions. Echo is suppressed. Video and audio are synchronized.
1.1.61.6 Multiconference with NAT`s users Test Reference STLF_IO_MC_NAT Subsystem: RCST, RSGW,
NCC, NMC, VoIP Gateway, ISTP
Pre-Requisite Tests: STLF_IF_SERV_NONREGR_STAR Test Platform: In Orbit Objectives: Performance of multiconferences between Satlife subscribers and towards the Internet and ISDN from NATed SIP Satlife users while being registered at the RSGW SIP Proxy. Test Setup: Test tool: TID Softphone. SIP user agents are registered in the RSGW SIP proxy ISDN PRI emulator is connected to the RSGW’s VoIP GW User 1 NATed in the RCST User 2 non-NATed in the RCST User 3 located in the ISDN registered in the ITSP SIP Proxy. User 4 is a Internet user agent registered in a different SIP proxy (ITSP), external to SATLIFE network. Test Descr iption: Perform an audio multiconference among the three users Perform an video multiconference among the three users Measure the time it takes to establish the conference. Measure the time it takes a new participant joining the conference. Measure the time it takes a participant leaving the multiconference. Measure the time it takes to terminate the multiconference. Results Expected: A user NATed in a RCST can participate in a multiconference with Internet users, ISDN users and non-NATed Satlife users.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
107 / 151
NOMADIC TERMINAL INTEGRATION This chapter defines the tests to be performed on the Nomadic Terminal using the regenerative platform. The test procedures regarding satellite access and physical layers are documented in chapter 0 NOMADIC TERMINAL INTEGRATION inside the transparent platform test procedures. This chapter covers the interoperability between the EMS Nomadic Terminal and other DVB-RCS terminals using the SatLife network. In this test it is intended to demonstrate that the Nomadic Terminal is capable of functioning in the regenerative platform. A basic set of operations will be performed, as satellite downlink adquisition, GPS position adquisition and transmitted to the modem, RCS tables decoding, and terminal synchronization. The new kind of terminal must be manageable from the MS as well. Following these operations, some traffic tests will be executed, including connectivity tests with terminals of the same and different coverage, unicast traffic transmission and reception, and finally, multicast traffic transmission and reception. Finally, as service tests, some web browsing and FTP will be performed.
1.1.62 Test Platform The nomadic test platform needed to perform the regenerative tests is the same than the transparent version. It comprises the following elements:
• A vehicle fitted with a one button auto-deploy antenna. • A portable rack comprising:
o DVB-RCS Modem o Antenna controller o UPS
• Portable Generator The antenna is an AvL Technologies mobile VSAT antenna system. The DVB-RCS modem is an EMS Technologies Satellite Networks E2020. An APC UPS is integrated into the system. A Honda portable generator supplies the power. The antenna comprises Compass, GPS, Inclinometer and a beacon receiver. Once activated the antenna reads the compass heading confirms the incline of the antenna is acceptable starts to obtain a GPS position. Once the controller has done this the antenna is deployed to the pre-selected satellite. Once the antenna has been deployed to the pre-selected satellite it auto-tracks to obtain the best signal. When this has been archived the controller indicates that is has obtained lock and then starts to send the GPS position to the DVB-RCS modem. The DVB-RCS modem takes the GPS position from the antenna controller and inserts this data into its configuration to enable full Forward and Return Link lock. Par tners involved:
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
108 / 151
• Alcatel Alenia Space Spain • EMS Satcom (supported by EMS Satellite Networks)
Figure 0-14. Nomadic terminal test platform
1.1.63 Expected Schedule In order to perform these tests, the following scheduling aspects are: Number of days: 1 day Pre-requisite tested services: 5 days
1.1.64 Technical requirements The technical requirements to perform the nomadic terminal tests are the following: • Available return link bandwidth – 512KB/s • RCSTs operative in 2 beams.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
109 / 151
1.1.65 Test procedures for interoperability
1.1.65.1 Logon Test Reference: STLF_IO_NOM_REG_LOGON Subsystem: Nomadic RCST
Pre-Requisite Tests: Test Platform: In Orbit Objectives: This test will verify the correct behaviour of a Nomadic terminal within SatLife network. Test Setup: VSN1 Test Descr iption: The nomadic terminal will be provisioned in the NMC. The installer should know all the required logon parameters, but the GPS position should be automatically updated in the terminal. The terminal should receive the tables, logon into the system, control and management connection opened. Check a minimum set of management operations (i.e. blind command or get and object from the MIB). Check C2P connection establishment / release (i.e. simple ping) between an RCST in orbit and the one nomadic. Check the quality (packets loss). Logout the nomadic terminal, move at least 30 km from the previous position. Try a new logon, and repeat similar tests on snmp , C2P messages and traffic transmission/reception. Results Expected: Successful logon and traffic transmission / reception of the nomadic terminal from different positions and for the different types of connections performed.
1.1.65.2 Multicast Transmission Test Reference: STLF_IO_NOM_REG_MCAST Subsystem:
DVB-RCS Modem Pre-Requisite Tests:
Test Platform:
Nomadic System
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
110 / 151
Objectives: Transmit a Multicast and verify it’s received error-free. Test Setup: Test Descr iption: Start a multicast flow from the nomadic terminal and receive simultaneously a multicast flow send by other RCST. Check that this RCST can receive the traffic started by the nomadic terminal. Establish a multicast connection against the GW-RCST in Arganda. SNR on Forward link >= 10dB. Results: Multicast transmitted and received error-free.
1.1.65.3 IP Pinging Test Reference: STLF_IO_NOM_REG_IP_PING Subsystem:
DVB-RCS Modem Pre-Requisite Tests:
Test Platform:
Nomadic System Objectives: Basic IP connectivity: Ping and verify packet transmission over the return link. Test Setup: Test Descr iption: SNR on return link shall be >= 10dB. Verify that all packets are received error-free Results: Compliant
1.1.65.4 FTP File transfer Test Reference: STLF_IO_NOM_REG_FTP_TRANS Subsystem:
DVB-RCS Modem Pre-Requisite Tests:
Test Platform:
Nomadic System
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
111 / 151
Objectives: Verify file transfers over TCP/IP. Test Setup: Test Descr iption: Establish FTP connection between the nomadic RCST and other manufactures’ RCSTs on the system. Perform FTP file transfers in both directions with RCST logged-on at 512kbps. File transfer duration should be less than 10 minutes, and no re-transmissions allowed. Results: Compliant
1.1.65.5 Web Browsing Test Reference: STLF_IO_NOM_REG_WEB_BROWS Subsystem:
DVB-RCS Modem Pre-Requisite Tests:
Test Platform:
Nomadic System Objectives: To test basic Internet connectivity Test Setup: Test Descr iption: RCST logged-on at 512kbps, true Internet access or Web server at other RCST side. Verify stable operation for at least 10 minutes while doing the following operations: • Browse different pages • IP Pinging • FTP transfer • Multicast Transmit • Multicast Receive Establish a connection against the GW-RCST in Arganda and navigate on the Internet. Results: Compliant
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
112 / 151
LOW-COST TERMINAL INTEGRATION This test is focussed to validate the low-cost satellite terminal in the regenerative platform. The behaviour of this terminal should be similar than the normal RCST, with a limitation in the frequency hopping and the performance.
1.1.66 Test platform Two terminals will be employed in this test, to verify traffic transmission and reception.
Figure 0-15: Low-cost terminal integration platform
1.1.67 Expected schedule Expected test duration : 1 day.
1.1.68 Technical requirements
• Satellite bandwidth needed: up to 2Mbps. • Continuous timeslot assignment. • Avoid to assign the last timeslot of the frame.
1.1.69 Test procedures
1.1.69.1 Low cost terminal interoperability Test Reference: STLF_IO_LCOST Subsystem: RCST Pre-Requisite Tests: STLF_IF_LCOST_LOGON, STLF_IF_LCOST_TRF, STLF_IF_LCOST_LOGOFF
Test Platform: In Orbit
Objectives: Verify that a low cost RCST can operate in the system. This means that the RCST should be able
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
113 / 151
to log on and logoff as a normal RCST. Analyze the effect of frequency hoping due to SYNC and traffic assignment. Test Setup: VSN 1. Install the software of a normal RCST into the low cost RCST. Test Descr iption: Provision the low cost RCST in the system. Log on the RCST. The low cost RCST shall use a traffic route in a single frequency with minimum SDR/PDR=64/128 kbps in the return link. Log off the RCST from the NMC by locking the terminal and/or by logging off the terminal. Results Expected: The low cost RCST should log on in the system as a normal RCST. The low cost RCST should create connections with other RCSTs although some traffic may be lost due to the frequency hoping between burst and SYNCs. The percentage should be less than 1 burst/18 superframes (SYNC periodicity). The NMC should be capable of logging off the terminal in both ways (the NCC will send the correspondent TIMu).
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
114 / 151
MIDDLEWARE The objective of the middleware real system tests is the verification in-orbit of all the software functionalities defined in D321 and D322 for the middleware in a real device. The main services considered to integrate with the SATLIFE network are services based on IP, like web browsing using the TV or video on demand services.
1.1.70 Test Platform The test platform used for the real system tests is a STB with the middleware installed on it, and connected to a RCST. In the server side there are another RCST connected to the servers that will provide the services used from the STB. The equipment used for this test platform will be composed by: • A set-top-box with the middleware installed on it. • A TV set to visualize the output of the set-top-box. • The Amazonas satellite. • Two DVB-RCSTs configured in regenerative mode, one for the server side and another for the
client side, where is located the STB. • A PC with a web server to simulate an Internet web server. • A PC with a VOD server to simulate a VOD service provider.
Figure 0-16 Middleware test platform
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
115 / 151
The partners involved in the following test are: • TID: which provides the servers and the set-top-box. • AAS-E: which provides the SATLIFE network configuration. • HIS: which provides the satellite bandwidth and the RCST. TID and AAS-E are in charge of: • Setup the scenario. • Perform the proposed test procedures. • Analyse and document their results.
1.1.71 Expected schedule The excepted duration for the following tests are 3 days. It is recommended to test this device after the real system tests for VOD and NVOD services.
1.1.72 Technical requirements The satellite bandwidth needed for VOD test procedures is up to 2Mbps, and up to 256Kbps for web browsing tests.
1.1.73 Test procedures
1.1.73.1 Middleware in a VOD application STLF_IO_DEV_MID Test Reference: STLF_IO_DEV_MID_001 Subsystem:
Device Middleware, RCST, NCC. Pre-Requisite Tests:
Test Platform:
In-orbit middleware test platform
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
116 / 151
Objectives: The purpose of the test is to verify the functionality of a VOD application running over a set-top-box working with the middleware. Test Setup: Set up and start the middleware test platform. The set-top-box should be configured properly, that is, the middleware must be running and attached to the satellite network. Test Descr iption: - Using the remote control of the set-top-box open the main menu window. - Select video on demands contents. A new window will appear with the current list of all
contents available for VOD. - Select any of the available contents. The selected content will begin to visualize. - Continue watching these contents some minutes. - Push the fast forward button and wait some seconds. - Push the play button and wait some seconds. - Push the pause button and wait some seconds. - Push the fast forward button and wait some seconds. - Push the play button and wait some seconds. - Push the stop button and wait some seconds. - Push the play button and wait some seconds. - Push the stop button to finish the test. Results: The middleware should acknowledge the remote control keystrokes and perform the related action. With this test procedure it will be possible to check if the middleware is able to: - Capture and manage the remote control keystrokes. - Send the key codes to the active application. - Control the screen manager to display text and graphics.· - Access to web contents. - Reproduce audio and video contents properly. - Manage the IP connection to send RTSP commands and receive RTSP replies and UDP
packets containing audio and video data. - Pause, and move forward and backwards, and stop the video. Sniff with a network analyzer right after the Service Provider Unit and before the client terminal. The RTSP session commands will be seen.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
117 / 151
1.1.73.2 Middleware in a web browser application Test Reference: STLF_IO_DEV_MID_002 Subsystem:
Device Middleware, RCST, NCC. Pre-Requisite Tests: STLF_IO_DEV_MID_001
Test Platform:
In-orbit middleware test platform Objectives: The purpose of the test is to verify the functionality of a web browsing application over a set-top-box working with the middleware. Test Setup: Set up and start the middleware test platform. The set-top-box should be configured properly, that is, the middleware must be running and attached to the satellite network and the web server should be loaded with test web pages. Test Descr iption: - Using the remote control of the set-top-box open the main menu window. - Select the Internet access. A new window will appear with the web browser application. - Check in the HTML example page that:
∗ code with text formats, color, sizes and images is correctly depicted. ∗ The code with tables is correctly depicted. ∗ The code with frames is correctly depicted. ∗ The code with forms is correctly interpreted. ∗ The Javascript code is correctly executed. ∗ Cascade style sheets code are correctly used. ∗ Cookies are correctly managed. ∗ The java applets work well.
Results: The middleware should acknowledge the remote control keystrokes and perform the related action. With this test procedure it will be possible to check if the middleware is able to: - Support text formats, color, sizes and images. - Support tables, frames and forms. - Support HTML v1.1. - Support Javascript. - Support style sheet code. - Support style java applets.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
118 / 151
1.1.73.3 Middleware in a multicast TV application Test Reference: STLF_IO_DEV_MID_003 Subsystem:
Device Middleware, RCST, NCC. Pre-Requisite Tests: STLF_IO_DEV_MID_004
Test Platform:
In-orbit middleware test platform Objectives: The purpose of the test is to verify the functionality of a multicast TV application over a set-top-box working with the middleware. Test Setup: Set up and start the middleware test platform. The set-top-box should be configured properly, that is, the middleware must be running and attached to the satellite network. Test Descr iption: - Using the remote control of the set-top-box open the main menu window. - Select the ‘TV’ access. A new window with the TV application will appear. - Watch the different TV channels. Results: The middleware should acknowledge the remote control keystrokes and perform the related action. With this test procedure it will be possible to check if the middleware is able to reproduce the TV channels.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
119 / 151
ADSL & SATELLITE INTERNETWORKING The objective of these real system tests is the verification in-orbit of all the software functionalities and scenarios defined in D321 and D322 for the ADSL and satellite internetworking.
1.1.74 Test Platform The test platform used for the real system tests is a Unix machine with the VOD server connected to a RCST in the server side and another RCST connected to an IP set-top-box that will be used to visualize the videos in a TV set. We will use the same IP set-top-box for MPEG-2 and MPEG-4 AVC / H.264 contents: an ADB model 3100. The equipment used for this test platform will be composed by: • One PC with Windows O.S. to simulate the client side. • One ADSL modem-router and a USB ADSL modem. • One IP DSLAM. • The Amazonas satellite. • Two DVB-RCSTs configured in regenerative mode, one for the server side and another for the
client side, where is located the IP DSLAM. • One PC in the Internet service provider side with a web server to simulate Internet, or a direct
connection to Internet in the server side.
Figure 0-17 ADSL and satellite internetworking test platform
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
120 / 151
The partners involved in the following test are: • TID: which provides the server, the ADSL modems and the IP DSLAM. • AAS-E: which provides the SATLIFE network configuration. • HIS: which provides the satellite bandwidth and the RCST. TID and AAS-E are in charge of: • Setup the scenario. • Perform the proposed test procedures. • Analyse and document their results.
1.1.75 Expected schedule The excepted duration for the following tests are 3 days. There are no dependences with other tests.
1.1.76 Technical requirements The satellite bandwidth needed for these test procedures is 1Mbps for the downlink and 320Kbps for the uplink.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
121 / 151
1.1.77 Test procedures
1.1.77.1 PPPoE single-user scenario Test Reference: STLF_IO_DEV_ADSL_001 Subsystem: ADSL and satellite
internetworking, RCST, NCC. Pre-Requisite Tests:
Test Platform: In-orbit ADSL and satellite test platform
Objectives: The purpose of the test is to verify the connectivity using a PPPoE single-user scenario in the proposed test bed. Test Setup: Set up and start the test-bed. The IP DSLAM should be configured to accept one client at least. The client PC should have the PPPoE client software installed and configured according to the IP DSLAM configuration Test Descr iption: - Connect the USB modem-router to the user PC. Check that the USB modem-router detects
ADSL and it is synchronized with the IP DSLAM. - Open a MS-DOS command line window and perform an IPCONFIG command. Check that the
PC has been configured using DHCP with a public IP address. - Perform a ping command to the public IP address of the web server that simulates Internet. - Open a web browser and connect to the web server home page typing its URL. Results: In this scenario, the user PC will have a public IP address assigned by DHCP. The IP DSLAM will have a range of public IP address that will be assigned to any user that initiates a new PPPoE session. It should be checked in the IP DSLAM log files the related traces with the connection. It should be checked in the RADIUS log files the related traces with the log-on process.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
122 / 151
1.1.77.2 PPPoE multi-user scenario Test Reference: STLF_IO_DEV_ADSL_002 Subsystem: ADSL and satellite
internetworking, RCST, NCC. Pre-Requisite Tests:
Test Platform: In-orbit ADSL and satellite test platform
Objectives: The purpose of the test is to verify the connectivity using a PPPoE muli-user scenario in the proposed test bed. Test Setup: Set up and start the test-bed. The IP DSLAM should be configured to accept one client at least. The client PC should have the TCP/IP drivers installed. The ADSL router should have been configured to use PPPoE Test Descr iption: - Connect an Ethernet cable from the PC Ethernet card to the ADSL router. Check that the link
LED is on. - Open a MS-DOS command line window and perform an IPCONFIG command. Check that the
PC has been configured using DHCP with a private IP address. - Open a web browser and connect to the ADSL router web page typing its private IP address. - Go to the diagnostic tool. Check that the ADSL router is synchronized with the IP DSLAM
and the ATM loopback test is successful. - Perform a ping command to the public IP address of the web server that simulates Internet. - Open a web browser and connect to the web server home page typing its URL. Results: In this scenario, the user's PC will have a private IP address assigned by DHCP (DHCP is not mandatory, but it is typically used in a LAN configuration). The ADSL router performs a PPPoE connection to the IP DSLAM, and the IP DSLAM assigns a public IP address from a internal range to the ADSL router. This public IP address is not known by the user PC because the ADSL router will perform a NAT. It should be checked in the IP DSLAM log files the related traces with the connection. It should be checked in the RADIUS log files the related traces with the log-on process. It should be checked that adding some more PCs to the user LAN with the same configuration, they will have access to the public IP address of the web server that simulates Internet.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
123 / 151
1.1.77.3 Routing single-user scenario Test Reference: STLF_IO_DEV_ADSL_003 Subsystem: ADSL and satellite
internetworking, RCST, NCC. Pre-Requisite Tests:
Test Platform: In-orbit ADSL and satellite test platform
Objectives: The purpose of the test is to verify the connectivity using a routing single-user scenario in the proposed test bed Test Setup: Set up and start the test-bed. The IP DSLAM should be configured to accept one client at least. The client PC should have configured the USB ADSL modem-router. Test Descr iption: - Connect the USB modem-router to the user PC. Check that the USB modem-router detects
ADSL and it is synchronized with the IP DSLAM. - Open a MS-DOS command line window and perform an IPCONFIG command. Check that the
PC has a static and public IP address. - Perform a ping command to the public IP address of the web server that simulates Internet. - Open a web browser and connect to the web server home page typing its URL. Results: In this scenario, the user PC will have a public IP address assigned statically. It should be checked in the IP DSLAM log files the related traces with the connection.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
124 / 151
1.1.77.4 Routing multi-user scenario Test Reference: STLF_IO_DEV_ADSL_004 Subsystem: ADSL and satellite
internetworking, RCST, NCC. Pre-Requisite Tests:
Test Platform: In-orbit ADSL and satellite test platform
Objectives: The purpose of the test is to verify the connectivity using a routing muli-user scenario in the proposed test bed. Test Setup: Set up and start the test-bed. The IP DSLAM should be configured to accept one client at least. The client PC should have the TCP/IP drivers installed. The ADSL router should have been configured to use a static IP address Test Descr iption: - Connect an Ethernet cable from the PC Ethernet card to the ADSL router. Check that the link
LED is on. - Open a MS-DOS command line window and perform an IPCONFIG command. Check that the
PC has been configured using DHCP with a private IP address. - Open a web browser and connect to the ADSL router web page typing its private IP address. - Go to the diagnostic tool. Check that the ADSL router is synchronized with the IP DSLAM
and the ATM loopback test is successful. - Perform a ping command to the public IP address of the web server that simulates Internet. - Open a web browser and connect to the web server home page typing its URL. Results: In this scenario, the user PC will have a private IP address assigned by DHCP (DHCP is not mandatory, but it is typically used in a LAN configuration). The ADSL has a static public IP address. This public IP address is not known by the user PC because the ADSL router will perform a NAT. It should be checked in the IP DSLAM log files the related traces with the connection. It should be checked that adding some more PCs to the user LAN with the same configuration, they will have access to the public IP address of the web server that simulates Internet.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
125 / 151
HOME GATEWAY The objective of the Home Gateway real system tests is the verification in-orbit of all the service capabilities defined in D321 and D322 for the Home Gateway device. Trough this set of test procedures, the home gateway functionality will be checked between the domotic network, the home gateway and the user of this device using a connection via satellite in regenerative mode.
1.1.78 Test Platform The test platform used for the real system tests is a home gateway from Siemens connected to the domotic network and to the internal IP network where it is attached a surveillance IP camera. The home gateway is connected to a DVB-RCST that provides a bi-direccional link with the final user. The final user will be located in a remote place and connected to the satellite network using another DVB-RCST or a RSGW. The list with the needed equipment for the Video on demand test is composed by: • A home gateway PylixTM of Siemens. • Several LonWorks or X.10 domotic devices as:
o Lights. o Shutter. o Dishwasher machine. o Oven.
• The Amazonas satellite. • Two DVB-RCSTs configured in regenerative mode, one for the server side and another for the
client side. • A PC with Windows O.S. to access remotely to the home gateway. • An IP camera to be used for surveillance.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
126 / 151
Figure 0-18 Home gateway test platform
The partners involved in the following test are: • TID: which provides the devices. • AAS-E: which provides the SATLIFE network configuration. • HIS: which provides the satellite bandwidth and the RCST. TID and AAS-E are in charge of: • Setup the scenario. • Perform the proposed test procedures. • Analyse and document their results.
1.1.79 Expected schedule The excepted duration for the following tests are 3 days.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
127 / 151
1.1.80 Technical requirements The satellite bandwidth needed for home gateway test procedures is 200Kbps.
1.1.81 Test procedures
1.1.81.1 Check the status of a domotic device Test Reference: STLF_IO_DEV_HGW_001 Subsystem: Home gateway
device, RCST, NCC. Pre-Requisite Tests:
Test Platform: In-orbit Home Gateway test platform
Objectives: The purpose of the test is to verify that it is possible to check remotely the status of a domotic device. Test Setup: Set up and start the test-bed. Test Descr iption: - Open a MS-DOS command line window and perform an IPCONFIG command. - Check using a ping command that there is connectivity to its default gateway. The default
gateway must be the PC that will provide the connectivity to the home gateway. - Check using a ping command that there is connectivity to the home gateway. - Open a web browser and connect to the home gateway web page typing its IP address. - Go to the domotic devices page. - Switch on manually a light and refresh the domotic devices web page. Results: In order to access the home gateway web server should be IP connectivity between the user's PC and the home gateway through the router PC. The domotic devices page will show all of the domotic devices configured in the domotic network with its current status. If there is any change in the status of any domotic device, it will be shown in the next load of the web page.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
128 / 151
1.1.81.2 Telecontrol of a domotic device Test Reference: STLF_IO_DEV_HGW_002 Subsystem: Home gateway
device, RCST, NCC. Pre-Requisite Tests: STLF_IO_DEV_HGW_001
Test Platform: In-orbit Home Gateway test platform
Objectives: The purpose of the test is to verify that it is possible to change remotely the status of a domotic device. Test Setup: Test Descr iption: - Open a MS-DOS command line window and perform an IPCONFIG command. - Check using a ping command that there is connectivity to its default gateway. The default
gateway must be the PC that will provide the connectivity to the home gateway. - Check using a ping command that there is connectivity to the home gateway. - Open a web browser and connect to the home gateway web page typing its IP address. - Go to the domotic devices page. - Select any domotic device shown in this page. A new window will be displayed to change its
current status. - Change its current status to any value. Results: In order to access the home gateway web server should be IP connectivity between the user PC and the home gateway through the router PC. The domotic devices page will show all of the domotic devices configured in the domotic network with its current status. Will exist different values depending on the type of the domotic devices, for instance, a light will have two different status: on and off, but a shutter could be opened or closed using several positions. Any change will be applied immediately, and the domotic devices web page will show its new status.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
129 / 151
1.1.81.3 Streaming video from the surveillance camera Test Reference: STLF_IO_DEV_HGW_003 Subsystem: Home gateway
device, RCST, NCC. Pre-Requisite Tests: STLF_IO_DEV_HGW_001
Test Platform: In-orbit Home Gateway test platform
Objectives: The purpose of the test is to verify the streaming video from a surveillance camera attached to the home gateway. Test Setup: Test Descr iption: - Open a MS-DOS command line window and perform an IPCONFIG command. - Check using a ping command that there is connectivity to its default gateway. The default
gateway must be the PC that will provide the connectivity to the home gateway. - Check using a ping command that there is connectivity to the home gateway. - Open a web browser and connect to the home gateway web page typing its IP address. - Go to the surveillance page. - A new web page will be opened with an active-X component that will connect to the IP camera
to capture its video and audio and it will reproduce it. Results: In order to access the home gateway web server should be IP connectivity between the user PC and the home gateway through the router PC. The web browser will download the specific plug-in if needed. This plug-in will contact directly to the IP camera using a RTSP session. In the proposed test-bed there is no connectivity problem but in the integration test-bed will be needed to configure the RCST properly to allow this kind of traffic.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
130 / 151
1.1.81.4 View the motion detection alarms Test Reference: STLF_IO_DEV_HGW_004 Subsystem: Home gateway
device, RCST, NCC. Pre-Requisite Tests: STLF_IO_DEV_HGW_003
Test Platform: In-orbit Home Gateway test platform
Objectives: The purpose of the test is to verify the reception of alarms in the home gateway and its visualization. Test Setup: Test Descr iption: - Open a MS-DOS command line window and perform an IPCONFIG command. - Check using a ping command that there is connectivity to its default gateway. The default
gateway must be the PC that will provide the connectivity to the home gateway. - Check using a ping command that there is connectivity to the home gateway. - Open a web browser and connect to the home gateway web page typing its IP address. - Go to the surveillance events page. - Check the list of received events. - Make any movement that could be captured by the IP camera. - Check again the list of received events. A new event will be shown. - Click in the new event link. A group of pictures will be shown containing the movement
sequence. Results: The surveillance events page will show all of the movements that the camera has registered previously. Selecting any event, the web server will show several pictures prior to the movement, during the movement and before the movement.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
131 / 151
DIGITAL TV The objective of the Digital TV real system tests is the verification in-orbit of all the service capabilities defined in D321 and D322 for the Digital TV service. Trough this set of test procedures, the Digital TV functionality will be checked between the Service Provider and the final users using a connection via satellite in regenerative mode.
1.1.82 Test Platform As in the tests procedures made for the in factory trials, the digital TV service capabilities to be tested in the real system tests are organised as:
• Broadcast Digital TV The transmission of digital TV contents from server to clients and their reception will be checked.
• Broadcast interactive applications The main objective of this test group is to check the transmission and the reception of MHP interactive applications to standard MHP set-top-boxes.
The test platform used for the real system tests is composed by several servers that sends the multimedia contents and interactive applications to the Service Provider and to the RCS terminal. In the client side, several commercial STB and analyzers will be used to check and visualize the received contents. The equipment needed for the Digital TV tests is composed by: • A Unix machine with Solaris O.S. to install the flow server. • A High Speed MPEG-2 Interface Board: MediaPump XL PCI card. • A PC with Windows O.S. to serve as Management PC. • A Service Provider Unit. • A DVB-RCS terminal from Shiron. • The Amazonas satellite. • A Monitoring Station to directly receive the DVB-S information and monitor it. • A DVB-S set-top-box without MHP support. • A DVB-S MHP set-top-box.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
132 / 151
Figure 0-19 Digital TV test platform
The partners involved in the following test are: • TID: which provides the flow and management servers and the STB to receive the TV contents. • THALES: which provides the Service Provider Unit and the Monitoring Station. • SHIRON: which provides the RCST-SP. • AAS-E: which provides the SATLIFE network configuration. • HIS: which provides the satellite bandwidth and the RCST. • Hispamar and TPD: which tests the reception of TV contents. The server side with the Service provider Unit, the SP-RCST and the content servers will use the European bean of the Amanozas satellite to transmit the TV contents. These contents will be received in three locations: Madrid (AAS-E) where is installed the STB and the monitoring station, Guaratiba (Hispamar) and Sao Paulo (TPD). The partners involved in these tests are in charge of: • Setup the scenario.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
133 / 151
• Perform the proposed test procedures. • Analyse and document their results.
1.1.83 Expected schedule The excepted duration for the following tests are 5 days. This service should be tested with the Software Download because both services share the same test platform.
1.1.84 Technical requirements The satellite bandwidth needed for home gateway test procedures is 2Mbps.
1.1.85 Common test procedures
1.1.85.1 Multi-VSP Management Test Reference: STLF_IO_MGT_VSP Subsystem: SP RCST, NCC, SP
Pre-Requisite Tests: None Test Platform: In-orbit Digital
TV platform Objectives: Verify that two SP RCST can be provisioned with the necessary information in the same VSN. Only one can transmit at a time. Test Setup: VSN 2 Both SP-RCSTs provisioned in VSN 2 Test Descr iption: The traffic route is not shared with other VSNs. Start-up the SP RCST 1. The terminal should receive the tables and logon into the system. Try to log on SP-RCST2 and check that the two SP-RCSTs cannot be logged at the same time. Results Expected: Both VSPs can be provisioned in the same VSN but only one of them can be logged each time.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
134 / 151
1.1.85.2 SP-RCST Management Test Reference: STLF_IO_MGT_SPRCST Subsystem: SP RCST, NCC, SP,
NSM Pre-Requisite Tests: STLF_IF_MGMT_SPRCST Test Platform: In-orbit Digital
TV platform Objectives: Verify that the SP RCST can be provisioned with the necessary information to logon, and that management operations can be performed against it. Test Setup: VSN 2 or 3. In the VSN of the SP-RCST there will be no other terminal. Test Descr iption: The traffic route is not shared with other VSNs. The NCC shall be configured with a range of PID for the VSPs defined in a XML configuration file in order to receive DVB tables or sections of DVB tables from the SP-RCST. To provision a SP-RCST next configuration is entered: RCST profile menu - terminal usage = GW-RCST SLA (RCST Service menu) specific : - Star parameters all parameters = 0 - Mesh parameters max mesh PDR forward = 0 max mesh PDR return = max mesh SDR return = traffic capacity for VSP - other parameters alpha forward = 100 (unused by NCC) connections max number = 1 (mono channel) or 2 (multi channels) on demand jitter max = 0 (unused by NCC) RBDC max for sig = 0 (unused by NCC) CRA for sig = signalization capacity for VSP (SNMP and VSP tables) Start-up the SP RCST. Configure the SP RCST using the CLI interface. Restart the SP RCST and request the parameters that have been changed. The terminal should receive the tables, logon into the system, control and management connection opened. Check a minimum set of management operations (i.e. blind command or get and object from the MIB). Results Expected: The SP RCST should start-up successfully using this information and start the logon procedure. The SP RCST should store the data in non-volatile memory.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
135 / 151
1.1.86 Broadcast Digital TV test procedures
1.1.86.1 Start/Stop the flow server Test Reference: STLF_IO_DTV_VIDEO_001 Subsystem: SP RCST, NCC, SP
Pre-Requisite Tests: STLF_IO_MGT_VSP Test Platform: In-orbit Digital
TV platform Objectives: The purpose of the test is to verify the correct start and stop of the video contributions transmission to the client side after normal start-up sequence and log-on into the flow server Test Setup: Test Descr iption: - Open the PATROL console for the management of the Digital TV service. - To start the flow server, right click with your mouse in the ‘Processes’ icon in Machine_Icon-
>FLOW_SERVER->Processes, and then choose the ‘KM Commands’ option and then ‘SF_DVB’ and then ‘Start’ .
- To stop the flow server, right click with your mouse in the ‘Processes’ icon in Machine_Icon->Flow Server->Processes, and then choose the ‘KM Commands’ option and then ‘SF_DVB’ and then ‘Stop’ .
Results Expected: You can be sure that the flow server is running by checking from the console the current process as asi S.O. user:
$ ps -fe|grep DVB root 417 1 92 08:14:00 pts/1 2:55 /export/home/asi/bin/SF_DVB_Stream -p 7000 -b 19906000 -g 4000 –nb
Correct start can not be monitored in the client side before sending contents. After stopping the flow server, if contents were being transmitted, it can be seen that the transport stream changes to a null packets transport stream.
1.1.86.2 Add/configure and start a new flow to the flow server Test Reference: STLF_IO_DTV_VIDEO_002 Subsystem: SP RCST, NCC, SP
Pre-Requisite Tests: STLF_IO_MGT_VSP and STLF_IO_DTV_VIDEO_001
Test Platform: In-orbit Digital TV platform
Objectives: The purpose of the test is to verify the correct configuration and transmission of a new flow that will be added to the transport stream
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
136 / 151
Test Setup: Test Descr iption:
• Open the PATROL console for the management of the Digital TV service. Go to Machine_Icon-> FLOW_SERVER.
• Click with the right button of the mouse in the icon called ‘FLOWS’. In the mouse right-click menu choose ‘KM Commands’ and then click on the ‘Add Flow’ option.
• Fill in the data of the flow and then push the OK button to create a new flow. The data of the flow are: ID->50, PID->8191 (0x1fff), name->video1, bitrate->1500000, filename-> /export/home/asi/videos/satlife1.mpg. This content is coded using MPEG-2.
• To start a flow so that it begins to transmit, go to ‘FLOWS’ in the PATROL console and then click with the right mouse button on the icon of the flow you want to start. In the mouse right button menu choose ‘KM Commands’ and then ‘Enable Flow’ . Accept the confirmation box . The traffic light icon of the flow will change from yellow to green, indicating that the flow has started to transmit.
• Repeat last three steps to send the signaling information of the PMT for the MPEG-2 file. These are the parameters: ID->51, PID->1100 (0x44c), name->video1_PMT, bitrate->4000, filename->/export/home/asi/mhp/PSI_SI/pmt1100.ts.
Unlike the PMT, which is sent once per service from the Content Service Provider, only one SDT and one PAT has to be sent per Transport Stream. They can be added by the Content Service Provider or optionally from the Service Provider.
• Repeat the operations to add and start a new flow with the SDT of the transport stream with the MEPG-2 content. The parameters are: ID->52, PID->17 (0x11), name->video1_SDT, bitrate->4000, filename->/export/home/asi/mhp/PSI_SI/sdt.ts. This step is optional, it can be also done from the Service Provider Unit.
• The Service Provider Unit has to be set so as to accept the following PIDs: 1100 (0x44c, PMT), 17 (0x11, SDT, optional), 1101 (0x44d, Video), 1103 (0x44f, Audio).
• Then, stop the flows involved in the transmission of the MPEG-2 content as indicated in STLF_LS_CSP_DTV_003. Then, repeat the operation to add and start a new flow with H264 content with the following parameters: ID->50, PID->768 (0x300), name->video2, bitrate->1200000, filename->/export/home/asi/videos/H264_1200_content1 .mpg. The PMT and SDT of the contents of this file file is included in the file.
• The Service Provider Unit has to be set so as to accept the following PIDs: 257 (PMT), 17 (SDT, optional), 768 (Video), 769 (Audio).
Results Expected: After creation and starting of the flow you can check the correct configuration of the newly created flow by checking from a flow server console the flow server's current status file ~/config/statusGF. The last flag will be set to ‘1’ when the flow is started (enabled). It will show for the MPEG-2 file:
50||video1|/export/home/asi/videos/video.mpg|2|0|8191|0|1500000|1| 51||video1_PMT|/export/home/asi/mhp/PSI_SI/pmt1100.ts|2|0|1100|0|4000|1| 52||video1_SDT|/export/home/asi/mhp/PSI_SI/sdt.ts|2|0|17|0|4000|1|
and for the H264 file: 50||video2|/export/home/asi/videos/ H264_1200_content1.mpg |2|0|768|0|1200000|1|
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
137 / 151
The following verifications have to be done for both the MPEG-2 and the H264 contents: − With a network sniffer check in that there is packet traffic with the PIDs associated to the
flows. − Check the transport stream in the client side using the Monitoring Station. The Monitoring
Station should inform about the new PIDs corresponding to the new video and audio content and PMT and SDT.
− Further verification must be made by checking that now the content can be correctly seen in the TV connected to the Set-Top-Box.
1.1.86.3 Stop a flow Test Reference: STLF_IO_DTV_VIDEO_003 Subsystem: SP RCST, NCC, SP
Pre-Requisite Tests: STLF_IO_MGT_VSP and STLF_IO_DTV_VIDEO_002
Test Platform: In-orbit Digital TV platform
Objectives: The purpose of the test is to verify in the client side the stop of a configured content transmission into the transport stream.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
138 / 151
Test Setup: Test Descr iption: - Open the PATROL console for the management of the Digital TV service. Go to
Machine_Icon-> FLOW_SERVER->FLOWS. - To stop the MPEG-2 content transmission, click with the right mouse button on the icon of
each of the flows with PIDs: 1100 (PMT), 17 (SDT, optional), 8191 (video and audio). For each of them, in the mouse right button menu choose ‘KM Commands’ and then ‘Disable Flow’ . Accept the confirmation box . The traffic light icon of the flows will change from green to yellow, indicating that the flows have stopped transmitting.
- To stop the H264 content transmission, click with the right mouse button on the icon of the flow with PID 768 (includes the video, audio, PMT and SDT). In the mouse right button menu choose ‘KM Commands’ and then ‘Disable Flow’ . Accept the confirmation box . The traffic light icon of the flow will change from green to yellow, indicating that the flow has stopped transmitting.
Results Expected: To see that the flow server has disabled the flow, you can check the flow server current status file ~/config/statusGF, the last flag will be reset to ‘0’ when the flow is stopped (disabled):
50||video1|/export/home/asi/videos/video.mpg|2|0|8191|0|1500000|0| 51||video1_PMT|/export/home/asi/mhp/PSI_SI/pmt1100.ts|2|0|1100|0|4000|0| 52||video1_SDT|/export/home/asi/mhp/PSI_SI/sdt.ts|2|0|17|0|4000|0|
and for the H264 file: 50||video2|/export/home/asi/videos/ H264_1200_content1.mpg |2|0|768|0|1200000|0|
Check with a net analyzer/sniffer that the Service Provider Unit stops receiving packets with those PIDs of the stopped flows. Check the transport stream using the Monitoring Station. The Monitoring Station should inform that it isn't receiving any more packets associated to this content. Consequently, no signal can be seen on STB-TV.
1.1.86.4 Delete an existing flow Test Reference: STLF_IO_DTV_VIDEO_004 Subsystem: SP RCST, NCC, SP
Pre-Requisite Tests: STLF_IO_MGT_VSP and STLF_IO_DTV_VIDEO_003
Test Platform: In-orbit Digital TV platform
Objectives: The purpose of the test is to verify in the client side that a flow could be deleted from the flow server.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
139 / 151
Test Setup: Test Descr iption: - Open the PATROL console for the management of the Digital TV service. Go to
Machine_Icon-> FLOW_SERVER->FLOWS - Click with the right mouse button on the icon of the flows with PID 8191, 1100 and 17
(MPEG-2 comnponents). In the mouse right button menu choose ‘KM Commands’ and then ‘Delete Flow’ . Accept the confirmation box and then the a new box will appear indicating that the flow is deleted. Push OK and the traffic light icon of the flow will disappear.
- Repeat the same operations for the flow with PID 768 (H264 components). Results Expected: Check the flow server current status file ~/config/statusGF, it will not show any line with the flow identifier number of the deleted flow. As the flows were already stopped there is no change in the transport stream received in the Service Provider Unit and client side.
1.1.87 Broadcast interactive applications procedures
1.1.87.1 Start/Stop the flow server This is the same initial test as STLF_IO_DTV_VIDEO_001.
1.1.87.2 Add/configure and start a new interactive application in the flow server Test Reference: STLF_IO_DTV_APP_001 Subsystem: SP RCST, NCC, SP
Pre-Requisite Tests: STLF_IO_MGT_VSP Test Platform: In-orbit Digital
TV platform Objectives: The purpose of the test is to verify in the client side the normal configuration and transmission of a new interactive application that will be added to the transport stream.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
140 / 151
Test Setup: Test Descr iption:
• Open the PATROL console for the management of the Digital TV service. Go to Machine_Icon-> FLOW_SERVER
• Click with the right button of the mouse in the icon called ‘FLOWS’. In the mouse right-click menu choose ‘KM Commands’ and then click on the ‘Add Flow’ option.
• Fill in the data of the flow and then push the OK button to create a new flow. The data of the flow containing the application carousel are: ID->60, PID->1121, name->test1_OC, bitrate->500000, filename->/export/home/asi/mhp/SATLIFE1/multipantalla_OC.mux. This file corresponds to the MHP carousel of the interactive application. The MHP carousel was created with the TID Object Carousel generator as follows:
genOC –i / home/ expor t / asi / mhp/ SATLI FE1/ mul t i pant al l a_OC. xml -o / expor t / home/ asi / mhp/ SATLI FE1/ mul t i pant al l a_OC. mux
• Create a new flow as in the previous point to add the application AIT with the following data: ID->61, PID->1111, name->test1_AIT, bitrate->4000, filename->/export/home/asi/mhp/SATLIFE1/multipantalla_AIT.mux. This file corresponds to the AIT of the interactive application.The AIT was created with the TID AIT generator:
genAI T –i / home/ expor t / asi / mhp/ SATLI FE1/ mul t i pant al l a_AI T. xml - o / expor t / home/ asi / mhp/ SATLI FE1/ mul t i pant al l a_AI T. mux
• Create a new flow as in the previous point to add the SDT with the following data: ID->62, PID->17, name->test1_SDT, bitrate->4000, filename->/export/home/asi/mhp/PSI_SI/sdt.ts.
• Create a new flow as in the previous point to add the PMT with the following data: ID->63, PID->1100, name->test1_PMT, bitrate->4000, filename->/export/home/asi/mhp/PSI_SI/ pmt1100.ts.
• To start the application and AIT flows so that the flow server begins to transmit them, go to ‘FLOWS’ in the PATROL console and then click with the right mouse button on the icon of the application flow you want to start. In the mouse right button menu choose ‘KM Commands’ and then ‘Enable Flow’ . Accept the confirmation box . The traffic light icon of the flow will change from yellow to green, indicating that the flow has started to transmit. Repeat the same operation for the AIT flow (PID 1111) and with the SDT and PMT flows (PIDs 17 and 1100).
• Set the accepted packets in the Service Provider Unit to these PIDs: 1121 (0x461), 1111 (0x457), 17 (0x11) and 1100 (0x44c).
Results Expected: After creation and start of the flows, to see that the flow server has started (enabled) the flow, you can check the flow server current status file ~/config/statusGF, the last flag will be set to ‘1’ when the flow is started (enabled): 60|test1_OC|/export/home/asi/mhp/SATLIFE1/multipantalla_OC.mux|2|0|1121|0|500000|1| 61||test1_AIT|/export/home/asi/mhp/SATLIFE1/multipantalla_AIT.mux |2|0|1111|0|4000|1| 62|test1_SDT|/export/home/asi/mhp/PSI_SI/sdt.ts|2|0|17|0|4000|1| 63||test1_PMT|/export/home/asi/mhp/PSI_SI/pmt1100.ts|2|0|1100|0|4000|1|
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
141 / 151
Check with network analyzer/sniffer that the Service Provider Unit starts receiving packets with those PIDs of the new flows. Check the transport stream in the client side using the Monitoring Station. The Monitoring Station should inform about the new PIDs.
1.1.87.3 Load of an application Test Reference: STLF_IO_DTV_APP_002 Subsystem: SP RCST, NCC, SP
Pre-Requisite Tests: STLF_IO_MGT_VSP and STLF_IO_DTV_APP_001
Test Platform: In-orbit Digital TV platform
Objectives: The purpose of the test is to verify in the client side the loading process of one MHP application. Test Setup: Test Descr iption: Use the IRD remote control to check the load of the interactive applications configured in STLF_LS_CSP_DTV_005. Results Expected: After the loading process, the home page associated with the MHP application will be displayed in the TV set.
1.1.87.4 Stop an interactive application Test Reference: STLF_IO_DTV_APP_003 Subsystem: SP RCST, NCC, SP
Pre-Requisite Tests: STLF_IO_MGT_VSP and STLF_IO_DTV_APP_002
Test Platform: In-orbit Digital TV platform
Objectives: The purpose of the test is to verify in the client side that a started interactive application flow could be stopped and deleted from the transport stream.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
142 / 151
Test Setup: Test Descr iption: - Open the PATROL console for the management of the Digital TV service. Go to
Machine_Icon-> FLOW_SERVER->FLOWS - To stop the application flows, click with the right mouse button on the icon of the flow with
PID 1121. In the mouse right button menu choose ‘KM Commands’ and then ‘Disable Flow’ . Accept the confirmation box . The traffic light icon of the flows will change from green to yellow, indicating that the flow has stopped transmitting.
- Repeat the same for the AIT (PID 1111), SDT (PID 17) and PMT (PID 1100). Results Expected: To see that the flow server has disabled the flow, you can check the flow server current status file ~/config/statusGF, the last flag will be reset to ‘0’ when the flow is stopped (disabled): 60|test1_OC|/export/home/asi/mhp/SATLIFE1/multipantalla_OC.mux|2|0|1121|0|500000|0| 61||test1_AIT|/export/home/asi/mhp/SATLIFE1/multipantalla_AIT.mux |2|0|1111|0|4000|0| 62|test1_SDT|/export/home/asi/mhp/PSI_SI/sdt.ts|2|0|17|0|4000|0|
63||test1_PMT|/export/home/asi/mhp/PSI_SI/pmt1100.ts|2|0|1100|0|4000|0| Check with a network analyzer/sniffer that the Service Provider Unit stops receiving packets with those PIDs of the stopped flows. Check the transport stream in the client side using the Monitoring Station. The Monitoring Station should inform that it isn't receiving any more packets associated to this content. Consequently, no application can be loaded on the STB-TV.
1.1.87.5 Delete an existing interactive application in the flow server Test Reference: STLF_IO_DTV_APP_004 Subsystem: SP RCST, NCC, SP
Pre-Requisite Tests: STLF_IO_MGT_VSP and STLF_IO_DTV_APP_003
Test Platform: In-orbit Digital TV platform
Objectives: The purpose of the test is to verify that a started interactive application could be deleted from the flow server
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
143 / 151
Test Setup: Test Descr iption: - Open the PATROL console for the management of the Digital TV service. Go to
Machine_Icon-> FLOW_SERVER->FLOWS - To delete the application flows, click with the right mouse button on the icon of the OC flow
(PID 1121). In the mouse right button menu choose ‘KM Commands’ and then ‘Delete Flow’ . Accept the confirmation box and then the a new box will appear indicating that the flow is deleted. Push OK and the traffic light icon of the flow will disappear.
- Repeat the same operation with the AIT (PID 1111), SDT (PID 17) and PMT (PID 1100) flows.
Results Expected: Check the flow server current status file ~/config/statusGF, it will not show any line with the flow identifiers numbers 60, 61, 62 or 63. Check the transport stream in the client side using the Monitoring Station. The Monitoring Station shouldn't change its current status, because all the packets monitored are null packets.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
144 / 151
SOFTWARE DOWNLOAD The objective of the Software Download real system tests is the verification in-orbit of all the service capabilities defined in D321 and D322 for the Software Download service, from the content acquisition in the server side to the content reception in the client side using a connection via satellite in regenerative mode.
1.1.88 Test Platform The test platform used for the real system tests is composed by several servers that sends the multimedia contents to the Service Provider and to the RCS terminal. In the client side, a Windows PC will be used to receive the contents and a analyzer to check the transport stream generated. The equipment needed for the Software Download tests is composed by: • A Sun Blade 100 with Solaris 8 O.S. with the software download services. • A PC with Windows O.S. for the management of the download server. • A Service Provider Unit. • A DVB-RCS terminal from Shiron. • The Amazonas satellite. • A PC with Windows O.S. and with a DVB-S card to simulate the client side. • A Monitoring Station to directly receive the DVB-S information and monitor it.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
145 / 151
Figure 0-20 Software Download test platform
The partners involved in the following test are: • TID: which provides the flow and management servers and the client PC. • THALES: which provides the Service Provider and the Monitoring Station. • SHIRON: which provides the RCST. • AAS-E: which provides the SATLIFE network configuration. • HIS: which provides the satellite bandwidth and the RCST. • Hispamar and TPD: which tests the reception of PC contents. The server side with the Service provider Unit, the SP-RCST and the content servers will use the European bean of the Amanozas satellite to transmit the TV contents. These contents will be received in three locations: Madrid (AAS-E) where is installed the client PC and the monitoring station, Guaratiba (Hispamar) and Sao Paulo (TPD). The partners involved in these tests are in charge of: • Setup the scenario. • Perform the proposed test procedures. • Analyse and document their results.
1.1.89 Expected schedule The excepted duration for the following tests are 3 days. This service should be tested with the Digital TV because both services share the same test platform.
1.1.90 Technical requirements The satellite bandwidth needed for home gateway test procedures is 2Mbps.
1.1.91 Test procedures
1.1.91.1 Content transmission Test Reference: STLF_IO_DTV_SWDL_001 Subsystem: SP RCST, NCC, SP
Pre-Requisite Tests: Test Platform: In-orbit SWD
platform Objectives: The purpose of the test is to verify the content transmission procedure all along the line from the software download server to the client side.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
146 / 151
Test Setup: Test Descr iption: - Log-on into the Patrol Console. - Open the software download machine icon and expand the FLOW_SERVER icon and select
the PROCESSES icon to view the current status of all the software download processes. - Select each process (pushMgr, SF_IP, udpFile, wgetMgr) and use the KM command start on
each of them. It will be needed to specify the username and its password. Use the ipg O.S. user.
- Open the software download machine icon and expand the FLOW_SERVER icon and select the PSI_FLOWS icon to view the current status of all the software download flows. Select the KM command to create a new flow. Write the new PID and its bitrate.
- Start the previously created flow by clicking on ‘Enable Flow’ in the ‘KM_Commands’ menu that appears by mouse right button clicking on the flow icon.
- Enable also the PSI/SI data with the same procedure. - Configure the Service Provider Unit to accept packets with PID of the created data flow and
the PIDs that belongs to the PSI/SI data flow (SDT and PMT). - Log-on into the software download web interface. Use the URL
http://192.168.100.20:82/SSDS, Where 192.168.100.20 is the IP address and port number of the software download server.
- Select the Channel management link. A new window will appear that will let the operator to add or delete a channel.
- Add a new channel by associating a flow with port number. - Create a new content schedule with the ‘Guide’ page of SSDS with any existing content and
the channel previously added. Set the starting time in 10 minutes. Set many repetitions in this content schedule.
Results Expected: In the software download server the file ~/ipg/config/statusGF will be configured with one flow and with the PSI/SI data. The list of running processes can be checked by executing the ps command from the software download server console. The status of the current content schedule could be checked using the web interface: Content Administration link -> Schedule list. It would change its status from Enable to Transmitting when the software download server begins to transmit this content. The transmission line can be checked with a network analyzer/sniffer right after the SP Unit. Packets with the content flow PID as well as those PIDs of PSI/SI packets have to be seen. Check with a Monitoring Station in the client side that the VSP transmits a full transport stream with the PSI/SI tables and packets with those PIDs used to configure the test flow.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
147 / 151
1.1.91.2 Program guide reception Test Reference: STLF_IO_DTV_SWDL_002 Subsystem: SP RCST, NCC, SP
Pre-Requisite Tests: STLF_IO_DTV_SWDL_001 Test Platform: In-orbit SWD
platform Objectives: The purpose of the test is to verify the program guide reception procedure all along the line from the software download server to the client side. Test Setup: Test Descr iption: - Log-on into the client PC. - Configure the receiver software to specify the PIDs of the PSI/SI flows and that of the content
flow used to download software. - Configure the server proxy/cache. - Start the web browser application. - Connect to the specific home URL provided by the software download service
http://www.guia-tid.es/guia/index.html. - It will display the current program guide. Results Expected: The program guide has to be available in the client PC. It will display the multiple channels transmitted in the received transport stream with their related contents and the time in which they will be transmitted.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
148 / 151
1.1.91.3 Content download Test Reference: STLF_IO_DTV_SWDL_003 Subsystem: SP RCST, NCC, SP
Pre-Requisite Tests: STLF_IO_DTV_SWDL_002 Test Platform: In-orbit SWD
platform Objectives: The purpose of the test is to verify the content download procedure. Test Setup: Test Descr iption: - Log-on into the client PC. - Go to the current program guide web page: http://www.guia-tid.es/guia/index.html. - Select any content shown in this page to download it. A new window will be displayed with
the content properties. - Select download content. Results Expected: Selecting a new content for its download will start the LSPC process. This process will be in charge of the downloading process when this transmission begins. It is possible to check what contents are going to be downloaded opening with the web browser the HTML file that the LSPC stores in locally.
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
149 / 151
RISKS AND CONTINGENCY PLANS Currently, there are some risks identified that can affect the progress of the SatLife project, delaying some specific functionalities or features of the SatLife equipment, services or devices. In order to reduce or avoid these risks, a contingency plan has been conceive to reduce or avoid them. The following list describes the identified risks, which part of SatLife project is involved, their expected impact, and the contingency plan. Name: Unavailability of the transparent platform capacity in the satellite to carry out the tr ials Subsystem: Transparent platform Supervisor: Hispasat Impact: Without satellite capacity will not be possible to perform in-orbit trials. Actions: • Risk avoidance: to avoid this situation, it is predicted to prepare a correct and early planning for the
different trials, in order to book the necessary capacity for these given dates. • Problem solving: even if after a correct planning there is no availability due to any type of
unexpected event, new trial dates would be fixed with enough time to reorganize all the scenario and the participating partners.
Name: Problems in the international tr ials: installation and terminals reception in Latin Amer ica. Subsystem: Trials in Latin America. Supervisor: Hispasat Impact: Several risks can be encountered here. • First of all, for the installation phase, some of the problems may appear are:
o Equipment installation and initial configuration o Equipment operation
• Second, for the terminal reception in Latin America: o Sending of the equipment. o Dates reception and custom delay/cost. o Correctly terminal reception.
Actions: • Risk avoidance:
o Equipment installation and initial configuration: correct planning of the partners involved in this task fixing the exact dates when they will have to configure or help to the new partners to do it.
o Equipment operation: same than equipment installation. o Sending of the equipment: correct planning of the dates when the equipment will be sent,
identifying who is going to be in charge of sending each of the equipment. o Dates reception and custom delay/cost: correct planning of the dates when the equipment will
be sent, identifying who is going to be in charge of receiving each equipment as well as using the experience from local partners to know the required time/cost (if any) at the customs, will determine the margin required (based on past experience from other deliveries).
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
150 / 151
o Correctly terminal reception: correct planning of who will be in charge of receiving the equipment together with the exact places where these equipment will be logged.
• Problem solving o Equipment installation and initial configuration: in case of installation/configuration problems,
if partners in charge of this task are not able to solve the problems from their premises, will have to travel to the company where the equipment have been sent.
o Equipment operation: same than equipment installation. o Sending of the equipment: if any problems with the sending of the equipment may appear, like
delay, partners will have to inform urgently to all the partners about this delay, making a study of the impact for the reception and remaining trials.
o Dates reception and custom delay/cost: in case of any delay in the reception of the equipment, partners involved will have to urgently inform to all of them about the new date reception and the new planning for that given trial and the remaining ones.
o Correctly terminal reception: if some problems with the correct terminal reception may appear, depending on the impact of the damage, terminals will be repaired in site, sent back to the partner to be fixed, or in the worst case, a new terminal will have to be sent. For sure, if any on this problems may appear, it will encounter some delay, being necessary to inform to the partners and create a new planning taking into account this new expected delay.
Name: Integration of services in the transparent platform. Subsystem: Transparent platform Supervisor: Hispasat Impact: compatibility or integration problems/bugs with the transparent platform. Actions: • Risk avoidance: to avoid this unexpected situation, it is predicted to prepare a correct and early
planning for the different trials, in order to book the enough margin for the successful completion of this task. An early integration can be planned. Maximum compatibility is already pursued through the development and interoperability measures adopted in the project.
• Problem solving: in case of some minor unexpected problem, partners will co-operate to solve this situation. As far as the overall plan for trials covers several months, normal problems that could be encountered could be easily fixed based on the experience gained in the phase of integration at laboratory and for the regenerative part.
Name: Delay in final AmerHis delivery. Subsystem: NCC Supervisor: Alcatel Alenia Space Spain Impact: Delay in the integration of the Video Service Provider features. Actions: NCC delivery splitted into three incremental versions to allow the start of the integration with the rest of the subsystems: - NCC v1.0: support of SP RCST synchronization - NCC v2.0: multicast features - NCC v3.0: multiple VSP table management
IST-1-507675
SATLIFE SATLIFE
D422 DATE:
30/09/2006
ISSUE:
v1.2
PAGE:
151 / 151
Name: Problems with the traffic transmission from the SP RCST. Subsystem: SP RCST Supervisor: Alcatel Alenia Space Spain Impact: Traffic transmission with limitations Actions: Shiron people have come to Madrid to perform the test with AAS-E test bed to speed up the resolution of problems in the SP RCST. However this is not solved yet. They are commited to perform more debugging in their premises to achieve the expected results. Name: Support of the NERA terminal. Subsystem: NERA Supervisor: Alcatel Alenia Space Spain Impact: The support of NERA for the resolution of possible bugs will be limited in time after being bought by STMi company from the United States. Actions: Remote Access to the AAS-E test bed has been prepared for online debugging and to speed up the integration. Name: The MCU used in the Multiconference service needs a license in order to continue the tests. Subsystem: Multiconference service. Supervisor: Telefónica Investigación y Desarrollo Impact: The MCU is in charge of transform unicast traffic into multicast, so it is an essential element for SatLife multiconference system. Without this license, multicast will not be available. Actions: Radvision, the provider of the MCU, has provided a licence to use it until 23th July 2006. In order to continue with MCU tests, a new license will have to be bought because Radvision will not provide more demo license. Name: The IP DSLAM doesn’ t have activated the PPPoE functionality. Subsystem: ADSL and satellite internetworking Supervisor: Telefónica Investigación y Desarrollo Impact: The PPPoE scenarios proposed for ADSL and satellite internetworking scenarios couldn’ t be tested with TID’s IP DSLAM. Actions: There is a negotiation with Lucent in order to obtain a temporal activation for the PPPoE functionality in the IP DSLAM. Currently there are four scenarios for ADSL and satellite internetworking, two of them uses PPPoE, so at least, two scenarios will be ready to test. It is expected to document PPPoE scenarios in SatLife deliverables even if PPPoE tests can’ t be performed. If the activation of PPPoE functionality couldn’ t be done, TID will try to change the IP DSLAM used in this scenario to another IP DSLAM manufacturer.
